F5 Synthesis: All Active ADC Clustering

#SDAS #Cloud ADC clustering isn't enough because you deliver app services, not ADC instances

The classic high availability (HA) deployment pattern is hard to break. It's been the keystone upon which data centers have been built since the turn of the century. Redundancy, after all, ensures reliability.

But today's data centers are as concerned with efficiency as they are with reliability, and with economies of scale even more so. Assigning pairs of application delivery controllers (ADC) to every application in need of high availability is no longer economically or operationally viable.

A fabric-based model cannot be based on the premise of simply extending the HA model to a larger set of devices. The traditional HA model relies on device-level failover; if the primary device fails, simply make the secondary active and voila! Continued availability.

This model, of course, required a secondary (and very idle) device. In today's OpEx-aware world, that's not going to fly. And we won't even cite the number of times a primary failed after long years of service only to discover the backup was long dead, too.

Active-active seems a logical way to go, except for that whole over-subscribed thing. You know, when the distributed load across the two systems is greater than the capacity of a single system. When 60% load plus 60% load = too much load. Failover? Sure, for some of the load. The rest? Bah! Who needed those thousands of dollars worth of transactions anyway, right?

A better model is needed, for sure, and the advances in technology over the past few years have resulted in an awareness that it can't just be about device clustering for ADCs. The increased demand for multi-tenancy in the network has been answered, for the most part. The actual ADC platform today is capable of hosting multiple, multi-tenant (virtual) ADC instances. But if one of those fails, you don't want to impact the others. Device-level failover isn't enough for modern, virtualized networking. Clustering has to be about app services clustering, too

Which is what F5 offers with Synthesis' High Performance Services Fabric through its ScaleN technology.

ScaleN: Device Service Clustering

ScaleN is a scalability and availability model based on the premise that infrastructure is hybrid (physical and virtual), that app services scale (and often fail) elastically and erratically, and operational efficiency is number one. Device Service Clustering (DSC) is designed to meet and exceed those requirements, by enabling a more flexible and efficient model of availability and scalability at the same time.

DSC starts with the ability to cluster together (today up to 32) devices, whether physical or virtual (and by virtual we mean on any of the popular hypervisors), and create up to 2560 multi-tenant ADC instances*. Then we enable the ability to group those devices together and synchronize configurations (because you've got better things to do than copy config files from device to device, don't you?). And then we also make sure that each of the ADC instances is isolated from the other. That means if one ADC instance with all its app services has trouble and needs to fail over to another device, it doesn't impact any other instance (and all its app services) on the original device. That's app service isolation.

What you end up with is a highly flexible services fabric (a pool of hardware and/or virtual resources) that enables app services to scale beyond the traditional pair of ADC instances (scale out) or to migrate from one instance to another (scale up) without disruption.

 

DSC offers organizations the ability to optimize delivery services across a heterogeneous pool of resources without fear of oversubscribing a device. That's because ScaleN is capable of performing load-aware and user-defined failover. In the past, failover was a strictly static proposition because on a fixed order of devices. Primary to secondary, secondary to tertiary, etc... Using load aware and user-defined failover, however, the order of failover becomes dynamic and based on current conditions. That allows the fabric to maintain as equal a distribution across a cluster as possible.

The goal is always to maintain the most efficient use of resources across clusters and avoid disruptive failover events - both at the device and the service level.

Because you should be delivering app services, not ADC instances. And while the two are inexorably linked, they shouldn't be chained permanently together. That's the old, static HA model - whether active-standby or active-active. The new, dynamic HA model is all-active, elastic and service-aware clustering.

 

* You can further divide an F5 ADC instance using route domains and administrative partitions. The number of possible "instances" using all three options is, well, really big. Really, really, big.