So you decided to deploy OpenStack

You've probably heard about OpenStack. Damn, yes, they talk about him at every more or less related event. All and sundry advocate OpenStack. Fashionable, youth, everything is already there, Open Source, come on come. And after listening to tons of marketing bulshit, you decide: We will install OpenStack!

I did not conduct any special research on this subject, but there seems to be not so much negative reviews about him, at least in Russian. At first glance, everything looks fantastic. Well, if you please present my personal post hate OpenStack.

Prehistory

I learned about OpenStack at an OSS conference in about 2012. At that time I worked in a company actively using large clusters (100+ machines), but without virtualization, orchestrating (kickstarter + IBM CSM for the score?) And mostly with batch execution of tasks: I started, worked, took the result. A full understanding of what clouds are and why they are not needed yet, but interest has arisen. Of course, immediately there was a desire to deploy a new cool thing, which right now will do everything well.

A little later in the same year, such an opportunity presented itself, though within the framework of a startup. It was necessary to deploy a project that uses clustering and scaling, but it was necessary to isolate the environments and share resources of one machine by several services - the budget is still not rubber.
')
In general, in 2012 we deployed OpenStack, at that time it was Essex, we launched the project, lived with such a cloud infrastructure until 2014, it seems until the Grizzly release inclusive. Forces and desires to support it further were not, and OpenStack was drunk with shame.

Once upon a time I even thought of writing an article on how to put it correctly, with comments on what to pay attention to. But you know, I changed my mind. Do not put it better at all. Just do not mess. Probably, some of the theses are already outdated, write in the comments about what I m ​​*** to and did not understand, but in general I do not think that the situation has changed dramatically.

So let's get started, what I don’t like about Openstack and you’ll probably not like it.

It is too complex

Not even that. He, *****, MONSTERIOUS . No, see for yourself.



Once upon a time, when we put Essex, everything was relatively simple and clear. Keystone (authorization service), Glance (image storage service) and Nova (hypervisor management service). In addition, there was still a Horizon (dashboard) and a bunch of small and not very dependencies. Each node of the system is almost dozens of auxiliary demons. After a while it becomes scary to look at the controller node.



So, when our virtual cluster approached 20 servers, the controller node began to shamelessly slow down, for some strange reason. Well, more precisely understandable, but I do not understand why the identity service loaded the processor 100%?

From complexity comes the following disadvantage.

He is tangled

The OpenStack architecture is quite fragmented. There are a very large number of "moving parts", the relationship between which is not always absolutely clear. Did you break something? Okay, try to figure out where it broke and why. The OpenStack Foundation seems proud that the OpenStack has more than 20 million lines of code, even to the main page of its site. So, this nifiga not dignity .

The code is mostly written in Python. Thanks, OpenStack, thanks to you, I hated Python and everything related to it. Perhaps now with the documentation better, but before it almost was not. The logic may well begin in one daemon, and then with the help of requests through RabbitMQ will be executed completely in another and even on another machine. Needless to say that writing your own extensions for OpenStack is not at all easy. It's one thing if it's just a small hack, another thing if it's a full-fledged plug-in with new functionality. 5 lines of code you definitely will not do.

If you need to get under the hood to understand what is happening there ...



The fact is that being an OSS, OpenStack tries to be kind of unix-way. Those. under the hood, all these monstrous services actually pull tens and hundreds of unix-utilities according to your own logic, which you will have to learn and maybe even debazhit. With the documentation, at least it used to be, everything is bad. Why do you need to tell exactly which iptables rules we add to the host and for what? We have a super cool application that does everything by itself and does not require your intervention. Want to add your own rules? Well, good luck, the source code is open.

While you are more or less fit into the script, the authors supposed - all more or less ok. If you need to take a step aside, wait for the difficulties. Stock up on man's, patience, you may have to explore some more problems that are not directly related to the task, for example, how does RabbitMQ work and what else does he need?

This causes the following problem.

He is unreliable

It would seem logical, the more complex the system, the less reliable it is. But apparently this truth is not for everyone. Get ready to search for the source of underground knocks, run demons in the RIGHT sequence, google a lot and read logs, dig into the source and that's it.

