Le snapshots di VMware sono la base di ogni soluzione di backup basata sulle librerie VADP (VMware APIs for Data Protection). Se un disco può essere oggeto di snapshot, allora può essere salvato. Semplice.
Tuttavia, ci sono alcune situazioni dove questa soluzione incontra delle difficoltà. La più nota forse, e per esempio chi è abiutale frequentatore dei forum di Veeam lo sa bene, sono le virtual machine con Exchange 2010.
L’uso del disco in Exchange 2010
Il nuovo formato del database è stato progettato da Microsoft per essere leggero e poco invasivo sullo storage sottostante, ed è stato ottimamente spiegato qui. La spiegazione tecnica sta in questo passaggio:
“By increasing the size of the I/O and reducing the frequency of read/writes in Exchange 2010, ESE is able to increase performance. In addition, ESE can increase performance by making the data in the database more sequential, which increases the likelihood that related data is in the same vicinity in the B-tree.
In Exchange, all data inside the database is stored in B-trees, and the B-trees are then divided into pages. In Exchange 2007 and earlier, the data stored in the B-trees isn’t contiguous. In fact, previous versions of Exchange performed random read/writes to the database. This means that related data may not be in the same vicinity on the hard disk. Non-contiguous data requires more passes to read and write to the hard disk.”
Quindi, per riassumere, Exchange cerca quanto più possibile di usare blocchi contigui di disco e di scrivere blocchi molto grandi. Il design pare concepito prettamente per un sistema fisico, ma anche in ambienti virtualizzati porta grandi benefici. Dato che la RAM diventa sempre più economica, e con il nuovo vSphere 5.1 i limiti di vRam sono stati tolti, è possibile aggiungere più RAM ad un server Exchange 2010 e usarla come cache, riducendo quindi lo stress sui dischi.
VMware ha condotto alcuni test prestazionali e ha pubblicato i risultati qui.
Alla fine, da un punto di vista produttivo, sono state migliorie notevoli, dato che adesso è possibile eseguire Exchange 2010 su lenti dischi SATA e avere nonostante ciò buone performance, potendo quindi virtualizzare un’altra applicazione “Tier 1” senza patemi.
Il problema con i backup VADP
Ma, cosa succede dal punto di vista di VADP? I backup incrementali utilizzano le informazioni CBT rese disponibili da vSphere stesso. Il programma di backup legge quali blocchi sono stati modificati rispetto al precedente backup, e salva solo questi. Ma dal momento che Exchange 2010 funziona nel modo descritto prima, ci sono molti più blocchi modificati, e i set di backup sono più grandi che nelle precedenti versioni di Exchange.
Questo porta a due conseguenze: prima, i set di backup sono più grossi e usano più spazio disco per essere salvati, seconda richiedono più tempo per essere completati e quindi anche il commit delle snapshot a fine backup richiede molto più tempo che in passato, e a volte crea problemi al sistema operativo guest e ai servizi Exchange. Potete leggere in giro di come gli amministratori di Exchange 2010 attendono letteralmente ore per completare la commit di una snapshot.
Inoltre, a peggiorare le cose, avrete posizionato la VM Exchange su un lento datastore SATA come vi è stato suggerito, e quindi ogni operazione disco sarà impattata da questa lentezza, backup e snapshots commits inclusi.
Alla fine, se guardata all’immagine complessiva, un datastore sata eccessivamente lento per Exchange 2010 forse non è la scelta perfetta dopo tutto…