The Layers of OpenStack

I think anyone who has looked into OpenStack has read that it is complicated and difficult to install let alone operate over time. However, that’s not the point of this post–rather the point of this short post is just to discuss what pieces are involved in OpenStack and how I tend to approach deploying it, an approach that I feel simplifies the system somewhat.

Computering is complicated. Sometimes it helps to simplify it from a high level, and I use “layers” to do that. What’s more this model can help people who don’t have to understand every single component of the entire system to get in idea of what it looks like. An OpenStack production system can be very large, especially when considering all the ancilliary infrastructure required.

I do want to note that once it’s deployed the order of the layers is not all that relevant, but I think putting the layers in order prior to deployment can help people understand the components of OpenStack.

Prior to installation

Before installing all kinds of decisions have to be made, things like what server vendor will be used, same for network, datacenter requirements, what OpenStack will look like (eg. are you using Ceph for block and object, booting from volumes, nova network or neutron, neutron with a plugin, etc, etc) but I’m not going to cover any of that, rather I will just simply list what I usually install and in what order.

Before starting these layers I have applied the base OS to every server, and there is basic network connectivity on the managment network that Ansible operates over.

The Layers

I use Ansible to deploy OpenStack. Perhaps that’s why I’ve settled on the layer strategy. Ansible pretty much works in a serial fashion, one task after another, one playbook after another. Ansible is applied “top to bottom” versus something like Puppet where modules are compiled and then applied. So with Puppet order isn’t defined unless it’s specifically defined.

The basic layers are below. Some of the layers are more complicated than others, ie. have more tasks to complete.

1. ssh-keys - Setup operator ssh keys
2. node-network - Setup more comlicated /etc/network/interfaces
3. sshd - Setup sshd securely, eg. only listen on specific interfaces, no password logins, etc
4. baremetal - Some basic common requirements and security settings
5. rsyslog - Setup rsyslog server and clients
6. etc-hosts - Configure /etc/hosts
7. lxc-hosts - Configure servers that will be lxc hosts
8. lxc-containers - Start various lxc-containers
9. mariadb-galera - MySQL Galera cluster
10. haproxy - haproxy does all the API load balancing
11. rabbitmq-cluster - Rabbit cluster
12. memcached - Setup memcached servers
13. openstack-repo - If installing OpenStack from packages, setup the repo (eg. Juno, Kilo, etc)
14. keystone - Keystone authentication service
15. swift-common - Next up, Swift because it’s backing Glance
16. swift-object - Setup Swift storage nodes
17. swift-ring - Create Swift ring
18. swift-fetch-ring-files - Obtain the created Swift ring files
19. swift-distribute-ring-files - Distribute the ring files across all Swift nodes
20. swift-proxy - Configure Swift-proxy servers
21. glance - Setup Glance
22. nova-common - Next up, Nova for compute
23. nova-controller
24. nova-compute
25. neutron-common - Networking!
26. neutron-controller
27. neutron-network
28. neutron-compute
29. cinder-common - Block storage!
30. cinder-controller
31. cinder-storage
32. heat - And Heat (heat is nice and easy to install)
33. horizon - Finally the GUI

Obviously there are more pieces (metrics, monitoring, cron jobs, backups, alerting, more logging, DNS, etc) but I won’t cover those in this post. And of course there are many other OpenStack projects that could be used (and more every day).

OpenStack deployed!

Now with all those layers laid down, you have an OpenStack system. At this point the layers don’t really exist in a defined order and you are going to be operating this system over a long period of time. And that, my Internet friend, is a whole other story. :)