OpenStack Myth-busting. (Part 2)

OpenStack has had a rocky road to acceptance, and some (I) included would argue that its still thought of as a poor cousin, deployed by few, understood by fewer, and generally not suitable for production.

In this post, I am to bust one of those myths and help people to understand that actually OpenStack is a credible choice for both public and private clouds, especially with the uncertainty brought about by the Broadcom VMWare changes.

OpenStack is hard to manage!

Is it though? Really?…

Most large application stacks are hard to manage when your new to them, and OpenStack is by no means the exception to this rule. It is complicated, its made up of multiple open source projects bundled together to provide a cloud service, usable for either internal private cloud, or to allow MSP’s and other providers to deploy public clouds.

A FULL CLOUD SERVICE, let that sink in. Its a deployable cloud service, which provides an experience similar to AWS Azure and GCP, inside your datacenter, or your home lab if your mad enough :D.

So yes it does come with some complexity. Its not something to step into with out some thought and a serious desire to learn and understand, but done right it can be an amazing platform.

What does an OpenStack platform comprise of?

I guess before we talk about how hard (or easy) an OpenStack platform is to manage, we should first take a look at what makes up an OpenStack platform.

Now im not just talking about the software, although this is important, its not the base layer. At the very bottom layer we have a network.

Network

If you have dealt with any physical infrastructure you will know that without a good solid underlying network, everything you build on top is pretty much useless. OpenStack is no different, ideally speed wise the faster the better, but anything north of 40Gbps is good. Technologies such as VXLAN/EVPN can make things easier to manage as well, but are not 100% required. What will be required is some vlans and a good network design that fits with what your looking to use the platform for.

There are lots of guides out on the internet that talk about the “ideal” network setup or design for an OpenStack network, but generally it comes down to having some vlans to segregate traffic types , and ensuring those vlans are delivered to the correct interfaces on the correct machines.

Now, if your operating your own DC’s or colo locations in a DC, im pretty sure your already doing this type of work. So the addition of OpenStack shouldn’t be too complicated….

Physical Hosts

Once you have a network layer, you need some hosts to run the OpenStack platform software, and ancillary services. OpenStack runs on top of Linux, and within reason pretty much any Distro. Mainly due to the fact that its now containerised. So as long as your hardware meets the minimum spec, you wont have an issue. There are some caveats, generally you will want 4 NICS in your hypervisor nodes, and you controller nodes. Two pairs, one pair will be for management and certain OpenStack traffic, the other pair is given over to OpenStack Neutron to become part of the OVS/OVN network.

So now the second layer are some physical hosts, running linux, and some containers. Im pretty sure your going to already be running Linux in your environment, and as such you already know how to manage, maintain and patch your linux estate, so again, nothing overly new or complex has been added to your plate.

OpenStack itself

As i alluded too before OpenStack itself is a group of projects bundled together to create the OpenStack platform. This is where the learning will begin, most tools that install OpenStack will install as containers, so if your already used to Docker (or by extension Podman), this shouldn’t cause any additional stress. All of OpenStacks main components (excluding items like RabbitMQ/MariaDB etc) are written in python and the source code is available to view, so if your that way inclinded you can go and have a poke around when troubleshooting a problem. OpenStacks components all log in a sensible way and if your used to working on Linux systems the log format will be familiar most problems that you run into will have a useful error message, or a quick google will reveal that someone has come across this problem before. If they havent then there is a great community on IRC and the mailing lists who will usually help dig into the problem. (They wont do it for you, and you will have to put some effort in)

Upgrades

Upgrades, everyones favorite boogy man. OpenStack upgrades have come a long way in a very short space of time, I used to hate them, they were the bain of my existence, fraught with complexity and a ever deepening pit of dread. Luckily as the OpenStack eco system has become more mature, and deployment tools have also matured, these upgrades are no longer always horrible. They still require thought, and they still require testing (you test all your upgrades right, RIGHT). Now with a good bit of planning and some good testing you can be confident that the upgrades will work.

Conclusion

I guess what I’m trying to show is that if your already running your own network, your own linux hosts, and your managing upgrades of other complicated software stacks, that taking on OpenStack is not the massive scary beast that people have made it out to be. You will already be exercising the the skills you need to deploy an excellent OpenStack platform, you just need to spend some time learning how OpenStack works, and how to fit it into your existing tech stack and platform plans. Will there be challenges, yes, will there be outages, and down time and tears, I expect so, but then show me a platform that doesn’t come with these challenges. I have sat watching enough VMware upgrades, internal tool upgrades, network changes and seemingly simple changes break in horrible ways, to know that no platform is ever perfect.

On a side note, if your interested in running an OpenStack platform, but feel you need some additional expertise to get yourselves off the ground, there are loads of small, medium and large consultancy firms, and OpenStack vendors who will be happy to help out.

Until next time. Steve