From e5ba83585d170a770d0344584c5739b0e6c49150 Mon Sep 17 00:00:00 2001 From: Andreas Jaeger Date: Fri, 25 Jul 2014 20:02:09 +0200 Subject: [PATCH] Arch Design: Edits on compute_focus and storage_focus Edits to follow conventions. Change-Id: I640d27ac6d6b1bc1878b6f196b6c4936f316c914 --- ...on_prescriptive_examples_compute_focus.xml | 2 +- ...ection_user_requirements_compute_focus.xml | 84 +++++-- .../section_architecture_storage_focus.xml | 235 ++++++++++++------ ...ection_user_requirements_storage_focus.xml | 17 +- 4 files changed, 234 insertions(+), 104 deletions(-) diff --git a/doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml b/doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml index b494eb59a1..28b0e90cf5 100644 --- a/doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml +++ b/doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml @@ -11,7 +11,7 @@ provides particle accelerators and other infrastructure for high-energy physics research. As of 2011 CERN operated these two compute centers in Europe - with plans to add a third: + with plans to add a third. To support a growing number of compute heavy users of experiments related to the Large Hadron Collider (LHC) CERN ultimately elected to deploy an OpenStack cloud using diff --git a/doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml b/doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml index e8cc6672b2..6cac44484d 100644 --- a/doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml +++ b/doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml @@ -1,4 +1,8 @@ + +%openstack; +]>
Compute intensive workloads are defined by their high utilization of CPU, RAM, or both. User requirements will determine if a cloud must be built to accommodate anticipated - performance demands. - + performance demands. + + + + Cost - Cost: Cost is not generally a primary concern for a + Cost is not generally a primary concern for a compute-focused cloud, however some organizations might be concerned with cost avoidance. Repurposing existing resources to tackle compute-intensive tasks instead of needing to acquire additional resources may offer cost reduction opportunities. + + + Time to market - Time to Market: Compute-focused clouds can be used + Compute-focused clouds can be used to deliver products more quickly, for example, speeding up a company's software development life cycle (SDLC) for building products and applications. + + + Revenue opportunity - Revenue Opportunity: Companies that are interested + Companies that are interested in building services or products that rely on the power of the compute resources will benefit from a compute-focused cloud. Examples include the analysis @@ -35,7 +48,8 @@ rendering, scientific computation, or simulations. - + +
Legal requirements Many jurisdictions have legislative and regulatory @@ -57,33 +71,41 @@ jurisdictions. - Data compliance - certain types of information needs - to reside in certain locations due to regular issues - - and more important cannot reside in other locations + Data compliance—certain types of information needs + to reside in certain locations due to regular issues—and + more important cannot reside in other locations for the same reason. - Examples of such legal frameworks include the data - protection framework of the European Union - (http://ec.europa.eu/justice/data-protection/ ) and the - requirements of the Financial Industry Regulatory Authority - (http://www.finra.org/Industry/Regulation/FINRARules/ ) in the - United States. Consult a local regulatory body for more - information.
+ + Examples of such legal frameworks include the data + protection framework of the European Union and the + requirements of the Financial + Industry Regulatory Authority in the United + States. Consult a local regulatory body for more + information.
Technical considerations The following are some technical requirements that need to - be incorporated into the architecture design. - + be incorporated into the architecture design. + + + + Performance - Performance: If a primary technical concern is for + If a primary technical concern is for the environment to deliver high performance capability, then a compute-focused design is an obvious choice because it is specifically designed to host compute-intensive workloads. + + + Workload persistence - Workload persistence: Workloads can be either + Workloads can be either short-lived or long running. Short-lived workloads might include continuous integration and continuous deployment (CI-CD) jobs, where large numbers of @@ -104,8 +126,11 @@ workloads is legacy applications that typically are persistent over time. + + + Storage - Storage: Workloads targeted for a compute-focused + Workloads targeted for a compute-focused OpenStack cloud generally do not require any persistent block storage (although some usages of Hadoop with HDFS may dictate the use of persistent @@ -118,8 +143,11 @@ scale the object store or shared file system to match the storage demand. + + + User interface - User Interface: Like any other cloud architecture, a + Like any other cloud architecture, a compute-focused OpenStack cloud requires an on-demand and self-service user interface. End users must be able to provision computing power, storage, networks @@ -127,8 +155,11 @@ scaling the infrastructure up to a substantial level without disrupting host operations. + + + Security - Security: Security is going to be highly dependent + Security is going to be highly dependent on the business requirements. For example, a computationally intense drug discovery application will obviously have much higher security requirements @@ -137,11 +168,14 @@ recommendations and guidelines provided in the OpenStack Security Guide are applicable. -
+ + +
Operational considerations The compute intensive cloud from the operational perspective is similar to the requirements for the general-purpose cloud. More details on operational requirements can be found in the - general-purpose design section.
+ general-purpose design section. + 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 254caee0d5..72281554fc 100644 --- a/doc/arch-design/storage_focus/section_architecture_storage_focus.xml +++ b/doc/arch-design/storage_focus/section_architecture_storage_focus.xml @@ -1,4 +1,8 @@ + +%openstack; +]>
- + + + Cost - Cost: The overall cost of the solution will play a + The overall cost of the solution will play a major role in what storage architecture and the resulting storage hardware that is selected. + + + Performance - Performance: The performance of the solution, + The performance of the solution, measured by observing the latency of storage I-O requests, also plays a major role. In a compute-focused OpenStack cloud storage latency could @@ -48,10 +57,11 @@ storage can have a significant impact on the overall performance of the application. - - + + + Scalability - Scalability: "Scalability" refers to how well the + "Scalability" refers to how well the storage solution performs as it is expanded up to its maximum size. A storage solution that performs well in small configurations but has degrading performance as @@ -61,8 +71,11 @@ ability of the storage solution to continue to perform well as it expands is important. + + + Expandability - Expandability: Here we are referring to the overall + Here we are referring to the overall ability of the solution to grow. A storage solution that expands to 50 PB is considered more expandable than a solution that only scales to 10 PB. Note that @@ -70,7 +83,8 @@ scalability which is a measure of the solution's performance as it expands. - + + Latency is one of the key considerations in a storage-focused OpenStack cloud . Using solid-state disks (SSDs) to minimize latency for instance storage and reduce CPU @@ -97,9 +111,11 @@ Some potential impacts that might affect a particular storage architecture (and corresponding storage hardware) of a Storage-focused OpenStack cloud: - + + + Connectivity - Connectivity: Based on the storage solution + Based on the storage solution selected, ensure the connectivity matches the storage solution requirements. If a centralized storage array is selected it is important to determine how the @@ -109,48 +125,70 @@ characteristics will minimize latency to boost the overall performance of the design. + + + Latency - Latency: Determine if the use case will have + Determine if the use case will have consistent or highly variable latency. + + + Throughput - Throughput: Ensure that the storage solution + Ensure that the storage solution throughput is optimized based on application requirements. + + + Server hardware - Server Hardware: Use of DAS impacts the server + Use of DAS impacts the server hardware choice and affects host density, instance density, power density, OS-hypervisor, and management tools, to name a few. - + +
Compute (server) hardware selection Compute (server) hardware must be evaluated against four opposing dimensions: - + + + Server density - Server density: A measure of how many servers can + A measure of how many servers can fit into a given measure of physical space, such as a rack unit [U]. + + + Resource capacity - Resource capacity: The number of CPU cores, how much + The number of CPU cores, how much RAM, or how much storage a given server will deliver. + + + Expandability - Expandability: The number of additional resources + The number of additional resources that can be added to a server before it has reached its limit. + + + Cost - Cost: The relative of the hardware weighted against + The relative of the hardware weighted against the level of design effort needed to build the system. - + + The dimensions need to be weighed against each other to determine the best design for the desired purpose. For example, increasing server density can mean sacrificing @@ -231,31 +269,40 @@ Other factors that will strongly influence server hardware selection for a storage-focused OpenStack design architecture: - + + + Instance density - Instance density: In this architecture, instance + In this architecture, instance density and CPU-RAM oversubscription are lower. More hosts will be required to support the anticipated scale, especially if the design uses dual-socket hardware designs. + + + Host density - Host density: Another option to address the higher + Another option to address the higher host count is to use a quad socket platform. Taking this approach will decrease host density which also increases rack count. This configuration affects the number of power connections and also impacts network and cooling requirements. + + + Power and cooling density - Power and cooling density: The power and cooling + The power and cooling density requirements might be lower than with blade, sled, or 1U server designs due to lower host density (by using 2U, 3U or even 4U server designs). For data centers with older infrastructure, this might be a desirable feature. - + + Storage-focused OpenStack design architecture server hardware selection should focus on a "scale up" versus "scale out" solution. The determination of which will be the best @@ -267,17 +314,22 @@ Networking hardware selection Some of the key considerations that should be included in the selection of networking hardware include: - + + + Port count - Port count: The user will require networking + The user will require networking hardware that has the requisite port count. + + + Port density - Port density: The network design will be affected by + The network design will be affected by the physical space that is required to provide the - requisite port count. A switch that can provide 48 10 - GbE ports in 1U has a much higher port density than a - switch that provides 24 10 GbE ports in 2U. On a + requisite port count. A switch that can provide 48 10 GbE + ports in 1U has a much higher port density than a + switch that provides 24 10 GbE ports in 2U. On a general scale, a higher port density leaves more rack space for compute or storage components which is preferred. It is also important to consider fault @@ -285,13 +337,19 @@ switches are more expensive, therefore it is important not to over design the network. + + + Port speed - Port speed: The networking hardware must support the - proposed network speed, for example: 1 GbE, 10 GbE, or - 40 GbE (or even 100 GbE). + The networking hardware must support the + proposed network speed, for example: 1 GbE, 10 GbE, or + 40 GbE (or even 100 GbE). + + + Redundancy - Redundancy: The level of network hardware redundancy + The level of network hardware redundancy required is influenced by the user requirements for high availability and cost considerations. Network redundancy can be achieved by adding redundant power @@ -300,22 +358,30 @@ User requirements will determine if a completely redundant network infrastructure is required. + + + Power requirements - Power requirements: Make sure that the physical data + Make sure that the physical data center provides the necessary power for the selected network hardware. This is not typically an issue for top of rack (ToR) switches, but may be an issue for spine switches in a leaf and spine fabric, or end of row (EoR) switches. + + + Protocol support - Protocol support: It is possible to gain even more + It is possible to gain even more performance out of a single storage system by using specialized network technologies such as RDMA, SRP, iSER and SCST. The specifics for using these technologies is beyond the scope of this book. -
+ + +
Software selection Selecting software to be included in a storage-focused @@ -346,9 +412,11 @@ support it. Some areas that could be impacted by the selection of OS and hypervisor include: - + + + Cost - Cost: Selection of a commercially supported + Selection of a commercially supported hypervisor, such as Microsoft Hyper-V, will result in a different cost model rather than selected a community-supported open source hypervisor like @@ -358,8 +426,11 @@ requirements might dictate a specific or commercially supported hypervisor. + + + Supportability - Supportability: Whichever hypervisor is chosen, the + Whichever hypervisor is chosen, the staff needs to have appropriate training and knowledge to support the selected OS and hypervisor combination. If they do not training will need to be provided, @@ -372,8 +443,11 @@ resources. Either decision has a cost that will have an impact on the design. + + + Management tools - Management tools: The management tools used for + The management tools used for Ubuntu and Kinstance differ from the management tools for VMware vSphere. Although both OS and hypervisor combinations are supported by OpenStack, there will @@ -381,16 +455,22 @@ design as a result of the selection of one combination versus the other. + + + Scale and performance - Scale and performance: Make sure that selected OS + Make sure that selected OS and hypervisor combination meet the appropriate scale and performance requirements needed for this general purpose OpenStack cloud. The chosen architecture will need to meet the targeted instance-host ratios with the selected OS-hypervisor combination. + + + Security - Security: Make sure that the design can accommodate + Make sure that the design can accommodate the regular periodic installation of application security patches while maintaining the required workloads. The frequency of security patches for the @@ -398,8 +478,11 @@ on performance and the patch installation process could affect maintenance windows. + + + Supported features - Supported features: Determine what features of + Determine what features of OpenStack are required. This will often determine the selection of the OS-hypervisor combination. Certain features are only available with specific OSs or @@ -407,8 +490,11 @@ available, the design might need to be modified to meet the user requirements. + + + Interoperability - Interoperability: Consideration should be given to + Consideration should be given to the ability of the selected OS-hypervisor combination to interoperate or co-exist with other OS-hypervisors ,or other software solutions in the overall design, if @@ -419,7 +505,9 @@ address if the two sets of tools need to interoperate. -
+ + +
OpenStack components The selection of OpenStack components has a significant @@ -439,36 +527,36 @@ following components would typically be used: - Keystone + OpenStack Identity (keystone) - Horizon + OpenStack dashboard (horizon) - Nova (including the use of multiple hypervisor + OpenStack Compute (nova) (including the use of multiple hypervisor drivers) - Swift (or another object storage solution) + OpenStack Object Storage (swift) (or another object storage solution) - Cinder + OpenStack Block Storage (cinder) - Glance + OpenStack Image Service (glance) - Neutron or nova-network + OpenStack Networking (neutron) or nova-network The exclusion of certain OpenStack components may limit or constrain the functionality of other components. If a design - opts to include Heat but exclude Ceilometer, then the design - will not be able to take advantage of Heat's auto scaling - functionality (which relies on information from Ceilometer). - Due to the fact that you can use Heat to spin up a large + opts to include Orchestration but exclude Telemetry, then the design + will not be able to take advantage of Orchestration's auto scaling + functionality (which relies on information from Telemetry). + Due to the fact that you can use Orchestration to spin up a large number of instances to perform the compute-intensive - processing, including Heat in a compute-focused architecture + processing, including Orchestration in a compute-focused architecture design is strongly recommended.
Supplemental software @@ -478,18 +566,21 @@ any given OpenStack design.
Networking software - OpenStack Neutron provides a wide variety of networking + OpenStack Networking (neutron) provides a wide variety of networking 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). Some of these software packages, HAProxy in particular, are described - in more detail in the OpenStack HA Guide (refer to Chapter 8 - of the OpenStack High Availability Guide). For a general - purpose OpenStack cloud, it is reasonably likely that the - OpenStack infrastructure components will need to be highly - available, and therefore networking software packages like - HAProxy will need to be included.
+ in more detail in the OpenStack High Availability + Guide (refer to the Network + controller cluster stack chapter of the OpenStack High + Availability Guide). For a general purpose OpenStack cloud, it + is reasonably likely that the OpenStack infrastructure + components will need to be highly available, and therefore + networking software packages like HAProxy will need to be + included.
Management software This includes software for providing clustering, logging, @@ -504,8 +595,8 @@ Therefore, the impact of including (or not including) these software packages is determined by the availability of the cloud infrastructure and the complexity of supporting the - configuration after it is deployed. The OpenStack High - Availability Guide provides more details on the installation + configuration after it is deployed. The OpenStack High + Availability Guide provides more details on the installation and configuration of Corosync and Pacemaker, should these packages need to be included in the design. Requirements for logging, monitoring, and alerting are @@ -526,7 +617,7 @@ design impacts include: - OS - Hypervisor combination: Ensure that the + OS-Hypervisor combination: Ensure that the selected logging, monitoring, or alerting tools support the proposed OS-hypervisor combination. @@ -545,7 +636,7 @@ of the OpenStack services. MySQL is generally considered to be the de facto database for OpenStack, however, other compatible databases are also - known to work. Note, however, that Ceilometer uses + known to work. Note, however, that Telemetry uses MongoDB. The solution selected to provide high availability for the database will change based on the selected database. If MySQL @@ -570,4 +661,6 @@ components might require it depending on the specific implementation. -
+ + + diff --git a/doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml b/doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml index ab40ee5a97..bf22fab7ed 100644 --- a/doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml +++ b/doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml @@ -58,13 +58,16 @@ other locations for the same reason. - Examples of such legal frameworks include the data - protection framework of the European Union - (http://ec.europa.eu/justice/data-protection/ ) and the - requirements of the Financial Industry Regulatory Authority - (http://www.finra.org/Industry/Regulation/FINRARules/ ) in the - United States. Consult a local regulatory body for more - information. + + Examples of such legal frameworks include the data + protection framework of the European Union and the + requirements of the Financial + Industry Regulatory Authority in the United + States. Consult a local regulatory body for more information. + +
Technical requirements The following are some technical requirements that could be