39ac6cc258
It's "compute node", not "Compute node" (similarly compute host). Also, fix capitalization of "live migration". Change-Id: I57ac46b845e217c2607cf99dfabcfaab25d84ea5
112 lines
6.7 KiB
XML
112 lines
6.7 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 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 a
|
|
Block Storage device for Compute to use as a bootable persistent instance.</para>
|
|
<para>The Block Storage service differs slightly from the Amazon EBS offering. The Block Storage
|
|
service does not provide a shared storage solution like NFS. With the Block Storage service,
|
|
you can attach a device to only one instance.</para>
|
|
<para>The 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 Compute's EC2
|
|
interface, which calls in to the Block Storage client.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><systemitem class="service">cinder-scheduler</systemitem>. Schedules and routes
|
|
requests to the appropriate volume service. 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 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 Block Storage Volume
|
|
to OpenStack Object Store (SWIFT).</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>The Block Storage service contains the following components:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><emphasis role="bold">Back-end Storage Devices</emphasis>. The 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 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 back-end 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 Block Storage
|
|
service can be used by many different cloud computing consumers or customers
|
|
(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 can be configured by the system
|
|
administrator in 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 Block Storage 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 Block Storage service are volumes and snapshots which are
|
|
derived from volumes and volume 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 <option>--force True</option>) 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>
|