Home > Blogs > VMware Consulting Blog

Quickly Calculate Bandwidth Requirements with New vSphere ‘fling’

By Sunny Dua, Senior Technology Consultant at VMware 

With a number of my recent consulting engagements, I have seen an increasing demand for host-based replication solutions for data replication. In a few of my recent projects, I have implemented VMware Site Recovery Manager in combination with VMware vSphere Replication.

I have written about vSphere Replication (VR) in the past and I am not surprised that a number of VMware customers are shifting focus from a storage-based replication solution to a host-based replication solution due to the cost-benefit and flexibility that comes with such a solution.

In my projects I started with replicating simple web servers to DR site using VR; now customers are discussing database servers, exchange, and other critical workloads to be replicated using vSphere Replication. With an out-of-the-box integration with a solution such a as VMware Site Recovery Manager, building a DR environment for your virtualized datacenter has become extremely simple and cost effective.

The configuration of the replication appliance and SRM is as easy as clicking NEXT, NEXT, FINISH; however, the most common challenge has been around estimating the bandwidth requirements from Protected Site to Recovery Site for the replication of workloads. One of the most commonly asked question is: “How do I calculate the bandwidth requirements for replication?”

This is not only a concern with any host-based replication solution, but with storage-based replication too. I have done crazy things like capturing writes on a workload in KB/Sec for days to get to an average change rate for a workload. This has to be done for each workload that you want to replicate until you finally come to an estimate—which is usually no where close to the actual figure. Nevertheless, something is better than nothing.

During my recent discussions with VMware product management, I requested a tool that can do the mathematics for a given workload and help us estimate the bandwidth requirements. This is critical for customers: An oversized bandwidth requirement can lead to waste and unnecessary Operational Expenditure, while an undersized bandwidth calculation can break the DR solution, a catastrophic event for any business.

The great news is that such a tool (a fling) now exists! The vSphere Replication Capacity Planning Appliance.

According to the developers: “The vSphere Replication Capacity Planning Appliance allows administrators to model the network impact of a virtual machine replication without producing actual replication traffic. The appliance provides command-line tools to configure replication for any VM in a vSphere Virtual Center. The replication is established in preview mode and thus requires no storage space. Networking traffic, required for the replication, is measured and displayed in an easy-to-understand graphical format that allows you to estimate the network bandwidth required.”

Since this is a fling, you’ll want to know that there is no official support for flings. I recently got an opportunity to deploy the appliance and run it to capture traffic and replication requirements for one of my lab virtual machines. I cover all the steps to configure this appliance and get the results you need in my latest blog post.

This post originally appeared on Sunny Dua’s vXpress blog. Sunny Dua is a Senior Technology Consultant for VMware’s Professional Services Organization, focused on India and SAARC countries.

3 thoughts on “Quickly Calculate Bandwidth Requirements with New vSphere ‘fling’

  1. Rob

    I’m using vSphere replication and SRM 5.1, and have run into issues during a test recovery where the snapshots created for the test consume too much available disk space. Do you know of a method for calculating the storage disk space requirements for the target datastores used by vSphere replication and SRM?

  2. Sunny Dua

    Rob, this would depend upon the length of time you are running the Test Recovery for. Remember, once you run a Test Recovery there are 2 Redo Logs which are generated per VMDK. One Redo Log is the replication delta which keeps on adding due to continuous replication as per the configured RPO. As you are aware that during a test recovery the replication keeps running and since the primary VMDK on which this replication redo log is committed is being used by the Test.

    The 2nd redo log is of the Test Recovery itself. As soon as the test is initiated SRM takes a snapshot of the original VMDK and any new data is now written on this snapshot disk. This snapshot disk is usually 16 MB in size and grows as per the data which you are adding while running the test recovery on the virtual machine.

    If your VM has multiple VMDKs then you would have 2 of such redo logs per VMDK which would keep growing till the time the test is running. The growth however cannot be assumed or calculated as it will be different in every environment.

    I would suggest that you look at 2 things to get some estimates, one would be the size of delta which is being replicated on every replication cycle for a VM and the amount of data being added during the test. I know this would be difficult, hence I would start with following the practice of keeping atleast 15% to 20% free space on the DR site data-stores. At the same time you might also want to reduce the Testing time if it runs into days. This will reduce the space requirement and alsi ensure that your RPO is not violated.

    Hope this helps!!

  3. Paul

    Hey Sunny,
    I have deployed the capacity planner into my environment and hand picked a few test VMs for review. The graphs appear as expected however there is no data input on the graphs. Should this be immediately populated or will I need to wait 4hrs minimum before any data will be recorded on the graphs??


Leave a Reply

Your email address will not be published. Required fields are marked *