Mirantis OpenStack 9.0 -- Addressing the Operational Challenge
Michelle Yakura - July 12, 2016
OpenStack, as we know well, is a distributed software system. It is also 100% open-source -- i.e., no single company determines its fate, making it hard to productize. Plus it is fast-moving, and as if that’s not enough, OpenStack jiu-jitsu skills are in short supply. All of this makes it really hard for enterprise IT teams to manage OpenStack. That is exactly why we are making Mirantis OpenStack easier to operate.
(It's also why we are investing in services-led consumption models of our software, but that’s outside the scope of this blog; see Boris Renski’s Infrastructure Software is Dead blog.)
Mirantis OpenStack 9.0, our latest release, based on Mitaka, has added important new functionalities to simplify both initial deployment (Day 1) and post-deployment operations (Day 2). Also, we introduced features to make onboarding workloads easier. Finally, we didn’t forget about stability. After creating two back-to-back releases that were the most stable in the industry, we continue to invest in this very important vector. Our unrelenting effort to improve stability has won us praise from large enterprise customers.
Because no cloud is static, the focus of this release is on the shaded box, i.e., post-deployment Day 2 changes. There are lots of reasons to make post-deployment changes. It might be to add capacity, or to introduce new functionality such as StackLight via a plugin, or to change a configuration parameter, such as DHCP address ranges.
In the 9.0 release, Fuel, the OpenStack management project, enables certain plugins to be added post-deployment without having to redeploy the entire cloud. It also keeps certain settings “unlocked” after initial deployment. If a setting remains unlocked, it can similarly be changed without having to redeploy the cloud.
Next, as much as we at Mirantis might want everyone to stay within the confines of Fuel, large-scale cloud operators need more flexibility in terms of integrating with their existing tooling, so Mirantis OpenStack 9.0 can export Fuel settings to a configuration management tool.
Finally, in 9.0, Fuel keeps a history of executed tasks (for auditing, troubleshooting, etc.) and enables operators to create custom graphs of deployment tasks to enable complex lifecycle management orchestration such as rolling updates.
Of course, we continue to make Day 1 operations easier as well. In prior releases, if you encountered a networking issue or hardware problem mid-way through your deployment, you were out of luck. You had to fix the issue and restart the entire deployment process to all nodes. With 9.0, you can stop and restart deployments to fix these types of issues, and simply redeploy to the failed component.
You now also have the flexibility of staging the provisioning of the operating system and then, in a separate step, deploying OpenStack (or you can do both at the same time, as in previous releases) on any node. Again, this gives more flexibility to the whole Day 1 operation with respect to preparing an environment by merely having Fuel install the base OS, then letting you test many aspects of the environment, such as networking and HW compatibility. Next, you can trigger the deployment of OpenStack packages and services. This flexibility gains you significant savings in time with troubleshooting and redeploying if need be.
Finally, the task-based deployment feature that parallelizes tasks to speed up initial deployment by up to 2x is now fully tested and ready for production use (it was in tech preview in 8.0).
With 9.0, we have introduced a whole range of NFV infrastructure acceleration features (Intel calls them Enhanced Platform Awareness features) such as support for huge pages, SR-IOV, NUMA/CPU pinning and a technical preview of DPDK. These features had been supported by the community releases as early as the Kilo cycle; but as with everything else, we only introduce new functionality if it meets two criteria: (i) it is stable enough for production use and (ii) it is supported by Fuel for easy configuration.
For developers and DevOps practitioners, we now support the TOSCA infrastructure orchestration framework in Murano, the OpenStack application catalog and orchestrator. Murano can also simulate workflow execution, enabling you to test the workflow without having to deploy it first, speeding up the development flow of Murano application packages.
Last but not least, in 9.0 OpenStack Sahara, the big data project, supports newer versions of Cloudera CDH (v5.5) and Hortonworks HDP (v2.3 with Ambari) with high availability features, as well as Spark (v1.6). Sahara and Ironic integration is also now supported, so big data scientists who cannot afford the VM performance hit can run their jobs on bare metal servers. Additionally, the performance of the block storage device driver has been optimized.
We also have some cool new features that improve stability. First, you can set thresholds on the resources a service such as RabbitMQ can consume in terms of CPU, memory, disk, etc. This will make life for other services on the same physical (or virtual) machine that much better. Multipath drivers for SAN connectivity are also supported, so you can now have two redundant paths to storage for high availability. The legacy L3 router (as opposed to DVR) supports high-availability modes as well.
And speaking of Oracle, in the 9.0 release, we have added support for Oracle Linux. This means Mirantis OpenStack can now interoperate with Ubuntu, RHEL, VMware, Xen and now Oracle.
Also, the list of community Fuel deployment plugins continues to grow, from 170 in the last release to a current count of 220. As always, you can find a list of validated plugins in our Fuel plugin catalog.
Finally, Ubuntu users will be happy to learn that in addition to dynamically building the Ubuntu bootstrap OS (introduced in 8.0), you can now also inject additional software into the host OS image at provisioning time, enabling you to customize both the bootstrap and provisioning images.
Learn more through additional videos:
For more details on what's new and different, you can read the release notes or check out the what’s new page.
(It's also why we are investing in services-led consumption models of our software, but that’s outside the scope of this blog; see Boris Renski’s Infrastructure Software is Dead blog.)
Mirantis OpenStack 9.0, our latest release, based on Mitaka, has added important new functionalities to simplify both initial deployment (Day 1) and post-deployment operations (Day 2). Also, we introduced features to make onboarding workloads easier. Finally, we didn’t forget about stability. After creating two back-to-back releases that were the most stable in the industry, we continue to invest in this very important vector. Our unrelenting effort to improve stability has won us praise from large enterprise customers.
Tackling the difficult operational problem
This framework is useful in explaining Mirantis OpenStack lifecycle management:Because no cloud is static, the focus of this release is on the shaded box, i.e., post-deployment Day 2 changes. There are lots of reasons to make post-deployment changes. It might be to add capacity, or to introduce new functionality such as StackLight via a plugin, or to change a configuration parameter, such as DHCP address ranges.
In the 9.0 release, Fuel, the OpenStack management project, enables certain plugins to be added post-deployment without having to redeploy the entire cloud. It also keeps certain settings “unlocked” after initial deployment. If a setting remains unlocked, it can similarly be changed without having to redeploy the cloud.
Next, as much as we at Mirantis might want everyone to stay within the confines of Fuel, large-scale cloud operators need more flexibility in terms of integrating with their existing tooling, so Mirantis OpenStack 9.0 can export Fuel settings to a configuration management tool.
Finally, in 9.0, Fuel keeps a history of executed tasks (for auditing, troubleshooting, etc.) and enables operators to create custom graphs of deployment tasks to enable complex lifecycle management orchestration such as rolling updates.
Of course, we continue to make Day 1 operations easier as well. In prior releases, if you encountered a networking issue or hardware problem mid-way through your deployment, you were out of luck. You had to fix the issue and restart the entire deployment process to all nodes. With 9.0, you can stop and restart deployments to fix these types of issues, and simply redeploy to the failed component.
You now also have the flexibility of staging the provisioning of the operating system and then, in a separate step, deploying OpenStack (or you can do both at the same time, as in previous releases) on any node. Again, this gives more flexibility to the whole Day 1 operation with respect to preparing an environment by merely having Fuel install the base OS, then letting you test many aspects of the environment, such as networking and HW compatibility. Next, you can trigger the deployment of OpenStack packages and services. This flexibility gains you significant savings in time with troubleshooting and redeploying if need be.
Finally, the task-based deployment feature that parallelizes tasks to speed up initial deployment by up to 2x is now fully tested and ready for production use (it was in tech preview in 8.0).
Without workloads you get orphan clouds
Of course, OpenStack is not an end in itself. It is a means to an end -- that end being the running of workloads. Unfortunately, this obvious fact is sometimes missed, resulting in orphan clouds where no tenants sign up, and the cloud remains unused. To avoid this, we have been working hard to make it easier to run workloads on Mirantis OpenStack.With 9.0, we have introduced a whole range of NFV infrastructure acceleration features (Intel calls them Enhanced Platform Awareness features) such as support for huge pages, SR-IOV, NUMA/CPU pinning and a technical preview of DPDK. These features had been supported by the community releases as early as the Kilo cycle; but as with everything else, we only introduce new functionality if it meets two criteria: (i) it is stable enough for production use and (ii) it is supported by Fuel for easy configuration.
For developers and DevOps practitioners, we now support the TOSCA infrastructure orchestration framework in Murano, the OpenStack application catalog and orchestrator. Murano can also simulate workflow execution, enabling you to test the workflow without having to deploy it first, speeding up the development flow of Murano application packages.
Last but not least, in 9.0 OpenStack Sahara, the big data project, supports newer versions of Cloudera CDH (v5.5) and Hortonworks HDP (v2.3 with Ambari) with high availability features, as well as Spark (v1.6). Sahara and Ironic integration is also now supported, so big data scientists who cannot afford the VM performance hit can run their jobs on bare metal servers. Additionally, the performance of the block storage device driver has been optimized.
The most stable distribution
The most stable OpenStack continues to be the most stable. We have added additional tests and increased automation with more than 96% of tests automated. We are the #1 bug fixer in Mitaka with over 3,700 bugs fixed, and we fixed an additional 1,900 bugs in Mirantis OpenStack 9.0. Users often ask, “What is the value of a distribution?” In addition to lifecycle management and workload onboarding, stability is a big one. If you choose to go with trunk, you will need to create in-house expertise to deal with the latest bugs in addition to the latest features (all 1,900 in this case).We also have some cool new features that improve stability. First, you can set thresholds on the resources a service such as RabbitMQ can consume in terms of CPU, memory, disk, etc. This will make life for other services on the same physical (or virtual) machine that much better. Multipath drivers for SAN connectivity are also supported, so you can now have two redundant paths to storage for high availability. The legacy L3 router (as opposed to DVR) supports high-availability modes as well.
More flexibility and infrastructure choices
By now, you are probably familiar with our pure play philosophy. OpenStack is all we do, and instead of using it to push other products in our portfolio, we ensure that OpenStack works well with a wide ecosystem of partners, giving you best-in-class solutions. This philosophy is in direct opposition to the co-engineered philosophy that our competitors push. They state that there is so much dependency between OpenStack, the host operating system and the hypervisor that it is a huge folly to get these items from different vendors. Time will tell who is right, but we feel history is on our side. After all, if our competitors’ logic were true, Oracle databases would never have prevailed over IBM, HP or DEC.And speaking of Oracle, in the 9.0 release, we have added support for Oracle Linux. This means Mirantis OpenStack can now interoperate with Ubuntu, RHEL, VMware, Xen and now Oracle.
Also, the list of community Fuel deployment plugins continues to grow, from 170 in the last release to a current count of 220. As always, you can find a list of validated plugins in our Fuel plugin catalog.
Finally, Ubuntu users will be happy to learn that in addition to dynamically building the Ubuntu bootstrap OS (introduced in 8.0), you can now also inject additional software into the host OS image at provisioning time, enabling you to customize both the bootstrap and provisioning images.
Where to get it
So download Mirantis OpenStack 9.0 and take it for a spin. See how you can consume all of this cutting-edge innovation without spinning up an engineering team of your own.Learn more through additional videos:
For more details on what's new and different, you can read the release notes or check out the what’s new page.
