64b6c9261e
Current folder name New folder name Book title ---------------------------------------------------------- basic-install DELETE cli-guide DELETE common common NEW admin-guide-cloud Cloud Administrators Guide docbkx-example DELETE openstack-block-storage-admin DELETE openstack-compute-admin DELETE openstack-config config-reference OpenStack Configuration Reference openstack-ha high-availability-guide OpenStack High Availabilty Guide openstack-image image-guide OpenStack Virtual Machine Image Guide openstack-install install-guide OpenStack Installation Guide openstack-network-connectivity-admin admin-guide-network OpenStack Networking Administration Guide openstack-object-storage-admin DELETE openstack-security security-guide OpenStack Security Guide openstack-training training-guide OpenStack Training Guide openstack-user user-guide OpenStack End User Guide openstack-user-admin user-guide-admin OpenStack Admin User Guide glossary NEW OpenStack Glossary bug: #1220407 Change-Id: Id5ffc774b966ba7b9a591743a877aa10ab3094c7 author: diane fleming
243 lines
14 KiB
XML
243 lines
14 KiB
XML
<section xml:id="section_compute-cells"
|
|
xmlns="http://docbook.org/ns/docbook"
|
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
|
xmlns:ns5="http://www.w3.org/1999/xhtml"
|
|
xmlns:ns4="http://www.w3.org/2000/svg"
|
|
xmlns:ns3="http://www.w3.org/1998/Math/MathML"
|
|
xmlns:ns="http://docbook.org/ns/docbook"
|
|
version="5.0">
|
|
<title>Cells</title>
|
|
<?dbhtml stop-chunking?>
|
|
<para><emphasis role="italic">Cells</emphasis> 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.</para>
|
|
<para>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 <systemitem class="service">nova-api</systemitem> service,
|
|
but no <systemitem class="service">nova-compute</systemitem> services. Each child cell
|
|
should run all of the typical <systemitem class="service">nova-*</systemitem> services in a
|
|
regular Compute cloud except for <systemitem class="service">nova-api</systemitem>. You can
|
|
think of cells as a normal Compute deployment in that each cell has its own database server
|
|
and message queue broker.</para>
|
|
<para>The <systemitem class="service">nova-cells</systemitem> service handles communication
|
|
between cells and selects cells for new instances. This service is required for every cell.
|
|
Communication between cells is pluggable, and currently the only option is communication through
|
|
RPC.</para>
|
|
<para>Cells scheduling is separate from host scheduling. <systemitem class="service">nova-cells</systemitem> first picks a
|
|
cell (now randomly, but future releases plan to add filtering/weighing functionality, and
|
|
decisions will be based on broadcasts of capacity/capabilities). Once a cell is
|
|
selected and the new build request reaches its <systemitem class="service">nova-cells</systemitem> service, it is sent
|
|
over to the host scheduler in that cell and the build proceeds as it would have without
|
|
cells.</para>
|
|
<warning>
|
|
<para>Cell functionality is currently considered experimental.</para>
|
|
</warning>
|
|
<section xml:id="cell-config-options">
|
|
<title>Cell configuration options</title>
|
|
<para>Cells are disabled by default. All cell-related configuration options go under a
|
|
<literal>[cells]</literal> section in <filename>nova.conf</filename>. The following
|
|
cell-related options are currently supported:<variablelist>
|
|
<varlistentry>
|
|
<term><literal>enable</literal></term>
|
|
<listitem>
|
|
<para>Set this is <literal>True</literal> to turn on cell functionality,
|
|
which is off by default.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><literal>name</literal></term>
|
|
<listitem>
|
|
<para>Name of the current cell. This must be unique for each cell.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><literal>capabilities</literal></term>
|
|
<listitem>
|
|
<para>List of arbitrary
|
|
<literal><replaceable>key</replaceable>=<replaceable>value</replaceable></literal>
|
|
pairs defining capabilities of the current cell.
|
|
Values include
|
|
<literal>hypervisor=xenserver;kvm,os=linux;windows</literal>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><literal>call_timeout</literal></term>
|
|
<listitem>
|
|
<para>How long in seconds to wait for replies from calls
|
|
between cells.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term>scheduler_filter_classes</term>
|
|
<listitem>
|
|
<para>Filter classes that the cells scheduler should
|
|
use. By default, uses
|
|
"<literal>nova.cells.filters.all_filters</literal>"
|
|
to map to all cells filters included with
|
|
nova.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term>scheduler_weight_classes</term>
|
|
<listitem><para>Weight classes the cells scheduler should use. By default, uses
|
|
"<literal>nova.cells.weights.all_weighers</literal>"
|
|
to map to all cells weight algorithms (weighers)
|
|
included with Compute.</para></listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term>ram_weight_multiplier</term>
|
|
<listitem>
|
|
<para>Multiplier used for weighing ram. Negative numbers
|
|
mean you want Compute to stack VMs on one host
|
|
instead of spreading out new VMs to more hosts in
|
|
the cell. Default value is 10.0.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist></para>
|
|
</section>
|
|
<section xml:id="config-API-cell">
|
|
<title>Configuring the API (top-level) cell</title>
|
|
<para>The compute API class must be changed in the API cell so that requests can be proxied
|
|
through nova-cells down to the correct cell properly. Add the following to
|
|
<filename>nova.conf</filename> in the API
|
|
cell:<programlisting language="ini">[DEFAULT]
|
|
compute_api_class=nova.compute.cells_api.ComputeCellsAPI
|
|
...
|
|
|
|
[cells]
|
|
enable=True
|
|
name=api</programlisting></para>
|
|
</section>
|
|
<section xml:id="config-child-cell">
|
|
<title>Configuring the child cells</title>
|
|
<para>Add the following to <filename>nova.conf</filename> in the child cells, replacing
|
|
<replaceable>cell1</replaceable> with the name of each
|
|
cell:<programlisting language="ini">[DEFAULT]
|
|
# Disable quota checking in child cells. Let API cell do it exclusively.
|
|
quota_driver=nova.quota.NoopQuotaDriver
|
|
|
|
[cells]
|
|
enable=True
|
|
name=<replaceable>cell1</replaceable></programlisting></para>
|
|
</section>
|
|
<section xml:id="config-cell-db">
|
|
<title>Configuring the database in each cell</title>
|
|
<para>Before 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 <application>RabbitMQ</application> server credentials
|
|
for the particular cell.</para>
|
|
<para>Use the <command>nova-manage cell create</command> command to add this information to
|
|
the database in each
|
|
cell:<screen><prompt>$</prompt> <userinput>nova-manage cell create -h</userinput>
|
|
<computeroutput>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>
|
|
(weight offset) It might be used by some cell scheduling code in the future
|
|
--wscale=<float>
|
|
(weight scale) It might be used by some cell scheduling code in the future
|
|
</computeroutput></screen></para>
|
|
<para>As an example, assume we have an API cell named <literal>api</literal> and a child
|
|
cell named <literal>cell1</literal>. Within the api cell, we have the following RabbitMQ
|
|
server
|
|
info:<programlisting language="ini">rabbit_host=10.0.0.10
|
|
rabbit_port=5672
|
|
rabbit_username=api_user
|
|
rabbit_password=api_passwd
|
|
rabbit_virtual_host=api_vhost</programlisting></para>
|
|
<para>And in the child cell named <literal>cell1</literal> we have the following RabbitMQ
|
|
server
|
|
info:<programlisting language="ini">rabbit_host=10.0.1.10
|
|
rabbit_port=5673
|
|
rabbit_username=cell1_user
|
|
rabbit_password=cell1_passwd
|
|
rabbit_virtual_host=cell1_vhost</programlisting></para>
|
|
<para>We would run this in the API cell, as
|
|
root.<screen><prompt>#</prompt> <userinput>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</userinput></screen></para>
|
|
<para>Repeat the above for all child cells.</para>
|
|
<para>In the child cell, we would run the following, as
|
|
root:<screen><prompt>#</prompt> <userinput>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
|
|
</userinput></screen></para>
|
|
<xi:include href="../../common/tables/nova-cells.xml"/>
|
|
</section>
|
|
<section xml:id="cell-weights-filters">
|
|
<title>Cell scheduling configuration</title>
|
|
<para>New for the Havana release, you can configure some cells with
|
|
higher weights so that those cells are given priority for new VMs to
|
|
be launched.</para>
|
|
<para>As an admin user, you can also add a filter that directs builds to
|
|
a particular cell. The <filename>policy.json</filename> file must
|
|
have a line with <literal>"cells_scheduler_filter:TargetCellFilter"
|
|
: "is_admin:True"</literal> to let an admin user specify a
|
|
scheduler hint to direct a build to a particular cell.</para>
|
|
<para>There are two modules available by default in the
|
|
<filename>nova.conf</filename> file so that cell selection is no
|
|
longer random. These are selected with the default
|
|
<filename>nova.conf</filename> file which has
|
|
<literal>scheduler_weight_classes=nova.cells.weights.all_weighers</literal>
|
|
as the default.</para>
|
|
<itemizedlist><listitem><para>ram_by_instance_type: Select cells with the most RAM capacity for the
|
|
instance type being requested. Since higher weights win,
|
|
Compute returns the number of available units for the
|
|
instance type requested. In nova.conf there's a
|
|
ram_weight_multiplier defaulted to 10.0 that adds to the
|
|
weight by a factor of 10.</para></listitem>
|
|
<listitem><para>weight_offset: Allows modifying the database to weight a particular cell.
|
|
You can use this when you want to disable a cell. Originally
|
|
designed so you can set a default cell by making its
|
|
weight_offset very high, like 999999999999999. The highest
|
|
weight will be first cell scheduled for launching
|
|
VMs.</para></listitem></itemizedlist>
|
|
</section>
|
|
<section xml:id="cell-config-optional-json">
|
|
<title>Optional cell configuration</title>
|
|
<para>Cells currently keeps all intercell communication data, including
|
|
usernames and passwords, in the database. This is undesirable and
|
|
unnecessary since cells data isn't updated very frequently. Instead,
|
|
create a JSON file to input cells data specified via a
|
|
<code>[cells]cells_config</code> option. When specified, the
|
|
database is no longer consulted when reloading cells data. The file
|
|
will need the columns present in the Cell model (excluding common
|
|
database fields and the <code>id</code> column). The queue
|
|
connection information must be specified through a
|
|
<code>transport_url</code> field, instead of
|
|
<code>username</code>, <code>password</code>, and so on. The
|
|
<code>transport_url</code> has the following form:</para>
|
|
<programlisting>
|
|
rabbit://<username>:<password>@<hostname>:<port>/<virtual_host>
|
|
</programlisting>
|
|
<para>The scheme may be either 'rabbit' (shown above) or 'qpid'. The following sample shows this optional configuration:</para>
|
|
<programlisting language="json">
|
|
[{
|
|
"name": "Cell1",
|
|
"api_url": "http://example.com:8774",
|
|
"transport_url": "rabbit://hare:wabbit@rabbit.cell1.example.com/cell1",
|
|
"weight_offset": 0.0,
|
|
"weight_scale": 1.0,
|
|
"is_parent": false
|
|
}, {
|
|
"name": "Parent",
|
|
"api_url": "http://example.com:8774",
|
|
"transport_url": "rabbit://hare:wabbit@rabbit.parent.example.com/parent",
|
|
"weight_offset": 0.0,
|
|
"weight_scale": 1.0,
|
|
"is_parent": true
|
|
}]
|
|
</programlisting>
|
|
</section>
|
|
</section>
|