Another Milestone Implementing SRM for Disaster Recovery

There are many FAQ available about SRM installation and configuration . One of them which I like is

http://www.yellow-bricks.com/srm-faq/

I would like to share my own personal experience. On Saturday 21^st of Nov 2009 I have tested live DR scenario for our customer readiness .

This involved 26 Key application of our customer running across 17 Physical Database server and 45 virtual machines. We have excluded AD/Exchange. For exchange we used EMS system from Dell.

For SRM setup I used

1. 4 ESX host running on DL380 G5 with few of them has installed Qlogic HBA and other used S/W ISCSI.

2. 4 ESX host were installed with ESX3.5 U4 and both side I was running VC2.5 U5.

3. All the 4 ESX host were configured for HA/DRS.

4. Unfortunately all the 45 VM were spread across 33 lun. I could have consolidated for the SRM prospective.

5. For this purpose I have used SRMV1.0.1 with Patch 1. We are using NetAPP as our storage solution.

6. To save bandwidth we have kept protected and recovery filer at same location . Replicated and then ship it across to DR location. This will help us to save bandwidth for initial replication as we are dependent on incremental replication.

7. We are using  “Stretch VLAN “ so that we don’t have to re-ip the machine when it recovered at recovery site.

SRM setup and configuration:

1. Create a service account for SRM ,which will be used for setup SQL database for SRM and will be used during the installation of SRM

2.Install SRM database at each of the Virtual Center on SQL server. I configured DSN  prior though during the SRM setup it will prompt.

3.Install all the SRM patch for 1.0 and then install SRA(Storage Replication Adaptor). This Adaptor comes from the vendor whose storage solution you are using. You can download from VMware site only if you login to their account or else they don’t allow open download. In my case I used NetAPP SRA.

4. Once both site Protected Site and Recovery Site had the all the component installed we will start pairing the site. At Recovery site we need to provide Protected site IP and at Protected site we need to provide Recovery Site ip so that it can be paired. Use service account to pair the site.

5.Once the site is paired then we will need configure SRA for Protected site and Recovery site. Before this being configured we should insure that replication is completed . Check  with storage admin, or else we can not proceed further with configuration. This replicated also help us to create a bubble VM at recovery site.

Once it is confirmed that replication is over then configure the Array  by running “Configure Array  Managers” wizard.

a. For Protected site supply the IP address of the NetAPP filer. Ensure that you uses root or root like credential to authenticate. You must see replicated Array Pairs. If you have many filer which has lun/volume spread across then use the add button to add all those filer

b. Then we will configuring the same for Recovery site. Which all filer are paired ,insure that you add all the pair filer at the recovery site as well. Use the root/root like credential to add it . You can keep adding all the recovery site filer IP and then you will see green icon which states that Array has been paired properly

c. Once Protected Site and Recovery Site has been paired using replication array then we can find all the replicated datastores. If not

visible then rescan the array

After setup at Protected Site we need to do the same at Recovery Site. Protected Site and Recovery Site IP will be remain as we configured at Protected Site. You won’t be able to see Replicated Datastores at the Recovery Site as we are not configuring two way recovery site.

6. Now we need to configure the Inventory mapping at “Protected Site” .

This is very crucial and critical setup at Protected Site. Before we do inventories mapping we should consolidate all the VM into single folder by name something like SRM at Protected site.  Create similar folder at Recovery site so that we can have one to one mapping. We also need to make sure that if we are doing mapping for “Computer Resource” for Cluster host . It should have HA/DRS enabled or it will NOT allow to create bubble VM.

Assuming that we are using stretched VLAN and we have those VLAN created at Recovery Site.

This step is not required at Recovery Site.

7. We  now need to create Protection Group at Protected site and does not require at Recovery  site.

