By: Kent Erickson >>We’re talking to many organizations that are beginning to use VMware NSX for software-defined networking. It looks like it can help VMware users simplify the provisioning of secure network services to data center applications.
It’s pretty clear that network provisioning just hasn’t kept up with server provisioning. It’s easy to spin up a multi-VM application but still very challenging to establish a private layer 2 subnet with firewalls and load balancers to support the application. And we have to repeat the network process every time we need to move VMs around to handle an overloaded or failing server, too. While the number of guest OSs per server administrator is rising into the thousands, the number of network devices per network administrator is still stuck in the dozens. That’s just inefficient.
VMware NSX adds four key features to address this complexity:
- Logical switching and routing integrated in the hypervisor
- Bridging logical networks to physical network devices
- Distributed firewall built into the hypervisor
- Logical edge services – VMs that can be spun up to provide load balancing, DNS services, and the like
The useful part of these features is that they can all be deployed and configured as VMs. The switches, firewalls, and load balancers don’t need to be racked, stacked, cabled, and configured with cryptic commands in SSH sessions.
These features are aimed squarely at the VMware team. With a narrow focus, it’s not too challenging to overcome internal barriers and get NSX installed and working. Zenoss customers with NSX are beginning to move responsibility for running VMware NSX to the broader operations team, hence, we’ve made our NSX ZenPack available.
For the first release, we focused on using the new NSX API to discover and report on the NSX components. That means we’re discovering the NSX Manager (UI), Edge devices (routers and network services), Controllers and Clusters (the implementers of changes requested by the NSX Manager), virtual switches and interfaces, etc. At initial load and regularly afterward, these components and their attributes are identified and kept up to date. And, of course, the ZenPack collects NSX system events.
Performance data collection is focused on throughput through the edge devices and switch interfaces. These are logical interfaces, and it’s useful for an operations team to be able to identify what the actual throughput capacity of virtualized network devices is in practice. Sure, the theory is line rate. We need to know!
A big part of running an intelligent data center is understanding relationships between technologies, and the NSX ZenPack continues this with, for example, relationships from NSX virtual switches into vSphere portgroups, VMs, and vNICs.
Perhaps surprisingly, it also tracks relationships from NSX into OpenStack. This is the second major set of OpenStack function provided by Zenoss this year — Neutron and now NSX— building on top of existing Nova support. Expect OpenStack data centers to continue!
And as proof that we can goof up, we somehow omitted the impact relationships connecting the NSX Edge devices to the VMs they run in. Oops! It’s there — you can look at the details of the Edge device and see which VM and ESXi host it’s running in, but it just doesn’t show up in the impact graphs. That’ll get fixed.
This first release of the NSX ZenPack is just about perfect for organizations who are using Zenoss and exploring production use of VMware NSX. We’re eager to hear from customers using it— we have so many ideas of how to grow it, that we need your help in choosing!