Some decisions in my opinion are simply controversial. Is the metadata service on a virtual IP address emulated via iptables? Seriously? Very "reliable" work dnsmasq on issuing IP virtualkam. Thousands of them.

And this is compounded by the fact that ...

It gets even bigger

As I already mentioned, when we were just starting to use it, there were not so many services, although some problems were already there. But with each release of services becomes even more.

For example, look at the current list of services, each of which adds a few more daemons to your machine:

• Identity service (keystone)
• Image service (glance)
• Compute service (nova)
• Networking service (neutron)
• Dashboard (horizon)
• Block Storage service (cinder)
• Bare Metal service (ironic)
• Container Infrastructure Management service (magnum)
• Database service (trove)
• DNS service (designate)
• Key Manager service (barbican)
• Messaging service (zaqar)
• Object Storage services (swift)
• Orchestration service (heat)
• Shared File Systems service (manila)
• Telemetry Alarming services (aodh)
• Telemetry Data Collection service (ceilometer)

Yes, it is not formally necessary to install absolutely all services. But do not think that some kind of nothing, which is not in the main service, can be easily and simply added to your infrastructure.

For example, at the time of Essex there was no easy way to add an entry about your new virtual machine to your DNS service. Hands - please. Hooks? No, not heard. I did not wait for the birth of designate.

And you know what?

It breaks

From release to release. Those. Well, you have finally washed down the infrastructure of your dreams, at the very least everything works as expected, but one piece of detail is missing. And in the new release it is. Well, at least on the release notes.

Ok google, let's update our OpenStack. And here it turns out that the functionality that you happily used was cut out. Well, because. Well, he was ugly and in general, we better do it, honestly, honestly. In the next release. May be. In the meantime, here's easier for you, but it works the same! Well, do not care what is not in your case, but it works!

In our case, it was the network functionality. The network is generally a sore point, delivering the most pain in OpenStack. In general, our application consumes traffic from the Internet, sometimes very intensively. Of course, this is not quite a standard requirement, but the best option for us was when virtuals use their own host as a router, and the host itself already sends traffic to the provider. And this could be done in Essex. And it somehow worked.

And in the next release, the guys from OpenStack decided that that's that, we will cut the functionality of working with the network into a separate module (future neutron), we will implement something simple like one router per virtual network and play for now. Those. it would be necessary to send all the traffic of the whole cluster through a single node of our network, it would become a bottleneck.

As a result, OpenStack is such a thing that really works - do not touch. Do not even try to stick your ruchenki there, n ** p. It is better not to reboot even just in case, and then suddenly it will not rise again? Any update is a hindrance, nerves, hate.

He is raw (in places)

And you have a very wondrous feeling when you need a functional, say, a division into zones. Well, here you have cars with large screws, you have SSD, you have with vidyuhi, I want to split the cluster into zones so that the virtual machine falls on the machine with the necessary resource. Well, we read to dock, it seems like the availability zones are suitable. Customize, enable. And nothing. The dock says that everything should, but in practice, nothing. We climb into the code, and there.



It will be implemented. In the next release. May be. Well, you understand. See previous item.

Are there any pros, what will be the conclusions?

For me personally, the conclusion is simple. Vanilla version of OpenStack is better not to use. I do not know how things are with vendor versions and for all offices selling turnkey installations, but as for me this somewhat contradicts the ideology of the free cloud. We again get the vendor lock-in, only under a different sauce.

Want to try your luck with vanilla OpenStack? No, well, in general, please. There are many plug-ins, a large community, a marketing bulshit is generally above the roof. Good luck, in general. But for small and medium installations I would rather not advise.

In my opinion, one of the main problems of OpenStack stems from a not quite true architectural message. In an effort to make it simple for the end user, they made the total too difficult. Anyone drank to his needs turns into a nightmare, because even such a simple and banal thing as hooks on the events are not delivered. How would it simplify the implementation of many things ...

In general, after one and a half years of fighting OpenStack, we abandoned it and switched to another cloud. Infrastructure management has become simple and enjoyable, and updating versions is as simple as apt dist-upgrade.

What is this cloud and why it is more convenient OpenStack, I will try to tell in the next article. (Spoiler: this is OpenNebula).