NetScaler ADC Load Balancing: Virtual Servers & Monitors - 夜莺博客

NetScaler ADC Load Balancing: Virtual Servers & Monitors

Citrix NetScaler ADC (formerly NetScaler, and still NetScaler in the CLI) is one of the
three load balancers you will meet in enterprise data centres alongside F5 BIG-IP and HAProxy.
Its configuration model is strictly three-layered: services represent the backend servers,
virtual servers represent the public endpoint, and bindings connect them. Health monitors are
what decide whether a service is UP, which in turn decides whether the virtual server is UP.
This article builds a working HTTP load-balancing configuration over the CLI and covers the
state logic that explains most "the VIP is down" tickets.

The Model Before the Commands

  • Service — a named object holding the IP address, port and protocol of one
    backend server. Each real server gets its own service.
  • Virtual server — the address clients connect to, with a protocol and port.
    It starts DOWN until services are bound and proven operational.
  • Binding — associates a service with a virtual server and carries weight
    and monitor overrides.
  • Monitor — a probe bound to a service (or inherited from the virtual
    server). The monitor, not the network, decides UP or DOWN.

The state propagation rule matters: if all bound services are DOWN, the virtual server is
marked DOWN. If any bound service is UP or OUT OF SERVICE, the virtual server is UP. That is why
a VIP can be unreachable while the firewall, routes and certificates are all fine.

Step 1: Enable the Feature

> enable feature lb
> show ns feature

Load balancing is disabled on a fresh appliance. Enabling it is a global change that
requires no reboot, and forgetting it produces ERROR: Feature(s) not enabled
on every subsequent command.

Step 2: Create the Services

# Two HTTP backends
> add service Service-HTTP-1 10.10.80.11 HTTP 80
> add service Service-HTTP-2 10.10.80.12 HTTP 80

# Verify
> show service Service-HTTP-1
> show service

For TLS backends use SSL as the service type; for non-HTTP protocols use
TCP. Mixing service and virtual server types is allowed in specific combinations —
an SSL service can bind to an HTTP virtual server to add encryption, and an HTTP service can
bind to an SSL virtual server for SSL offload — but the mismatch must be deliberate.

Step 3: Create the Virtual Server

> add lb vserver Vserver-LB-1 HTTP 203.0.113.50 80
> show lb vserver Vserver-LB-1
# GUI equivalent
Traffic Management > Load Balancing > Virtual Servers > Add
   Name:        Vserver-LB-1
   IP Address:  203.0.113.50
   Port:        80
   Protocol:    HTTP

The virtual server needs an ARP-able address on a subnet the appliance is directly attached
to, or the appliance must be the routed next hop for it. A VIP in a subnet with no local
presence requires set ip or a route — this is the second most common reason a
newly built VIP does not respond.

Step 4: Bind Services

> bind lb vserver Vserver-LB-1 Service-HTTP-1
> bind lb vserver Vserver-LB-1 Service-HTTP-2

# With weights (default 1)
> bind lb vserver Vserver-LB-1 Service-HTTP-1 -weight 2

> show lb vserver Vserver-LB-1

The output lists the bound services and their state. If the virtual server still shows DOWN
after binding, the monitors have not yet succeeded — check the service state before assuming
the VIP itself is the problem.

Step 5: Health Monitors

Inheriting the default tcp-default monitor only proves the TCP port is open. A
web server whose application pool is broken still passes that test. Bind an HTTP monitor that
checks a real path:

> add lb monitor mon-http-health HTTP
> set lb monitor mon-http-health -respCode 200 -send "GET /healthz" \
      -recv "OK" -interval 5 -resptimeout 3 -retries 3

> bind lb monitor mon-http-health Service-HTTP-1
> bind lb monitor mon-http-health Service-HTTP-2

> show service Service-HTTP-1
> show lb monitor mon-http-health

Tuning guidance: a 5-second interval with 3 retries means a service needs to fail for
15 seconds before being removed from rotation. Shorter intervals detect failures faster and
generate more probe traffic; for a two-server pool that is fine, for a 500-target pool it is
not.

Step 6: Load-Balancing Method and Persistence

> set lb vserver Vserver-LB-1 -lbMethod LEASTCONNECTION
> set lb vserver Vserver-LB-1 -persistenceType COOKIEINSERT -timeout 20
> set lb vserver Vserver-LB-1 -cookieName NSC_SESSION

Available methods include ROUNDROBIN, LEASTCONNECTION,
LEASTRESPONSETIME, SOURCEIPHASH and LEASTBANDWIDTH.
Least connection is a better default than round robin whenever requests have uneven cost.
Persistence is required for any application that keeps session state on the server — without
it, users are bounced between backends mid-session.

Verification: What to Look At

> show lb vserver Vserver-LB-1                 # state, method, bound services
> show service                                  # all services and their states
> show lb vserver Vserver-LB-1 -bindings
> stat lb vserver Vserver-LB-1                  # hit rate, request counters
> show ns runningConfig | grep "add lb vserver"
> show lb monitor mon-http-health -bindings

And from outside the appliance:

curl -I http://203.0.113.50/
curl -s http://203.0.113.50/ -o /dev/null -w '%{time_total}\n'
# Repeat and watch which backend answers, to confirm distribution

Common Problems and Their Causes

  • VIP is DOWN immediately after creation — expected until services are bound
    and monitor-proven. Do not chase it before step 4.
  • VIP UP but no traffic reaches a backend — the bound service state, not the
    VIP, is the thing to check. Also confirm the backend accepts the source address the appliance
    uses (many servers allow only specific sources).
  • Intermittent 5xx under load — persistence misconfigured or a monitor
    threshold flapping services in and out. Look at service state transitions, not just the
    current state.
  • Different behaviour in HA — in a high-availability pair only the primary
    owns the VIPs. Confirm which node is primary and whether failover is forced, not automatic on
    one node.
  • Configuration lost after reboot — NetScaler keeps a running configuration
    and a saved configuration. save ns config is the step people forget during a
    maintenance window.
> save ns config
> show ns ns.conf | head

Where It Fits

The concepts translate directly to F5 BIG-IP (virtual server, pool, pool member,
health monitor) and to open-source alternatives. Compare the monitoring configuration in
F5 BIG-IP virtual server and health monitor configuration and, for protocol-level load balancing without application awareness, nginx stream module TCP/UDP load balancing. If you need a floating address for an active/standby pair, Keepalived VRRP and HAProxy virtual IP failover covers the mechanism.

原文链接:https://docs.netscaler.com/en-us/citrix-adc/current-release/load-balancing/load-balancing-setup