Review: Mirantis takes the sting out of OpenStack deployments

Those who know OpenStack know it’s an exceptionally powerful cloud infrastructure platform. They also know it’s far from simple to build and deploy. A large number of moving parts make up a production OpenStack environment, and coordinating them can be tricky at best.

This is where Mirantis comes in. Mirantis’ OpenStack distribution includes Fuel, a deployment and management tool that takes the pain out of building an OpenStack environment. Combining a very fluid and attractive GUI with powerful behind-the-scenes orchestration, Fuel makes standing up an OpenStack infrastructure the work of a few hours, not days.

Building OpenStack

The Mirantis solution is built around a CentOS-based ISO image that installs the Fuel management framework and Web-based UI. The install is as simple as booting the ISO and walking through a few prompts. Once installed, the system boots and presents a text-based configuration interface to enter network settings for the management system. Here you will need to configure at least two interfaces: one for access to the Fuel UI and another that resides on a physical network or VLAN that connects to your physical OpenStack servers to enable PXE booting. This management system, which is built with extensive use of Docker containers and takes quite a while to build from scratch, forms the center of the Mirantis solution.

Once the Fuel deployment and management framework is built and configured, its Web UI can be accessed via a browser, and you can begin building the OpenStack environment itself.

First, of course, we need resources. This is where the PXE booting comes into play. Physical (or virtual) servers are PXE booted from the Mirantis management server and added to the Fuel UI as unallocated nodes. These systems boot to a minimal bootstrap environment that essentially runs instructions from the management server. We might boot a dozen or so systems, then note in the UI that we have 12 unallocated nodes, ready for assignment.

We can then create a new environment, give it a name, and choose whether we want the OpenStack Icehouse release running on CentOS or Ubuntu. Following this, we define the rest of the environment, such as whether we want multinode alone or multinode with high availability; the type of virtualization we need such as KVM, QEMU, or VMware; and how our networking is configured, whether it’s OpenStack Nova, or Neutron, with GRE, VLAN, or VMware NSX.

We next define our storage requirements (Cinder, Glance, or Swift for image storage, or Ceph with Nova) and whether we want to use Ceph for Cinder and Glance. From there, we can define extra services, such as Sahara for Hadoop clusters, Murano to support application stack catalogs, and Ceilometer for telemetry services.

Assigning roles and resources

These building blocks make up an OpenStack environment, and Mirantis condenses all of these pieces into a wizard that takes only a few minutes to navigate. Once defined, the environment is ready for resources to be assigned. All other environment parameters can be adjusted prior to deployment.

In the case of a general OpenStack environment with block and object storage, a few compute nodes, Nova networking, and a single controller, we might have six or seven servers assigned. We assign those nodes through the Fuel UI by selecting nodes from the unallocated pool and setting their roles in the new environment. The servers designated for storage will be assigned roles as Cinder, Swift, or Glancestorage, depending on how we configured the environment initially. We then select certain servers to be used as compute nodes and telemetry nodes for Ceilometer.

The storage and network configuration of each node can then be configured to fit the required design. This is done simply by dragging and dropping networks between interfaces on each node. In a simple Nova network configuration we will have separate public, management, storage, and Nova networks, and each will need to be on its own physical network or VLAN. By default, Mirantis will set up the public network on its own interface and use VLAN tags for management, storage, and Nova, though all of this can be changed before deployment.

The network connecting the nodes is of critical importance in ensuring a functional environment, and Mirantis has included a specific network testing tool to make sure the network is properly designed and built before deploying the environment. The network verification tool instructs each node to listen for test frames on every interface and to send out 802.1Q tagged UDP frames. The nodes listen for other nodes and send DHCP discover messages on all interfaces. This is very useful to ensure that the network is functional and no network anomalies will cause problems with deployment.

Deploying OpenStack

Assuming we've allocated our controller, compute, storage, and telemetry nodes and set up our network and OpenStack settings appropriately, we can then deploy the environment. This takes a while depending on the number of nodes in the environment and the options selected. The process starts by rebooting all nodes assigned to the environment and installs either CentOS or Ubuntu on each node. Once installation has finished, the necessary OpenStack elements are installed on each node depending on how it was assigned, and configuration of each node is performed. This is where the magic happens, as an entire OpenStack environment is built essentially automatically.

Once the nodes have completed installation, the Fuel dashboard shows all nodes as ready and instructs you to log in to the OpenStack Horizon Web UI at the IP address Fuel had assigned to an OpenStack controller node. From here, you’re working with OpenStack, with Mirantis support, and you have full control over the environment from every aspect, as if you had built it manually.

Before jumping into OpenStack itself, however, you can run a large set of tests from the Mirantis Fuel UI to make sure your environment is properly built and deployed. From the Health Check tab in the Fuel UI, you simply select some or all tests to run, then fire them off. These tests will run through the entire environment to ensure everything works as it should, including building, deploying, and destroying instances, all network tests, various OpenStack telemetry tests, and others. Assuming a clean bill of health here, your environment is ready for whatever workload you have.

Note that once your OpenStack environment has been deployed, it cannot be altered. You can add nodes to the environment, but you cannot alter the configuration of existing, assigned nodes, nor can you alter any configuration parameters for networking, component settings, or other options. If an environment is deployed, consider it locked. This means that if you need to change an environment, you must essentially destroy it and all instances running on it, then redeploy it with the new changes.

Mirantis allows for simple environment resets and deletes to take some of the sting out of this fact. If you have an environment deployed that needs a networking adjustment, you can reset the environment rather than completely destroy it. This sets all nodes back to bootstrap and destroys any data in the environment, but retains all of the configuration, so you need only to make your changes and redeploy, rather than start the configuration over from scratch. Once the changes are made, the environment can be deployed, which starts with the OS installation on each node.

Welcome to OpenStack

Following a successful deployment, you now have a functional OpenStack environment and can use the Horizon UI, the CLI, or API to drive the environment itself. At this point the management is native OpenStack, not Mirantis, and the environment is subject to all of the ups and downs of OpenStack itself, such as the fact that nodes that are offline or have been removed from the environment still appear and must be manually removed from the Nova database.

Using Horizon you can define instance flavors, upload images to deploy new instances, and do everything else OpenStack offers. What Mirantis has done is make the path from a pile of resources to a fully functional OpenStack environment incredibly easy to navigate.

While I encountered minor bugs here and there with Mirantis, such as problems reconfiguring network interfaces on the Fuel management server after the initial autoconfiguration, the overall solution is impeccably designed and a pleasure to work with. The elegance and simplicity of the Fuel UI belies the immense amount of engineering behind it that takes a number of very challenging tasks and reduces them to a few minutes of parameter selection followed by watching progress bars edge toward completion.

As with any solution that greatly simplifies arduous tasks, you lose some flexibility. After all, you are not working in the depths of the solution, but rather within the framework of the UI. Although you can dig into the underpinnings after deployment, I can see how managing very large environments with the Web UI may get unwieldy. That said, the speed and consistency of Mirantis OpenStack solution is exceptionally complete and will greatly reduce the time and hassle required to build and deploy OpenStack in any infrastructure.