From 60cf15d1ffc368f49acf534d62e68cb41ee74e8e Mon Sep 17 00:00:00 2001 From: annegentle Date: Fri, 24 Jan 2014 14:04:55 -0600 Subject: [PATCH] Edits to Storage Decisions chapter - Rearrange definitions before table - Fix technologies table - Adds conclusion Change-Id: I79bd84318cad17894869d1c6c2e88c624abc1a5d --- doc/openstack-ops/ch_arch_storage.xml | 144 ++++++++++++++------------ 1 file changed, 79 insertions(+), 65 deletions(-) diff --git a/doc/openstack-ops/ch_arch_storage.xml b/doc/openstack-ops/ch_arch_storage.xml index 5c3cab0c..6a17199d 100644 --- a/doc/openstack-ops/ch_arch_storage.xml +++ b/doc/openstack-ops/ch_arch_storage.xml @@ -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. +
+ Ephemeral Storage + 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. + Today, OpenStack clouds explicitly support two types of + persistent storage: object storage + and block storage.
+
+ Object Storage + 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. +
+
+ Block Storage + 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. + 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. + 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. + 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. + 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 + /var/lib/nova/instances. +
OpenStack Storage Concepts -
OpenStack Storage
@@ -95,59 +148,6 @@ format="SVG" scale="60"/>
- 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. - Today, OpenStack clouds explicitly support two types of - persistent storage: object storage - and block storage. -
- Object Storage - 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. -
- -
- Block Storage - 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. - 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. - 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. - 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. - 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 - /var/lib/nova/instances. -
File-level Storage With file-level storage, users access stored data @@ -169,9 +169,15 @@ format="SVG" scale="60"/>
Choosing Storage Back-ends - In general, when you select storage + 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 storage back-ends, ask the following - questions: + questions on behalf of your users: Do my users need block storage? @@ -210,14 +216,14 @@ format="SVG" scale="60"/> To deploy your storage by using entirely commodity hardware, you can use a number of open-source packages, as shown in the following table: - + + - @@ -264,7 +270,7 @@ format="SVG" scale="60"/> - +
Persistent file-based storage support
  Object Block File-level* (live migration support)
 
* 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"/>
Commodity Storage Back-end Technologies - This section provides a high-level overview of the - differences among the different commodity storage - back-end technologies. - + 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. 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 — you do want the private network to be private. 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. More proxies means more bandwidth, if your storage can keep up.
+
+ Conclusion + 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. +