The functions of cells allow users to expand the openstack computing cloud in a more dispersed manner without using complex technologies, such as databases and Message Queue clusters. It aims to support large-scale deployment.
When this feature is enabled, hosts in the openstack computing cloud are grouped into cells. Cells can be configured as a tree structure. The host of the cell on the top layer should run the NOVA-API service, but there is no Nova-compute service. Each childcell should run all the NOVA-* services except the NOVA-API in the conventional computing cloud. It can be considered that, as cells for normal computing deployment, each cell has its own database server and Message Queue proxy.
The Nova-cells Service is responsible for communication between cells and selecting a cell for a new instance. All cells need this service. Communication between cells is pluggable, and the only choice is to implement communication through rpc.
Cells scheduling is independent of host scheduling. Nova-cells first needs to find a cell (the current selection is random, and the filtering/weighing function and broadcast-based capacity/capability decision will be added in future versions ). Once a cell is selected and a new generation request is sent to the Nova-cells service, it will be sent to the host scheduling of the cell and the generation process will be used as the cells that do not exist.
For how to configure Nova-cells, see https://wiki.openstack.org/wiki/Blueprint-nova-compute-cells
Cell features
1. The purpose is to support large-scale deployment;
2. The cell structure is in the tree format;
3. The hosts in the top-level cell (API cell) run the NOVA-API service without the NOVA-compute service and do not perceive the underlying physical hosts and virtualization;
4. The sub-cell does not have the NOVA-API service;
5. Each sub-cell should run all the NOVA-* services in the conventional openstack cloud computing, except the NOVA-API service;
6. Each cell in the tree has its own database service and Message Queue Service;
7. In terms of design, communication between cells is pluggable, that is, multiple message communication frameworks will be supported in the future. Currently, communication between cells is only implemented through the RPC service;
8. The cell service is used to separate cell scheduling from host node scheduling;
9. when a new instance is created, the Nova-cells service selects cell. Currently, the cell is selected randomly. In the future, the filter/weight function will be added. You can also obtain parameters such as capacity/capabilities based on broadcast;
10. The cell function is disabled by default;
Cells Architecture
In the API cell node, you must deploy the NOVA-API to provide unified services, while the NOVA-Cell is responsible for communication with the sub-cell. In the Sub-cell node, you must deploy the NOVA-cell, if the sub-cell is directly connected to the virtualization layer, You need to deploy the NOVA-schedute and Nova-compute.
It is a cascade of three cells. After receiving the request, the API cell forwards the message to the Child cell node through the scheduling algorithm provided by NOVA-cell through the message queue, perform the same work as the API cell on the Child cell node. Select a grandchild cell and continue forwarding. perform real host Scheduling On the grandchild node and select the host to create a virtual machine.
References
Https://wiki.openstack.org/wiki/Blueprint-nova-compute-cells
Http://blog.csdn.net/lynn_kong/article/details/8564558
Http://m.blog.csdn.net/blog/ustc_dylan/17758393
Http://m.blog.csdn.net/blog/gaoxingnengjisuan/13631401
Http://m.blog.csdn.net/blog/gaoxingnengjisuan/14216977
Nova-cells source code parsing 1 http://blog.csdn.net/gaoxingnengjisuan/article/details/14216977
Nova-cells source code parsing 2 http://blog.csdn.net/gaoxingnengjisuan/article/details/14484033