-
Overview
- Google Cloud provides health checking mechanisms that determine if backends, such as instance groups and zonal network endpoint groups (NEGs), properly respond to traffic
- Google Cloud offers global health checks with application-based autohealing for managed instance groups
- Google Cloud provides global and regional health check systems that connect to backends on a configurable, periodic basis
- Each connection attempt is called a probe, and each health check system is called a prober
- Google Cloud records the success or failure of each probe
- Health checks and load balancers work together
- Based on a configurable number of sequential successful or failed probes, Google Cloud computes an overall health state for each backend in the load balancer
- Backends that respond successfully for the configured number of times are considered healthy
- Backends that fail to respond successfully for a separate number of times are unhealthy
- Google Cloud uses the overall health state of each backend to determine its eligibility for receiving new requests or connections
- In addition to being able to configure probe frequency and health state thresholds, users can configure the criteria that define a successful probe
- Google Cloud uses special routes not defined in the Virtual Private Cloud (VPC) network for health checks
-
Health check categories, protocols, and ports
- Google Cloud organizes health checks by category and protocol
- Each category of health check supports a different set of protocols and a means for specifying the port used for health checking
- The protocol and port determine how Google Cloud health check systems contact backends
- Users can create a health check that uses the HTTP protocol on TCP port 80, or create a health check that uses the TCP protocol for a named port configured on an instance group
- Most Google Cloud load balancers require non-legacy health checks, but Network Load Balancing requires legacy health checks that use the HTTP protocol
- A legacy health check cannot be converted to a health check, nor a health check converted to a legacy health check.
-
Selecting a health check
- Health checks must be compatible with the type of load balancer and the types of backends (instance groups or zonal NEGs) that it uses
-
The three factors that must be specified when creating a health check are
- Category: health check or legacy health check, which must be compatible with the load balancer
- Protocol: defines what protocol the Google Cloud systems use to periodically probe your backends
- Port specification: defines which ports are used for the health check's protocol
-
Category and protocol
- The type of load balancer and the types of backends that the load balancer uses determine the health check's category
- Network Load Balancing requires legacy health checks that use the HTTP protocol
- All other load balancer types use regular health check
- Select a protocol from the list of protocols supported by the health check's category
- It's a best practice to use the same protocol as the load balancer; however, this is not a requirement, nor is it always possible
- Network load balancers require legacy health checks, and they require that the legacy health checks use the HTTP protocol, despite the fact that Network Load Balancing supports TCP and UDP in general
- For network load balancers, users must run an HTTP server on their virtual machine (VM) instances so that they can respond to health check probes
-
Category and port specification
- In addition to a protocol, users must select a port specification for the health check
- Health checks provide three port specification methods, and legacy health checks provide one method
- Not all port specification methods are applicable to each type of load balancer
- The type of load balancer and the types of backends that the load balancer uses determine which port specification method should be used