In the previous article, we introduced Nova's features and usage methods. This article will continue to explain Nova's architecture.
OpenStack Nova System Architecture
Nova includes multiple service processes, each performing different functions. The user-facing interface is the REST API, while internal components of Nova communicate via RPC to perform operations.
The API service handles REST requests, which typically involve reading/writing data from the database or sending RPC messages to other Nova services, and generates corresponding REST responses. RPC message transmission is accomplished through oslo.messaging, a common RPC message abstraction layer used across OpenStack components, enabling OpenStack services to operate without needing to know the underlying RPC implementation.
Most major Nova components can run on multiple service servers and have a manager to handle RPC messages, achieving high availability and load balancing. A key example is nova-compute, which runs as a single process on each hypervisor managed by the system (except when using VMware or Ironic drivers).
All Nova components use a shared central database. However, to simplify upgrading and reduce complexity, the database is accessed through an object layer, ensuring backward compatibility with older versions of nova-compute. Thus, nova-compute forwards all database requests via RPC to the nova-conductor component, which handles the actual operations—refer to the official documentation for detailed implementation.This article's Objects section。
Nova components and their respective functions
We can refer to the diagram in the official documentation to understand how Nova’s internal components interact with each other and with other OpenStack components, and how they communicate:
We can summarize as follows:
- Nova's interoperability with other components is through REST API
- All internal Nova components communicate via RPC provided by oslo.messaging
- All database requests from nova-compute are handled through nova-conductor
Now let's briefly describe the main responsibilities of each component:
- DB: A SQL database used for storing data, commonly using MariaDB
- API: Receives HTTP requests, translates commands, and communicates with other components via oslo.messaging RPC or HTTP
- Scheduler: Responsible for determining which hypervisor to spawn each instance on
- Compute: Manages communication between Nova and the hypervisor and guest OS
- Conductor: Handles requests requiring coordination across multiple components (such as build/resizing), and tasks like acting as a database proxy for nova-compute
- Placement: Tracks resource providers' inventory and usage
That concludes our technical overview of Nova's full architecture. If you have any unclear points, feel free to ask in the comment section.
Summary
This article completes our coverage of Nova’s full architecture and features. The next article will introduce Keystone.
Copyright Notice: All articles in this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.