Global DNS Load Balancers for Multi-Foundation Environments

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 PCF foundation and you are using an F5 LTM, see Configuring an F5 Load Balancer for PAS.

About Multi-Foundation Environments

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:

Term Description
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.

Configure Your GLB

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, do the following:

  • 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.

  • Add the domain you recorded to both PCF 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.

About Foundation Affinity

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
Term Description
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.
Microservice-to-microservice affinity For microservice apps, you typically use a Services Registry to manage traffic between microservices. There are two ways to do this:
  • If the microservices are using the domain which maps to the GLB, then their traffic is routed through the GLB.
  • If the microservices are communicating using IP address or internal domains, such as when using Envoy, then the traffic does not pass through the GLB.

About Healthchecks

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:

Level Description
Foundation GLB relies on a local load balancer in front of the PCF 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 backend 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.

Create a pull request or raise an issue on the source for this page in GitHub