openstack-manuals/doc/common/section_getstart_compute.xml
Don Domingo 20f780cd61 Apply service name conventions for Compute
There are several instances of "Compute Service" and "compute service"
in the upstream documentation. As was recently clarified in the docs
mailing list, these should be "Compute service/s". This patch corrects
all untagged instances inside normal <para> blocks.

Change-Id: Idcd7aafa0ce463e70635cb1c883a2476c1d97b5e
Partial-Bug: #1217503
2014-03-18 13:58:14 +10:00

205 lines
9.8 KiB
XML

<section xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="compute-service">
<title>Compute service</title>
<para>The Compute service is a cloud computing fabric controller,
which is the main part of an IaaS system. Use it to host and
manage cloud computing systems. The main modules are implemented
in Python.</para>
<para>Compute interacts with the Identity Service for
authentication, Image Service for images, and the Dashboard for
the user and administrative interface. Access to images is limited
by project and by user; quotas are limited per project (for
example, the number of instances). The Compute service scales
horizontally on standard hardware, and downloads images to launch
instances as required.</para>
<para>The Compute service is made up of the following functional
areas and their underlying components:</para>
<itemizedlist>
<title>API</title>
<listitem>
<para><systemitem class="service">nova-api</systemitem> service.
Accepts and responds to end user compute API calls. Supports
the OpenStack Compute API, the Amazon EC2 API, and a special
Admin API for privileged users to perform administrative
actions. Also, initiates most orchestration activities, such
as running an instance, and enforces some policies.</para>
</listitem>
<listitem>
<para><systemitem class="service">nova-api-metadata</systemitem>
service. Accepts metadata requests from instances. The
<systemitem class="service">nova-api-metadata</systemitem>
service is generally only used when you run in multi-host mode
with <systemitem class="service">nova-network</systemitem>
installations. For details, see <link
xlink:href="http://docs.openstack.org/admin-guide-cloud/content/section_metadata-service.html"
>Metadata service</link> in the <citetitle>Cloud
Administrator Guide</citetitle>.</para>
<para>On Debian systems, it is included in the <systemitem
class="service">nova-api</systemitem> package, and can be
selected through <package>debconf</package>.</para>
</listitem>
</itemizedlist>
<itemizedlist>
<title>Compute core</title>
<listitem>
<para><systemitem class="service">nova-compute</systemitem>
process. A worker daemon that creates and terminates virtual
machine instances through hypervisor APIs. For example, XenAPI
for XenServer/XCP, libvirt for KVM or QEMU, VMwareAPI for
VMware, and so on. The process by which it does so is fairly
complex but the basics are simple: Accept actions from the
queue and perform a series of system commands, like launching
a KVM instance, to carry them out while updating state in the
database.</para>
</listitem>
<listitem>
<para><systemitem class="service">nova-scheduler</systemitem>
process. Conceptually the simplest piece of code in Compute.
Takes a virtual machine instance request from the queue and
determines on which compute server host it should run.</para>
</listitem>
<listitem>
<para><systemitem class="service">nova-conductor</systemitem>
module. Mediates interactions between <systemitem
class="service">nova-compute</systemitem> and the database.
Aims to eliminate direct accesses to the cloud database made
by <systemitem class="service">nova-compute</systemitem>. The
<systemitem class="service">nova-conductor</systemitem>
module scales horizontally. However, do not deploy it on any
nodes where <systemitem class="service"
>nova-compute</systemitem> runs. For more information, see
<link
xlink:href="http://russellbryantnet.wordpress.com/2012/11/19/a-new-nova-service-nova-conductor/"
>A new Nova service: nova-conductor</link>.</para>
</listitem>
</itemizedlist>
<itemizedlist>
<title>Networking for VMs</title>
<listitem>
<para><systemitem class="service">nova-network</systemitem>
worker daemon. Similar to <systemitem class="service"
>nova-compute</systemitem>, it accepts networking tasks from
the queue and performs tasks to manipulate the network, such
as setting up bridging interfaces or changing iptables rules.
This functionality is being migrated to OpenStack Networking,
which is a separate OpenStack service.</para>
</listitem>
<listitem>
<para><systemitem class="service">nova-dhcpbridge</systemitem>
script. Tracks IP address leases and records them in the
database by using the dnsmasq <literal>dhcp-script</literal>
facility. This functionality is being migrated to OpenStack
Networking. OpenStack Networking provides a different
script.</para>
</listitem>
</itemizedlist>
<?hard-pagebreak?>
<itemizedlist>
<title>Console interface</title>
<listitem>
<para><systemitem class="service">nova-consoleauth</systemitem>
daemon. Authorizes tokens for users that console proxies
provide. See <systemitem class="service"
>nova-novncproxy</systemitem> and <systemitem
class="service">nova-xvpnvcproxy</systemitem>. This service
must be running for console proxies to work. Many proxies of
either type can be run against a single <systemitem
class="service">nova-consoleauth</systemitem> service in a
cluster configuration. For information, see <link
xlink:href="http://docs.openstack.org/trunk/config-reference/content/about-nova-consoleauth.html"
>About nova-consoleauth</link>.</para>
</listitem>
<listitem>
<para><systemitem class="service">nova-novncproxy</systemitem>
daemon. Provides a proxy for accessing running instances
through a VNC connection. Supports browser-based novnc
clients.</para>
</listitem>
<listitem>
<para><systemitem class="service">nova-console</systemitem>
daemon. Deprecated for use with Grizzly. Instead, the
<systemitem class="service">nova-xvpnvncproxy</systemitem>
is used.</para>
</listitem>
<listitem>
<para><systemitem class="service">nova-xvpnvncproxy</systemitem>
daemon. A proxy for accessing running instances through a VNC
connection. Supports a Java client specifically designed for
OpenStack.</para>
</listitem>
<listitem>
<para><systemitem class="service">nova-cert</systemitem> daemon.
Manages x509 certificates.</para>
</listitem>
</itemizedlist>
<para os="debian">In Debian, a unique
<package>nova-consoleproxy</package> package provides the
<package>nova-novncproxy</package>,
<package>nova-spicehtml5proxy</package>, and
<package>nova-xvpvncproxy</package> packages. To select
packages, edit the
<filename>/etc/default/nova-consoleproxy</filename> file or use
the <package>debconf</package> interface. You can also manually
edit the <filename>/etc/default/nova-consoleproxy</filename> file
and stop and start the console daemons.</para>
<itemizedlist>
<title>Image management (EC2 scenario)</title>
<listitem>
<para><systemitem class="service">nova-objectstore</systemitem>
daemon. Provides an S3 interface for registering images with
the Image Service. Mainly used for installations that must
support euca2ools. The euca2ools tools talk to <systemitem
class="service">nova-objectstore</systemitem> in <emphasis
role="italic">S3 language</emphasis>, and <systemitem
class="service">nova-objectstore</systemitem> translates S3
requests into Image Service requests.</para>
</listitem>
<listitem>
<para>euca2ools client. A set of command-line interpreter
commands for managing cloud resources. Though not an OpenStack
module, you can configure <systemitem class="service"
>nova-api</systemitem> to support this EC2 interface. For
more information, see the <link
xlink:href="http://www.eucalyptus.com/eucalyptus-cloud/documentation/2.0"
>Eucalyptus 2.0 Documentation</link>.</para>
</listitem>
</itemizedlist>
<itemizedlist>
<title>Command-line clients and other interfaces</title>
<listitem>
<para>nova client. Enables users to submit commands as a tenant
administrator or end user.</para>
</listitem>
<listitem>
<para>nova-manage client. Enables cloud administrators to submit
commands.</para>
</listitem>
</itemizedlist>
<itemizedlist>
<title>Other components</title>
<listitem>
<para>The queue. A central hub for passing messages between
daemons. Usually implemented with <link
xlink:href="http://www.rabbitmq.com/">RabbitMQ</link>, but
could be any AMPQ message queue, such as <link
xlink:href="http://qpid.apache.org/">Apache Qpid</link> or
<link xlink:href="http://www.zeromq.org/">Zero
MQ</link>.</para>
</listitem>
<listitem>
<para>SQL database. Stores most build-time and runtime states
for a cloud infrastructure. Includes instance types that are
available for use, instances in use, available networks, and
projects. Theoretically, OpenStack Compute can support any
database that SQL-Alchemy supports, but the only databases
widely used are SQLite3 databases (only appropriate for test
and development work), MySQL, and PostgreSQL.</para>
</listitem>
</itemizedlist>
<para>The Compute service interacts with other OpenStack services:
Identity Service for authentication, Image Service for images, and
the OpenStack dashboard for a web interface.</para>
</section>