2c48b3a676
Make corrections into chapters 6: fix wording Implements: blueprint openstack-operations-guide-update-with-manila-features Change-Id: I7c3833bbdbf97262e03f6cde6cb9abe9981788ef
956 lines
38 KiB
XML
956 lines
38 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
||
<chapter version="5.0" xml:id="storage_decision"
|
||
xmlns="http://docbook.org/ns/docbook"
|
||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||
xmlns:ns5="http://www.w3.org/1999/xhtml"
|
||
xmlns:ns4="http://www.w3.org/2000/svg"
|
||
xmlns:ns3="http://www.w3.org/1998/Math/MathML"
|
||
xmlns:ns="http://docbook.org/ns/docbook">
|
||
<?dbhtml stop-chunking?>
|
||
|
||
<title>Storage Decisions</title>
|
||
|
||
<para>Storage is found in many parts of the OpenStack stack, and the
|
||
differing types can cause confusion to even experienced cloud engineers.
|
||
This section focuses on persistent storage options you can configure with
|
||
your cloud. It's important to understand the distinction between <glossterm
|
||
baseform="ephemeral volume"> ephemeral</glossterm> storage and <glossterm
|
||
baseform="persistent volume"> persistent</glossterm> storage.</para>
|
||
|
||
<section xml:id="ephemeral_storage">
|
||
<title>Ephemeral Storage</title>
|
||
|
||
<para>If you deploy only 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.<indexterm class="singular">
|
||
<primary>storage</primary>
|
||
|
||
<secondary>ephemeral</secondary>
|
||
</indexterm></para>
|
||
</section>
|
||
|
||
<section xml:id="persistent_storage">
|
||
<title>Persistent Storage</title>
|
||
|
||
<para>Persistent storage means that the storage resource outlives any
|
||
other resource and is always available, regardless of the state of a
|
||
running instance.</para>
|
||
|
||
<para>Today, OpenStack clouds explicitly support three types of persistent
|
||
storage: <emphasis>object storage</emphasis>, <emphasis>block storage</emphasis>,
|
||
and <emphasis>file system storage</emphasis>.
|
||
<indexterm class="singular">
|
||
<primary>swift</primary>
|
||
|
||
<secondary>Object Storage API</secondary>
|
||
</indexterm>
|
||
<indexterm class="singular">
|
||
<primary>persistent storage</primary>
|
||
</indexterm>
|
||
<indexterm class="singular">
|
||
<primary>objects</primary>
|
||
|
||
<secondary>persistent storage of</secondary>
|
||
</indexterm>
|
||
<indexterm class="singular">
|
||
<primary>Object Storage</primary>
|
||
|
||
<secondary>Object Storage API</secondary>
|
||
</indexterm>
|
||
<indexterm class="singular">
|
||
<primary>storage</primary>
|
||
|
||
<secondary>object storage</secondary>
|
||
</indexterm>
|
||
<indexterm class="singular">
|
||
<primary>shared file system storage</primary>
|
||
<secondary>shared file systems service</secondary>
|
||
</indexterm>
|
||
</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. Object storage is implemented in OpenStack
|
||
by the OpenStack Object Storage (swift) project. 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 <phrase
|
||
role="keep-together">machine</phrase> (VM) images inside of an object
|
||
storage system, as an alternative to storing the images on a file
|
||
system.<indexterm class="singular">
|
||
<primary>binary</primary>
|
||
|
||
<secondary>binary objects</secondary>
|
||
</indexterm></para>
|
||
|
||
<para>OpenStack Object Storage provides a highly scalable, highly
|
||
available storage solution by relaxing some of the constraints of
|
||
traditional file systems. In designing and procuring for such a cluster,
|
||
it is important to understand some key concepts about its operation.
|
||
Essentially, this type of storage is built on the idea that all storage
|
||
hardware fails, at every level, at some point. Infrequently encountered
|
||
failures that would hamstring other storage systems, such as issues
|
||
taking down RAID cards or entire servers, are handled gracefully with
|
||
OpenStack Object Storage.<indexterm class="singular">
|
||
<primary>scaling</primary>
|
||
|
||
<secondary>Object Storage and</secondary>
|
||
</indexterm></para>
|
||
|
||
<para>A good document describing the Object Storage architecture is
|
||
found within <link xlink:href="http://docs.openstack.org/developer/swift/overview_architecture.html"
|
||
xlink:title="OpenStack wiki">the developer documentation</link>—read
|
||
this first. Once you understand the architecture, you should know what a
|
||
proxy server does and how zones work. However, some important points are
|
||
often missed at first glance.</para>
|
||
|
||
<para>When designing your cluster, you must consider durability and
|
||
availability. Understand that the predominant source of these is the
|
||
spread and placement of your data, rather than the reliability of the
|
||
hardware. Consider the default value of the number of replicas, which is
|
||
three. This means that before an object is marked as having been
|
||
written, at least two copies exist—in case a single server fails to
|
||
write, the third copy may or may not yet exist when the write operation
|
||
initially returns. Altering this number increases the robustness of your
|
||
data, but reduces the amount of storage you have available. Next, look
|
||
at the placement of your servers. Consider spreading them widely
|
||
throughout your data center's network and power-failure zones. Is a zone
|
||
a rack, a server, or a disk?</para>
|
||
|
||
<para>Object Storage's network patterns might seem unfamiliar at first.
|
||
Consider these main traffic flows:
|
||
<indexterm class="singular">
|
||
<primary>objects</primary>
|
||
<secondary>storage decisions and</secondary>
|
||
</indexterm>
|
||
<indexterm class="singular">
|
||
<primary>containers</primary>
|
||
<secondary>storage decisions and</secondary>
|
||
</indexterm><indexterm class="singular">
|
||
<primary>account server</primary>
|
||
</indexterm>
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Among <glossterm>object</glossterm>,
|
||
<glossterm>container</glossterm>, and
|
||
<glossterm>account server</glossterm>s</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Between those servers and the proxies</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Between the proxies and your users</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
</para>
|
||
|
||
<para>Object Storage is very "chatty" among servers hosting data—even a
|
||
small cluster does megabytes/second of traffic, which is predominantly,
|
||
“Do you have the object?”/“Yes I have the object!” Of course, if the
|
||
answer to the aforementioned question is negative or the request times
|
||
out, replication of the object begins.</para>
|
||
|
||
<para>Consider the scenario where an entire server fails and 24 TB of
|
||
data needs to be transferred "immediately" to remain at three
|
||
copies—this can put significant load on the network.</para>
|
||
|
||
<?hard-pagebreak ?>
|
||
|
||
<para>Another fact that's often forgotten is that when a new file is
|
||
being uploaded, the proxy server must write out as many streams as there
|
||
are replicas—giving a multiple of network traffic. For a three-replica
|
||
cluster, 10 Gbps in means 30 Gbps out. Combining this with the previous
|
||
high bandwidth
|
||
<indexterm class="singular">
|
||
<primary>bandwidth</primary>
|
||
|
||
<secondary>private vs. public network recommendations</secondary>
|
||
</indexterm> demands of replication is what results in the
|
||
recommendation that your private network be of significantly higher
|
||
bandwidth than your public need be. Oh, and OpenStack Object Storage
|
||
communicates internally with unencrypted, unauthenticated rsync for
|
||
performance—you do want the private network to be private.
|
||
</para>
|
||
|
||
<para>The remaining point on bandwidth is the public-facing portion. The
|
||
<literal>swift-proxy</literal> 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="block_storage">
|
||
<title>Block Storage</title>
|
||
|
||
<para>Block storage (sometimes referred to as volume storage) provides
|
||
users with access to block-storage devices. Users interact with block
|
||
storage by attaching volumes to their running VM instances.<indexterm
|
||
class="singular">
|
||
<primary>volume storage</primary>
|
||
</indexterm><indexterm class="singular">
|
||
<primary>block storage</primary>
|
||
</indexterm><indexterm class="singular">
|
||
<primary>storage</primary>
|
||
|
||
<secondary>block storage</secondary>
|
||
</indexterm></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. However, support for utilizing files
|
||
as volumes is also well established, with full support for NFS,
|
||
GlusterFS and others.</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="shared_file_system_service">
|
||
<title>Shared File Systems Service</title>
|
||
<para>
|
||
The Shared File Systems service provides a set of services for
|
||
management of Shared File Systems in a multi-tenant cloud environment.
|
||
Users interact with Shared File Systems service by mounting remote File
|
||
Systems on their instances with the following usage of those systems
|
||
for file storing and exchange. Shared File Systems service provides you
|
||
with shares. A share is a remote, mountable file system. You can mount
|
||
a share to and access a share from several hosts by several users at a
|
||
time. With shares, user can also:
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Create a share specifying its size, shared file system
|
||
protocol, visibility level
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
Create a share on either a share server or standalone, depending
|
||
on the selected back-end mode, with or without using a share
|
||
network.
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Specify access rules and security services for existing
|
||
shares.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Combine several shares in groups to keep data consistency
|
||
inside the groups for the following safe group operations.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Create a snapshot of a selected share or a share group for
|
||
storing the existing shares consistently or creating new shares from
|
||
that snapshot in a consistent way</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Create a share from a snapshot.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Set rate limits and quotas for specific shares and snapshots</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>View usage of share resources</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Remove shares.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
Like Block Storage, the Shared File Systems service is persistent. It
|
||
can be:
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Mounted to any number of client machines.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Detached from one instance and attached to another without
|
||
data loss. During this process the data are safe unless the
|
||
Shared File Systems service itself is changed or removed.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
Shares are provided by the Shared File Systems service. In OpenStack,
|
||
Shared File Systems service is implemented by Shared File System
|
||
(manila) project, which supports multiple back-ends in the form of
|
||
drivers. The Shared File Systems service can be configured to provision
|
||
shares from one or more back-ends. Share servers are, mostly, virtual
|
||
machines that export file shares via different protocols such as NFS,
|
||
CIFS, GlusterFS, or HDFS.
|
||
</para>
|
||
</section>
|
||
</section>
|
||
|
||
<section xml:id="storage_concepts">
|
||
<title>OpenStack Storage Concepts</title>
|
||
|
||
<para><xref linkend="openstack_storage" /> explains the different storage
|
||
concepts provided by OpenStack.<indexterm class="singular">
|
||
<primary>block device</primary>
|
||
</indexterm><indexterm class="singular">
|
||
<primary>storage</primary>
|
||
|
||
<secondary>overview of concepts</secondary>
|
||
</indexterm></para>
|
||
|
||
<table rules="all" xml:id="openstack_storage">
|
||
<caption>OpenStack storage</caption>
|
||
|
||
<col width="12%" />
|
||
|
||
<col width="22%" />
|
||
|
||
<col width="22%" />
|
||
|
||
<col width="22%" />
|
||
|
||
<col width="22%" />
|
||
|
||
<thead>
|
||
<tr>
|
||
<th></th>
|
||
|
||
<th>Ephemeral storage</th>
|
||
|
||
<th>Block storage</th>
|
||
|
||
<th>Object storage</th>
|
||
|
||
<th>Shared File System storage</th>
|
||
</tr>
|
||
</thead>
|
||
|
||
<tbody>
|
||
<tr>
|
||
<td><para>Used to…</para></td>
|
||
|
||
<td><para>Run operating system and scratch space</para></td>
|
||
|
||
<td><para>Add additional persistent storage to a virtual machine
|
||
(VM)</para></td>
|
||
|
||
<td><para>Store data, including VM images</para></td>
|
||
|
||
<td><para>Add additional persistent storage to a virtual machine</para></td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td><para>Accessed through…</para></td>
|
||
|
||
<td><para>A file system</para></td>
|
||
|
||
<td><para>A <glossterm>block device</glossterm> that can be
|
||
partitioned, formatted, and mounted (such as, /dev/vdc)</para></td>
|
||
|
||
<td><para>The REST API</para></td>
|
||
|
||
<td><para>A Shared File Systems service share (either manila
|
||
managed or an external one registered in manila) that can be partitioned,
|
||
formatted and mounted (such as /dev/vdc)</para></td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td><para>Accessible from…</para></td>
|
||
|
||
<td><para>Within a VM</para></td>
|
||
|
||
<td><para>Within a VM</para></td>
|
||
|
||
<td><para>Anywhere</para></td>
|
||
|
||
<td><para>Within a VM</para></td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td><para>Managed by…</para></td>
|
||
|
||
<td><para>OpenStack Compute (nova)</para></td>
|
||
|
||
<td><para>OpenStack Block Storage (cinder)</para></td>
|
||
|
||
<td><para>OpenStack Object Storage (swift)</para></td>
|
||
|
||
<td><para>OpenStack Shared File System Storage (manila)</para></td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td><para>Persists until…</para></td>
|
||
|
||
<td><para>VM is terminated</para></td>
|
||
|
||
<td><para>Deleted by user</para></td>
|
||
|
||
<td><para>Deleted by user</para></td>
|
||
|
||
<td><para>Deleted by user</para></td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td><para>Sizing determined by…</para></td>
|
||
|
||
<td><para>Administrator configuration of size settings, known as
|
||
<emphasis>flavors</emphasis> </para></td>
|
||
|
||
<td><para>User specification in initial request</para></td>
|
||
|
||
<td><para>Amount of available physical storage</para></td>
|
||
|
||
<td>
|
||
<para>
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>
|
||
User specification in initial request
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
Requests for extension
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
Available user-level quotes
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
Limitations applied by Administrator
|
||
</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
</para>
|
||
</td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td><para>Encryption set by…</para></td>
|
||
|
||
<td><para>Parameter in nova.conf</para></td>
|
||
|
||
<td><para>Admin establishing
|
||
<link xlink:href="http://docs.openstack.org/user-guide-admin/dashboard_manage_volumes.html">encrypted volume type</link>,
|
||
then user selecting encrypted volume</para></td>
|
||
|
||
<td><para>Not yet available</para></td>
|
||
|
||
<td><para>Shared File Systems service does not apply any additional
|
||
encryption above what the share’s back-end storage provides</para></td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td><para>Example of typical usage…</para></td>
|
||
|
||
<td><para>10 GB first disk, 30 GB second disk</para></td>
|
||
|
||
<td><para>1 TB disk</para></td>
|
||
|
||
<td><para>10s of TBs of dataset storage</para></td>
|
||
|
||
<td><para>Depends completely on the size of back-end storage specified when
|
||
a share was being created. In case of thin provisioning it can be partial
|
||
space reservation (for more details see <link xlink:href="http://docs.openstack.org/developer/manila/devref/capabilities_and_extra_specs.html?highlight=extra%20specs#common-capabilities">Capabilities and Extra-Specs</link> specification)</para></td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<sidebar>
|
||
<title>File-level Storage (for Live Migration)</title>
|
||
|
||
<para>With file-level storage, users access stored data using the
|
||
operating system's file system interface. Most users, if they have used
|
||
a network storage solution before, have encountered this form of
|
||
networked storage. In the Unix world, the most common form of this is
|
||
NFS. In the Windows world, the most common form is called CIFS
|
||
(previously, SMB).<indexterm class="singular">
|
||
<primary>migration</primary>
|
||
</indexterm><indexterm class="singular">
|
||
<primary>live migration</primary>
|
||
</indexterm><indexterm class="singular">
|
||
<primary>storage</primary>
|
||
|
||
<secondary>file-level</secondary>
|
||
</indexterm></para>
|
||
|
||
<para>OpenStack clouds do not present file-level storage to end users.
|
||
However, it is important to consider file-level storage for storing
|
||
instances under <code>/var/lib/nova/instances</code> when designing your
|
||
cloud, since you must have a shared file system if you want to support
|
||
live migration.</para>
|
||
</sidebar>
|
||
</section>
|
||
|
||
<section xml:id="storage_backends">
|
||
<title>Choosing Storage Back Ends</title>
|
||
|
||
<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 want to
|
||
set a time-to-live (TTL) value on a file. Others may access only 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—storage that is released when a VM attached to it is shut down— is
|
||
the preferred way. When you select <glossterm>storage
|
||
back end</glossterm>s, <indexterm class="singular">
|
||
<primary>storage</primary>
|
||
|
||
<secondary>choosing back ends</secondary>
|
||
</indexterm><indexterm class="singular">
|
||
<primary>storage back end</primary>
|
||
</indexterm><indexterm class="singular">
|
||
<primary>back end interactions</primary>
|
||
|
||
<secondary>store</secondary>
|
||
</indexterm>ask the following questions on behalf of your users:</para>
|
||
|
||
<itemizedlist role="compact">
|
||
<listitem>
|
||
<para>Do my users need block storage?</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Do my users need object storage?</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Do I need to support live migration?</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Should my persistent storage drives be contained in my compute
|
||
nodes, or should I use external storage?</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>What is the platter count I can achieve? Do more spindles result
|
||
in better I/O despite network access?</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Which one results in the best cost-performance scenario I'm
|
||
aiming for?</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>How do I manage the storage operationally?</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>How redundant and distributed is the storage? What happens if a
|
||
storage node fails? To what extent can it mitigate my data-loss
|
||
disaster scenarios?</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
|
||
<para>To deploy your storage by using only commodity hardware, you can use
|
||
a number of open-source packages, as shown in <xref
|
||
linkend="storage_solutions" />.</para>
|
||
|
||
<table rules="all" xml:id="storage_solutions" role="resize">
|
||
<caption>Persistent file-based storage support</caption>
|
||
|
||
<thead>
|
||
<tr>
|
||
<th> </th>
|
||
|
||
<th>Object</th>
|
||
|
||
<th>Block</th>
|
||
|
||
<th>File-level<footnote>
|
||
<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 deployed a
|
||
file-level shared storage solution that you can use.</para>
|
||
</footnote></th>
|
||
</tr>
|
||
</thead>
|
||
|
||
<tbody>
|
||
<tr>
|
||
<td><para>Swift</para></td>
|
||
|
||
<td><para><inlinemediaobject>
|
||
<imageobject>
|
||
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/Check_mark_23x20_02.png"
|
||
format="PNG"></imagedata>
|
||
</imageobject>
|
||
</inlinemediaobject></para></td>
|
||
|
||
<td><para></para></td>
|
||
|
||
<td><para> </para></td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td><para>LVM</para></td>
|
||
|
||
<td><para> </para></td>
|
||
|
||
<td><para><inlinemediaobject>
|
||
<imageobject>
|
||
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/Check_mark_23x20_02.png"
|
||
format="PNG"></imagedata>
|
||
</imageobject>
|
||
</inlinemediaobject></para></td>
|
||
|
||
<td><para> </para></td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td><para>Ceph</para></td>
|
||
|
||
<td><para><inlinemediaobject>
|
||
<imageobject>
|
||
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/Check_mark_23x20_02.png"
|
||
format="PNG"></imagedata>
|
||
</imageobject>
|
||
</inlinemediaobject></para></td>
|
||
|
||
<td><para><inlinemediaobject>
|
||
<imageobject>
|
||
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/Check_mark_23x20_02.png"
|
||
format="PNG"></imagedata>
|
||
</imageobject>
|
||
</inlinemediaobject></para></td>
|
||
|
||
<td><para>Experimental</para></td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td><para>Gluster</para></td>
|
||
|
||
<td><para><inlinemediaobject>
|
||
<imageobject>
|
||
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/Check_mark_23x20_02.png"
|
||
format="PNG"></imagedata>
|
||
</imageobject>
|
||
</inlinemediaobject></para></td>
|
||
|
||
<td><para><inlinemediaobject>
|
||
<imageobject>
|
||
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/Check_mark_23x20_02.png"
|
||
format="PNG"></imagedata>
|
||
</imageobject>
|
||
</inlinemediaobject></para></td>
|
||
|
||
<td><para><inlinemediaobject>
|
||
<imageobject>
|
||
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/Check_mark_23x20_02.png"
|
||
format="PNG"></imagedata>
|
||
</imageobject>
|
||
</inlinemediaobject></para></td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td><para>NFS</para></td>
|
||
|
||
<td><para></para></td>
|
||
|
||
<td><para><inlinemediaobject>
|
||
<imageobject>
|
||
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/Check_mark_23x20_02.png"
|
||
format="PNG"></imagedata>
|
||
</imageobject>
|
||
</inlinemediaobject></para></td>
|
||
|
||
<td><para><inlinemediaobject>
|
||
<imageobject>
|
||
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/Check_mark_23x20_02.png"
|
||
format="PNG"></imagedata>
|
||
</imageobject>
|
||
</inlinemediaobject></para></td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td><para>ZFS</para></td>
|
||
|
||
<td><para> </para></td>
|
||
|
||
<td><para><inlinemediaobject>
|
||
<imageobject>
|
||
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/Check_mark_23x20_02.png"
|
||
format="PNG"></imagedata>
|
||
</imageobject>
|
||
</inlinemediaobject></para></td>
|
||
|
||
<td><para> </para></td>
|
||
</tr>
|
||
<tr>
|
||
<td><para>Sheepdog</para></td>
|
||
<td><para><inlinemediaobject>
|
||
<imageobject>
|
||
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/Check_mark_23x20_02.png"
|
||
format="PNG"></imagedata>
|
||
</imageobject>
|
||
</inlinemediaobject></para></td>
|
||
<td><para><inlinemediaobject>
|
||
<imageobject>
|
||
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/Check_mark_23x20_02.png"
|
||
format="PNG"></imagedata>
|
||
</imageobject>
|
||
</inlinemediaobject></para></td>
|
||
<td><para> </para></td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<sidebar>
|
||
<title>Storage Driver Support</title>
|
||
|
||
<para>In addition to the open source technologies, there are a number of
|
||
proprietary solutions that are officially supported by OpenStack Block
|
||
Storage.<indexterm class="singular">
|
||
<primary>storage</primary>
|
||
|
||
<secondary>storage driver support</secondary>
|
||
</indexterm> They are offered by the following vendors:</para>
|
||
|
||
<itemizedlist role="compact">
|
||
<listitem>
|
||
<para>IBM (Storwize family/SVC, XIV)</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>NetApp</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Nexenta</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>SolidFire</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
|
||
<para>You can find a matrix of the functionality provided by all of the
|
||
supported Block Storage drivers on the <link
|
||
xlink:href="https://wiki.openstack.org/wiki/CinderSupportMatrix"
|
||
xlink:title="OpenStack wiki">OpenStack wiki</link>.</para>
|
||
</sidebar>
|
||
|
||
<para>Also, you need to decide whether you want to support object storage
|
||
in your cloud. The two common use cases for providing object storage in a
|
||
compute cloud are:</para>
|
||
|
||
<itemizedlist role="compact">
|
||
<listitem>
|
||
<para>To provide users with a persistent storage mechanism</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>As a scalable, reliable data store for virtual machine
|
||
images</para>
|
||
</listitem>
|
||
</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. Depending on
|
||
your cloud user's needs, you can implement one or many of these
|
||
technologies in different combinations:<indexterm class="singular">
|
||
<primary>storage</primary>
|
||
|
||
<secondary>commodity storage</secondary>
|
||
</indexterm></para>
|
||
|
||
<variablelist>
|
||
<varlistentry>
|
||
<term>OpenStack Object Storage (swift)</term>
|
||
|
||
<listitem>
|
||
<para>The official OpenStack Object Store implementation. It is a
|
||
mature technology that has been used for several years in
|
||
production by Rackspace as the technology behind Rackspace Cloud
|
||
Files. As it is highly scalable, it is well-suited to managing
|
||
petabytes of storage. OpenStack Object Storage's advantages are
|
||
better <phrase role="keep-together">integration</phrase> with
|
||
OpenStack (integrates with OpenStack Identity, works with the
|
||
OpenStack dashboard interface) and better support for multiple
|
||
data center deployment through support of asynchronous eventual
|
||
consistency replication.</para>
|
||
|
||
<para>Therefore, if you eventually plan on distributing your
|
||
storage cluster across multiple data centers, if you need unified
|
||
accounts for your users for both compute and object storage, or if
|
||
you want to control your object storage with the OpenStack
|
||
dashboard, you should consider OpenStack Object Storage. More
|
||
detail can be found about OpenStack Object Storage in the section
|
||
below.<indexterm class="singular">
|
||
<primary>accounts</primary>
|
||
</indexterm></para>
|
||
</listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term>Ceph<indexterm class="singular">
|
||
<primary>Ceph</primary>
|
||
</indexterm></term>
|
||
|
||
<listitem>
|
||
<para>A scalable storage solution that replicates data across
|
||
commodity storage nodes. Ceph was originally developed by one of
|
||
the founders of DreamHost and is currently used in production
|
||
there.</para>
|
||
|
||
<para>Ceph was designed to expose different types of storage
|
||
interfaces to the end user: it supports object storage, block
|
||
storage, and file-system interfaces, although the file-system
|
||
interface is not yet considered production-ready. Ceph supports
|
||
the same API as swift for object storage and can be used as a
|
||
back end for cinder block storage as well as back-end storage for
|
||
glance images. Ceph supports "thin provisioning," implemented
|
||
using copy-on-write.</para>
|
||
|
||
<para>This can be useful when booting from volume because a new
|
||
volume can be provisioned very quickly. Ceph also supports
|
||
keystone-based authentication (as of version 0.56), so it can be a
|
||
seamless swap in for the default OpenStack swift
|
||
implementation.</para>
|
||
|
||
<para>Ceph's advantages are that it gives the administrator more
|
||
fine-grained control over data distribution and replication
|
||
strategies, enables you to consolidate your object and block
|
||
storage, enables very fast provisioning of boot-from-volume
|
||
instances using thin provisioning, and supports a distributed
|
||
file-system interface, though this interface is <link
|
||
xlink:href="http://ceph.com/docs/master/cephfs/"
|
||
xlink:title="OpenStack wiki">not yet recommended</link> for use in
|
||
production deployment by the Ceph project.</para>
|
||
|
||
<para>If you want to manage your object and block storage within a
|
||
single system, or if you want to support fast boot-from-volume,
|
||
you should consider Ceph.</para>
|
||
</listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term>Gluster<indexterm class="singular">
|
||
<primary>GlusterFS</primary>
|
||
</indexterm></term>
|
||
|
||
<listitem>
|
||
<para>A distributed, shared file system. As of Gluster version
|
||
3.3, you can use Gluster to consolidate your object storage and
|
||
file storage into one unified file and object storage solution,
|
||
which is called Gluster For OpenStack (GFO). GFO uses a customized
|
||
version of swift that enables Gluster to be used as the back-end
|
||
storage.</para>
|
||
|
||
<para>The main reason to use GFO rather than regular swift is if
|
||
you also want to support a distributed file system, either to
|
||
support shared storage live migration or to provide it as a
|
||
separate service to your end users. If you want to manage your
|
||
object and file storage within a single system, you should
|
||
consider GFO.</para>
|
||
</listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term>LVM<indexterm class="singular">
|
||
<primary>LVM (Logical Volume Manager)</primary>
|
||
</indexterm></term>
|
||
|
||
<listitem>
|
||
<para>The Logical Volume Manager is a Linux-based system that
|
||
provides an abstraction layer on top of physical disks to expose
|
||
logical volumes to the operating system. The LVM back-end
|
||
implements block storage as LVM logical partitions.</para>
|
||
|
||
<para>On each host that will house block storage, an administrator
|
||
must initially create a volume group dedicated to Block Storage
|
||
volumes. Blocks are created from LVM logical volumes.</para>
|
||
|
||
<note>
|
||
<para>LVM does <emphasis>not</emphasis> provide any replication.
|
||
Typically, administrators configure RAID on nodes that use LVM
|
||
as block storage to protect against failures of individual hard
|
||
drives. However, RAID does not protect against a failure of the
|
||
entire host.</para>
|
||
</note>
|
||
</listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term>ZFS<indexterm class="singular">
|
||
<primary>ZFS</primary>
|
||
</indexterm></term>
|
||
|
||
<listitem>
|
||
<para>The Solaris iSCSI driver for OpenStack Block Storage
|
||
implements blocks as ZFS entities. ZFS is a file system that also
|
||
has the functionality of a volume manager. This is unlike on a
|
||
Linux system, where there is a separation of volume manager (LVM)
|
||
and file system (such as, ext3, ext4, xfs, and btrfs). ZFS has a
|
||
number of advantages over ext4, including improved data-integrity
|
||
checking.</para>
|
||
|
||
<para>The ZFS back end for OpenStack Block Storage supports only
|
||
Solaris-based systems, such as Illumos. While there is a Linux
|
||
port of ZFS, it is not included in any of the standard Linux
|
||
distributions, and it has not been tested with OpenStack Block
|
||
Storage. As with LVM, ZFS does not provide replication across
|
||
hosts on its own; you need to add a replication solution on top of
|
||
ZFS if your cloud needs to be able to handle storage-node
|
||
failures.</para>
|
||
|
||
<para>We don't recommend ZFS unless you have previous experience
|
||
with deploying it, since the ZFS back end for Block Storage
|
||
requires a Solaris-based operating system, and we assume that your
|
||
experience is primarily with Linux-based systems.</para>
|
||
</listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term>Sheepdog<indexterm class="singular">
|
||
<primary>Sheepdog</primary>
|
||
</indexterm></term>
|
||
|
||
<listitem>
|
||
<para>Sheepdog is a userspace distributed storage system. Sheepdog scales
|
||
to several hundred nodes, and has powerful virtual disk management features
|
||
like snapshot, cloning, rollback, thin provisioning.</para>
|
||
|
||
<para>It is essentially an object storage system that manages disks and aggregates
|
||
the space and performance of disks linearly in hyper scale on commodity hardware in
|
||
a smart way. On top of its object store, Sheepdog provides elastic volume service
|
||
and http service. Sheepdog does not assume anything about kernel version and can
|
||
work nicely with xattr-supported file systems.</para>
|
||
</listitem>
|
||
</varlistentry>
|
||
</variablelist>
|
||
</section>
|
||
</section>
|
||
|
||
<section xml:id="storagedecisions_conclusion">
|
||
<title>Conclusion</title>
|
||
|
||
<para>We hope that 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 <phrase
|
||
role="keep-together">design</phrase>.</para>
|
||
</section>
|
||
</chapter>
|