2163ad9a00
Restores Troubleshoot Object Storage Removes Monitoring section, which was based on a blog backport: havana Closes-Bug: #1251515 author: nermina miller Change-Id: I580b077a0124d7cd54dced6c0d340e05d5d5f983
76 lines
4.8 KiB
XML
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)
|
||
interfacesone 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>
|