cancel
Showing results for 
Search instead for 
Did you mean: 
Login & Join the DevCentral Connects Group to watch the Recorded LiveStream (May 12) on Basic iControl Security - show notes included.
Lori_MacVittie
F5 Employee
F5 Employee

#cloud #sdn Without the ability to gracefully shutdown the "contraction" side of elasticity may be problematic

0151T000003d5bzQAA.jpg

Quiescence, in a nutshell, is your mom telling you to "finish what you're doing but don't start anything new, we're getting ready to go".

It's an integral capability of load balancers (of enterprise-class load balancers, at least) that enables the graceful shutdown of application instances for a variety of purposes (patches, scheduled maintenance, etc... ).

In more modern architectures this capability forms the foundation for non-disruptive (and thus live) migration of virtual machines.During the process the VM is moved and launched in location Y, the load balancer continues to send requests to the same VM in location X. Once the VM is available in location Y, the load balancer will no longer send new requests to location X but will continue to manage existing connections until they are complete.

Cloud bursting, too, is enabled by the ability of a load balancer to quiesce connections at a global layer (virtual pattern) and at the local layer (bridged pattern).

Load balancers must be able to support a "finish what's been started but don't start anything new" mode of operation on any given application

The inability of a load 0151T000003d5c0QAA.pngbalancing service to quiesce connections impacts not only the ability to implement specific architectural patterns, but it can seriously impact elasticity.

The IMPACT on ELASTICITY

Scaling out is easy, especially in the cloud. Add another instance of the application to the load balancing service and voila! Instant capacity. But scaling back, that's another story. You can't just stop the instance when load contracts, because, well, any existing connections relying on that instance will simply vanish. It's disruptive, in a very negative way, and can have a real impact on revenue (what happened to my order?) as well as productivity (that was three hours of work lost, OMERGERD).

Scaling back requires careful collaboration between the load balancing service and the management framework to ensure that the process is graceful, that is, non-disruptive. It is unacceptable to business and operational stakeholders to simply "cut off" connections that may in the middle of executing a transaction or performing critical business functions. The problem is that the load balancing service must be imbued with enough intelligence to discern that there is a state between "up" and "down" for an instance. It must recognize that this state indicates "maintain, but do not add" connections.

It is this capability, this stateful capability, that makes it difficult for many cloud and SDN-related architectures to really support the notion of elasticity at the application services layer. They might be able to scale out, but scaling back in requires more intelligence (and stateful awareness) than is currently available with most of these solutions. 


 0151T000003d5WCQAY.png0151T000003d5WDQAY.png0151T000003d5WEQAY.png0151T000003d5WFQAY.png0151T000003d5WGQAY.png0151T000003d5WHQAY.png

Comments
rjhintz_145665
Nimbostratus
Nimbostratus
There's an argument that the app itself should handle both graceful quiesce by ceasing to listen on the service port but also sudden process death with a queuing backend that returns activity to the queue for replay. See 12 Factor App "processes" and "disposability" principles for a better statement.
Version history
Last update:
‎25-Feb-2013 04:29
Updated by:
Contributors