Mirantis Training Blog: What’s the best architecture for multiple OpenStack component databases?

Todd Bowman, Mirantis Training - June 30, 2016 - , ,

Welcome to Mirantis OpenStack Training’s monthly Q&A section. Here our instructors field questions about all aspects of OpenStack, and every month we’ll be sharing some of those answers with you here on the blog. If you have a question that you would like a Mirantis technical instructor to answer, feel free to post your comments in the section below. We will do our best to cover your question in next month’s post.

What’s the best architecture for multiple OpenStack component databases? Should they be co-located or can they be on separate nodes?

Most OpenStack components store state in an SQL database. By design, the databases do not have to be on the same database server. Each component is designed independently of other components. This allows for various components to point to a separate physical database, or to a database server that is hosting the database for other components. However, for operational efficiency the recommended best practice is that the databases should be hosted on the same database server.

Let’s take a closer look at the details of what all that means.

Typically OpenStack components store their respective state in an SQL database and they access the database using the OpenStack Oslo library. The Oslo library, in turn, uses the python SQLAlchemy library. In theory, then, OpenStack can support any SQL database that SQLAlchemy supports.

Because the components are independent projects, they have their own configuration files, such as /etc/neutron/neutron.conf, /etc/nova/nova.conf, and so on, and the database locations are defined in these individual files files.

For example, the database entry in nova.conf might look similar to the following:

connection =mysql+pymysql://user:nova@//nova?charset=utf8

While the entry in cinder.conf might look similar to:

connection =mysql+pymysql://user:cinder@//cinder?charset=utf8

The database location is specified by the IP address. Because each database is specified separately, each component can point to a different location. You can also use different kinds of databases for each component. For example you might have a situation in which Neutron uses SQLite, Nova uses MySQL, and Cinder uses PostgreSQL.

For practical purposes however, it is best to use a single database node or cluster and configure the components to point that database. This is advantageous from an operations and maintenance point of view, because it gives you fewer database servers to manage. The advantage is even more evident when using a database cluster to provide high availability, rather than a single server.

The most common database used by OpenStack deployment tools is MySQL/MariaDB. Most deployment tools will also install a database cluster, usually with 3 servers. In this case, the primary HA component of the cluster is Galera, a tool that works with a MySQL/MariaDB cluster to provide data synchronization between database servers.

You’ll also need other tools such as Pacemaker/Corosync to present a single IP address, a virtual IP (VIP), to access the database cluster. A component accesses the database via the VIP and stores the data in whichever database the VIP points to at that moment, then Galera copies the data to the other db servers.

Are you required to do it this way? Of course not; OpenStack is designed to be flexible and modular so it can work with your own specific situation.  But current best practices recommend using a single database server or a cluster of database servers to provide high availability, enabling you to start with the most stable, easiest to manage architecture and take advantage of the greater flexibility the OpenStack design allows if the need arises over time.

From Virtualization to Containerization
Learn how to move from monolithic to microservices in this free eBook
Download Now
Radio Cloud Native – Week of May 11th, 2022

Every Wednesday, Nick Chase and Eric Gregory from Mirantis go over the week’s cloud native and industry news. This week they discussed: Docker Extensions Artificial Intelligence shows signs that it's reaching the common person Google Cloud TPU VMs reach general availability Google buys MobileX, folds into Google Cloud NIST changes Palantir is back, and it's got a Blanket Purchase Agreement at the Department of Health and Human …

Radio Cloud Native – Week of May 11th, 2022
Where do Ubuntu 20.04, OpenSearch, Tungsten Fabric, and more all come together? In the latest Mirantis Container Cloud releases!

In the last several weeks we have released two updates to Mirantis Container Cloud - versions 2.16 and 2.17, which bring a number of important changes and enhancements. These are focused on both keeping key components up to date to provide the latest functionality and security fixes, and also delivering new functionalities for our customers to take advantage of in …

Where do Ubuntu 20.04, OpenSearch, Tungsten Fabric, and more all come together? In the latest Mirantis Container Cloud releases!
Monitoring Kubernetes costs using Kubecost and Mirantis Kubernetes Engine [Transcript]

Cloud environments & Kubernetes are becoming more and more expensive to operate and manage. In this demo-rich workshop, Mirantis and Kubecost demonstrate how to deploy Kubecost as a Helm chart on top of Mirantis Kubernetes Engine. Lens users will be able to visualize their Kubernetes spend directly in the Lens desktop application, allowing users to view spend and costs efficiently …

Monitoring Kubernetes costs using Kubecost and Mirantis Kubernetes Engine [Transcript]
Technical training
Learn Kubernetes & OpenStack from Deployment Experts
Prep for certification!
View schedule
Manage your cloud-native container environment with Mirantis Container Cloud

Wednesday, January 5 at 10:00 am PST
Istio in the Enterprise: Security & Scale Out Challenges for Microservices in k8s

Presented with Tetrate