VMware vCloud Availability 3.0 (vCAv) allows for self-serviceability by the provider and tenants for disaster recovery services. When working with the customer to set up the service, it is important to understand the scope of responsibility for the service and how it will be managed. This blog will focus on different factors impacting replication in vCloud Availability.
If we start by looking at the general architecture of the platform, it is designed in a way that allows for replication management from vSphere or vCloud Director. vCloud Availability supports cloud-to-cloud replication as well as vSphere-to-cloud replication. This means that vSphere users can set up replications in the vCloud Director UI. This also means that vCD users may have visibility into vSphere to set up replications as well. So what happens if we want to be able to seperate access between the vSphere users and the vCloud Director users and define domains of control. With vCloud Availability 3.0, this is possible.
Controlling vCloud Availability access from vCloud Director
For the enterprise administrators, when deploying the on-premises vCloud Availability appliance, there is an option under Cloud Details, Allow Access from Cloud, that can be set that controls the ability of users to set up new replications from vCD. If this is deactivated, vCD users cannot remotely browse vCenter. The only way to establish new replications is leveraging through vCenter. If this option is enabled, new replications can be established from either side.
If a vCloud Director user tries to set up a replication when this is deactivated, they will receive an appropriate permissions error.
vCloud Director users still have visibility into existing replications and can edit details and perform migrations or failovers regardless of how this flag is set.
Replication owners and visibility
So what about managed services and how is that affected by all of this? Not only do these permissions play an important role in the provider being able to see vSphere virtual machines, but there is an additional factor thrown into the mix. That factor is owner. When operating in a self-service model, the tenant who created the replication will also be the owner of the replication, so visibility is not impacted. But in the case of a managed service, the person who created the replication is the service provider, or the system administrator. Since the service provider created the replication, they are also the owner of the replication.
What this means is that the tenant, will not have the appropriate permissions to see vCloud Availability replications at the system level.
So how do we fix this so that the tenant can see the replications and allow the service provider to still manage the services? We can resolve this by assigning ownership of the replication to the tenant.
Won’t reassigning ownership impact the provider’s visibility? Remember, the service provider is a super user so they operate at the system level and can see across all tenants.
To make the change, select the replication(s) you would like to reassign. Next, click owner in the toolbar. This will bring up a modal with all of the available tenants this can be reassigned. Select the tenant to be assigned as owner. Finally, click Select to reassign ownership.
Once this is complete, not only does the service provider have visibility of the replication, but the tenant can now monitor and manage the replication as well.
Conclusion
It is important for not only the service provider, but the tenant to be aware of what controls are in place to control access. For customer who want limited access, they can force all replications to be instantiated from vCenter, but these replications can be managed from vCenter or vCD. In the case of service providers who are providing managed services, it will be important to not only ensure that Allow Cloud Access is enabled. Once replications have been established on behalf of the customer, it will be important for the provider to reassign the replications to the tenant so that they have visibility into the replication configuration and status.
Please feel free to review other articles related to the vCloud Availability blogs series:
1. vCloud Availability 3.0 Blog Series: Introduction
2. vCloud Availability 3.0 Blog Series: Provider Installation
3. vCloud Availability 3.0 Blog Series: Provider Post Deployment Configuration
4. vCloud Availability 3.0 Blog Series: Tenant Installation
5. vCloud Availability 3.0 Blog Series: Tenant Post Deployment Configuration
6. vCloud Availability 3.0 Blog Series: Managing vCloud Availability Access
7. vCloud Availability 3.0 Blog Series: Cloud Access, Ownership, and Visibility
Additional Resources
- Download vCloud Availability 3.0 here: https://my.vmware.com/en/web/vmware/info/slug/datacenter_cloud_infrastructure/vmware_vcloud_availability/3_0_1
- Release notes: https://docs.vmware.com/en/VMware-vCloud-Availability/3.0.1/rn/VMware-vCloud-Availability-301-Release-Notes.html
- Documentation: https://docs.vmware.com/en/VMware-vCloud-Availability/
- API reference: https://code.vmware.com/apis/441
- Rerefence architecture: https://cloudsolutions.vmware.com/reference-architectures/vcloud-availability-3-0-deployment-reference-architecture
