Migrate to Innovate Summit:
Learn how migrating and modernizing to Azure can boost your business's performance, resilience, and security, enabling you to fully embrace AI.Register now
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Overview of multi-tenant support for VMware disaster recovery to Azure with CSP
Article
Azure Site Recovery supports multi-tenant environments for tenant subscriptions. It also supports multi-tenancy for tenant subscriptions that are created and managed through the Microsoft Cloud Solution Provider (CSP) program.
This article provides an overview of implementing and managing multi-tenant VMware to Azure replication.
Multi-tenant environments
There are three major multi-tenant models:
Shared Hosting Services Provider (HSP): The partner owns the physical infrastructure, and uses shared resources (vCenter, datacenters, physical storage, and so on) to host multiple tenant VMs on the same infrastructure. The partner can provide disaster-recovery management as a managed service, or the tenant can own disaster recovery as a self-service solution.
Dedicated Hosting Services Provider: The partner owns the physical infrastructure, but uses dedicated resources (multiple vCenters, physical datastores, and so on) to host each tenant’s VMs on a separate infrastructure. The partner can provide disaster-recovery management as a managed service, or the tenant can own it as a self-service solution.
Managed Services Provider (MSP): The customer owns the physical infrastructure that hosts the VMs, and the partner provides disaster-recovery enablement and management.
Shared-hosting services provider (HSP)
The other two scenarios are subsets of the shared-hosting scenario, and they use the same principles. The differences are described at the end of the shared-hosting guidance.
The basic requirement in a multi-tenant scenario is that tenants must be isolated. One tenant should not be able to observe what another tenant has hosted. In a partner-managed environment, this requirement is not as important as it is in a self-service environment, where it can be critical. This article assumes that tenant isolation is required.
The architecture is shown in the following diagram.
Shared-hosting with one vCenter server
In the diagram, each customer has a separate management server. This configuration limits tenant access to tenant-specific VMs, and enables tenant isolation. VMware VM replication uses the configuration server to discover VMs, and install agents. The same principles apply to multi-tenant environments, with the addition of restricting VM discovery using vCenter access control.
The data isolation requirement means that all sensitive infrastructure information (such as access credentials) remains undisclosed to tenants. For this reason, we recommend that all components of the management server remain under the exclusive control of the partner. The management server components are:
Configuration server
Process server
Master target server
A separate scaled-out process server is also under the partner's control.
Configuration server accounts
Every configuration server in the multi-tenant scenario uses two accounts:
vCenter access account: This account is used to discover tenant VMs. It has vCenter access permissions assigned to it. To help avoid access leaks, we recommend that partners enter these credentials themselves in the configuration tool.
Virtual machine access account: This account is used to install the Mobility service agent on tenant VMs, with an automatic push. It is usually a domain account that a tenant might provide to a partner, or an account that the partner might manage directly. If a tenant doesn't want to share the details with the partner directly, they can enter the credentials through limited-time access to the configuration server. Or, with the partner's assistance, they can install the Mobility service agent manually.
vCenter account requirements
Configure the configuration server with an account that has a special role assigned to it.
The role assignment must be applied to the vCenter access account for each vCenter object, and not propagated to the child objects. This configuration ensures tenant isolation, because access propagation can result in accidental access to other objects.
The alternative approach is to assign the user account and role at the datacenter object, and propagate them to the child objects. Then give the account a No access role for every object (such as VMs that belong to other tenants) that should be inaccessible to a particular tenant. This configuration is cumbersome. It exposes accidental access controls, because every new child object is also automatically granted access that's inherited from the parent. Therefore, we recommend that you use the first approach.
Create a vCenter account
Create a new role by cloning the predefined Read-only role, and then give it a convenient name (such as Azure_Site_Recovery, as shown in this example).
Assign access levels to the vCenter account (used in the tenant configuration server) for various objects, as follows:
Object
Role
Remarks
vCenter
Read-Only
Needed only to allow vCenter access for managing different objects. You can remove this permission if the account is never going to be provided to a tenant or used for any management operations on the vCenter.
Datacenter
Azure_Site_Recovery
Host and host cluster
Azure_Site_Recovery
Re-ensures that access is at the object level, so that only accessible hosts have tenant VMs before failover and after failback.
Datastore and datastore cluster
Azure_Site_Recovery
Same as preceding.
Network
Azure_Site_Recovery
Management server
Azure_Site_Recovery
Includes access to all components (CS, PS, and MT) outside the CS machine.
Tenant VMs
Azure_Site_Recovery
Ensures that any new tenant VMs of a particular tenant also get this access, or they will not be discoverable through the Azure portal.
The vCenter account access is now complete. This step fulfills the minimum permissions requirement to complete failback operations. You can also use these access permissions with your existing policies. Just modify your existing permissions set to include role permissions from step 2, detailed previously.
Failover only
To restrict disaster recovery operations up until failover only (that is, without failback capabilities), use the previous procedure, with these exceptions:
Instead of assigning the Azure_Site_Recovery role to the vCenter access account, assign only a Read-Only role to that account. This permission set allows VM replication and failover, and it does not allow failback.
Everything else in the preceding process remains as is. To ensure tenant isolation and restrict VM discovery, every permission is still assigned at the object level only, and not propagated to child objects.
Deploy resources to the tenant subscription
On the Azure portal, create a resource group, and then deploy a Recovery Services vault per the usual process.
Download the vault registration key.
Register the CS for the tenant by using the vault registration key.
Enter the credentials for the two access accounts, the account to access the vCenter server, and the account to access the VM.
Register servers in the vault
In the Azure portal, in the vault that you created earlier, register the vCenter server to the configuration server, using the vCenter account you created.
Finish the "Prepare infrastructure" process for Site Recovery per the usual process.
The VMs are now ready to be replicated. Verify that only the tenant’s VMs are displayed in Replicate > Select virtual machines.
Dedicated hosting solution
As shown in the following diagram, the architectural difference in a dedicated hosting solution is that each tenant’s infrastructure is set up for that tenant only.
Dedicated hosting scenario with multiple vCenters
Managed service solution
As shown in the following diagram, the architectural difference in a managed service solution is that each tenant’s infrastructure is also physically separate from other tenants' infrastructure. This scenario usually exists when the tenant owns the infrastructure and wants a solution provider to manage disaster recovery.
Managed service scenario with multiple vCenters
Next steps
Learn more about role-based access control in Site Recovery.