We are looking into using Azure Site Recovery as part of our Disaster Recovery plan. The hope is to spin up cloud VM's in case of a system outage to continue using Centricity until a local problem is resolved. Does anyone have any experience using this with Centricity?
Following
Drew,
we are getting quotes on a similar solution from Veeam connecting to Azure. The idea is to get an offsite backup of our local VM backups (we are using Veeam) nightly to the cloud. Based on the overall risk, we decided that we did not need near real-time recovery points, so there is no need for site to site replication. In the event of a true disaster (i.e. one that would prevent us from restoring our VMs from a local backup), we would spin up the necessary VMs stored in Azure until we had time to fully recover from the event. This strategy will also allow us to test our recovery procedures by allowing us to temporarily spin up the cloud VMs once or twice a year. I'd be happy to share our findings, but as of now we are just getting competitive quotes. We do plan on moving forward with this approach once we are comfortable with a final bid. I'll try and remember to post results once we have gone live.
I haven't done this with CPS or Azure, but I have set this up with other mission-critical apps on VMWare's DR cloud a couple of years ago.
If you're in a terminal services environment, I would expect things to work quite well for DR mode.
In the case of VMWare, essential servers are mirrored to the cloud. We could start any of them up at will, either connected to the network or not, to make sure they'd start. There were a number of test scenarios available.
The network failover was the harder part due to duplicate IP addressing. If the local network failed, it isn't a big deal because users can use hotspots, Starbucks, or whatever internet to RDP into the failover cloud.
If the local network was up, but we had a server cluster failure of some type, how do we route around the failure to the same subnet in the cloud. The VMWare cloud lets you automatically change server IPs to a different subnet, but try that with your static DNS entries and see how it works out. We chose to mirror our production subnets. IIRC, I think our plan was to have users join an alternate local network via wifi or switch computers to a different VLAN for internet access which didn't conflict with the production subnets.
Here's a planned failover guide for VMWare's system: https://www.vmware.com/cloud-services/using-vcloud-air/tutorials/disaster-recovery-performing-a-planned-failover.html
-dp
This is good info. Thanks for the response. We are using VMware, so we will look into that as well.
No problem. Admittedly, VMWare's cloud service at the time seemed clunky. It wasn't really ready for prime time, but it was fully functional. There were two different halves of the cloud management environment which made things confusing. I would imagine they've finished all that by now and cleaned up the user interfaces.
-dp