This protection group based each individual LUN and which VM’s on those lun needs to be protected. One LUN can be part of one protected group and cannot be mapped to any other protection group. Hence it is very important we need to classify the lun based on HIGH/NORMAL/LOW categories. Similarly we can plan for mapping. If we have done inventory mapping correctly then status will be shown as configured for protection

We can also run through wizard for configuring for each VM. Here we can configure for priories of startup as low/normal/high based on which VM should be started first.

If the replication is over then you can also see the status on Storage devices.

Also make a note that at Protected Site there should not any CD-ROM connection or Floppy connected or else automatic configuration will fail.

8. Once we have all the steps configured as above we can start with setup at of Recovery Plan @Recovery site. This recovery plan can be run in two mode test and recovery mode. Test mode is to insure that  you actual recovery run as per requirement. This runs using flex Clone (Incase of NetAPP storage)lun and recovery bubble network.  We need to ensure license for FlexClone at Recovery site filer. These test does not impact the Production system. After the test all the VM’s are powered off and LUN’s are resyched. Here we can move the VM in the priorities list to make sure it start first and then next VM and so on .

9. In the actual recovery mode it does attach the lun and then start powering on VM from high to low. Once this is overy you can export the report by clicking history

How to perform manual DR using VMWare and NetAPP?

Well I had been working on vSRM as you can find few reference from my blog about it. But I had been asked to see incase SRM fail how can we have “plan B”.
We used SNAP mirror technologies from NetAPP to accomplish “Plan B”
Here is what I suggested:
1. During initial setup snap mirror on LAN and then once it is completed plan to ship the filer to DR location. This way we can save some bandwidth for replication as it will be only changes which will get replicated.
2. With manual process we need to maintain few documents especially with all the luns which will get replicated across location along with the serial number. The reason will be explained below
3. Once the replication is over we will start preparing for DR testing. For testing purpose I have selected one ESX host with dummy VLAN’s
4. I broke the snap mirror relationship between filer for the volume which was interested in testing. Once the volume is broken it become active and all luns are visible on the filer. It will be with same lun name and lun number . But the serial number will be changes.
5. This being very scariest part of entire exercise . If the lun serial number do not match with that of primary site then lun will appear as blank lun. We need to one to one mapping for lun serial number as it should be matching with that of protected site.

Before you change the lun serial number at the recovery site we need to make the lun offline and then run following command to change the serial number
# lun serial serial number.

Eg: lun serial /vol/S_xxxx_011PP_vol1/lun1 12345

6. Once it has same serial number map the lun to correct igroup and rescan hba on ESX host. Once the rescan is completed all the lun and datastore will appear “AS IT IS ” at the recovery site.

7. We have to register all the VM in order to power on . This can be accomplished using script.

Happy DR.

VSRM2:Network Consideration

I had been trying to write about my SRM implementation for a long time. I wrote about Network consideration long time back. This is how I have implemented stretched VLAN.
Then Man behind this effort was network colleague Randall Bjorge.
1. What we did is we created same VLAN at Recovery site as in Protected site. For example say if VLAN100 exist in Protected site then we also created VLAN 100 at the Recovery Site
2. Same VLAN created at Recovery site has been keep in shutdown state.
3. When we initiated actual DR for our test environment we shut down the VLAN at Protected site.
4. We then brought VLAN at Recovery Site and pressed the RED recovery button.

To simplified this process we scripted this VLAN shutdown and VLAN bring up process. When we brought VLAN at Recovery site we had some challenges in routing network.

I expected this process to be very tough but when we worked it turned out to be very simple and straight. In actual DR scenario I am planning to place a DC/DNS/DHCP to make this IP routing simple.

vSRM2: Database consideration

For Microsoft SQL Server, the database should be configured as follows:
1. Schema name should be same as the user name and you must have a default schema associated with the user account
2. Bulk insert administrator privileges
3. If Windows authentication is used, install SRM service on a host that shares the same domain as the database server
4. If SQL Server is installed locally, you might need to disable the shared memory network setting on the database server

vSRM 1: Network Consideration

