Why Smart Fabric Services with VxRail?

In recent discussions with customers about their environments, I have noticed the conversation has naturally evolved to the benefits of Smart Fabric Services (SFS) and networking, even though I wasn’t brought in to talk about networks. Many of the customers I talk with need their infrastructure to be much more flexible. VxRail is bringing them the scalability, flexibility and speed that they need but realising the benefits is difficult when they are hamstrung by their network limitations. Here are a few challenges I have seen:

1. Lack of networking skills – Networking skills are in high demand but finding people that can fill the roles is difficult. Many of the smaller customers only have a small team that need to work across multiple technologies and just don’t have the bandwidth to be dedicated to networking.

2. Wasting resources – For some of the mid to larger customers that are lucky enough to have a dedicated networking resource, having them spend their time configuring ports to end devices is a waste of their time. They would be better to focus on their core network and ensuring smooth operation.

3. Scale – This is a big one for everyone but even more so for our larger customers. Some customers have hundreds of VxRail nodes each with multiple network ports. Making a change across many switches and many hundreds of ports presents operational risk and significant effort for a dedicated networking team.

4. Network Architecture – On numerous occasions I have found that the customers network isn’t architected well for HCI. It might not be designed for the significant east-west traffic that goes with HCI or it may have network stacking which means there is no way to upgrade switches non-disruptively. In the past this may not have been a problem if the applications could suffer an outage, but the network is the backbone of software defined storage.

Luckily SFS can help with each of these pain points.

1. Lack of networking skills – Once SFS is integrated into your vCenter using the OMNI plugin (Figure 1), it will monitor the environment for changes. If it sees that an admin has added a portgroup to your distributed switch it will update the physical switches to match with no extra effort (Figure 2). This makes adding additional VLANs a trivial task that doesn’t require anyone from the networking team.

Figure 1 - OMNI plugin in vCenter

Figure 2 - OMNI updating the switches after adding a port group

2. Wasting resources – From the network engineer perspective now the whole VxRail environment looks like a single endpoint. The SFS becomes part of the engineered solution and environment can be treated as one thing with only a few uplinks into the network.

3. Scale – The automated SFS fabric takes away the complexity of scale. The SFS network can scale as more and more racks of VxRail are introduced and still maintain automation over the environment.

Figure 3 - Leaf-Spine SFS Network

4. Network Architecture – SFS is engineered alongside VxRail and understands what is attached to it. The design of the leaf-spine network that SFS implements is a modern architectural design ideally suited to VxRail. There is no need to go through a lengthy consultation process to understand all the requirements, design a suitable network then implement.

There are other operational benefits to SFS with VxRail too.

Lifecycle management of the fabric is simple. VxRail and SFS engineering teams work together to create and test firmware and software versions together to ensure compatibility. When it comes time for a VxRail update the release notes contain the matching OS10 Smart Fabric code version. The switch code can be upgraded non-disruptively by uploading the bundle directly into the web interface. OMNI then automates the task of implementing the upgrade.

When you unplug a cable from a SFS enabled switch the fabric will detect that and remove the config from the port. This is an incredible benefit to security focused organisations, as it removes the ability to physically gain network access by plugging in a rogue device.

SFS can also understand what has been plugged in and configure a port to suit. For example, if you unplug a VxRail node from its port, that port will be reset to a default safe state. If you then plug that same VxRail node into a different port, SFS will see it, know what it is and configure the new port correctly. This all happens without any user input. I worked with a customer that had a need to shuffle all the VxRail nodes across a few ports to balance out the load. We were able to do this in their live environment seamlessly without ever touching the switch CLI.

When adding new VxRail nodes to your cluster there is no configuration required on the switches. When you plug in the new node SFS will know what it is and configure the ports for discovery. The node will appear within the vCenter VxRail plugin ready to be added. Once the VxRail automation workflow is completed the switch ports will also be configured ready to host workload.

Figure 4 - Node discovered in vCenter

Figure 5 - Node successfully added

This is a high level look at how SFS with VxRail can be of benefit. It is a conversation that I have found myself having regularly and everyone seems to be surprised when they learn that we have SFS available and the numerous things it can do.