Archive for May, 2008

DR deployment strategies to consider

Thursday, May 22nd, 2008

There are a few deployment strategies and would depend on the ’status’ of your IT applications and ‘posture’ of the current DR deployment (if any).

I will describe the status and posture later but lets assume that most of our Business Applications are deployed (and not being built/delivered) - then, one of the deployment strategies we have seen is: Start a DR site with ‘DR ecosystem’ and ‘Testing/Staging ecosystem’ in the same datacenter.  As you build the DR ecosystem, you can test failovers on testing/staging ecosystem with DR ecosystem. On reaching sufficient comfort, start fail-overs between primary-to-DR site. Treat this as a baseline and any additions, you first test between DR ecosystem and test ecosystem and finally test with primary site. This is a great strategy as long as your IT ecosystem is fairly stable.

The assumption made above is what I call ’status’ - term refered to status of the business applications - IT is always deploying upgrades one way or another - its hard to see a ’stable’ status.

In addition to the status, you could also have a ‘temporary’ DR site and that is what I call ‘posture’ - term used to refer to DR ecosystem status. In the above scenario, the posture of the DR site is completely new.

Now back to another example, if the status of IT is half-ready and DR posture is ‘temporary’, it might be best to do this:  Start creating a clone of the existing temporary DR site (assuming it is deployed right) at the new site - start migrating application by application to the new site. Essentially, you are doing DR-to-DR site migration and performing fail-over between these 2 sites. This would also enable you to not dump all the investments in the old DR site. While you are doing this, new deployments should be done in the new IT ecosystem and perform fail-over tests between the primary and new DR site. Once the old DR site is ready to be retired, start the fail-over testing between new DR site and the primary site.  Whoooosh!

If the IT status is pretty stable and posture is fully ready however you need a new DR site for logistics reason (which is very rare), you may want to consider building a DR site (which is almost or better clone of the old DR site) and perform Primary-to-New-DR-failovers and build this one application at a time.

If you need additional perspectives, please let me know. Maybe, I can help.