I have done demo in past for vSRM 1.0 using NetApp SIM. I though of starting a new fresh topic on my blog about Site recovery Manager.

Option 1: Use the Same IP
When we start powering on VMs at the Recovery Site – they may be on totally different networks requiring different IP addresses and DNS updates to allow for user connectivity. The good news is SRM can control and automate this process. One very easy way to simplify this for SRM is to implement “stretched VLANs” where two geographically different locations appear to be on the same VLAN/subnet. However, you may not have the authority to implement this – and unless it is already in place it is a major change to your physical switch configuration, to say the least. It’s worth making it clear that even if you do implement stretched VLANs you may still have to create inventory mappings because of port group differences. For example there may indeed be a VLAN 101 in Boston and a VLAN 101 in Amsterdam . But if the administrative team in Boston call their port groups on a virtual switch BOS-101 and the guys in Amsterdam call theirs AMS-101 then you would still need a port group mapping in the Inventory Mappings tab.

(Source : Administering VMware's Site Recovery Manager chapter 4)

Option 2: Re-IP all the VM’s at the recovery site

This can be done using “dr-ip-customizer.exe” The basic process is to export the current NIC settings to a CSV, edit the CSV with your new IP addresses and then import it back into SRM with the new desired IP addresses. In reality this tool is helping to create the Customization Specifications for you, so you can actually see them from the Edit - Customization Specifications window after you follow the process.

(Source : Site Recovery Manager Administration Guide Page54)

Duncan : If you want to keep it simple in terms of failover I would always prefer stretched vlan's. Especially dependency wise re-ip'ing can be a huge problem. (hardcoded ip's within apps / databases etc)

Lee Dilworth : From the x86 side of things I sometimes get the feeling that for historic reasons a lot of x86 teams were forced to re-ip in DR since
A) Networks didn't support transparent failover
B) Not that many workloads existed on x86 that were classed as critical for the business that they needed to be included in any DR strategy, as we all know in the last 5-10 years this swing has shifted massively and now the vast majority of workloads will be running on x86 based OS's. So maybe its time for a re-think?
What you need to consider are todays "modern" and multi-tier applications (web/msg/rdbms) how many in your portfolio would you expect to work unaided if you simply re-ip'd them? probably not many and confidence is low...for example would you really want to failover lots of oracle/sql srvr/exchange VM's and then give them all brand new ipaddresses. ok they may work if you are VERY confident that the apps respond well to that and that you have been very strict company wide in your use of FQDN's and aliases if not then there's always those hardcoded ipaddresses that can bring your application stacks to their knees if you forget (or miss) to change on. Bottom line, when changing the ip-addresses over you could (not always) introduce a whole extra set of tests that need to be run once the VM's are recovered. The nice thing about SRM is that at least now you can perform these tests in a non-disruptive way which is great but if you feel that in real DR situations you still need to run them no matter how well your testing went then any extra tests

1. Whats our strategy for failover? change ip addresses / keep same address?
2. Do we stretch layer2 vlan?
3. Do we failover layer 3?
4. How do we update DNS if we make changes? is that scripted?
5. Do we need a secure test set of vlans created at the test site that can be used for DR testing? do these exist?
6. If we do re-ip do we have an existing mechanism/solution/set of scripts/dhcp reservations that do this for us (if you do then these same techniques will almost certainly work unaltered against your VM's)
7. Does SRM offer any other options for re-ip if we don't have an existing mechanism (yes it does!)

Once you can answer the above you then will have a better idea of what your solution should look like. customers i am working with now that are deploying SRM and have answered this usually then come back with a simple addition to their network setup. they create the required vlans at the network layer, ensure they have the correct routing / ACL's set etc and then they present these down the same trunk ports that the recovery site ESX hosts are using. once this is done they can then create portgroups for these new test vlans and finally in their SRM recovery plans they now select these "test" portgroups as the ones to use for the test network rather than the "Auto" default.