Zonal affinity for internal passthrough Network Load Balancers

Zonal affinity, configured on the backend service of the load balancer, lets you limit cross-zone traffic, reduce latency, and improve performance, all while maintaining the benefits of a multi-zonal architecture.

Internal passthrough Network Load Balancers support three zonal affinity options that offer varying degrees of preference for routing new connections to eligible backends that are in the same zone as a supported client. Zonal affinity modifies the set of eligible backends after the load balancer selects an eligible backend for a new connection. Established connections in the load balancer's connection tracking table aren't affected by zonal affinity.

Compatibility

Zonal affinity is compatible with internal passthrough Network Load Balancers that:

• Are next hops for static routes or next hops for policy-based routes
• Have a failover policy

Zonal affinity is incompatible with internal passthrough Network Load Balancers that:

• Have backend subsetting enabled
• Are collector destinations for Packet Mirroring
• Are used to provide a Private Service Connect published service. Zonal affinity is only possible for compatible clients that send packets to the load balancer, not to a Private Service Connect endpoint whose published service producer uses an internal passthrough Network Load Balancer.

Compatible clients

Zonal affinity is possible only for VM clients that are located in the same region as the load balancer. Zonal affinity isn't compatible with the following clients, which always operate as if zonal affinity is disabled:

• Client Cloud VPN tunnels and client Cloud Interconnect VLAN attachments: Cloud VPN tunnels and Cloud Interconnect VLAN attachments are regional resources, not zonal resources. Packets routed through a Cloud VPN tunnel or VLAN attachment never support zonal affinity, regardless of whether they are in the same region as the load balancer or not.

• Client VMs in regions that don't match the load balancer's region: an internal passthrough Network Load Balancer located in one region is reachable by clients in all other regions if global access is enabled. When client VMs are in a region that's different from the load balancer's region, client VMs never share a common zone with any of the load balancer's backends.

Zonal match

A zonal match describes the conditions under which zonal affinity is triggered. The load balancer might then modify the original set of eligible backends to provide the configured zonal affinity. The modification of the original set of eligible backends takes place after the Identify eligible backends step in the Backend selection and connection tracking process.

In order for the zonal affinity logic to be triggered, the following sequence of events must occur:

1. Zonal affinity must be enabled

   If zonal affinity is enabled, you need to determine whether the client is a compatible client.

2. Determine whether the client is a compatible client

   If the client is compatible, determine whether a zonal match can occur.

3. Determine whether a zonal match can occur

   A zonal match means that the client VM is in a zone that contains at least one configured backend of the relevant type. The different backends that can be configured are outlined in the Zonal match conditions section.

   A zonal match is never possible if either of the following is true:

   • Zonal affinity is disabled
   • The client isn't a compatible client

4. Apply the zonal affinity logic

   If a zonal match occurs, apply the zonal affinity logic depending on the zonal affinity option that is configured. The options that enable zonal affinity are as follows:

   • ZONAL_AFFINITY_STAY_WITHIN_ZONE
   • ZONAL_AFFINITY_SPILL_CROSS_ZONE with a spillover ratio of 0
   • ZONAL_AFFINITY_SPILL_CROSS_ZONE with a nonzero spillover ratio

   After a zonal match occurs and depending on the type of zonal affinity option that is configured, the original set of eligible backends might be refined, replaced, or left unchanged. Any new connections from the client are routed to this modified set of eligible backends.

Zonal match conditions

The following table determines whether the load balancer can restrict traffic to the client's zone. If the condition in the third column isn't met, zonal affinity is ignored, and new connections are routed to any eligible backend.

Zonal match example

Consider the following situation to determine whether there is a zonal match:

• Failover policy is configured
• Zonal affinity is enabled
• Client is in zone A
• Primary backends are only in zone B and zone C
• There are no primary backends in zone A

Now even if zonal affinity is enabled and there is a compatible client, no zonal match occurs because there's no primary backend in zone A, which is the client VM's zone. Therefore, zonal affinity is ignored.

Zonal affinity options

Internal passthrough Network Load Balancers support the following zonal affinity options:

• ZONAL_AFFINITY_DISABLED (default): zonal affinity is disabled. The load balancer selects an eligible backend for a new connection without modifying the set of eligible backends.

• ZONAL_AFFINITY_STAY_WITHIN_ZONE: zonal affinity is enabled. When a zonal match occurs, the load balancer keeps traffic in the client's zone by either refining the original set of eligible backends, or replacing the original set of eligible backends with a new set. For details about this option, see How ZONAL_AFFINITY_STAY_WITHIN_ZONE works.

• ZONAL_AFFINITY_SPILL_CROSS_ZONE: zonal affinity is enabled. When a zonal match occurs, the load balancer might refine the set of eligible backends or it might leave the original set of eligible backends unchanged. This option allows traffic to spill over to other zones if not enough healthy backends are in the client's zone. The spill over is controlled by the spillover ratio. For more information about this option, see How ZONAL_AFFINITY_SPILL_CROSS_ZONE and spillover ratio work.

