This needs the Azure Site Recovery Provider that coordinates disaster operations on the Hyper-V host. It uses port 443 to communicate with the Microsoft Azure Data Center. Data protection people will be delighted. A Recovery Services Agent on each VM is also required. Where needed, it runs scripts on the actual VMs in order to execute the operations during a disaster.
3. Microsoft Azure Automation
Last but least there will have to be the opportunity for the automatic execution of a failover process. Microsoft Azure Automation is predestined for this task. Users can set up an Azure Automation Account or select a ready-made runbook from a pool. After adding the runbook to the personal account it only takes a mouse click to launch several operations.
The test failover does not impact the local servers at all. The VMs are merely booted in Azure and the volumes are mapped to the VMs. Before that happens the StorSimple volumes are cloned and attached to the Virtual Appliance, thus producing the perfect playing field.
The planned failover tries the ‘friendly approach’ to shutting down the VMs in the local data center in order to then boot the resources in Azure. To do this an existing Cloud Snapshot is mapped to the Virtual Appliance. Voilà!
The unplanned failover then simply boots the VMs in Azure and executes a failover of the StorSimple volume container. Afterwards the volumes are available to the VMs, and access to the data is restored for the file server.