- Exploring Infrastructure with Purpose
- Bringing Network Administration into the Automation Age
- Exploring Infrastructure with Purpose – The Cumulus Approach
- Can Change Control and Network Automation Coexist?
- Exploring Infrastructure With Purpose – Delivering Your Strategy
- Infrastructure as Code: Free Your Intellect
Remember the early days of data center virtualization, when a single hypervisor solution promised to abstract away so many of your organization’s silos and unlock the potential of your liberated technology workers? We were all so excited to start collapsing racks of servers into neat little clusters that we overlooked a harsh truth about first generation virtualization: it trampled all over your org chart and often introduced a new layer of bureaucracy and red tape in the process.
One of the earliest examples of this problem was the provisioning process for a single VM. The amazing technology that allowed virtualization administrators to create virtual machines with a few clicks of a button had a dark secret: often, creating a VM was a far simpler process than connecting that VM to the network. In fact, the ability to rapidly provision a VM exposed a major problem with the server lifecycle in general: coordination and collaboration between server and network teams was a major bottleneck. Network teams lacked the same type of automation in their domain to quickly respond to connectivity requests from the server teams. In other words, while the process of creating a new virtual server was a few clicks, the process of creating a VLAN or assigning VLANs to switch ports was unchanged.
The initial response to this issue was converged infrastructure, a bundle of hardware and software configured to work as seamlessly as possible. But this approach had a short lifecycle thanks to our current generation of hyperconverged infrastructure, which took compute and storage and blended them together so tightly that you could no longer separate one resource pool from the other.
But networking remains an outlier, primarily because the network’s management plane is still far outside the control of the hypervisor: VLANs live on switches and routers, and only exist as port groups on the hypervisor.
Most virtualization shops have accepted that the process of adding a VM (and of adding a virtualization host as well) required a lengthy delay as a result of this disconnect. You could build a new host in an hour, and end up waiting a week for the network team to configure switch ports for the new host.
In the era of cloud, however, this delay is no longer acceptable. The notion of waiting for any IT resource has been made obsolete by the instant provisioning of network resources in the big cloud computing providers.
Enter Cumulus Networks and Nutanix
What if instead of waiting for your network team to provision your uplinks, your network could auto-provision VLANs and MLAGs as soon as a new hypervisor node was connected to the network? Cumulus Networks and Nutanix aim to solve this problem with their partnership to bring automation via open networking to your AHV clusters.
A switch running Cumulus Linux can be configured to monitor for new AHV nodes when they’re connected to an open port. MLAGs (bundled physical connections to multiple switches that are presented as a single switch to your server) can be auto-configured based on your specifications, which can drastically reduce the time needed to establish connectivity for new hypervisor nodes.
Or you can take a major step towards turning your network into an appliance and use the “Nutanix on a stick” approach, which involves downloading the Cumulus OS image to a USB thumbdrive, adding a configuration file to connect with your AHV environment, and plugging the thumb drive into your switch. When you power the switch on, Cumulus OS will auto-install, connect with Prism, and stand ready to dynamically configure server ports to handle VM traffic.
But this is just the beginning.
Thanks to an integration between the Cumulus OS and Nutanix Prism, VM lifecycle actions can drive just-in-time changes to your switches. For example, when VMs move among nodes in your AHV cluster, Prism will notify your switches of this move and the switches can respond by changing which VLANs are allowed on your uplink ports. If Cumulus detects that a VLAN is no longer in use (possibly because you’ve de-provisioned all VMs in that VLAN), the VLAN will be dropped from your aggregation groups and peer links. Security-conscious users will definitely dig this.
All of this network automation may be unsettling to shops that are still mastering virtualization. But forward-thinking organizations that have already taken the leap of adopting Nutanix AHV as their hypervisor are likely to be less risk-averse in this area, and would certainly benefit from getting educated on this technology.
Leave a Comment