How Nova components work together-5 minutes a day to play with OpenStack (24)

Nova Physical Deployment Scenario

We've seen that Nova is made up of a lot of sub-services, and we know that OpenStack is a distributed system that can be deployed to several nodes, and then you might ask: How do Nova's services physically be deployed?

For Nova, these services are deployed on two types of nodes: compute nodes and control nodes. The Hypervisor is installed on the compute node, which runs the virtual machine. So: 1. Only nova-compute need to be placed on the compute nodes. 2. Other sub-services are placed on the control node.

Below we can look at the specific deployment of the experimental environment. View running Nova sub-services by running Ps-elf|grep Nova on compute nodes and control nodes

COMPUTE Nodes

The Nova-compute child service is only running on the compute node devstack-compute1

Control Node

Several nova-* sub-services are running on the control node Devstack-controller

RabbitMQ and MySQL are also placed on the control node.

Perhaps the attentive classmate has found that our control node is also running on the Nova-compute. This actually means that the Devstack-controller is both a control node, a compute node, and a virtual machine running on it.

This also shows us the flexibility of the distributed architecture deployment of OpenStack: All services can be placed on a single physical machine as a all-in-one test environment, and services can be deployed on multiple physical machines for better performance and high availability.

Alternatively, you can use Nova service-list to see which nodes the nova-* sub-service is distributed on

how nova-* Sub-services work together from the virtual machine creation process

From the point of view of learning Nova, virtual machine creation is a very good scene, involving the nova-* sub-service is full, the following is a flowchart.

2. The customer (which can be an OpenStack end-user or other program) sends a request to the API (NOVA-API): "Create a virtual machine for me"

4. After the API has made some necessary processing of the request, a message is sent to Messaging (RabbitMQ): "Let Scheduler create a virtual machine"

6. Scheduler (Nova-scheduler) Gets the message from Messaging to the API, then executes the scheduling algorithm and selects node A from several compute nodes

8. Scheduler sent a message to Messaging: "Create this virtual machine on compute node A"

10. The Compute (nova-compute) of compute node A obtains the message Scheduler sent to it from Messaging, and then starts the virtual machine on the Hypervisor of this node.

12. In the process of virtual machine creation, Compute sends a message to conductor (nova-conductor) via Messaging If the database information needs to be queried or updated, conductor is responsible for database access.

The above is a few steps to create the core of the virtual machine, of course, also omitted a lot of details, we will discuss in detail in later chapters. These steps show us the way the collaboration between the nova-* sub-services is, and the distributed design of the entire OpenStack system, which is very helpful for us to gain an in-depth understanding of OpenStack.

In the next section we will detail the general design ideas for OpenStack components.

How Nova components work together-5 minutes a day to play with OpenStack (24)