openstack-manuals/doc/common/section_objectstorage-arch.xml
Gauvain Pocentek 169b574661 replace a unicode character with a dash
Change-Id: I91733af6fd4e8b1caad55006ac1beab7b0c928bf
2014-03-06 21:34:18 +01:00

76 lines
4.8 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_objectstorage-cluster-architecture">
<!-- ... Old module003-ch007-swift-cluster-architecture edited, renamed, and stored in doc/common for use by both Cloud Admin and Operator Training Guides... -->
<title>Cluster architecture</title>
<section xml:id="section_access-tier">
<title>Access tier</title>
<para>Large-scale deployments segment off an access tier, which is considered the Object Storage
system's central hub. The access tier fields the incoming API requests from clients and
moves data in and out of the system. This tier consists of front-end load balancers,
ssl-terminators, and authentication services. It runs the (distributed) brain of the
Object Storage system: the proxy server processes.</para>
<figure>
<title>Object Storage architecture</title>
<mediaobject>
<imageobject>
<imagedata fileref="../common/figures/objectstorage-arch.png"/>
</imageobject>
</mediaobject>
</figure>
<para>Because access servers are collocated in their own tier, you can scale out read/write
access regardless of the storage capacity. For example, if a cluster is on the public
Internet, requires SSL termination, and has a high demand for data access, you can
provision many access servers. However, if the cluster is on a private network and used
primarily for archival purposes, you need fewer access servers.</para>
<para>Since this is an HTTP addressable storage service, you may incorporate a load balancer
into the access tier.</para>
<para>Typically, the tier consists of a collection of 1U servers. These machines use a
moderate amount of RAM and are network I/O intensive. Since these systems field each
incoming API request, you should provision them with two high-throughput (10GbE)
interfaces - one for the incoming "front-end" requests and the other for the "back-end"
access to the object storage nodes to put and fetch data.</para>
<section xml:id="section_access-tier-considerations">
<title>Factors to consider</title>
<para>For most publicly facing deployments as well as private deployments available
across a wide-reaching corporate network, you use SSL to encrypt traffic to the
client. SSL adds significant processing load to establish sessions between clients,
which is why you have to provision more capacity in the access layer. SSL may not be
required for private deployments on trusted networks.</para>
</section>
</section>
<section xml:id="section_storage-nodes">
<title>Storage nodes</title>
<para>In most configurations, each of the five zones should have an equal amount of storage
capacity. Storage nodes use a reasonable amount of memory and CPU. Metadata needs to be
readily available to return objects quickly. The object stores run services not only to
field incoming requests from the access tier, but to also run replicators, auditors, and
reapers. You can provision object stores provisioned with single gigabit or 10 gigabit
network interface depending on the expected workload and desired performance.</para>
<figure>
<title>Object Storage (Swift)</title>
<mediaobject>
<imageobject>
<imagedata fileref="../common/figures/objectstorage-nodes.png"/>
</imageobject>
</mediaobject>
</figure>
<para>Currently, 2TB or 3TB SATA disks deliver good price/performance value. You can use
desktop-grade drives if you have responsive remote hands in the datacenter and
enterprise-grade drives if you don't.</para>
<section xml:id="section_storage-nodes-considerations">
<title>Factors to consider</title>
<para>You should keep in mind the desired I/O performance for single-threaded requests .
This system does not use RAID, so a single disk handles each request for an object.
Disk performance impacts single-threaded response rates.</para>
<para>To achieve apparent higher throughput, the object storage system is designed to
handle concurrent uploads/downloads. The network I/O capacity (1GbE, bonded 1GbE
pair, or 10GbE) should match your desired concurrent throughput needs for reads and
writes.</para>
</section>
</section>
</section>