diff --git a/doc/arch-design/storage_focus/section_architecture_storage_focus.xml b/doc/arch-design/storage_focus/section_architecture_storage_focus.xml index 218a43e7c0..3578e316d1 100644 --- a/doc/arch-design/storage_focus/section_architecture_storage_focus.xml +++ b/doc/arch-design/storage_focus/section_architecture_storage_focus.xml @@ -9,7 +9,7 @@ version="5.0" xml:id="architecture-storage-hardware"> Architecture - There are three areas to consider when selecting storage hardware: + Consider the following factors when selecting storage hardware: Cost @@ -21,15 +21,15 @@ Reliability - Storage-focused OpenStack clouds must reflect that the workloads are storage - intensive. These workloads are not compute intensive, nor are - they consistently network intensive. The network may be + Storage-focused OpenStack clouds must address I/O + intensive workloads. These workloads are not CPU intensive, + nor are they consistently network intensive. The network may be heavily utilized to transfer storage, but they are not otherwise network intensive. - For a storage-focused OpenStack design architecture, the - selection of storage hardware determines the overall - performance and scalability of the design architecture. Several factors - impact the design process: + The selection of storage hardware determines the overall + performance and scalability of a storage-focused OpenStack design + architecture. + Several factors impact the design process, including: Cost @@ -57,50 +57,35 @@ that performs well as it expands. - - Expandability - - Expandability is the overall ability of the solution - to grow. A storage solution that expands to 50 PB is - more expandable than a solution that only scales to 10 PB. - - This meter is related to scalability. - - - - - Latency is a key consideration in a - storage-focused OpenStack cloud. Using solid-state disks - (SSDs) to minimize latency for instance storage, and to reduce - CPU delays caused by waiting for the storage, increases - performance. We recommend evaluating the - gains from using RAID controller cards in compute hosts to - improve the performance of the underlying disk - subsystem. - The selection of storage architecture determines if a scale-out - solution should be used or if a single, highly expandable and - scalable centralized storage array would be a better choice. - If a centralized storage array is the right fit for the requirements - then the array vendor determines the hardware selection. It is possible - to build a storage array using commodity hardware with Open Source - software, but requires people with expertise to build such a system. + Latency is a key consideration in a storage-focused OpenStack cloud. + Using solid-state disks (SSDs) to minimize latency and, to reduce CPU + delays caused by waiting for the storage, increases performance. Use RAID + controller cards in compute hosts to improve the performance of the + underlying disk subsystem. + Depending on the storage architecture, you can adopt a scale-out + solution, or use a highly expandable and scalable centralized storage + array. If a centralized storage array is the right fit for + your requirements, then the array vendor determines the hardware + selection. It is possible to build a storage array using commodity + hardware with Open Source software, but requires people with expertise + to build such a system. On the other hand, a scale-out storage solution that uses direct-attached storage (DAS) in the servers may be an appropriate choice. This requires configuration of the server hardware to support the storage solution. Considerations affecting storage architecture (and corresponding - storage hardware) of a Storage-focused OpenStack cloud: + storage hardware) of a Storage-focused OpenStack cloud include: Connectivity Based on the selected storage solution, ensure the connectivity matches the storage solution requirements. - If selecting centralized storage array, determine how the - hypervisors connect to the storage array. - Connectivity can affect latency and thus performance. - We recommended confirming that the network + For example, if you select a centralized storage array, + determine how the hypervisors connect to the storage + array. Connectivity can affect latency and thus + performance. We recommended confirming that the network characteristics minimize latency to boost the overall performance of the design. @@ -116,7 +101,7 @@ Throughput Ensure that the storage solution - throughput is optimized based on application + throughput is optimized for your application requirements. @@ -133,8 +118,8 @@
Compute (server) hardware selection - Evaluate Compute (server) hardware four - opposing dimensions: + Four opposing factors determine the compute (server) + hardware selection: Server density @@ -161,7 +146,7 @@ Cost - The relative of the hardware weighted against + The relative cost of the hardware weighed against the level of design effort needed to build the system. @@ -213,8 +198,8 @@ (ODMs) or second-tier manufacturers. This may cause issues for organizations that have - preferred vendor policies or concerns with support and hardware - warranties of non-tier 1 vendors. + preferred vendor policies or concerns with support and + hardware warranties of non-tier 1 vendors. @@ -235,8 +220,8 @@ Rack-mounted servers that support multiple independent servers in a single - 2U or 3U enclosure, "sled servers", deliver increased density as - compared to a typical 1U-2U rack-mounted servers. + 2U or 3U enclosure, "sled servers", deliver increased + density as compared to a typical 1U-2U rack-mounted servers. For example, many sled servers offer four independent dual-socket nodes in 2U for a total of 8 CPU sockets in 2U. However, the dual-socket limitation on @@ -244,9 +229,9 @@ additional cost and configuration complexity. - Other factors strongly influence server hardware + Other factors that influence server hardware selection for a storage-focused OpenStack design - architecture. The following is a list of these factors: + architecture include: Instance density @@ -262,7 +247,7 @@ Host density Another option to address the higher - host count is to use a quad socket platform. Taking + host count is to use a quad-socket platform. Taking this approach decreases host density which also increases rack count. This configuration affects the number of power connections and also impacts network @@ -282,10 +267,10 @@ Storage-focused OpenStack design architecture server - hardware selection should focus on a "scale up" versus "scale - out" solution. The determination of which is the best - solution, a smaller number of larger hosts or a larger number of - smaller hosts, depends on a combination of factors + hardware selection should focus on a "scale-up" versus + "scale-out" solution. The determination of which is the best + solution (a smaller number of larger hosts or a larger number of + smaller hosts), depends on a combination of factors including cost, power, cooling, physical rack and floor space, support-warranty, and manageability.
@@ -366,8 +351,8 @@
Software selection - Selecting software for a storage-focused - OpenStack architecture design includes three areas: + Factors that influence the software selection for a storage-focused + OpenStack architecture design include: Operating system (OS) and hypervisor @@ -385,19 +370,20 @@
Operating system and hypervisor - Selecting the OS and hypervisor has a significant impact - on the overall design and also affects server hardware - selection. Ensure that the selected operating system and + Operating system (OS) and hypervisor have a significant impact + on the overall design and also affect server hardware + selection. Ensure the selected operating system and hypervisor combination support the storage hardware and work with the networking hardware selection and topology. For example, Link Aggregation Control Protocol (LACP) requires - support from both the OS and hypervisor. - OS and hypervisor selection affect the following areas: + support from both the operating system and hypervisor. + Operating system and hypervisor selection affect the following + areas: Cost - Selection of a commercially supported + Selecting a commercially supported hypervisor, such as Microsoft Hyper-V, results in a different cost model than a community-supported open source hypervisor like @@ -434,7 +420,7 @@ Scale and performance - Ensure that the selected OS + Ensure the selected OS and hypervisor combination meet the appropriate scale and performance requirements needed for this storage focused OpenStack cloud. The chosen architecture must @@ -445,7 +431,7 @@ Security - Ensure that the design can accommodate + Ensure the design can accommodate the regular periodic installation of application security patches while maintaining the required workloads. The frequency of security patches for the @@ -457,19 +443,17 @@ Supported features - Determine the required features of - OpenStack. This often determines the - selection of the OS-hypervisor combination. Certain - features are only available with specific OSes or - hypervisors. For example, if certain features are not - available, you might need to modify the design to - meet user requirements. + Selecting the OS-hypervisor combination often determines + the required features of OpenStack. Certain features are only + available with specific OSes or hypervisors. For example, + if certain features are not available, you might need to modify + the design to meet user requirements. Interoperability - Any chosen OS/hypervisor combination should be chosen + The OS-hypervisor combination should be chosen based on the interoperability with one another, and other OS-hyervisor combinations. Operational and troubleshooting tools for one OS-hypervisor combination may differ @@ -484,19 +468,19 @@
OpenStack components - Which OpenStack components you choose can have a significant + The OpenStack components you choose can have a significant impact on the overall design. While there are certain - components that are always present, Compute and Image service, for - example, there are other services that may not need to be - present. As an example, a certain design may not require - the Orchestration module. Omitting Orchestration would not typically have a - significant impact on the overall design, however, if the - architecture uses a replacement for OpenStack Object Storage for its - storage component, this could potentially have significant - impacts on the rest of the design. + components that are always present + (Compute and Image service, for example), there are other services + that may not be required. As an example, a certain design + may not require the Orchestration module. Omitting Orchestration would + not typically have a significant impact on the overall design, + however, if the architecture uses a replacement for OpenStack Object + Storage for its storage component, this could potentially have + significant impacts on the rest of the design. A storage-focused design might require the ability to use - Orchestration to launch instances with Block Storage volumes to perform - storage-intensive processing. + Orchestration to launch instances with Block Storage volumes to + perform storage-intensive processing. A storage-focused OpenStack design architecture typically uses the following components: @@ -507,11 +491,12 @@ OpenStack dashboard (horizon) - OpenStack Compute (nova) (including the use of multiple hypervisor - drivers) + OpenStack Compute (nova) (including the use of multiple + hypervisor drivers) - OpenStack Object Storage (swift) (or another object storage solution) + OpenStack Object Storage (swift) (or another object + storage solution) OpenStack Block Storage (cinder) @@ -520,7 +505,8 @@ OpenStack Image service (glance) - OpenStack Networking (neutron) or legacy networking (nova-network) + OpenStack Networking (neutron) or legacy networking + (nova-network) Excluding certain OpenStack components may limit or @@ -547,7 +533,7 @@ services for instances. There are many additional networking software packages that may be useful to manage the OpenStack components themselves. Some examples include HAProxy, - keepalived, and various routing daemons (like Quagga). The + Keepalived, and various routing daemons (like Quagga). The OpenStack High Availability Guide describes some of these software packages, HAProxy in particular. See the Network