Since the announcement of Mirantis’ partnership with VMware at the Fall 2013 OpenStack Summit in Hong Kong, the two companies have collaborated to automate deployment and management by Mirantis OpenStack of VMware vCenter hypervisor and VMWare NSX networking via a pluggable set of VMware drivers.
The speed with which this integration has come together is a testament to the power of OpenStack’s abstractions for component, APIs and drivers, and the flexibility and relative ease with which the Fuel control pane can be taught new tricks. For customers, the collaboration brings important new capabilities to the table, with important contributions from both sides of the aisle.
In last week’s blog post, we mentioned that you’re likely to view the integration OpenStack with VMware differently depending on where you come from: i.e., whether you are a committed/experienced VMware type, or conversely, or if you are more well-versed in the OpenStack way of doing things. While benefits accrue to both sides, what’s more interesting is to look at these new choices as a range of powerful go-forward options; it’s not intended in any way to be a temporary stopover in a migration towards some lowest common denominator.
How’s OpenStack fit in?
OpenStack provides a framework that orchestrates, builds and manages clouds by discovering hardware and installing and configuring a long list of collaborative software components for hypervisor, CPU and platform virtualization, storage abstraction and virtualization, network virtualization, metrics and more.
While all these underlying components have their own APIs, using these APIs directly to build and maintain clouds would be dauntingly complex, time-consuming and prone to error. It would mean knowing all the APIs, and also knowing each component intimately – even though many versions of a component may be in use at any given time. And even more challenging, most components are themselves evolving rapidly in response to end-user requests, the changing IT landscape, and constant shifts in dependencies on other components.
Without a framework like OpenStack to manage this complexity overall (plus many subsidiary components that manage aspects of lower-level complexity), open clouds would not be the agile, flexible, powerful solutions that they are, and component evolution itself would become stalled.
OpenStack replaces this welter of product-specific APIs with tools for creating an abstract cloud with compute, storage and network components, and a single set of APIs for managing these, most of which are further simplified by placing them under the control of web-based management tools, providing a point-and-click cloud creation and administration experience. The OpenStack system directs vendor components via drivers that (in most cases) vendors themselves maintain as part of the OpenStack community. In this way, OpenStack empowers members to maintain close compatibility with the ecosystem through collaborative abstraction, while insuring that what makes their contributions uniquely valuable is easily accessible to users.
OpenStack distributions typically ship with deployment automation – usually scripts — that help implementors create variable cluster configurations. If appropriately designed, these configurations can coexist within hardware pools.
Mirantis OpenStack, with Fuel, takes cluster configuration to another level of ease-of-use, speed and flexibility. It enables rapid deployment and single-pane-of-glass management of multiple cluster configurations.
And VMware fits in how?
Historically, OpenStack users might deploy VMWare alongside Mirantis OpenStack (or some arbitrary ACME OpenStack distro), using VMWare deployment tools. In the best case, this was unwieldy – requiring two distinct deployment and management processes, and using at least two sets of tools to maintain the enterprise cloud.
But now that Fuel knows how to deploy and manage vCenter (courtesy of the VMWare vCenter plugin) everything makes more sense. VMware runs in the same regime as OpenStack clusters, and the VMware virtual infrastructure can be managed via OpenStack (FUEL, Horizon, etc.). The big, obvious benefit is that you can now run VMware workloads, which is a critical use-case for the majority of cloud-enabled enterprises today. But that’s far from all.
Just as easily, operators of the VMware virtualization layer can use VMware’s familiar tools to see inside the OpenStack layer running on top, which offers new opportunities for rapid troubleshooting, accelerated maintenance along with cluster and hardware fine-tuning. This is where the ‘pets vs. cattle’ thing becomes a happy, diverse barnyard: critical enterprise workloads run on ultra-stable strongly-emulated VMware virtualization, alongside genericized, ‘cattle’ machines that serve the buildout of cloud-aware applications at high cost efficiency.
But even that’s not all. VMware stuff is pretty strong (okay: ‘best of breed’) in a few key areas, and integrating OpenStack with VMware means you can exploit these refined solutions to increase uptime, efficiency and flexibility in your datacenter.
For example, you can use VMware NSX networking – provided as a Neutron plugin – to build virtual networks in OpenStack with L2 segments, then link these via L3 segments to one another, WAN, endpoints, internet. Another example: you can use OpenStack’s interface to direct VMware’s VMotion migration system to quickly move VMs in a cluster off given host hardware, facilitating maintenance without incurring significant downtime.
Enter the OpenStack SDDC
VMware’s Software Defined Datacenter component portfolio comprises what are arguably today’s best of breed cloud components. But placing these in the context of OpenStack’s framework, VMware is doing both its own customers, and some OpenStack pure-players, a great favor – enabling customer choice and empowering customers to create future-proofed clouds today, without sacrificing familiarity and depth of established tools, or needing to re-engineer critical workloads to coexist with new, cloud-centric innovations.
See you at the webinar!