7.4 Server Groups, App Connector Groups & Health Reporting

7.4 Server Groups, App Connector Groups & Health Reporting

Core Principle: In Zscaler Private Access, traffic routing between client endpoints and backend enterprise applications is governed by a decoupled three-tier hierarchy: Application Segments, Server Groups, and App Connector Groups. By separating the definition of what users can access from how traffic physically reaches backend infrastructure, ZPA provides high availability, automated load balancing, dynamic server discovery, and continuous synthetic health monitoring across multi-datacenter and hybrid cloud environments.

---

1. The Three-Tier Architecture: Segments, Server Groups & Connector Groups

To achieve operational agility, ZPA decouples policy definitions from physical server hosting infrastructure.

+-----------------------------------------------------------------------------------+
|                    ZPA THREE-TIER ROUTING & BINDING HIERARCHY                     |
+-----------------------------------------------------------------------------------+

  TIER 1: LOGICAL APPLICATION DEFINITION
  ┌───────────────────────────────────────────────────────────────────────────────┐
  │ Application Segment: "ERP-Financial-Suite" (*.erp.corp.internal:443)         │
  └───────────────────────────────────────┬───────────────────────────────────────┘
                                          │ Bound to
                                          ▼
  TIER 2: BACKEND DESTINATION GROUPING
  ┌───────────────────────────────────────────────────────────────────────────────┐
  │ Server Group: "ERP-Production-Servers"                                        │
  │ * Dynamic Server Discovery: ENABLED                                           │
  │ * Health Check: HTTPS Probe to /healthz (Port 443, Interval 30s)              │
  └───────────────────────────────────────┬───────────────────────────────────────┘
                                          │ Bound to
                                          ▼
  TIER 3: PHYSICAL NETWORK INGRESS & PROXIES
  ┌───────────────────────────────────────────────────────────────────────────────┐
  │ App Connector Group: "US-East-Datacenter-Cluster"                             │
  │ ├── App Connector 01 (10.10.1.10 - Active)                                    │
  │ └── App Connector 02 (10.10.1.11 - Active)                                    │
  └───────────────────────────────────────┬───────────────────────────────────────┘
                                          │ Local L4 Proxy
                                          ▼
  ┌───────────────────────────────────────────────────────────────────────────────┐
  │ Physical / Virtual Servers: erp-node-01.corp (10.10.5.50), erp-node-02 (10.10.5.51)│
  └───────────────────────────────────────────────────────────────────────────────┘

Why This Decoupling Matters:

• Infrastructure Independence: If backend application server IP addresses change, or if workloads migrate from an on-premises datacenter to AWS, administrators simply update the Server Group or Connector Group binding without modifying user access policies or Application Segments.
• Multi-Region Redundancy: An Application Segment can be bound to multiple Server Groups located in different geographic regions, enabling automated disaster recovery and proximity routing.

---

2. Dynamic Server Discovery vs. Explicit Servers

When configuring a Server Group, administrators choose between Dynamic Server Discovery and Explicit Servers.

+-----------------------------------------------------------------------------------+
|            DYNAMIC SERVER DISCOVERY VS. EXPLICIT SERVER CONFIGURATION             |
+-----------------------------------------------------------------------------------+

  DYNAMIC SERVER DISCOVERY (Recommended for Cloud & Scalable Apps):
  [ Server Group (Dynamic = ON) ] ──> App Connector receives request for 'app05.corp'
                                              │
                                              ▼
                                   [ Local DNS Resolution ] ──> Discovers 10.20.4.15
                                              │
                                              ▼
                                   [ Automatic Proxy & Cataloging ]

  EXPLICIT SERVERS (Recommended for Strict Static Workloads):
  [ Server Group (Dynamic = OFF) ]
         ├── Server 1: 10.20.1.50 (Explicit Host / IP)
         ├── Server 2: 10.20.1.51 (Explicit Host / IP) ──> Probed individually
         └── Server 3: app-backup.corp (Explicit FQDN)

Comparison Table

---

3. Synthetic Health Checks & Probing Mechanics

To ensure that user sessions are steered only to operational backend servers, ZPA employs Synthetic Health Checks.

+-----------------------------------------------------------------------------------+
|                     SYNTHETIC HEALTH CHECK PROBING MECHANICS                      |
+-----------------------------------------------------------------------------------+

  ┌─────────────────────────────────┐
  │        ZPA App Connector        │
  └────────────────┬────────────────┘
                   │ (Periodic Synthetic Health Probes)
       ┌───────────┴───────────┐
       │                       │
       ▼                       ▼
  ┌─────────────────────────┐ ┌───────────────────────────────────────────────┐
  │    TCP Health Check     │ │          HTTP / HTTPS Health Check            │
  │  * TCP 3-Way Handshake  │ │  * Sends GET / HEAD request to URI path       │
  │  * SYN -> SYN/ACK -> ACK│ │  * Evaluates HTTP status code (200 OK, 302)   │
  │  * RTT Latency Recorded │ │  * Validates SSL/TLS handshake & certificate  │
  └─────────────────────────┘ └───────────────────────────────────────────────┘

Health Check Protocols:

1. TCP Health Check: The App Connector executes a standard TCP 3-way handshake against the target server IP and port. If the handshake completes within the timeout threshold, the server is marked Healthy and the TCP round-trip time (RTT) is recorded.
2. HTTP / HTTPS Health Check: The App Connector transmits an HTTP/HTTPS GET or HEAD request to a specific path (e.g., /healthz, /status, or /index.html). The administrator configures acceptable HTTP response codes (e.g., 200 OK, 204 No Content, 302 Found). If the server returns a matching code, it is marked Healthy.

