Zonal affinity for internal passthrough Network Load Balancers

Preview

This product or feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA products and features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

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 different zonal affinity options that offer varying degrees of preference for routing new connections to eligible backends that are in the same zone as a compatible client. Note that established connections in the load balancer's connection tracking table aren't affected by zonal affinity.

Before you begin

Before enabling zonal affinity, you must understand which internal passthrough Network Load Balancer features are supported with zonal affinity.

Supported

• Next hops for static routes
• Next hops for policy-based routes
• Failover
• Symmetric hashing is supported only when both internal passthrough Network Load Balancers have zonal affinity enabled.

Unsupported

Zonal affinity is incompatible with internal passthrough Network Load Balancers that are configured with the following:

• Backend subsetting
• Collector destinations for Packet Mirroring
• Network Security Integration deployments—in-band or out-of-band. Using zonal affinity with Network Security Integration results in packet drops.
• 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 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 original 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 even if it means using unhealthy backends. 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 allows new connections to be distributed within the client's zone or spill over to other zones. 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.

Different types of backends

Zonal affinity creates a set of modified eligible backends based on the load balancer's original eligible backends and configured backends. To explain how zonal affinity performs this modification, we precisely define five different backend sets. This document references the following terms in subsequent sections as it explains how zonal affinity works.

• Input sets

  • Configured backends: the set of all backends that are a part of the load balancer's backend service. This includes all primary backends and, if the failover feature is enabled, all primary and all failover backends.

  • Original eligible backends: a subset of configured backends that are eligible to receive new connections. The set of original eligible backends is produced by the Identify eligible backends step of the backend selection and connection tracking process.

• Intermediary sets

  • Zonal match test backends: a subset of configured backends used to test for a zonal match. Both the configured backends and the original eligible backends determine which VMs are zonal match test backends.

  • Zonal matched backends: a subset of the zonal match test backends that are in the same zone as a compatible client.

• Output set

  • Modified eligible backends: depending on the type of zonal affinity configured and the spillover ratio, the modified eligible backends might be the same as the original eligible backends, a subset of the original eligible backends, or different from the original eligible backends. This set is used to provide the configured zonal affinity.

Zonal match

A zonal match describes the conditions under which zonal affinity is triggered. The load balancer might then modify the set of original eligible backends to provide the configured zonal affinity. The modification of the original eligible backends takes place after the load balancer selects an eligible backend for a new connection.

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, continue to the next step.

2. Determine whether the client is a compatible client.

   If the client is compatible, continue to the next step.

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.

Zonal match conditions

For a zonal match to happen, at least one instance or endpoint in the zonal match test backends must be in the same zone as a compatible client. Both the configured backends and the original eligible backends are inputs used to determine the zonal match test backends.

Original eligible backends	Zonal match test backends
All healthy primary backends	All configured primary backends Configured primary backends might all be healthy or a combination of healthy and unhealthy.
All healthy failover backends	All configured failover backends Configured failover backends might all be healthy or a combination of healthy and unhealthy.
All unhealthy primary backends	All configured primary backends The configured primary backends are all unhealthy by definition when the original eligible backends are all unhealthy primary backends.

Zonal match example

Consider the following setup for an internal passthrough Network Load Balancer to understand whether a zonal match occurs.

• Primary backends: Zones A and B
• Failover backends: Zones C and D
• Client VM location: Zone A
• Zonal affinity enabled
• Default failover policy is present

Scenario 1:

• Original eligible backends: All healthy primary backends (zones A and B)
• Zonal match test backends: All configured primary backends (zones A and B)
• Is there a zonal match?: Yes. In this case, the client VM is in the same zone as the zonal match test backends, so there's a zonal match.

Scenario 2:

• Original eligible backends: All healthy failover backends (zones C and D)
• Zonal match test backends: All configured failover backends (zones C and D)
• Is there a zonal match?: No. For a zonal match to occur, the client VM must be in a zone that contains at least one backend from the set of zonal match test backends. In this case, the client is in zone A, and the zonal match test backends are in zones C and D.

After a zonal match occurs, you apply the zonal affinity logic as outlined in the following sections.

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 modified eligible backends might be the same as the original eligible backends, a subset of the original eligible backends, or different from the original eligible backends.

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 distributes new connections to the modified eligible backends. The modified eligible backends might be the same as the original eligible backends, a subset of the original eligible backends, or different from the original eligible backends.

To create modified eligible backends, the load balancer uses the following process:

1. Start with the zonal match test backends identified by the zonal match condition.

