openstack/operations-guide
Code Issues Proposed changes

Edits to Storage Decisions chapter

Browse Source 
- Rearrange definitions before table
- Fix technologies table
- Adds conclusion

Change-Id: I79bd84318cad17894869d1c6c2e88c624abc1a5d
This commit is contained in:
annegentle 2014-01-24 14:04:55 -06:00
parent d5b92a38fd
commit 60cf15d1ff
1 changed files with 79 additions and 65 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

144
doc/openstack-ops/ch_arch_storage.xml
View File

@ -22,11 +22,64 @@ format="SVG" scale="60"/>
the differing types can cause confusion to even experienced
cloud engineers. This section focuses on persistent storage
options you can configure with your cloud.</para>
<section xml:id="ephemeral_storage">
<title>Ephemeral Storage</title>
<para>If you only deploy the OpenStack Compute Service (nova),
your users do not have access to any form of persistent
storage by default. The disks associated with VMs are
"ephemeral", meaning that (from the user's point of view)
they effectively disappear when a virtual machine is
terminated. You must identify what type of persistent
storage you want to support for your users.</para>
<para>Today, OpenStack clouds explicitly support two types of
persistent storage: <emphasis>object storage</emphasis>
and <emphasis>block storage</emphasis>.</para></section>
<section xml:id="object_storage">
<title>Object Storage</title>
<para>With object storage, users access binary objects
through a REST API. You may be familiar with Amazon
S3, which is a well-known example of an object storage
system. If your intended users need to archive or
manage large datasets, you want to provide them with
object storage. In addition, OpenStack can store your
virtual machine (VM) images inside of an object
storage system, as an alternative to storing the
images on a file system.</para>
</section>
<section xml:id="block_storage">
<title>Block Storage</title>
<para>Block storage (sometimes referred to as volume
storage) exposes a block device to the user. Users
interact with block storage by attaching volumes to
their running VM instances.</para>
<para>These volumes are persistent: they can be detached
from one instance and re-attached to another, and the
data remains intact. Block storage is implemented in
OpenStack by the OpenStack Block Storage (Cinder)
project, which supports multiple back-ends in the form
of drivers. Your choice of a storage back-end must be
supported by a Block Storage driver.</para>
<para>Most block storage drivers allow the instance to
have direct access to the underlying storage
hardware's block device. This helps increase the
overall read/write IO.</para>
<para>Experimental support for utilizing files as volumes
began in the Folsom release. This initially started as
a reference driver for using NFS with Cinder. By
Grizzly's release, this has expanded into a full NFS
driver as well as a GlusterFS driver.</para>
<para>These drivers work a little differently than a
traditional "block" storage driver. On an NFS or
GlusterFS file system, a single file is created and
then mapped as a "virtual" volume into the instance.
This mapping/translation is similar to how OpenStack
utilizes QEMU's file-based virtual machines stored in
<code>/var/lib/nova/instances</code>.</para>
</section>
<section xml:id="storage_concepts">
<title>OpenStack Storage Concepts</title>
<table xml:id="openstack_storage" rules="all">
<caption>OpenStack Storage</caption>
<thead>
<tr>
<th/>
@ -95,59 +148,6 @@ format="SVG" scale="60"/>
</tr>
</tbody>
</table>
<para>If you only deploy the OpenStack Compute Service (nova),
your users do not have access to any form of persistent
storage by default. The disks associated with VMs are
"ephemeral", meaning that (from the user's point of view)
they effectively disappear when a virtual machine is
terminated. You must identify what type of persistent
storage you want to support for your users.</para>
<para>Today, OpenStack clouds explicitly support two types of
persistent storage: <emphasis>object storage</emphasis>
and <emphasis>block storage</emphasis>.</para>
<section xml:id="object_storage">
<title>Object Storage</title>
<para>With object storage, users access binary objects
through a REST API. You may be familiar with Amazon
S3, which is a well-known example of an object storage
system. If your intended users need to archive or
manage large datasets, you want to provide them with
object storage. In addition, OpenStack can store your
virtual machine (VM) images inside of an object
storage system, as an alternative to storing the
images on a file system.</para>
</section>
<section xml:id="block_storage">
<title>Block Storage</title>
<para>Block storage (sometimes referred to as volume
storage) exposes a block device to the user. Users
interact with block storage by attaching volumes to
their running VM instances.</para>
<para>These volumes are persistent: they can be detached
from one instance and re-attached to another, and the
data remains intact. Block storage is implemented in
OpenStack by the OpenStack Block Storage (Cinder)
project, which supports multiple back-ends in the form
of drivers. Your choice of a storage back-end must be
supported by a Block Storage driver.</para>
<para>Most block storage drivers allow the instance to
have direct access to the underlying storage
hardware's block device. This helps increase the
overall read/write IO.</para>
<para>Experimental support for utilizing files as volumes
began in the Folsom release. This initially started as
a reference driver for using NFS with Cinder. By
Grizzly's release, this has expanded into a full NFS
driver as well as a GlusterFS driver.</para>
<para>These drivers work a little differently than a
traditional "block" storage driver. On an NFS or
GlusterFS file system, a single file is created and
then mapped as a "virtual" volume into the instance.
This mapping/translation is similar to how OpenStack
utilizes QEMU's file-based virtual machines stored in
<code>/var/lib/nova/instances</code>.</para>
</section>
<section xml:id="file_level_storage">
<title>File-level Storage</title>
<para>With file-level storage, users access stored data
@ -169,9 +169,15 @@ format="SVG" scale="60"/>
<?hard-pagebreak?>
<section xml:id="storage_backends">
<title>Choosing Storage Back-ends</title>
<para>In general, when you select <glossterm>storage
<para>Users will indicate different needs for their cloud use cases.
Some may need fast access to many objects that do not change often,
or they want to set a Time To Live (TTL) value on a file. Others may only
access storage that is mounted with the file system itself, but want
it to be replicated instantly when starting a new instance. For
other systems, ephemeral storage that is released when a VM attached
to it is shut down. When you select <glossterm>storage
back-end</glossterm>s, ask the following
questions:</para>
questions on behalf of your users:</para>
<itemizedlist role="compact">
<listitem>
<para>Do my users need block storage?</para>
@ -210,14 +216,14 @@ format="SVG" scale="60"/>
<para>To deploy your storage by using entirely commodity
hardware, you can use a number of open-source packages, as
shown in the following table:</para>
<informaltable rules="all">
<table xml:id="storage_solutions" rules="all">
<caption>Persistent file-based storage support</caption>
<thead>
<tr>
<th> </th>
<th>Object</th>
<th>Block</th>
<th>File-level* (live migration support)</th>
</tr>
</thead>
<tbody>
@ -264,7 +270,7 @@ format="SVG" scale="60"/>
<td><para> </para></td>
</tr>
</tbody>
</informaltable>
</table>
<para>* This list of open-source file-level shared storage
solutions is not exhaustive, other open source solutions
exist (MooseFS). Your organization may already have
@ -309,10 +315,10 @@ format="SVG" scale="60"/>
</itemizedlist>
<section xml:id="commodity_storage_backends">
<title>Commodity Storage Back-end Technologies</title>
<para>This section provides a high-level overview of the
differences among the different commodity storage
back-end technologies.</para>
<para>This section provides a high-level overview of the differences
among the different commodity storage back-end technologies.
Depending on your cloud user's needs, you can implement one or
many of these technologies in different combinations.</para>
<itemizedlist role="compact">
<listitem>
<para><emphasis role="bold">OpenStack Object
@ -539,13 +545,21 @@ format="SVG" scale="60"/>
recommendation that your private network is of
significantly higher bandwidth than your public need be.
Oh, and OpenStack Object Storage communicates internally
with unencrypted, unauthenticated rsync for performance -
with unencrypted, unauthenticated rsync for performance &mdash;
you do want the private network to be private.</para>
<para>The remaining point on bandwidth is the public facing
portion. swift-proxy is stateless, which means that you
portion. The swift-proxy service is stateless, which means that you
can easily add more and use http load-balancing methods to
share bandwidth and availability between them.</para>
<para>More proxies means more bandwidth, if your storage can
keep up.</para>
</section>
<section xml:id="storagedecisions_conclusion">
<title>Conclusion</title>
<para>Hopefully you now have some considerations in mind and questions
to ask your future cloud users about their storage use cases. As you
can see, your storage decisions will also influence your network design
for performance and security needs. Continue with us to make more
informed decisions about your OpenStack cloud design.</para>
</section>
</chapter>