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

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

Internal passthrough Network Load Balancers support threezonalaffinityoptions that offer varying degrees of preference for routing new connectionsto eligible backends that are in the same zone as a supported client. Zonalaffinity modifies the set of eligible backends after the load balancerselectsan eligible backend for a newconnection.Established connections in the load balancer's connection tracking tablearen't affected by zonal affinity.

Compatibility

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

• Arenext hops for staticroutes ornext hopsfor policy-based routes
• Have afailover policy

Zonal affinity is compatible withsymmetric hashingonly when the following conditions are true:

• Both the internal passthrough Network Load Balancers in the forward and reverse directionhave zonal affinity enabled.
• Traffic from sender VMs is only directed to receiver VMs in the same zone.

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

• Havebackendsubsetting enabled
• Arecollector destinations forPacket Mirroring
• Are used to provide aPrivate Service Connect publishedservice. Zonalaffinity is only possible for compatible clients that send packetsto the load balancer, not to a Private Service Connectendpoint 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 thesame region as the load balancer. Zonal affinity isn't compatible withthe following clients, which always operate as if zonal affinity isdisabled:

• Client Cloud VPN tunnels and client Cloud InterconnectVLAN attachments:Cloud VPNtunnels andCloud InterconnectVLAN attachments are regional resources, not zonal resources. Packetsrouted through a Cloud VPN tunnel or VLAN attachment neversupport zonal affinity, regardless of whether they are in the sameregion 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 clientsin all other regions ifglobalaccessis enabled. When client VMs are in a region that's different from theload balancer's region, client VMs never share a common zone with anyof the load balancer's backends.

Zonal match

A zonal match describes the conditions under which zonal affinity is triggered.The load balancermight then modify the original set of eligible backends toprovide the configured zonal affinity. The modification of the original set ofeligible backends takes placeafter theIdentify eligible backendsstep in theBackend selection and connection tracking process.

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

1. Zonal affinity must be enabled

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

2. Determine whether the client is acompatible 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 leastone configured backend of the relevant type. The different backends thatcan be configured are outlined in theZonal match conditions section.

   A zonal match isnever 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 thezonal affinity option that is configured. The options that enable zonalaffinity are as follows:

   • ZONAL_AFFINITY_STAY_WITHIN_ZONE
   • ZONAL_AFFINITY_SPILL_CROSS_ZONE with a spillover ratio of0
   • ZONAL_AFFINITY_SPILL_CROSS_ZONE with a nonzero spillover ratio

   After a zonal match occurs and depending on the type of zonal affinity optionthat is configured, the original set of eligible backends might berefined,replaced, or leftunchanged. Any new connections from the client arerouted to this modified set of eligible backends.

Zonal match conditions

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

Zonal match example

Consider the following situation to determine whether there is azonal match:

• Failover policy is configured
• Zonal affinity is enabled
• Client is inzone A
• Primary backends are only inzone B andzone C
• There are no primary backends inzone 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 balancerselects 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 eitherrefining the original set of eligible backends, orreplacing the original set of eligible backends with a new set. For details about this option, seeHowZONAL_AFFINITY_STAY_WITHIN_ZONE works.

• ZONAL_AFFINITY_SPILL_CROSS_ZONE: zonal affinity is enabled. When a zonalmatch occurs, the load balancer might refine the set of eligible backends orit might leave the original set of eligible backends unchanged. This optionallows traffic to spill over to other zones if not enough healthy backendsare in the client's zone. Thespill over is controlled by the spilloverratio. For more information about this option, seeHowZONAL_AFFINITY_SPILL_CROSS_ZONE and spillover ratiowork.

To learn how to configure zonal affinity on the backend service of aninternal passthrough Network Load Balancer, seeUse zonal affinity.

HowZONAL_AFFINITY_STAY_WITHIN_ZONE works

If zonal affinity is set toZONAL_AFFINITY_STAY_WITHIN_ZONE, and a zonalmatch 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 balancerrefines the set of eligible backends by doing the following:

  • Discarding all eligible backends that arenot 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 configuredbackends (not in the set of eligible backends) are present in the client'szone because a zonal match did occur for zonal affinity to be triggered. Inthis situation, the load balancerreplaces the set of eligible backends witha new set that includes unhealthy backends within the client's zone, based onwhether 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 eligiblebackends consists of all unhealthy backends in the client's zone.

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

  • If a failover policy is configured and the original eligible backends werefailover backends, the replacement set of eligible backends consists ofall unhealthyfailover backends in the client's zone.

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

