Controller Federations: Cluster by Proximity or Service?
Controller Federations: Cluster by Proximity or Service?
Join the DZone community and get the full member experience.Join For Free
Get the Edge with a Professional Java IDE. 30-day free trial.
As SDN moves closer to large-scale deployments, the issue of controller scaling is becoming a hotter topic. The consensus seems to favor some form of distributed cluster environment, likely in the form of federated clusters. But how should these federations be formed?
The first thing to think about is the blast radius for controllers. Even if a controller could scale to manage every node in the network, it is unlikely that you would want that to be the design. It simply creates too large a maintenance and failure domain. Even with a redundant controller, the issues with expansive failure domains are prohibitively scary.
So most people understand that typical large-scale deployments are likely to utilize a multi-controller architecture. But how do you decide how many controllers you need?
The easiest way to think about the problem is by geography. You can take a number of switches or routers that are in relative close proximity and manage them under a single controller. This is particularly easy to do when the selected geography spans a reasonably manageable size of similar devices. A typical example might be a set of top-of-rack switches all managed under a single controller. To reduce the likelihood of a catastrophic failure, you might double up on the controller and provide multiple management connections back to the network.
But are there other ways to think about controller attachment beyond just proximity?
Imagine a case where you select a controller not because it is a natural upward extension of the physical devices but because it provides useful abstractions derived from the applications or services. Fundamentally, this would suggest a controller choice that is top-down rather than bottom-up.
It could be that a particular controller is especially good at content serving. You want to use this controller because it uses protocols like ALTO and OpenFlow to do intelligent content routing. The point of the controller is to deploy an application, so this controller might not be terribly useful in managing individual device configuration. Additionally, the network over which the content must ultimately flow might consist of a bunch of disparate devices from a handful of vendors.
In this case, the controller is more concerned with the overarching service than with managing the individual devices. The blast radius here changes. If the controller fails, the meaningful way to think about what is impacted is from a service perspective rather than a straight box perspective. It could very well be that the network is still functional for other services, but if this controller goes down, anything related to the content request routing service is impacted.
In this type of environment, there is actually a gap in the service controller; it is incapable of performing all of the management (provisioning, monitoring, and troubleshooting) capabilities that might be required for the specific devices under management. The controller is oriented to perform the specific service exceedingly well, but it lacks the individual configuration hooks to be used as a general provisioning and management device.
This is important. The controller is not necessarily an adequate network management device. It is instead a service controller (or maybe an over-the-top controller). And for architects who want to maintain management control, they might need to augment the service controller with other controllers that provide more specific device support.
In this type of architecture, it is possible to have multiple controllers managing the same set of devices. One controller can provide general support, while others are more service-oriented.
A hybrid architecture like this changes the notion of blast radius for sure. Failures and maintenance events are bounded by the edge of the service. But this also changes the notion of a federated controller cluster. Controller domains need not necessarily be non-overlapping sets of boxes that are separated primarily by their proximity to each other (or the controller).
In part, this is how Plexxi views the controller space. We have been actively working to push our notion of application abstractions into the open source community. If we do that, the question people ask is: will OpenDaylight become the controller of record for Plexxi?
This question is far more subtle than people might imagine. Will we ever use OpenDaylight as the primary controller for Plexxi? Well, first, what does that really mean? Is OpenDaylight ever going to be able to serve as a single point of administration for the entirety of a Plexxi deployment? Probably not. OpenDaylight doesn’t want to be in the business of device management. Trying to keep up with configuration options for all the devices that ODP supports would be nauseatingly difficult.
But does that mean that Plexxi doesn’t expect to use OpenDaylight? We absolutely believe that ODP will be successful. We want people using ODP in heterogeneous environments to be able to interface with ODP as a primary controller. Services provisioned (or actions taken) from ODP ought to extend into the Plexxi devices and yield meaningful results. In this case, Plexxi Control acts as a point of integration, and it creates an instance of a cluster federation. Plexxi Control would be subordinate to ODP in the general case here, allowing users to perform overarching tasks from ODP and manage more specific details of the Plexxi deployment from Plexxi Control.
What we end up with is a hybrid controller environment where customers are potentially using two (or more) controllers to manage the same set of devices. What is the distinction for those controllers? It is likely to be more task or service-oriented rather than proximity – use the right controller for the right job. Is this the future of federated control for SDN? It is certainly one possibility.
To see Plexxi’s integration with OpenDaylight, tune into the March 14 live demonstration on SDNCentral. For full details, check out the event registration page.
[Today’s fun fact: The microwave was invented after a researcher walked by a radar tube and a chocolate bar melted in his pocket. I wonder how spray paint was invented.]
Published at DZone with permission of Mike Bushong , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.