Persistence support for content switching virtual server
Applications are moving from monolithic architectures toward microservices architecture. Different versions of the same application can co-exist in the microservices architecture. NetScaler appliance must support continuous deployment of applications. It is achieved by platforms that perform Canary deployments (such as Spinnaker). In a continuous deployment setup, a newer version of an application is deployed automatically and exposed to client traffic in stages until the application is stable to take complete traffic. Also, there must be uninterrupted services to the client.
The NetScaler content switching feature enables NetScaler the appliance to distribute client requests across multiple load balancing virtual servers based on the policies bound to the content switching virtual server.
For continuous deployments, content switching is used to select the load balancing virtual server serving various versions of an application.
In content switching, the selection of a load balancing virtual server for a specific application version changes at runtime because of the change in the content switching policies. During this transition, if some sessions are present with older versions of the application, such traffic must continue to be served by older versions only. To support the requirement, the NetScaler appliance maintains persistence across multiple load balancing groups behind a content switching virtual server. Persistence for content switching virtual server enables seamless transition of clients from one version to another.
Related information
Supported persistence types on content switching virtual server
The following persistence types are supported on content switching virtual servers.
| Persistence type | Description |
|---|---|
| Source IP | SOURCEIP. Connections from the same client IP address are parts of the same persistence session. For more details, see Source IP address persistence. |
| HTTP Cookie | COOKIEINSERT. Connections that have the same HTTP Cookie header are parts of the same persistence session. The format of the cookie that the NetScaler appliance inserts is: NSC_<vid_str of CSvserver>=<vid_str of Lbvserver> where NSC_XXXX is the virtual server ID that is derived from the virtual server name. For more details, see HTTP cookie persistence. |
| SSL Session ID | SSLSESSION. Connections that have the same SSL Session ID are parts of the same persistence session. For more details, see SSL session ID persistence. |
You can configure a timeout value for persistence that is based on HTTP cookies. If you set the timeout value to 0, the ADC appliance does not specify the expiration time, regardless of the HTTP cookie version used. The expiration time then depends on the client software, and such cookies are valid only if the software is running.
Depending on the type of persistence that you have configured, the virtual server can support either 250,000 simultaneous persistent connections or any number of persistent connections up to the limits imposed by the amount of memory on your NetScaler appliance. The following table shows which types of persistence fall into each category.
| Persistence type | Number of simultaneous persistent connections supported |
|---|---|
| Source IP, SSL Session ID | 250,000 |
| HTTP Cookie | Memory limit. In CookieInsert, if the timeout is not 0, the number of connections is limited by memory. |
Some types of persistence are specific to particular types of virtual server. The following table lists each type of persistence and indicates which types of persistence are supported on which types of virtual server.
| Persistence type | HTTP | HTTPS | TCP | UDP/IP | SSL_Bridge | SSL_TCP | RTSP | SIP_UDP |
|---|---|---|---|---|---|---|---|---|
| SOURCEIP | Yes | Yes | Yes | Yes | Yes | Yes | No | No |
| COOKIEINSERT | Yes | Yes | No | No | No | No | No | No |
| SSLSESSION | No | Yes | No | No | Yes | Yes | No | No |
Backup persistence support
You can configure the content switching virtual server to use the source IP persistence type as the backup persistence type when the cookie persistence type fails. It is useful for canary deployments in the microservices architecture. When the cookie persistence type fails, the appliance falls back to source IP based persistence only when the client browser does not return any cookie in the request. However, if the browser returns a cookie (not necessarily the persistence cookie) it is assumed that the browser supports cookies and hence backup persistence is not triggered. You can also set a timeout value for backup persistence. Timeout is the time period for which a persistence session is in effect.
How persistence on content switching virtual server works
Scenario 1: A content switching virtual server without persistence
The following example illustrates the deployment of multiple versions of an application with a content switching virtual server without persistence.
When client C1 sends a request to the application, the request is sent to the content switching virtual server in the NetScaler appliance. The content switching virtual server evaluates the policy and forwards the request to the load balancing virtual server (LB1) that is serving version v1 of the application.
Consider a new version v2 of the application is deployed and has to be exposed to a subset of users. The new load balancing virtual server (LB2) serving the v2 version is bound to the content switching virtual server by the appropriate content switching policy.
When client C1 sends a new request, the policy is evaluated again and the request is forwarded to the load balancing virtual server LB2. Thus, the transactions for stateful applications fail if multiple versions of the application are deployed.
Scenario 2: Content switching virtual server with persistence
The following example illustrates the deployment of multiple versions of the application with a content switching virtual server with persistence.
When client C1 sends a request to the application, the request is sent to the content switching virtual server in the NetScaler appliance. The content switching virtual server evaluates the policy, creates a persistence session entry, and forwards the request to the load balancing virtual server LB1 that is serving version v1 of the application.
The same client C1 requests again for the application, and the request is sent to the content switching virtual server in the NetScaler appliance. A lookup for the persistence session is performed. Since an existing entry is found, the load balancing virtual server LB1 is selected from the existing persistence session, and the request is forwarded to LB1. Therefore, CS policy evaluation is not performed in this scenario. No breakage of the existing transaction happens with this solution; thus, maintaining the stateful nature of the application.
Let’s consider a new client C2. The new request C2 is sent to the newer version of the application through policy evaluation as there is no existing persistence session for this client. It results in a successful rollout of the newer version of the application without breaking its statefulness.
Because of the persistence support, customers can deploy multiple content or different versions of the application seamlessly without impacting the existing transactions, specifically for stateful applications. It is not possible without persistence in the picture.
Configure persistence type on content switching virtual server by using the CLI
At the command prompt, type:
set cs vserver <name> -PersistenceType <type> [-timeout <integer>]
Example:
set cs vserver Vserver-CS-1 -persistenceType SOURCEIP -timeout 60
Configure persistence type on content switching virtual server by using the GUI
-
Navigate to Traffic Management > Content Switching > Virtual Servers and click Add.
-
In Basic Settings, configure the persistence details.