a0c12a5f05
Currently, ext4 is supported as default for all Linux. Also, for non-linux and non-windows OSs the default is vfat (used to be ext3). There is still support for ext3 as the default if some deployers do choose to keep that as the default, by using either virt_mkfs or default_ephemeral_format configuration option. Change-Id: I1b315043d0738bc4eec6739ad82be52e395f8d58 Closes-Bug: #1415407
513 lines
29 KiB
XML
513 lines
29 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE section [
|
|
<!ENTITY % openstack SYSTEM "../common/entities/openstack.ent">
|
|
%openstack;
|
|
]>
|
|
<chapter 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="ch_introduction-to-openstack-compute">
|
|
<title>Compute</title>
|
|
<para>The OpenStack Compute service allows you to control an
|
|
Infrastructure-as-a-Service (IaaS) cloud computing platform.
|
|
It gives you control over instances and networks, and allows
|
|
you to manage access to the cloud through users and
|
|
projects.</para>
|
|
<para>Compute does not include virtualization software.
|
|
Instead, it defines drivers that interact with underlying
|
|
virtualization mechanisms that run on your host operating
|
|
system, and exposes functionality over a web-based API.</para>
|
|
<section xml:id="section_system-architecture">
|
|
<title>System architecture</title>
|
|
<para>OpenStack Compute contains several main components.</para>
|
|
<para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>The <glossterm>cloud controller</glossterm> represents the global state
|
|
and interacts with the other components. The <literal>API server</literal>
|
|
acts as the web services front end for the cloud controller. The
|
|
<literal>compute controller</literal> provides compute server resources
|
|
and usually also contains the Compute service.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>The <literal>object store</literal> is an optional component that provides
|
|
storage services; you can also instead use OpenStack Object Storage.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>An <literal>auth manager</literal> provides authentication and
|
|
authorization services when used with the Compute system; you can also
|
|
instead use OpenStack Identity as a separate authentication service.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>A
|
|
<literal>volume controller</literal> provides fast and
|
|
permanent block-level storage for the compute servers.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>The <literal>network controller</literal> provides virtual networks to
|
|
enable compute servers to interact with each other and with the public
|
|
network. You can also instead use OpenStack Networking.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>The
|
|
<literal>scheduler</literal> is used to select the
|
|
most suitable compute controller to host an
|
|
instance.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
<para>Compute uses a messaging-based, <literal>shared nothing</literal> architecture. All
|
|
major components exist on multiple servers, including the compute, volume, and network
|
|
controllers, and the object store or image service. The state of the entire system is
|
|
stored in a database. The cloud controller communicates with the internal object store
|
|
using HTTP, but it communicates with the scheduler, network controller, and volume
|
|
controller using AMQP (advanced message queuing protocol). To avoid blocking a
|
|
component while waiting for a response, Compute uses asynchronous calls, with a callback
|
|
that is triggered when a response is received.</para>
|
|
<section xml:id="section_hypervisors">
|
|
<title>Hypervisors</title>
|
|
<para xlink:href="https://www.docker.io/">Compute controls hypervisors through an API
|
|
server. Selecting the best hypervisor to use can be difficult, and you must take budget,
|
|
resource constraints, supported features, and required technical specifications into
|
|
account. However, the majority of OpenStack development is done on systems using KVM and
|
|
Xen-based hypervisors. For a detailed list of features and support across different
|
|
hypervisors, see <link xlink:href="http://wiki.openstack.org/HypervisorSupportMatrix"
|
|
>http://wiki.openstack.org/HypervisorSupportMatrix</link>.</para>
|
|
<para>You can also orchestrate clouds using multiple
|
|
hypervisors in different availability zones. Compute
|
|
supports the following hypervisors:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><link xlink:href="https://wiki.openstack.org/wiki/Baremetal">Baremetal</link>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><link xlink:href="https://www.docker.io">Docker</link></para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><link
|
|
xlink:href="http://www.microsoft.com/en-us/server-cloud/hyper-v-server/default.aspx"
|
|
>Hyper-V</link>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><link xlink:href="http://www.linux-kvm.org/page/Main_Page">Kernel-based
|
|
Virtual Machine (KVM)</link>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><link xlink:href="https://linuxcontainers.org/">Linux Containers (LXC)</link>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><link xlink:href="http://wiki.qemu.org/Manual">Quick Emulator (QEMU)</link>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><link xlink:href="http://user-mode-linux.sourceforge.net/">User Mode Linux
|
|
(UML)</link>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><link
|
|
xlink:href="http://www.vmware.com/products/vsphere-hypervisor/support.html"
|
|
>VMware vSphere</link>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><link xlink:href="http://www.xen.org/support/documentation.html">Xen</link>
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>For more information about hypervisors, see the <link
|
|
xlink:href="http://docs.openstack.org/juno/config-reference/content/section_compute-hypervisors.html"
|
|
>Hypervisors</link> section in the
|
|
<citetitle>OpenStack Configuration
|
|
Reference</citetitle>.</para>
|
|
</section>
|
|
<section xml:id="section_users-and-projects">
|
|
<title>Tenants, users, and roles</title>
|
|
<para>The Compute system is designed to be used by different
|
|
consumers in the form of tenants on a shared system, and
|
|
role-based access assignments. Roles control the actions
|
|
that a user is allowed to perform.</para>
|
|
<para>Tenants are isolated resource containers that form the
|
|
principal organizational structure within the Compute
|
|
service. They consist of an individual VLAN, and volumes,
|
|
instances, images, keys, and users. A user can specify the
|
|
tenant by appending <literal>:project_id</literal> to
|
|
their access key. If no tenant is specified in the API
|
|
request, Compute attempts to use a tenant with the same ID
|
|
as the user.</para>
|
|
<para>For tenants, you can use quota controls to limit the:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Number of volumes that can be launched.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Number of processor cores and the amount of RAM that can be allocated.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Floating IP addresses assigned to any instance when it launches. This allows
|
|
instances to have the same publicly accessible IP addresses.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Fixed IP addresses assigned to the same instance when it launches. This allows
|
|
instances to have the same publicly or privately accessible IP addresses.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>Roles control the actions a user is allowed to perform.
|
|
By default, most actions do not require a particular role,
|
|
but you can configure them by editing the
|
|
<filename>policy.json</filename> file for user roles.
|
|
For example, a rule can be defined so that a user must
|
|
have the <parameter>admin</parameter> role in order to be
|
|
able to allocate a public IP address.</para>
|
|
<para>A tenant limits users' access to particular images. Each
|
|
user is assigned a user name and password. Keypairs
|
|
granting access to an instance are enabled for each user,
|
|
but quotas are set, so that each tenant can control
|
|
resource consumption across available hardware
|
|
resources.</para>
|
|
<note>
|
|
<para>Earlier versions of OpenStack used the term
|
|
<systemitem class="service">project</systemitem>
|
|
instead of <systemitem class="service"
|
|
>tenant</systemitem>. Because of this legacy
|
|
terminology, some command-line tools use
|
|
<parameter>--project_id</parameter> where you
|
|
would normally expect to enter a tenant ID.</para>
|
|
</note>
|
|
</section>
|
|
<section xml:id="section_storage-and-openstack-compute">
|
|
<title>Block storage</title>
|
|
<para>OpenStack provides two classes of the block storage:
|
|
ephemeral storage and persistent volume.</para>
|
|
|
|
<simplesect>
|
|
<title>Ephemeral storage</title>
|
|
<para>An ephemeral storage includes a root ephemeral volume
|
|
and an additional ephemeral volume.</para>
|
|
|
|
<para>The root disk is associated with an instance,
|
|
and exists only for the life of this very
|
|
instance. Generally, it is used
|
|
to store an instance`s root file system, persists across
|
|
the guest operating system reboots, and is removed
|
|
on an instance deletion. The amount of the root ephemeral
|
|
volume is defined by the flavor of an instance.</para>
|
|
|
|
<para>In addition to the ephemeral root volume, all default types of flavors,
|
|
except <literal>m1.tiny</literal>, which is
|
|
the smallest one, provide an additional ephemeral block
|
|
device sized between 20 and 160 GB (a configurable
|
|
value to suit an environment).
|
|
It is represented as a raw block device with
|
|
no partition table or file system. A cloud-aware operating
|
|
system can discover, format, and mount such a
|
|
storage device. OpenStack Compute defines the default file system for
|
|
different operating systems as Ext4 for Linux distributions,
|
|
VFAT for non-Linux and non-Windows operating systems, and
|
|
NTFS for Windows. However, it is possible to specify
|
|
any other filesystem type by using <parameter>virt_mkfs</parameter> or
|
|
<parameter>default_ephemeral_format</parameter> configuration options.</para>
|
|
<note>
|
|
<para>For example, the <systemitem class="service">cloud-init</systemitem> package
|
|
included into an Ubuntu's stock cloud image, by default,
|
|
formats this space as an Ext4 file system and mounts
|
|
it on <filename>/mnt</filename>.
|
|
This is a cloud-init feature, and is not an OpenStack mechanism.
|
|
OpenStack only provisions the raw storage.</para>
|
|
</note>
|
|
</simplesect>
|
|
|
|
<simplesect>
|
|
<title>Persistent volume</title>
|
|
<para>A persistent volume is represented by a persistent virtualized block device
|
|
independent of any particular instance, and provided by OpenStack Block Storage.</para>
|
|
|
|
<para>A persistent volume is created by a user, and its size
|
|
is limited only by a user's quota and availability
|
|
limits. Upon initial creation, a volume is a raw block
|
|
device without a partition table or a file system. To
|
|
partition or format a volume, you must attach it to an
|
|
instance. Once it is attached, it can be used
|
|
the same way as an external hard disk drive.
|
|
A single volume can be attached to one instance at a time,
|
|
though you can detach and reattach it to other instances
|
|
as many times as required.</para>
|
|
|
|
<para>You can configure a persistent volume as bootable and use
|
|
it to provide a persistent virtual instance similar to
|
|
the traditional non-cloud-based virtualization system.
|
|
It is still possible for the resulting instance to keep
|
|
ephemeral storage, depending on the flavor selected. In this
|
|
case, the root file system can be on the persistent volume,
|
|
and its state is maintained, even if the instance is shut down.
|
|
For more information about this type of configuration, see
|
|
the <link
|
|
xlink:href="http://docs.openstack.org/juno/config-reference/content/">
|
|
<citetitle>OpenStack Configuration Reference</citetitle></link>.
|
|
</para>
|
|
<note>
|
|
<para>A persistent volume does not provide concurrent access
|
|
from multiple instances. That type of configuration
|
|
requires a traditional network file system like NFS, or
|
|
CIFS, or a cluster file system such as GlusterFS.
|
|
These systems can be built within an OpenStack cluster,
|
|
or provisioned outside of it, but OpenStack software
|
|
does not provide these features.</para>
|
|
</note>
|
|
</simplesect>
|
|
</section>
|
|
|
|
<section xml:id="instance-mgmt-ec2compat">
|
|
<title>EC2 compatibility API</title>
|
|
<para>In addition to the native compute API, OpenStack provides
|
|
an EC2-compatible API. This API allows EC2 legacy workflows
|
|
built for EC2 to work with OpenStack. For more information and
|
|
configuration options about this compatibility API, see the <link
|
|
xlink:href="http://docs.openstack.org/juno/config-reference/content/">
|
|
<citetitle>OpenStack Configuration Reference</citetitle></link>.
|
|
</para>
|
|
<para>Numerous third-party tools and language-specific SDKs
|
|
can be used to interact with OpenStack clouds, using both
|
|
native and compatibility APIs. Some of the more popular
|
|
third-party tools are:</para>
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>Euca2ools</term>
|
|
<listitem>
|
|
<para>A popular open source command-line tool for
|
|
interacting with the EC2 API. This is
|
|
convenient for multi-cloud environments where
|
|
EC2 is the common API, or for transitioning
|
|
from EC2-based clouds to OpenStack. For more
|
|
information, see the <link
|
|
xlink:href="http://open.eucalyptus.com/wiki/Euca2oolsGuide"
|
|
>euca2ools site</link>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term>Hybridfox</term>
|
|
<listitem>
|
|
<para>A Firefox browser add-on that provides a
|
|
graphical interface to many popular public and
|
|
private cloud technologies, including
|
|
OpenStack. For more information, see the <link
|
|
xlink:href="http://code.google.com/p/hybridfox/"
|
|
> hybridfox site</link>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term>boto</term>
|
|
<listitem>
|
|
<para>A Python library for interacting with Amazon
|
|
Web Services. It can be used to access
|
|
OpenStack through the EC2 compatibility API.
|
|
For more information, see the <link
|
|
xlink:href="https://github.com/boto/boto">
|
|
boto project page on GitHub</link>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term>fog</term>
|
|
<listitem>
|
|
<para>A Ruby cloud services library. It provides
|
|
methods for interacting with a large number of
|
|
cloud and virtualization platforms, including
|
|
OpenStack. For more information, see the <link
|
|
xlink:href="https://rubygems.org/gems/fog"
|
|
> fog site</link>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term>php-opencloud</term>
|
|
<listitem>
|
|
<para>A PHP SDK designed to work with most
|
|
OpenStack- based cloud deployments, as well as
|
|
Rackspace public cloud. For more information,
|
|
see the <link
|
|
xlink:href="http://www.php-opencloud.com">
|
|
php-opencloud site</link>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</section>
|
|
<section xml:id="section_instance-building-blocks">
|
|
<title>Building blocks</title>
|
|
<para>In OpenStack the base operating system is usually copied
|
|
from an image stored in the OpenStack Image Service. This
|
|
is the most common case and results in an ephemeral
|
|
instance that starts from a known template state and loses
|
|
all accumulated states on virtual machine deletion. It is
|
|
also possible to put an operating system on a persistent
|
|
volume in the Cinder volume system. This gives a more
|
|
traditional persistent system that accumulates states,
|
|
which are preserved on the Cinder volume across the
|
|
deletion and re-creation of the virtual machine. To get a
|
|
list of available images on your system run:
|
|
<screen><prompt>$</prompt> <userinput>nova image-list</userinput>
|
|
<?db-font-size 50%?><computeroutput>+--------------------------------------+-------------------------------+--------+--------------------------------------+
|
|
| ID | Name | Status | Server |
|
|
+--------------------------------------+-------------------------------+--------+--------------------------------------+
|
|
| aee1d242-730f-431f-88c1-87630c0f07ba | Ubuntu 14.04 cloudimg amd64 | ACTIVE | |
|
|
| 0b27baa1-0ca6-49a7-b3f4-48388e440245 | Ubuntu 14.10 cloudimg amd64 | ACTIVE | |
|
|
| df8d56fc-9cea-4dfd-a8d3-28764de3cb08 | jenkins | ACTIVE | |
|
|
+--------------------------------------+-------------------------------+--------+--------------------------------------+</computeroutput></screen>
|
|
</para>
|
|
<para>The displayed image attributes are:</para>
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><literal>ID</literal></term>
|
|
<listitem>
|
|
<para>Automatically generated UUID of the
|
|
image</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><literal>Name</literal></term>
|
|
<listitem>
|
|
<para>Free form, human-readable name for
|
|
image</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><literal>Status</literal></term>
|
|
<listitem>
|
|
<para>The status of the image. Images marked
|
|
<literal>ACTIVE</literal> are available
|
|
for use.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><literal>Server</literal></term>
|
|
<listitem>
|
|
<para>For images that are created as snapshots of
|
|
running instances, this is the UUID of the
|
|
instance the snapshot derives from. For
|
|
uploaded images, this field is blank.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
<para>Virtual hardware templates are called
|
|
<literal>flavors</literal>. The default installation
|
|
provides five flavors. By default, these are configurable
|
|
by admin users, however that behavior can be changed by
|
|
redefining the access controls for
|
|
<parameter>compute_extension:flavormanage</parameter>
|
|
in <filename>/etc/nova/policy.json</filename> on the
|
|
<filename>compute-api</filename> server.</para>
|
|
<para>For a list of flavors that are available on your
|
|
system:</para>
|
|
<screen><prompt>$</prompt> <userinput>nova flavor-list</userinput>
|
|
<computeroutput>+-----+-----------+-----------+------+-----------+------+-------+-------------+-----------+
|
|
| ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public |
|
|
+-----+-----------+-----------+------+-----------+------+-------+-------------+-----------+
|
|
| 1 | m1.tiny | 512 | 1 | 0 | | 1 | 1.0 | True |
|
|
| 2 | m1.small | 2048 | 20 | 0 | | 1 | 1.0 | True |
|
|
| 3 | m1.medium | 4096 | 40 | 0 | | 2 | 1.0 | True |
|
|
| 4 | m1.large | 8192 | 80 | 0 | | 4 | 1.0 | True |
|
|
| 5 | m1.xlarge | 16384 | 160 | 0 | | 8 | 1.0 | True |
|
|
+-----+-----------+-----------+------+-----------+------+-------+-------------+-----------+</computeroutput></screen>
|
|
</section>
|
|
<section xml:id="section_compute-service-arch">
|
|
<title>Compute service architecture</title>
|
|
<para>These basic categories describe the service
|
|
architecture and information about the cloud controller.</para>
|
|
<simplesect>
|
|
<title>API server</title>
|
|
<para>At the heart of the cloud framework is an API server,
|
|
which makes command and control of the hypervisor, storage,
|
|
and networking programmatically available to users.</para>
|
|
<para>The API endpoints are basic HTTP web services
|
|
which handle authentication, authorization, and
|
|
basic command and control functions using various
|
|
API interfaces under the Amazon, Rackspace, and
|
|
related models. This enables API compatibility
|
|
with multiple existing tool sets created for
|
|
interaction with offerings from other vendors.
|
|
This broad compatibility prevents vendor
|
|
lock-in.</para>
|
|
</simplesect>
|
|
<simplesect>
|
|
<title>Message queue</title>
|
|
<para>A messaging queue brokers the interaction
|
|
between compute nodes (processing), the networking
|
|
controllers (software which controls network
|
|
infrastructure), API endpoints, the scheduler
|
|
(determines which physical hardware to allocate to
|
|
a virtual resource), and similar components.
|
|
Communication to and from the cloud controller is handled
|
|
by HTTP requests through multiple API
|
|
endpoints.</para>
|
|
<para>A typical message passing event begins with the API
|
|
server receiving a request from a user. The API server
|
|
authenticates the user and ensures that they are permitted
|
|
to issue the subject command. The availability of objects
|
|
implicated in the request is evaluated and, if available,
|
|
the request is routed to the queuing engine for the
|
|
relevant workers. Workers continually listen to the queue
|
|
based on their role, and occasionally their type host name.
|
|
When an applicable work request arrives on the queue, the
|
|
worker takes assignment of the task and begins executing it.
|
|
Upon completion, a response is dispatched to the queue
|
|
which is received by the API server and relayed to the
|
|
originating user. Database entries are queried, added, or
|
|
removed as necessary during the process.</para>
|
|
</simplesect>
|
|
<simplesect>
|
|
<title>Compute worker</title>
|
|
<para>Compute workers manage computing instances on
|
|
host machines. The API dispatches commands to
|
|
compute workers to complete these tasks:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Run instances</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Terminate instances</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Reboot instances</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Attach volumes</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Detach volumes</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Get console output</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</simplesect>
|
|
<simplesect>
|
|
<title>Network Controller</title>
|
|
<para>The Network Controller manages the networking
|
|
resources on host machines. The API server
|
|
dispatches commands through the message queue,
|
|
which are subsequently processed by Network
|
|
Controllers. Specific operations include:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Allocate fixed IP addresses</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Configuring VLANs for projects</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Configuring networks for compute
|
|
nodes</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</simplesect>
|
|
</section>
|
|
</section>
|
|
<xi:include href="compute/section_compute-images-instances.xml"/>
|
|
<xi:include href="compute/section_compute-networking-nova.xml"/>
|
|
<xi:include href="compute/section_compute-system-admin.xml"/>
|
|
<xi:include href="../common/section_support-compute.xml"/>
|
|
</chapter>
|