The previous post to this one in my Plexxi series discussed the platform in which Plexxi deliver their software solution. The hardware was rounded off and numbers fired off. The optical cable pass through and topologies were discussed. That was a beginning. If you were wowed back then, wait to see what Plexxi control can do for your network.
The word affinity has now become synonymous with Plexxi in the SDN space. Affinity based networking is what their caper is. Well what is it? First lets define affinity.
‘A similarity of characteristics suggestion a relationship‘. Think on that whilst incorporating network traffic and their flows. Storage traffic requires fast forwarding, cannot tolerate loss, and cannot tolerate corruption. Web traffic is bursty, transactional, and bandwidth can spike on demand. Plexxi seeks class traffic with affinities and then take it one step more. Bandwidth sensitive? No worries. An affinity can command x amount of bandwidth. A customer requires path isolation for their payment gateway to the exclusion of all others? Sure, assign your requirement to your relevant traffic affinity and you have the magic. Now this is all well and good assigning requirements and stipulations to affinities but how does one apply them. Plexxi Control helps us out here. This Virtual machine or hardware platform is the smarts behind the solution.
Plexxi Control leverages a broker to conduct communications between the controller and switches. The broker is the conduit between the two devices. Control and the underlying topology work on the theory that you are going to device your important affinities first. This can be done through an automated set and get. Over time as you learn and classify your traffic you can improve your affinities over time. You can create manual overrides too or set affinities to take place. An example of such would be Backup or vMotion traffic every Tuesday, or dynamic bandwidth allocation based on a event. Every time an affinity is laid down, the Plexxi controller will rework the topology to suit. This logical adjustment leverages the LightRail technology as discussed in the previous post. Dynamic flow based network topologies are here!
The venerable Terry Slattery asked two important questions. The first ” How can you track and create affinities ” and the second ” What if you had 1,000,000 affinities or flows per second?”. Both of these questions were very well thought out in my opinion. The reason being Plexxi’s target market is the Data Center. This without a doubt can scale from a dozen flows to countless numbers. If all customers required path isolation, having 12 east and 12 west will quickly dry you up. This is something that I believe we will see answered in time with tried and true deployments. Plexxi were rather tight lipped regarding some deployments. Feel free to comment if you’re reading guys!
Now with all of these smarts in the box many of you may be screaming “STAHP” Isn’t this a single point of failure? Well it is though it isn’t performance affect. You lose the ability to define and push out new affinities. What ever affinities are down on the Plexxi Switches stay on there all the while forwarding, and very fast forwarding at that , is continuously occurring. When the Control VM comes back on line you will gain your web interface back.
My thoughts on Plexxi control were initially mixed. At the start, I saw the potential then started to think of scale. They addressed some points which garnered confidence then Terry broke my vision open again. I know as the product matures, their engineers, lead by brilliant minds such as Derick, Mat, Martin, and others, will overcome this. In the brave new world of SDN and flow defined automation, someone has to start somewhere. Plexxi are a long way ahead of many companies. Most of those are still defining, most of those still wallowing.
3 thoughts on “Plexxi Control”
First, thanks for the write up Anthony!
Let’s talk about scaling, though. Terry asked about having one million affinities or flows per second. Affinities do not equate to flows. Affinities describe types of conversations, not the individual conversations themselves. For instance, you may describe a type of conversation between two endpoints and in operation there could numerous, numerous individual flows of that conversation type.
Having said that, it’s not likely one would design their data center with a single Plexxi “domain” covering millions of affinities. This would be broken down into multiple pod-like sections. Right now, affinities are aimed at providing enhanced forwarding treatment to specific kinds of traffic, such as latency sensitive control or media traffic, or bandwidth hogging bulk traffic. It is not realisitic to expect to affinitize everything.. yet. Though, as you say, we certainly have this future in mind.