133 lines
7.1 KiB
XML
133 lines
7.1 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<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="section_block-storage-overview">
|
|
<title>Introduction to the OpenStack Block Storage Service</title>
|
|
<para>The OpenStack Block Storage service provides persistent
|
|
block storage resources that OpenStack Compute instances can
|
|
consume. This includes secondary attached storage similar to
|
|
the Amazon Elastic Block Storage (EBS) offering. In addition,
|
|
you can write images to an OpenStack Block Storage device for
|
|
OpenStack Compute to use as a bootable persistent
|
|
instance.</para>
|
|
<para>The OpenStack Block Storage service differs slightly from
|
|
the Amazon EBS offering. The OpenStack Block Storage service
|
|
does not provide a shared storage solution like NFS. With the
|
|
OpenStack Block Storage service, you can attach a device to
|
|
only one instance.</para>
|
|
<para>The OpenStack Block Storage service provides:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><systemitem class="service">cinder-api</systemitem>. A WSGI
|
|
app that authenticates and routes requests throughout
|
|
the Block Storage service. It supports the OpenStack
|
|
APIs only, although there is a translation that can be
|
|
done through Nova's EC2 interface, which calls in to
|
|
the cinderclient.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><systemitem class="service">cinder-scheduler</systemitem>. Schedules and routes 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 filters on things like Capacity, Availability
|
|
Zone, Volume Types, and Capabilities as well as custom filters.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><systemitem class="service">cinder-volume</systemitem>.
|
|
Manages Block Storage devices, specifically the
|
|
back-end devices themselves.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><systemitem class="service">cinder-backup</systemitem>
|
|
Provides a means to back up a Cinder Volume to
|
|
OpenStack Object Store (SWIFT).</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>The OpenStack Block Storage service contains the following
|
|
components:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><emphasis role="bold">Backend Storage
|
|
Devices</emphasis>. The OpenStack Block Storage
|
|
service 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, the OpenStack Block Storage service
|
|
also provides the means to add support for other
|
|
storage devices to be utilized such as external Raid
|
|
Arrays or other storage appliances. These backend storage devices
|
|
may have custom block sizes when using KVM or QEMU as the hypervisor.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">Users and Tenants
|
|
(Projects)</emphasis>. The OpenStack Block Storage
|
|
service 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. 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>For tenants, quota controls are available to
|
|
limit:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>The number of volumes that can be
|
|
created</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>The number of snapshots that can be
|
|
created</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>The total number of GBs allowed per tenant
|
|
(shared between snapshots and volumes)</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>You can revise the default quota values with the cinder CLI, so the limits placed by quotas are editable by admin users.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">Volumes, Snapshots, and
|
|
Backups</emphasis>. The basic resources offered by
|
|
the OpenStack Block Storage service are volumes and
|
|
snapshots, which are derived from volumes, and
|
|
backups:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><emphasis role="bold">Volumes</emphasis>.
|
|
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 through iSCSI.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">Snapshots</emphasis>.
|
|
A read-only point in time copy of a volume.
|
|
The snapshot can be created from a volume that
|
|
is currently in use (through the use of
|
|
'--force True') or in an available state. The
|
|
snapshot can then be used to create a new
|
|
volume through create from snapshot.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">Backups</emphasis>. An
|
|
archived copy of a volume currently stored in
|
|
OpenStack Object Storage (Swift).</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</section>
|