From d81f3251a70d1cd5ca5209130dfa7d569a90fe6b Mon Sep 17 00:00:00 2001 From: asettle Date: Tue, 18 Aug 2015 13:30:25 +1000 Subject: [PATCH] Edits to the prescriptive examples and tech consideration files 1. Removal of duplicated content 2. Removal of unnecessary content 3. Edits to existing content Change-Id: Ib44cb3364dd7ec199e6134906fc83b575e6e4150 Implements: blueprint arch-guide --- ...on_prescriptive_examples_compute_focus.xml | 46 ++-- ...tion_tech_considerations_compute_focus.xml | 254 ++++-------------- 2 files changed, 76 insertions(+), 224 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 36ce259f27..2ce4e220d5 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 @@ -80,23 +80,31 @@ There is also some customization of the filter scheduler that handles placement within the cells: - - ImagePropertiesFilter - To provide special handling + + ImagePropertiesFilter + + Provides special handling depending on the guest operating system in use (Linux-based or Windows-based). - ProjectsToAggregateFilter - To provide special - handling depending on the project the instance is + + ProjectsToAggregateFilter + Provides special + handling depending on which project the instance is associated with. - default_schedule_zones - Allows the selection of + + default_schedule_zones + Allows the selection of multiple default availability zones, rather than a - single default. - - + single default. + + + A central database team manages the MySQL database server in each cell in an active/passive configuration with a NetApp storage back end. Backups run every 6 hours. +
Network architecture To integrate with existing networking infrastructure, CERN @@ -110,7 +118,9 @@ placed an instance and selects a MAC address and IP from the pre-registered list associated with that node in the database. The database updates to reflect the address assignment to - that instance.
+ that instance. + +
Storage architecture CERN deploys the OpenStack Image service in the API cell and @@ -119,7 +129,9 @@ use is a 3 PB Ceph cluster. CERN maintains a small set of Scientific Linux 5 and 6 images onto which orchestration tools can place applications. Puppet manages - instance configuration and customization.
+ instance configuration and customization. + +
Monitoring CERN does not require direct billing, but uses the Telemetry module @@ -147,18 +159,4 @@ project.
-
References - The authors of the Architecture Design Guide would like to - thank CERN for publicly documenting their OpenStack deployment - in these resources, which formed the basis for this - chapter: - - http://openstack-in-production.blogspot.fr - - - Deep - dive into the CERN Cloud Infrastructure - -
diff --git a/doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml b/doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml index 7ddb76ae37..a8a083a840 100644 --- a/doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml +++ b/doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml @@ -12,10 +12,7 @@ Technical considerations In a compute-focused OpenStack cloud, the type of instance workloads you provision heavily influences technical - decision making. For example, specific use cases that demand - multiple, short-running jobs present different requirements - than those that specify long-running jobs, even though both - situations are compute focused. + decision making. Public and private clouds require deterministic capacity planning to support elastic growth in order to meet user SLA expectations. Deterministic capacity planning is the path to @@ -23,21 +20,19 @@ perform consistently. This process is important because, when a service becomes a critical part of a user's infrastructure, the user's experience links directly to the SLAs of - the cloud itself. In cloud computing, it is not average speed but - speed consistency that determines a service's performance. - There are two aspects of capacity planning to consider: + the cloud itself. + There are two aspects of capacity planning to consider: - planning the initial deployment footprint + Planning the initial deployment footprint - planning expansion of it to stay ahead of the demands of cloud - users + Planning expansion of the environment to stay ahead of the + demands of cloud users - Plan the initial footprint for an OpenStack deployment - based on existing infrastructure workloads - and estimates based on expected uptake. + Begin planning an initial OpenStack deployment footprint with + estimations of expected uptake, and existing infrastructure workloads. The starting point is the core count of the cloud. By applying relevant ratios, the user can gather information about: @@ -50,7 +45,7 @@ Required storage: flavor disk size × number of instances - Use these ratios to determine the amount of + These ratios determine the amount of additional infrastructure needed to support the cloud. For example, consider a situation in which you require 1600 instances, each with 2 vCPU and 50 GB of storage. Assuming the @@ -61,7 +56,7 @@ 1600 = (16 × (number of physical cores)) / 2 - storage required = 50 GB × 1600 + Storage required = 50 GB × 1600 On the surface, the equations reveal the need for 200 @@ -71,19 +66,10 @@ look at patterns of usage to estimate the load that the API services, database servers, and queue servers are likely to encounter. - Consider, for example, the differences between a cloud that - supports a managed web-hosting platform and one running - integration tests for a development project that creates one - instance per code commit. In the former, the heavy work of - creating an instance happens only every few months, whereas - the latter puts constant heavy load on the cloud controller. - The average instance lifetime is significant, as a larger - number generally means less load on the cloud - controller. Aside from the creation and termination of instances, consider the impact of users accessing the service, particularly on nova-api and its associated database. Listing - instances gathers a great deal of information and, given the + instances gathers a great deal of information and given the frequency with which users run this operation, a cloud with a large number of users can increase the load significantly. This can even occur unintentionally. For example, the @@ -104,17 +90,12 @@ the impacts of different hardware and instance load outs. See: https://github.com/noslzzp/cloud-resource-calculator/blob/master/cloud-resource-calculator.ods +
Expansion planning A key challenge for planning the expansion of cloud compute services is the elastic nature of cloud infrastructure - demands. Previously, new users or customers had to - plan for and request the infrastructure they required ahead of - time, allowing time for reactive procurement processes. Cloud - computing users have come to expect the agility of having - instant access to new resources as required. - Consequently, plan for typical usage and for sudden bursts in - usage. + demands. Planning for expansion is a balancing act. Planning too conservatively can lead to unexpected oversubscription of the cloud and dissatisfied users. Planning @@ -127,31 +108,11 @@ average speed or capacity of the cloud. Using this information to model capacity performance enables users to more accurately determine the current and future capacity of the - cloud.
-
CPU and RAM - Adapted from: - http://docs.openstack.org/openstack-ops/content/compute_nodes.html#cpu_choice - In current generations, CPUs have up to 12 cores. If an - Intel CPU supports Hyper-Threading, those 12 cores double - to 24 cores. A server that supports multiple CPUs multiplies - the number of available cores. - Hyper-Threading is Intel's proprietary simultaneous - multi-threading implementation, used to improve - parallelization on their CPUs. Consider enabling - Hyper-Threading to improve the performance of multithreaded - applications. - Whether the user should enable Hyper-Threading on a CPU - depends on the use case. For example, disabling - Hyper-Threading can be beneficial in intense computing - environments. Running performance tests using local - workloads with and without Hyper-Threading can help - determine which option is more appropriate in any particular - case. - If they must run the Libvirt or KVM hypervisor drivers, - then the compute node CPUs must support - virtualization by way of the VT-x extensions for Intel chips - and AMD-v extensions for AMD chips to provide full - performance. + cloud. +
+ +
+ CPU and RAM OpenStack enables users to overcommit CPU and RAM on compute nodes. This allows an increase in the number of instances running on the cloud at the cost of reducing the @@ -176,13 +137,10 @@ long as the total amount of RAM associated with the instances is less than 1.5 times the amount of RAM available on the physical node. - For example, if a physical node has 48 GB of RAM, the - scheduler allocates instances to that node until the sum of - the RAM associated with the instances reaches 72 GB (such as - nine instances, in the case where each instance has 8 GB of - RAM). You must select the appropriate CPU and RAM allocation ratio - based on particular use cases.
+ based on particular use cases. + +
Additional hardware Certain use cases may benefit from exposure to additional @@ -193,8 +151,6 @@ the availability of graphics processing units (GPUs) for general-purpose computing. - - Cryptographic routines that benefit from the availability of hardware random number generators to @@ -210,11 +166,14 @@ characteristics, which can include hardware similarities. The addition of specialized hardware to a cloud deployment is likely to add to the cost of each node, so consider carefully - consideration whether all compute nodes, or + whether all compute nodes, or just a subset targeted by flavors, need the additional customization to support the desired - workloads.
-
Utilization + workloads. +
+ +
+ Utilization Infrastructure-as-a-Service offerings, including OpenStack, use flavors to provide standardized views of virtual machine resource requirements that simplify the problem of scheduling @@ -253,107 +212,9 @@ different ratios of CPU versus RAM versus HDD requirements. For more information on Flavors see: - http://docs.openstack.org/openstack-ops/content/flavors.html -
-
Performance - So that workloads can consume as many resources - as are available, do not share cloud infrastructure. Ensure you accommodate - large scale workloads. - The duration of batch processing differs depending on - individual workloads. Time limits range from - seconds to hours, and as a result it is difficult to predict resource - use. -
-
Security - The security considerations for this scenario are - similar to those of the other scenarios in this guide. - A security domain comprises users, applications, servers, - and networks that share common trust requirements and - expectations within a system. Typically they have the same - authentication and authorization requirements and - users. - These security domains are: - - - Public - - - Guest - - - Management - - - Data - - - You can map these security domains individually to the - installation, or combine them. For example, some - deployment topologies combine both guest and data domains onto - one physical network, whereas in other cases these networks - are physically separate. In each case, the cloud operator - should be aware of the appropriate security concerns. Map out - security domains against specific OpenStack - deployment topology. The domains and their trust requirements - depend on whether the cloud instance is public, private, or - hybrid. - The public security domain is an untrusted area of - the cloud infrastructure. It can refer to the Internet as a - whole or simply to networks over which the user has no - authority. Always consider this domain untrusted. - Typically used for compute instance-to-instance traffic, the - guest security domain handles compute data generated by - instances on the cloud. It does not handle services that support the - operation of the cloud, for example API calls. Public cloud - providers and private cloud providers who do not have - stringent controls on instance use or who allow unrestricted - Internet access to instances should consider this an untrusted domain. - Private cloud providers may want to consider this - an internal network and therefore trusted only if they have - controls in place to assert that they trust instances and all - their tenants. - The management security domain is where services interact. - Sometimes referred to as the "control plane", the networks in - this domain transport confidential data such as configuration - parameters, user names, and passwords. In most deployments this - is a trusted domain. - The data security domain deals with - information pertaining to the storage services within - OpenStack. Much of the data that crosses this network has high - integrity and confidentiality requirements and depending on - the type of deployment there may also be strong availability - requirements. The trust level of this network is heavily - dependent on deployment decisions and as such we do not assign - this a default level of trust. - When deploying OpenStack in an enterprise as a private cloud, you can - generally assume it is behind a firewall and within the trusted - network alongside existing systems. Users of the cloud are - typically employees or trusted individuals that are bound by - the security requirements set forth by the company. This tends - to push most of the security domains towards a more trusted - model. However, when deploying OpenStack in a public-facing - role, you cannot make these assumptions and the number of attack vectors - significantly increases. For example, the API endpoints and the - software behind it become vulnerable to hostile - entities attempting to gain unauthorized access or prevent access - to services. This can result in loss of reputation and you must - protect against it through auditing and appropriate - filtering. - Take care when managing the users of the - system, whether in public or private - clouds. The identity service enables LDAP to be part of the - authentication process, and includes such systems as an - OpenStack deployment that may ease user management if - integrated into existing systems. - We recommend placing API services behind hardware that - performs SSL termination. API services - transmit user names, passwords, and generated tokens between - client machines and API endpoints and therefore must be - secure. - For more information on OpenStack Security, see - http://docs.openstack.org/security-guide/ - + OpenStack Operations Guide: Flavors
+
OpenStack components Due to the nature of the workloads in this @@ -376,47 +237,40 @@ Orchestration module (heat) + Given the nature of the + applications involved in this scenario, these are heavily + automated deployments. Making use of Orchestration is highly + beneficial in this case. You can script the deployment of a + batch of instances and the running of tests, but it + makes sense to use the Orchestration module + to handle all these actions. - - It is safe to assume that, given the nature of the - applications involved in this scenario, these are heavily - automated deployments. Making use of Orchestration is highly - beneficial in this case. You can script the deployment of a - batch of instances and the running of tests, but it - makes sense to use the Orchestration module - to handle all these actions. - Telemetry module (ceilometer) + Telemetry and the alarms it generates support autoscaling + of instances using Orchestration. Users that are not using the + Orchestration module do not need to deploy the Telemetry module and + may choose to use external solutions to fulfill their + metering and monitoring requirements. - - Telemetry and the alarms it generates support autoscaling - of instances using Orchestration. Users that are not using the - Orchestration module do not need to deploy the Telemetry module and - may choose to use external solutions to fulfill their - metering and monitoring requirements. - See also: - http://docs.openstack.org/openstack-ops/content/logging_monitoring.html - OpenStack Block Storage (cinder) + Due to the burst-able nature of the workloads and the + applications and instances that perform batch + processing, this cloud mainly uses memory or CPU, so + the need for add-on storage to each instance is not a likely + requirement. This does not mean that you do not use + OpenStack Block Storage (cinder) in the infrastructure, but + typically it is not a central component. - - Due to the burst-able nature of the workloads and the - applications and instances that perform batch - processing, this cloud mainly uses memory or CPU, so - the need for add-on storage to each instance is not a likely - requirement. This does not mean that you do not use - OpenStack Block Storage (cinder) in the infrastructure, but - typically it is not a central component. - Networking + When choosing a networking platform, ensure that it either + works with all desired hypervisor and container technologies + and their OpenStack drivers, or that it includes an implementation of + an ML2 mechanism driver. You can mix networking platforms + that provide ML2 mechanisms drivers. - When choosing a networking platform, ensure that it either - works with all desired hypervisor and container technologies - and their OpenStack drivers, or that it includes an implementation of - an ML2 mechanism driver. You can mix networking platforms - that provide ML2 mechanisms drivers.
+