SDN for Cloud Infrastructure – combing Plexxi’s switch with SolidFire storage.
For those of you who joined us for the exciting SDN DemoFriday™ with Plexxi and SolidFire, we thank you and hope you found it useful. For our readers who missed a groundbreaking demonstration of SDN in combination with storage solutions, feel free to visit our archives here. Unique to this particular DemoFriday is a guest appearance from a joint customer of Plexxi’s and SolidFire’s: Bernino Lind, COO of CloudSigma.
As for your questions addressed to Plexxi and SolidFire during the demo, we have answers from Senior Systems Engineer, Colin Ross of Plexxi and Adam Carter, SolidFire’s Director of Product Management.
SolidFire Questions and Answers:
Q: No mention of Nexgen Storage – their strategy is very similar to SolidFire. Any comments on differentiation?
A: While there is some overlap from a marketing perspective, the products take quite different technical paths. The biggest differentiation is around Quality-of-Service, Data Efficiency, Scale and Automation.
Q: What are the key benefits from the differentiation points covered in the presentation?
- QoS – SolidFire is capable of guaranteeing fine grained performance to tens, hundreds or thousands of applications at the same time with no concern that one application’s performance needs will impact the performance another application.
- Efficiency – The storage system delivers in-line deduplication and compression requiring no off-peak time period to perform these tasks. This is ideal for a 24×7 cloud environment.
- Scale – A single SolidFire cluster can scale up to 2 PBs in capacity and provision out 5 million IOPS. This is unmatched in the industry.
- Automation – SolidFIre is the only storage system that is 100% API driven. This is critical for deep integration into cloud environments.
Plexxi Questions and Answers:
Q: Do you have a Plexxi switch with SDN features ? Or you do use some other vendor’s SDN switches ?
A: Plexxi has its own switch; having said that, all components are off-the-shelf. We use Broadcom as our Ethernet ASIC, but we also add in optical multiplexing and L1 crossbars that enable us to change the physical topology without ever re-cabling. No other switch offers this type of capability, and this is critical to the “simplify” value add we provide.
Q: How is the Plexxi ring better than a spine-leaf design?
A: There are a number of ways. I can not possibly cover all the ways here, as Plexxi is so much more than a simple data center switch.
Although Plexxi fully supports L3 (including OSPF and BGP) we also allow for the scaling of an L2 environment. Spine-leaf requires that you have L3 domains on each leaf and you must add the complexity of routing, LACP and constrain yourself with ECMP. This means that to run devices that require L2 environments (vMotion for example), you have to add more complexity in the form of some kind of overlay protocol to “fool” the devices to think that they are on the same network.
- On Plexxi, all the optics and inter-swtich cabling is included as a part of the cost of the switch. This works out to be 1 MTP cable per switch. . When delivering a spine-leaf environment, the inter-switch cabling and optics must be planned and purchased separately.
- Plexxi offers a 2:1 oversubscription ratio from access to core (as we are the access and core). For a 528 10G port environment, a Plexxi switch requires the following: 11 x 48 port Plexxi Switch 12 x MTP cable and 0 x optics No configuration The equivalent spine-leaf with a 2:1 oversubscription would require as follows (assuming 64 port switches) 13 leaf switches 5 spine switches 286 uplink cables 572 uplink optics LACP Routing Plenty of configuration
- In order to grow your environment in Plexxi: Break ring, Insert switch, Add 1 cable and no optics. No configuration required. For Spine-Leaf: Add in new leaf switch. Add in new spine switch. Add 36 new cables. Add 72 new optics modules. Add in new L3 domain. Configure LACP, Routing.
Don’t forget that according to Gartner, 80% of outages will be caused by humans, so the more configuration you have to do, the riskier it becomes. It should be quite clear from this that a spine-leaf becomes quite cumbersome quite quickly.
I have simply gone into the architecture of the data center itself here. When you start adding in that Plexxi, due to the abstract nature of configuration, can eliminate human error in configuration, and gives you complete oversight of the entire network, you can begin to see that the overall proposition becomes extremely efficient. All this, and we have not even gone into the SDN/Automation side of things.
Q: How are you eliminating spanning-tree?
Spanning-tree is a distributed protocol that runs on each switch. Its purpose is to figure out where possible loops can happen and shut off paths that cause potential loops. This is particularly bad for broadcast traffic. The calculations that Plexxi Control makes always result in directed acyclic graphs, which are inherently loop free. Having many paths to the same place could be problematic for broadcast traffic. This is handled by sending broadcasts over one path that actually goes around the ring, and not flooding it down all data links.
Q: So you are blocking some links when you eliminate loops?
Plexxi does not block any links. All links are 100% active and all are usable. Remember: Plexxi does not block links, does not use spanning-tree, does not care about “shortest path” and does not care about “equal cost path”. It uses intelligence learned from the controller to ensure that all these complexities are removed.
Be sure to catch our upcoming events and more DemoFridays™ to stay current on what the hottest companies are doing in the SDN space.