2. Remove all backends that aren't in the same zone as the client. This gives us a set of zonal matched backends. This set is always non-empty because a zonal match has occurred.

3. Compute the intersection of the zonal matched backends with the original eligible backends. This intersection might be non-empty or empty.

   • If the intersection is non-empty, the modified eligible backends is the intersection set. The modified eligible backends might be the same as the original eligible backends, or the modified eligible backends might be a subset of the original eligible backends.

   • If the intersection is empty, the modified eligible backends is the zonal matched backends itself, which is always different from the original eligible backends. In this situation, all modified eligible backends are unhealthy.

The following table summarizes the process to create the set of modified eligible backends when the zonal affinity option is ZONAL_AFFINITY_STAY_WITHIN_ZONE. This zonal affinity option favors backends in the client's zone even if it means using unhealthy backends.

Original eligible backends (A)	Zonal match test backends (B)	Zonal matched backends (C)	Intersection (A∩C)	Modified eligible backends
All healthy primary backends	All configured primary backends Zonal match test backends might all be healthy or a combination of healthy and unhealthy.	All primary backends in the client's zone Zonal matched backends might all be healthy or a combination of healthy and unhealthy.	All healthy primary backends in the client's zone	Intersection not empty: The modified eligible backends are all healthy primary backends in the client's zone. The modified eligible backends might be the same as the original eligible backends or a subset of the original eligible backends. Intersection is empty: The modified eligible backends are all unhealthy primary backends in the client's zone. The modified eligible backends are the same as the zonal matched backends, which are all primary backends in the client's zone; however, all of these backends are unhealthy because the intersection with the original eligible backends is empty.
All healthy failover backends	All configured failover backends Zonal match test backends might all be healthy or a combination of healthy and unhealthy.	All failover backends in the client's zone Zonal matched backends might all be healthy or a combination of healthy and unhealthy.	All healthy failover backends in the client's zone	Intersection not empty: The modified eligible backends are all healthy failover backends in the client's zone. The modified eligible backends might be the same as the original eligible backends or a subset of the original eligible backends. Intersection is empty: The modified eligible backends are all unhealthy failover backends in the client's zone. The modified eligible backends are the same as the zonal matched backends, which are all failover backends in the client's zone; however, all of these backends are unhealthy because the intersection with the original eligible backends is empty.
All unhealthy primary backends	All configured primary backends Zonal match test backends are all unhealthy by definition when the original eligible backends are all unhealthy primary backends.	All unhealthy primary backends in the client's zone	All unhealthy primary backends in the client's zone	Intersection is always not empty: The modified eligible backends are all unhealthy primary backends in the client's zone. The modified eligible backends might be the same as the original eligible backends or a subset of the original eligible backends.

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 load balancer distributes new connections to the modified eligible backends. The modified eligible backends might be the same as the original eligible backends or a subset of the original eligible backends.

When the modified eligible backends are the same as the original eligible backends, new connections might be sent to eligible backends in the client's zone, or they might be sent to eligible backends in any zone ("spill over"). This distribution depends on a configurable spillover ratio.

A configurable spillover ratio indicates the threshold value for keeping traffic in the client's zone. 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, Google Cloud uses a default value of 0.0.

Zero spillover ratio

If the configured spillover ratio is 0.0, the load balancer uses the following process to create the modified eligible backends:

1. Start with the zonal match test backends identified by the zonal match condition.

2. Remove all backends that aren't in the same zone as the client. This gives us a set of zonal matched backends. This set is always non-empty because a zonal match has occurred.

3. Compute the intersection of the zonal matched backends with the original eligible backends. This intersection might be non-empty or empty.

   • If this intersection is non-empty, the modified eligible backends is the intersection set. The modified eligible backends might be the same as the original eligible backends, or the modified eligible backends might be a subset of the original eligible backends.

   • If the intersection is empty, the modified eligible backends are the same as the original eligible backends.

The following table summarizes the process to create the set of modified eligible backends when the zonal affinity option is ZONAL_AFFINITY_SPILL_CROSS_ZONE and the configured spillover ratio is 0.0.