To learn how to configure zonal affinity on the backend service of an internal passthrough Network Load Balancer, see Use zonal affinity.

How ZONAL_AFFINITY_STAY_WITHIN_ZONE works

If zonal affinity is set to ZONAL_AFFINITY_STAY_WITHIN_ZONE, and a zonal match occurs, the load balancer keeps traffic in the client's zone by doing one of the following:

• Refine the original set of eligible backends

  If at least one eligible backend is in the client's zone, the load balancer refines the set of eligible backends by doing the following:

  • Discarding all eligible backends that are not in the client's zone
  • Using only eligible backends that are in the client's zone

  The refined set of eligible backends is a subset of the original set of eligible backends.

• Replace the original set of eligible backends

  If there are no eligible backends in the client's zone, other configured backends (not in the set of eligible backends) are present in the client's zone because a zonal match did occur for zonal affinity to be triggered. In this situation, the load balancer replaces the set of eligible backends with a new set that includes unhealthy backends within the client's zone, based on whether a failover policy is configured, and, if so, the failover state.

  This new set of replaced eligible backends consists of one of the following:

  • If a failover policy isn't configured, the replacement set of eligible backends consists of all unhealthy backends in the client's zone.

  • If a failover policy is configured and the original eligible backends were primary backends, the replacement set of eligible backends consists of all unhealthy primary backends in the client's zone.

  • If a failover policy is configured and the original eligible backends were failover backends, the replacement set of eligible backends consists of all unhealthy failover backends in the client's zone.

The following table summarizes all refinement and replacement scenarios for the ZONAL_AFFINITY_STAY_WITHIN_ZONE option:

It is important to note the following for the ZONAL_AFFINITY_STAY_WITHIN_ZONE option:

• This zonal affinity option never leaves the original set of eligible backends unchanged.
• This zonal affinity option favors backends in the client's zone even if it means using unhealthy backends, assuming a zonal match condition is met.

How ZONAL_AFFINITY_SPILL_CROSS_ZONE and spillover ratio work

If zonal affinity is set to ZONAL_AFFINITY_SPILL_CROSS_ZONE and a zonal match occurs, the set of eligible backends for the client might be refined or it might also result in no change to the set of eligible backends.

In the case where the original set of eligible backends remain unchanged, new connections might be sent to eligible backends in the client's zone, or they might spill over to eligible backends in other zones. This distribution depends on a configurable spillover ratio that determines when traffic starts spilling over to eligible backends in other zones.

A configurable spillover ratio indicates the threshold value for keeping traffic in the client's zone. If the proportion of healthy and eligible backends falls below the defined spillover ratio, all new connections from clients in the zone are distributed to eligible backends in other zones. The value of the spillover ratio can range from 0.0 to 1.0, inclusive.

If you don't specify a spillover ratio when configuring ZONAL_AFFINITY_SPILL_CROSS_ZONE zonal affinity, Google Cloud uses a default value of 0.0.

Zero spillover ratio

If the configured spillover ratio is 0.0, the load balancer refines the set of eligible backends by discarding all eligible backends that are not in the client's zone, provided that one of the following is true:

• If a failover policy isn't configured, eligible backends are all healthy backends, and at least one eligible backend is in the client's zone
• If a failover policy is configured, eligible backends are all healthy primary backends, and at least one eligible backend is in the client's zone
• If a failover policy is configured, eligible backends are all healthy failover backends, and at least one eligible backend is in the client's zone

If there are no eligible backends in the client's zone:

• The load balancer keeps the original set of eligible backends
• New connections are allowed to spill over to eligible backends in other zones

The following table summarizes all refinement scenarios for the ZONAL_AFFINITY_SPILL_CROSS_ZONE option when the configured spillover ratio is 0.0:

Nonzero spillover ratio

If the configured spillover ratio is greater than 0.0 but less than or equal to 1.0, the load balancer first calculates one of the following ratios:

• If a failover policy isn't configured, the calculated ratio is the number of eligible and healthy backends in the client's zone divided by the number of configured backends in the client's zone.

  $$ \frac{\text{count}(\text{Eligible and healthy backends})_{\text{Client's zone}}}{\text{count}(\text{Configured backends})_{\text{Client's zone}}} $$

• If a failover policy is configured and all eligible backends are primary backends, the calculated ratio is the number of eligible and healthy backends in the client's zone divided by the number of configured primary backends in the client's zone.

  $$ \frac{\text{count}(\text{Eligible and healthy primary backends})_{\text{Client's zone}}}{\text{count}(\text{Configured primary backends})_{\text{Client's zone}}} $$