It is important to note the following for theZONAL_AFFINITY_STAY_WITHIN_ZONEoption:

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

HowZONAL_AFFINITY_SPILL_CROSS_ZONE and spillover ratio work

If zonal affinity is set toZONAL_AFFINITY_SPILL_CROSS_ZONE and a zonalmatch occurs, the set of eligible backends for the clientmight be refined orit might also result inno 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 theclient's zone, or they might spill over to eligible backends in other zones.This distribution depends on a configurable spillover ratio that determines whentraffic starts spilling over to eligible backends in other zones.

A configurable spillover ratio indicates the threshold value for keeping trafficin the client's zone. If the proportion of healthy and eligible backends fallsbelow the defined spillover ratio, all new connections from clients in the zoneare distributed to eligible backends in other zones. The value of the spilloverratio can range from0.0 to1.0, inclusive.

If you don't specify a spillover ratiowhen configuringZONAL_AFFINITY_SPILL_CROSS_ZONE zonal affinity,Google Cloud uses a default value of0.0.

Zero spillover ratio

If the configured spillover ratio is0.0, the load balancer refines theset of eligible backends by discarding all eligible backends that arenotin the client's zone, provided that one of the following is true:

• If a failover policy isn't configured, eligible backends are all healthybackends, and at least one eligible backend is in the client's zone
• If a failover policy is configured, eligible backends are all healthyprimary backends, and at least one eligible backend is in the client's zone
• If a failover policy is configured, eligible backends are all healthyfailover 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 theZONAL_AFFINITY_SPILL_CROSS_ZONE option when the configured spillover ratio is0.0:

Nonzero spillover ratio

If the configured spillover ratio is greater than0.0 but less than or equalto1.0, the load balancer first calculates one of the following ratios:

• If a failover policy isn't configured, the calculated ratio is the numberofeligible and healthy backends in the client's zone divided by the numberofconfigured 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 primarybackends, the calculated ratio is the number ofeligible and healthy backendsin the client's zone divided by the number ofconfigured primary backends inthe 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 failoverbackends, the calculated ratio is the number ofeligible and healthy backendsin the client's zone divided by the number ofconfigured failover backends inthe 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, theload balancer refines the set of eligible backends by discarding all eligiblebackends that arenot in the client's zone. Otherwise, the load balancer usesthe original eligible backends.

When computing the calculated ratio, remember the following:

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

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

• A spillover ratio of1.0 indicates that one of the following is true:

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

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

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

The following table summarizes all refinement scenarios for theZONAL_AFFINITY_SPILL_CROSS_ZONE option when the configured spillover ratioisn't0.0:

Spillover ratio examples

The following examples show howZONAL_AFFINITY_SPILL_CROSS_ZONE workswhen there's no failover policy configured.

• For zonal affinity to apply when you configure a spillover ratio of1.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 zonemust equal the number of configured backends in the client's zone.

  A spillover ratio of1.0 indicates that 100% of the eligiblebackends in the client's zone need to be healthy for all new connections to bedistributed to backends in the client's zone only. Even if one backend becomesunhealthy, the load balancer distributes some new connections to backends inother zones.

• For zonal affinity to apply when you configure a spillover ratio of0.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 zonedivided by the number of configured backends in the client's zonemust be at least0.8.

  A spillover ratio of0.8 indicates that at least 80% of theeligible backends in the client's zone need to be healthy for all newconnections to be distributed to backends in the client's zone only. If lessthan 80% of the backends in the client's zone are healthy, the load balancerdistributes some new connections to backends in other zones.

• For zonal affinity to apply when you configure a spillover ratio of0.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 of0.0 means that as long as there is at least one healthybackend in the client's zone, all new connections are distributed tobackends in the client's zone. If the spillover ratio is0.0 and there is nohealthy backend in the client's zone, the load balancer distributes all newconnections to healthy backends in zones other than the client's zone.

The following diagram shows a spillover ratio of0.8:

• Zones 1 and 2 each contain five configured backends.

• The original set of eligible backends consists of eight out of the tenconfigured 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 is5/5 =1.0.

• For the compatible client in zone 1: because the calculated ratio of1.0 is greater than the spillover ratio of0.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 is3/5 =0.6.

• For the compatible client in zone 2: because the calculated ratio of0.6 isn't greater than or equal to the spillover ratio of0.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, seeInternal passthrough Network Load Balancer logging andmonitoring.
• To troubleshoot issues with your internal passthrough Network Load Balancer, seeTroubleshoot internal passthrough Network Load Balancers.