Re-architecting Data Protection Processes with Data Deduplication and Virtualization Technologies #BC3819
This session is moderated by Ron Oglesby, Service Director – Virtualization for Glass House Technologies. This is a Datadomain session that I anticipate to be a about the design and implementation issues faced by various Datadomain customers. No internet connection in this room so this will be a delayed post.
Like all the other sessions, the disclaimer slide is shown. I’ve learned from the last session not every session is going to have “forward looking” statements. Ron even commented that the slide was put in all the VMworld 2008 presentations by the VMware legal team.
Ron begins by discussing storage being the number one cost in a virtualization implementation. Snapshots, backups, and VM replication and cloning result in the need for large amounts of storage. Complicate this with the need for faster recovery, management automation, and increasing retention and compliance requirements help skyrocket the storage design footprint. Storage is implemented for virtualization too often as an afterthought.
Ron explains the session is about options for storing and replicating snapshots of VMs and the storage ramifications of server consolidation. The session will also illustrate how deduplication and virtualization complement each other.
The rest of the session was customer testimonials. The following are various comments from the customers that caught my attention.
- Datadomain demo box was installed and receiving data within 15 minutes. Very quick to install and configure.
- Able to get rid of about a rack and half of backup equipment and replace it with a 3U Datadomain box
- A 5TB Datadomain box is more expensive than 5TB of disk storage. In reality it equates to 5X the amount of storage.
- Using vRanger and Backup Exec as the backup products and Datadomain as the target.
- A 5TB Datadomain device is actually storing 50TB of data at the primary location and close to 100TB at the secondary location.
- Data is deduplicated inline and before it ever hits the disk.
- The Datadomain filer is a target on the network. It is seen as a NAS or can be used with fiber channel.
- If using vRanger do not compress the backup for quicker restores. Turning off compression also increases the de-dupe ratio.
- After the Backup Exec job completed, replication to the DR site Datadomain filer was complete within 15 minutes.
- Experimenting with running live VMs on the Datadomain NFS share at the DR site
- 185 VMs are being replicated on a DS3 connection with about 15% utilization of that pipe. Only de-dupe deltas are replicated.
- You can triple the capacity of the 5TB Datadomain device by adding up to 3 additional disk shelves.
- Sizing the disk space needed for the Datadomain device must take into account the retention period of the data along with the size of data in use.
It was interesting to me to hear about running live VMs on the Datadomain NFS share. I was under the impression this was not supported and even if it was, it was not a good idea. A Datadomain filer was better used as a target for static files such as backups. The session today showed that some customers are running VMs on NFS from a Datadomain device at least in the DR site.
Related Posts
Tags: backup, datadomain, NFS share, replication, snapshot, storage, virtualization, vmware, vmworld2008
September 16th, 2008 at 11:52 pm
[...] pc a couple of great articles were released, read ‘em or view ‘em here: Rich Bramley: BC3819: Re-architecting Data Protection Processes with Data Deduplication and Virtualization Technol… VirtualFutute.info: Fault Tolerance VirtualFuture.info: VDM 3.0 Scott Lowe: TA2668: VMware ESX [...]
September 17th, 2008 at 10:42 am
Rich,
You need to pay attention to the following 2 statements which summarize the cost/benefit ratio:
1) Runnning Live VMs
2) A 5TB data domain box is actually more expensive than 5TB of disk. In reality it equates to 5x storage.
Dedupe vendors provide, as an example, 1TB of physical disk which they make it look like 10TB (10: 1) and charge as if you’d purcased 5TB.
Production and user data dedupes at around 2:1 ratio. In fact, the avg. dedup we’re seeing in server virt. deployments is in the 50-60 percentile.
So how would someone like to buy 1TB of physical, pay for 5TB logical capacity, and get 2TB out of it?
September 23rd, 2008 at 10:45 pm
Nick,
If I understand your comment right, you are referring specifically to running live VMs or live user data on a deduped volume? That’s where the ratio falls to the lower numbers and makes the cost ratio unacceptable. That basically supports my comment about a Datadomain device being a better target for static backup files. That’s why it surprised me to hear about running VMs from the DD filer in the DR site. Did I misunderstand your point?
September 27th, 2008 at 11:24 am
[...] Rich Brambley has some great coverage of various VMworld sessions: BC3819, BC2370, PO2575, and VD3261, among others. Excellent work, [...]
October 9th, 2008 at 1:37 pm
Using NFS as a datastore for ESX guest OSs is completely supported and has been since ESX 3.0 [http://www.vmware.com/pdf/vi35_san_guide.pdf page 33].
There are several advocates for taking this approach.
On the performance front, NetApp and VMware have shown that due to NFS’s efficient nature, NFS over 1Gb Ethernet holds it’s own when compared to VMFS over iSCSI and 2Gb Fiber Channel [http://media.netapp.com/documents/tr-3697.pdf].
NFS has several features that make it appealing to many shops. Each organization has to weight the cost/benefit of VMFS over FCA, VMFS over iSCSI, and NFS for themselves. Each solution has its merits and pitfalls–none are out and out a bad idea.
October 10th, 2008 at 7:55 am
Mike,
My comment about running the VMs on the NFS share was not about NFS in general. NFS is absolutely supported as a data store for ESX and can host live VMs with performance matching iSCSI and FC in some cases.
I was commenting on using the DataDomain NFS share specifically. The DD device is designed as a backup target. I’ve personally been advised by a DD rep not to architect VI solutions relying on using a DD NFS target as a live ESX datastore.
October 10th, 2008 at 9:57 am
Whew! Thanks for clarifying. Keep up the good work!