VMware vCenter Server - Physical vs. Virtual

This post is coming straight out of discussions I had with a client about, "How a vCenter Server should be deployed?". Since vCenter manages a virtual infrastructure you can either install it on a physical x86 server or as a Virtual Machine.

vCenter is an important machine and I have written about the importance of Protecting the VMware vCenter Server in one of my articles - Providing Protection & High Availability to a VMware vCenter Server. I would recommend you read this in order to understand the importance of taking the decision of keeping your vCenter Physical or Virtual.

People often ask me this question not only for vCenter but for all the other applications which they want to Virtualize. My answer to them is usually this "PLEASE ASK THE APPLICATION VENDOR". The team and the organization who have developed the application know the best about the attributes of the application hence they should be able to tell you whether an application can be virtualized or not.

vCenter being a VMware application, let's see what VMware has to say about Virtualizing the vCenter Server. As per page number 2 on the following white paper, VMware says - "Users can run vCenter Server in a virtual machine or on a physical server. We recommend running vCenter inside a virtual machine."

Sweeeett.. I believe the recommendation is exactly inline with my thought process... If you cannot Virtualize your own application (the vCenter Server) which is CRITICAL for a Virtual Infrastructure, you cannot really ask the application owners to Virtualize their critical apps on the VMware vSphere platform... Hence this is a great point which IT today can take to their application owners and convince them to Virtualize whatever fits on a VMware virtual machine today (I guess everything with vSphere 5.1. Read What's New - 5.1 to know more...)

Great, apart from the story of "Eating your own Dogfood", let's look at some other reasons which would help us take this decision around virtualizing vCenter or NOT.....

Well the above points are just a snapshot of what I think and I believe these pointers give you good enough reasons to decide whether your vCenter should be Virtual or Physical. 

I remember someone asking me a question which was "What will happen if the Virtual Machine which is running the vCenter goes down due to an ESXi server failure??"

The answer is that VMware HA will still work since it does not require vCenter to be up and running.. So if you have a HA cluster, you can be sure that you will get back the control on your environment as soon as the vCenter Virtual Machine is up on any other host in the cluster with the help of HA. 

What will happen if your PHYSICAL vCenter Server goes down??? I will leave you with this thought for now... :-)

Yup, Virtual is Better for me....

Hope this helps you take a decision on what is best for your environment..... Do share your thoughts if any!!

Choosing the Platform for your Virtual Center. vCenter Server Appliance(vCSA-Linux) vs vCenter (Windows)!!

With the release of vSphere 5.0 in 2011, VMware just increased the options for its customers to chose between the traditional vCenter Server which was installed on a 64 bit Windows OS and the freshly baked, Linux Based - vCSA (vCenter Server Appliance).

Though the intention behind this does not look like going away from Microsoft dependency :-) for vCenter. I hear this a lot from a lot of people, however VMware's decision of a Linux based vCenter is more from a customer demand perspective. Customers who are not Windows Centric or in other words are Linux based shops would not want to install a Windows Based Application in there environment as this would increase the cost of acquiring Windows Licenses and most importantly a resource to manage this Windows server.

With this, let's quickly have a look at both the platforms and see which one is the best!!

I would say this is not a fight between which is a better platform, however the decision between selecting the platform depends upon what suits your environment the best.

I hope this will help you take a decision around which option is better suited for your environment.

I would recommend you go through my other articles about vCenter Server which would help you take important decisions around this application which provides you centralized controls and management of your VMware Virtual Infrastructure.

VMware vCenter Server - Physical vs. Virtual

Providing Protection & High Availability to a VMware vCenter Server

Share your thoughts, use the comment option to open  and discussion points.

Providing Protection & High Availability to a VMware vCenter Server..

vCenter being the heart of a virtual infrastructure can be considered as one of the most important piece of the puzzle. I have had numerous discussions with customers, colleagues and VMware partners about the importance of vCenter Availability and the options to protect the vCenter to improve the up-time and mitigate any risks around losing the control of your Virtual Infrastructure.

