20f780cd61
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
245 lines
12 KiB
XML
245 lines
12 KiB
XML
<?xml version="1.0" encoding="utf-8"?>
|
||
<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="module001-ch005-vm-provisioning-walk-through">
|
||
<title>VM Provisioning Walk Through</title>
|
||
<para>More Content To be Added ...</para>
|
||
<para>OpenStack Compute gives you a tool to orchestrate a cloud,
|
||
including running instances, managing networks, and controlling
|
||
access to the cloud through users and projects. The underlying
|
||
open source project's name is Nova, and it provides the software
|
||
that can control an Infrastructure-as-a-Service (IaaS) cloud
|
||
computing platform. It is similar in scope to Amazon EC2 and
|
||
Rackspace Cloud Servers. OpenStack Compute does not include any
|
||
virtualization software; rather 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>
|
||
<para><guilabel>Hypervisors</guilabel></para>
|
||
<para>OpenStack Compute requires a hypervisor and Compute controls
|
||
the hypervisors through an API server. The process for selecting
|
||
a hypervisor usually means prioritizing and making decisions
|
||
based on budget and resource constraints as well as the
|
||
inevitable list of supported features and required technical
|
||
specifications. The majority of development is done with the KVM
|
||
and Xen-based hypervisors. Refer to
|
||
<link xlink:href="http://wiki.openstack.org/HypervisorSupportMatrix"></link>
|
||
<link xlink:href="http://goo.gl/n7AXnC">
|
||
http://goo.gl/n7AXnC</link>
|
||
for a detailed list of features and support across the hypervisors.</para>
|
||
<para>With OpenStack Compute, you can orchestrate clouds using
|
||
multiple hypervisors in different zones. The types of
|
||
virtualization standards that may be used with Compute
|
||
include:</para>
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>KVM- Kernel-based Virtual Machine (visit <link
|
||
xlink:href="http://goo.gl/70dvRb"
|
||
>http://goo.gl/70dvRb</link>)</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>LXC- Linux Containers (through libvirt) (visit <link
|
||
xlink:href="http://goo.gl/Ous3ly"
|
||
>http://goo.gl/Ous3ly</link>)</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>QEMU- Quick EMUlator (visit <link
|
||
xlink:href="http://goo.gl/WWV9lL"
|
||
>http://goo.gl/WWV9lL</link>)</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>UML- User Mode Linux (visit <link
|
||
xlink:href="http://goo.gl/4HAkJj"
|
||
>http://goo.gl/4HAkJj</link>)</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>VMWare vSphere4.1 update 1 and newer (visit <link
|
||
xlink:href="http://goo.gl/0DBeo5"
|
||
>http://goo.gl/0DBeo5</link>)</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Xen- Xen, Citrix XenServer and Xen Cloud Platform (XCP)
|
||
(visit <link xlink:href="http://goo.gl/yXP9t1"
|
||
>http://goo.gl/yXP9t1</link>)</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Bare Metal- Provisions physical hardware via pluggable
|
||
sub-drivers. (visit <link xlink:href="http://goo.gl/exfeSg"
|
||
>http://goo.gl/exfeSg</link>)</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
<para><guilabel>Users and Tenants (Projects)</guilabel></para>
|
||
<para>The OpenStack Compute system is designed to be used by many
|
||
different cloud computing consumers or customers, basically
|
||
tenants on a shared system, using role-based access assignments.
|
||
Roles control the actions that a user is allowed to perform. In
|
||
the default configuration, most actions do not require a
|
||
particular role, but this is configurable by the system
|
||
administrator editing the appropriate <filename>policy.json</filename>
|
||
file that
|
||
maintains the rules. For example, a rule can be defined so that
|
||
a user cannot allocate a public IP without the admin role. A
|
||
user's access to particular images is limited by tenant, but the
|
||
username and password are assigned per user. Key pairs granting
|
||
access to an instance are enabled per user, but quotas to
|
||
control resource consumption across available hardware resources
|
||
are per tenant.</para>
|
||
<para>While the original EC2 API supports users, OpenStack Compute
|
||
adds the concept of tenants. Tenants are isolated resource
|
||
containers forming the principal organizational structure within
|
||
the Compute service. They consist of a separate VLAN, volumes,
|
||
instances, images, keys, and users. A user can specify which
|
||
tenant he or she wishes to be known as by appending :project_id
|
||
to his or her 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, quota controls are available to limit
|
||
the:</para>
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Number of volumes which may be created</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Total size of all volumes within a project as measured
|
||
in GB</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Number of instances which may be launched</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Number of processor cores which may be allocated</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Floating IP addresses (assigned to any instance when it
|
||
launches so the instance has the same publicly accessible IP
|
||
addresses)</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Fixed IP addresses (assigned to the same instance each
|
||
time it boots, publicly or privately accessible, typically
|
||
private for management purposes)</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
<para><guilabel>Images and Instances</guilabel></para>
|
||
<para>This introduction provides a high level overview of what
|
||
images and instances are and description of the life-cycle of a
|
||
typical virtual system within the cloud. There are many ways to
|
||
configure the details of an OpenStack cloud and many ways to
|
||
implement a virtual system within that cloud. These
|
||
configuration details as well as the specific command-line
|
||
utilities and API calls to perform the actions described are
|
||
presented in the Image Management and Volume
|
||
Management chapters.</para>
|
||
<para>Images are disk images which are templates for virtual
|
||
machine file systems. The OpenStack Image Service is responsible
|
||
for the storage and management of images within
|
||
OpenStack.</para>
|
||
<para>Instances are the individual virtual machines running on
|
||
physical compute nodes. The OpenStack Compute service manages
|
||
instances. Any number of instances maybe started from the same
|
||
image. Each instance is run from a copy of the base image so
|
||
runtime changes made by an instance do not change the image it
|
||
is based on. Snapshots of running instances may be taken which
|
||
create a new image based on the current disk state of a
|
||
particular instance.</para>
|
||
<para>When starting an instance a set of virtual resources known
|
||
as a flavor must be selected. Flavors define how many virtual
|
||
CPUs an instance has and the amount of RAM and size of its
|
||
ephemeral disks. OpenStack provides a number of predefined
|
||
flavors which cloud administrators may edit or add to. Users
|
||
must select from the set of available flavors defined on their
|
||
cloud.</para>
|
||
<para>Additional resources such as persistent volume storage and
|
||
public IP address may be added to and removed from running
|
||
instances. The examples below show the cinder-volume service
|
||
which provide persistent block storage as opposed to the
|
||
ephemeral storage provided by the instance flavor.</para>
|
||
<para>Here is an example of the life cycle of a typical virtual
|
||
system within an OpenStack cloud to illustrate these
|
||
concepts.</para>
|
||
<para><guilabel>Initial State</guilabel></para>
|
||
<para><guilabel>Images and Instances</guilabel></para>
|
||
<para>The following diagram shows the system state prior to
|
||
launching an instance. The image store fronted by the Image
|
||
Service has some number of predefined images. In the
|
||
cloud, there is an available compute node with available vCPU,
|
||
memory and local disk resources. Plus there are a number of
|
||
predefined volumes in the
|
||
<systemitem class="service">cinder-volume</systemitem> service.
|
||
</para>
|
||
<para>Figure 2.1. Base image state with no running
|
||
instances</para>
|
||
<figure>
|
||
<title>Initial State</title>
|
||
<mediaobject>
|
||
<imageobject>
|
||
<imagedata fileref="figures/image21.png"/>
|
||
</imageobject>
|
||
</mediaobject>
|
||
</figure>
|
||
<para><guilabel>Launching an instance</guilabel></para>
|
||
<para>To launch an instance, the user selects an image, a flavor,
|
||
and other optional attributes. In this case the selected
|
||
flavor provides a root volume (as all flavors do) labeled vda in
|
||
the diagram and additional ephemeral storage labeled vdb in the
|
||
diagram. The user has also opted to map a volume from the
|
||
<systemitem class="service">cinder-volume</systemitem>
|
||
store to the third virtual disk, vdc, on this
|
||
instance.</para>
|
||
<para>Figure 2.2. Instance creation from image and run time
|
||
state</para>
|
||
<figure>
|
||
<title>Launch VM Instance</title>
|
||
<mediaobject>
|
||
<imageobject>
|
||
<imagedata fileref="figures/image09.png"/>
|
||
</imageobject>
|
||
</mediaobject>
|
||
</figure>
|
||
<para>The OpenStack system copies the base image from the image
|
||
store to local disk which is used as the first disk of the
|
||
instance (vda). Having small images will result in faster start
|
||
up of your instances as less data needs to be copied across the
|
||
network. The system also creates a new empty disk image to
|
||
present as the second disk (vdb). Be aware that the second disk
|
||
is an empty disk with an emphemeral life as it is destroyed when
|
||
you delete the instance. The compute node attaches to the
|
||
requested <systemitem class="service">cinder-volume</systemitem>
|
||
using iSCSI and maps this to the third
|
||
disk (vdc) as requested. The vCPU and memory resources are
|
||
provisioned and the instance is booted from the first drive. The
|
||
instance runs and changes data on the disks indicated in red in
|
||
the diagram.</para>
|
||
<para>There are many possible variations in the details of the
|
||
scenario, particularly in terms of what the backing storage is
|
||
and the network protocols used to attach and move storage. One
|
||
variant worth mentioning here is that the ephemeral storage used
|
||
for volumes vda and vdb in this example may be backed by network
|
||
storage rather than local disk. The details are left for later
|
||
chapters.</para>
|
||
<para><guilabel>End State</guilabel></para>
|
||
<para>Once the instance has served its purpose and is deleted
|
||
all state is reclaimed, except the persistent volume. The
|
||
ephemeral storage is purged. Memory and vCPU resources are
|
||
released. And of course the image has remained unchanged
|
||
throughout.</para>
|
||
<para>Figure 2.3. End state of image and volume after instance
|
||
exits</para>
|
||
<figure>
|
||
<title>End State</title>
|
||
<mediaobject>
|
||
<imageobject>
|
||
<imagedata fileref="figures/image22.png"/>
|
||
</imageobject>
|
||
</mediaobject>
|
||
</figure>
|
||
<para>Once you launch a VM in OpenStack, there's something more
|
||
going on in the background. To understand what's happening
|
||
behind the dashboard, lets take a deeper dive into OpenStack’s
|
||
VM provisioning. For launching a VM, you can either use
|
||
the command-line interfaces or the OpenStack dashboard.
|
||
</para>
|
||
</chapter>
|