We have been using the VMware Data Recovery Appliance (or trying to) since it was released. Overall it has been a bumpy road, but the latest release shows a lot of promise.
Improvements in stability are obvious, but we still run into issues where backup jobs stop running for no reason. This means that you have to monitor somehow, unfortunately there appears to be no good way to automate this.
You are still limited to 100 VMs per appliance, this would be OK if it were possible to attach more than one appliance for management to a VC client session simultaneously. Even better would be a unified console of some kind.
The 100 VM limitation can be worked around using carefully designed Resource Pools. The VDR appliance "notices" when a VM has been added to a RP properly.
At this point I would suggest completely skipping CIFS. It is horribly unreliable. In fact when you attempt to configure a CIFS destination you are greeted with a warning that in many more words says this.
If your goal is to send VM backups to remote storage, I would suggest a NFS datastore, and using VMDK storage on that. The VDR appliance seems to deal with this very well.
The total size of the destination dedupe store is still limited to 1TB per destination, and a max (suggested) of two destinations. VMware's explanation for this suggests performance issues with larger stores.
In our experience, the data deduplication works very well. You can pack a lot of backups into that 1TB of storage.
The hot-add backup mechanism works very well and created very little I/O impact while running backups. However, if the appliance does not shutdown properly orphan devices are left attached to the appliance. These often need to be removed manually.
Overall, the VDR appliance shows a lot of promise. We would like to see better management, better stability, easier scaling and some kind of monitoring capability are needed. We would like to see the backup tasks and progress shown in the normal VC task list. This would help with the monitoring. A published API would also be helpful for us to write our own NAGIOS plugins.
Random ramblings of a common nerd. IT Professional, Kitchen Hacker, Electronics hobbyist, and coder of microprocessors small and large. This is my corner of the web.
Showing posts with label VMware. Show all posts
Showing posts with label VMware. Show all posts
Sunday, January 3, 2010
Saturday, December 19, 2009
Upgrading to VMware vSphere 4? Check the HCL!
If you are upgrading your VMware VI3 compute complexes to VMware vSphere 4, you will need to confirm that all your hardware is certified for the release you are upgrading to. Most hardware manufacturers will only do the certification work while a system is considered a current product. This can be as short as two years.
After a server, blade or storage array is no longer availible for sale, you may be STUCK on whatever ESX rev you are currently running. This is a big problem for vManagers who want to use new features only availible for vSphere 4. Even worse, VMware Update Manager makes it dangerously simple to upgrade your entire cluster to vSphere 4 with a few mouse clicks. Regardless if your hardware is still certified.
After a server, blade or storage array is no longer availible for sale, you may be STUCK on whatever ESX rev you are currently running. This is a big problem for vManagers who want to use new features only availible for vSphere 4. Even worse, VMware Update Manager makes it dangerously simple to upgrade your entire cluster to vSphere 4 with a few mouse clicks. Regardless if your hardware is still certified.
- Keeping compute and storage hardware on a life cycle plan is critical, and keep that plan aligned as best as possible with the software.
- Talk to your vendors, demand a policy on VMware HCL certification.
- Understand your hardware vendor's product lifecycle
- Check the HCL: VMware's Live Hardware Compatibility Guide
Subscribe to:
Posts (Atom)