In the previous article, we introduced the features and usage of Nova. This article will continue by introducing the architecture of Nova.
OpenStack Nova System Architecture
Nova consists of multiple server processes, each performing different functions. The user-facing interface is a REST API, while the various internal components of Nova communicate via RPC.
The API server handles REST requests, which typically involve database reads/writes or sending RPC messages to other Nova services, and generates the corresponding REST responses. RPC message passing is accomplished through oslo.messaging, which is an RPC message abstraction layer shared by OpenStack components, allowing them to operate without needing to worry about the underlying RPC implementation.
Most major Nova components can run on multiple servers and have a manager to listen for RPC messages, achieving high availability and load balancing. A major exception is nova-compute, which runs as a single process on each hypervisor it manages (except when using VMware or Ironic drivers).
All Nova components use a logically shared central database. However, to reduce the burden during upgrades, the database is accessed through an object layer to ensure that the upgraded control plane can still communicate with previous versions of nova-compute. Therefore, nova-compute proxies all DB requests to the nova-conductor component via RPC. For details on how this works, you can refer tothe Objects section of this article.。
Nova Components and Their Respective Functions
We can refer to the diagrams in the official documentation to understand the relationships between Nova's internal components and other OpenStack components, as well as how they communicate:
We can summarize that:
- Nova communicates with other components via REST APIs.
- Internal Nova components communicate via RPC provided by oslo.messaging.
- All database requests from nova-compute are handled through nova-conductor.
Next, I will introduce the primary functions of each component.
- DB: An SQL database used for data storage, typically MariaDB.
- API: Receives HTTP requests, converts commands, and communicates with other components via oslo.messaging RPC or HTTP.
- Scheduler: Responsible for determining which host (hypervisor) will spawn each instance.
- Compute: Manages communication between Nova, the hypervisor, and virtual machines.
- Conductor: Handles requests requiring coordination across multiple components (such as build/resize) and acts as a database proxy for nova-compute.
- Placement: Tracks the inventory and usage of resource providers.
This concludes the technical introduction to the Nova architecture. If you have any questions, feel free to ask in the comments section.
Summary
This concludes the introduction to Nova's architecture and features. The next article will introduce Keystone.
Copyright Notice: All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise specified.