Key Health Check Parameters:

• Interval (Default: 30s): Time between consecutive synthetic health probes.
• Timeout (Default: 5s): Maximum duration to wait for a server response before marking the probe as failed.
• Unhealthy Threshold (Default: 3): Number of consecutive probe failures required to mark a server Down/Unhealthy.
• Healthy Threshold (Default: 2): Number of consecutive successful probes required to restore an unhealthy server to Healthy status.

---

4. Health Reporting Modes

ZPA provides three distinct Health Reporting Modes within Server Groups to balance health visibility against network overhead:

+-----------------------------------------------------------------------------------+
|                         ZPA HEALTH REPORTING MODES                                |
+-----------------------------------------------------------------------------------+

  1. CONTINUOUS HEALTH REPORTING (Always Probing):
     [ App Connector ] ──( Probes Every 30s 24/7 )──> [ Backend Server ]
     * Best for mission-critical apps requiring instantaneous failover
     * Continuously reports health status to ZPA Central Authority

  2. ON-DEMAND HEALTH REPORTING (Probing on Request):
     [ User Requests App ] ──> [ App Connector Probes Server ] ──> [ Session Connected ]
     * Probe ceases after inactivity timeout
     * Conserves network bandwidth and connector CPU for rarely accessed apps

  3. NONE (Configured Up / No Probing):
     [ App Connector ] ──( No Probes Sent )──> [ Backend Server ]
     * Server is always assumed healthy
     * Used for UDP services, ICMP, or rate-limited legacy application APIs

---

5. Intelligent Load Balancing & Failover Mechanics

When multiple healthy servers and App Connectors are available, ZPA uses intelligent selection algorithms to optimize user experience.

+-----------------------------------------------------------------------------------+
|                   MULTI-REGION LOAD BALANCING & FAILOVER FLOW                     |
+-----------------------------------------------------------------------------------+

                                  [ Remote User ]
                                         │
                                         ▼
                            [ ZPA Public Service Edge ]
                                         │
                  ┌──────────────────────┴──────────────────────┐
                  │ (Primary: Lowest Latency)                   │ (Secondary: Failover)
                  ▼                                             ▼
      [ US-East Connector Group ]                   [ US-West Connector Group ]
      * App Connector 01 (Healthy)                  * App Connector 03 (Healthy)
      * App Connector 02 (Healthy)                  * App Connector 04 (Healthy)
                  │                                             │
                  ▼                                             ▼
      [ Primary Datacenter Servers ]                [ DR Datacenter Servers ]
      (Active-Active Load Balanced)                 (Standby Disaster Recovery)

Selection & Load Balancing Hierarchy:

1. Connector Group Selection: The Central Authority identifies all App Connector Groups bound to the target Server Group and selects the group with the lowest round-trip latency to the user's Service Edge.
2. Connector Load Balancing: Within the selected App Connector Group, active user sessions are balanced across healthy App Connectors in an active-active cluster.
3. Server Load Balancing: Within the Server Group, traffic is distributed across healthy backend servers using:
   • Round Robin: Requests cycle sequentially across all available healthy servers.
   • Dynamic RTT / Least Latency: Requests route to the server demonstrating the lowest synthetic probe response time.
4. Automated Failover: If all servers or connectors in the primary location fail health checks, ZPA automatically redirects new user sessions to the secondary Server Group/Connector Group without administrative intervention.

---

6. Practical Configuration Scenario: Multi-Datacenter Resilient Setup

Scenario: An organization hosts an internal intranet portal (intranet.corp.internal) across two datacenters: East DC (Primary) and West DC (Disaster Recovery).

Configuration Procedure in ZPA Admin Portal:

1. Configure App Connector Groups:
   • Create East-DC-Connector-Group (Ashburn, VA) with 2 App Connectors.
   • Create West-DC-Connector-Group (Santa Clara, CA) with 2 App Connectors.
2. Configure Synthetic Health Check:
   • Navigate to Application Management > Health Checks and create Intranet-HTTPS-Check (Protocol: HTTPS, Port: 443, Path: /status, Interval: 30s, Unhealthy Threshold: 3).
3. Configure Server Groups:
   • Create East-DC-Server-Group: Enable Dynamic Server Discovery, assign East-DC-Connector-Group, bind Intranet-HTTPS-Check, set Health Reporting to Continuous.
   • Create West-DC-Server-Group: Enable Dynamic Server Discovery, assign West-DC-Connector-Group, bind Intranet-HTTPS-Check, set Health Reporting to Continuous.
4. Configure Application Segment:
   • Create Intranet-Portal-Segment: FQDN = intranet.corp.internal, TCP Port = 443, bind both East-DC-Server-Group and West-DC-Server-Group.
5. Validation: In Diagnostics > App Connector Status, verify both connector groups show healthy server probes. Simulate an East DC outage by stopping web services in East DC; verify user sessions immediately route to West DC.

---

7. Exam Tips & High-Frequency Traps

[!IMPORTANT] Exam Key Point (Who Initiates Health Probes?): On the ZDTA exam, remember that App Connectors execute the synthetic health checks, NOT the Central Authority or Service Edge. Probes originate locally from the App Connector's internal IP address to the backend server.

[!WARNING] Exam Trap (Health Reporting: None): If Health Reporting is set to None, ZPA marks the server as perpetually Up/Healthy. If the backend server goes offline, ZPA will continue forwarding traffic to it because no synthetic probing is performed to detect failure.

[!TIP] Operational Best Practice (Dynamic Discovery & Auto-Scaling): Always enable Dynamic Server Discovery when deploying applications in AWS, Azure, or GCP auto-scaling groups to ensure new backend instances are automatically discovered without administrative intervention.