Original eligible backends (A)	Zonal match test backends (B)	Zonal matched backends (C)	Intersection (A∩C)	Modified eligible backends
All healthy primary backends	All configured primary backends Zonal match test backends might all be healthy or a combination of healthy and unhealthy.	All primary backends in the client's zone Zonal matched backends might all be healthy or a combination of healthy and unhealthy.	All healthy primary backends in the client's zone	Intersection not empty: The modified eligible backends are all healthy primary backends in the client's zone. New connections are distributed within the client's zone. The modified eligible backends might be the same as the original eligible backends or a subset of the original eligible backends. Intersection is empty: The modified eligible backends are the same as original eligible backends. New connections might be distributed within the client's zone or to other zones.
All healthy failover backends	All configured failover backends Zonal match test backends might all be healthy or a combination of healthy and unhealthy.	All failover backends in the client's zone Zonal matched backends might all be healthy or a combination of healthy and unhealthy.	All healthy failover backends in the client's zone	Intersection not empty: The modified eligible backends are all healthy failover backends in the client's zone. New connections are distributed within the client's zone. The modified eligible backends might be the same as the original eligible backends or a subset of the original eligible backends. Intersection is empty: The modified eligible backends are the same as original eligible backends. New connections might be distributed within the client's zone or to other zones.
All unhealthy primary backends	All configured primary backends Zonal match test backends are all unhealthy by definition when the original eligible backends are all unhealthy primary backends.	All unhealthy primary backends in the client's zone	All unhealthy primary backends in the client's zone	Intersection is always not empty: The modified eligible backends are all unhealthy primary backends in the client's zone. New connections are distributed within the client's zone. The modified eligible backends might be the same as the original eligible backends or a subset of the original eligible backends.

Nonzero spillover ratio

If the configured spillover ratio is greater than 0.0 but less than or equal to 1.0, the load balancer uses the following process to create the modified eligible backends:

1. Start with the zonal match test backends identified by the zonal match condition.

2. Remove all backends that aren't in the same zone as the client. This gives us a set of zonal matched backends. This set is always non-empty because a zonal match has occurred.

3. Compute the intersection of the zonal matched backends with the original eligible backends. This set might be non-empty or empty.

4. Calculate the following ratio:

   $$ \frac{\text{count}(\text{zonal matched backends} \; \cap \; \text{original eligible backends})}{\text{count}(\text{zonal matched backends})} $$

   Note that the calculated ratio is always zero when the intersection set is empty.

5. Use the calculated ratio to determine the modified eligible backends:

   • If the calculated ratio is greater than or equal to the spillover ratio, the modified eligible backends is the intersection set. The modified eligible backends might be the same as the original eligible backends, or the modified eligible backends might be a subset of the original eligible backends.

   • If the calculated ratio is less than the spillover ratio, the modified eligible backends are the same as the original eligible backends.

The following table summarizes the process to create the set of modified eligible backends when the zonal affinity option is ZONAL_AFFINITY_SPILL_CROSS_ZONE option and the configured spillover ratio isn't 0.0:

Original eligible backends (A)	Zonal match test backends (B)	Zonal matched backends (C)	Intersection (A∩C)	Modified eligible backends
All healthy primary backends	All configured primary backends Zonal match test backends might all be healthy or a combination of healthy and unhealthy.	All primary backends in the client's zone Zonal matched backends might all be healthy or a combination of healthy and unhealthy.	All healthy primary backends in the client's zone	Calculated ratio ≥ spillover ratio: The modified eligible backends are all healthy primary backends in the client's zone. New connections are distributed within the client's zone. The modified eligible backends might be the same as the original eligible backends or a subset of the original eligible backends. Calculated ratio < spillover ratio: The modified eligible backends are the same as original eligible backends. New connections might be distributed within the client's zone or to other zones.
All healthy failover backends	All configured failover backends Zonal match test backends might all be healthy or a combination of healthy and unhealthy.	All failover backends in the client's zone Zonal matched backends might all be healthy or a combination of healthy and unhealthy.	All healthy failover backends in the client's zone	Calculated ratio ≥ spillover ratio: The modified eligible backends are all healthy failover backends in the client's zone. New connections are distributed within the client's zone. The modified eligible backends might be the same as the original eligible backends or a subset of the original eligible backends. Calculated ratio < spillover ratio: The modified eligible backends are the same as original eligible backends. New connections might be distributed within the client's zone or to other zones.
All unhealthy primary backends	All configured primary backends Zonal match test backends are all unhealthy by definition when the original eligible backends are all unhealthy primary backends.	All unhealthy primary backends in the client's zone	All unhealthy primary backends in the client's zone	Calculated ratio is always ≥ spillover ratio: The modified eligible backends are all unhealthy primary backends in the client's zone. New connections are distributed within the client's zone. The modified eligible backends might be the same as the original eligible backends or a subset of the original eligible backends.

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.