The impossible task of rapid Disaster Recovery – and how Microsoft Azure can help

I remember when I had to setup my first DR plan for a datacenter failover of critical systems from one datacenter to our backup datacenter.  It was a nightmare of logistical planning and near duplicate hardware / infrastructure required to have the bare minimum systems in place for some level of business continuity. It took months of planning and I-Don’t-Even-Want-To-Think-How-Much money in order to pull it off.

Oh – then we had to test it.

That was a fun weekend of 18 hr days I will never get back.

Virtualization has made things significantly easier than running on bare metal.  It makes your VMs are transportable between different systems running the same hypervisor and managed by tools like SystemCenter to ensure proper synchronization and coordination when something goes wrong.  BUT – you still needed to have duplicate resources / networking setups and physical datacenters in order for this to work… Until Public Cloud datacenters like Microsoft Azure became an option.  With hybrid connectivity,  virtual networks and subnets, firewall endpoints and a wide range of virtual machine base image sizes – you can dial in your configurations to be damn near identical to the VM spec of your on-premises systems AND only pay for what is up and running.

Our Disaster Recovery offering is called Azure Site Recovery.  It recently got a boost in capabilities that now allows you to include VM Guests that run on Hyper-V, VMware – so long as they are running a supported version of Windows Server and Linux distribution that is comparable in Azure.  In the past – Azure Site Recovery required that you had a comprehensive SystemCenter implementation in place in order to protect various workloads. that isn’t the case anymore (although still recommencement for more complex workloads of multiple machines) .  In case you missed it – I recently did an interview with Matt McSpirit (a fellow Technical Evangelist on my team who handles the On-Premises space) where he took us through how Azure Site Recovery works.

If DR is on your list of things to explore and possibly implement in the future OR if you already manage a DR implementation and are interested in simplifying it’s setup and execution – you need to check out Azure Site Recovery.

You should sign up for the preview so you can try it out yourself (scroll down to the bottom)… Once you’ve been accepted (or just want some more detailed step by step instructions on how it is setup) check out this article on the Azure site.

 

About author View all posts

Rick


Warning: sizeof(): Parameter must be an array or an object that implements Countable in D:\home\site\wwwroot\wp-content\plugins\projectnami-blob-cache\project-nami-blob-cache.php on line 416

Fatal error: Uncaught WindowsAzure\Common\ServiceException: Fail: Code: 400 Value: The account being accessed does not support http. details (if any): <?xml version="1.0" encoding="utf-8"?><Error><Code>AccountRequiresHttps</Code><Message>The account being accessed does not support http. RequestId:1cd01262-001e-0057-53eb-8921c2000000 Time:2021-08-05T11:15:29.7877602Z</Message><AccountName>ritgcache</AccountName></Error>. in D:\home\site\wwwroot\wp-content\plugins\projectnami-blob-cache\library\WindowsAzure\Common\Internal\Http\HttpClient.php:382 Stack trace: #0 D:\home\site\wwwroot\wp-content\plugins\projectnami-blob-cache\library\WindowsAzure\Common\Internal\Http\HttpClient.php(275): WindowsAzure\Common\Internal\Http\HttpClient::throwIfError(400, 'The account bei...', '\xEF\xBB\xBF<?xml versio...', Array) #1 D:\home\site\wwwroot\wp-content\plugins\projectnami-blob-cache\library\WindowsAzure\Common\Internal\RestProxy.php(141): WindowsAzure\Common\Internal\Http\HttpClient->send(Array, Object(WindowsAzure\Common\Internal\ in D:\home\site\wwwroot\wp-content\plugins\projectnami-blob-cache\library\WindowsAzure\Common\Internal\Http\HttpClient.php on line 382