This article is to ensure that we document all the available scenarios and options and help others to take decisions around improving the availability of VMware vCenter. I am sure there would still be some scenarios out there which I might have missed, and would be happy to discuss them through the "Comments" section of this post.... So feel free to share your thoughts!!!

Alright let's begin.....

First of all lets start with a few basic questions to clear the fog around the role of VMware vCenter Server (I am doing this for the new kids on the block..)

What is vCenter Server?

Virtual Center provides a centralized and extensible platform for managing virtual infrastructure. VMware vCenter Server, formerly VMware VirtualCenter, manages VMware vSphere environments allowing IT administrators simple and automated control over the virtual environment to deliver infrastructure with confidence. More Details can be found here.

vCenter Should be Virtual or Physical?

Yes your vCenter is an application which can be installed on Virtual Machine as well.. Read my post on this topic - VMware vCenter Server - Physical vs. Virtual. This should tell you what is the best option for your environment.

vCenter Server (Windows Based) or vCenter Server Appliance a.k.a VCSA (Linux Based)?

For Linux lovers vCenter is not restricted to Windows anymore, you can also get a Linux based appliance from VMware. I have written a post about "Choosing the Platform for your Virtual Center. vCenter Server Appliance(vCSA-Linux) vs vCenter (Windows)"!! I would recommend you read this to understand which is a better option for your environment.


Whether its Physical or Virtual, Linux Based Appliance or Windows Based, it is important that we protect the virtual center so that we do not lose control of the ESXi servers and the virtual machines which run the business applications. Let us quickly look at the options to protect both vCenter Server (Windows Based) & vCenter Server Appliance a.k.a VCSA (Linux Based)...

Great, so now we have the methods available in the table... Lets dissect them one at a time to see what each option has to offer.

Option 1 - Use VMware vSphere HA  - If your vCenter is a Virtual Machine you can place the vCenter Virtual Machine in the VMware HA cluster. HA will protect the vCenter Virtual machine just like any other virtual machine. If the ESXi server which is running the vCenter VM goes down, HA will kick-in and power on this VM from the shared storage, on another HA cluster member host. The only downtime in this case would be the time taken to reboot the vCenter VM. Pretty cool, right!! I appreciate this from VMware...

Option 2 - Cold/Standby vCenter - This is a poor man's HA and I have seen customer's use this configuration, especially the one who have the vCenter as a physical server and cannot use vSphere HA. The  architecture of this deployment, needs you to have a remote database for vCenter application. You have 2 servers with same version of vCenter application installed. In case the first one goes down, you power on the other server which connects to the same database and hence pulls up all the configuration. This method surely works but needs human intervention. Hence if you vCenter goes down in the middle of the night when your backups are happening using VADP, your backups would fail and you would not be able to fix this unless you come back in the morning and see the damage......


Option 3 - Using vCenter Heartbeat - vCenter Heartbeat is a high availability solution for vCenter Server which protects the vCenter against OS, Application, Database(SQL), Configuration, Networking or Hardware failures. Yup it also protects the SQL database and can be installed across sites as well (remote location). The beauty is that if you have a Heartbeat license, you would only need one vCenter license for both Primary and Failover site. You should be able to get more information about Heartbeat on the following link.

The reason I have highlighted this option in the above table is due to a reason. Heartbeat comes with a cost and I would highly recommend this option for environments where vCenter up-time is critical. Environments with VMware View, VMware vCloud Director or wherever vCenter APIs are used, the availability of vCenter Server defines the availability of these services. Hence if these services are important vCenter should be given protection using vCenter Heartbeat.

Option 4 - Third party Solutions to Protect vCenter Server - There are a number of options available to name some, configure MSCS for vCenter windows based server, Neverfail etc. can help you protect vCenter Server.

