NSX-T Native Load Balancer Backup Pool Behavior
search cancel

NSX-T Native Load Balancer Backup Pool Behavior

book

Article ID: 436093

calendar_today

Updated On:

Products

VMware NSX

Issue/Introduction

This article clarifies the behavior of Backup Members within an NSX-T Server Pool. It outlines how traffic is distributed during health transitions and explains why traffic may or may not shift to backup servers as expected based on specific configuration settings.

Active vs. Backup Members

  • Active Members: Handle all incoming traffic under normal conditions.
  • Backup Members: Remain in a "Standby" state and do not receive traffic unless the active pool fails to meet the health criteria.

 

Environment

VMware NSX

Cause

This is a informative article to explain NSX-T Native Load Balancer Backup Pool Behavior

Resolution

 

  • Scenario 1: Optimal Health (All Active Members Up)

    • Behavior: Traffic is distributed exclusively among the primary active members.

    • Backup State: Backup members receive 0% traffic and remain in a standby state.

  • Scenario 2: Partial Active Failure (Default Settings)

    • Behavior: If one or more active members fail—but at least one remains healthy—traffic is redistributed among the remaining active members.

    • Backup State: Backup members do not activate because the pool is not yet considered "down" by default logic.

  • Scenario 3: Capacity-Based Trigger (Minimum Active Members)

    • Behavior: When the number of healthy active members drops below a user-defined threshold (e.g., "Minimum Active Members" set to 3), the system triggers a failover.

    • Backup State: Backup members activate immediately to support the remaining active members or take over the full load.

  • Scenario 4: Total Active Failure (Emergency Failover)

    • Behavior: All primary active members are marked "Down" by health monitors.

    • Backup State: All traffic is immediately routed to the Backup Pool. This is the standard emergency failover state.

  • Scenario 5: Post-Recovery Sticky Traffic (Persistence)

    • Behavior: Primary members return to an "Up" state, and new connections begin hitting the primary pool. However, total traffic to the backup pool does not immediately drop to zero.

    • Reasoning: Existing users with Session Persistence (Source IP, Cookie, etc.) remain "stuck" to the backup member until their session expires or the persistence table is cleared.

  • Scenario 6: Clean Recovery (No Persistence)

    • Behavior: Once primary members recover, all subsequent traffic (new and existing) shifts away from the backup members.

    • Requirement: This only occurs if persistence is disabled.