Throttle vSphere Replication with Network I/O Control

 Disaster Recovery, Network, Storage, Tips and Tricks  1 Response »
Dec 092011
 

vSphere Replication and Site Recovery Manager make it very easy to replicate your VMs to your DR site (ahem, once they are set up).  Some customers asked me if there is any way to throttle the bandwidth used for replication.  The good news is that there is a way in vMware software but it cannot be found in SRM.  Unfortunately, it can only be found in the Enterprise Plus Edition of vSphere 5.  It’s Network I/O Control in the Distributed vSwitch (DvS) in v5.  I’m not going to go into a deep dive on Network I/O Control but I will recommend that you read the Network I/O Control best practices doc here.

To enable Network I/O Control we need to have a DvS in place.  If we select the distributed switch and then select the Resource Application tab on the right, this gives us the “properties” option on the far right.  By selecting the Properties option, you can enable Network I/O Control on the DvS.  Once enabled you can see all of the System network resource pools.  There is one at the bottom of the list labeled “vSphere Replication (VR) Traffic”.  Selecting it and then clicking the “Edit Settings” link just below it opens up the settings window.

From here, you can edit the adapter shares.  The shares are to balance the bandwidth so that network flows can use the bandwidth thats available from a given dvuplink.  The shares are for a given dvUplink.

Alternatively, you can uncheck the Unlimited checkbox and set a host limit.  Keep in mind that this is Megabits per sec, not MegaBytes.  This is also the limit of the combined set of dvUplinks on a given host.

Lastly, a QOS priority tag can be used.  The traffic will have a 802.1p tag applied to it.  The IEEE does not standardize or mandate the use of the priority tag applied to the packets but the switches should treat higher tags with higher priority.  The choices are None, 1-7.

While not the granular controls that we may wish for, say individual bandwidth controls on a per VM or per-site replication limits, these settings and options are a start.  Hopefully in the future in vSphere Replication v2 we will have more granular controls for bandwidth throttling but until then, these are what we can use.  Happy computing.

 

SRM Per-VM licensing coming September 1

 Disaster Recovery, VMware News  Comments Off
Jul 202010
 

You may remember from a recent article that I wrote about the VMware licensing dilemmas, that one of the scenarios I mentioned was SRM licensing when a customer wants to protect only a small percentage of VMs.  In the per-CPU licensing model, a customer would have to license all of the CPUs in a cluster even if they wanted to protect only 10% of the VMs.  VMware has announced that Per-VM licensing will be available on September 1, 2010.  Customers will now be able to license SRM on a Per-VM basis.  Customers who like their per-CPU model will be able to continue that purchasing method until December 15, 2010.  After that, it’s per-VM only.

There are a few things to think about with regard to licensing  first, vSphere 4.1 now allows for DRS affinity so that VMs only move between certain hosts of a cluster.  I’m still waiting for a definite answer from my VMware friends but that should allow you to protect some VM’s and set their DRS Affinity to only the hosts that you own SRM CPUs for and still keep the full cluster for the unprotected VMs. Previously, VMware would recommend that you create a separate cluster for your “protected” VMs if they were a small subset of the whole.  Now with DRS Affinity, you can dictate that certain “protected” VMs only move between a subset of a cluster.  We’ll still have to wait and see the final ruling from VMware but I’m thinking that would work in the short-term for those in the per-CPU dilemma.

The second feature of the new licensing that I really like is the rolling average of VMs over the last twelve months.  What that translates to is that now I need to buy what my daily average of VMs protected would be over a 12 month period.  If I have certain points of the year where my VM count spikes, this average would be monitored by vCenter and alarm if I am going over my licensing limits.  However, I would only need the average number of protected VMs over the past year.  The system will continue to run after going over your limit but that’s definitely not something I would condone (Famous VMware SE saying: ethics don’t ship in the box people).

The per-vm licenses are sold in blocks of 25 and range from $1,250 to $11,250 depending on the product.  Per-vm licensing will be available for Chargeback, Appspeed, SRM, and, later this year, CapacityIQ.  You can find more information on VMware’s website here.

The last question I had was, “How do I know what my rolling average is for those licenses?”  The good news is that once you enter in a license key, the new license reporting manager in vSphere 4.1 will tell you what your rolling average is year-to-date.  Looks like someone was planning ahead.

Site Recovery Manager by example

 Disaster Recovery  Comments Off
Nov 092008
 

One of my favorite things in talking to people is when they tell me how well the software I teach them about works.  Even better is when someone will take the time to blog about their experiences.  I have had a few customers become early adopters of Site Recovery Manager.  One of the most memorable was a customer (let’s call him Virtual_JTW) whom I worked with in September.  On a Friday afternoon we ran thru configuring and setting up SRM in his environment.  We worked thru the configuration and integration with his Celerra storage.  In the end, we passed with flying colors and his Disaster Recovery test was 100% successful.  It was fun and exciting for me to watch Virtual_JTW’s reaction to the success of the test.  He felt so impressed by the results and his subsequent demonstration for his Disaster Recovery team, he felt the need to blog on the whole experience.  You can read his account of what happened as well as the test results here .