Controlling surge/burst (Must know)

Handling massive surges in traffic is extremely important for organizations that do their business in websites. Even for others, sudden bursts in traffic do not come fully announced and need to be taken care of. This section deals with how the Citrix NetScaler controls and regulates traffic, thereby preventing outages.

Getting ready

The surge protection feature of NetScaler is enabled either globally or at service level. This feature controls the number of simultaneous connections made by NetScaler to the backend server farm. Surge protection is enabled by default and hence for scenarios where surge protection is not necessary it needs to be disabled. Surge protection should not be enabled when the Use Source IP (USIP) mode is enabled because with the USIP mode the number of backend connections will increase, as the original client IP will be shown as the source IP, and hence connection re-use is ruled out. Therefore, when more and more connections form, surge protection will get aggressive and not work as expected.

How to do it...

Setting up surge protection on NetScaler is a very simple procedure. As discussed before, it is enabled by default on the NetScaler GUI. It can be found under System | Settings | Global System Settings:

By default, two values are set:

• Base Threshold is the maximum number of concurrent connections that NetScaler will forward to the backend servers before triggering the surge protection. For each Throttle value, a predefined numbered set that can be changed.

• Throttle can be normal, aggressive, or relaxed, each having a predefined number of connections that can be changed.

At service level, we have the surge protection checkbox under Advanced | Settings | Surge Protection:

How it works...

It is important to keep the server functioning at a normal capacity, as overloading it may result in undesirable results, such as application crashes and unavailability of resources for clients. NetScaler's basic functionality is connection multiplexing between the client and server (per request based). Hence, whenever a new connection is made and surge protection is enabled, it would check for any free existing connection to the servers; if not, then according to the max client and max request value set at the service level, the connection will be served or put in the surge queue.

The length of the surge queue will decrease if any existing connection in the backend becomes free.

There's more...

This section deals with certain tidbits that will come in handy with respect to surge protection.

If the rate at which requests hit NetScaler increase exponentially, the surge queue will become longer, hence it will be necessary to flush the surge queue. The following are a few simple network management protocol OIDs that retrieve the length of surge queue at the vserver level:

• vsvrSurgeCount,1.3.6.1.4.1.5951.4.1.3.1.1.10

• surgeCount,1.3.6.1.4.1.5951.1.4.1.1.1.7

• tcpSurgeQueueLen,1.3.6.1.4.1.5951.4.1.1.46.15

• svcSurgeCount,1.3.6.1.4.1.5951.4.1.2.1.1.10

When the surge queue length becomes long and affects the availability of resources to the users, you can flush the surge queue with the following CLI command:

root@ns> flush ns surgeQ [-name <name>] [-serverName <serverName> <port>]