Stateful applications are applications that maintain client information locally and use the information for future transactions from the same client. These applications expect the client to reconnect to the same application instance, even when proxies or load balancers are introduced in the middle. Citrix ADC achieves this through the persistence feature provided by the load balancing (LB) virtual server. A classic example of a persistence use case? Application owners using HTTP cookies to deliver a personalized experience to individual end users.
In our last blog post we looked at using Citrix ADC for canary deployments. Did you know that you can employ a canary deployment strategy for stateful applications, as well? You have to be careful, though. Adopting a canary deployment strategy here can lead to disruptions because it can break the persistence, which is a key requirement for the basic functioning of stateful applications. Keep reading to learn how to use Citrix ADC to implement canary deployment for stateful applications.
Filling the “Stickiness Gap”
Citrix ADC provides stickiness for stateful applications through the persistence feature at the LB vserver, but not at the content switching (CS) vserver. Because canary deployments work on the CS vserver, there has been no way to associate previously connected client to the same back-end deployment (the LB vserver).
With the release of Citrix ADC 13.0, this persistence feature is supported at the CS vserver entity, helping fill the “stickiness gap” between the client and a particular deployment for stateful applications. When a new version of an application is released and introduced to production, the persistence feature ensures that the existing client transactions are not directed to the new canary version. Only a portion of the new client transactions is directed to canary version.
Similarly, after a new client is routed to a particular version, if the same client reconnects back, it should stick to the same version and should not evaluate the content switching policies again. Persistence overrides the content switching decision. To configure persistence on CS vserver, use the following command:
set cs vserver <name> -PersistenceType <type> [-timeout <integer>]
If the application monitoring returns a “failure” for the canary version, configurations corresponding to the newer version have to be removed from Citrix ADC. For stateful applications, these changes can’t be done abruptly because they could lead to disruptions that are visible to the user.
Citrix recommends that you use a domain-based service group to represent the back-end set of instances of a particular version. By doing so, when the user (or container orchestrator) decommissions the back-end instances, the corresponding entities on Citrix ADC are removed graciously. The entities are not removed from Citrix ADC until the client transaction is completed. This enables seamless adoption of a canary deployment without disruptions to the user experience. Citrix recommends enabling DNS-based autoscale on the service group using the following command:
add serviceGroup <serviceGroupName> -autoScale (YES | NO)
Learn More
More information is available in the Citrix ADC product documentation, including resources on content switching and load balancing. And learn about canary deployments using Citrix ADC’s application insights in our previous blog post.
Citrix Tech Bytes – Created by Citrix Experts, made for Citrix Technologists! Learn from passionate Citrix Experts and gain technical insights into the latest Citrix Technologies.
Click here for more Tech Bytes and subscribe.
Want specific Tech Bytes? Let us know! tech-content-feedback@citrix.com.
