Deployment prerequisites: On-premises to on-premises
Updated: September 10, 2014
Do the following before you deploy Azure Site Recovery for on-premises to on-premises protection:
Read through the Privacy information in this topic. It summarizes the information that’s collected, processed, or transmitted for each Azure Site Recovery feature.
Verify Prerequisites and support in the Planning guide.
Sign up for Azure and check the pricing details for Azure Site Recovery. See Step 1: Sign up for Azure in the Planning Guide.
Read through Capacity planning for Hyper-V replication to figure out Hyper-V Replication requirements.
Learn how Network mappingworks.
Ensure that your Virtual Machine Manager (VMM) infrastructure is ready for Azure Site Recovery deployment. See Step 2: Plan the VMM infrastructure in the Planning Guide.
Prepare your VMM networks for network mapping in Azure Site Recovery. See Step 3: Prepare for network mapping in the Planning Guide
Prepare VMM storage classifications for storage mapping for on-premises to on-premises deployment. See Step 3: Prepare for network mapping in the Planning Guide
Read through Step 5: Prepare for Provider deployment in the Planning guide.
After verifying everything’s in place, start deployment with Step 1: Create an Azure Site Recovery vault: On-premises to on-premises.
This section provides additional privacy information for the Microsoft Azure Site Recovery service (“Service”).
To view the privacy statement for Microsoft Azure services, see the Microsoft Azure Privacy Statement.
You use this feature to register your VMM server with the Service. Registration helps to establish a trust relationship between your VMM server and the Service. Once the trust is established, the Service can provide protection to selected virtual machines in case of disaster.
After registering a VMM server, the Service collects, processes, and transmits the following information:
Management certificate information from the VMM server that’s designated to provide disaster recovery using the Service name of the VMM server
The name of virtual machine clouds on your VMM server
The Service uses the above information as follows:
- Management certificate—This is used to help identify and authenticate the registered VMM server for access to the Service. The Service uses the public key portion of the certificate to secure a token that only the registered VMM server can gain access to. The server needs to use this token to gain access to the Service features.
- Name of the VMM server—The VMM server name is required to identify and communicate with the appropriate VMM server on which the clouds are located.
- Cloud names from the VMM server—The cloud name is required when using the Service cloud pairing/unpairing feature described below. When you decide to pair your cloud from a primary data center with another cloud in the recovery data center, the names of all the clouds from the recovery data center are presented.
This information is an essential part of the Service registration process because it helps you and the Service to identify the VMM server for which you want to provide Azure Site Recovery protection, as well as to identify the correct registered VMM server. If you don’t want to send this information to the Service, do not use this Service. If you register your server and then later want to unregister it, you can do so by deleting the VMM server information from the Service portal (which is the Azure portal).
The Azure Site Recovery Provider installed on the VMM server is the conduit for communicating with the Service. The Provider is a dynamic-link library (DLL) hosted in the VMM process. After the Provider is installed, the “Datacenter Recovery” feature gets enabled in the VMM administrator console. Any new or existing virtual machines in a cloud can enable a property called “Datacenter Recovery” to help protect the virtual machine. Once this property is set, the Provider sends the name and ID of the virtual machine to the Service. The virtual protection is enabled by Windows Server 2012 or Windows Server 2012 R2 Hyper-V replication technology. The virtual machine data gets replicated from one Hyper-V host to another (typically located in a different “recovery” data center).
The Service collects, processes, and transmits metadata for the virtual machine, which includes the name, ID, virtual network, and the name of the cloud to which it belongs.
The Service uses the above information to populate the virtual machine information on your Service portal.
This is an essential part of the service and can’t be turned off. If you don’t want this information sent to the Service, don’t enable Azure Site Recovery protection for any virtual machines.
All data sent by the Provider to the Service is sent over Secure Hypertext Transfer Protocol (HTTPS).
This feature helps you to build an orchestration plan for the “recovery” data center. You can define the order in which the virtual machines or a group of virtual machines should be started at the recovery site. You can also specify any automated scripts to be run, or any manual action to be taken, at the time of recovery for each virtual machine. Failover (covered in the next section) is typically triggered at the Recovery Plan level for coordinated recovery.
The Service collects, processes, and transmits the following information as part of the Recovery Plan feature:
Recovery plan, including virtual machine metadata
Metadata of the automation script or the manual action note
The metadata described above is used to build the recovery plan in your Service portal.
This is an essential part of the service and can’t be turned off. If you don’t want this information sent to the Service, don’t build Recovery Plans in this Service.
This feature allows you to map network information from the primary data center to the recovery data center. When the virtual machines are recovered on the recovery site, this mapping helps in establishing network connectivity for them.
As part of the network mapping feature, the Service collects, processes, and transmits the metadata of the logical networks for each site (primary and datacenter).
The Service uses the metadata to populate your Service portal where you can map the network information.
This is an essential part of the Service and can’t be turned off. If you don’t want this information sent to the Service, don’t use the network mapping feature.
This feature helps failover of a virtual machine from one VMM managed data center to another VMM managed data center. The failover action is triggered by the user on their Service portal. Possible reasons for a failover could be any of the following:
An unplanned event (for example, in the case of a natural disaster)
A planned event (for example, data center load balancing)
A test failover (for example, a recovery plan rehearsal)
The Provider on the VMM server gets notified of the event from the Service, and executes a failover action on the Hyper-V host through VMM interfaces. Actual failover of the virtual machine from one Hyper-V host to another (typically running in a different “recovery” data center) is handled by the Windows Server 2012 or Windows Server 2012 R2 Hyper-V replication technology.
After the failover is complete, the Provider installed on the VMM server of the “recovery” data center sends the success information to the Service.
The Service collects, processes, and transmits the following information as part of the failover feature:
Metadata for the virtual machine, which includes name, ID, virtual network, and the name of the cloud to which it belongs
Success or failure messages pertaining to the failover action
The Service uses the above information to populate the status of the failover action information on your Service portal.
This is an essential part of the service and can’t be turned off. If you don’t want this information sent to the Service, don’t use this Service.
The Provider transmits any Provider-related error or job progress information to the Service for user alerting.
The Provider activities on the VMM server.
Any errors in the Provider. For example, errors during heartbeats, or certificate expiry, or errors that occurred due to actions triggered by the Provider (errors while initiating Hyper-V replication, errors during virtual machine failover, and so on) are transmitted to the Service.
Any information related to jobs triggered by the user (for example, failover, enable protection, and so on) is transmitted to the Service for progress notification.
To alert the user by displaying error messages encountered while using functionality of the Service.
This is an essential part of the service and can’t be turned off. If you don’t want this data sent to the Service, don’t use this feature.
Other ResourcesMicrosoft Azure Recovery Services Forum