Pivotal Cloud Foundry v1.9

Configuring Load Balancer Healthchecks for Cloud Foundry Routers

Page last updated:

This topic describes how to configure load balancer healthchecks for Cloud Foundry (CF) routers to ensure that the load balancer only forwards requests to healthy router instances. You can also configure a healthcheck for your HAProxy if your deployment uses the HAProxy component.

In environments that require high availability, operators must configure their own redundant load balancer to forward traffic directly to the CF routers. In environments that do not require high availability, operators can skip the load balancer and configure DNS to resolve the CF domains directly to a single instance of a router.

Add Healthcheck Endpoints for CF Routers

Configure your load balancer to use the following HTTP healthcheck endpoints. Add the IP addresses of all router instances along with their corresponding port and path.

  • HTTP Router (Gorouter): http://GOROUTER_IP:8080/health
  • TCP Router: http://TCP_ROUTER_IP:80/health

The configuration above assumes the default healthcheck ports for the CF routers. To modify these ports, see the sections below.

Set the Gorouter Healthcheck Port

You can set the healthcheck port for the Gorouter in the cf-release manifest using the router.status.port property. Defaults to 8080.

Set the TCP Router Healthcheck Port

You can set the healthcheck port for the TCP Router in the routing-release manifest using the tcp_router.health_check_port property. Defaults to 80.

Note: This property does not affect the healthcheck of the HAProxy deployed with cf-release.

Add a Healthcheck Endpoint for HAProxy

Configure your load balancer to use the following HTTP healthcheck endpoint: http://HAPROXY_IP:8080/health.

The HAProxy included in cf-release is a legacy, optional component. Formerly, HAProxy handled TLS termination of HTTP requests, but Gorouter can now perform this termination. To make HAProxy highly available requires another load balancer in front of it, defeating the purpose. In environments where high availability is not required, DNS can resolve CF domains directly to single instances of the CF routers.

Set the Healthy and Unhealthy Threshold Properties for the Gorouter

To maintain high availability during upgrades to the HTTP router, each router is upgraded on a rolling basis. In a highly available environment with multiple routers, during upgrade, a router is shutdown, upgraded, and restarted before another router is upgraded. This ensures that any pending HTTP request passed to the router are handled correctly.

Elastic Runtime uses the following properties:

  • Unhealthy Threshold: Specifies the amount of time, in seconds, that the Router will continue to accept connections before shutting down. During this period the healthcheck will report unhealthy to cause load balancers to fail over to other Routers. This value should be greater than or equal to the max time it could take your load balancer to consider a Router instance unhealthy, given contiguous failed healthchecks.

  • Healthy Threshold: Specifies the amount of time, in seconds, to wait until declaring the router instance started. This allows an external load balancer time to register the instance as healthy.

These properties are available from the Settings > Network tab.

To understand how to set these properties and why they are useful, it is important to understand the behavior of the load balancer health checks when a router is shut down and restarted.

Lb health check

Step Description
1 A shutdown request is sent to the router.
2 The router receives shutdown request, which causes the following:
  • The router begins sending Service Unavailable responses to the load balancer health checks.
  • The load balancer continues sending HTTP request to the router
3 The load balancer considers the router to be in an unhealthy state, which causes the load balancer to stop sending HTTP requests to the router.

The time between step 2 and 3 is defined by the values of the health check interval and threshold configured on the load balancer.

4 The router shuts down.

The interval between step 2 and 4 is defined by the Unhealthy Threshold property of the Gorouter. In general, the value of this property should be longer than the value of the interval and threshold values (interval x threshold) of the load balancer. This additional interval ensures that any remaining HTTP requests are handled before the router shuts down.

5 If the router shutdown is intitiated by an upgrade, the Gorouter software is upgraded.
6 The router restarts.
7 The routers begins returning Service Available responses to the load balancer health check.
8 The load balancer considers the router to be in a healthy state. The time between step 7 and 8 is specified by the health check interval and threshold configured for your load balancer (health check threshold x health check interval).
9 Shutdown and upgrade of the other router begins.
Was this helpful?
What can we do to improve?
View the source for this page in GitHub