Tuesday, February 21, 2012

Placing swap files for SRM

After some time working with Site Recovery Manager (SRM), you might be asking yourself how you can improve it.
The Technical White Paper SRM 5.0 Performance and Best Practices can give you a good starting point .

One of the topics I see a lot of discussion about is the location of vSphere swap files on a non-replicated datastore.
If you think about this concept why not also configure the guest swap file (aka page file) on a non-replicated datastore ?!

As you know the data on swap files are lost during reboots and power off.
So it’s useless during a recovery as the VM will be power on again on the recovery site and the swap files will be populated with new data from scratch.

So, placing the swap files on a non-replicated datastore would make sense.

Some benefits of this approach are:
Since you will have less data to replicate you will conserve some bandwidth on your link.
In some environments the replicated datastore could be more expensive than non-replicated datastore, allowing you to save some $$$.
Faster recovery and tests, as there’s no swap file to be replicated this step is skipped.

But it also has some downsides.
It’s a bit more complex to manage, since not all VM’s files are on the same replicated datastores.
Changing the swap file to a single datastore create a single point of failure for all your VMs, you should carefully evaluate that.
Windows assigns volumes letters to disks based on the signature of the disk, it could be trick to make Windows recognize the page-file disk after you recovery it.

Ok, let’s focus on how to do that.

• vSphere swap file.

- change the cluster settings, so the swap file location will be specified by the host.

- on the host settings, change the swap file location to the non-replicated storage.

You would need to change it on both vCenters, Protected Site and Recovery Site.

• Guest Page-File

On Protected Site
- create a new vmdk file for the VM on a non-replicate storage
- using the VM format the new disk
- change the page-file location the new disk.

On Recovery Site
- Copy the new VMDK from the Protected site to the Recovery Site to a non-replicated storage.
- Change the Placeholder VM to point the secondary disk to the disk you just copied.

As I’d like to say there’s no size that fits all.
I’m not saying it should be or should not be the design for your environment, I’m just pointing out the options you have and what the SRM is capable of, it’s up to you evaluate the options, test them on your environment and take the decision which is better for you. ; )

See you next

Wednesday, February 8, 2012

Reprotect and SRM with VR

******    Updated information - May 28, 2015                                          *****
******     I know I'm later for this update, either way here it goes            
******     Reprotect for VR workloads has been introduced on SRM 5.1  ***** *************************************************************************
As my last post this one is also about SRM and the Reprotect process when using vSphere Replication (VR) as your replication method.

If you red the SRM Admin Guide carefully you will notice that Reprotect is not supported when using VR.

on their's own words:
NOTE Reprotect is supported only for array-based replication. vSphere Replication (VR) reprotect is not supported. If a recovery plan contains VR groups, remove those groups before you execute a reprotect

So, After you run a Migration (Planned or Not) you see that Reprotect icon is available.

So in what world you would not be tempted to do not try that on ?!?!?

If you are like me you will press that just to see what happens.
Well, reprotect would not start and the message you will get is:
“Reprotect is not supported for VR protection groups. You must edit the plan to remove all VR protection groups before running reprotect.”

So you might be wondered how to Failback your VMs to the original site.

In fact you need to configure everything back in the reverse order.

Here’s some main steps that can guide you on your environment.

- remove the VM from the inventory at the Protected Site (just removing it from the inventory instead of deleting it will speed up the first synchronization because the VMDK will be already there and just the changes will be replicated).
- remove the original Protection Group or remove the VM from it.
- If you want to keep the Original Recovery Plan historical information keep it, otherwise it’s safe to delete it.
- configure replication from the Recovery site to the Protected site.
- create a new protection group with the VM from the Recovery Site
- create a new recovery plan
Now you are ready, it’s just to run a migration again and your VM will be back to the original site.

Make sure to test it exhaustively until you are safe with the process and be prepared to any incident.

Who am I

My photo
I’m an IT specialist with over 15 years of experience, working from IT infrastructure to management products, troubleshooting and project management skills from medium to large environments. Nowadays I'm working for VMware as a Consulting Architect, helping customers to embrace the Cloud Era and make them successfully on their journey. Despite the fact I'm a VMware employee these postings reflect my own opinion and do not represents VMware's position, strategies or opinions. Reach me at @dumeirell

Most Viewed Posts

Blog Archive