Global DNS Load Balancers for Multi-Foundation Environments
Page last updated:
This topic describes global DNS load balancers (GLBs) for multi-foundation environments. This topic also describes concepts such as foundation affinity and healthchecks.
Note: If you want to configure a load balancer dedicated to one Pivotal Platform foundation and you are using an F5 LTM, see Configuring an F5 Load Balancer for PAS.
Multi-foundation environments are multiple instances of BOSH and Ops Manager that can communicate with each other. Each foundation can use different infrastructures to fit your preferences.
Multi-foundation environments are commonly deployed in an active-active or active-passive pattern. See below for descriptions of each term:
|Active-active pattern||Instances of apps run on two foundations and they are both in use.|
|Active-passive pattern||Instances of apps run on two foundations, but the instances may only be active on one foundation. The other foundation becomes active only in the event of a failover.|
The typical setup for foundation failover requires the GLB be authoritative for a wildcard app domain. The wildcard app domain is not the same domain as the foundation-default app domain.
To configure your GLB:
Find and record your wildcard app domain. For Pivotal Application Service (PAS), your wildcard app domain is typically the Apps domain you configure in the Domains pane of the PAS tile. For more information, see the Configure Domains section of the Configuring PAS topic.
Add the domain you recorded to both Pivotal Platform foundations using a shared domain. You can create a shared domain using the Cloud Foundry Command Line Interface (cf CLI). For more information about the cf CLI command to create shared domains, see create-shared-domain in the cf CLI reference guide.
To support failover, set the time-to-live (TTL) in the wildcard DNS record. Set the TTL to about 30 to 180 seconds. When determining your TTL, consider the tradeoff between the app performance impact and the resulting time for failover to occur.
Foundation affinity occurs when the GLB favors one foundation over another during a route request. For example, users experience less latency if they are routed to a foundation that is geographically closer, so the GLB may favor that foundation.
Different GLBs have their own mechanisms to achieve this. See the following table for common concepts:
|Foundation Affinity Concepts|
|Topology/geographically-based affinity||The GLB attempts to direct traffic to the graphically nearest foundation based on IP geolocation or provided topology for private networks of the LDNS server performing the lookup.|
|Static-persist/member-hashing affinity||The GLB attempts to direct traffic to the graphically nearest foundation based on IP geolocation or provided topology for private networks of the LDNS server performing the lookup.|
|Active/passive foundations||If one foundation is usually idle, you can always pick the active foundation IP as long as it remains available.|
For microservice apps, you typically use a Services Registry to manage traffic between microservices. There are two ways to do this:
Healthchecks determine whether a foundation for an app is healthy or not.
See the following table for the levels at which you can check the health of your foundation:
|Foundation||GLB relies on a local load balancer in front of the Pivotal Platform Gorouters to determine the overall health of the foundation. GLB can perform healthchecks on TCP port 443 or 80 or on the local load balancer. The local load balancer healthchecks the back end pool of Gorouters on port 8080.|
|App||Healthchecks are set only for apps which have instances on both foundations. Each app instance has canary DNS records. The canary DNS records are the same for the app instances on each foundation. You would also need to add more VIPs dedicated to these canary apps that would be used to check their health.|
Warning: Pivotal does not recommend setting healthchecks at the app level. Configuring healthchecks in this way can cause more frequent failover and delays while pushing apps. Complete failover of a foundation affects all apps on the platform. Healthchecks on a per-app basis can require additional overhead beyond the control of an app developer.