A big thank you to all of you who attended our inaugural DemoFriday™ with Plexxi and Boundary. We had a great turnout and and an even more impressive demonstration from Plexxi and Boundary. If you missed the webinar, we encourage you to check out the recording.
With a fully-packed webinar, we didn’t have time to answer all the questions from our attendees. However, we’ve consolidated all the questions we received during and after the webinar and reached out to Boundary and Plexxi for their assistance in answering them. Here’s the list of questions and answers for your enjoyment!
Q: What do you mean by simple cabling would this cabling work within a modular data center in a container?
To cable up the Plexxi data center, you literally connect Plexxi switches together using MTP cables. This means that if you deploy 20 switches, you literally only need 20 cables to interconnect your entire network. The MTP cables are a standard 12-strand single-mode fiber, and even though the switches are connected directly together, the actual fibers optically bypass intermediate switches to give you direct reach to other switches. The ring fibers themselves have a reach of up to 10KM, but can also be as short as 1M. This makes these cables very appropriate for a container.
Q: I do not understand how Plexxi is an SDN technology? Can you clarify?
SDN is a methodology rather than any one single technology. Plexxi helps bridge the gap between applications and network infrastructure by exchanging affinity information. Through affinity, applications are directly in control over what connectivity and service the infrastructure should enable for them, without having to resort to implementation-specific network details . In essence we enable control without the application having to become a network expert or the network having to become an application expert. This type of abstract control, while relatively new to the networking industry, is precisely what SDN can and should offer to the entire IT infrastructure.
Q: Can a Plexxi fit be ‘undone’?
Absolutely. In fact, we keep a history of fits, and you can choose to roll back to any one in your history.
Q: Can the same instance of Plexxi control manage multiple Plexxi rings?
Yes. Control can manage multiple Plexxi rings. Those rings can be independent rings, or they can also be interconnected but still managed from a single central Plexxi Control instance.
Q: What category of applications will see an immediate improvement by using both your tools? What percent improvements you can see on those?
Categories include: distributed web applications, big data applications (e.g. Hadoop), compute intensive applications, and even general enterprise applications like Microsoft Exchange, SAP, etc. The key vectors are distribution of resources that need to cooperate, and dependence on the network to deliver high bandwidth, low latency, or other critical capabilities for the application to perform. It’s also worth noting that it applies to things like a virtual network overlay, or a set of VMs owned by a tenant in a multi-tenant cloud. In both cases, the “affinity” is between virtual machines and/or vSwitches, not necessarily application components.
In terms of specific performance improvements, of course the answer is “it varies”. This is not to be obtuse, but it depends on the size of the application cluster, the specific sensitivity (to bandwidth, latency, etc) and of course the actual load at any given time. We prefer to look at metrics like application user experience as a way to quantify the improvements, and we’ll be working with folks that instrument applications to provide some hard before/after measurements.
Q: Is the Boundary collector embedded in the Plexxi switch?
In the Plexxi-Boundary solution, the connector is an off-box connector that can be deployed on any device that has a Python interpreter and has IP access to www.boundary.com (where Boundary hosts its analytics engine).
Q: For Plexxi, how compatible is the switch with other vendor network devices?
The Plexxi Switch is a bog-standard Ethernet switch. The only difference is that we have a private interconnect between our switches, but connecting to other networking devices is standard IP/Ethernet. We support static and dynamic routing protocols (some of which are coming soon), etc. From an interface perspective, there are no compatibility issues with other networking products.
Q: Does Plexxi support OpenFlow?
OpenFlow is not in our products today. We don’t have any real religion about the underlying protocols we use, but we believe the industry is still a ways off from a fully functional, robust, standardized southbound interface. In the mean time we will continue to expose network-abstracted interfaces to the operator and DevOps automation systems, with the goal to enable functional control of the network as an entire system.
Q: For Plexxi, are loop problems just non-existent or do you have your own loop algorithms ?
As we are a pure Ethernet fabric, loops are present, however, the controller has visibility into the entire network, and knows how all devices are interconnected. There are no distributed or proprietary protocols running on the fabric, instead, the Plexxi Control, due to the visibility that it has, runs algorithms that calculate the forwarding topologies. These calculations always result in a set of directed acyclic graphs, which are inherently loop free. This information is pushed to all switches during a fit to ensure a loop-free environment.
Q: Can you comment a bit more on the scripting/programming to get Boundary and Plexxi to communicate?
Both Boundary and Plexxi have a full set of REST APIs. Using the Boundary REST API, we can collect the information that is interesting to us. In this case, we are collecting information about the hosts, what application groups they belong to, and the conversations that they are having with other devices. Using this information, we can create our affinity groups, and create the affinity links. If there is something specific in your network that you are interested in (for example, it could be database traffic), you could write into the script to make sure that it affinitizes all database traffic to ensure that the network topology is centered around giving this traffic the most efficient paths. These scripts, we actually wrote in Python, however, any scripting language that supports sending and receiving HTTPS can be used (for example, Bash with curl).
Plexxi integration with Boundary is done entirely through our out-of-the-box RESTful API’s. To read more about the API, please refer to https://app.boundary.com/docs – note you’ll need a (free) Boundary account to view this.
Q: Can Plexxi explain more about automated affinity discovery and continuous tuning of the switching fabric. How does that happen over time?
The integration of Boundary with Plexxi is what allows us to automate affinity discovery. Boundary has real-time information pertaining to conversations in the network, and makes it available via REST calls. This information is very granular, so, for example, you could decide that you only want to automate affinity discovery for certain protocols, or maybe only for devices that hit a certain sustained throughput. The running of the resultant scripts is a function of what the requirement of the network is. If you want a completely hands free network, you would want to run these scripts periodically to pick up new affinities. Or maybe you want to run them as a part of your orchestration environment to bring on or expand services. It is really a matter of preference. Over time, Plexxi Control will collect interface statistics from the switches, so that the next time you fit your network, it attempts to even out traffic distribution over all paths.
Q: What’s the maximum size of the Plexxi network, in term of number of ports?
Currently it’s 256 switches or about 10,000 10 GbE ports *per ring*. Two very important points to make: 1) you can certainly have multiple rings, and those can be interconnected using either 10 GbE or 40 GbE ports (in one or many points in the ring), and 2) the size of the ring is really a soft limit, so it could be increased with future software releases. In the near future, we will also have switches that allow the rings to be interconnected optically, so we can build networks of 100’s of thousands of ports.
Q: Is Boundary useful for private cloud or managed hosted environments?
Yes. Boundary does not rely on appliances or tap/span ports and so can be used to monitor applications in the Public Cloud, Private Cloud and Private Datacenters.
Q: Does Boundary introduce latency into the transaction?
Boundary doesn’t instrument the JVM/container, it simply observes packets and so does not introduce any latency.
Q: What stacks can Boundary monitor?
Boundary is platform/stack independent and so can monitor any stack or technology. Many customers are using Boundary to monitor Hadoop, Cassandra, NoSQL, Ruby, PHP, Erlang and Java.
Q: How does the agent communicates with the controller ? What security measures are used during communication?
Boundary agents (referred to as Meters) communicate with the Boundary SaaS solution over duly authenticated TLS. As Boundary only reads network packet headers, it specifically refrains from obtaining and communicating more information than required for our service, furthermore, we provide source and build instructions for the meter so if someone is interested in reviewing our code, we’re fully transparent.
Find the SDN Products that are right for you at DemoFriday watch videos, download podcasts and PDF about leading SDN technologies: