2013-09-09 22:13:48 +05:30
|
|
|
|
<?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>
|
2013-09-11 18:56:45 +05:30
|
|
|
|
<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
|
2014-03-14 09:19:14 +01:00
|
|
|
|
that can control an Infrastructure-as-a-Service (IaaS) cloud
|
2013-09-11 18:56:45 +05:30
|
|
|
|
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
|
2013-10-08 14:18:12 +02:00
|
|
|
|
and Xen-based hypervisors. Refer to
|
2013-09-11 18:56:45 +05:30
|
|
|
|
<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
|
2014-02-24 21:19:29 +01:00
|
|
|
|
administrator editing the appropriate <filename>policy.json</filename>
|
|
|
|
|
file that
|
2013-09-11 18:56:45 +05:30
|
|
|
|
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
|
2014-02-24 21:19:29 +01:00
|
|
|
|
configuration details as well as the specific command-line
|
2013-09-11 18:56:45 +05:30
|
|
|
|
utilities and API calls to perform the actions described are
|
2014-02-24 21:19:29 +01:00
|
|
|
|
presented in the Image Management and Volume
|
|
|
|
|
Management chapters.</para>
|
2013-09-11 18:56:45 +05:30
|
|
|
|
<para>Images are disk images which are templates for virtual
|
2014-02-24 21:19:29 +01:00
|
|
|
|
machine file systems. The OpenStack Image Service is responsible
|
2013-09-11 18:56:45 +05:30
|
|
|
|
for the storage and management of images within
|
|
|
|
|
OpenStack.</para>
|
|
|
|
|
<para>Instances are the individual virtual machines running on
|
2014-03-18 13:49:32 +10:00
|
|
|
|
physical compute nodes. The OpenStack Compute service manages
|
2013-09-11 18:56:45 +05:30
|
|
|
|
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
|
2014-02-24 21:19:29 +01:00
|
|
|
|
launching an instance. The image store fronted by the Image
|
|
|
|
|
Service has some number of predefined images. In the
|
2014-03-05 20:09:43 +01:00
|
|
|
|
cloud, there is an available compute node with available vCPU,
|
2013-09-11 18:56:45 +05:30
|
|
|
|
memory and local disk resources. Plus there are a number of
|
2014-02-24 21:19:29 +01:00
|
|
|
|
predefined volumes in the
|
|
|
|
|
<systemitem class="service">cinder-volume</systemitem> service.
|
|
|
|
|
</para>
|
2013-09-11 18:56:45 +05:30
|
|
|
|
<para>Figure 2.1. Base image state with no running
|
|
|
|
|
instances</para>
|
|
|
|
|
<figure>
|
|
|
|
|
<title>Initial State</title>
|
|
|
|
|
<mediaobject>
|
|
|
|
|
<imageobject>
|
2014-05-02 20:33:50 +02:00
|
|
|
|
<imagedata fileref="figures/image21.png" contentwidth="7in"/>
|
2013-09-11 18:56:45 +05:30
|
|
|
|
</imageobject>
|
|
|
|
|
</mediaobject>
|
|
|
|
|
</figure>
|
|
|
|
|
<para><guilabel>Launching an instance</guilabel></para>
|
2014-02-24 21:19:29 +01:00
|
|
|
|
<para>To launch an instance, the user selects an image, a flavor,
|
|
|
|
|
and other optional attributes. In this case the selected
|
2013-09-11 18:56:45 +05:30
|
|
|
|
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
|
2014-02-24 21:19:29 +01:00
|
|
|
|
<systemitem class="service">cinder-volume</systemitem>
|
|
|
|
|
store to the third virtual disk, vdc, on this
|
2013-09-11 18:56:45 +05:30
|
|
|
|
instance.</para>
|
|
|
|
|
<para>Figure 2.2. Instance creation from image and run time
|
|
|
|
|
state</para>
|
|
|
|
|
<figure>
|
|
|
|
|
<title>Launch VM Instance</title>
|
|
|
|
|
<mediaobject>
|
|
|
|
|
<imageobject>
|
2014-05-02 20:33:50 +02:00
|
|
|
|
<imagedata fileref="figures/image09.png" contentwidth="7in"/>
|
2013-09-11 18:56:45 +05:30
|
|
|
|
</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
|
2014-01-17 12:52:18 -05:00
|
|
|
|
instance (vda). Having small images will result in faster start
|
2013-09-11 18:56:45 +05:30
|
|
|
|
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
|
2014-02-24 21:19:29 +01:00
|
|
|
|
requested <systemitem class="service">cinder-volume</systemitem>
|
|
|
|
|
using iSCSI and maps this to the third
|
2013-09-11 18:56:45 +05:30
|
|
|
|
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>
|
2014-05-02 20:33:50 +02:00
|
|
|
|
<imagedata fileref="figures/image22.png" contentwidth="7in"/>
|
2013-09-11 18:56:45 +05:30
|
|
|
|
</imageobject>
|
|
|
|
|
</mediaobject>
|
|
|
|
|
</figure>
|
2014-01-17 12:52:18 -05:00
|
|
|
|
<para>Once you launch a VM in OpenStack, there's something more
|
2013-09-11 18:56:45 +05:30
|
|
|
|
going on in the background. To understand what's happening
|
2014-02-24 21:19:29 +01:00
|
|
|
|
behind the dashboard, lets take a deeper dive into OpenStack’s
|
2013-09-11 18:56:45 +05:30
|
|
|
|
VM provisioning. For launching a VM, you can either use
|
2014-02-24 21:19:29 +01:00
|
|
|
|
the command-line interfaces or the OpenStack dashboard.
|
2013-09-11 18:56:45 +05:30
|
|
|
|
</para>
|
2013-10-08 14:18:12 +02:00
|
|
|
|
</chapter>
|