An alternative to the traffic-based load sharing model uses intelligent DNS resolution to distribute connections across multiple vCloud Director instances. In the previous section, connections to the “portal.cloud.example.com” URL only reached the redirection server as a result of a DNS query/resolution. Typically, a DNS query will return a single IP address which will be used to connect to the target system. Some DNS queries will return multiple answers and the querying application or service will then decide how to select the one (or more) that it will use. A third category of DNS responses, mostly invisible to the user, are those which apply some form of intelligence to the response they select. This can take the form of identifying the approximate location of the user making the request, and returning the IP address of a more local server to minimize latency and maximize responsiveness. Alternatively, the intelligent DNS service might be able to interrogate each target site to identify the one currently returning the fastest responses, or the one with the lowest number of connections. Or, at its simplest level, the intelligent DNS service might only have a list of sites and cycle through them, returning each in turn in a round-robin method.

The specifics of the method used are beyond the scope of this document, but the basic principle is shown in the following figure.

 

Unless already present within the Provider environment, this approach requires the deployment of intelligent DNS applications, ideally at multiple, resilient locations. Those applications might require connectivity to each other as well as to the target sites to better coordinate their responses. This represents a potential increase in both up-front and operational expenditure. The advantage of this approach is that by its nature, DNS is a resilient, low-bandwidth application. There is no need for the relatively intensive step of establishing an SSL/TLS session only to be told the resource has moved and to repeat the process again at the chosen vCloud Director site. During the process of DNS resolution, the identity of the intelligent DNS server responsible for the “portal” FQDN is established using DNS queries. Those queries can return the details for multiple intelligent DNS servers at different provider sites, a process inherent to the operation of DNS. This makes the deployment of resilient global access more straightforward than the traffic approach in the previous section. If coordinated intelligence can be incorporated into the solution, connections can be “balanced” between the sites rather than just “shared” among them.

Unlike the traffic-based approach in the previous section, the redirection in this model takes place within the IP address resolution process of DNS. The user enters “https://portal.cloud.example.com” into their browser and, following the multistage resolution process explained earlier, connects to the IP address of the vCloud Director user interface. No HTTP redirect takes place, so the client expects to see an SSL certificate that is valid for the “portal” FQDN. However, if each site can also receive connections to its http://Site-X.cloud.example.com/” URL directly, without raising a security warning in the user’s browser, the SSL certificate associated with the site will need to be valid for the site-specific FQDN too.

There are two common methods for making sure that an SSL certificate is valid for both access routes. The first is to use a “wildcard” to match any value in the left-hand position in the FQDN. In this example, each vCloud Director instance has an SSL certificate matching “*.cloud.example.com“, where the asterisk would match both “portal” and the site’s “Site-X” name. The same certificate could then be deployed in all three sites and would be valid irrespective of whether the user entered the global “portal” URL in their browser or one of the site-specific ones. While this seems simple, many organizations are uncomfortable with wildcard certificates because there is no control over the portion of the URI in the wildcard position. If misused, or compromised, the certificate might be used to represent the company on a malicious, but apparently “secure” URI using, for example, “customer-admin.cloud.example.com” for which it would still be valid.

The second method is to include more than one valid name within the certificate. Using the Subject Alternative Name (SAN) field, a certificate can contain multiple FQDNs that are considered valid. The disadvantage of this approach is that the individual certificates are required for each combination of names (for example “portal” / “Site-A” or “portal” / “Site-B”), but the advantage from a security perspective is that the certificate can only represent the names encoded within it, and cannot be used to represent any other company resource either accidently or maliciously. This is often preferred over the wildcard approach, but does increase the administrative effort involved. Both methods will work with vCloud Director but company security guidelines and policies must be considered before either method is selected for a production deployment.