VM /ETC

Posts Tagged ‘fail over’

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 »

VMware has announced an upgrade release of Site Recovery Manager (SRM).  Available today, SRM version 4 not only adds the much anticipated compatibility for vSphere 4 but also provides support for NFS storage, allows multi instance replication between single site pairs, and can be managed in vCenter Linked Mode. More details on the new version follow in the paragraphs below.

VMware customers who currently own SRM with active Sales and Support (SnS) contracts will receive the upgrade at no additional cost. VMware has not changed the per processor licensing model or cost for new customers wishing to purchase.

Some quick links for SRM 4:

• SRM 4. Release notes – http://www.vmware.com/support/srm/srm_releasenotes_4_0.html
• Upgrade KB article – http://kb.vmware.com/kb/1013166
• SRM download – http://downloads.vmware.com/d/ and select Site Recovery Manger
• Michael White’s post SRM 4.0 is here! The wait for vSphere and NFS support is over! on the VMware Uptime Blog covers upgrade strategy options.
• VMware’s documentation for all version of SRM – http://www.vmware.com/support/pubs/srm_pubs.html

vSphere 4.0 Supported

The main requirement to enable the new compatibility and features in SRM is upgrading vCenter to version 4. In fact, Read the rest of this entry »

I attended this VMworld 2008 session on Wednesday 09.18 at 9:00 AM. The presenter was Sunder Parameswaran who is a Senior Product Manager at Symantec. The session was about using Veritas Cluster Server (VCS) in VMware virtual infrastructure (VI) to overcome application high availability and disaster recovery (DR) challenges.

My main interest in this session was on the topic of Geo Clustering with VCS. Also known as Metro Clustering, this is the ability to have one node of the cluster at your primary data center location and the second node at a separate physical location like a disaster recovery site.

Sunder began by outlining various VI challenges.

Read the rest of this entry »

Chad Sakac has a great post on his Virtual Geek blog titled The Case For And Against Stretched ESX Clusters. In this post Chad discusses the possibilities of configuring ESX Clusters between 2 different physical data centers. That is, spanning the SAN across a wide area network so that VMs can be vmotioned between sites. The concept is a frequently discussed desire of many administrators, and Chad brings to light some great points for and against this design with specific configuration details about making it work with VMware ESX.

For example, the post explores several options: 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 »

How do you design resource pools in an ESX Cluster? There are two strategies that are the most popular in my experience. The first strategy creates resource pools based on CPU and Memory shares for host resource conflict management, and the second strategy uses reservations and limits to guarantee physical resources and ensure VM containment. This post will use a 3 ESX host example to explain both strategies. Please feel free to comment on the pros and cons of each or why you think one is better than the other.

In the example scenario three ESX hosts each have 16 GB RAM and 2 dual core 3.0 Ghz CPUs. The three hosts will all be members of the same ESX cluster. Read the rest of this entry »

How many VMs should run on each ESX host? The answer is determined mostly by the physical resources of the host’s platform (storage, ram, cpu, etc.). Before VI3 introduced ESX Clusters with DRS and HA squeezing as many VMs on each ESX host as possible was acceptable. Today it’s not just ESX host capacity, but ESX Clusters need to be take into consideration. Planning Cluster capacity means ensuring availability of VMs while maintaining acceptable host performance in a fail over scenarios.

First, what is a fail over scenario? The first thing that comes to mind is a problem. One or more of your ESX hosts unexpectedly crashed. This is considered unplanned downtime. Another fail over scenario to consider is planned downtime such as rebooting after applying ESX patches. For both of these types of scenarios you want to make sure your VMs stay online.

VMware’s solution for planned downtime is VMotion. The solution for unplanned downtime is the HA feature of ESX Clusters. When determining your ESX capacity be sure to allow room to leverage these features.

VMotion migrates a VM to a different ESX host without users losing connectivity. Evacuating an ESX server by VMotion enables you Read the rest of this entry »