Mar 312011
 

I was installing Site Recovery Manager in Miami today for a customer who replicates to Atlanta.  I’ve been working with them the last few days to setup SRM and get their Protection Groups and Recovery Plans in place.  One suggestion that I made was to add a Message to their Recovery Plans to pause after the Shutdown of the Primary Site VMs.

Here’s why:  In a true failover in SRM, the first step of the Recovery Plan is to shut down all of the VMs in the primary site that are protected.  This is so that when the VMs restart in the recovery site, they do not conflict on the network with the original VMs.  Here in Miami the typical disaster is, of course, hurricanes.  Hurricanes are typically predictable with a decent notice.  I can then assume that my odds are higher than normal that when the person hits the failover button here, both sites are still available and I will be avoiding a disaster and not recovering from one.  For this reason, I recommended to my customer that they add a message in their recovery plan right above “Prepare Storage” in the Recovery Plan.  You can do this by right-clicking “Prepare Storage” and selecting “Add Message”.

I added the following message to their Recovery Plan:

If this is a true failover and Miami is still available, perform a final replication of the storage to get the last transactions from Miami.  Once all replication is completed, you may click Continue.

If this is only a test of the plan, you may click Continue at any time.”
My customer replicates hourly between sites.  If they were to start a failover 45 minutes after the last replication, they would lose the last 45 minutes of transactions when they ran the Recovery Plan.  SRM does not kick off replication in any way.  When we add the message above, we can have the storage admin run a final sync from the production site with the VM’s in a down state.  This will extent my Recovery Time Objective as it will add time to the whole plan to have to wait for the final replication to finish.  However, using this last replication, I can now get the final transactions over to the Recovery Site and minimize the clean up work on recovery.  Of course, you can script this last replication if you want to, however be very careful as there is no way to mark a script to run in failover mode only (vs. test mode).  You may not want a script to force a replication in both test mode and full recovery mode.
Just a little tip to optimize your Disaster Failover.  Now let’s hope we never need to use it.
Mar 012011
 

This is an important release as it allows customers to migrate their VMs or vApps from the private to the public clouds.  You can go straight to the downloads section here.  You’ll find some interesting features in the release notes:

VMware vCloud Connector (vCC) allows the vSphere Administrators to use their familiar vSphere Client as a singlepane-of-glass view across hybrid clouds and perform the following operations:

  • See a list of virtual machines, vApps, or VM templates on vSphere and vCloud Director-based private and public clouds.
  • Copy virtual machines, vApps, or VM templates between vSphere and vCloud Director-based private and public clouds.
  • Perform basic operations (for example, power on/off, suspend, reset, delete) on virtual machines and
    vApps in vSphere and vCloud Director-based private and public clouds.
  • Deploy vApp templates as vApps (fenced mode) in vCloud Director-based private and public clouds.
  • Access vCloud vApp consoles on specific update releases of vSphere Client 4.0 and 4.1.