Since, vCenter needs a minimum of 2 vCPU's we cannot use VMware FT to protect this virtual machine. However, I am sure VMware would look at supporting VMware FT with SMP (symmetric multi-processing), which would give another option to customers to protect vCenter Server and ensure they have full control and manageability for their VMware Virtual Environments.

Feel free to share your thoughts around this topic and I hope this helps you design your vCenter with the best suited options for your VMware environments.

Changing Swap file Location of VMware vSphere Virtual Machines

While working on a SRM project for a customer, I came across a situation where the customer wanted to minimize the amount of data which we need to replicate at the storage layer for the virtual machines to be available at the DR Site. We are using Storage Array based replication and not vSphere Replication in this case.

The best bet is to ignore the files which are not required to be a part of the DR VM. In a virtual machine a file which you can readily ignore is a .vswap file as this is a resultant file which is used by Virtual machines for swapping memory pages. To read more about virtual machine swap file, refer to this post by Frank Denneman. This would give you a good insight about Virtual machine Swapfiles.

Lets quickly look at what we need to do and consider to perform the relocation of the Swapfiles to a shared datastore (You can keep it on a local datastore as well, however this will increase the time taken to vMotion a Virtual Machine from one host to another since a full copy of the swap file would happen, the post above by Frank explains the same.

Changing the location of Virtual Machine SWAP file to a Shared Datastore

Note:- To change the location of the SWAP files of all the virtual machines in the virtual infrastructure follow the steps below:-

      1-     Connect directly to your host or to your vCenter Server using the VMware Infrastructure/vSphere Client.

      2-     Configure the setting on the Cluster level first by Right Clicking on the cluster in question and click on Edit      Settings, select the Swapfile Location and select the option “Store Swapfile in the datastore specified by host”.

(screenshots courtesy - SOS Tech - Wordpress)

The next step would be to set it up on each and every host in the cluster

      3-     Click the Configuration tab for the ESX host.

4-     Click Virtual Machine Swapfile Location and click Edit.

(screenshots courtesy - SOS Tech - Wordpress)

      5-     Specify the datastore where you want to store the virtual machine swap files.

      6-     After restarting your virtual machines, ensure the swap file is located on the specified host datastore.

      7-     An important point to note is that you would have to redo this setting on a host every time the HOST   is removed from the cluster or else the Swapfile location will default to with “Virtual Machine Files”.

Please ensure that we size this datastore appropriately for performance and Space. The space should be greater than or equal to the total vRAM assigned to the all the Virtual Machines in the Environment. Please ensure you size for future growth as well.

The performance of this datastore is important as the SWAP files help a VM swap out memory pages when the host is memory constrained, hence this datastore should be backed up by disks which have good performance characteristics. With vSphere 5.1 you can actually select the datastore for storing the swapfiles as a SSD based location which will improve the performance drastically.

You can also configure only specific virtual machines for redirecting there SWAP files, however this would incur management overhead. If you need to do this, you can follow the steps below (Reference VMware KB article 1004082)

To change the swap file location for a single virtual machine:

1. Power off the virtual machine.
2. Unregister the virtual machine. Right-click the virtual machine in the Inventory and choose Remove from Inventory.
3. Connect to the host:
• For ESX, use an SSH client. For more information, see Connecting to an ESX host using a SSH client (1019852).
• For ESXi, use Tech Support Mode. For more information, Tech Support Mode for Emergency Support (1003677) or Using Tech Support Mode in ESXi 4.1 and ESXi 5.0 (1017910). 
4. Change directory to the folder where the virtual machine resides:
   
   cd /vmfs/volumes/datastore_name/virtual_machine_folder/ 
5. Edit the virtual machines configuration file with a text editor.
6. Add this line:
   
   sched.swap.dir = /vmfs/volumes/datastore/ 
7. Register the virtual machine again. For more information, see Registering or adding a virtual machine to the inventory (1006160).

Hope this helps people who have to take similar decisions for their Virtual Environments.

*********************************************************************************

Update to the article (20th Sept. 2012)

*********************************************************************************

Happy to share that this article got a lot of traction in the last 4 days and there were a number of discussions which happened over the web, however unfortunately, those discussions were not updated here automatically. I wish there was a feature to do that... 

So for the benefit of all... I am updating the discussions in a question and answer format..

FAQ's

Ques: How does this affect performance of the VMs if the swap is on another datastore? We are re-architecting the vm environment.

Ans: The Performance of the VM's would be affected if you locate them on a storage LUN which could be under-performing due to the characteristics of the LUN. For ex- if the LUN is carved out of slow SATA disks. 

Just relocating the swap files to a different LUN does not result in performance issues. 
Another issue could be a slowness in the process of vMotion if the swap files are not located on a share storage (instead the are on a local storage.) 


Ques: From a architecture view, if we have all the swap space setup on a single lun for the production environment, would we need a corresponding same size lun setup for the dr site? Or would it be better just to have the vm take care of the swap at the dr site? 

Ans: I would not suggest you to dedicate a lun for Swap files in DR site, because this storage space would be kept idle for most of its life. Storage being expensive you might not want to keep it idle. Instead, let the VM's boot with the swap file with the virtual machine file. 

However, if you ever get into a failover situation and run VM's from the DR site, at the time of failback the Swap files would be replicated back to the Primary site, creating a similar situation which you have in hand today. Still the cost to replicate this during Failback might be much less as compared to idle storage space of this capacity. 

Chose what suits your environment the best. 

Ques: After reading your blogpost, need your inputs 

- As you might be aware storage vmotion creates a temp second vswp file on the source, so how did you size the .vswp datastore to incorporate storage vmotion functionality 

- In the scenario you shared how did you addressed a memory overhead vswp file "VMX swap file" created with each VM post ESXi 5.0 

- If I assume business critical VM's part of your SRM scenario do not undergo frequent power cycles and the solution architect correctly for configured and memory reservation the .vswp file will be static with no changes to storage blocks post first full copy would you still recommend a dedicated .vswp datastore

Ans 1 (By Samir Roshan of - http://thinkingloudoncloud.com/)

: By default now you have two vswp files in a VM directory one is old good friend swap file and the new VMX swap file. More details here http://pubs.vmware.com/vsphere-50/index.jsp?topic=/com.vmware.vsphere.resmgmt.doc_50/GUID-51767DC5-9A03-4B41-A385-9A11F6BD36F1.html

There are also chances of the .vswp storage block changes as the .vswp file is not a static file although it may seem so (due to it's size calculation on the datastore) but remember this is used for swapping and it is not guaranteed that the same memory pages are swapped all the time.

Now the SRM and swap file connection, in SRM your VM is going to have a reboot any way in the DR site in that case the vswp file is an additional load that you have to carry even for the initial copy. As we know the .vswp file gets created when the VM is powered on and it gets deleted when the VM is powered off.

So in SRM it's good to have the .vswp files stored in some other datastore than the one participating in the Protection group.

Local swap files with SSD is a good design consideration which can give better performance if there is swapping.

Ans 2: To start with I would not setup dedicated datastore for virtual machines unless I have to implement SRM in the environment, as this adds some complexity in the environment. 

As we all know that when we look at Interoperability with Storage vMotion and Storage DRS 

"Due to some specific and limited cases where recoverability can be compromised during storage movement, Site Recovery Manager 5.0.1 is not supported for use with Storage vMotion (SVmotion) and is not supported for use with the Storage Distributed Resource Scheduler (SDRS) including the use of datastore clusters. If you use SVMotion to move a protected virtual machine from a datastore that is in a protection group to a datastore that is not protected, you must manually reconfigure the protection of that virtual machine." 

The above extract from the SRM Release notes clearly shows that its not a great idea to use storage vmotion for vm's which are protected by SRM, since it would result in a reconfiguration of protection group, or a resync of entire data in case of vSphere Replication... 

To your second point, in case you need to do a storage vMotion, you would have to have extra space on the data store as the storage vMotion would create a new swapfile for the period of storage vmoition... Since you would not perform a storage vmotion on all the vm's at the same time, a 20% head room on the Swapfile LUN should be enough to help any environment.... 

To your third point, I agree that your super critical machines would not Swap out as much, however the files will be created... So if you have around 50 machines which you are protecting with 4 GB of swap each, you have to replicate around 200GB of the data which is of no use.... Companies can burst out bandwidth to do so, however it comes with a cost..... 

Ques: Very helpful note. BTW i have this suggestion if you want to keep the Swap file locally(its just idea only i have never tested it, so pleas feel free to feed back) 

Why not we plan future esx hosts with at lease 64GB SSD for Swaps. As i think this this solves 2 issues 
1. improve performance of VM due to swap out. 
2. improves vmotion if the swap is on local DS. 

I understand this is not for all environments but can used for most of them and its justifiable from the cost factor also. 

Ans: The suggestion is great and I completely agree with you on this... SSD is the way to go for local swapfiles... Infact it is a Performance Best Practice by VMware. Refer to following link for more

http://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.0.pdf

*********************************************************************************

Update to the article (22nd Sept. 2012)

*********************************************************************************

Alright, this discussion is heating up and we have got some great comments adding a couple from @amitchell01

Placing swap on SSD won't help vMotion performance - in fact it will hurt it as we now need to 

copy the swap file from one host to another in order to move the VM. If vMotion performance is 

a concern keep the swap on shared storage so it doesn't have to be moved when the VM is 

migrated. 

Ideally and if your VMs and hosts are sized appropriately, swap thrashing shouldn't be a 

problem so the placement of the swap file should have a negligible effect on performance 

anyway. 

What I generally do if dealing with replicated storage is place the swap on a shared datastore that is not replicated. 

You can definitely do that but keep in mind that you will get no performance gains other than faster reboots of the ESXi host. Once ESXi is loaded it runs from memory so having a faster boot device provides no benefits.

Oracle Licensing & Support in VMware vSphere Environments

I believe this is one of the most controversial and confusing topic when it comes to licensing of Oracle Applications/Databases on a Virtual Machine running on VMware vSphere platform. 

During discussions with my colleagues and customers, we debated on some excellent points on this topic. I thought it would be worth blogging about this to spread the correct information out to the decision makers who want to realize the full potential of their vSphere farms by Virtualizing Business Critical Apps such as Oracle Databases, E-business suite etc.

Let's look at the options which we have one at a time..

-------------------------------------------------------------------------------------------------------------------------------------------------------------


How Oracle Licenses its databases?

Oracle like most of the Vendors licenses their databases by 3 ways:-

Method A - Per CPU(Core)
Method B - Enterprise Licensing (All you can eat)
Method C - By Named users

Now, the customers who would worry about Virtualizing Oracle on vSphere would would mostly be using Method A, i.e. to license each and every CPU Socket/Core of the ESXi Server on which the Virtual Machine running the Oracle Application would live. There is a processor core factor depending on the type of CPU and can be 0.25, 0.5, 0.75 or 1.0. This means that you would either have to buy 0.25 , 0.5, 0.75 or 1 license for each CPU, and this entirely depends on the CPU Type (Intel, AMD) and the number of cores.

I would recommend reading and understanding more about Oracle Licensing on the following link - http://www.oracle.com/us/products/database/product-editions-066501.html

-------------------------------------------------------------------------------------------------------------------------------------------------------------

Lets do a quick math with an example for ease of understanding.

Situation - I want to run 6 Servers which need 2 CPU with 2 Cores each, hence I need a total of 12 CPU's with 24 Cores. How would I license this in a Physical World and then Virtual World??
-------------------------------------------------------------------------------------------------------------------------------------------------------------
For Physical World - Total Number of Oracle Licenses required = No. of CPU's * 0.5 (0.5 being the CPU Factor) 
                                                                               = 12 *0.5 
                                                                               = 6 Licenses

Hence if you want to run these servers you would have to pay Oracle for 6 licenses.

-------------------------------------------------------------------------------------------------------------------------------------------------------------
For Virtual World - Now, if you want to Virtualize these Servers, lets see what you need to do. To run these 6 servers as Virtual Machines, you can do with a Single ESXi server with 4 CPU and 6 Cores each. Lets see how many licenses you need

Total Number of Oracle Licenses required = No. of CPU's * 0.75 (0.75 being the CPU Factor, increased since the number of cores/CPU increased) 
                                                                 = 4*0.75 
                                                                 = 3 Licenses

Yup, you actually saved 50% of the cost by Virtualizing these servers just on the license. Lets say you want to give High Availability to these Physical Servers ( in The Physical World ). In that case you would have to buy 2 times the licenses, i.e 6 *2 = 12 licenses (You might have to buy additional licenses for clustering solutions / OS etc).

However, if you give the vSphere host another ESXi server for VMware HA then you would have to obtain just 3 more licenses making it a total of 6 licenses, plus the ESXi License per CPU. (VMware HA would be a part of the vSphere License, hence no extra cost).
-------------------------------------------------------------------------------------------------------------------------------------------------------------

Now, you would think that what is the stopping the customers from Virtualizing their Oracle Databases on VMware vSphere when they can actually save this much money?

The answer is a 3 letter word "FUD" - Fear, Uncertainty & Doubt. There are more and enough myths around Virtualizing Oracle on VMware vSphere Platform and we will look into each one of them and demystify them...

Alright, lets get the ball rolling.........

-------------------------------------------------------------------------------------------------------------------------------------------------------------

MYTH  - I have to license for all the ESXi hosts in the cluster where my Virtual Machine running oracle application/database is running. Hence if you have 6 vm's running oracle running on a 10 host ESXi cluster, you would have to license the CPU's on all the 10 Hosts, irrespective of the fact that my VM just lives on the first 2 hosts.

FACT  - It is true that you would have to license each CPU on which your oracle Virtual Machine might live even momentarily. In a vSphere Cluster, the virtual machines are free to move from one host to another using DRS & vMotion, and vCenter logs keep a track of what all hosts the machine was running on. In such a situation you would have to license all the hosts for Oracle and it is not a Myth.

The Myth is that you cannot use features such as DRS Affinity which can restrict all the Oracle virtual machines to run on specific ESXi hosts in a cluster. Hence license only those hosts which are required for all the Oracle Virtual Machines to run. At the end of the day what ORACLE checks is the vCenter Logs and if the logs say that the oracle virtual machines were only running on 2 hosts and those hosts are already licensed you are good to go. Hence we should use the features given by VMware on the vSphere Platform to achieve this and benefit out of Virtualization of oracle databases and application.

If you think that managing this is not your cup of tea and you want a simpler method, use the popular concept of ORACLE Islands. Instead of mixing your oracle virtual machines with other workloads, just go ahead and create a separate cluster of 2, 3 or as many hosts you want to run just Oracle Workloads and license only those hosts. As simple as it gets....

Now lets look at the Second Myth!!!

-------------------------------------------------------------------------------------------------------------------------------------------------------------

MYTH  - Oracle Applications and Databases running on VMware vSphere Virtual Machines are NOT SUPPORTED by oracle support.

FACT - This myth scares the customers the most and hence is used mostly by the Field Sales to ensure that the customer looks at alternative hypervisor choices.This helps them to scare away customers from using VMware vSphere which is the most advance and mature hypervisor if you compare it with any of the Claiming Competitors.

Now lets look at the reality. Oracle has a Support Statement which says that :-

"Oracle has not certified any of its products on VMware virtualized environments" (Quoted from - Oracle official support statement, note 249212.1 on My Oracle Support)

The above statement does not even carry the word "Support",  hence as a customer or a consultant, I would re-visit what the words of the sales guy and get the appropriate information. 

The support statement clearly states that Oracle does support VMware platform but does not certify it. This certification program of Oracle certifies hardware which run Oracle Applications and not hypervisor, hence it is not certified. 

However, it is supported by default and only in case of an unknown issue, you are asked to re-pro the issue on a physical environment. The reason  they ask you to do that is because they cannot do any testing internally as Oracle Engineering is forced to use Oracle VM and cannot deploy vSphere in their labs [which is understandable :-) ]

To take care of such a situation, VMware has taken a great initiative to help its customers to get support on Oracle issues from a specialized set of Oracle Support Engineers working out of VMware GSS. Understand VMware's own Oracle Support policy : Reference VMware's Global Support Services (GSS) support site and statement. Read Support Policy. This support is a part of the normal vSphere SnS and does not cost you extra. Seems, VMware has a point to prove. 

-------------------------------------------------------------------------------------------------------------------------------------------------------------

To top it all VMware runs all its Oracle Applications and Databases on vSphere Platform and guess what, they get support from Oracle whenever needed . I guess this would be a biggest case study for any customer who is considering Virtualizing Oracle on Vmware.

Well, enough of blowing the VMware Trumpet on Oracle support and licensing. Lets listen to what Oracle has to say on this.

I got my hands on an interview which was done at VMworld 2012 where the Oracle spokesperson was Richard Garsthagen, Director for Cloud Business Development, Oracle EMEA. Richard himself demystified the MYTHS around this subject. Lets listen to what he has to say on this.

 

-------------------------------------------------------------------------------------------------------------------------------------------------------------

I would also take this opportunity to share some of the other great resources on this topic which might help you take the right decision for your business. Here are a few links:-

Understanding Oracle Certification, Support and Licensing for VMware Environments on vmware.com

Virtualizing Business Critical Oracle Systems - by Michael Webster 

A great Oracle Blog called the Oracle Storage guy - http://oraclestorageguy.typepad.com/oraclestorageguy/

-------------------------------------------------------------------------------------------------------------------------------------------------------------

Do share your comments if you have any and I would be happy to discuss.

- Sunny Dua

Using vSphere Replication with VMware Site Recovery Manager !!

Today was the SRM day at office, so I thought lets get all the discussions together and put them in an article which would help others as well. I will do it in a question and answer format to make it easier for the audiences of this article...

Note: - This is primarily focused on how VMware Site Recovery Manager along with vSphere Replication helps customers create a BCP/DR solution for them with some amazing and easy features available in this product from VMware.

----------------------------------------------------------------------------------------------------------------------------------

Question - Will SRM 5 work with different hardware at the DC and DR site? As I understand, in case of failover with SRM VMs cold-boot. So there shouldn’t be a hardware compatibility issue.

Answer - You can have different models of x86 server hardware on 2 sites as the Virtualization layer of vSphere would make it seamless for the virtual machines to boot up on the DR Site and then failback as well.


The identical hardware comes into question when you are implementing Storage Array based replication for SRM to use. In this case, your storage arrays should be identical for the replication technology to successfully replicate Luns from Protected to Recovery Site and back.

However, if you are using vSphere Replication, you would not have to worry about that as SRM then uses the host based replication instead of Storage array based replication.

----------------------------------------------------------------------------------------------------------------------------------

Question - If total replication data size is around 20 TB how can we achieve this using host based replication? It is huge data.

Answer - That’s a great questions and probably a challenge which any organization would face, whether they use, Host based replication or vSphere Replication. Now if you are using vSphere replication, there are 2 ways to solve this issue:-

      a)    Use the Full Replication option, which literally means that you start the replication on each VM and then let it finish before you could start creating and configuring your recovery plans on the SRM interface. So for a total of 20 TB of data it could take days (depending on the available bandwidth, distance and latency) before this would complete. I do not recommend this method to customers who are using vSphere Replication as they have an easier way of making these images available on the Recovery (DR) Site.

      b)    Let’s talk about the easier way now. Instead of replicating the entire data over the wire, we can use Physical Couriering method which would save time and bandwidth for the customers. It is as simple as taking a backup / clone of the Virtual Machines which need to be protected on the Protected Site, dump this copy on a USB Drive / Tape or multiple drives/Tapes in your case. Create a MD5 Checksum on these images to ensure consistency(optional step) and ship them across to the Recovery Site. Now, you can seed these images on the target LUNS. Once you are done with this process, configure replication on the Protected Site and point to the seeds as vSphere replication gives you that option during configuration and you are done. Now vSphere Replication will run its magic and just replicate the Delta changes to the Protected site which would be a minimal amount of data as compared to what you would do in the first approach.

