Note: This page describes how to configure a specific load balancer component orfeature before or after you've already created a load balancer. Working withspecific components is useful for advanced configurations and necessary for someconfiguration options. Before using the information on this page, know thetypeof Google Cloud load balancerthat you need.

Connection draining is a process that ensures that existing, in-progressrequests are given time to complete when a virtual machine (VM) instance isremoved from an instance group or when an endpoint is removed from networkendpoint groups (NEGs) that are zonal in scope.

The information on this page applies only to instance groups and thefollowing types of NEGs that are zonal in scope:

• Zonal NEG
• Hybrid connectivity NEG

Connection draining begins whenever you do the following:

• You manuallyremove a VM from an instancegroup.
• You remove an instance from a managed instance group by performing aresize(),deleteInstances(),recreateInstances(),orabandonInstances()call.
• You remove a Dynamic NIC from a VM that is part of an instancegroup backend.
• Youremove an instance group or NEG from a backendservice. Thisisn't supported for internal passthrough Network Load Balancers and external passthrough Network Load Balancers.
• Google Cloud deletes an instance as part ofautoscaling.
• You perform an update to the managed instance group using theManaged Instance Group Updater.
• You manuallyremove an endpoint from a zonalNEG.

Connection draining doesn't apply when you disconnect a backend (instance groupor zonal NEG) from a load balancer's backend service.

How connection draining works

To enable connection draining, you set aconnection draining timeout on thebackend service. The timeout duration must be from 0 to 3600 seconds, inclusive.

It can take up to 60 seconds after your specified timeout duration has passedfor the instance to be terminated.

The following is a list of specifications about connection draining:

• Connection draining is available for backend services that are part of thefollowing load balancers:

  • External Application Load Balancer
  • Internal Application Load Balancer
  • External proxy Network Load Balancer
  • Internal proxy Network Load Balancer
  • Internal passthrough Network Load Balancer
  • Backend service-based External passthrough Network Load Balancer

  Both internal passthrough Network Load Balancers and external passthrough Network Load Balancers support connection draining for TCP,UDP, and other non-TCP protocols.

• Connection draining is also available for backend services that are part ofCloud Service Mesh deployments.

• When a connection draining timeout is set, and an instance is removed from theinstance group or an endpoint is removed from a zonal NEG,Google Cloud load balancers and Cloud Service Mesh behave in thefollowing way:

  • No new connections are sent to the removed instance or endpoint.

  • Application Load Balancers: For the specified duration of the timeout,existing requests to the VM or endpoint marked for removal are given timeto complete. The load balancer doesn't send new connections to this VM orendpoint. After the timeout duration is reached, the load balancer stopssending all traffic to the removed VM or endpoint.

  • Proxy Network Load Balancers: For the specified duration of the timeout,existing TCP connections to the VM or endpoint marked for removalcontinue to work during the configured connection draining period. The loadbalancer doesn't send new connections to this VM or endpoint. After thetimeout duration is reached, existing TCP connections to the removed VM orendpoint remain active and the proxy closes all existing TCP connectionswithin 10 minutes, the default idle timeout.

  • passthrough Network Load Balancers: For the specified duration of the connection drainingtimeout, packets belonging to existing connections are routed to the VM orendpoint marked for removal. After the timeout duration is reached, theconntrack entry for the removed VM or endpoint is removed. Any non-SYNpacket from an existing connection leads to the creation of a new conntrackentry for the healthy backend. When the packet goes to a new healthybackend, the backend sends a RST to the client as it doesn't have any recordof the packet it has just received. The internal and external passthrough Network Load Balancersthemselves don't send a TCP-RST or TCP-FIN to end existing connections afterthe connection draining timeout expires.

• If you enable connection draining on multiple backend services that share thesame instance groups or NEGs, the largest timeout value is used. For example,suppose that the same instance group or zonal NEG is a backend for two backendservices, where one backend service has a connection draining timeout of 100seconds, and the other backend service has a connection draining timeout of200 seconds. Google Cloud uses 200 seconds as the effective connectiondraining timeout before terminating them. If the backend is a managed instancegroup, operations that delete the instance are delayed by at least 200seconds.

• If you don't set a connection draining timeout, or if the connection drainingtimeout is set to zero (0), Google Cloud ends existing connections onthe removed instance or endpoint as quickly as possible.

• If you're using connection pooling, you might see that new requests, usinga previously established connection, are still being received on VMs thatare getting drained, causing connection errors when those VMs are eventuallydeleted.

Enable connection draining

To enable connection draining, complete the following steps.

What's next

For general information on backend services, seeBackendservices overview.