Mirantis OpenStack Training
Crystal Echo offer vendor certification training in Mirantis OpenStack, which is the most vendor neutral OpenStack training you are likely to find across all distributions. Sure, there will be specific Mirantis training courses designed to support Mirantis customers, however the entry level training if you are looking to operate, deploy and configure will certainly meet your needs.
OpenStack Summit, Sydney, 2017
Vanilla vs OpenStack Distributions – Update on Distinctions, Status, and Statistics
Presentation delivered by Danny Al-Gaaf at the first OpenStack Summit in Sydney on November 2017.
At some point you will have to choose an install of OpenStack for your organisation and will be quickly confronted with the question, do I go with opensource Vanilla or an OpenStack distribution?
Naturally it will depend on your use case, technical requirements, resources and organization. The presentation by Danny highlights the differences between these choices and between the distributions and their offerings.
Unfortunately, it is not as clear cut as you would like and further consideration to the OpenStack product itself such as the hypervisor platform, Ceph (unified distributed storage) base distributions and support. Additionally, new topics that weigh heavily into your decision are SDN, NFV, Container, Managed Cloud along with statistics on community contribution and market share that may influence your final decision.
The vendors who distribute OpenStack; Red Hat, SUSE, Mirantis and Ubuntu/Canonical are discussed in this presentation.
Define Vanilla OpenStack?
It’s taking upstream OpenStack without any private changes to deploy in your network. It sounds great in theory, but when you start building an OpenStack cloud solution on Vanilla upstream you must know your environment and up your knowledge, so you can answer:
- Which software do I need?
- What storage solution do I have?
- What base operating system do I need?
You will then consider other topics like which specific components of OpenStack you’ll need and what features such as CephFS, SDN Controller, Hypervisor/Container and API versions will be required. Additionally, you will consider operational topics like Automation, CI/CD and your final platform management which means release cycles, updates, SLA’s and how your organisation will be equipped to support this.
The above will have significant bearing on the ongoing operational cost and skills required to build and manage the cloud environment from a technical perspective. An example of skills required and needing to adapt would be your storage team that have been managing your NetApp environment for many years now need to be knowledgeable CEPH Engineers. This highlights there are going to be some big decisions along with many small but influential ones to make. Your organisation will need to be flexible for the change it is about to encounter.
Management needs fully to support this transformation and not get in the way and possibly another area requiring change will be the to address legal requirements and obligations you’ll have for internal and external customers using this environment.
When you get your organisation working with a fully automated environment with your vanilla upstream-based cloud solution, you’ll need experienced operators and likely full-time developers. If not, your project will likely fail. On the other hand, you proactively address that you’ll need to adapt many of your processes and change the mindset of your people. Full support from management is paramount for the success of your OpenStack deployment.
Adding to the list, you’ll need think of problems you’ll encounter with your vanilla OpenStack deployment such as how to have a bug fixed or feature implemented. You’ll need to find the time and participate in the community. Even if you do or don’t have developers you’ll be able to report your bugs and missing features back to the community, write blueprints/scope documents and supporting documentation to support your test results.
There’ll be risk in resolving your vanilla OpenStack bugs and having features added. It will heavily rely on your knowing the open source developers who will either be interested and quickly jump on your blueprint, or you’ll need to pay for someone’s time to program the changes. You should be prepared to manage this process and perform the implementation yourself.
Looking deeper into some of the OpenStack components and major projects that are highly mature and widely adopted.
There are many differing projects that have not the same level of maturity. The below displays some projects that one or another way are all supported by the different OS OpenStack Distribution vendors.
The next item to consider is what level of Automation you’ll require from your OpenStack environment. If you decide to write your own you are likely to invest a lot of time and money to ensure you don’t fail. That being said, you will then be stuck with your Automation code and won’t benefit from what the community is doing. So, an alternative is to go more with what’s found in the OpenStack the community which is primarily Ansible, Puppet, Chef and SaltStack with Juju found where people are using Canonical or Ubuntu. You are then locked in with Juju with 96% of the code coming from one company.
It’s not that you should not use Juji but be mindful of the implications of this decision for which there are many more like this to follow as you begin your OpenStack journey. There are reported cases of customers running Juju on Red Hat. Understand that the community code may not 100% fit your needs which will likely require investment to modify making it work for your environment. After this you’ll need to be aware that it could be some time before the next release or the code will not be compatible.
Looking at CEPH for storage with the main features are the RBD block devices, the RADOSGW object store and the CEPHFS distributed client system. If you refer to the automation discussed earlier you again will likely use Ansible, Puppet, Chef and SaltStack.
So, what are the alternative to using Vanilla OpenStack?
Firstly, if you decide to run vanilla OpenStack, you’ll likely not do everything yourself and will need partner with 3rd party who can provide everything you’ll need from consulting, installation, management of package updates and ongoing operations.
Alternatively, you could consider using one of the four big OpenStack distributions who can license you OpenStack and package a range of additional services to aid in your deployment.
The decision could be easy based on which logo you are already familiar with and have an existing commercial arrangement in place and quick become the preferred solution for your company. However, don’t jump too quick as there are many other elements to take into account pending your final deployment which we’ll now cover the pros and cons with four of the main distributions from Red Hat, SUSE, Mirantis, Canonical (Ubuntu), addressed in this order.
RED HAT OPENSTACK
If you already use Red Hat, you probably want to choose Red Hat right because you don’t want to change all the engineers holding years of experience managing Red Hat.
Red Hat OpenStack product is currently version 11 and it’s coming with OpenStack Ocata based on RHEL7.3 The kernel version is 3.10 but don’t be surprised that it’s not really at 3.10. There’s more code in there that’s back-ported from newer kernel versions. So, you have an enterprise kernel with a lot of features built in. Virtualisation is ESX (vCentre) and KVM.
Deployment is done via OSP Director which is based on TripleO/Ironic and Anisble (Optional) or Packstack for test environments. That’s also supported by Red Hat.
There are many services within OpenStack which the OpenStack Foundation distinguishes between core services and optional services. The core services are Nova, Neutron, Swift, Cinder, Keystone, and Glance. The above graphic shows the additional optional services which Red Hat chooses to support.
There are many packages. They still support some are only in technical preview available and some are not supported at all. The common situation between all distributions is that nobody supports everything. For example if your desired service of Designate (DNSaaS component for OpenStack) is not supported by Red Hat and is important for your deployment then you will likely begin evaluation of Mirantis OpenStack.
Looking at the lifecycle for Red Hat, a new downstream version with every upstream release with the release of Pike in a few weeks or months. Additionally, bundled in the product will be Cloudforms and will be recommended to use satellite and large installations to manage patches and licenses or subscriptions.
Last year the support model was changed similar to that of Ubuntu or Canonical so you have an LTS (long term support) release. Every three versions is an LTS release which is supported up to five years (LLR/LTS releases like r10). Compared to intermediate releases like r11 only being supported for 1 year.
They have two phases in this report. (In the first you get) In the first two years you get auto back-ports from newer versions and then the following three years you only get big bugs fixes. The intermediate releases between the LTS releases are only supported one year. For pricing it’s very common based on machine and socket-pair. Socket-pair was introduced to prevent to use large machines with a lot of sockets in the high-performance computing area paying less in licensing fees.
If you look at Red Hat CEPH storage 2.4 it is based on Jewel RHEL 7.4 or Ubuntu 16.04. It was meant to come out with Luminous but didn’t, so it will be in the next release of Luminous 3.0. You can get support for RHEL or Ubuntu, so you could also buy this product to run it on your Ubuntu installation. It comes with the deployment method is easily Red Hat Storage Console or Ansible or manually even is supported. With the next release it will be only Ansible. So, this is changing and the Red Hat Storage Console will be end-of-life.
Feature-wise, CephFS (Tech Preview) it will be in the upcoming release fully-supported. There is support for NFS (via Object Gateway) and iSCSI (Tech Preview). As iSCSI is still Tech Preview it will be supported in the next release with support for BlueStore and will remain in Tech-Preview status to the next release. For pricing it’s based on raw capacity with node limit. Another option is you can have pre-production subscriptions which are cheaper for testing environments.
Containers are currently the hot topic in the communities right now. Red Hat have OpenShift with Kubernetes and Docker with the Docker version coming from the open source version and Red Hat offer an Atomic and RHEL OS for this.
The SUSE OpenStack deployment is still shipping OpenStack Newton which is based on SLES 12 SP2 base so the kernel version is a little bit newer but with a very common LTS kernel version 4.4-base. For SUSE Virtualisation there’s many options for OpenStack supporting KVM, Xen, VMware vSphere, IBM z/VM, Kubernetes via Magnum.
SUSE deployment is performed by Crowbar and Chef.
SUSE in addition to the core OpenStack services supports many others with only a few packages currently not supported. The life cycle is different always skipping one release. So a new downstream version with every second upstream release with the next after Newton will be Pike (Q1/18).
It is recommended if you want to build appliances on your systems to use SUSE Studio and to manage everything the SUSE Manager. If you need staff to support your legacy applications but are not cloud-ready you probably also want to have the HA extension which allows you to run HA compute nodes based on KVM and Xen.
Current support for the product is 27 months after general availability. The next version which is coming up is the version 8 with Pike (aligned with SLES12-SP3) which will have 3 years support or depending on when you buy it, it will be bundled to the service pack 3. If you purchase late such as one year after the GA and SP3 is flagged for end of life in 2 years then you will only get 2 years of support.
SUSE price is very comparable with a special price for Control and Admin nodes but the rest are compute nodes are basically auto-socket-pair-based and you have the same rules as everybody depending on your SLA’s the price will reflect this.
Looking at CEPH, it is probably the most driven distribution around that’s offering HA. Offering an enterprise-ready version, they always are around half a year, ahead of Red Hat offering special features. SUSE Enterprise Storage 5 is based on Luminous with OpenATTIC based on SLES12-SP3 being a good tool is to monitor and manage CEPH.
Deployment is via DeepSea and SaltStack with feature supported for BlueStore, Data Compression on CEPH, CEPH-vessels already widely supported and CEPHFS offering multi-DMS, MDS support. iSCSI is supported, NFS Ganesha/S3 and recently CIFS Samba implementation for CEPH is in Tech Preview. Pricing per node plus there’s a base subscription to get your initial cluster with four nodes and controller nodes.
SUSE container platform support is via a product called SUSE CaaS platform based on Kubernetes, Docker (OS) in addition to offering Micro OS based on SUSE.
Additionally, SUSE obtained some assets from HPE that have been integrated which might have some implications on how the next releases will look. HPE Helion and SUSE Cloud 8 will basically base on the OpenStack side and on the under-laying on the same code base in the future. Expect some consolidation, more community engagement with more people developing.
Some experiences with SUSE is that if agreed on a specific feature you won’t pay for its development as everything is upstream and therefore everybody has the advantage of the implemented feature in their subscription. Other distributions usually charge you engineering hours depending on the feature.
Mirantis runs OpenStack Ocata and is the only distribution that doesn’t have their own base operating system. Today everything is based on Ubuntu and previously offered support for Red Hat and SUSE. Node (computer & controller) run on Ubuntu 16.04 LTS. No longer support for SLES/RHEL/Oracle).
Kernel 4.4 based virtualization support for Kubernetes, Docker and KVM.
Mirantis deployment is done via MCP Drivetrain (SaltStack-based + Jenkins/Gerrit) within CI/CD chain. There’s no traditional release model anymore with frequent updates and each time you will receive a new version of OpenStack.
Supporting only a few projects with a lot of projects that are not even technical preview. For life-cycle management every upstream release will be released depending on the CI/CD chain. When they make it available it’s usually within 1 to 6 months of the official release. Because they run it to the CI/CD chain, support exists for multiple versions of OpenStack next MCP 1.2 scheduled Q4/2017 supports Mitaka, Ocata and Pike (not Newton).
It comes with Stacklight, Drivetrain, Kubernetes support and OpenContrail (SDN solution) included. The pricing is similar as machine-based with no limitations on the socket-pairs. Support of 8×5, 24×7 with Mirantis also offering managed services.
CEPH is already included as part of MCP which is based on Luminous. and going the same way as SUSE with deployment via SaltStack and OpenATTIC (Decapod / ansible discontinued). What they used before the Decapod/ansible is discontinued.
There is no support for CephFS but support BlueStore.
Pricing for the storage is the same as server-based and they also have a container platform included there which is basically Kubernetes and Docker.
Ubuntu it’s already Pike-based. On the 16.04 LTS release of Ubuntu, Kernel-wise it’s the same as Mirantis. They also support besides KVM, Hyper V and LXD for deployment.
Canonical OpenStack (enterprise version) is not the same as Ubuntu OpenStack (community version). Canonical isn’t the official name of the product but there’s an enterprise version and community version. You will hear people say they have so many people using Ubuntu but you always have to ask yourself if it’s the enterprise or community version with support?. So while the most community developers using Ubuntu make us out of DevStack, Puppet, Ansible, SaltStack, Chef, etc, the Enterprise version uses JuJu with MaaS.
For support you see many of the additional services in a Technical Preview state with only three supported services. Excluded are PANKO and MONASCA, so you are close to having access to getting all the services.
The Ubuntu life cycle has the new downstream version with every upstream release. Additionally, if you have a large installation probably landscape is recommended for system management, security compliance and audit.
Ubuntu support model is a little complex. 5 year support for LTS versions of Ubuntu, 1.5 years for versions (N, O, P) and 3 years for OpenStack release of next TLS in former version.
Pricing is node-based per year or VM per hour with OpenStack regions (S/M/L) based on your scale of installation. With additional costs based on what level of support is required 24×7, managed etc.
For CEPH, Ubuntu’s Advantage Storage is based on Luminous and it comes with the CEPH Dashboard and OpenAttic. Feature wise CephFS is supported along with iSCSI, NFS Gateway and Erasure coding (no Juju charm) which can probably be configured manually. Rados Gateway and RBD are supported in all distributions therefore excluded from the list.
Pricing is different as it is based on usage capacity, not on how many servers you have.
The container platform supports LXD, Kubernetes, Docker (CS) which is the commercial (not community) version supported by Docker which is Juju based. It comes with entry-level 3 support for that from Docker.
Potential issues if you want to have an Open Source stack is that Landscape is not open source and does not have an Open Source license, additionally the controversial integration of ZFS which could be the single stumbling block for some companies. LXD is not supported by other distributions and there’s a vendor lock-in as a result. So, if decide to change, there will be other elements you’ll need to change as a result.
Customers have many questions to ask and decisions to make when selecting their OpenStack platform. Here’s some to consider in no particular order, which the knowledge of one question possibly changing the next question to be asked.
- Current infrastructure and skills
- Vendor relationships
- Available features
- Access to development skills in house / external
- Support options
- Upgrade paths
- Experience from others
- Community engagement, code contributions etc
- What the distributions doing in the community
- Other large customers using the same platform
- Number of changes between releases
- Bugs fix ratio, some can fix more bugs than are opened
- Licensing and final solution pricing
- Support options, problem ownership
- Budget etc.
The best start would be an evaluation or proof of concept