Cells functionality allows you to scale an OpenStack Compute cloud in a more distributed fashion without having to use complicated technologies like database and message queue clustering. It is intended to support very large deployments.
When this functionality is enabled, the hosts in an OpenStack Compute cloud are
partitioned into groups called cells. Cells are configured as a tree. The top-level cell
should have a host that runs a nova-api service,
but no nova-compute services. Each child
cell should run all of the typical nova-* services
in a regular Compute cloud except for nova-api.
You can think of a cells as a normal Compute deployment in that each cell has its
own database server and message queue broker.
The nova-cells service handles communication
between cells and selecting a cell for new instances. This service is required for every cell.
Communication between cells is pluggable, with the only option currently implemented being
communication via RPC.
Cells scheduling is separate from host scheduling. nova-cells first picks a cell (currently randomly, future releases will add filtering/weighing functionality and decisions can be based on broadcasts of capacity/capabilities). Once a cell has been selected and the new build request has reached its nova-cells service, it will be sent over to the host scheduler in that cell and the build proceeds as it does without cells.
![[Warning]](../common/images/admon/warning.png) | Warning |
|---|---|
Cell functionality is currently considered experimental. |
Cells are disabled by default. All cell-related configuration options go under a
[cells] section in nova.conf. The following
cell-related options are currently supported:
enableSet this is
Trueto turn on cell functionality, which is off by default.nameName of the current cell. This must be unique for each cell.
capabilitiesList of arbitrary
key=valuecall_timeoutHow long to wait for replies from calls between cells.
The compute API class must be changed in the API cell so that requests can be proxied
via nova-cells down to the correct cell properly. Add the following to
nova.conf in the API
cell:
[DEFAULT] compute_api_class=nova.compute.cells_api.ComputeCellsAPI ... [cells] enable=True name=api
Add the following to nova.conf in the child cells, replacing
cell1 with the name of each
cell:
[DEFAULT]
# Disable quota checking in child cells. Let API cell do it exclusively.
quota_driver=nova.quota.NoopQuotaDriver
[cells]
enable=True
name=cell1Before bringing the services online, the database in each cell needs to be configured with information about related cells. In particular, the API cell needs to know about its immediate children, and the child cells need to know about their immediate agents. The information needed is the RabbitMQ server credentials for the particular cell.
Use the nova-manage cell create command to add this information to the database in each cell:
$ nova-manage cell create -h
Options:
-h, --help show this help message and exit
--name=<name> Name for the new cell
--cell_type=<parent|child>
Whether the cell is a parent or child
--username=<username>
Username for the message broker in this cell
--password=<password>
Password for the message broker in this cell
--hostname=<hostname>
Address of the message broker in this cell
--port=<number> Port number of the message broker in this cell
--virtual_host=<virtual_host>
The virtual host of the message broker in this cell
--woffset=<float>
--wscale=<float>As an example, assume we have an API cell named api and a child
cell named cell1. Within the api cell, we have the following RabbitMQ
server
info:
rabbit_host=10.0.0.10 rabbit_port=5672 rabbit_username=api_user rabbit_password=api_passwd rabbit_virtual_host=api_vhost
And in the child cell named cell1 we have the following RabbitMQ
server
info:
rabbit_host=10.0.1.10 rabbit_port=5673 rabbit_username=cell1_user rabbit_password=cell1_passwd rabbit_virtual_host=cell1_vhost
We would run this in the API cell, as root.
# nova-manage cell create --name=cell1 --cell_type=child --username=cell1_user --password=cell1_passwd --hostname=10.0.1.10 --port=5673 --virtual_host=cell1_vhost --woffset=1.0 --wscale=1.0
Repeat the above for all child cells.
In the child cell, we would run the following, as root:
# nova-manage cell create --name=api --cell_type=parent --username=api1_user --password=api1_passwd --hostname=10.0.0.10 --port=5672 --virtual_host=api_vhost --woffset=1.0 --wscale=1.0
| Configuration option=Default value | (Type) Description |
| call_timeout=60 | (IntOpt)Seconds to wait for response from a call to a cell. |
| capabilities=['hypervisor=xenserver;kvm', 'os=linux;windows'] | (ListOpt)Key/Multi-value list with the capabilities of the cell |
| driver=nova.virt.baremetal.pxe.PXE | (StrOpt)Baremetal driver back-end (pxe or tilera) |
| driver=nova.cells.rpc_driver.CellsRPCDriver | (StrOpt)Cells communication driver to use |
| enable=False | (BoolOpt)Enable cell functionality |
| instance_update_num_instances=1 | (IntOpt)Number of instances to update per periodic task run |
| instance_updated_at_threshold=3600 | (IntOpt)Number of seconds after an instance was updated or deleted to continue to update cells |
| manager=nova.cells.manager.CellsManager | (StrOpt)Manager for cells |
| manager=nova.conductor.manager.ConductorManager | (StrOpt)full class name for the Manager for conductor |
| max_hop_count=10 | (IntOpt)Maximum number of hops for cells routing. |
| name=nova | (StrOpt)name of this cell |
| reserve_percent=10.0 | (FloatOpt)Percentage of cell capacity to hold in reserve. Affects both memory and disk utilization |
| scheduler=nova.cells.scheduler.CellsScheduler | (StrOpt)Cells scheduler to use |
| topic=cells | (StrOpt)the topic cells nodes listen on |
| topic=conductor | (StrOpt)the topic conductor nodes listen on |
