4.3.1 Global Site Access with Traffic Load Sharing
Connections to the global URI (“portal.cloud.example.com” in this example) are delivered to the IP address resolved by a DNS query for the FQDN portion of the full tenant interface URL. After a connection is established, the terminating equipment advises the client (the user’s browser in this case) that the resource it requested has moved. The response also includes an alternate location at which the resource can now be found, and this results in the client repeating the connection process to the newly received location. The following figure illustrates this process.
Figure 23. Global Site Access Using Web Server Redirection
1. The user enters the global URL into their browser and, following DNS resolution, a connection is made to a server.
2. The server uses a standalone algorithm (random, round-robin or similar), or might use interaction with the vCloud Director sites, to determine the load at each site and then selects the site to which this connection should be sent.
3. The server issues an HTTP 3xx redirection response to the client and includes the site-specific URL of the chosen vCloud Director instance.
4. The client makes a new connection to the site contained within the redirect.
5. The selected site receives the new connection from the client and responds with the login page.
This approach has the benefit of using fairly common and well understood technology, but has the disadvantage that without additional complexity, the server providing the redirection runs in a single location. While the infrastructure providing the redirection can be made resilient, the location can form a single point of failure. It is therefore recommended that customers are provided with both the site-specific and global URLs so that in the event of a failure they can connect directly to any surviving sites.
In this model, the user’s initial connection to “https://portal.cloud.example.com/” terminates on the service which will redirect the connection to the target site. This service must contain an SSL certificate which is valid for the “portal” FQDN. When the client is told that the resource has moved and it should instead connect to the site-specific URL, its new connection will be to “https://site-X.cloud.example.org” and the service terminating the connection (typically a local load balancer in front of the vCloud Director cells) must contain an SSL certificate which is valid for the “Site-X” FQDN. If the same local load balancer is responsible for both “global” site redirection and local site termination, it must hold certificates which are valid for both FQDNs. If it presents the redirection and local site on separate IP addresses, separate SSL certificates, each valid for one of the FQDNs can be used. If the same IP address (or Virtual IP “VIP”) is used for both services, it must hold an SSL certificate that is valid for both names. See the following section for more information.
