Chris Behrens
f9a868e86c
This introduces *EXPERIMENTAL* compute cells functionality as a way to
scale nova in a more distributed fashion without having to use complicated
technologies like DB and message queue clustering.
Cells are configured as a tree and the top level cell should contain
nova-api without any nova-computes while child cells contain everything
except nova-api. One can think of a cell as a normal nova deployment in
that each cell has its own DB server and message queue broker.
The top level cell keeps a subset of data about ALL instances in all
cells in its DB. Child cells send messages to the top level cell when
instances change state. Data in 1 child cell is not shared with another
child cell.
A new service, nova-cells, is introduced that handles communication
between cells and picking of a cell for new instances. This service is
required for every cell. Communication between cells is pluggable with
the only option currently implemented being communnication via RPC.
Cells scheduling is separate from host scheduling. nova-cells first picks
a cell (currently randomly -- future patches 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'll be sent over to the host
scheduler in that cell and the build proceeds as it does without cells.
New config options are introduced for enabling and configuring the cells
code. Cells is disabled by default. All of the config options below go
under a '[cells]' section in nova.conf. These are the options that one
may want to tweak:
enable -- Turn on cells code (default is False)
name -- Name of the current cell.
capabilities -- List of arbitrary key=value pairs defining capabilities
of the current cell. These are sent to parent cells,
but aren't used in scheduling until later filter/weight
support is added.
call_timeout -- How long to wait for replies from a calls between cells
When using 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. Thus, config requirements for API cell:
--
[DEFAULT]
compute_api_class=nova.compute.cells_api.ComputeCellsAPI.
[cells]
enable=True
name=api-cell
--
Config requirements for child cell:
--
[cells]
enable=True
name=child-cell1
--
Another requirement is populating the 'cells' DB table in each cell.
Each cell needs to know about its parent and children and how to
communicate with them (message broker location, credentials, etc).
Implements blueprint nova-compute-cells
DocImpact
Change-Id: I1b52788ea9d7753365d175abf39bdbc22ba822fe
OpenStack Nova README ===================== OpenStack Nova provides a cloud computing fabric controller, supporting a wide variety of virtualization technologies, including KVM, Xen, LXC, VMWare, and more. In addition to its native API, it includes compatibility with the commonly encountered Amazon EC2 and S3 APIs. OpenStack Nova is distributed under the terms of the Apache License, Version 2.0. The full terms and conditions of this license are detailed in the LICENSE file. Nova primarily consists of a set of Python daemons, though it requires and integrates with a number of native system components for databases, messaging and virtualization capabilities. To keep updated with new developments in the OpenStack project follow `@openstack <http://twitter.com/openstack>`_ on Twitter. To learn how to deploy OpenStack Nova, consult the documentation available online at: http://docs.openstack.org In the unfortunate event that bugs are discovered, they should be reported to the appropriate bug tracker. If you obtained the software from a 3rd party operating system vendor, it is often wise to use their own bug tracker for reporting problems. In all other cases use the master OpenStack bug tracker, available at: http://bugs.launchpad.net/nova Developers wishing to work on the OpenStack Nova project should always base their work on the latest Nova code, available from the master GIT repository at: http://github.com/openstack/nova Developers should also join the discussion on the mailing list, at: https://lists.launchpad.net/openstack/ Any new code must follow the development guidelines detailed in the HACKING.rst file, and pass all unit tests. Further developer focused documentation is available at: http://nova.openstack.org/ For information on how to contribute to Nova, please see the contents of the CONTRIBUTING.rst file. -- End of broadcast