The vCloud Director Multisite feature enables a service provider or other institutional owner of multiple, geographically-distributed vCloud Director installations (server groups) to manage and monitor those installations and their organizations as single entities.
When you associate two vCloud Director sites, you enable administration of the sites as a single entity. You also enable organizations at those sites to form associations with each other. When an organization is a member of an association, organization users can use the vCloud Director Tenant Portal to access organization assets at any member site, although each member organization and its assets are local to the site it occupies. The vCloud Director Web Console cannot be used to access resources at a remote association member.
A site or organization can form an unlimited number of associations with a peer, but each association includes exactly two members. Each site or organization must have its own private key. Association members establish a trust relationship by exchanging public keys, which are used to verify signed requests from one member to another.
Each site in an association is defined by the scope of a vCloud Director server group (a group of servers that share a vCloud Director database). Each organization in an association occupies a single site. The organization administrator controls access by organization users and groups to assets at each member site.
The installation or upgrade process creates a Site object that represents the local vCloud Director server group. A system administrator whose authority extends to more than one vCloud Director server group can configure those server groups as an association of vCloud Director sites.
Each Site object is created with a name attribute that is a UUID.
GET https://Site-B.example.com/api/site ... <Site name="b5920690-fe13-4c31-8e23-9e86005e7a7b" ...> ... <RestEndpoint>https://Site-A.example.com/api/org/Org-A</RestEndpoint> <RestEndpointCertificate>-----BEGIN CERTIFICATE----- MIIDDTCCAfWgAwIBAgI...Ix0eSE= -----END CERTIFICATE----- </RestEndpointCertificate> ... </Site>
While there's no requirement that the site name match the hostname in the API endpoint, a system administrator can update the site name as an administrative convenience for vCloud API users, with a request like this one:
PUT https://Site-B.example.com/api/site content-type: application/vnd.vmware.admin.site.xml ... <Site name="Site-B" ...> ... <RestEndpoint>https://Site-A.example.com/api/org/Org-A</RestEndpoint> <RestEndpointCertificate>-----BEGIN CERTIFICATE----- MIIDDTCCAfWgAwIBAgI...Ix0eSE= -----END CERTIFICATE----- </RestEndpointCertificate> ... </Site>
The Site element in the request body must retain the formatting in which it was returned by the GET .../site request. Additional characters, particularly carriage-returns, line feeds, or spaces, before or after the certificates can cause the system to return a bad request exception.
After site association is complete, organization administrators at any member site can begin associating their organizations.
When you make a login request to an organization that is a member of an association, you can specify an additional value, multisite=global, in the Accept header to have the login request authenticate you at all other association members.
Accept: application/*;version=29.0;multisite=global
This value is recognized for requests specifying API version 29 and later. Unless you include this value in the in the Accept header, the login request authenticates you only to the organization that is the target of the request.
When you include multisite=global in the Accept header of a login request, the response includes an x-vcloud-authorization header with comma-separated values, one for each association members. Use this header, including all the values, when making API requests to any association member. See Create a vCloud API Session for more information about logging in to the vCloud API.
The Session object returned from a login request includes an AuthorizedLocations element that provides vCloud API connection endpoints for other sites that are associated with this one and the vCloud Director Tenant Portal connection endpoint for any organizations at those sites that are associated with the local organization association member. In this example:
■
| |
■
|
An organization named Org-A that occupies Site-A is associated with an organization named Org-B that occupies Site-B. |
■
|
POST https://Site-A.example.com/api/sessions Authorization: Basic ... Accept: application/*;version=29.0;multisite=global ...
200 OK x-vcloud-authorization: 1f89....dc2b1,d54c....a99ac Content-Type: application/vnd.vmware.vcloud.session+xml;version=29.0;multisite=global ... <Session ...> ... <AuthorizedLocations> <Locations> <LocationName>Site-B</LocationName> <RestApiEndpoint>https://Site-B.example.com/api</RestApiEndpoint> <UIEndpoint>https://Site-B.example.com/tenant/Org-B/compute</UIEndpoint> <UseMultisiteToken>true</UseMultisiteToken> </Locations> </AuthorizedLocations> </Session>
Associations of sites and organizations must agree to use the same identity provider (IDP). User and group identities for all organizations in the association must be managed through this IDP.
With the exception of the System organization, which must use the vCloud Director integrated IDP, association members are free to choose the IDP that works best for them. See About Federation and Single Sign-On for more information about the IDPs that vCloud Director supports.
Organization administrators can configure their IDP to generate user or group access tokens that are valid at all member sites, or valid at only a subset of member sites. Note that while user and group identities must be the same in all member organizations, user and group rights are constrained by the roles those users and groups are assigned in each member organization. Assignment of a role to a user or group is local to a member organization, as are any custom roles you create.
Effective implementation of a Multisite deployment requires you to configure a load balancer that distributes requests arriving at an institutional endpoint such as https://vcloud.example.com to the endpoints for each member of the site association (for example, https://us.vcloud.example.com and https://uk.vcloud.example.com). Unless a site has only a single cell, it must also configure a load balancer that distributes incoming requests across all of its cells, so that a request to https://us.vcloud.example.com can be handled by https://cell1.us.vcloud.example.com , https://cell2.us.vcloud.example.com , and so on.
After you have created a site association, the system periodically retrieves the status of the remote site and updates that status in the local site's vCloud Director database. This so-called heartbeat process runs with the identity of the Multisite system user, a local vCloud Director user account created in the System organization during vCloud Director installation. Although this account is a member of the System organization, it does not have system administrator rights. It has only a single right, Multisite: System Operations, which gives it permission to make a vCloud API request that retrieves the status of the remote member of a site association.