openstack/openstack-manuals
Code Issues Proposed changes

Merge "[arch-guide] Completing storage design section"

Browse Source
This commit is contained in:
Jenkins 2017-08-08 09:28:39 +00:00 committed by Gerrit Code Review
commit 1787ce4093
1 changed files with 17 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
doc/arch-design/source/design-storage/design-storage-arch.rst
View File

@ -24,9 +24,6 @@ be answered:
Choosing storage back ends Choosing storage back ends
~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~
.. TODO how to decide (encryption, SLA requirements, live migration
availability)
Users will indicate different needs for their cloud architecture. Some may Users will indicate different needs for their cloud architecture. Some may
need fast access to many objects that do not change often, or want to 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 set a time-to-live (TTL) value on a file. Others may access only storage
@ -163,9 +160,6 @@ compute cloud are to provide:
Selecting storage hardware Selecting storage hardware
~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~
.. TODO how to design (IOPS requirements [spinner vs SSD]/Read+Write/
Availability/Migration)
Storage hardware architecture is determined by selecting specific storage Storage hardware architecture is determined by selecting specific storage
architecture. Determine the selection of storage architecture by architecture. Determine the selection of storage architecture by
evaluating possible solutions against the critical factors, the user evaluating possible solutions against the critical factors, the user
@ -260,12 +254,17 @@ What about SSD? DRAM SSD?
(14x) (14x)
Scalability Scalability
Scalability, along with expandability, is a major consideration in a Scalability, along with expandability, is a major consideration in
general purpose OpenStack cloud. It might be difficult to predict a general purpose OpenStack cloud. It might be difficult to predict the final
the final intended size of the implementation as there are no intended size of the implementation as there are no established usage patterns
established usage patterns for a general purpose cloud. It might for a general purpose cloud. It might become necessary to expand the initial
become necessary to expand the initial deployment in order to deployment in order to accommodate growth and user demand. Many vendors have
accommodate growth and user demand. implemented their own solutions to this problem. Some use clustered file
systems that span multiple appliances, while others have similar technologies
to allow block storage to scale past a fixed capacity. Ceph, a distributed
storage solution that offers block storage, was designed to solve this scale
issue and does not have the same limitations on domains, clusters, or scale
issues of other appliance driven models.
Expandability Expandability
Expandability is a major architecture factor for storage solutions Expandability is a major architecture factor for storage solutions
@ -492,7 +491,12 @@ nodes and proxy servers should make use of a design which is scalable.
Redundancy Redundancy
---------- ----------
When making swift more redundant, one approach is to add additonal proxy
servers and load balancing. HAProxy is one method of providing load
balancing and high availability and is often combined with keepalived
or pacemaker to ensure the HAProxy service maintains a stable VIP.
Sample HAProxy configurations can be found in the `OpenStack HA Guide.
<https://docs.openstack.org/ha-guide/controller-ha-haproxy.html#configuring-haproxy>`_.
Replication Replication
----------- -----------