2009-03-24 03:03 PM
What has your strategy been for protecting your VDI data (OS and/or user data)?
Here are some things to consider that might help you decide whats best for your environment.
Solved! SEE THE SOLUTION
2009-03-24 04:26 PM
Data Protection for VDI is a very interesting topic. I think this conversation will evolve over time. This thread reminded me of a conversation this week that I thought was worth sharing.
In a meeting with a customer this week planning to deploy a 1300 seat VDI environment they saw SMVI and began an interesting dialog. Today they don't backup any workstation data. They are a healthcare organization and have had situations where a investigation has began for some HIPPA violation. In those circumstances they are required to collect the users workstation and retain all data on it to assist the investigators in determining if a violation occurred and specifically what exposure there might be. The collection of the users workstation and the legal hold that is placed on that desktop is disruptive to that employees productivity for the organization.
They long considered performing backups of user workstations to simply restore the data from that particular users desktop to a new desktop and provide that to the folks performing the investigation. The analysis of costs associated with backup agents, bandwidth required for backups and the need for all users PCs to be left on all night, plus the absolute nightmare of tracking down why a desktops backup failed proved to be simply not worth the effort.
VDI and SMVI bundled with a couple of other NetApp technologies present a very unique possibility for the customer and I believe something that others might consider in similar situations.
So if you have followed our capabilities with SMVI you know that we can take a point in time, space efficient SnapShot, of a running virtual machine. You also know that we can make a FlexClone from that SnapShot and boot up that virtual machine from the FlexClone.
We often think of the use of FlexClones and virtual machines in the context of Site Recovery Manager or Rapid Cloning, yet as you begin to embrace the functionality available in these features you begin to see other potential uses.
Now many NetApp customers know that we have a product called SnapLock which effectively allows us to take a volume and turn it into a WORM compliant storage destination. Many organizations are required by law to write data to a WORM compliant volume in the context of an archive using an application like Symantec's Enterprise Vault.
Many people also know that when we replicate production volumes with SnapMirror, the SnapShots in those production volumes are also replicated. Finally, there are a great number of customers who know that we can replicate, just snapshots, from one array to another through the use of our SnapVault technology (basically Vault the snapshots to another destination to extend the period that copy is retained). What many people don't know is that we had a product called LockVault, this product basically was the SnapLock and a SnapVault license bundled together to enable the ability to make WORM compliant SnapShots. We eliminated the LockVault bundle but the functionality still remains through the purchase of SnapVault and SnapLock.
Roll this forward into what this means to the healthcare organization I met with. They can now use SMVI to take nightly snapshots of all 1300 desktops in their environment. In the event that a users workstation, now a Virtual Desktop is deemed to be on legal hold. They can simply take that SnapShot and vault it has a WORM compliant SnapShot, with retention set for the time frame identified by legal.
When legal wants to research that desktop the IT staff can simply make a FlexClone of the WORM compliant Snapshot and boot up that virtual desktop for legal to perform their research. No more need to stop the employee who's desktop needs to be investigated from continuing to work. The next great feature in all of this is that legal can work with the FlexClone without worrying about deleting any data on legal hold, they can't. The original data contained in the SnapShot remains because it has been Vaulted as a WORM compliant SnapShot.
The possibilities are near limitless with many of these different NetApp technology combinations. Sorry to deviate from the original intent of the thread but thought it was a unique data protection story worth sharing.
One of our biggest evangelists in virtualization at NetApp is Vaughn Stewart and he often says that "virtualization changes everything". I will add to that and say when you begin to observe the business problems that can be solved with a few technologies that NetApp has had for several years combined with Virtualization....
"Virtualization running on NetApp changes Everything."
2009-03-27 10:44 AM
In addition to the previous summary of our broad NetApp to NetApp story around data protection, NetApp has a set of solutions targeted for non-NetApp environments. Included in that set is Open Systems SnapVault (which one of the replies to this discussion is using today for the VDI Data Protection), and VTL.
Quick rundown of OSSV is that it provides backup to disk over IP network infrastructure from all major OS's/Guest OS's with SAN and direct attached storage or internal storage. Essentially, install a light weight agent on an OS (Win, UNIX, LINUX, GuestOS, ESX) and pick and choose filesystems to backup to our disk over existing IP networks. The coolest part about OSSV is that it backs up the filesystem data and stores it in a SnapMirror/SnapVault format for quick NFS/CIFS/access. It's all stored in a snapshot and can be cloned/replicated/moved to tape, etc etc etc. Hundreds of versions of your host can be stored on disk and can be recovered from in a variety of ways. It really does ease the pain of restoring (the entire reason we backup). The latest version of OSSV, OSSV 2.6, installs on ESX and will discover all VMs that belong to that VI and will backup the raw VMDKs, VMX files from those VMs all from ONE agent. No need to install 50 backup agents if you have 50 VMs, install 1 on the ESX and manage it all from there.
Lastly, for the traditional backup to tape solution in a large data center with a fairly complex tape backup infrastructure we have NetApp NearStore VTL appliances which essentially make disk look like tape. VTL is primarily for a quick movement to a disk based backup solution for non-NetApp environments when all policies must be preserved, backup performance must be out of this world, and FC/SAN environments are used.
Oh yea, don't forget about dedupe on any of these solutions! We can run it on our disk backups, we can run it before replicas (esp Snapmirror replicas) and achieve dedupe across data centers, etc. And... it's free....
Again, sorry to move away from VDI in general but VDI certainly falls into this area whether it's on NetApp or not!
2009-03-27 10:56 AM
One more thing I forgot to mention, for more info on the non-NetApp backup solutions see:
http://media.netapp.com/documents/tr-3466.pdf (OSSV Best Practice Guide).
For more info on our VTL solution see:
http://media.netapp.com/documents/tr-3673.pdf (config guide for VTL)
2009-03-27 11:01 AM
Hi Bren. You can also use OSSV 2.6 which is built for ESX, the agent is installed directly on the ESX server and not on each individual VM. Can reduce management/deployment headache as well. You backup the actual raw image files for DR, etc with 2.6. You'd backup each VMs, VMDKs, and other system files. You then could restore an entire VM from the backups sitting in OSSV snapshots on NetApp. We still only backup block level (4KB) incrementals (not files) on updates. More info here: http://www.netapp.com/us/library/technical-reports/tr-3653.html
2009-03-28 01:25 PM
Just since I haven't heard this mentioned.....the last discussion I had around this focused on forcing all user data onto CIFS shares from the NetApp. At that point it's all same tools/techniques we're relatively familiar with already in a CIFS environment.
Although this could be done at any time (locking down Windows workstations could be done whether physical or virtual), using VDI + non-persistent desktops + CIFS shares seemed like a good combination (and a good way for them to get to where they wanted to be with data off the "local desktop").