250 lines
13 KiB
XML
250 lines
13 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-ch011-block-storage">
|
||
<title>OpenStack Block Storage</title>
|
||
<para><emphasis role="bold">Block Storage and OpenStack
|
||
Compute</emphasis></para>
|
||
<para>OpenStack provides two classes of block storage, "ephemeral"
|
||
storage and persistent "volumes". Ephemeral storage exists only
|
||
for the life of an instance, it will persist across reboots of the
|
||
guest operating system but when the instance is deleted so is the
|
||
associated storage. All instances have some ephemeral storage.
|
||
Volumes are persistent virtualized block devices independent of
|
||
any particular instance. Volumes may be attached to a single
|
||
instance at a time, but may be detached or reattached to a
|
||
different instance while retaining all data, much like a USB
|
||
drive.</para>
|
||
<para><guilabel>Ephemeral Storage</guilabel></para>
|
||
<para>Ephemeral storage is associated with a single unique instance.
|
||
Its size is defined by the flavor of the instance.</para>
|
||
<para>Data on ephemeral storage ceases to exist when the instance it
|
||
is associated with is terminated. Rebooting the VM or restarting
|
||
the host server, however, will not destroy ephemeral data. In the
|
||
typical use case an instance's root filesystem is stored on
|
||
ephemeral storage. This is often an unpleasant surprise for people
|
||
unfamiliar with the cloud model of computing.</para>
|
||
<para>In addition to the ephemeral root volume all flavors except
|
||
the smallest, m1.tiny, provide an additional ephemeral block
|
||
device varying from 20G for the m1.small through 160G for the
|
||
m1.xlarge by default - these sizes are configurable. This is
|
||
presented as a raw block device with no partition table or
|
||
filesystem. Cloud aware operating system images may discover,
|
||
format, and mount this device. For example the cloud-init package
|
||
included in Ubuntu's stock cloud images will format this space as
|
||
an ext3 filesystem and mount it on /mnt. It is important to note
|
||
this a feature of the guest operating system. OpenStack only
|
||
provisions the raw storage.</para>
|
||
<para><guilabel>Volume Storage</guilabel></para>
|
||
<para>Volume storage is independent of any particular instance and
|
||
is persistent. Volumes are user created and within quota and
|
||
availability limits may be of any arbitrary size.</para>
|
||
<para>When first created volumes are raw block devices with no
|
||
partition table and no filesystem. They must be attached to an
|
||
instance to be partitioned and/or formatted. Once this is done
|
||
they may be used much like an external disk drive. Volumes may
|
||
attached to only one instance at a time, but may be detached and
|
||
reattached to either the same or different instances.</para>
|
||
<para>It is possible to configure a volume so that it is bootable
|
||
and provides a persistent virtual instance similar to traditional
|
||
non-cloud based virtualization systems. In this use case the
|
||
resulting instance may still have ephemeral storage depending on
|
||
the flavor selected, but the root filesystem (and possibly others)
|
||
will be on the persistent volume and thus state will be maintained
|
||
even if the instance is shutdown. Details of this configuration
|
||
are discussed in the<link
|
||
xlink:href="http://docs.openstack.org/user-guide/content/"
|
||
>OpenStack End User Guide</link>.</para>
|
||
<para>Volumes do not provide concurrent access from multiple
|
||
instances. For that you need either a traditional network
|
||
filesystem like NFS or CIFS or a cluster filesystem such as
|
||
GlusterFS. These may be built within an OpenStack cluster or
|
||
provisioned outside of it, but are not features provided by the
|
||
OpenStack software.</para>
|
||
<para>The OpenStack Block Storage service works via the interaction
|
||
of a series of daemon processes named cinder-* that reside
|
||
persistently on the host machine or machines. The binaries can all
|
||
be run from a single node, or spread across multiple nodes. They
|
||
can also be run on the same node as other OpenStack
|
||
services.</para>
|
||
<para><guilabel>The current services available in OpenStack Block
|
||
Storage are:</guilabel></para>
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para><emphasis role="bold">cinder-api</emphasis> - The
|
||
cinder-api service is a WSGI app that authenticates and routes
|
||
requests throughout the Block Storage system. It supports the
|
||
OpenStack API's only, although there is a translation that can
|
||
be done via Nova's EC2 interface which calls in to the
|
||
cinderclient.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para><emphasis role="bold">cinder-scheduler</emphasis> - The
|
||
cinder-scheduler is responsible for scheduling/routing
|
||
requests to the appropriate volume service. As of Grizzly;
|
||
depending upon your configuration this may be simple
|
||
round-robin scheduling to the running volume services, or it
|
||
can be more sophisticated through the use of the Filter
|
||
Scheduler. The Filter Scheduler is the default in Grizzly and
|
||
enables filter on things like Capacity, Availability Zone,
|
||
Volume Types and Capabilities as well as custom
|
||
filters.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para><emphasis role="bold">cinder-volume</emphasis> - The
|
||
cinder-volume service is responsible for managing Block
|
||
Storage devices, specifically the back-end devices
|
||
themselves.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para><emphasis role="bold">cinder-backup</emphasis> - The
|
||
cinder-backup service provides a means to back up a Cinder
|
||
Volume to OpenStack Object Store (SWIFT).</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
<para><guilabel>Introduction to OpenStack Block
|
||
Storage</guilabel></para>
|
||
<para>OpenStack Block Storage provides persistent High Performance
|
||
Block Storage resources that can be consumed by OpenStack Compute
|
||
instances. This includes secondary attached storage similar to
|
||
Amazon's Elastic Block Storage (EBS). In addition images can be
|
||
written to a Block Storage device and specified for OpenStack
|
||
Compute to use a bootable persistent instance.</para>
|
||
<para>There are some differences from Amazon's EBS that one should
|
||
be aware of. OpenStack Block Storage is not a shared storage
|
||
solution like NFS, but currently is designed so that the device is
|
||
attached and in use by a single instance at a time.</para>
|
||
<para><guilabel>Backend Storage Devices</guilabel></para>
|
||
<para>OpenStack Block Storage requires some form of back-end storage
|
||
that the service is built on. The default implementation is to use
|
||
LVM on a local Volume Group named "cinder-volumes". In addition to
|
||
the base driver implementation, OpenStack Block Storage also
|
||
provides the means to add support for other storage devices to be
|
||
utilized such as external Raid Arrays or other Storage
|
||
appliances.</para>
|
||
<para><guilabel>Users and Tenants (Projects)</guilabel></para>
|
||
<para>The OpenStack Block Storage 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 policy.json file that
|
||
maintains the rules. A user's access to particular volumes is
|
||
limited by tenant, but the username and password are assigned per
|
||
user. Key pairs granting access to a volume are enabled per user,
|
||
but quotas to control resource consumption across available
|
||
hardware resources are per tenant.</para>
|
||
<para><guilabel>For tenants, quota controls are available to limit
|
||
the:</guilabel></para>
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Number of volumes which may be created</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Number of snapshots which may be created</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Total number of Giga Bytes allowed per tenant (shared
|
||
between snapshots and volumes)</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
<para><guilabel>Volumes Snapshots and Backups</guilabel></para>
|
||
<para>This introduction provides a high level overview of the two
|
||
basic resources offered by the OpenStack Block Storage service.
|
||
The first is Volumes and the second is Snapshots which are derived
|
||
from Volumes.</para>
|
||
<para><guilabel>Volumes</guilabel></para>
|
||
<para>Volumes are allocated block storage resources that can be
|
||
attached to instances as secondary storage or they can be used as
|
||
the root store to boot instances. Volumes are persistent R/W Block
|
||
Storage devices most commonly attached to the compute node via
|
||
iSCSI.</para>
|
||
<para><guilabel>Snapshots</guilabel></para>
|
||
<para>A Snapshot in OpenStack Block Storage is a read-only point in
|
||
time copy of a Volume. The Snapshot can be created from a Volume
|
||
that is currently in use (via the use of '--force True') or in an
|
||
available state. The Snapshot can then be used to create a new
|
||
volume via create from snapshot.</para>
|
||
<para><guilabel>Backups</guilabel></para>
|
||
<para>A Backup is an archived copy of a Volume currently stored in
|
||
Object Storage (Swift).</para>
|
||
<para><guilabel>Managing Volumes</guilabel></para>
|
||
<para>Cinder is the OpenStack service that allows you to give extra
|
||
block level storage to your OpenStack Compute instances. You may
|
||
recognize this as a similar offering from Amazon EC2 known as
|
||
Elastic Block Storage (EBS). The default Cinder implementation is
|
||
an iSCSI solution that employs the use of Logical Volume Manager
|
||
(LVM) for Linux. Note that a volume may only be attached to one
|
||
instance at a time. This is not a ‘shared storage’ solution like a
|
||
SAN of NFS on which multiple servers can attach to. It's also
|
||
important to note that Cinder also includes a number of drivers to
|
||
allow you to use a number of other vendor's back-end storage
|
||
devices in addition to or instead of the base LVM
|
||
implementation.</para>
|
||
<para>Here is brief walk-through of a simple create/attach sequence,
|
||
keep in mind this requires proper configuration of both OpenStack
|
||
Compute via cinder.conf and OpenStack Block Storage via
|
||
cinder.conf.</para>
|
||
<orderedlist>
|
||
<listitem>
|
||
<para>The volume is created via cinder create; which creates
|
||
an LV into the volume group (VG) "cinder-volumes"</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>The volume is attached to an instance via nova
|
||
volume-attach; which creates a unique iSCSI IQN that will be
|
||
exposed to the compute node</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>The compute node which run the concerned instance has
|
||
now an active ISCSI session; and a new local storage
|
||
(usually a /dev/sdX disk)</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>libvirt uses that local storage as a storage for the
|
||
instance; the instance get a new disk (usually a /dev/vdX
|
||
disk)</para>
|
||
</listitem>
|
||
</orderedlist>
|
||
<para><guilabel>Block Storage Capabilities</guilabel></para>
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>OpenStack provides persistent block level storage
|
||
devices for use with OpenStack compute instances.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>The block storage system manages the creation, attaching
|
||
and detaching of the block devices to servers. Block storage
|
||
volumes are fully integrated into OpenStack Compute and the
|
||
Dashboard allowing for cloud users to manage their own
|
||
storage needs.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>In addition to using simple Linux server storage, it has
|
||
unified storage support for numerous storage platforms
|
||
including Ceph, NetApp, Nexenta, SolidFire, and
|
||
Zadara.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Block storage is appropriate for performance sensitive
|
||
scenarios such as database storage, expandable file systems,
|
||
or providing a server with access to raw block level
|
||
storage.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Snapshot management provides powerful functionality for
|
||
backing up data stored on block storage volumes. Snapshots
|
||
can be restored or used to create a new block storage
|
||
volume.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
</chapter>
|