VM /ETC

Posts Tagged ‘replication’

Because of the prevalence of virtual infrastructure these days, I’ll make the argument that virtual machine (VM) replication, both for business continuity (BC) and disaster recovery (DR) purposes, is the new P2V (physical to virtual migration) project. Not in the literal migration of physical to virtual, but in the same P2V concepts of infrastructure consolidation and capacity planning. I’m also talking similarity of process and in the frequency in which it is occurring. Simply put, IT shops that performed P2V migrations several years ago are now exploring how they can accomplish their DR site fail over or their BC needs with their virtual machines.

Let’s call these new generation of projects V4DR (virtualization for disaster recovery) or V4BC (virtualization for business continuity).

The comparison

If I rewind 3 to 5 years ago in my career, capacity planning for server consolidation was a weekly project and topic of discussion. Customers were either in the process of converting physical servers to virtual machines or they were exploring the possibility to do so. In both cases, capacity planning scenario spreadsheets and reports were frequent “ground zero documents” to almost every project plan I was involved in.

Just like P2V projects, VM replication today also requires some of the same considerations for job scalability and times to complete – i.e. using multiple hosts as targets and making sure the network can support getting the job done as quick as possible. Not to mention ip addressing, VLAN assignments, and application connectivity after the fact. Thank goodness we no longer have to deal with hardware drivers and other unneeded software a second time. Hopefully, VM alignment is a thing of the past too!

I’m not seeing the same “ground zero documents” for replication projects, however.

Use the same capacity planning tools?

So, I’ll ask the question:  Read the rest of this entry »

Figuring out whether you can replicate your VMs across your WAN to a DR site is never easy. There are many factors to consider, but luckily, one of my Veeam peers and a fellow VMware vExpert, Ricky El -Qasem has created a Replication Calculator to help figure it out.

From the post on the Virtualize Planet Blog: Replication Bandwidth Calculator | Virtualize Planet

ReplicaCalc

How many times do you get asked “how do I work out if VM Replication will work with my internet link” Well I wanted to demonstrate some way of providing a calculator without working it out in my head every time. So I made a Replication Calculation tool.  It is assumed that you provide it with 3 values:

1. Average Rate of Change.
2. The Link speed – this value should reflect the upload speed at the source site or the download speed at the target if this is less. So for example if the upload at the source is 6Mbs and 10Mbs download at the target then go for 6Mbs
3. Bandwidth % – which is the amount of bandwidth as % which achievable from the link speed specified.

Download and install ReplicaCalc from here > ReplicaCalc

Ricky describes the needed values in more detail in his post so be sure to read it all there. He also demonstrates how to use Veeam Backup and Replication to get the VM dynamic rate of change. The tool is useful whether using Veeam to replicate your VMs or not, however.

Thanks Ricky!

For more on this topic, I’ve blogged about using a bandwidth calculator to figure out whether your current WAN link is adequate or not for your replication jobs before.

If you are looking at various options to automate virtual machine (VM) ip address reconfiguration when failing over virtual machines to a disaster recovery (DR) site, this post explains an option so simple it is beautiful. To give full credit, the Vizioncore vReplicator 2.5 Best Practices document enlightened me to the strategy of using a local only VMware vSwitch and an extra virtual NIC (vNIC) in each VM. It’s been a long time since I had a “ton of bricks” moment, but this concept crashed down on me with the realization of a configuration that works in any version of ESX, doesn’t require extra software or hardware, and better yet, doesn’t have to be scripted! Just configure some extra virtual networking and forget about it!

Here is a general outline for automating the DR ip addressing with this method:

At the Primary Site

• For these instructions assume the production vSwitch at the primary site has a Portgroup named VM Network
• Build a new vSwitch and do not attach any physical NICs (local only isolated switch). Create a Portgroup named DR Network
• For each VM you need to fail over to a DR site, add an extra vNIC and attach it to the DR Network Portgroup

At the DR Site

• Create your DR site production vSwitch, attach physical NICs and add a Portgroup named DR Network.
• Create another vSwitch and do not attach any physical NICs (local only isolated switch). Create a Portgroup named VM Network

All you have to do for this to work is

Read the rest of this entry »

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. Read the rest of this entry »

VMware announced officially today that Site Recovery Manager will be available for order next week and then generally available within 30 days. As I mentioned in my Site Recovery Manager Overview post last week, a requirement to using SRM will be a Site Recovery Agent (SRA) from the various storage vendors. VMware’s announcement reveals what vendors will provide SRAs initially:

“VMware Site Recovery Manager leverages customers’ investment in storage replication software from VMware’s leading storage partners including 3PAR, Dell, EMC, FalconStor, Hitachi Data Systems, HP, IBM, LeftHand Networks and NetApp. VMware is working with partners across its storage partner ecosystem to ensure that customers can use Site Recovery Manager with their storage system and software platform of choice.”

As expected, several reports surfaced on the Internet today Read the rest of this entry »

One of the hands on labs I attended at VMware Partner Exchange was the Site Recovery Manager (SRM) lab. In the lab I was able to get a good understanding of the technical details of how the yet to be released product is configured. The lab then walked us through the fail over process and workflow. This post is a high level summary of what I learned. This post is not intended to be a detailed how to, but instead just a logical overview about what it will take to set up SRM.
Read the rest of this entry »

When planning P2V migrations there is always a handful of servers that have huge disk requirements. A network file share could be as large as several terabytes. User Home Directories can also cause large, cumbersome servers that present unique challenges when migrating to virtual infrastructure. Given that VMware VI3 has a 2 TB VMFS volume limitation as well as a 2 TB .vmdk limitation, there is a better option. Consolidate your shares to a Read the rest of this entry »