----------------------------------------------------------------------------------------------------------------------------------

      Question - Suppose we replicate 10 VMs to the DR site and 5 go down at DC, in this case do we have to manually make DR VMs up or it does that automatically?

    Answer -The SRM solution primarily looks at providing you a framework to design your BCP/DR environment, hence you would use it in a case where you see either a Disaster coming or a disaster which has already destroyed your primary site(Protected Site). This will allow you to either do a planned migration (if you know that disaster is coming) or a site failover (if the damage is already done). Hence, it is not a VM level recovery solution, but a Site Level recovery solution. However, in your case, you can create 2 recovery plans with 5 VM’s each and execute only one recovery plan instead of failing over the entire site. So you can actually have a recovery plan for each VM and execute the one which you want to recover on the DR site in case of a disaster. However, I would revisit my statement here and recommend that we should first look at high availability solutions such as VMware HA, FT or third party clustering solutions for recovering from VM failures. If it is impossible to recover VM’s at a site then we should look at SRM as a Site failure solution.

----------------------------------------------------------------------------------------------------------------------------------

     Question - Suppose customer has  a VM in which we do some configuration like configuring IP of DB server so that it can be in sync with DB server. Now if that VM goes down then at DR it will come up and will try to contact the DB server which is in DC. So in that case how can we utilize SRM feature effectively.

      Answer - SRM gives you the automation to recover virtual machines at the Recovery Site, however it is important that you provide all the components which are required for the applications running on those virtual machines. Taking the database example, you should either have the database available with the same IP address on the DR site or if the database has a different IP address then you can either script the changes using VB Script to change that setting in the ODBC connection after the VM powers on or you can do it manually. If you script it, then SRM Recovery Plan workflow can accommodate that script for you and execute it. For the IP address of the virtual machines, we can use Guest IP customization and that would do the IP changes on the fly using API’s on Windows. You can use Bulk IP customization if you want to change IP’s on a number of virtual machines at one go and this can all be configured while setting up SRM for the first time. Regarding the DB, you can either Virtualize it so that SRM can replicate it and make it available at the recovery site or you can use DB replication technologies to have the database available at the recovery site. 

----------------------------------------------------------------------------------------------------------------------------------

These features really differentiates vSphere Replication from other host based replication technologies and helps the customers implement DR which they were unable to do before.

Alright, I know that might open the "Can of Worms" and make you ask more questions, if that's the case, feel free to use the comment field and we can have some more discussions around this topic.

In addition to this, I would highly recommend the following links from VMware Technical Marketing teams who have done a great job to deep dive into the vSphere Replication technology and discussed "Behind the Scenes" of this feature :-

Advanced vSphere Replication Options for Single VM Replication Performance - by Ken Werneburg

How to Track Replication for Bandwidth Estimation?

Hosting.com shares data on bandwidth, sync times, and RPOs with vSphere Replication