• If a failover policy is configured and all eligible backends are failover backends, the calculated ratio is the number of eligible and healthy backends in the client's zone divided by the number of configured failover backends in the client's zone.

  $$ \frac{\text{count}(\text{Eligible and healthy failover backends})_{\text{Client's zone}}}{\text{count}(\text{Configured failover backends})_{\text{Client's zone}}} $$

The load balancer then compares the calculated ratio to the spillover ratio. If the calculated ratio is greater than or equal to the spillover ratio, the load balancer refines the set of eligible backends by discarding all eligible backends that are not in the client's zone. Otherwise, the load balancer uses the original eligible backends.

When computing the calculated ratio, remember the following:

• Eligible backends might be all healthy backends, all backends, all healthy primary backends, all healthy failover backends, or all primary backends.

• Except when eligible backends consist of either all backends or all primary backends, the set of configured backends, configured primary backends, or configured failover backends contains more than just eligible backends.

• A spillover ratio of 1.0 indicates that one of the following is true:

  • If a failover policy isn't configured, the set of eligible backends must be all healthy backends, and the number of eligible backends in the client's zone must equal the number of configured backends in the client's zone.

  • If a failover policy is configured and all eligible backends are primary backends, the set of eligible backends must contain all healthy primary backends, and the number of eligible backends in the client's zone must equal the number of configured primary backends in the client's zone.

  • If a failover policy is configured and all eligible backends are failover backends, the set of eligible backends must contain all healthy failover backends, and the number of eligible backends in the client's zone must equal the number of configured failover backends in the client's zone.

The following table summarizes all refinement scenarios for the ZONAL_AFFINITY_SPILL_CROSS_ZONE option when the configured spillover ratio isn't 0.0:

Spillover ratio examples

The following examples show how ZONAL_AFFINITY_SPILL_CROSS_ZONE works when there's no failover policy configured.

• For zonal affinity to apply when you configure a spillover ratio of 1.0, the following needs to be true:

  • The set of eligible backends must be all healthy backends.
  • The number of healthy eligible backends in the client's zone must equal the number of configured backends in the client's zone.

  A spillover ratio of 1.0 indicates that 100% of the eligible backends in the client's zone need to be healthy for all new connections to be distributed to backends in the client's zone only. Even if one backend becomes unhealthy, the load balancer distributes some new connections to backends in other zones.

• For zonal affinity to apply when you configure a spillover ratio of 0.8, the following needs to be true:

  • The set of eligible backends must be all healthy backends.
  • The number of healthy eligible backends in the client's zone divided by the number of configured backends in the client's zone must be at least 0.8.

  A spillover ratio of 0.8 indicates that at least 80% of the eligible backends in the client's zone need to be healthy for all new connections to be distributed to backends in the client's zone only. If less than 80% of the backends in the client's zone are healthy, the load balancer distributes some new connections to backends in other zones.

• For zonal affinity to apply when you configure a spillover ratio of 0.0, the following needs to be true:

  • The set of eligible backends must be all healthy backends.
  • At least one healthy eligible backend must exist in the client's zone.

  A spillover ratio of 0.0 means that as long as there is at least one healthy backend in the client's zone, all new connections are distributed to backends in the client's zone. If the spillover ratio is 0.0 and there is no healthy backend in the client's zone, the load balancer distributes all new connections to healthy backends in zones other than the client's zone.

The following diagram shows a spillover ratio of 0.8:

• Zones 1 and 2 each contain five configured backends.

• The original set of eligible backends consists of eight out of the ten configured backends:

  • All five configured backends in zone 1 are healthy.

  • Three configured backends in zone 2 are healthy.

For a compatible client that is in zone 1:

• A zonal match happens because there exists at least one configured backend in zone 1.

• The ratio of healthy eligible backends in zone 1 to all configured backends in zone 1 is 5/5 = 1.0.

• For the compatible client in zone 1: because the calculated ratio of 1.0 is greater than the spillover ratio of 0.8, the load balancer refines the set of eligible backends by discarding all eligible backends that aren't in zone 1. Consequently, new connections from the compatible client in zone 1 are distributed exclusively among the five healthy eligible backends in zone 1.

For a compatible client that is in zone 2:

• A zonal match happens because there exists at least one configured backend in zone 2.

• The ratio of healthy eligible backends in zone 2 to all configured backends in zone 2 is 3/5 = 0.6.

• For the compatible client in zone 2: because the calculated ratio of 0.6 isn't greater than or equal to the spillover ratio of 0.8, the load balancer makes no changes to the set of eligible backends. Consequently, new connections from the compatible client in zone 2 are distributed among the original set of eight healthy eligible backends (five in zone 1 and three in zone 2).

What's next

• To configure Cloud Monitoring for internal passthrough Network Load Balancers, see Internal passthrough Network Load Balancer logging and monitoring.
• To troubleshoot issues with your internal passthrough Network Load Balancer, see Troubleshoot internal passthrough Network Load Balancers.