The shift from physical servers to consolidated, virtualized server infrastructures has had undeniable IT benefits. However, the rapid move to VMware has caused traditional approaches to disaster recovery (DR) to become outmoded and added a layer of complexity to DR implementation. DR for VMware® Virtual Infrastructure 3 (VI3) requires that all your VMs (virtual machines) be regularly replicated to a remote site, consuming significant storage and network bandwidth. By using NetApp deduplication on your primary VMware storage systems, you can substantially reduce the amount of data in your primary storage environment. This reduction results in a cascading benefit to your downstream infrastructure, reducing the bandwidth necessary for replication and the storage necessary at the DR site. The cost savings created by using deduplication can make DR feasible in situations in which it may have otherwise been cost prohibitive. For instance, one customer reported that after deduplicating his VMware Virtual Desktop Infrastructure (VDI) environment, the storage and bandwidth needed to provide DR for his desktops was relatively minor and made adding DR feasible for his VDI environment as well as his VI3 environment.
The shift from physical servers to consolidated, virtualized server infrastructures has had undeniable IT benefits. However, the rapid move to VMware has caused traditional approaches to disaster recovery (DR) to become outmoded and added a layer of complexity to DR implementation. DR for VMware® Virtual Infrastructure 3 (VI3) requires that all your VMs (virtual machines) be regularly replicated to a remote site, consuming significant storage and network bandwidth. By using NetApp deduplication on your primary VMware storage systems, you can substantially reduce the amount of data in your primary storage environment. This reduction results in a cascading benefit to your downstream infrastructure, reducing the bandwidth necessary for replication and the storage necessary at the DR site.
The cost savings created by using deduplication can make DR feasible in situations in which it may have otherwise been cost prohibitive. For instance, one customer reported that after deduplicating his VMware Virtual Desktop Infrastructure (VDI) environment, the storage and bandwidth needed to provide DR for his desktops was relatively minor and made adding DR feasible for his VDI environment as well as his VI3 environment. In this article I’m going to explore what it takes to implement deduplication with VMware DR. I’ll also talk about leveraging the replicated data in your DR environment for DR testing and other purposes. Implementing Deduplication in Your Primary VMware Environment Because each virtual machine in a VMware environment requires dedicated storage for its operating system, there is a large amount of duplication. You may have numerous VMs that are all installed with more or less the same operating system and applications. If you have 100 VMs running the same OS and each virtual machine requires 10GB to 20GB of storage, that’s 1TB to 2TB of storage dedicated to almost identical copies of the same data.
Applying NetApp deduplication can eliminate much of this redundancy. In general terms, if you have X virtual machines assigned to a storage volume, after deduplication you will need approximately 1/X the amount of operating system storage you would require in a non-deduplicated environment. Obviously, the actual results you achieve will depend on how many VMs you have in a volume and how similar they are. In practice, customers typically see space savings of 50% or more in ESX VI3 environments, with some obtaining storage savings as high as 90%. This is for deduplication of the entire VMware storage environment including application data—not just operating systems. In VDI environments customers typically see space savings up to 90%. Another advantage of NetApp deduplication is that not only can it run on primary storage, it can run on any existing NetApp volume.
Even if your VMware infrastructure is well established, you can run deduplication and free up significant storage space. All that is required is the deduplication license (which is free of charge) plus a NearStore® license on the target storage system. Configuring for Disaster Recovery While the reduction in storage use in your primary storage environment is a significant benefit by itself, the true leverage you get from deduplication becomes apparent when you implement disaster recovery with NetApp SnapMirror®. Because deduplication significantly reduces the amount of data that must be replicated, it reduces both the space needed in your DR location and the network bandwidth needed between sites. After deduplication, you may be able to configure DR over a slower link than would otherwise be possible, and it will be easier and faster to get your DR environment up and running.
To configure DR, you first deduplicate all the volumes in which your data stores reside in your primary VMware storage environment. Then you create SnapMirror relationships between your primary volumes and target volumes at your DR site. Note that because deduplication acts at the volume level, you must use Volume SnapMirror to get the maximum benefit. Volume SnapMirror acts on the entire volume, so your mirror always retains the same level of deduplication as the original, saving space, decreasing bandwidth utilization, and speeding up the mirror update process. Once you complete the initial sync, you configure SnapMirror to run on a set schedule to keep your DR site up to date. In each iteration, SnapMirror transfers only the blocks that have changed, so it uses network bandwidth very efficiently.
In this article I’m going to explore what it takes to implement deduplication with VMware DR. I’ll also talk about leveraging the replicated data in your DR environment for DR testing and other purposes.
Implementing Deduplication in Your Primary VMware Environment
Because each virtual machine in a VMware environment requires dedicated storage for its operating system, there is a large amount of duplication. You may have numerous VMs that are all installed with more or less the same operating system and applications.
If you have 100 VMs running the same OS and each virtual machine requires 10GB to 20GB of storage, that’s 1TB to 2TB of storage dedicated to almost identical copies of the same data. Applying NetApp deduplication can eliminate much of this redundancy. In general terms, if you have X virtual machines assigned to a storage volume, after deduplication you will need approximately 1/X the amount of operating system storage you would require in a non-deduplicated environment. Obviously, the actual results you achieve will depend on how many VMs you have in a volume and how similar they are.
In practice, customers typically see space savings of 50% or more in ESX VI3 environments, with some obtaining storage savings as high as 90%. This is for deduplication of the entire VMware storage environment including application data—not just operating systems. In VDI environments customers typically see space savings up to 90%.
Another advantage of NetApp deduplication is that not only can it run on primary storage, it can run on any existing NetApp volume. Even if your VMware infrastructure is well established, you can run deduplication and free up significant storage space. All that is required is the deduplication license (which is free of charge) plus a NearStore® license on the target storage system.
Configuring for Disaster Recovery
While the reduction in storage use in your primary storage environment is a significant benefit by itself, the true leverage you get from deduplication becomes apparent when you implement disaster recovery with NetApp SnapMirror®. Because deduplication significantly reduces the amount of data that must be replicated, it reduces both the space needed in your DR location and the network bandwidth needed between sites. After deduplication, you may be able to configure DR over a slower link than would otherwise be possible, and it will be easier and faster to get your DR environment up and running.
To configure DR, you first deduplicate all the volumes in which your data stores reside in your primary VMware storage environment. Then you create SnapMirror relationships between your primary volumes and target volumes at your DR site. Note that because deduplication acts at the volume level, you must use Volume SnapMirror to get the maximum benefit. Volume SnapMirror acts on the entire volume, so your mirror always retains the same level of deduplication as the original, saving space, decreasing bandwidth utilization, and speeding up the mirror update process.
Once you complete the initial sync, you configure SnapMirror to run on a set schedule to keep your DR site up to date. In each iteration, SnapMirror transfers only the blocks that have changed, so it uses network bandwidth very efficiently.
