2009-03-24 10:25 AM
If I want to put Exchange or SQL server onto VMWare hosts. How do I get MS VSS to flush and snap the databases?
Do I need to create luns for each of the databases and manage them from the VM using iSCSI and lose some of the VMotion options or do I create the databases on VMDK and then use something to manage VM's VSS and ESX server to flush and snap.
Solved! SEE THE SOLUTION
2009-03-24 12:36 PM
There is information about the VSS driver in the VMware VM Backup guide here http://vmware.com/pdf/vi3_35/esx_3/r35u2/vi3_35_25_u2_vm_backup.pdf
Basically, if you have installed the version of VMware tools distributed with ESX 3.5U2 or later then the VSS driver is installed by default. Once this is installed inside the guest this means that any VMware VM snapshots that are taken of that guest (such as the snapshots that SMVI temporarily creates) will us the VSS driver and create application consistent snapshot of that VM for any VSS aware applications running in that VM.
VMware currently doesnt support calling the VSS driver with VMware snapshots if you have storage connected directly to the guest via a software iscsi initiator inside the guest. So the model described above would be for VMs with applications where the data was stored in vmdk disks. For VMs with data in guest connected luns you would use a product like SnapManager for Exchange or Snapmanager for SQL to create application consistent snapshots.
I hope this addresses your question, please let me know.
Thank you for the question,
2009-03-24 06:18 PM
Just to highlight one part of Larry's (very good) answer, if you want to use SnapManager for SQL/Exchange on a VM, you'll need to put the Exchange/SQL data on a disk provided by an RDM (i.e. LUN) directly from the filer.
There is also a bit missing right now as far as coordination between SMVI & SME/SMSQL when inside VM's.
2009-03-25 03:16 AM
Just a minor point on that reply...
use the VSS driver and create application consistent snapshot of that VM for any VSS aware applications running in that VM.
This discussion has been had elsewhere, but the VSS driver alone is not enough to create application consistent snapshot. The application has to be prepared, and you also need a way to handle log files.
The ideal way to do this is to have your application data on SnapDrive connected storage, and then use SMAI to trigger fully consistent snapshots of the application data. Then you snapshot the Virtual Machine anyway you like as the data you really care about has been backed up cleanly.
2009-03-25 09:14 AM
Keep in mind that these two scenarios meet different goals, and you get different restore capabilities depending on what design you implement.
SQL/Exch with data in guest connected iSCSI LUNs or FCP RDMs and Snapdrive and SMSQL/E inside the guest: In this case you use the SMSQL/E appliction inside the guest to get application consistency for data disks. You get full restore capabilities including point in time restores and the ablilty to roll logs foward (if you still have them of course) to recover to specific points in time that you select or as far forward as you can go. You also get other such features provided by the SMSQL/E products like backup validation that is done each time a snapshot is created. If you put SnapManager for Virtual Infrastructure into this environment then you get the ability to create NetApp snapshots of the virtual machine system disks. If you should need to recover the whole VM you would perform a VM recovery with SMVI, then go into the VM and use SMSQL/E to recover the database to the desired consistency point.
SQL/Exch with all data in vmdk disks, no Snapdrive or SMSQL/E in the guest, using SMVI: In this case you can enable VSS by using the VMware tools that ships with ESX 3.5U2 or later, and also enabling the application's VSS writer, in the case of SQL for example this is the SQL Writer. The goal of doing this, in an SMVI environment, is to ensure that the image of the whole VM that is captured in the NetApp snapshot is application consistent. Keep in mind that what SMVI does is capture a VMware VM snapshot inside of a NetApp snapshot. So enabling VSS in this manor is actually capturing application point-in-time consistency in the VMware snapshot, and then NetApp captures that. This is the same technique use by VMware's VCB 1.5 product to get application consistent backups. The VCB product create a VSS application consistent VMware snapshot of the whole VM, then mounts that snapshot and reads the data from it, in our case we do the same but instead of mounting and reading, we create a NetApp snapshot. This design is not intended to truncate log files for the purpose of providing restore capabilities such as individually restoring data disks vs. log disks then picking a restore point or rolling logs forward. This design is simply intended to ensure that the image of the VM being captured by SMVI is application consistent. Recovery of a VM with SMVI that has been backed up in this maner is more like a "restart" than a "restore". When performing the SMVI restore of the whole VM you are, in effect, restarting the VM back to a point-in-time, it just so happens that this point-in-time was made application consistent with the VSS writer. When the VM was made application consistent with the VSS call there were no truncation of logs or creating of restore points. However, when you perform a SMVI VM restore, as far as the Windows OS inside that VM is concerned, you are not performing a "restore" you are simply "restarting" the VM, which restarts the application, which comes up to the last point-in-time captured by VSS. This model does not provide any roll forward restore capability but it does capture a point-in-time application consistent whole VM image which can be restored all at once.
The SQL writer was shipped with SQL 2005 and installed but not enabled by default, in SQL 2005 SP2 it was enabled by default. In SQL 2008 it is installed by default. There is info about the SQL writers here, here, and here from MS tech net.
2009-03-25 09:56 AM
Cheers for the info Larry, that's a lot to take in.
Excuse me for being naive, but this is completely contradictory to the SMAI message (or I have completely misunderstood the message, which is entirely likely ) . To get full application consistent snapshots you need to use the VSS writer in conjunction with some level of application integration to prepare the application for a clean backup. Many competitors have VSS writer plugins and this is the strong foot we have used to prove that the NetApp solution is superior.
Sorry to ask you to spell it out, but I just want to make sure I am clear on the messages here.
2009-03-25 10:11 AM
What you say is true regarding creating a history of backups of a database application for example, in which you can select any one of the backups and recover to it, or roll transactions or contents of logs into the recovered data files. However in the case of using the VSS driver inside of a VM that is being backed up with SMVI, we are not backing up just the application, we re backing up the whole VM. The VSS driver provides a way to ensure that the application is consistent inside that VM backup image, just as it is used by VMware's VCB 1.5 product to ensure that a database is consitent inside the VMware snapshot that VCB creates then reads from. In this case VSS is not being used to create a history of backups inside the VM, or a list of backups with which you could roll forward, only to force a flush of application data to disk to create point-in-time application consistency. A SMVI restore recovers the VM to that point-in-time.