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.
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):
- TCP Router:
The configuration above assumes the default healthcheck ports for the CF routers. To modify these ports, see the sections below.
You can set the healthcheck port for the Gorouter in the cf-release manifest using the
router.status.port property. The value of this property defaults to
You can set the healthcheck port for the TCP Router in the routing-release manifest using the
tcp_router.health_check_port property. The value of this property defaults to
Note: This property does not affect the healthcheck of the HAProxy deployed with cf-release.
If you have deployed one or more instances of HAProxy between your infrastructure load balancer and Gorouters, configure your infrastructure load balancer to use the following HTTP healthcheck endpoint:
The HAProxy is an optional component that provides some features that Gorouter does not and can be helpful for demonstrating horizontal scalability of the CF routers in environments where an infrastructure load balancer is not available.
To maintain high availability during upgrades to the HTTP router, each router is upgraded on a rolling basis. During upgrade of a highly available environment with multiple routers, each router is shutdown, upgraded, and restarted before the next router is upgraded. This ensures that any pending HTTP request passed to the HTTP router are handled correctly.
Cloud Foundry uses the following properties:
router.drain_wait: Specifies, in seconds, the
unhealthy threshold that determines when the Gorouter stops accepting connections and the process gracefully stops. During this period, the Gorouter continues to serve HTTP requests and the health check endpoint returns
router.load_balancer_healthy_threshold: Specifies the amount of time, in seconds, the load balancer waits until declaring the Gorouter instance
started. This enables the load balancer time to register the instance as
The image and table below describe the behavior of the load balancer health checks when a router shuts down and is restarted.
|1||A shutdown request is sent to the router.|
|2||The router receives shutdown request, which causes the following:
|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
|5||If the router shutdown is initiated by an upgrade, the Gorouter software is upgraded.|
|6||The router restarts. The router will return Service Unavailable responses for load balancer health checks for 20 seconds; during this time the routing table is preloaded.|
|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.|