# SOME DESCRIPTIVE TITLE. # Copyright (C) 2015-2016, OpenStack contributors # This file is distributed under the same license as the Architecture Design Guide package. # FIRST AUTHOR , YEAR. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: Architecture Design Guide 0.9\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2016-03-15 06:09+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# hybrid-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# multi-site-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# network-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:3 ../generalpurpose-architecture.rst:3 #: ../hybrid-architecture.rst:3 ../multi-site-architecture.rst:3 #: ../network-focus-architecture.rst:2 ../storage-focus-architecture.rst:2 msgid "Architecture" msgstr "" #: ../compute-focus-architecture.rst:4 msgid "The hardware selection covers three areas:" msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:6 ../generalpurpose-architecture.rst:7 #: ../generalpurpose-technical-considerations.rst:7 msgid "Compute" msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:8 ../generalpurpose-architecture.rst:9 #: ../generalpurpose-technical-considerations.rst:9 msgid "Network" msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# multi-site-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# multi-site-user-requirements.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:10 ../generalpurpose-architecture.rst:11 #: ../generalpurpose-technical-considerations.rst:11 #: ../multi-site-architecture.rst:51 ../multi-site-user-requirements.rst:112 msgid "Storage" msgstr "" #: ../compute-focus-architecture.rst:12 msgid "" "Compute-focused OpenStack clouds have high demands on processor and memory " "resources, and requires hardware that can handle these demands. Consider the " "following factors when selecting compute (server) hardware:" msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:16 ../generalpurpose-architecture.rst:39 #: ../storage-focus-architecture.rst:84 msgid "Server density" msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:18 ../generalpurpose-architecture.rst:43 #: ../storage-focus-architecture.rst:88 msgid "Resource capacity" msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:20 ../generalpurpose-architecture.rst:46 #: ../generalpurpose-architecture.rst:162 ../storage-focus-architecture.rst:92 msgid "Expandability" msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-user-requirements.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# hybrid-user-requirements.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# multi-site-user-requirements.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:22 ../compute-focus-architecture.rst:111 #: ../generalpurpose-architecture.rst:50 #: ../generalpurpose-architecture.rst:147 #: ../generalpurpose-architecture.rst:355 #: ../generalpurpose-user-requirements.rst:27 #: ../hybrid-user-requirements.rst:24 ../multi-site-user-requirements.rst:101 #: ../storage-focus-architecture.rst:6 ../storage-focus-architecture.rst:23 #: ../storage-focus-architecture.rst:96 ../storage-focus-architecture.rst:265 msgid "Cost" msgstr "" #: ../compute-focus-architecture.rst:24 msgid "" "Weigh these considerations against each other to determine the best design " "for the desired purpose. For example, increasing server density means " "sacrificing resource capacity or expandability." msgstr "" #: ../compute-focus-architecture.rst:28 msgid "" "A compute-focused cloud should have an emphasis on server hardware that can " "offer more CPU sockets, more CPU cores, and more RAM. Network connectivity " "and storage capacity are less critical." msgstr "" #: ../compute-focus-architecture.rst:32 msgid "" "When designing a compute-focused OpenStack architecture, you must consider " "whether you intend to scale up or scale out. Selecting a smaller number of " "larger hosts, or a larger number of smaller hosts, depends on a combination " "of factors: cost, power, cooling, physical rack and floor space, support-" "warranty, and manageability." msgstr "" #: ../compute-focus-architecture.rst:38 msgid "Considerations for selecting hardware:" msgstr "" #: ../compute-focus-architecture.rst:40 msgid "" "Most blade servers can support dual-socket multi-core CPUs. To avoid this " "CPU limit, select ``full width`` or ``full height`` blades. Be aware, " "however, that this also decreases server density. For example, high density " "blade servers such as HP BladeSystem or Dell PowerEdge M1000e support up to " "16 servers in only ten rack units. Using half-height blades is twice as " "dense as using full-height blades, which results in only eight servers per " "ten rack units." msgstr "" #: ../compute-focus-architecture.rst:48 msgid "" "1U rack-mounted servers that occupy only a single rack unit may offer " "greater server density than a blade server solution. It is possible to place " "forty 1U servers in a rack, providing space for the top of rack (ToR) " "switches, compared to 32 full width blade servers." msgstr "" #: ../compute-focus-architecture.rst:53 msgid "" "2U rack-mounted servers provide quad-socket, multi-core CPU support, but " "with a corresponding decrease in server density (half the density that 1U " "rack-mounted servers offer)." msgstr "" #: ../compute-focus-architecture.rst:57 msgid "" "Larger rack-mounted servers, such as 4U servers, often provide even greater " "CPU capacity, commonly supporting four or even eight CPU sockets. These " "servers have greater expandability, but such servers have much lower server " "density and are often more expensive." msgstr "" #: ../compute-focus-architecture.rst:62 msgid "" "``Sled servers`` are rack-mounted servers that support multiple independent " "servers in a single 2U or 3U enclosure. These deliver higher density as " "compared to typical 1U or 2U rack-mounted servers. For example, many sled " "servers offer four independent dual-socket nodes in 2U for a total of eight " "CPU sockets in 2U." msgstr "" #: ../compute-focus-architecture.rst:68 msgid "" "Consider these when choosing server hardware for a compute-focused OpenStack " "design architecture:" msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:71 ../generalpurpose-architecture.rst:98 #: ../storage-focus-architecture.rst:164 msgid "Instance density" msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:73 ../generalpurpose-architecture.rst:108 #: ../storage-focus-architecture.rst:171 msgid "Host density" msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:75 ../storage-focus-architecture.rst:177 msgid "Power and cooling density" msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:78 ../generalpurpose-architecture.rst:240 msgid "Selecting networking hardware" msgstr "" #: ../compute-focus-architecture.rst:80 msgid "" "Some of the key considerations for networking hardware selection include:" msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:83 ../generalpurpose-architecture.rst:259 #: ../storage-focus-architecture.rst:193 msgid "Port count" msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:85 ../generalpurpose-architecture.rst:269 #: ../storage-focus-architecture.rst:203 msgid "Port density" msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:87 ../generalpurpose-architecture.rst:273 #: ../storage-focus-architecture.rst:207 msgid "Port speed" msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:89 ../generalpurpose-architecture.rst:280 #: ../storage-focus-architecture.rst:219 msgid "Redundancy" msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:91 ../generalpurpose-architecture.rst:284 #: ../storage-focus-architecture.rst:225 msgid "Power requirements" msgstr "" #: ../compute-focus-architecture.rst:93 msgid "" "We recommend designing the network architecture using a scalable network " "model that makes it easy to add capacity and bandwidth. A good example of " "such a model is the leaf-spline model. In this type of network design, it is " "possible to easily add additional bandwidth as well as scale out to " "additional racks of gear. It is important to select network hardware that " "supports the required port count, port speed, and port density while also " "allowing for future growth as workload demands increase. It is also " "important to evaluate where in the network architecture it is valuable to " "provide redundancy." msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:104 #: ../generalpurpose-architecture.rst:335 #: ../storage-focus-architecture.rst:249 msgid "Operating system and hypervisor" msgstr "" #: ../compute-focus-architecture.rst:106 msgid "" "The selection of operating system (OS) and hypervisor has a significant " "impact on the end point design." msgstr "" #: ../compute-focus-architecture.rst:109 msgid "OS and hypervisor selection impact the following areas:" msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:113 #: ../generalpurpose-architecture.rst:361 #: ../storage-focus-architecture.rst:272 msgid "Supportability" msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:115 #: ../generalpurpose-architecture.rst:368 #: ../storage-focus-architecture.rst:278 msgid "Management tools" msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:117 #: ../generalpurpose-architecture.rst:374 #: ../storage-focus-architecture.rst:285 msgid "Scale and performance" msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-user-requirements.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# hybrid-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# legal-security-requirements.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:119 #: ../generalpurpose-architecture.rst:382 #: ../generalpurpose-technical-considerations.rst:546 #: ../generalpurpose-user-requirements.rst:98 ../hybrid-architecture.rst:90 #: ../legal-security-requirements.rst:37 ../storage-focus-architecture.rst:292 #: ../storage-focus-technical-considerations.rst:33 msgid "Security" msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:121 #: ../generalpurpose-architecture.rst:388 #: ../storage-focus-architecture.rst:299 msgid "Supported features" msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:123 #: ../generalpurpose-architecture.rst:396 #: ../generalpurpose-technical-considerations.rst:296 #: ../storage-focus-architecture.rst:307 msgid "Interoperability" msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# compute-focus-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# legal-security-requirements.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# multi-site-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:126 #: ../compute-focus-technical-considerations.rst:173 #: ../generalpurpose-architecture.rst:330 #: ../generalpurpose-architecture.rst:399 #: ../generalpurpose-technical-considerations.rst:341 #: ../legal-security-requirements.rst:222 #: ../multi-site-technical-considerations.rst:135 #: ../storage-focus-architecture.rst:241 ../storage-focus-architecture.rst:310 msgid "OpenStack components" msgstr "" #: ../compute-focus-architecture.rst:128 msgid "" "The selection of OpenStack components is important. There are certain " "components that are required, for example the compute and image services, " "but others, such as the Orchestration service, may not be present." msgstr "" #: ../compute-focus-architecture.rst:133 msgid "" "For a compute-focused OpenStack design architecture, the following " "components may be present:" msgstr "" #: ../compute-focus-architecture.rst:136 msgid "Identity (keystone)" msgstr "" #: ../compute-focus-architecture.rst:138 msgid "Dashboard (horizon)" msgstr "" #: ../compute-focus-architecture.rst:140 msgid "Compute (nova)" msgstr "" #: ../compute-focus-architecture.rst:142 msgid "Object Storage (swift)" msgstr "" #: ../compute-focus-architecture.rst:144 msgid "Image (glance)" msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# hybrid-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:146 #: ../generalpurpose-technical-considerations.rst:132 #: ../hybrid-technical-considerations.rst:127 msgid "Networking (neutron)" msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# hybrid-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:148 #: ../hybrid-technical-considerations.rst:135 msgid "Orchestration (heat)" msgstr "" #: ../compute-focus-architecture.rst:152 msgid "" "A compute-focused design is less likely to include OpenStack Block Storage. " "However, there may be some situations where the need for performance " "requires a block storage component to improve data I-O." msgstr "" #: ../compute-focus-architecture.rst:156 msgid "" "The exclusion of certain OpenStack components might also limit the " "functionality of other components. If a design includes the Orchestration " "service but excludes the Telemetry service, then the design cannot take " "advantage of Orchestration's auto scaling functionality as this relies on " "information from Telemetry." msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:163 #: ../generalpurpose-architecture.rst:415 #: ../storage-focus-architecture.rst:354 msgid "Networking software" msgstr "" #: ../compute-focus-architecture.rst:165 msgid "" "OpenStack Networking provides a wide variety of networking services for " "instances. There are many additional networking software packages that might " "be useful to manage the OpenStack components themselves. The `OpenStack High " "Availability Guide `_ describes some of " "these software packages in more detail." msgstr "" #: ../compute-focus-architecture.rst:171 msgid "" "For a compute-focused OpenStack cloud, the OpenStack infrastructure " "components must be highly available. If the design does not include hardware " "load balancing, you must add networking software packages, for example, " "HAProxy." msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:177 #: ../generalpurpose-architecture.rst:440 #: ../storage-focus-architecture.rst:367 msgid "Management software" msgstr "" #: ../compute-focus-architecture.rst:179 msgid "" "The selected supplemental software solution impacts and affects the overall " "OpenStack cloud design. This includes software for providing clustering, " "logging, monitoring and alerting." msgstr "" #: ../compute-focus-architecture.rst:183 msgid "" "The availability of design requirements is the main determiner for the " "inclusion of clustering software, such as Corosync or Pacemaker." msgstr "" #: ../compute-focus-architecture.rst:186 msgid "" "Operational considerations determine the requirements for logging, " "monitoring, and alerting. Each of these sub-categories include various " "options." msgstr "" #: ../compute-focus-architecture.rst:190 msgid "Some other potential design impacts include:" msgstr "" #: ../compute-focus-architecture.rst:193 msgid "" "Ensure that the selected logging, monitoring, or alerting tools support the " "proposed OS-hypervisor combination." msgstr "" #: ../compute-focus-architecture.rst:194 msgid "OS-hypervisor combination" msgstr "" #: ../compute-focus-architecture.rst:197 msgid "" "The logging, monitoring, and alerting software must support the network " "hardware selection." msgstr "" #: ../compute-focus-architecture.rst:198 msgid "Network hardware" msgstr "" # #-#-#-#-# compute-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-architecture.rst:201 #: ../generalpurpose-architecture.rst:472 #: ../storage-focus-architecture.rst:413 msgid "Database software" msgstr "" #: ../compute-focus-architecture.rst:203 msgid "" "A large majority of OpenStack components require access to back-end database " "services to store state and configuration information. Select an appropriate " "back-end database that satisfies the availability and fault tolerance " "requirements of the OpenStack services. OpenStack services support " "connecting to any database that the SQLAlchemy Python drivers support, " "however most common database deployments make use of MySQL or some variation " "of it. We recommend that you make the database that provides back-end " "services within a general-purpose cloud highly available. Some of the more " "common software solutions include Galera, MariaDB, and MySQL with multi-" "master replication." msgstr "" # #-#-#-#-# compute-focus-operational-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-operational-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# hybrid-operational-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# massively-scalable-operational-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# multi-site-operational-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# network-focus-operational-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-operational-considerations.rst:3 #: ../generalpurpose-operational-considerations.rst:3 #: ../hybrid-operational-considerations.rst:3 #: ../massively-scalable-operational-considerations.rst:2 #: ../multi-site-operational-considerations.rst:3 #: ../network-focus-operational-considerations.rst:2 msgid "Operational considerations" msgstr "" #: ../compute-focus-operational-considerations.rst:5 msgid "" "There are a number of operational considerations that affect the design of " "compute-focused OpenStack clouds, including:" msgstr "" #: ../compute-focus-operational-considerations.rst:8 msgid "Enforcing strict API availability requirements" msgstr "" #: ../compute-focus-operational-considerations.rst:10 msgid "Understanding and dealing with failure scenarios" msgstr "" #: ../compute-focus-operational-considerations.rst:12 msgid "Managing host maintenance schedules" msgstr "" #: ../compute-focus-operational-considerations.rst:14 msgid "" "Service-level agreements (SLAs) are contractual obligations that ensure the " "availability of a service. When designing an OpenStack cloud, factoring in " "promises of availability implies a certain level of redundancy and " "resiliency." msgstr "" # #-#-#-#-# compute-focus-operational-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# compute-focus-prescriptive-examples.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-operational-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-operational-considerations.rst:20 #: ../compute-focus-prescriptive-examples.rst:109 #: ../generalpurpose-operational-considerations.rst:47 #: ../storage-focus-architecture.rst:375 msgid "Monitoring" msgstr "" #: ../compute-focus-operational-considerations.rst:22 msgid "" "OpenStack clouds require appropriate monitoring platforms to catch and " "manage errors." msgstr "" #: ../compute-focus-operational-considerations.rst:27 msgid "" "We recommend leveraging existing monitoring systems to see if they are able " "to effectively monitor an OpenStack environment." msgstr "" #: ../compute-focus-operational-considerations.rst:30 msgid "Specific meters that are critically important to capture include:" msgstr "" # #-#-#-#-# compute-focus-operational-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-operational-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-operational-considerations.rst:32 #: ../generalpurpose-operational-considerations.rst:53 msgid "Image disk utilization" msgstr "" #: ../compute-focus-operational-considerations.rst:34 msgid "Response time to the Compute API" msgstr "" # #-#-#-#-# compute-focus-operational-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-operational-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# hybrid-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# network-focus-user-requirements.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-operational-considerations.rst:37 #: ../generalpurpose-operational-considerations.rst:76 #: ../hybrid-technical-considerations.rst:38 #: ../network-focus-user-requirements.rst:45 msgid "Capacity planning" msgstr "" #: ../compute-focus-operational-considerations.rst:39 msgid "" "Adding extra capacity to an OpenStack cloud is a horizontally scaling " "process." msgstr "" #: ../compute-focus-operational-considerations.rst:42 msgid "" "We recommend similar (or the same) CPUs when adding extra nodes to the " "environment. This reduces the chance of breaking live-migration features if " "they are present. Scaling out hypervisor hosts also has a direct effect on " "network and other data center resources. We recommend you factor in this " "increase when reaching rack capacity or when requiring extra network " "switches." msgstr "" #: ../compute-focus-operational-considerations.rst:49 msgid "" "Changing the internal components of a Compute host to account for increases " "in demand is a process known as vertical scaling. Swapping a CPU for one " "with more cores, or increasing the memory in a server, can help add extra " "capacity for running applications." msgstr "" #: ../compute-focus-operational-considerations.rst:54 msgid "" "Another option is to assess the average workloads and increase the number of " "instances that can run within the compute environment by adjusting the " "overcommit ratio." msgstr "" #: ../compute-focus-operational-considerations.rst:60 msgid "" "It is important to remember that changing the CPU overcommit ratio can have " "a detrimental effect and cause a potential increase in a noisy neighbor." msgstr "" #: ../compute-focus-operational-considerations.rst:64 msgid "" "The added risk of increasing the overcommit ratio is that more instances " "fail when a compute host fails. We do not recommend that you increase the " "CPU overcommit ratio in compute-focused OpenStack design architecture, as it " "can increase the potential for noisy neighbor issues." msgstr "" # #-#-#-#-# compute-focus-prescriptive-examples.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# hybrid-prescriptive-examples.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# multi-site-prescriptive-examples.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# network-focus-prescriptive-examples.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-prescriptive-examples.rst:3 #: ../hybrid-prescriptive-examples.rst:3 #: ../multi-site-prescriptive-examples.rst:3 #: ../network-focus-prescriptive-examples.rst:2 msgid "Prescriptive examples" msgstr "" #: ../compute-focus-prescriptive-examples.rst:5 msgid "" "The Conseil Européen pour la Recherche Nucléaire (CERN), also known as the " "European Organization for Nuclear Research, provides particle accelerators " "and other infrastructure for high-energy physics research." msgstr "" #: ../compute-focus-prescriptive-examples.rst:9 msgid "" "As of 2011 CERN operated these two compute centers in Europe with plans to " "add a third." msgstr "" #: ../compute-focus-prescriptive-examples.rst:13 msgid "Approximate capacity" msgstr "" #: ../compute-focus-prescriptive-examples.rst:13 msgid "Data center" msgstr "" #: ../compute-focus-prescriptive-examples.rst:15 msgid "3.5 Mega Watts" msgstr "" #: ../compute-focus-prescriptive-examples.rst:15 msgid "Geneva, Switzerland" msgstr "" #: ../compute-focus-prescriptive-examples.rst:17 msgid "91000 cores" msgstr "" #: ../compute-focus-prescriptive-examples.rst:19 msgid "120 PB HDD" msgstr "" #: ../compute-focus-prescriptive-examples.rst:21 msgid "100 PB Tape" msgstr "" #: ../compute-focus-prescriptive-examples.rst:23 msgid "310 TB Memory" msgstr "" #: ../compute-focus-prescriptive-examples.rst:25 msgid "2.5 Mega Watts" msgstr "" #: ../compute-focus-prescriptive-examples.rst:25 msgid "Budapest, Hungary" msgstr "" #: ../compute-focus-prescriptive-examples.rst:27 msgid "20000 cores" msgstr "" #: ../compute-focus-prescriptive-examples.rst:29 msgid "6 PB HDD" msgstr "" #: ../compute-focus-prescriptive-examples.rst:32 msgid "" "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 Scientific Linux and RDO. This effort aimed to " "simplify the management of the center's compute resources with a view to " "doubling compute capacity through the addition of a data center in 2013 " "while maintaining the same levels of compute staff." msgstr "" #: ../compute-focus-prescriptive-examples.rst:39 msgid "" "The CERN solution uses :term:`cells ` for segregation of compute " "resources and for transparently scaling between different data centers. This " "decision meant trading off support for security groups and live migration. " "In addition, they must manually replicate some details, like flavors, across " "cells. In spite of these drawbacks cells provide the required scale while " "exposing a single public API endpoint to users." msgstr "" #: ../compute-focus-prescriptive-examples.rst:46 msgid "" "CERN created a compute cell for each of the two original data centers and " "created a third when it added a new data center in 2013. Each cell contains " "three availability zones to further segregate compute resources and at least " "three RabbitMQ message brokers configured for clustering with mirrored " "queues for high availability." msgstr "" #: ../compute-focus-prescriptive-examples.rst:52 msgid "" "The API cell, which resides behind a HAProxy load balancer, is in the data " "center in Switzerland and directs API calls to compute cells using a " "customized variation of the cell scheduler. The customizations allow certain " "workloads to route to a specific data center or all data centers, with cell " "RAM availability determining cell selection in the latter case." msgstr "" #: ../compute-focus-prescriptive-examples.rst:61 msgid "" "There is also some customization of the filter scheduler that handles " "placement within the cells:" msgstr "" #: ../compute-focus-prescriptive-examples.rst:65 msgid "" "Provides special handling depending on the guest operating system in use " "(Linux-based or Windows-based)." msgstr "" #: ../compute-focus-prescriptive-examples.rst:66 msgid "ImagePropertiesFilter" msgstr "" #: ../compute-focus-prescriptive-examples.rst:69 msgid "" "Provides special handling depending on which project the instance is " "associated with." msgstr "" #: ../compute-focus-prescriptive-examples.rst:70 msgid "ProjectsToAggregateFilter" msgstr "" #: ../compute-focus-prescriptive-examples.rst:73 msgid "" "Allows the selection of multiple default availability zones, rather than a " "single default." msgstr "" #: ../compute-focus-prescriptive-examples.rst:74 msgid "default_schedule_zones" msgstr "" #: ../compute-focus-prescriptive-examples.rst:76 msgid "" "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." msgstr "" #: ../compute-focus-prescriptive-examples.rst:81 msgid "Network architecture" msgstr "" #: ../compute-focus-prescriptive-examples.rst:83 msgid "" "To integrate with existing networking infrastructure, CERN made " "customizations to legacy networking (nova-network). This was in the form of " "a driver to integrate with CERN's existing database for tracking MAC and IP " "address assignments." msgstr "" #: ../compute-focus-prescriptive-examples.rst:88 msgid "" "The driver facilitates selection of a MAC address and IP for new instances " "based on the compute node where the scheduler places the instance." msgstr "" #: ../compute-focus-prescriptive-examples.rst:92 msgid "" "The driver considers the compute node where the scheduler 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." msgstr "" #: ../compute-focus-prescriptive-examples.rst:98 msgid "Storage architecture" msgstr "" #: ../compute-focus-prescriptive-examples.rst:100 msgid "" "CERN deploys the OpenStack Image service in the API cell and configures it " "to expose version 1 (V1) of the API. This also requires the image registry. " "The storage back end in use is a 3 PB Ceph cluster." msgstr "" #: ../compute-focus-prescriptive-examples.rst:104 msgid "" "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." msgstr "" #: ../compute-focus-prescriptive-examples.rst:111 msgid "" "CERN does not require direct billing, but uses the Telemetry service to " "perform metering for the purposes of adjusting project quotas. CERN uses a " "sharded, replicated, MongoDB back-end. To spread API load, CERN deploys " "instances of the nova-api service within the child cells for Telemetry to " "query against. This also requires the configuration of supporting services " "such as keystone, glance-api, and glance-registry in the child cells." msgstr "" #: ../compute-focus-prescriptive-examples.rst:121 msgid "" "Additional monitoring tools in use include `Flume `__, `Elastic Search `__, `Kibana `__, and the CERN developed `Lemon " "`__ project." msgstr "" # #-#-#-#-# compute-focus-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# hybrid-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# massively-scalable-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# multi-site-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# network-focus-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-technical-considerations.rst:3 #: ../generalpurpose-technical-considerations.rst:3 #: ../hybrid-technical-considerations.rst:3 #: ../massively-scalable-technical-considerations.rst:2 #: ../multi-site-technical-considerations.rst:3 #: ../network-focus-technical-considerations.rst:2 #: ../storage-focus-technical-considerations.rst:2 msgid "Technical considerations" msgstr "" #: ../compute-focus-technical-considerations.rst:5 msgid "" "In a compute-focused OpenStack cloud, the type of instance workloads you " "provision heavily influences technical decision making." msgstr "" #: ../compute-focus-technical-considerations.rst:8 msgid "" "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 predicting the effort and expense of making " "a given process 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." msgstr "" #: ../compute-focus-technical-considerations.rst:16 msgid "There are two aspects of capacity planning to consider:" msgstr "" #: ../compute-focus-technical-considerations.rst:18 msgid "Planning the initial deployment footprint" msgstr "" #: ../compute-focus-technical-considerations.rst:20 msgid "" "Planning expansion of the environment to stay ahead of cloud user demands" msgstr "" #: ../compute-focus-technical-considerations.rst:22 msgid "" "Begin planning an initial OpenStack deployment footprint with estimations of " "expected uptake, and existing infrastructure workloads." msgstr "" #: ../compute-focus-technical-considerations.rst:25 msgid "" "The starting point is the core count of the cloud. By applying relevant " "ratios, the user can gather information about:" msgstr "" #: ../compute-focus-technical-considerations.rst:28 msgid "" "The number of expected concurrent instances: (overcommit fraction × cores) / " "virtual cores per instance" msgstr "" #: ../compute-focus-technical-considerations.rst:31 msgid "Required storage: flavor disk size × number of instances" msgstr "" #: ../compute-focus-technical-considerations.rst:33 msgid "" "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 default " "overcommit rate of 16:1, working out the math provides an equation of:" msgstr "" #: ../compute-focus-technical-considerations.rst:39 msgid "1600 = (16 × (number of physical cores)) / 2" msgstr "" #: ../compute-focus-technical-considerations.rst:41 msgid "Storage required = 50 GB × 1600" msgstr "" #: ../compute-focus-technical-considerations.rst:43 msgid "" "On the surface, the equations reveal the need for 200 physical cores and " "80 TB of storage for ``/var/lib/nova/instances/``. However, it is also " "important to look at patterns of usage to estimate the load that the API " "services, database servers, and queue servers are likely to encounter." msgstr "" #: ../compute-focus-technical-considerations.rst:48 msgid "" "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 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 OpenStack Dashboard instances tab " "refreshes the list of instances every 30 seconds, so leaving it open in a " "browser window can cause unexpected load." msgstr "" #: ../compute-focus-technical-considerations.rst:58 msgid "" "Consideration of these factors can help determine how many cloud controller " "cores you require. A server with 8 CPU cores and 8 GB of RAM server would be " "sufficient for a rack of compute nodes, given the above caveats." msgstr "" #: ../compute-focus-technical-considerations.rst:63 msgid "" "Key hardware specifications are also crucial to the performance of user " "instances. Be sure to consider budget and performance needs, including " "storage performance (spindles/core), memory availability (RAM/core), network " "bandwidth (Gbps/core), and overall CPU performance (CPU/core)." msgstr "" #: ../compute-focus-technical-considerations.rst:68 msgid "" "The cloud resource calculator is a useful tool in examining the impacts of " "different hardware and instance load outs. See: https://github.com/noslzzp/" "cloud-resource-calculator/blob/master/cloud-resource-calculator.ods" msgstr "" #: ../compute-focus-technical-considerations.rst:73 msgid "Expansion planning" msgstr "" #: ../compute-focus-technical-considerations.rst:75 msgid "" "A key challenge for planning the expansion of cloud compute services is the " "elastic nature of cloud infrastructure demands." msgstr "" #: ../compute-focus-technical-considerations.rst:78 msgid "" "Planning for expansion is a balancing act. Planning too conservatively can " "lead to unexpected oversubscription of the cloud and dissatisfied users. " "Planning for cloud expansion too aggressively can lead to unexpected " "underuse of the cloud and funds spent unnecessarily on operating " "infrastructure." msgstr "" #: ../compute-focus-technical-considerations.rst:84 msgid "" "The key is to carefully monitor the trends in cloud usage over time. The " "intent is to measure the consistency with which you deliver services, not " "the 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." msgstr "" #: ../compute-focus-technical-considerations.rst:91 msgid "CPU and RAM" msgstr "" #: ../compute-focus-technical-considerations.rst:93 msgid "" "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 performance of the instances. OpenStack Compute uses " "the following ratios by default:" msgstr "" #: ../compute-focus-technical-considerations.rst:98 msgid "CPU allocation ratio: 16:1" msgstr "" #: ../compute-focus-technical-considerations.rst:100 msgid "RAM allocation ratio: 1.5:1" msgstr "" #: ../compute-focus-technical-considerations.rst:102 msgid "" "The default CPU allocation ratio of 16:1 means that the scheduler allocates " "up to 16 virtual cores per physical core. For example, if a physical node " "has 12 cores, the scheduler sees 192 available virtual cores. With typical " "flavor definitions of 4 virtual cores per instance, this ratio would provide " "48 instances on a physical node." msgstr "" #: ../compute-focus-technical-considerations.rst:108 msgid "" "Similarly, the default RAM allocation ratio of 1.5:1 means that the " "scheduler allocates instances to a physical node as 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." msgstr "" #: ../compute-focus-technical-considerations.rst:113 msgid "" "You must select the appropriate CPU and RAM allocation ratio based on " "particular use cases." msgstr "" #: ../compute-focus-technical-considerations.rst:117 msgid "Additional hardware" msgstr "" #: ../compute-focus-technical-considerations.rst:119 msgid "" "Certain use cases may benefit from exposure to additional devices on the " "compute node. Examples might include:" msgstr "" #: ../compute-focus-technical-considerations.rst:122 msgid "" "High performance computing jobs that benefit from the availability of " "graphics processing units (GPUs) for general-purpose computing." msgstr "" #: ../compute-focus-technical-considerations.rst:125 msgid "" "Cryptographic routines that benefit from the availability of hardware random " "number generators to avoid entropy starvation." msgstr "" #: ../compute-focus-technical-considerations.rst:128 msgid "" "Database management systems that benefit from the availability of SSDs for " "ephemeral storage to maximize read/write time." msgstr "" #: ../compute-focus-technical-considerations.rst:131 msgid "" "Host aggregates group hosts that share similar 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 whether all compute nodes, or just a subset targeted by flavors, " "need the additional customization to support the desired workloads." msgstr "" # #-#-#-#-# compute-focus-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# hybrid-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# multi-site-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus-technical-considerations.rst:139 #: ../hybrid-technical-considerations.rst:70 #: ../multi-site-technical-considerations.rst:77 msgid "Utilization" msgstr "" #: ../compute-focus-technical-considerations.rst:141 msgid "" "Infrastructure-as-a-Service offerings, including OpenStack, use flavors to " "provide standardized views of virtual machine resource requirements that " "simplify the problem of scheduling instances while making the best use of " "the available physical resources." msgstr "" #: ../compute-focus-technical-considerations.rst:146 msgid "" "In order to facilitate packing of virtual machines onto physical hosts, the " "default selection of flavors provides a second largest flavor that is half " "the size of the largest flavor in every dimension. It has half the vCPUs, " "half the vRAM, and half the ephemeral disk space. The next largest flavor is " "half that size again. The following figure provides a visual representation " "of this concept for a general purpose computing design:" msgstr "" #: ../compute-focus-technical-considerations.rst:156 msgid "The following figure displays a CPU-optimized, packed server:" msgstr "" #: ../compute-focus-technical-considerations.rst:160 msgid "" "These default flavors are well suited to typical configurations of commodity " "server hardware. To maximize utilization, however, it may be necessary to " "customize the flavors or create new ones in order to better align instance " "sizes to the available hardware." msgstr "" #: ../compute-focus-technical-considerations.rst:165 msgid "" "Workload characteristics may also influence hardware choices and flavor " "configuration, particularly where they present different ratios of CPU " "versus RAM versus HDD requirements." msgstr "" #: ../compute-focus-technical-considerations.rst:169 msgid "" "For more information on Flavors see `OpenStack Operations Guide: Flavors " "`_." msgstr "" #: ../compute-focus-technical-considerations.rst:175 msgid "" "Due to the nature of the workloads in this scenario, a number of components " "are highly beneficial for a Compute-focused cloud. This includes the typical " "OpenStack components:" msgstr "" #: ../compute-focus-technical-considerations.rst:179 msgid ":term:`Compute service` (nova)" msgstr "" #: ../compute-focus-technical-considerations.rst:181 msgid ":term:`Image service` (glance)" msgstr "" #: ../compute-focus-technical-considerations.rst:183 msgid ":term:`Identity service` (keystone)" msgstr "" #: ../compute-focus-technical-considerations.rst:185 msgid "Also consider several specialized components:" msgstr "" #: ../compute-focus-technical-considerations.rst:188 msgid "" "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 service to handle all these actions." msgstr "" #: ../compute-focus-technical-considerations.rst:192 msgid ":term:`Orchestration service` (heat)" msgstr "" #: ../compute-focus-technical-considerations.rst:195 msgid "" "Telemetry and the alarms it generates support autoscaling of instances using " "Orchestration. Users that are not using the Orchestration service do not " "need to deploy the Telemetry service and may choose to use external " "solutions to fulfill their metering and monitoring requirements." msgstr "" #: ../compute-focus-technical-considerations.rst:199 msgid ":term:`Telemetry service` (ceilometer)" msgstr "" #: ../compute-focus-technical-considerations.rst:202 msgid "" "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." msgstr "" #: ../compute-focus-technical-considerations.rst:207 msgid ":term:`Block Storage service` (cinder)" msgstr "" #: ../compute-focus-technical-considerations.rst:210 msgid "" "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." msgstr "" #: ../compute-focus-technical-considerations.rst:213 msgid ":term:`Networking service` (neutron)" msgstr "" #: ../compute-focus.rst:3 msgid "Compute focused" msgstr "" #: ../compute-focus.rst:13 msgid "" "Compute-focused clouds are a specialized subset of the general purpose " "OpenStack cloud architecture. A compute-focused cloud specifically supports " "compute intensive workloads." msgstr "" #: ../compute-focus.rst:19 msgid "" "Compute intensive workloads may be CPU intensive, RAM intensive, or both; " "they are not typically storage or network intensive." msgstr "" #: ../compute-focus.rst:22 msgid "Compute-focused workloads may include the following use cases:" msgstr "" # #-#-#-#-# compute-focus.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# network-focus.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../compute-focus.rst:24 ../network-focus.rst:100 msgid "High performance computing (HPC)" msgstr "" #: ../compute-focus.rst:25 msgid "Big data analytics using Hadoop or other distributed data stores" msgstr "" #: ../compute-focus.rst:26 msgid "Continuous integration/continuous deployment (CI/CD)" msgstr "" #: ../compute-focus.rst:27 msgid "Platform-as-a-Service (PaaS)" msgstr "" #: ../compute-focus.rst:28 msgid "Signal processing for network function virtualization (NFV)" msgstr "" #: ../compute-focus.rst:32 msgid "" "A compute-focused OpenStack cloud does not typically use raw block storage " "services as it does not host applications that require persistent block " "storage." msgstr "" #: ../generalpurpose-architecture.rst:5 msgid "Hardware selection involves three key areas:" msgstr "" #: ../generalpurpose-architecture.rst:13 msgid "" "Hardware for a general purpose OpenStack cloud should reflect a cloud with " "no pre-defined usage model, designed to run a wide variety of applications " "with varying resource usage requirements. These applications include any of " "the following:" msgstr "" #: ../generalpurpose-architecture.rst:18 msgid "RAM-intensive" msgstr "" #: ../generalpurpose-architecture.rst:20 msgid "CPU-intensive" msgstr "" #: ../generalpurpose-architecture.rst:22 msgid "Storage-intensive" msgstr "" #: ../generalpurpose-architecture.rst:24 msgid "" "Certain hardware form factors may better suit a general purpose OpenStack " "cloud due to the requirement for equal (or nearly equal) balance of " "resources. Server hardware must provide the following:" msgstr "" #: ../generalpurpose-architecture.rst:28 msgid "Equal (or nearly equal) balance of compute capacity (RAM and CPU)" msgstr "" #: ../generalpurpose-architecture.rst:30 msgid "Network capacity (number and speed of links)" msgstr "" #: ../generalpurpose-architecture.rst:32 msgid "" "Storage capacity (gigabytes or terabytes as well as Input/Output Operations " "Per Second (:term:`IOPS`)" msgstr "" #: ../generalpurpose-architecture.rst:35 msgid "Evaluate server hardware around four conflicting dimensions:" msgstr "" # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../generalpurpose-architecture.rst:38 ../storage-focus-architecture.rst:83 msgid "" "A measure of how many servers can fit into a given measure of physical " "space, such as a rack unit [U]." msgstr "" #: ../generalpurpose-architecture.rst:42 msgid "" "The number of CPU cores, amount of RAM, or amount of deliverable storage." msgstr "" #: ../generalpurpose-architecture.rst:46 msgid "Limit of additional resources you can add to a server." msgstr "" #: ../generalpurpose-architecture.rst:49 msgid "" "The relative purchase price of the hardware weighted against the level of " "design effort needed to build the system." msgstr "" #: ../generalpurpose-architecture.rst:52 msgid "" "Increasing server density means sacrificing resource capacity or " "expandability, however, increasing resource capacity and expandability " "increases cost and decreases server density. As a result, determining the " "best server hardware for a general purpose OpenStack architecture means " "understanding how choice of form factor will impact the rest of the design. " "The following list outlines the form factors to choose from:" msgstr "" #: ../generalpurpose-architecture.rst:59 msgid "" "Blade servers typically support dual-socket multi-core CPUs. Blades also " "offer outstanding density." msgstr "" #: ../generalpurpose-architecture.rst:62 msgid "" "1U rack-mounted servers occupy only a single rack unit. Their benefits " "include high density, support for dual-socket multi-core CPUs, and support " "for reasonable RAM amounts. This form factor offers limited storage " "capacity, limited network capacity, and limited expandability." msgstr "" #: ../generalpurpose-architecture.rst:68 msgid "" "2U rack-mounted servers offer the expanded storage and networking capacity " "that 1U servers tend to lack, but with a corresponding decrease in server " "density (half the density offered by 1U rack-mounted servers)." msgstr "" #: ../generalpurpose-architecture.rst:73 msgid "" "Larger rack-mounted servers, such as 4U servers, will tend to offer even " "greater CPU capacity, often supporting four or even eight CPU sockets. These " "servers often have much greater expandability so will provide the best " "option for upgradability. This means, however, that the servers have a much " "lower server density and a much greater hardware cost." msgstr "" #: ../generalpurpose-architecture.rst:80 msgid "" "*Sled servers* are rack-mounted servers that support multiple independent " "servers in a single 2U or 3U enclosure. This form factor offers increased " "density over typical 1U-2U rack-mounted servers but tends to suffer from " "limitations in the amount of storage or network capacity each individual " "server supports." msgstr "" #: ../generalpurpose-architecture.rst:86 msgid "" "The best form factor for server hardware supporting a general purpose " "OpenStack cloud is driven by outside business and cost factors. No single " "reference architecture applies to all implementations; the decision must " "flow from user requirements, technical considerations, and operational " "considerations. Here are some of the key factors that influence the " "selection of server hardware:" msgstr "" #: ../generalpurpose-architecture.rst:94 msgid "" "Sizing is an important consideration for a general purpose OpenStack cloud. " "The expected or anticipated number of instances that each hypervisor can " "host is a common meter used in sizing the deployment. The selected server " "hardware needs to support the expected or anticipated instance density." msgstr "" #: ../generalpurpose-architecture.rst:101 msgid "" "Physical data centers have limited physical space, power, and cooling. The " "number of hosts (or hypervisors) that can be fitted into a given metric " "(rack, rack unit, or floor tile) is another important method of sizing. " "Floor weight is an often overlooked consideration. The data center floor " "must be able to support the weight of the proposed number of hosts within a " "rack or set of racks. These factors need to be applied as part of the host " "density calculation and server hardware selection." msgstr "" #: ../generalpurpose-architecture.rst:111 msgid "" "Data centers have a specified amount of power fed to a given rack or set of " "racks. Older data centers may have a power density as power as low as 20 " "AMPs per rack, while more recent data centers can be architected to support " "power densities as high as 120 AMP per rack. The selected server hardware " "must take power density into account." msgstr "" #: ../generalpurpose-architecture.rst:115 msgid "Power density" msgstr "" #: ../generalpurpose-architecture.rst:118 msgid "" "The selected server hardware must have the appropriate number of network " "connections, as well as the right type of network connections, in order to " "support the proposed architecture. Ensure that, at a minimum, there are at " "least two diverse network connections coming into each rack." msgstr "" #: ../generalpurpose-architecture.rst:122 msgid "Network connectivity" msgstr "" #: ../generalpurpose-architecture.rst:124 msgid "" "The selection of form factors or architectures affects the selection of " "server hardware. Ensure that the selected server hardware is configured to " "support enough storage capacity (or storage expandability) to match the " "requirements of selected scale-out storage solution. Similarly, the network " "architecture impacts the server hardware selection and vice versa." msgstr "" #: ../generalpurpose-architecture.rst:132 msgid "Selecting storage hardware" msgstr "" #: ../generalpurpose-architecture.rst:134 msgid "" "Determine storage hardware architecture by selecting specific storage " "architecture. Determine the selection of storage architecture by evaluating " "possible solutions against the critical factors, the user requirements, " "technical considerations, and operational considerations. Incorporate the " "following facts into your storage architecture:" msgstr "" #: ../generalpurpose-architecture.rst:141 msgid "" "Storage can be a significant portion of the overall system cost. For an " "organization that is concerned with vendor support, a commercial storage " "solution is advisable, although it comes with a higher price tag. If initial " "capital expenditure requires minimization, designing a system based on " "commodity hardware would apply. The trade-off is potentially higher support " "costs and a greater risk of incompatibility and interoperability issues." msgstr "" #: ../generalpurpose-architecture.rst:150 msgid "" "Scalability, along with expandability, is a major consideration in a general " "purpose OpenStack cloud. It might be difficult to predict the final intended " "size of the implementation as there are no established usage patterns for a " "general purpose cloud. It might become necessary to expand the initial " "deployment in order to accommodate growth and user demand." msgstr "" # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# hybrid-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../generalpurpose-architecture.rst:155 #: ../generalpurpose-architecture.rst:307 ../hybrid-architecture.rst:91 #: ../storage-focus-architecture.rst:35 msgid "Scalability" msgstr "" #: ../generalpurpose-architecture.rst:158 msgid "" "Expandability is a major architecture factor for storage solutions with " "general purpose OpenStack cloud. A storage solution that expands to 50 PB is " "considered more expandable than a solution that only scales to 10 PB. This " "meter is related to scalability, which is the measure of a solution's " "performance as it expands." msgstr "" #: ../generalpurpose-architecture.rst:164 msgid "" "Using a scale-out storage solution with direct-attached storage (DAS) in the " "servers is well suited for a general purpose OpenStack cloud. Cloud services " "requirements determine your choice of scale-out solution. You need to " "determine if a single, highly expandable and highly vertical, scalable, " "centralized storage array is suitable for your design. After determining an " "approach, select the storage hardware based on this criteria." msgstr "" #: ../generalpurpose-architecture.rst:172 msgid "" "This list expands upon the potential impacts for including a particular " "storage architecture (and corresponding storage hardware) into the design " "for a general purpose OpenStack cloud:" msgstr "" #: ../generalpurpose-architecture.rst:177 msgid "" "Ensure that, if storage protocols other than Ethernet are part of the " "storage solution, the appropriate hardware has been selected. If a " "centralized storage array is selected, ensure that the hypervisor will be " "able to connect to that storage array for image storage." msgstr "" # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# introduction-methodology.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../generalpurpose-architecture.rst:180 #: ../generalpurpose-architecture.rst:301 ../introduction-methodology.rst:87 #: ../storage-focus-architecture.rst:63 msgid "Connectivity" msgstr "" #: ../generalpurpose-architecture.rst:183 msgid "" "How the particular storage architecture will be used is critical for " "determining the architecture. Some of the configurations that will influence " "the architecture include whether it will be used by the hypervisors for " "ephemeral instance storage or if OpenStack Object Storage will use it for " "object storage." msgstr "" #: ../generalpurpose-architecture.rst:187 msgid "Usage" msgstr "" #: ../generalpurpose-architecture.rst:190 msgid "" "Where instances and images will be stored will influence the architecture." msgstr "" #: ../generalpurpose-architecture.rst:191 msgid "Instance and image locations" msgstr "" #: ../generalpurpose-architecture.rst:194 msgid "" "If the solution is a scale-out storage architecture that includes DAS, it " "will affect the server hardware selection. This could ripple into the " "decisions that affect host density, instance density, power density, OS-" "hypervisor, management tools and others." msgstr "" # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../generalpurpose-architecture.rst:197 ../storage-focus-architecture.rst:75 msgid "Server hardware" msgstr "" #: ../generalpurpose-architecture.rst:199 msgid "" "General purpose OpenStack cloud has multiple options. The key factors that " "will have an influence on selection of storage hardware for a general " "purpose OpenStack cloud are as follows:" msgstr "" #: ../generalpurpose-architecture.rst:204 msgid "" "Hardware resources selected for the resource nodes should be capable of " "supporting enough storage for the cloud services. Defining the initial " "requirements and ensuring the design can support adding capacity is " "important. Hardware nodes selected for object storage should be capable of " "support a large number of inexpensive disks with no reliance on RAID " "controller cards. Hardware nodes selected for block storage should be " "capable of supporting high speed storage solutions and RAID controller cards " "to provide performance and redundancy to storage at a hardware level. " "Selecting hardware RAID controllers that automatically repair damaged arrays " "will assist with the replacement and repair of degraded or deleted storage " "devices." msgstr "" #: ../generalpurpose-architecture.rst:215 msgid "Capacity" msgstr "" #: ../generalpurpose-architecture.rst:218 msgid "" "Disks selected for object storage services do not need to be fast performing " "disks. We recommend that object storage nodes take advantage of the best " "cost per terabyte available for storage. Contrastingly, disks chosen for " "block storage services should take advantage of performance boosting " "features that may entail the use of SSDs or flash storage to provide high " "performance block storage pools. Storage performance of ephemeral disks used " "for instances should also be taken into consideration." msgstr "" # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-user-requirements.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# hybrid-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# multi-site-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# network-focus-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../generalpurpose-architecture.rst:225 #: ../generalpurpose-user-requirements.rst:56 #: ../hybrid-technical-considerations.rst:92 #: ../multi-site-technical-considerations.rst:110 #: ../network-focus-technical-considerations.rst:324 #: ../storage-focus-architecture.rst:8 ../storage-focus-architecture.rst:27 msgid "Performance" msgstr "" #: ../generalpurpose-architecture.rst:228 msgid "" "Object storage resource nodes have no requirements for hardware fault " "tolerance or RAID controllers. It is not necessary to plan for fault " "tolerance within the object storage hardware because the object storage " "service provides replication between zones as a feature of the service. " "Block storage nodes, compute nodes, and cloud controllers should all have " "fault tolerance built in at the hardware level by making use of hardware " "RAID controllers and varying levels of RAID configuration. The level of RAID " "chosen should be consistent with the performance and availability " "requirements of the cloud." msgstr "" #: ../generalpurpose-architecture.rst:237 msgid "Fault tolerance" msgstr "" #: ../generalpurpose-architecture.rst:242 msgid "" "Selecting network architecture determines which network hardware will be " "used. Networking software is determined by the selected networking hardware." msgstr "" #: ../generalpurpose-architecture.rst:246 msgid "" "There are more subtle design impacts that need to be considered. The " "selection of certain networking hardware (and the networking software) " "affects the management tools that can be used. There are exceptions to this; " "the rise of *open* networking software that supports a range of networking " "hardware means that there are instances where the relationship between " "networking hardware and networking software are not as tightly defined." msgstr "" #: ../generalpurpose-architecture.rst:254 msgid "" "Some of the key considerations that should be included in the selection of " "networking hardware include:" msgstr "" #: ../generalpurpose-architecture.rst:258 msgid "" "The design will require networking hardware that has the requisite port " "count." msgstr "" #: ../generalpurpose-architecture.rst:262 msgid "" "The network design will be affected by the physical space that is required " "to provide the requisite port count. A higher port density is preferred, as " "it leaves more rack space for compute or storage components that may be " "required by the design. This can also lead into concerns about fault domains " "and power density that should be considered. Higher density switches are " "more expensive and should also be considered, as it is important not to over " "design the network if it is not required." msgstr "" # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../generalpurpose-architecture.rst:272 #: ../storage-focus-architecture.rst:206 msgid "" "The networking hardware must support the proposed network speed, for " "example: 1 GbE, 10 GbE, or 40 GbE (or even 100 GbE)." msgstr "" #: ../generalpurpose-architecture.rst:276 msgid "" "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 supplies or paired " "switches. If this is a requirement, the hardware will need to support this " "configuration." msgstr "" #: ../generalpurpose-architecture.rst:283 msgid "" "Ensure that the physical data center provides the necessary power for the " "selected network hardware." msgstr "" #: ../generalpurpose-architecture.rst:288 msgid "" "This may be an issue for spine switches in a leaf and spine fabric, or end " "of row (EoR) switches." msgstr "" #: ../generalpurpose-architecture.rst:291 msgid "" "There is no single best practice architecture for the networking hardware " "supporting a general purpose OpenStack cloud that will apply to all " "implementations. Some of the key factors that will have a strong influence " "on selection of networking hardware include:" msgstr "" #: ../generalpurpose-architecture.rst:297 msgid "" "All nodes within an OpenStack cloud require network connectivity. In some " "cases, nodes require access to more than one network segment. The design " "must encompass sufficient network capacity and bandwidth to ensure that all " "communications within the cloud, both north-south and east-west traffic have " "sufficient resources available." msgstr "" #: ../generalpurpose-architecture.rst:304 msgid "" "The network design should encompass a physical and logical network design " "that can be easily expanded upon. Network hardware should offer the " "appropriate types of interfaces and speeds that are required by the hardware " "nodes." msgstr "" #: ../generalpurpose-architecture.rst:310 msgid "" "To ensure that access to nodes within the cloud is not interrupted, we " "recommend that the network architecture identify any single points of " "failure and provide some level of redundancy or fault tolerance. With regard " "to the network infrastructure itself, this often involves use of networking " "protocols such as LACP, VRRP or others to achieve a highly available network " "connection. In addition, it is important to consider the networking " "implications on API availability. In order to ensure that the APIs, and " "potentially other services in the cloud are highly available, we recommend " "you design a load balancing solution within the network architecture to " "accommodate for these requirements." msgstr "" #: ../generalpurpose-architecture.rst:320 msgid "Availability" msgstr "" # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../generalpurpose-architecture.rst:323 #: ../generalpurpose-technical-considerations.rst:239 #: ../storage-focus-architecture.rst:234 msgid "Software selection" msgstr "" #: ../generalpurpose-architecture.rst:325 msgid "" "Software selection for a general purpose OpenStack architecture design needs " "to include these three areas:" msgstr "" # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../generalpurpose-architecture.rst:328 #: ../storage-focus-architecture.rst:239 msgid "Operating system (OS) and hypervisor" msgstr "" # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../generalpurpose-architecture.rst:332 #: ../generalpurpose-technical-considerations.rst:364 #: ../storage-focus-architecture.rst:243 msgid "Supplemental software" msgstr "" #: ../generalpurpose-architecture.rst:337 msgid "" "The operating system (OS) and hypervisor have a significant impact on the " "overall design. Selecting a particular operating system and hypervisor can " "directly affect server hardware selection. Make sure the storage hardware " "and topology support the selected operating system and hypervisor " "combination. Also ensure the networking hardware selection and topology will " "work with the chosen operating system and hypervisor combination." msgstr "" #: ../generalpurpose-architecture.rst:345 msgid "" "Some areas that could be impacted by the selection of OS and hypervisor " "include:" msgstr "" #: ../generalpurpose-architecture.rst:349 msgid "" "Selecting a commercially supported hypervisor, such as Microsoft Hyper-V, " "will result in a different cost model rather than community-supported open " "source hypervisors including :term:`KVM`, Kinstance " "or :term:`Xen`. When comparing open source OS solutions, choosing Ubuntu " "over Red Hat (or vice versa) will have an impact on cost due to support " "contracts." msgstr "" #: ../generalpurpose-architecture.rst:358 msgid "" "Depending on the selected hypervisor, staff should have the appropriate " "training and knowledge to support the selected OS and hypervisor " "combination. If they do not, training will need to be provided which could " "have a cost impact on the design." msgstr "" #: ../generalpurpose-architecture.rst:364 msgid "" "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 be very different " "impacts to the rest of the design as a result of the selection of one " "combination versus the other." msgstr "" #: ../generalpurpose-architecture.rst:371 msgid "" "Ensure that selected OS and hypervisor combinations meet the appropriate " "scale and performance requirements. The chosen architecture will need to " "meet the targeted instance-host ratios with the selected OS-hypervisor " "combinations." msgstr "" #: ../generalpurpose-architecture.rst:377 msgid "" "Ensure that the design can accommodate regular periodic installations of " "application security patches while maintaining required workloads. The " "frequency of security patches for the proposed OS-hypervisor combination " "will have an impact on performance and the patch installation process could " "affect maintenance windows." msgstr "" #: ../generalpurpose-architecture.rst:385 msgid "" "Determine which features of OpenStack are required. This will often " "determine the selection of the OS-hypervisor combination. Some features are " "only available with specific operating systems or hypervisors." msgstr "" #: ../generalpurpose-architecture.rst:391 msgid "" "You will need to consider how the OS and hypervisor combination interactions " "with other operating systems and hypervisors, including other software " "solutions. Operational troubleshooting tools for one OS-hypervisor " "combination may differ from the tools used for another OS-hypervisor " "combination and, as a result, the design will need to address if the two " "sets of tools need to interoperate." msgstr "" #: ../generalpurpose-architecture.rst:401 msgid "" "Selecting which OpenStack components are included in the overall design is " "important. Some OpenStack components, like compute and Image service, are " "required in every architecture. Other components, like Orchestration, are " "not always required." msgstr "" #: ../generalpurpose-architecture.rst:406 msgid "" "Excluding certain OpenStack components can limit or constrain the " "functionality of other components. For example, if the architecture includes " "Orchestration but excludes Telemetry, then the design will not be able to " "take advantage of Orchestrations' auto scaling functionality. It is " "important to research the component interdependencies in conjunction with " "the technical requirements before deciding on the final architecture." msgstr "" #: ../generalpurpose-architecture.rst:417 msgid "" "OpenStack Networking (neutron) provides a wide variety of networking " "services for instances. There are many additional networking software " "packages that can be useful when managing OpenStack components. Some " "examples include:" msgstr "" #: ../generalpurpose-architecture.rst:422 msgid "Software to provide load balancing" msgstr "" #: ../generalpurpose-architecture.rst:424 msgid "Network redundancy protocols" msgstr "" #: ../generalpurpose-architecture.rst:426 msgid "Routing daemons" msgstr "" #: ../generalpurpose-architecture.rst:428 msgid "" "Some of these software packages are described in more detail in the " "OpenStack High Availability Guide (refer to the `OpenStack network nodes " "chapter `__ of the " "OpenStack High Availability Guide)." msgstr "" #: ../generalpurpose-architecture.rst:434 msgid "" "For a general purpose OpenStack cloud, the OpenStack infrastructure " "components need to be highly available. If the design does not include " "hardware load balancing, networking software packages like HAProxy will need " "to be included." msgstr "" #: ../generalpurpose-architecture.rst:442 msgid "" "Selected supplemental software solution impacts and affects the overall " "OpenStack cloud design. This includes software for providing clustering, " "logging, monitoring and alerting." msgstr "" #: ../generalpurpose-architecture.rst:446 msgid "" "Inclusion of clustering software, such as Corosync or Pacemaker, is " "determined primarily by the availability requirements. The impact of " "including (or not including) these software packages is primarily 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 and configuration of Corosync and Pacemaker, " "should these packages need to be included in the design." msgstr "" #: ../generalpurpose-architecture.rst:456 msgid "" "Requirements for logging, monitoring, and alerting are determined by " "operational considerations. Each of these sub-categories includes a number " "of various options." msgstr "" #: ../generalpurpose-architecture.rst:460 msgid "" "If these software packages are required, the design must account for the " "additional resource consumption (CPU, RAM, storage, and network bandwidth). " "Some other potential design impacts include:" msgstr "" #: ../generalpurpose-architecture.rst:464 msgid "" "OS-hypervisor combination: Ensure that the selected logging, monitoring, or " "alerting tools support the proposed OS-hypervisor combination." msgstr "" # #-#-#-#-# generalpurpose-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# storage-focus-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../generalpurpose-architecture.rst:468 #: ../storage-focus-architecture.rst:409 msgid "" "Network hardware: The network hardware selection needs to be supported by " "the logging, monitoring, and alerting software." msgstr "" #: ../generalpurpose-architecture.rst:474 msgid "" "OpenStack components often require access to back-end database services to " "store state and configuration information. Selecting an appropriate back-end " "database that satisfies the availability and fault tolerance requirements of " "the OpenStack services is required. OpenStack services supports connecting " "to a database that is supported by the SQLAlchemy python drivers, however, " "most common database deployments make use of MySQL or variations of it. We " "recommend that the database, which provides back-end service within a " "general purpose cloud, be made highly available when using an available " "technology which can accomplish that goal." msgstr "" #: ../generalpurpose-operational-considerations.rst:5 msgid "" "In the planning and design phases of the build out, it is important to " "include the operation's function. Operational factors affect the design " "choices for a general purpose cloud, and operations staff are often tasked " "with the maintenance of cloud environments for larger installations." msgstr "" #: ../generalpurpose-operational-considerations.rst:11 msgid "" "Expectations set by the Service Level Agreements (SLAs) directly affect " "knowing when and where you should implement redundancy and high " "availability. SLAs are contractual obligations that provide assurances for " "service availability. They define the levels of availability that drive the " "technical design, often with penalties for not meeting contractual " "obligations." msgstr "" #: ../generalpurpose-operational-considerations.rst:18 msgid "SLA terms that affect design include:" msgstr "" #: ../generalpurpose-operational-considerations.rst:20 msgid "" "API availability guarantees implying multiple infrastructure services and " "highly available load balancers." msgstr "" #: ../generalpurpose-operational-considerations.rst:23 msgid "" "Network uptime guarantees affecting switch design, which might require " "redundant switching and power." msgstr "" #: ../generalpurpose-operational-considerations.rst:26 msgid "" "Factor in networking security policy requirements in to your deployments." msgstr "" #: ../generalpurpose-operational-considerations.rst:30 msgid "Support and maintainability" msgstr "" #: ../generalpurpose-operational-considerations.rst:32 msgid "" "To be able to support and maintain an installation, OpenStack cloud " "management requires operations staff to understand and comprehend design " "architecture content. The operations and engineering staff skill level, and " "level of separation, are dependent on size and purpose of the installation. " "Large cloud service providers, or telecom providers, are more likely to be " "managed by specially trained, dedicated operations organizations. Smaller " "implementations are more likely to rely on support staff that need to take " "on combined engineering, design and operations functions." msgstr "" #: ../generalpurpose-operational-considerations.rst:42 msgid "" "Maintaining OpenStack installations requires a variety of technical skills. " "You may want to consider using a third-party management company with special " "expertise in managing OpenStack deployment." msgstr "" #: ../generalpurpose-operational-considerations.rst:49 msgid "" "OpenStack clouds require appropriate monitoring platforms to ensure errors " "are caught and managed appropriately. Specific meters that are critically " "important to monitor include:" msgstr "" #: ../generalpurpose-operational-considerations.rst:55 msgid "Response time to the :term:`Compute API`" msgstr "" #: ../generalpurpose-operational-considerations.rst:57 msgid "" "Leveraging existing monitoring systems is an effective check to ensure " "OpenStack environments can be monitored." msgstr "" #: ../generalpurpose-operational-considerations.rst:61 msgid "Downtime" msgstr "" #: ../generalpurpose-operational-considerations.rst:63 msgid "" "To effectively run cloud installations, initial downtime planning includes " "creating processes and architectures that support the following:" msgstr "" #: ../generalpurpose-operational-considerations.rst:67 msgid "Planned (maintenance)" msgstr "" #: ../generalpurpose-operational-considerations.rst:69 msgid "Unplanned (system faults)" msgstr "" #: ../generalpurpose-operational-considerations.rst:71 msgid "" "Resiliency of overall system and individual components are going to be " "dictated by the requirements of the SLA, meaning designing for :term:`high " "availability (HA)` can have cost ramifications." msgstr "" #: ../generalpurpose-operational-considerations.rst:78 msgid "Capacity constraints for a general purpose cloud environment include:" msgstr "" #: ../generalpurpose-operational-considerations.rst:80 msgid "Compute limits" msgstr "" #: ../generalpurpose-operational-considerations.rst:82 msgid "Storage limits" msgstr "" #: ../generalpurpose-operational-considerations.rst:84 msgid "" "A relationship exists between the size of the compute environment and the " "supporting OpenStack infrastructure controller nodes requiring support." msgstr "" #: ../generalpurpose-operational-considerations.rst:88 msgid "" "Increasing the size of the supporting compute environment increases the " "network traffic and messages, adding load to the controller or networking " "nodes. Effective monitoring of the environment will help with capacity " "decisions on scaling." msgstr "" #: ../generalpurpose-operational-considerations.rst:93 msgid "" "Compute nodes automatically attach to OpenStack clouds, resulting in a " "horizontally scaling process when adding extra compute capacity to an " "OpenStack cloud. Additional processes are required to place nodes into " "appropriate availability zones and host aggregates. When adding additional " "compute nodes to environments, ensure identical or functional compatible " "CPUs are used, otherwise live migration features will break. It is necessary " "to add rack capacity or network switches as scaling out compute hosts " "directly affects network and datacenter resources." msgstr "" #: ../generalpurpose-operational-considerations.rst:102 msgid "" "Assessing the average workloads and increasing the number of instances that " "can run within the compute environment by adjusting the overcommit ratio is " "another option. It is important to remember that changing the CPU overcommit " "ratio can have a detrimental effect and cause a potential increase in a " "noisy neighbor. The additional risk of increasing the overcommit ratio is " "more instances failing when a compute host fails." msgstr "" #: ../generalpurpose-operational-considerations.rst:109 msgid "" "Compute host components can also be upgraded to account for increases in " "demand; this is known as vertical scaling. Upgrading CPUs with more cores, " "or increasing the overall server memory, can add extra needed capacity " "depending on whether the running applications are more CPU intensive or " "memory intensive." msgstr "" #: ../generalpurpose-operational-considerations.rst:115 msgid "" "Insufficient disk capacity could also have a negative effect on overall " "performance including CPU and memory usage. Depending on the back-end " "architecture of the OpenStack Block Storage layer, capacity includes adding " "disk shelves to enterprise storage systems or installing additional block " "storage nodes. Upgrading directly attached storage installed in compute " "hosts, and adding capacity to the shared storage for additional ephemeral " "storage to instances, may be necessary." msgstr "" #: ../generalpurpose-operational-considerations.rst:123 msgid "" "For a deeper discussion on many of these topics, refer to the `OpenStack " "Operations Guide `_." msgstr "" #: ../generalpurpose-prescriptive-example.rst:3 msgid "Prescriptive example" msgstr "" #: ../generalpurpose-prescriptive-example.rst:5 msgid "" "An online classified advertising company wants to run web applications " "consisting of Tomcat, Nginx and MariaDB in a private cloud. To be able to " "meet policy requirements, the cloud infrastructure will run in their own " "data center. The company has predictable load requirements, but requires " "scaling to cope with nightly increases in demand. Their current environment " "does not have the flexibility to align with their goal of running an open " "source API environment. The current environment consists of the following:" msgstr "" #: ../generalpurpose-prescriptive-example.rst:14 msgid "" "Between 120 and 140 installations of Nginx and Tomcat, each with 2 vCPUs and " "4 GB of RAM" msgstr "" #: ../generalpurpose-prescriptive-example.rst:17 msgid "A three-node MariaDB and Galera cluster, each with 4 vCPUs and 8 GB RAM" msgstr "" #: ../generalpurpose-prescriptive-example.rst:20 msgid "" "The company runs hardware load balancers and multiple web applications " "serving their websites, and orchestrates environments using combinations of " "scripts and Puppet. The website generates large amounts of log data daily " "that requires archiving." msgstr "" # #-#-#-#-# generalpurpose-prescriptive-example.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# multi-site-prescriptive-examples.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../generalpurpose-prescriptive-example.rst:25 #: ../multi-site-prescriptive-examples.rst:91 msgid "The solution would consist of the following OpenStack components:" msgstr "" # #-#-#-#-# generalpurpose-prescriptive-example.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# multi-site-prescriptive-examples.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../generalpurpose-prescriptive-example.rst:27 #: ../multi-site-prescriptive-examples.rst:93 msgid "" "A firewall, switches and load balancers on the public facing network " "connections." msgstr "" #: ../generalpurpose-prescriptive-example.rst:30 msgid "" "OpenStack Controller service running Image, Identity, Networking, combined " "with support services such as MariaDB and RabbitMQ, configured for high " "availability on at least three controller nodes." msgstr "" # #-#-#-#-# generalpurpose-prescriptive-example.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# multi-site-prescriptive-examples.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../generalpurpose-prescriptive-example.rst:34 #: ../multi-site-prescriptive-examples.rst:103 msgid "OpenStack Compute nodes running the KVM hypervisor." msgstr "" #: ../generalpurpose-prescriptive-example.rst:36 msgid "" "OpenStack Block Storage for use by compute instances, requiring persistent " "storage (such as databases for dynamic sites)." msgstr "" #: ../generalpurpose-prescriptive-example.rst:39 msgid "OpenStack Object Storage for serving static objects (such as images)." msgstr "" #: ../generalpurpose-prescriptive-example.rst:43 msgid "" "Running up to 140 web instances and the small number of MariaDB instances " "requires 292 vCPUs available, as well as 584 GB RAM. On a typical 1U server " "using dual-socket hex-core Intel CPUs with Hyperthreading, and assuming 2:1 " "CPU overcommit ratio, this would require 8 OpenStack Compute nodes." msgstr "" #: ../generalpurpose-prescriptive-example.rst:49 msgid "" "The web application instances run from local storage on each of the " "OpenStack Compute nodes. The web application instances are stateless, " "meaning that any of the instances can fail and the application will continue " "to function." msgstr "" #: ../generalpurpose-prescriptive-example.rst:54 msgid "" "MariaDB server instances store their data on shared enterprise storage, such " "as NetApp or Solidfire devices. If a MariaDB instance fails, storage would " "be expected to be re-attached to another instance and rejoined to the Galera " "cluster." msgstr "" #: ../generalpurpose-prescriptive-example.rst:59 msgid "" "Logs from the web application servers are shipped to OpenStack Object " "Storage for processing and archiving." msgstr "" #: ../generalpurpose-prescriptive-example.rst:62 msgid "" "Additional capabilities can be realized by moving static web content to be " "served from OpenStack Object Storage containers, and backing the OpenStack " "Image service with OpenStack Object Storage." msgstr "" #: ../generalpurpose-prescriptive-example.rst:68 msgid "" "Increasing OpenStack Object Storage means network bandwidth needs to be " "taken into consideration. Running OpenStack Object Storage with network " "connections offering 10 GbE or better connectivity is advised." msgstr "" #: ../generalpurpose-prescriptive-example.rst:73 msgid "" "Leveraging Orchestration and Telemetry services is also a potential issue " "when providing auto-scaling, orchestrated web application environments. " "Defining the web applications in a :term:`Heat Orchestration Template (HOT)` " "negates the reliance on the current scripted Puppet solution." msgstr "" #: ../generalpurpose-prescriptive-example.rst:80 msgid "" "OpenStack Networking can be used to control hardware load balancers through " "the use of plug-ins and the Networking API. This allows users to control " "hardware load balance pools and instances as members in these pools, but " "their use in production environments must be carefully weighed against " "current stability." msgstr "" #: ../generalpurpose-technical-considerations.rst:5 msgid "General purpose clouds are expected to include these base services:" msgstr "" #: ../generalpurpose-technical-considerations.rst:13 msgid "" "Each of these services have different resource requirements. As a result, " "you must make design decisions relating directly to the service, as well as " "provide a balanced infrastructure for all services." msgstr "" #: ../generalpurpose-technical-considerations.rst:17 msgid "" "Take into consideration the unique aspects of each service, as individual " "characteristics and service mass can impact the hardware selection process. " "Hardware designs should be generated for each of the services." msgstr "" #: ../generalpurpose-technical-considerations.rst:22 msgid "" "Hardware decisions are also made in relation to network architecture and " "facilities planning. These factors play heavily into the overall " "architecture of an OpenStack cloud." msgstr "" #: ../generalpurpose-technical-considerations.rst:27 msgid "Compute resource design" msgstr "" #: ../generalpurpose-technical-considerations.rst:29 msgid "" "When designing compute resource pools, a number of factors can impact your " "design decisions. Factors such as number of processors, amount of memory, " "and the quantity of storage required for each hypervisor must be taken into " "account." msgstr "" #: ../generalpurpose-technical-considerations.rst:34 msgid "" "You will also need to decide whether to provide compute resources in a " "single pool or in multiple pools. In most cases, multiple pools of resources " "can be allocated and addressed on demand. A compute design that allocates " "multiple pools of resources makes best use of application resources, and is " "commonly referred to as bin packing." msgstr "" #: ../generalpurpose-technical-considerations.rst:40 msgid "" "In a bin packing design, each independent resource pool provides service for " "specific flavors. This helps to ensure that, as instances are scheduled onto " "compute hypervisors, each independent node's resources will be allocated in " "a way that makes the most efficient use of the available hardware. Bin " "packing also requires a common hardware design, with all hardware nodes " "within a compute resource pool sharing a common processor, memory, and " "storage layout. This makes it easier to deploy, support, and maintain nodes " "throughout their lifecycle." msgstr "" #: ../generalpurpose-technical-considerations.rst:49 msgid "" "An overcommit ratio is the ratio of available virtual resources to available " "physical resources. This ratio is configurable for CPU and memory. The " "default CPU overcommit ratio is 16:1, and the default memory overcommit " "ratio is 1.5:1. Determining the tuning of the overcommit ratios during the " "design phase is important as it has a direct impact on the hardware layout " "of your compute nodes." msgstr "" #: ../generalpurpose-technical-considerations.rst:56 msgid "" "When selecting a processor, compare features and performance " "characteristics. Some processors include features specific to virtualized " "compute hosts, such as hardware-assisted virtualization, and technology " "related to memory paging (also known as EPT shadowing). These types of " "features can have a significant impact on the performance of your virtual " "machine." msgstr "" #: ../generalpurpose-technical-considerations.rst:63 msgid "" "You will also need to consider the compute requirements of non-hypervisor " "nodes (sometimes referred to as resource nodes). This includes controller, " "object storage, and block storage nodes, and networking services." msgstr "" #: ../generalpurpose-technical-considerations.rst:68 msgid "" "The number of processor cores and threads impacts the number of worker " "threads which can be run on a resource node. Design decisions must relate " "directly to the service being run on it, as well as provide a balanced " "infrastructure for all services." msgstr "" #: ../generalpurpose-technical-considerations.rst:73 msgid "" "Workload can be unpredictable in a general purpose cloud, so consider " "including the ability to add additional compute resource pools on demand. In " "some cases, however, the demand for certain instance types or flavors may " "not justify individual hardware design. In either case, start by allocating " "hardware designs that are capable of servicing the most common instance " "requests. If you want to add additional hardware to the overall " "architecture, this can be done later." msgstr "" #: ../generalpurpose-technical-considerations.rst:82 msgid "Designing network resources" msgstr "" #: ../generalpurpose-technical-considerations.rst:84 msgid "" "OpenStack clouds generally have multiple network segments, with each segment " "providing access to particular resources. The network services themselves " "also require network communication paths which should be separated from the " "other networks. When designing network services for a general purpose cloud, " "plan for either a physical or logical separation of network segments used by " "operators and tenants. You can also create an additional network segment for " "access to internal services such as the message bus and database used by " "various services. Segregating these services onto separate networks helps to " "protect sensitive data and protects against unauthorized access to services." msgstr "" #: ../generalpurpose-technical-considerations.rst:95 msgid "" "Choose a networking service based on the requirements of your instances. The " "architecture and design of your cloud will impact whether you choose " "OpenStack Networking (neutron), or legacy networking (nova-network)." msgstr "" #: ../generalpurpose-technical-considerations.rst:100 msgid "" "The legacy networking (nova-network) service is primarily a layer-2 " "networking service that functions in two modes, which use VLANs in different " "ways. In a flat network mode, all network hardware nodes and devices " "throughout the cloud are connected to a single layer-2 network segment that " "provides access to application data." msgstr "" #: ../generalpurpose-technical-considerations.rst:106 msgid "" "When the network devices in the cloud support segmentation using VLANs, " "legacy networking can operate in the second mode. In this design model, each " "tenant within the cloud is assigned a network subnet which is mapped to a " "VLAN on the physical network. It is especially important to remember the " "maximum number of 4096 VLANs which can be used within a spanning tree " "domain. This places a hard limit on the amount of growth possible within the " "data center. When designing a general purpose cloud intended to support " "multiple tenants, we recommend the use of legacy networking with VLANs, and " "not in flat network mode." msgstr "" # #-#-#-#-# generalpurpose-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# network-focus-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../generalpurpose-technical-considerations.rst:115 #: ../network-focus-technical-considerations.rst:253 msgid "Legacy networking (nova-network)" msgstr "" #: ../generalpurpose-technical-considerations.rst:117 msgid "" "Another consideration regarding network is the fact that legacy networking " "is entirely managed by the cloud operator; tenants do not have control over " "network resources. If tenants require the ability to manage and create " "network resources such as network segments and subnets, it will be necessary " "to install the OpenStack Networking service to provide network access to " "instances." msgstr "" #: ../generalpurpose-technical-considerations.rst:125 msgid "" "OpenStack Networking (neutron) is a first class networking service that " "gives full control over creation of virtual network resources to tenants. " "This is often accomplished in the form of tunneling protocols which will " "establish encapsulated communication paths over existing network " "infrastructure in order to segment tenant traffic. These methods vary " "depending on the specific implementation, but some of the more common " "methods include tunneling over GRE, encapsulating with VXLAN, and VLAN tags." msgstr "" #: ../generalpurpose-technical-considerations.rst:134 msgid "We recommend you design at least three network segments:" msgstr "" #: ../generalpurpose-technical-considerations.rst:136 msgid "" "The first segment is a public network, used for access to REST APIs by " "tenants and operators. The controller nodes and swift proxies are the only " "devices connecting to this network segment. In some cases, this network " "might also be serviced by hardware load balancers and other network devices." msgstr "" #: ../generalpurpose-technical-considerations.rst:142 msgid "" "The second segment is used by administrators to manage hardware resources. " "Configuration management tools also use this for deploying software and " "services onto new hardware. In some cases, this network segment might also " "be used for internal services, including the message bus and database " "services. This network needs to communicate with every hardware node. Due to " "the highly sensitive nature of this network segment, you also need to secure " "this network from unauthorized access." msgstr "" #: ../generalpurpose-technical-considerations.rst:151 msgid "" "The third network segment is used by applications and consumers to access " "the physical network, and for users to access applications. This network is " "segregated from the one used to access the cloud APIs and is not capable of " "communicating directly with the hardware resources in the cloud. Compute " "resource nodes and network gateway services which allow application data to " "access the physical network from outside of the cloud need to communicate on " "this network segment." msgstr "" #: ../generalpurpose-technical-considerations.rst:161 msgid "Designing Object Storage" msgstr "" #: ../generalpurpose-technical-considerations.rst:163 msgid "" "When designing hardware resources for OpenStack Object Storage, the primary " "goal is to maximize the amount of storage in each resource node while also " "ensuring that the cost per terabyte is kept to a minimum. This often " "involves utilizing servers which can hold a large number of spinning disks. " "Whether choosing to use 2U server form factors with directly attached " "storage or an external chassis that holds a larger number of drives, the " "main goal is to maximize the storage available in each node." msgstr "" #: ../generalpurpose-technical-considerations.rst:174 msgid "" "We do not recommended investing in enterprise class drives for an OpenStack " "Object Storage cluster. The consistency and partition tolerance " "characteristics of OpenStack Object Storage ensures that data stays up to " "date and survives hardware faults without the use of any specialized data " "replication devices." msgstr "" #: ../generalpurpose-technical-considerations.rst:180 msgid "" "One of the benefits of OpenStack Object Storage is the ability to mix and " "match drives by making use of weighting within the swift ring. When " "designing your swift storage cluster, we recommend making use of the most " "cost effective storage solution available at the time." msgstr "" #: ../generalpurpose-technical-considerations.rst:185 msgid "" "To achieve durability and availability of data stored as objects it is " "important to design object storage resource pools to ensure they can provide " "the suggested availability. Considering rack-level and zone-level designs to " "accommodate the number of replicas configured to be stored in the Object " "Storage service (the default number of replicas is three) is important when " "designing beyond the hardware node level. Each replica of data should exist " "in its own availability zone with its own power, cooling, and network " "resources available to service that specific zone." msgstr "" #: ../generalpurpose-technical-considerations.rst:195 msgid "" "Object storage nodes should be designed so that the number of requests does " "not hinder the performance of the cluster. The object storage service is a " "chatty protocol, therefore making use of multiple processors that have " "higher core counts will ensure the IO requests do not inundate the server." msgstr "" #: ../generalpurpose-technical-considerations.rst:202 msgid "Designing Block Storage" msgstr "" #: ../generalpurpose-technical-considerations.rst:204 msgid "" "When designing OpenStack Block Storage resource nodes, it is helpful to " "understand the workloads and requirements that will drive the use of block " "storage in the cloud. We recommend designing block storage pools so that " "tenants can choose appropriate storage solutions for their applications. By " "creating multiple storage pools of different types, in conjunction with " "configuring an advanced storage scheduler for the block storage service, it " "is possible to provide tenants with a large catalog of storage services with " "a variety of performance levels and redundancy options." msgstr "" #: ../generalpurpose-technical-considerations.rst:214 msgid "" "Block storage also takes advantage of a number of enterprise storage " "solutions. These are addressed via a plug-in driver developed by the " "hardware vendor. A large number of enterprise storage plug-in drivers ship " "out-of-the-box with OpenStack Block Storage (and many more available via " "third party channels). General purpose clouds are more likely to use " "directly attached storage in the majority of block storage nodes, deeming it " "necessary to provide additional levels of service to tenants which can only " "be provided by enterprise class storage solutions." msgstr "" #: ../generalpurpose-technical-considerations.rst:224 msgid "" "Redundancy and availability requirements impact the decision to use a RAID " "controller card in block storage nodes. The input-output per second (IOPS) " "demand of your application will influence whether or not you should use a " "RAID controller, and which level of RAID is required. Making use of higher " "performing RAID volumes is suggested when considering performance. However, " "where redundancy of block storage volumes is more important we recommend " "making use of a redundant RAID configuration such as RAID 5 or RAID 6. Some " "specialized features, such as automated replication of block storage " "volumes, may require the use of third-party plug-ins and enterprise block " "storage solutions in order to provide the high demand on storage. " "Furthermore, where extreme performance is a requirement it may also be " "necessary to make use of high speed SSD disk drives' high performing flash " "storage solutions." msgstr "" #: ../generalpurpose-technical-considerations.rst:241 msgid "" "The software selection process plays a large role in the architecture of a " "general purpose cloud. The following have a large impact on the design of " "the cloud:" msgstr "" #: ../generalpurpose-technical-considerations.rst:245 msgid "Choice of operating system" msgstr "" #: ../generalpurpose-technical-considerations.rst:247 msgid "Selection of OpenStack software components" msgstr "" #: ../generalpurpose-technical-considerations.rst:249 msgid "Choice of hypervisor" msgstr "" #: ../generalpurpose-technical-considerations.rst:251 msgid "Selection of supplemental software" msgstr "" #: ../generalpurpose-technical-considerations.rst:253 msgid "" "Operating system (OS) selection plays a large role in the design and " "architecture of a cloud. There are a number of OSes which have native " "support for OpenStack including:" msgstr "" #: ../generalpurpose-technical-considerations.rst:257 msgid "Ubuntu" msgstr "" #: ../generalpurpose-technical-considerations.rst:259 msgid "Red Hat Enterprise Linux (RHEL)" msgstr "" #: ../generalpurpose-technical-considerations.rst:261 msgid "CentOS" msgstr "" #: ../generalpurpose-technical-considerations.rst:263 msgid "SUSE Linux Enterprise Server (SLES)" msgstr "" #: ../generalpurpose-technical-considerations.rst:267 msgid "" "Native support is not a constraint on the choice of OS; users are free to " "choose just about any Linux distribution (or even Microsoft Windows) and " "install OpenStack directly from source (or compile their own packages). " "However, many organizations will prefer to install OpenStack from " "distribution-supplied packages or repositories (although using the " "distribution vendor's OpenStack packages might be a requirement for support)." msgstr "" #: ../generalpurpose-technical-considerations.rst:275 msgid "" "OS selection also directly influences hypervisor selection. A cloud " "architect who selects Ubuntu, RHEL, or SLES has some flexibility in " "hypervisor; KVM, Xen, and LXC are supported virtualization methods available " "under OpenStack Compute (nova) on these Linux distributions. However, a " "cloud architect who selects Hyper-V is limited to Windows Servers. " "Similarly, a cloud architect who selects XenServer is limited to the CentOS-" "based dom0 operating system provided with XenServer." msgstr "" #: ../generalpurpose-technical-considerations.rst:283 msgid "The primary factors that play into OS-hypervisor selection include:" msgstr "" #: ../generalpurpose-technical-considerations.rst:286 msgid "" "The selection of OS-hypervisor combination first and foremost needs to " "support the user requirements." msgstr "" # #-#-#-#-# generalpurpose-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# generalpurpose-user-requirements.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# hybrid-user-requirements.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# massively-scalable-user-requirements.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# multi-site-user-requirements.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# network-focus-user-requirements.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../generalpurpose-technical-considerations.rst:287 #: ../generalpurpose-user-requirements.rst:3 ../hybrid-user-requirements.rst:3 #: ../massively-scalable-user-requirements.rst:2 #: ../multi-site-user-requirements.rst:3 #: ../network-focus-user-requirements.rst:2 msgid "User requirements" msgstr "" #: ../generalpurpose-technical-considerations.rst:290 msgid "" "The selected OS-hypervisor combination needs to be supported by OpenStack." msgstr "" #: ../generalpurpose-technical-considerations.rst:291 msgid "Support" msgstr "" #: ../generalpurpose-technical-considerations.rst:294 msgid "" "The OS-hypervisor needs to be interoperable with other features and services " "in the OpenStack design in order to meet the user requirements." msgstr "" # #-#-#-#-# generalpurpose-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# specialized-openstack-on-openstack.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../generalpurpose-technical-considerations.rst:299 #: ../specialized-openstack-on-openstack.rst:30 msgid "Hypervisor" msgstr "" #: ../generalpurpose-technical-considerations.rst:301 msgid "" "OpenStack supports a wide variety of hypervisors, one or more of which can " "be used in a single cloud. These hypervisors include:" msgstr "" #: ../generalpurpose-technical-considerations.rst:304 msgid "KVM (and QEMU)" msgstr "" #: ../generalpurpose-technical-considerations.rst:306 msgid "XCP/XenServer" msgstr "" #: ../generalpurpose-technical-considerations.rst:308 msgid "vSphere (vCenter and ESXi)" msgstr "" #: ../generalpurpose-technical-considerations.rst:310 msgid "Hyper-V" msgstr "" #: ../generalpurpose-technical-considerations.rst:312 msgid "LXC" msgstr "" #: ../generalpurpose-technical-considerations.rst:314 msgid "Docker" msgstr "" #: ../generalpurpose-technical-considerations.rst:316 msgid "Bare-metal" msgstr "" #: ../generalpurpose-technical-considerations.rst:318 msgid "" "A complete list of supported hypervisors and their capabilities can be found " "at `OpenStack Hypervisor Support Matrix `_." msgstr "" #: ../generalpurpose-technical-considerations.rst:322 msgid "" "We recommend general purpose clouds use hypervisors that support the most " "general purpose use cases, such as KVM and Xen. More specific hypervisors " "should be chosen to account for specific functionality or a supported " "feature requirement. In some cases, there may also be a mandated requirement " "to run software on a certified hypervisor including solutions from VMware, " "Microsoft, and Citrix." msgstr "" #: ../generalpurpose-technical-considerations.rst:329 msgid "" "The features offered through the OpenStack cloud platform determine the best " "choice of a hypervisor. Each hypervisor has their own hardware requirements " "which may affect the decisions around designing a general purpose cloud." msgstr "" #: ../generalpurpose-technical-considerations.rst:334 msgid "" "In a mixed hypervisor environment, specific aggregates of compute resources, " "each with defined capabilities, enable workloads to utilize software and " "hardware specific to their particular requirements. This functionality can " "be exposed explicitly to the end user, or accessed through defined metadata " "within a particular flavor of an instance." msgstr "" #: ../generalpurpose-technical-considerations.rst:343 msgid "" "A general purpose OpenStack cloud design should incorporate the core " "OpenStack services to provide a wide range of services to end-users. The " "OpenStack core services recommended in a general purpose cloud are:" msgstr "" #: ../generalpurpose-technical-considerations.rst:347 msgid ":term:`Compute service` (:term:`nova`)" msgstr "" #: ../generalpurpose-technical-considerations.rst:349 msgid ":term:`Networking service` (:term:`neutron`)" msgstr "" #: ../generalpurpose-technical-considerations.rst:351 msgid ":term:`Image service` (:term:`glance`)" msgstr "" #: ../generalpurpose-technical-considerations.rst:353 msgid ":term:`Identity service` (:term:`keystone`)" msgstr "" #: ../generalpurpose-technical-considerations.rst:355 msgid ":term:`Dashboard` (:term:`horizon`)" msgstr "" #: ../generalpurpose-technical-considerations.rst:357 msgid ":term:`Telemetry service` (:term:`ceilometer`)" msgstr "" #: ../generalpurpose-technical-considerations.rst:359 msgid "" "A general purpose cloud may also include :term:`Object Storage service` (:" "term:`swift`). :term:`Block Storage service` (:term:`cinder`). These may be " "selected to provide storage to applications and instances." msgstr "" #: ../generalpurpose-technical-considerations.rst:366 msgid "" "A general purpose OpenStack deployment consists of more than just OpenStack-" "specific components. A typical deployment involves services that provide " "supporting functionality, including databases and message queues, and may " "also involve software to provide high availability of the OpenStack " "environment. Design decisions around the underlying message queue might " "affect the required number of controller services, as well as the technology " "to provide highly resilient database functionality, such as MariaDB with " "Galera. In such a scenario, replication of services relies on quorum." msgstr "" #: ../generalpurpose-technical-considerations.rst:376 msgid "" "Where many general purpose deployments use hardware load balancers to " "provide highly available API access and SSL termination, software solutions, " "for example HAProxy, can also be considered. It is vital to ensure that such " "software implementations are also made highly available. High availability " "can be achieved by using software such as Keepalived or Pacemaker with " "Corosync. Pacemaker and Corosync can provide active-active or active-passive " "highly available configuration depending on the specific service in the " "OpenStack environment. Using this software can affect the design as it " "assumes at least a 2-node controller infrastructure where one of those nodes " "may be running certain services in standby mode." msgstr "" #: ../generalpurpose-technical-considerations.rst:388 msgid "" "Memcached is a distributed memory object caching system, and Redis is a key-" "value store. Both are deployed on general purpose clouds to assist in " "alleviating load to the Identity service. The memcached service caches " "tokens, and due to its distributed nature it can help alleviate some " "bottlenecks to the underlying authentication system. Using memcached or " "Redis does not affect the overall design of your architecture as they tend " "to be deployed onto the infrastructure nodes providing the OpenStack " "services." msgstr "" #: ../generalpurpose-technical-considerations.rst:398 msgid "Controller infrastructure" msgstr "" #: ../generalpurpose-technical-considerations.rst:400 msgid "" "The Controller infrastructure nodes provide management services to the end-" "user as well as providing services internally for the operating of the " "cloud. The Controllers run message queuing services that carry system " "messages between each service. Performance issues related to the message bus " "would lead to delays in sending that message to where it needs to go. The " "result of this condition would be delays in operation functions such as " "spinning up and deleting instances, provisioning new storage volumes and " "managing network resources. Such delays could adversely affect an " "application’s ability to react to certain conditions, especially when using " "auto-scaling features. It is important to properly design the hardware used " "to run the controller infrastructure as outlined above in the Hardware " "Selection section." msgstr "" #: ../generalpurpose-technical-considerations.rst:413 msgid "" "Performance of the controller services is not limited to processing power, " "but restrictions may emerge in serving concurrent users. Ensure that the " "APIs and Horizon services are load tested to ensure that you are able to " "serve your customers. Particular attention should be made to the OpenStack " "Identity Service (Keystone), which provides the authentication and " "authorization for all services, both internally to OpenStack itself and to " "end-users. This service can lead to a degradation of overall performance if " "this is not sized appropriately." msgstr "" #: ../generalpurpose-technical-considerations.rst:423 msgid "Network performance" msgstr "" #: ../generalpurpose-technical-considerations.rst:425 msgid "" "In a general purpose OpenStack cloud, the requirements of the network help " "determine performance capabilities. It is possible to design OpenStack " "environments that run a mix of networking capabilities. By utilizing the " "different interface speeds, the users of the OpenStack environment can " "choose networks that are fit for their purpose." msgstr "" #: ../generalpurpose-technical-considerations.rst:431 msgid "" "Network performance can be boosted considerably by implementing hardware " "load balancers to provide front-end service to the cloud APIs. The hardware " "load balancers also perform SSL termination if that is a requirement of your " "environment. When implementing SSL offloading, it is important to understand " "the SSL offloading capabilities of the devices selected." msgstr "" #: ../generalpurpose-technical-considerations.rst:439 msgid "Compute host" msgstr "" #: ../generalpurpose-technical-considerations.rst:441 msgid "" "The choice of hardware specifications used in compute nodes including CPU, " "memory and disk type directly affects the performance of the instances. " "Other factors which can directly affect performance include tunable " "parameters within the OpenStack services, for example the overcommit ratio " "applied to resources. The defaults in OpenStack Compute set a 16:1 over-" "commit of the CPU and 1.5 over-commit of the memory. Running at such high " "ratios leads to an increase in \"noisy-neighbor\" activity. Care must be " "taken when sizing your Compute environment to avoid this scenario. For " "running general purpose OpenStack environments it is possible to keep to the " "defaults, but make sure to monitor your environment as usage increases." msgstr "" #: ../generalpurpose-technical-considerations.rst:454 msgid "Storage performance" msgstr "" #: ../generalpurpose-technical-considerations.rst:456 msgid "" "When considering performance of Block Storage, hardware and architecture " "choice is important. Block Storage can use enterprise back-end systems such " "as NetApp or EMC, scale out storage such as GlusterFS and Ceph, or simply " "use the capabilities of directly attached storage in the nodes themselves. " "Block Storage may be deployed so that traffic traverses the host network, " "which could affect, and be adversely affected by, the front-side API traffic " "performance. As such, consider using a dedicated data storage network with " "dedicated interfaces on the Controller and Compute hosts." msgstr "" #: ../generalpurpose-technical-considerations.rst:466 msgid "" "When considering performance of Object Storage, a number of design choices " "will affect performance. A user’s access to the Object Storage is through " "the proxy services, which sit behind hardware load balancers. By the very " "nature of a highly resilient storage system, replication of the data would " "affect performance of the overall system. In this case, 10 GbE (or better) " "networking is recommended throughout the storage network architecture." msgstr "" #: ../generalpurpose-technical-considerations.rst:475 msgid "High Availability" msgstr "" #: ../generalpurpose-technical-considerations.rst:477 msgid "" "In OpenStack, the infrastructure is integral to providing services and " "should always be available, especially when operating with SLAs. Ensuring " "network availability is accomplished by designing the network architecture " "so that no single point of failure exists. A consideration of the number of " "switches, routes and redundancies of power should be factored into core " "infrastructure, as well as the associated bonding of networks to provide " "diverse routes to your highly available switch infrastructure." msgstr "" #: ../generalpurpose-technical-considerations.rst:486 msgid "" "The OpenStack services themselves should be deployed across multiple servers " "that do not represent a single point of failure. Ensuring API availability " "can be achieved by placing these services behind highly available load " "balancers that have multiple OpenStack servers as members." msgstr "" #: ../generalpurpose-technical-considerations.rst:492 msgid "" "OpenStack lends itself to deployment in a highly available manner where it " "is expected that at least 2 servers be utilized. These can run all the " "services involved from the message queuing service, for example RabbitMQ or " "QPID, and an appropriately deployed database service such as MySQL or " "MariaDB. As services in the cloud are scaled out, back-end services will " "need to scale too. Monitoring and reporting on server utilization and " "response times, as well as load testing your systems, will help determine " "scale out decisions." msgstr "" #: ../generalpurpose-technical-considerations.rst:501 msgid "" "Care must be taken when deciding network functionality. Currently, OpenStack " "supports both the legacy networking (nova-network) system and the newer, " "extensible OpenStack Networking (neutron). Both have their pros and cons " "when it comes to providing highly available access. Legacy networking, which " "provides networking access maintained in the OpenStack Compute code, " "provides a feature that removes a single point of failure when it comes to " "routing, and this feature is currently missing in OpenStack Networking. The " "effect of legacy networking’s multi-host functionality restricts failure " "domains to the host running that instance." msgstr "" #: ../generalpurpose-technical-considerations.rst:512 msgid "" "When using Networking, the OpenStack controller servers or separate " "Networking hosts handle routing. For a deployment that requires features " "available in only Networking, it is possible to remove this restriction by " "using third party software that helps maintain highly available L3 routes. " "Doing so allows for common APIs to control network hardware, or to provide " "complex multi-tier web applications in a secure manner. It is also possible " "to completely remove routing from Networking, and instead rely on hardware " "routing capabilities. In this case, the switching infrastructure must " "support L3 routing." msgstr "" #: ../generalpurpose-technical-considerations.rst:522 msgid "" "OpenStack Networking and legacy networking both have their advantages and " "disadvantages. They are both valid and supported options that fit different " "network deployment models described in the `OpenStack Operations Guide " "`_." msgstr "" #: ../generalpurpose-technical-considerations.rst:528 msgid "Ensure your deployment has adequate back-up capabilities." msgstr "" #: ../generalpurpose-technical-considerations.rst:530 msgid "" "Application design must also be factored into the capabilities of the " "underlying cloud infrastructure. If the compute hosts do not provide a " "seamless live migration capability, then it must be expected that when a " "compute host fails, that instance and any data local to that instance will " "be deleted. However, when providing an expectation to users that instances " "have a high-level of uptime guarantees, the infrastructure must be deployed " "in a way that eliminates any single point of failure when a compute host " "disappears. This may include utilizing shared file systems on enterprise " "storage or OpenStack Block storage to provide a level of guarantee to match " "service features." msgstr "" #: ../generalpurpose-technical-considerations.rst:541 msgid "" "For more information on high availability in OpenStack, see the `OpenStack " "High Availability Guide `_." msgstr "" #: ../generalpurpose-technical-considerations.rst:548 msgid "" "A security domain comprises users, applications, servers or networks that " "share common trust requirements and expectations within a system. Typically " "they have the same authentication and authorization requirements and users." msgstr "" #: ../generalpurpose-technical-considerations.rst:553 msgid "These security domains are:" msgstr "" #: ../generalpurpose-technical-considerations.rst:555 msgid "Public" msgstr "" #: ../generalpurpose-technical-considerations.rst:557 msgid "Guest" msgstr "" # #-#-#-#-# generalpurpose-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# multi-site-user-requirements.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../generalpurpose-technical-considerations.rst:559 #: ../multi-site-user-requirements.rst:114 msgid "Management" msgstr "" # #-#-#-#-# generalpurpose-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# hybrid-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../generalpurpose-technical-considerations.rst:561 #: ../hybrid-architecture.rst:127 msgid "Data" msgstr "" #: ../generalpurpose-technical-considerations.rst:563 msgid "" "These security domains can be mapped to an OpenStack deployment " "individually, or combined. In each case, the cloud operator should be aware " "of the appropriate security concerns. Security domains should be mapped out " "against your specific OpenStack deployment topology. The domains and their " "trust requirements depend upon whether the cloud instance is public, " "private, or hybrid." msgstr "" #: ../generalpurpose-technical-considerations.rst:570 msgid "" "The public security domain is an entirely untrusted area of the cloud " "infrastructure. It can refer to the internet as a whole or simply to " "networks over which you have no authority. This domain should always be " "considered untrusted." msgstr "" #: ../generalpurpose-technical-considerations.rst:575 msgid "" "The guest security domain handles compute data generated by instances on the " "cloud but not services that support the operation of the cloud, such as 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 domain to be untrusted. Private cloud " "providers may want to consider this network as internal and therefore " "trusted only if they have controls in place to assert that they trust " "instances and all their tenants." msgstr "" #: ../generalpurpose-technical-considerations.rst:585 msgid "" "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 domain is considered trusted." msgstr "" #: ../generalpurpose-technical-considerations.rst:591 msgid "" "The data security domain is concerned primarily 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, may also have strong availability requirements. " "The trust level of this network is heavily dependent on other deployment " "decisions." msgstr "" #: ../generalpurpose-technical-considerations.rst:598 msgid "" "When deploying OpenStack in an enterprise as a private cloud it is usually " "behind the firewall and within the trusted network alongside existing " "systems. Users of the cloud are employees 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, no assumptions can be made and the attack " "vectors significantly increase." msgstr "" #: ../generalpurpose-technical-considerations.rst:606 msgid "" "Consideration must be taken when managing the users of the system for both " "public and private clouds. The identity service allows for LDAP to be part " "of the authentication process. Including such systems in an OpenStack " "deployment may ease user management if integrating into existing systems." msgstr "" #: ../generalpurpose-technical-considerations.rst:612 msgid "" "It is important to understand that user authentication requests include " "sensitive information including user names, passwords, and authentication " "tokens. For this reason, placing the API services behind hardware that " "performs SSL termination is strongly recommended." msgstr "" #: ../generalpurpose-technical-considerations.rst:617 msgid "" "For more information OpenStack Security, see the `OpenStack Security Guide " "`_." msgstr "" #: ../generalpurpose-user-requirements.rst:5 msgid "" "When building a general purpose cloud, you should follow the Infrastructure-" "as-a-Service (:term:`IaaS`) model; a platform best suited for use cases with " "simple requirements. General purpose cloud user requirements are not " "complex. However, it is important to capture them even if the project has " "minimum business and technical requirements, such as a proof of concept " "(PoC), or a small lab platform." msgstr "" #: ../generalpurpose-user-requirements.rst:13 msgid "" "The following user considerations are written from the perspective of the " "cloud builder, not from the perspective of the end user." msgstr "" #: ../generalpurpose-user-requirements.rst:17 msgid "Business requirements" msgstr "" #: ../generalpurpose-user-requirements.rst:20 msgid "" "Financial factors are a primary concern for any organization. Cost is an " "important criterion as general purpose clouds are considered the baseline " "from which all other cloud architecture environments derive. General purpose " "clouds do not always provide the most cost-effective environment for " "specialized applications or situations. Unless razor-thin margins and costs " "have been mandated as a critical factor, cost should not be the sole " "consideration when choosing or designing a general purpose architecture." msgstr "" #: ../generalpurpose-user-requirements.rst:30 msgid "" "The ability to deliver services or products within a flexible time frame is " "a common business factor when building a general purpose cloud. Delivering a " "product in six months instead of two years is a driving force behind the " "decision to build general purpose clouds. General purpose clouds allow users " "to self-provision and gain access to compute, network, and storage resources " "on-demand thus decreasing time to market." msgstr "" #: ../generalpurpose-user-requirements.rst:36 msgid "Time to market" msgstr "" #: ../generalpurpose-user-requirements.rst:39 msgid "" "Revenue opportunities for a cloud will vary greatly based on the intended " "use case of that particular cloud. Some general purpose clouds are built for " "commercial customer facing products, but there are alternatives that might " "make the general purpose cloud the right choice." msgstr "" # #-#-#-#-# generalpurpose-user-requirements.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# hybrid-user-requirements.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../generalpurpose-user-requirements.rst:43 #: ../hybrid-user-requirements.rst:29 msgid "Revenue opportunity" msgstr "" #: ../generalpurpose-user-requirements.rst:46 msgid "Technical requirements" msgstr "" #: ../generalpurpose-user-requirements.rst:48 msgid "" "Technical cloud architecture requirements should be weighted against the " "business requirements." msgstr "" #: ../generalpurpose-user-requirements.rst:52 msgid "" "As a baseline product, general purpose clouds do not provide optimized " "performance for any particular function. While a general purpose cloud " "should provide enough performance to satisfy average user considerations, " "performance is not a general purpose cloud customer driver." msgstr "" #: ../generalpurpose-user-requirements.rst:59 msgid "" "The lack of a pre-defined usage model enables the user to run a wide variety " "of applications without having to know the application requirements in " "advance. This provides a degree of independence and flexibility that no " "other cloud scenarios are able to provide." msgstr "" #: ../generalpurpose-user-requirements.rst:62 msgid "No predefined usage model" msgstr "" #: ../generalpurpose-user-requirements.rst:65 msgid "" "By definition, a cloud provides end users with the ability to self-provision " "computing power, storage, networks, and software in a simple and flexible " "way. The user must be able to scale their resources up to a substantial " "level without disrupting the underlying host operations. One of the benefits " "of using a general purpose cloud architecture is the ability to start with " "limited resources and increase them over time as the user demand grows." msgstr "" #: ../generalpurpose-user-requirements.rst:71 msgid "On-demand and self-service application" msgstr "" #: ../generalpurpose-user-requirements.rst:74 msgid "" "For a company interested in building a commercial public cloud offering " "based on OpenStack, the general purpose architecture model might be the best " "choice. Designers are not always going to know the purposes or workloads for " "which the end users will use the cloud." msgstr "" #: ../generalpurpose-user-requirements.rst:77 msgid "Public cloud" msgstr "" #: ../generalpurpose-user-requirements.rst:80 msgid "" "Organizations need to determine if it is logical to create their own clouds " "internally. Using a private cloud, organizations are able to maintain " "complete control over architectural and cloud components." msgstr "" #: ../generalpurpose-user-requirements.rst:85 msgid "" "Users will want to combine using the internal cloud with access to an " "external cloud. If that case is likely, it might be worth exploring the " "possibility of taking a multi-cloud approach with regard to at least some of " "the architectural elements." msgstr "" #: ../generalpurpose-user-requirements.rst:90 msgid "" "Designs that incorporate the use of multiple clouds, such as a private cloud " "and a public cloud offering, are described in the \"Multi-Cloud\" scenario, " "see :doc:`multi-site`." msgstr "" #: ../generalpurpose-user-requirements.rst:92 msgid "Internal consumption (private) cloud" msgstr "" #: ../generalpurpose-user-requirements.rst:95 msgid "" "Security should be implemented according to asset, threat, and vulnerability " "risk assessment matrices. For cloud domains that require increased computer " "security, network security, or information security, a general purpose cloud " "is not considered an appropriate choice." msgstr "" #: ../generalpurpose.rst:3 msgid "General purpose" msgstr "" #: ../generalpurpose.rst:15 msgid "" "An OpenStack general purpose cloud is often considered a starting point for " "building a cloud deployment. They are designed to balance the components and " "do not emphasize any particular aspect of the overall computing environment. " "Cloud design must give equal weight to the compute, network, and storage " "components. General purpose clouds are found in private, public, and hybrid " "environments, lending themselves to many different use cases." msgstr "" #: ../generalpurpose.rst:25 msgid "" "General purpose clouds are homogeneous deployments. They are not suited to " "specialized environments or edge case situations." msgstr "" #: ../generalpurpose.rst:28 msgid "Common uses of a general purpose cloud include:" msgstr "" #: ../generalpurpose.rst:30 msgid "Providing a simple database" msgstr "" #: ../generalpurpose.rst:31 msgid "A web application runtime environment" msgstr "" #: ../generalpurpose.rst:32 msgid "A shared application development platform" msgstr "" #: ../generalpurpose.rst:33 msgid "Lab test bed" msgstr "" #: ../generalpurpose.rst:35 msgid "" "Use cases that benefit from scale-out rather than scale-up approaches are " "good candidates for general purpose cloud architecture." msgstr "" #: ../generalpurpose.rst:38 msgid "" "A general purpose cloud is designed to have a range of potential uses or " "functions; not specialized for specific use cases. General purpose " "architecture is designed to address 80% of potential use cases available. " "The infrastructure, in itself, is a specific use case, enabling it to be " "used as a base model for the design process." msgstr "" #: ../generalpurpose.rst:44 msgid "" "General purpose clouds are designed to be platforms that are suited for " "general purpose applications." msgstr "" #: ../generalpurpose.rst:47 msgid "" "General purpose clouds are limited to the most basic components, but they " "can include additional resources such as:" msgstr "" # #-#-#-#-# generalpurpose.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# massively-scalable.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../generalpurpose.rst:50 ../massively-scalable.rst:40 msgid "Virtual-machine disk image library" msgstr "" # #-#-#-#-# generalpurpose.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# massively-scalable.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../generalpurpose.rst:51 ../massively-scalable.rst:41 msgid "Raw block storage" msgstr "" # #-#-#-#-# generalpurpose.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# massively-scalable.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../generalpurpose.rst:52 ../massively-scalable.rst:42 msgid "File or object storage" msgstr "" # #-#-#-#-# generalpurpose.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# legal-security-requirements.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../generalpurpose.rst:53 ../legal-security-requirements.rst:178 msgid "Firewalls" msgstr "" #: ../generalpurpose.rst:54 msgid "Load balancers" msgstr "" #: ../generalpurpose.rst:55 msgid "IP addresses" msgstr "" #: ../generalpurpose.rst:56 msgid "Network overlays or virtual local area networks (VLANs)" msgstr "" # #-#-#-#-# generalpurpose.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# massively-scalable.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../generalpurpose.rst:57 ../massively-scalable.rst:47 msgid "Software bundles" msgstr "" #: ../hybrid-architecture.rst:5 msgid "" "Map out the dependencies of the expected workloads and the cloud " "infrastructures required to support them to architect a solution for the " "broadest compatibility between cloud platforms, minimizing the need to " "create workarounds and processes to fill identified gaps." msgstr "" #: ../hybrid-architecture.rst:10 msgid "" "For your chosen cloud management platform, note the relative levels of " "support for both monitoring and orchestration." msgstr "" # #-#-#-#-# hybrid-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# hybrid-technical-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../hybrid-architecture.rst:17 ../hybrid-technical-considerations.rst:150 msgid "Image portability" msgstr "" #: ../hybrid-architecture.rst:19 msgid "" "The majority of cloud workloads currently run on instances using hypervisor " "technologies. The challenge is that each of these hypervisors uses an image " "format that may not be compatible with the others. When possible, " "standardize on a single hypervisor and instance image format. This may not " "be possible when using externally-managed public clouds." msgstr "" #: ../hybrid-architecture.rst:25 msgid "" "Conversion tools exist to address image format compatibility. Examples " "include `virt-p2v/virt-v2v `_ and `virt-edit " "`_. These tools cannot serve beyond " "basic cloud instance specifications." msgstr "" #: ../hybrid-architecture.rst:30 msgid "" "Alternatively, build a thin operating system image as the base for new " "instances. This facilitates rapid creation of cloud instances using cloud " "orchestration or configuration management tools for more specific " "templating. Remember if you intend to use portable images for disaster " "recovery, application diversity, or high availability, your users could move " "the images and instances between cloud platforms regularly." msgstr "" #: ../hybrid-architecture.rst:39 msgid "Upper-layer services" msgstr "" #: ../hybrid-architecture.rst:41 msgid "" "Many clouds offer complementary services beyond the basic compute, network, " "and storage components. These additional services often simplify the " "deployment and management of applications on a cloud platform." msgstr "" #: ../hybrid-architecture.rst:46 msgid "" "When moving workloads from the source to the destination cloud platforms, " "consider that the destination cloud platform may not have comparable " "services. Implement workloads in a different way or by using a different " "technology." msgstr "" #: ../hybrid-architecture.rst:51 msgid "" "For example, moving an application that uses a NoSQL database service such " "as MongoDB could cause difficulties in maintaining the application between " "the platforms." msgstr "" #: ../hybrid-architecture.rst:55 msgid "" "There are a number of options that are appropriate for the hybrid cloud use " "case:" msgstr "" #: ../hybrid-architecture.rst:58 msgid "" "Implementing a baseline of upper-layer services across all of the cloud " "platforms. For platforms that do not support a given service, create a " "service on top of that platform and apply it to the workloads as they are " "launched on that cloud." msgstr "" #: ../hybrid-architecture.rst:62 msgid "" "For example, through the :term:`Database service` for OpenStack (:term:" "`trove`), OpenStack supports MySQL as a service but not NoSQL databases in " "production. To move from or run alongside AWS, a NoSQL workload must use an " "automation tool, such as the Orchestration service (heat), to recreate the " "NoSQL database on top of OpenStack." msgstr "" #: ../hybrid-architecture.rst:68 msgid "" "Deploying a :term:`Platform-as-a-Service (PaaS)` technology that abstracts " "the upper-layer services from the underlying cloud platform. The unit of " "application deployment and migration is the PaaS. It leverages the services " "of the PaaS and only consumes the base infrastructure services of the cloud " "platform." msgstr "" #: ../hybrid-architecture.rst:73 msgid "" "Using automation tools to create the required upper-layer services that are " "portable across all cloud platforms." msgstr "" #: ../hybrid-architecture.rst:76 msgid "" "For example, instead of using database services that are inherent in the " "cloud platforms, launch cloud instances and deploy the databases on those " "instances using scripts or configuration and application deployment tools." msgstr "" #: ../hybrid-architecture.rst:82 msgid "Network services" msgstr "" #: ../hybrid-architecture.rst:84 msgid "" "Network services functionality is a critical component of multiple cloud " "architectures. It is an important factor to assess when choosing a CMP and " "cloud provider. Considerations include:" msgstr "" #: ../hybrid-architecture.rst:89 msgid "Functionality" msgstr "" #: ../hybrid-architecture.rst:92 msgid "High availability (HA)" msgstr "" #: ../hybrid-architecture.rst:94 msgid "Verify and test critical cloud endpoint features." msgstr "" #: ../hybrid-architecture.rst:96 msgid "" "After selecting the network functionality framework, you must confirm the " "functionality is compatible. This ensures testing and functionality persists " "during and after upgrades." msgstr "" #: ../hybrid-architecture.rst:103 msgid "" "Diverse cloud platforms may de-synchronize over time if you do not maintain " "their mutual compatibility. This is a particular issue with APIs." msgstr "" #: ../hybrid-architecture.rst:107 msgid "" "Scalability across multiple cloud providers determines your choice of " "underlying network framework. It is important to have the network API " "functions presented and to verify that the desired functionality persists " "across all chosen cloud endpoint." msgstr "" #: ../hybrid-architecture.rst:113 msgid "" "High availability implementations vary in functionality and design. Examples " "of some common methods are active-hot-standby, active-passive, and active-" "active. Develop your high availability implementation and a test framework " "to understand the functionality and limitations of the environment." msgstr "" #: ../hybrid-architecture.rst:119 msgid "" "It is imperative to address security considerations. For example, addressing " "how data is secured between client and endpoint and any traffic that " "traverses the multiple clouds. Business and regulatory requirements dictate " "what security approach to take. For more information, see the :ref:`Security " "requirements ` chapter." msgstr "" #: ../hybrid-architecture.rst:129 msgid "" "Traditionally, replication has been the best method of protecting object " "store implementations. A variety of replication methods exist in storage " "architectures, for example synchronous and asynchronous mirroring. Most " "object stores and back-end storage systems implement methods for replication " "at the storage subsystem layer. Object stores also tailor replication " "techniques to fit a cloud's requirements." msgstr "" #: ../hybrid-architecture.rst:137 msgid "" "Organizations must find the right balance between data integrity and data " "availability. Replication strategy may also influence disaster recovery " "methods." msgstr "" #: ../hybrid-architecture.rst:141 msgid "" "Replication across different racks, data centers, and geographical regions " "increases focus on determining and ensuring data locality. The ability to " "guarantee data is accessed from the nearest or fastest storage can be " "necessary for applications to perform well." msgstr "" #: ../hybrid-architecture.rst:148 msgid "" "When running embedded object store methods, ensure that you do not instigate " "extra data replication as this can cause performance issues." msgstr "" #: ../hybrid-operational-considerations.rst:5 msgid "" "Hybrid cloud deployments present complex operational challenges. Differences " "between provider clouds can cause incompatibilities with workloads or Cloud " "Management Platforms (CMP). Cloud providers may also offer different levels " "of integration with competing cloud offerings." msgstr "" #: ../hybrid-operational-considerations.rst:11 msgid "" "Monitoring is critical to maintaining a hybrid cloud, and it is important to " "determine if a CMP supports monitoring of all the clouds involved, or if " "compatible APIs are available to be queried for necessary information." msgstr "" #: ../hybrid-operational-considerations.rst:17 msgid "Agility" msgstr "" #: ../hybrid-operational-considerations.rst:19 msgid "" "Hybrid clouds provide application availability across different cloud " "environments and technologies. This availability enables the deployment to " "survive disaster in any single cloud environment. Each cloud should provide " "the means to create instances quickly in response to capacity issues or " "failure elsewhere in the hybrid cloud." msgstr "" # #-#-#-#-# hybrid-operational-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# multi-site-user-requirements.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../hybrid-operational-considerations.rst:27 #: ../multi-site-user-requirements.rst:90 msgid "Application readiness" msgstr "" #: ../hybrid-operational-considerations.rst:29 msgid "" "Enterprise workloads that depend on the underlying infrastructure for " "availability are not designed to run on OpenStack. If the application cannot " "tolerate infrastructure failures, it is likely to require significant " "operator intervention to recover. Applications for hybrid clouds must be " "fault tolerant, with an SLA that is not tied to the underlying " "infrastructure. Ideally, cloud applications should be able to recover when " "entire racks and data centers experience an outage." msgstr "" # #-#-#-#-# hybrid-operational-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# multi-site-operational-considerations.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../hybrid-operational-considerations.rst:39 #: ../multi-site-operational-considerations.rst:60 msgid "Upgrades" msgstr "" #: ../hybrid-operational-considerations.rst:41 msgid "" "If a deployment includes a public cloud, predicting upgrades may not be " "possible. Carefully examine provider SLAs." msgstr "" #: ../hybrid-operational-considerations.rst:46 msgid "" "At massive scale, even when dealing with a cloud that offers an SLA with a " "high percentage of uptime, workloads must be able to recover quickly." msgstr "" #: ../hybrid-operational-considerations.rst:50 msgid "" "When upgrading private cloud deployments, minimize disruption by making " "incremental changes and providing a facility to either rollback or continue " "to roll forward when using a continuous delivery model." msgstr "" #: ../hybrid-operational-considerations.rst:54 msgid "" "You may need to coordinate CMP upgrades with hybrid cloud upgrades if there " "are API changes." msgstr "" #: ../hybrid-operational-considerations.rst:58 msgid "Network Operation Center" msgstr "" #: ../hybrid-operational-considerations.rst:60 msgid "" "Consider infrastructure control when planning the Network Operation Center " "(NOC) for a hybrid cloud environment. If a significant portion of the cloud " "is on externally managed systems, prepare for situations where it may not be " "possible to make changes. Additionally, providers may differ on how " "infrastructure must be managed and exposed. This can lead to delays in root " "cause analysis where each insists the blame lies with the other provider." msgstr "" #: ../hybrid-operational-considerations.rst:68 msgid "" "Ensure that the network structure connects all clouds to form integrated " "system, keeping in mind the state of handoffs. These handoffs must both be " "as reliable as possible and include as little latency as possible to ensure " "the best performance of the overall system." msgstr "" #: ../hybrid-operational-considerations.rst:75 msgid "Maintainability" msgstr "" #: ../hybrid-operational-considerations.rst:77 msgid "" "Hybrid clouds rely on third party systems and processes. As a result, it is " "not possible to guarantee proper maintenance of the overall system. Instead, " "be prepared to abandon workloads and recreate them in an improved state." msgstr "" #: ../hybrid-prescriptive-examples.rst:5 msgid "Hybrid cloud environments are designed for these use cases:" msgstr "" #: ../hybrid-prescriptive-examples.rst:7 msgid "Bursting workloads from private to public OpenStack clouds" msgstr "" #: ../hybrid-prescriptive-examples.rst:8 msgid "Bursting workloads from private to public non-OpenStack clouds" msgstr "" #: ../hybrid-prescriptive-examples.rst:9 msgid "High availability across clouds (for technical diversity)" msgstr "" #: ../hybrid-prescriptive-examples.rst:11 msgid "" "This chapter provides examples of environments that address each of these " "use cases." msgstr "" #: ../hybrid-prescriptive-examples.rst:15 msgid "Bursting to a public OpenStack cloud" msgstr "" #: ../hybrid-prescriptive-examples.rst:17 msgid "" "Company A's data center is running low on capacity. It is not possible to " "expand the data center in the foreseeable future. In order to accommodate " "the continuously growing need for development resources in the organization, " "Company A decides to use resources in the public cloud." msgstr "" #: ../hybrid-prescriptive-examples.rst:23 msgid "" "Company A has an established data center with a substantial amount of " "hardware. Migrating the workloads to a public cloud is not feasible." msgstr "" #: ../hybrid-prescriptive-examples.rst:26 msgid "" "The company has an internal cloud management platform that directs requests " "to the appropriate cloud, depending on the local capacity. This is a custom " "in-house application written for this specific purpose." msgstr "" #: ../hybrid-prescriptive-examples.rst:30 msgid "This solution is depicted in the figure below:" msgstr "" #: ../hybrid-prescriptive-examples.rst:35 msgid "" "This example shows two clouds with a Cloud Management Platform (CMP) " "connecting them. This guide does not discuss a specific CMP, but describes " "how the Orchestration and Telemetry services handle, manage, and control " "workloads." msgstr "" #: ../hybrid-prescriptive-examples.rst:40 msgid "" "The private OpenStack cloud has at least one controller and at least one " "compute node. It includes metering using the Telemetry service. The " "Telemetry service captures the load increase and the CMP processes the " "information. If there is available capacity, the CMP uses the OpenStack API " "to call the Orchestration service. This creates instances on the private " "cloud in response to user requests. When capacity is not available on the " "private cloud, the CMP issues a request to the Orchestration service API of " "the public cloud. This creates the instance on the public cloud." msgstr "" #: ../hybrid-prescriptive-examples.rst:50 msgid "" "In this example, Company A does not direct the deployments to an external " "public cloud due to concerns regarding resource control, security, and " "increased operational expense." msgstr "" #: ../hybrid-prescriptive-examples.rst:55 msgid "Bursting to a public non-OpenStack cloud" msgstr "" #: ../hybrid-prescriptive-examples.rst:57 msgid "" "The second example examines bursting workloads from the private cloud into a " "non-OpenStack public cloud using Amazon Web Services (AWS) to take advantage " "of additional capacity and to scale applications." msgstr "" #: ../hybrid-prescriptive-examples.rst:61 msgid "The following diagram demonstrates an OpenStack-to-AWS hybrid cloud:" msgstr "" #: ../hybrid-prescriptive-examples.rst:66 msgid "" "Company B states that its developers are already using AWS and do not want " "to change to a different provider." msgstr "" #: ../hybrid-prescriptive-examples.rst:69 msgid "" "If the CMP is capable of connecting to an external cloud provider with an " "appropriate API, the workflow process remains the same as the previous " "scenario. The actions the CMP takes, such as monitoring loads and creating " "new instances, stay the same. However, the CMP performs actions in the " "public cloud using applicable API calls." msgstr "" #: ../hybrid-prescriptive-examples.rst:77 msgid "" "If the public cloud is AWS, the CMP would use the EC2 API to create a new " "instance and assign an Elastic IP. It can then add that IP to HAProxy in the " "private cloud. The CMP can also reference AWS-specific tools such as " "CloudWatch and CloudFormation." msgstr "" #: ../hybrid-prescriptive-examples.rst:83 msgid "" "Several open source tool kits for building CMPs are available and can handle " "this kind of translation. Examples include ManageIQ, jClouds, and JumpGate." msgstr "" #: ../hybrid-prescriptive-examples.rst:88 msgid "High availability and disaster recovery" msgstr "" #: ../hybrid-prescriptive-examples.rst:90 msgid "" "Company C requires their local data center to be able to recover from " "failure. Some of the workloads currently in use are running on their " "private OpenStack cloud. Protecting the data involves Block Storage, Object " "Storage, and a database. The architecture supports the failure of large " "components of the system while ensuring that the system continues to deliver " "services. While the services remain available to users, the failed " "components are restored in the background based on standard best practice " "data replication policies. To achieve these objectives, Company C replicates " "data to a second cloud in a geographically distant location. The following " "diagram describes this system:" msgstr "" #: ../hybrid-prescriptive-examples.rst:107 msgid "" "This example includes two private OpenStack clouds connected with a CMP. The " "source cloud, OpenStack Cloud 1, includes a controller and at least one " "instance running MySQL. It also includes at least one Block Storage volume " "and one Object Storage volume. This means that data is available to the " "users at all times. The details of the method for protecting each of these " "sources of data differs." msgstr "" #: ../hybrid-prescriptive-examples.rst:115 msgid "" "Object Storage relies on the replication capabilities of the Object Storage " "provider. Company C enables OpenStack Object Storage so that it creates " "geographically separated replicas that take advantage of this feature. The " "company configures storage so that at least one replica exists in each " "cloud. In order to make this work, the company configures a single array " "spanning both clouds with OpenStack Identity. Using Federated Identity, the " "array talks to both clouds, communicating with OpenStack Object Storage " "through the Swift proxy." msgstr "" #: ../hybrid-prescriptive-examples.rst:125 msgid "" "For Block Storage, the replication is a little more difficult, and involves " "tools outside of OpenStack itself. The OpenStack Block Storage volume is not " "set as the drive itself but as a logical object that points to a physical " "back end. Disaster recovery is configured for Block Storage for synchronous " "backup for the highest level of data protection, but asynchronous backup " "could have been set as an alternative that is not as latency sensitive. For " "asynchronous backup, the Block Storage API makes it possible to export the " "data and also the metadata of a particular volume, so that it can be moved " "and replicated elsewhere. More information can be found here: https://" "blueprints.launchpad.net/cinder/+spec/cinder-backup-volume-metadata-support." msgstr "" #: ../hybrid-prescriptive-examples.rst:139 msgid "" "The synchronous backups create an identical volume in both clouds and " "chooses the appropriate flavor so that each cloud has an identical back end. " "This is done by creating volumes through the CMP. After this is configured, " "a solution involving DRDB synchronizes the physical drives." msgstr "" #: ../hybrid-prescriptive-examples.rst:145 msgid "" "The database component is backed up using synchronous backups. MySQL does " "not support geographically diverse replication, so disaster recovery is " "provided by replicating the file itself. As it is not possible to use Object " "Storage as the back end of a database like MySQL, Swift replication is not " "an option. Company C decides not to store the data on another geo-tiered " "storage system, such as Ceph, as Block Storage. This would have given " "another layer of protection. Another option would have been to store the " "database on an OpenStack Block Storage volume and backing it up like any " "other Block Storage." msgstr "" #: ../hybrid-technical-considerations.rst:5 msgid "" "A hybrid cloud environment requires inspection and understanding of " "technical issues in external data centers that may not be in your control. " "Ideally, select an architecture and CMP that are adaptable to changing " "environments." msgstr "" #: ../hybrid-technical-considerations.rst:10 msgid "" "Using diverse cloud platforms increases the risk of compatibility issues, " "but clouds using the same version and distribution of OpenStack are less " "likely to experience problems." msgstr "" #: ../hybrid-technical-considerations.rst:14 msgid "" "Clouds that exclusively use the same versions of OpenStack should have no " "issues, regardless of distribution. More recent distributions are less " "likely to encounter incompatibility between versions. An OpenStack community " "initiative defines core functions that need to remain backward compatible " "between supported versions. For example, the DefCore initiative defines " "basic functions that every distribution must support in order to use the " "name OpenStack." msgstr "" #: ../hybrid-technical-considerations.rst:22 msgid "" "Vendors can add proprietary customization to their distributions. If an " "application or architecture makes use of these features, it can be difficult " "to migrate to or use other types of environments." msgstr "" #: ../hybrid-technical-considerations.rst:26 msgid "" "If an environment includes non-OpenStack clouds, it may experience " "compatibility problems. CMP tools must account for the differences in the " "handling of operations and the implementation of services." msgstr "" #: ../hybrid-technical-considerations.rst:30 msgid "**Possible cloud incompatibilities**" msgstr "" #: ../hybrid-technical-considerations.rst:32 msgid "Instance deployment" msgstr "" #: ../hybrid-technical-considerations.rst:33 msgid "Network management" msgstr "" #: ../hybrid-technical-considerations.rst:34 msgid "Application management" msgstr "" #: ../hybrid-technical-considerations.rst:35 msgid "Services implementation" msgstr "" #: ../hybrid-technical-considerations.rst:40 msgid "" "One of the primary reasons many organizations use a hybrid cloud is to " "increase capacity without making large capital investments." msgstr "" #: ../hybrid-technical-considerations.rst:43 msgid "" "Capacity and the placement of workloads are key design considerations for " "hybrid clouds. The long-term capacity plan for these designs must " "incorporate growth over time to prevent permanent consumption of more " "expensive external clouds. To avoid this scenario, account for future " "applications' capacity requirements and plan growth appropriately." msgstr "" #: ../hybrid-technical-considerations.rst:50 msgid "" "It is difficult to predict the amount of load a particular application might " "incur if the number of users fluctuates, or the application experiences an " "unexpected increase in use. It is possible to define application " "requirements in terms of vCPU, RAM, bandwidth, or other resources and plan " "appropriately. However, other clouds might not use the same meter or even " "the same oversubscription rates." msgstr "" #: ../hybrid-technical-considerations.rst:58 msgid "" "Oversubscription is a method to emulate more capacity than may physically be " "present. For example, a physical hypervisor node with 32 GB RAM may host 24 " "instances, each provisioned with 2 GB RAM. As long as all 24 instances do " "not concurrently use 2 full gigabytes, this arrangement works well. However, " "some hosts take oversubscription to extremes and, as a result, performance " "can be inconsistent. If at all possible, determine what the oversubscription " "rates of each host are and plan capacity accordingly." msgstr "" #: ../hybrid-technical-considerations.rst:72 msgid "" "A CMP must be aware of what workloads are running, where they are running, " "and their preferred utilizations. For example, in most cases it is desirable " "to run as many workloads internally as possible, utilizing other resources " "only when necessary. On the other hand, situations exist in which the " "opposite is true, such as when an internal cloud is only for development and " "stressing it is undesirable. A cost model of various scenarios and " "consideration of internal priorities helps with this decision. To improve " "efficiency, automate these decisions when possible." msgstr "" #: ../hybrid-technical-considerations.rst:82 msgid "" "The Telemetry service (ceilometer) provides information on the usage of " "various OpenStack components. Note the following:" msgstr "" #: ../hybrid-technical-considerations.rst:85 msgid "" "If Telemetry must retain a large amount of data, for example when monitoring " "a large or active cloud, we recommend using a NoSQL back end such as MongoDB." msgstr "" #: ../hybrid-technical-considerations.rst:88 msgid "" "You must monitor connections to non-OpenStack clouds and report this " "information to the CMP." msgstr "" #: ../hybrid-technical-considerations.rst:94 msgid "" "Performance is critical to hybrid cloud deployments, and they are affected " "by many of the same issues as multi-site deployments, such as network " "latency between sites. Also consider the time required to run a workload in " "different clouds and methods for reducing this time. This may require moving " "data closer to applications or applications closer to the data they process, " "and grouping functionality so that connections that require low latency take " "place over a single cloud rather than spanning clouds. This may also require " "a CMP that can determine which cloud can most efficiently run which types of " "workloads." msgstr "" #: ../hybrid-technical-considerations.rst:105 msgid "" "As with utilization, native OpenStack tools help improve performance. For " "example, you can use Telemetry to measure performance and the Orchestration " "service (heat) to react to changes in demand." msgstr "" #: ../hybrid-technical-considerations.rst:111 msgid "" "Orchestration requires special client configurations to integrate with " "Amazon Web Services. For other types of clouds, use CMP features." msgstr "" #: ../hybrid-technical-considerations.rst:115 msgid "Components" msgstr "" #: ../hybrid-technical-considerations.rst:117 msgid "" "Using more than one cloud in any design requires consideration of four " "OpenStack tools:" msgstr "" #: ../hybrid-technical-considerations.rst:121 msgid "" "Regardless of deployment location, hypervisor choice has a direct effect on " "how difficult it is to integrate with additional clouds." msgstr "" #: ../hybrid-technical-considerations.rst:122 msgid "OpenStack Compute (nova)" msgstr "" #: ../hybrid-technical-considerations.rst:125 msgid "" "Whether using OpenStack Networking (neutron) or legacy networking (nova-" "network), it is necessary to understand network integration capabilities in " "order to connect between clouds." msgstr "" #: ../hybrid-technical-considerations.rst:130 msgid "" "Use of Telemetry depends, in large part, on what the other parts of the " "cloud you are using." msgstr "" #: ../hybrid-technical-considerations.rst:131 msgid "Telemetry (ceilometer)" msgstr "" #: ../hybrid-technical-considerations.rst:134 msgid "" "Orchestration can be a valuable tool in orchestrating tasks a CMP decides " "are necessary in an OpenStack-based cloud." msgstr "" #: ../hybrid-technical-considerations.rst:138 msgid "Special considerations" msgstr "" #: ../hybrid-technical-considerations.rst:140 msgid "" "Hybrid cloud deployments require consideration of two issues that are not " "common in other situations:" msgstr "" #: ../hybrid-technical-considerations.rst:144 msgid "" "As of the Kilo release, there is no common image format that is usable by " "all clouds. Conversion or recreation of images is necessary if migrating " "between clouds. To simplify deployment, use the smallest and simplest images " "feasible, install only what is necessary, and use a deployment manager such " "as Chef or Puppet. Do not use golden images to speed up the process unless " "you repeatedly deploy the same images on the same cloud." msgstr "" #: ../hybrid-technical-considerations.rst:153 msgid "" "Avoid using a hybrid cloud deployment with more than just OpenStack (or with " "different versions of OpenStack) as API changes can cause compatibility " "issues." msgstr "" #: ../hybrid-technical-considerations.rst:154 msgid "API differences" msgstr "" #: ../hybrid-user-requirements.rst:5 msgid "" "Hybrid cloud architectures are complex, especially those that use " "heterogeneous cloud platforms. Ensure that design choices match requirements " "so that the benefits outweigh the inherent additional complexity and risks." msgstr "" #: ../hybrid-user-requirements.rst:11 msgid "Business considerations" msgstr "" #: ../hybrid-user-requirements.rst:14 msgid "Business considerations when designing a hybrid cloud deployment" msgstr "" #: ../hybrid-user-requirements.rst:17 msgid "" "A hybrid cloud architecture involves multiple vendors and technical " "architectures. These architectures may be more expensive to deploy and " "maintain. Operational costs can be higher because of the need for more " "sophisticated orchestration and brokerage tools than in other architectures. " "In contrast, overall operational costs might be lower by virtue of using a " "cloud brokerage tool to deploy the workloads to the most cost effective " "platform." msgstr "" #: ../hybrid-user-requirements.rst:27 msgid "" "Revenue opportunities vary based on the intent and use case of the cloud. As " "a commercial, customer-facing product, you must consider whether building " "over multiple platforms makes the design more attractive to customers." msgstr "" #: ../hybrid-user-requirements.rst:32 msgid "" "One common reason to use cloud platforms is to improve the time-to-market of " "a new product or application. For example, using multiple cloud platforms is " "viable because there is an existing investment in several applications. It " "is faster to tie the investments together rather than migrate the components " "and refactoring them to a single platform." msgstr "" #: ../hybrid-user-requirements.rst:37 msgid "Time-to-market" msgstr "" #: ../hybrid-user-requirements.rst:40 msgid "" "Organizations leveraging cloud-based services can embrace business diversity " "and utilize a hybrid cloud design to spread their workloads across multiple " "cloud providers. This ensures that no single cloud provider is the sole " "host for an application." msgstr "" #: ../hybrid-user-requirements.rst:43 msgid "Business or technical diversity" msgstr "" #: ../hybrid-user-requirements.rst:46 msgid "" "Businesses with existing applications may find that it is more cost " "effective to integrate applications on multiple cloud platforms than " "migrating them to a single platform." msgstr "" #: ../hybrid-user-requirements.rst:48 msgid "Application momentum" msgstr "" #: ../hybrid-user-requirements.rst:51 msgid "Workload considerations" msgstr "" #: ../hybrid-user-requirements.rst:53 msgid "" "A workload can be a single application or a suite of applications that work " "together. It can also be a duplicate set of applications that need to run on " "multiple cloud environments. In a hybrid cloud deployment, the same workload " "often needs to function equally well on radically different public and " "private cloud environments. The architecture needs to address these " "potential conflicts, complexity, and platform incompatibilities." msgstr "" #: ../hybrid-user-requirements.rst:62 msgid "Use cases for a hybrid cloud architecture" msgstr "" #: ../hybrid-user-requirements.rst:65 msgid "" "An application that requires additional resources may suit a multiple cloud " "architecture. For example, a retailer needs additional resources during the " "holiday season, but does not want to add private cloud resources to meet the " "peak demand. The user can accommodate the increased load by bursting to a " "public cloud for these peak load periods. These bursts could be for long or " "short cycles ranging from hourly to yearly." msgstr "" #: ../hybrid-user-requirements.rst:71 msgid "Dynamic resource expansion or bursting" msgstr "" #: ../hybrid-user-requirements.rst:74 msgid "" "Cheaper storage makes the public cloud suitable for maintaining backup " "applications." msgstr "" #: ../hybrid-user-requirements.rst:75 msgid "Disaster recovery and business continuity" msgstr "" #: ../hybrid-user-requirements.rst:78 msgid "" "Adding self-service, charge back, and transparent delivery of the resources " "from a federated pool can be cost effective. In a hybrid cloud environment, " "this is a particularly important consideration. Look for a cloud that " "provides cross-platform hypervisor support and robust instance management " "tools." msgstr "" #: ../hybrid-user-requirements.rst:82 msgid "Federated hypervisor and instance management" msgstr "" #: ../hybrid-user-requirements.rst:85 msgid "" "An enterprise cloud delivers efficient application portfolio management and " "deployments by leveraging self-service features and rules according to use. " "Integrating existing cloud environments is a common driver when building " "hybrid cloud architectures." msgstr "" #: ../hybrid-user-requirements.rst:89 msgid "Application portfolio integration" msgstr "" #: ../hybrid-user-requirements.rst:92 msgid "" "Hybrid cloud architecture enables the migration of applications between " "different clouds." msgstr "" #: ../hybrid-user-requirements.rst:93 msgid "Migration scenarios" msgstr "" #: ../hybrid-user-requirements.rst:96 msgid "" "A combination of locations and platforms enables a level of availability " "that is not possible with a single platform. This approach increases design " "complexity." msgstr "" # #-#-#-#-# hybrid-user-requirements.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# multi-site-user-requirements.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# network-focus.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../hybrid-user-requirements.rst:98 ../multi-site-user-requirements.rst:46 #: ../network-focus.rst:63 msgid "High availability" msgstr "" #: ../hybrid-user-requirements.rst:100 msgid "" "As running a workload on multiple cloud platforms increases design " "complexity, we recommend first exploring options such as transferring " "workloads across clouds at the application, instance, cloud platform, " "hypervisor, and network levels." msgstr "" #: ../hybrid-user-requirements.rst:106 msgid "Tools considerations" msgstr "" #: ../hybrid-user-requirements.rst:108 msgid "" "Hybrid cloud designs must incorporate tools to facilitate working across " "multiple clouds." msgstr "" #: ../hybrid-user-requirements.rst:112 msgid "Tool functions" msgstr "" #: ../hybrid-user-requirements.rst:115 msgid "" "Brokering software evaluates relative costs between different cloud " "platforms. Cloud Management Platforms (CMP) allow the designer to determine " "the right location for the workload based on predetermined criteria." msgstr "" #: ../hybrid-user-requirements.rst:118 msgid "Broker between clouds" msgstr "" #: ../hybrid-user-requirements.rst:121 msgid "" "CMPs simplify the migration of application workloads between public, " "private, and hybrid cloud platforms. We recommend using cloud orchestration " "tools for managing a diverse portfolio of systems and applications across " "multiple cloud platforms." msgstr "" #: ../hybrid-user-requirements.rst:124 msgid "Facilitate orchestration across the clouds" msgstr "" #: ../hybrid-user-requirements.rst:127 msgid "Network considerations" msgstr "" #: ../hybrid-user-requirements.rst:129 msgid "" "It is important to consider the functionality, security, scalability, " "availability, and testability of network when choosing a CMP and cloud " "provider." msgstr "" #: ../hybrid-user-requirements.rst:133 msgid "" "Decide on a network framework and design minimum functionality tests. This " "ensures testing and functionality persists during and after upgrades." msgstr "" #: ../hybrid-user-requirements.rst:136 msgid "" "Scalability across multiple cloud providers may dictate which underlying " "network framework you choose in different cloud providers. It is important " "to present the network API functions and to verify that functionality " "persists across all cloud endpoints chosen." msgstr "" #: ../hybrid-user-requirements.rst:140 msgid "" "High availability implementations vary in functionality and design. Examples " "of some common methods are active-hot-standby, active-passive, and active-" "active. Development of high availability and test frameworks is necessary to " "insure understanding of functionality and limitations." msgstr "" #: ../hybrid-user-requirements.rst:145 msgid "" "Consider the security of data between the client and the endpoint, and of " "traffic that traverses the multiple clouds." msgstr "" #: ../hybrid-user-requirements.rst:149 msgid "Risk mitigation and management considerations" msgstr "" #: ../hybrid-user-requirements.rst:151 msgid "" "Hybrid cloud architectures introduce additional risk because they are more " "complex than a single cloud design and may involve incompatible components " "or tools. However, they also reduce risk by spreading workloads over " "multiple providers." msgstr "" #: ../hybrid-user-requirements.rst:157 msgid "Hybrid cloud risks" msgstr "" #: ../hybrid-user-requirements.rst:160 msgid "" "Business changes can affect provider availability. Likewise, changes in a " "provider's service can disrupt a hybrid cloud environment or increase costs." msgstr "" #: ../hybrid-user-requirements.rst:162 msgid "Provider availability or implementation details" msgstr "" #: ../hybrid-user-requirements.rst:165 msgid "" "Hybrid cloud designs must accommodate differences in SLAs between providers, " "and consider their enforceability." msgstr "" #: ../hybrid-user-requirements.rst:166 msgid "Differing SLAs" msgstr "" #: ../hybrid-user-requirements.rst:169 msgid "" "Securing multiple cloud environments is more complex than securing single " "cloud environments. We recommend addressing concerns at the application, " "network, and cloud platform levels. Be aware that each cloud platform " "approaches security differently, and a hybrid cloud design must address and " "compensate for these differences." msgstr "" #: ../hybrid-user-requirements.rst:173 msgid "Security levels" msgstr "" #: ../hybrid-user-requirements.rst:176 msgid "" "Consumers of external clouds rarely have control over provider changes to " "APIs, and changes can break compatibility. Using only the most common and " "basic APIs can minimize potential conflicts." msgstr "" #: ../hybrid-user-requirements.rst:177 msgid "Provider API changes" msgstr "" #: ../hybrid.rst:3 msgid "Hybrid" msgstr "" #: ../hybrid.rst:14 msgid "" "A :term:`hybrid cloud` design is one that uses more than one cloud. For " "example, designs that use both an OpenStack-based private cloud and an " "OpenStack-based public cloud, or that use an OpenStack cloud and a non-" "OpenStack cloud, are hybrid clouds." msgstr "" #: ../hybrid.rst:19 msgid "" ":term:`Bursting ` describes the practice of creating new instances " "in an external cloud to alleviate capacity issues in a private cloud." msgstr "" #: ../hybrid.rst:22 msgid "**Example scenarios suited to hybrid clouds**" msgstr "" #: ../hybrid.rst:24 msgid "Bursting from a private cloud to a public cloud" msgstr "" #: ../hybrid.rst:25 msgid "Disaster recovery" msgstr "" #: ../hybrid.rst:26 msgid "Development and testing" msgstr "" #: ../hybrid.rst:27 msgid "" "Federated cloud, enabling users to choose resources from multiple providers" msgstr "" #: ../hybrid.rst:28 msgid "Supporting legacy systems as they transition to the cloud" msgstr "" #: ../hybrid.rst:30 msgid "" "Hybrid clouds interact with systems that are outside the control of the " "private cloud administrator, and require careful architecture to prevent " "conflicts with hardware, software, and APIs under external control." msgstr "" #: ../hybrid.rst:35 msgid "" "The degree to which the architecture is OpenStack-based affects your ability " "to accomplish tasks with native OpenStack tools. By definition, this is a " "situation in which no single cloud can provide all of the necessary " "functionality. In order to manage the entire system, we recommend using a " "cloud management platform (CMP)." msgstr "" #: ../hybrid.rst:41 msgid "" "There are several commercial and open source CMPs available, but there is no " "single CMP that can address all needs in all scenarios, and sometimes a " "manually-built solution is the best option. This chapter includes discussion " "of using CMPs for managing a hybrid cloud." msgstr "" #: ../index.rst:8 msgid "OpenStack Architecture Design Guide" msgstr "" #: ../index.rst:11 msgid "Abstract" msgstr "" #: ../index.rst:13 msgid "" "To reap the benefits of OpenStack, you should plan, design, and architect " "your cloud properly, taking user's needs into account and understanding the " "use cases." msgstr "" #: ../index.rst:18 msgid "Contents" msgstr "" #: ../index.rst:42 msgid "Search in this guide" msgstr "" #: ../index.rst:44 msgid ":ref:`search`" msgstr "" #: ../introduction-how-this-book-is-organized.rst:2 msgid "How this book is organized" msgstr "" #: ../introduction-how-this-book-is-organized.rst:4 msgid "" "This book examines some of the most common uses for OpenStack clouds, and " "explains the considerations for each use case. Cloud architects may use this " "book as a comprehensive guide by reading all of the use cases, but it is " "also possible to review only the chapters which pertain to a specific use " "case. The use cases covered in this guide include:" msgstr "" #: ../introduction-how-this-book-is-organized.rst:10 msgid "" ":doc:`General purpose`: Uses common components that address " "80% of common use cases." msgstr "" #: ../introduction-how-this-book-is-organized.rst:13 msgid "" ":doc:`Compute focused`: For compute intensive workloads such " "as high performance computing (HPC)." msgstr "" #: ../introduction-how-this-book-is-organized.rst:16 msgid "" ":doc:`Storage focused`: For storage intensive workloads such " "as data analytics with parallel file systems." msgstr "" #: ../introduction-how-this-book-is-organized.rst:19 msgid "" ":doc:`Network focused`: For high performance and reliable " "networking, such as a :term:`content delivery network (CDN)`." msgstr "" #: ../introduction-how-this-book-is-organized.rst:22 msgid "" ":doc:`Multi-site`: For applications that require multiple site " "deployments for geographical, reliability or data locality reasons." msgstr "" #: ../introduction-how-this-book-is-organized.rst:26 msgid "" ":doc:`Hybrid cloud`: Uses multiple disparate clouds connected either " "for failover, hybrid cloud bursting, or availability." msgstr "" #: ../introduction-how-this-book-is-organized.rst:29 msgid "" ":doc:`Massively scalable`: For cloud service providers " "or other large installations." msgstr "" #: ../introduction-how-this-book-is-organized.rst:32 msgid "" ":doc:`Specialized cases`: Architectures that have not " "previously been covered in the defined use cases." msgstr "" #: ../introduction-how-this-book-was-written.rst:2 msgid "Why and how we wrote this book" msgstr "" #: ../introduction-how-this-book-was-written.rst:4 msgid "" "We wrote this book to guide you through designing an OpenStack cloud " "architecture. This guide identifies design considerations for common cloud " "use cases and provides examples." msgstr "" #: ../introduction-how-this-book-was-written.rst:8 msgid "" "The Architecture Design Guide was written in a book sprint format, which is " "a facilitated, rapid development production method for books. The Book " "Sprint was facilitated by Faith Bosworth and Adam Hyde of Book Sprints, for " "more information, see the Book Sprints website (www.booksprints.net)." msgstr "" #: ../introduction-how-this-book-was-written.rst:14 msgid "" "This book was written in five days during July 2014 while exhausting the " "M&M, Mountain Dew and healthy options supply, complete with juggling " "entertainment during lunches at VMware's headquarters in Palo Alto." msgstr "" #: ../introduction-how-this-book-was-written.rst:18 msgid "" "We would like to thank VMware for their generous hospitality, as well as our " "employers, Cisco, Cloudscaling, Comcast, EMC, Mirantis, Rackspace, Red Hat, " "Verizon, and VMware, for enabling us to contribute our time. We would " "especially like to thank Anne Gentle and Kenneth Hui for all of their " "shepherding and organization in making this happen." msgstr "" #: ../introduction-how-this-book-was-written.rst:24 msgid "The author team includes:" msgstr "" #: ../introduction-how-this-book-was-written.rst:26 msgid "Kenneth Hui (EMC) `@hui\\_kenneth `__" msgstr "" #: ../introduction-how-this-book-was-written.rst:28 msgid "Alexandra Settle (Rackspace) `@dewsday `__" msgstr "" #: ../introduction-how-this-book-was-written.rst:31 msgid "Anthony Veiga (Comcast) `@daaelar `__" msgstr "" #: ../introduction-how-this-book-was-written.rst:33 msgid "Beth Cohen (Verizon) `@bfcohen `__" msgstr "" #: ../introduction-how-this-book-was-written.rst:35 msgid "" "Kevin Jackson (Rackspace) `@itarchitectkev `__" msgstr "" #: ../introduction-how-this-book-was-written.rst:38 msgid "Maish Saidel-Keesing (Cisco) `@maishsk `__" msgstr "" #: ../introduction-how-this-book-was-written.rst:41 msgid "Nick Chase (Mirantis) `@NickChase `__" msgstr "" #: ../introduction-how-this-book-was-written.rst:43 msgid "Scott Lowe (VMware) `@scott\\_lowe `__" msgstr "" #: ../introduction-how-this-book-was-written.rst:45 msgid "Sean Collins (Comcast) `@sc68cal `__" msgstr "" #: ../introduction-how-this-book-was-written.rst:47 msgid "Sean Winn (Cloudscaling) `@seanmwinn `__" msgstr "" #: ../introduction-how-this-book-was-written.rst:50 msgid "Sebastian Gutierrez (Red Hat) `@gutseb `__" msgstr "" #: ../introduction-how-this-book-was-written.rst:52 msgid "Stephen Gordon (Red Hat) `@xsgordon `__" msgstr "" #: ../introduction-how-this-book-was-written.rst:54 msgid "" "Vinny Valdez (Red Hat) `@VinnyValdez `__" msgstr "" #: ../introduction-intended-audience.rst:2 msgid "Intended audience" msgstr "" #: ../introduction-intended-audience.rst:4 msgid "" "This book has been written for architects and designers of OpenStack clouds. " "For a guide on deploying and operating OpenStack, please refer to the " "`OpenStack Operations Guide `_." msgstr "" #: ../introduction-intended-audience.rst:8 msgid "" "Before reading this book, we recommend prior knowledge of cloud architecture " "and principles, experience in enterprise system design, Linux and " "virtualization experience, and a basic understanding of networking " "principles and protocols." msgstr "" #: ../introduction-methodology.rst:2 msgid "Methodology" msgstr "" #: ../introduction-methodology.rst:4 msgid "" "The best way to design your cloud architecture is through creating and " "testing use cases. Planning for applications that support thousands of " "sessions per second, variable workloads, and complex, changing data, " "requires you to identify the key meters. Identifying these key meters, such " "as number of concurrent transactions per second, and size of database, makes " "it possible to build a method for testing your assumptions." msgstr "" #: ../introduction-methodology.rst:12 msgid "" "Use a functional user scenario to develop test cases, and to measure overall " "project trajectory." msgstr "" #: ../introduction-methodology.rst:17 msgid "" "If you do not want to use an application to develop user requirements " "automatically, you need to create requirements to build test harnesses and " "develop usable meters." msgstr "" #: ../introduction-methodology.rst:21 msgid "" "Establishing these meters allows you to respond to changes quickly without " "having to set exact requirements in advance. This creates ways to configure " "the system, rather than redesigning it every time there is a requirements " "change." msgstr "" #: ../introduction-methodology.rst:28 msgid "" "It is important to limit scope creep. Ensure you address tool limitations, " "but do not recreate the entire suite of tools. Work with technical product " "owners to establish critical features that are needed for a successful cloud " "deployment." msgstr "" #: ../introduction-methodology.rst:34 msgid "Application cloud readiness" msgstr "" #: ../introduction-methodology.rst:36 msgid "" "The cloud does more than host virtual machines and their applications. This " "*lift and shift* approach works in certain situations, but there is a " "fundamental difference between clouds and traditional bare-metal-based " "environments, or even traditional virtualized environments." msgstr "" #: ../introduction-methodology.rst:41 msgid "" "In traditional environments, with traditional enterprise applications, the " "applications and the servers that run on them are *pets*. They are lovingly " "crafted and cared for, the servers have names like Gandalf or Tardis, and if " "they get sick someone nurses them back to health. All of this is designed so " "that the application does not experience an outage." msgstr "" #: ../introduction-methodology.rst:47 msgid "" "In cloud environments, servers are more like cattle. There are thousands of " "them, they get names like NY-1138-Q, and if they get sick, they get put down " "and a sysadmin installs another one. Traditional applications that are " "unprepared for this kind of environment may suffer outages, loss of data, or " "complete failure." msgstr "" #: ../introduction-methodology.rst:53 msgid "" "There are other reasons to design applications with the cloud in mind. Some " "are defensive, such as the fact that because applications cannot be certain " "of exactly where or on what hardware they will be launched, they need to be " "flexible, or at least adaptable. Others are proactive. For example, one of " "the advantages of using the cloud is scalability. Applications need to be " "designed in such a way that they can take advantage of these and other " "opportunities." msgstr "" #: ../introduction-methodology.rst:62 msgid "Determining whether an application is cloud-ready" msgstr "" #: ../introduction-methodology.rst:64 msgid "" "There are several factors to take into consideration when looking at whether " "an application is a good fit for the cloud." msgstr "" #: ../introduction-methodology.rst:68 msgid "" "A large, monolithic, single-tiered, legacy application typically is not a " "good fit for the cloud. Efficiencies are gained when load can be spread over " "several instances, so that a failure in one part of the system can be " "mitigated without affecting other parts of the system, or so that scaling " "can take place where the app needs it." msgstr "" #: ../introduction-methodology.rst:72 msgid "Structure" msgstr "" #: ../introduction-methodology.rst:75 msgid "" "Applications that depend on specific hardware, such as a particular chip set " "or an external device such as a fingerprint reader, might not be a good fit " "for the cloud, unless those dependencies are specifically addressed. " "Similarly, if an application depends on an operating system or set of " "libraries that cannot be used in the cloud, or cannot be virtualized, that " "is a problem." msgstr "" # #-#-#-#-# introduction-methodology.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# multi-site-architecture.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../introduction-methodology.rst:80 ../multi-site-architecture.rst:102 msgid "Dependencies" msgstr "" #: ../introduction-methodology.rst:83 msgid "" "Self-contained applications, or those that depend on resources that are not " "reachable by the cloud in question, will not run. In some situations, you " "can work around these issues with custom network setup, but how well this " "works depends on the chosen cloud environment." msgstr "" #: ../introduction-methodology.rst:90 msgid "" "Despite the existence of SLAs, things break: servers go down, network " "connections are disrupted, or too many tenants on a server make a server " "unusable. An application must be sturdy enough to contend with these issues." msgstr "" #: ../introduction-methodology.rst:93 msgid "Durability and resilience" msgstr "" #: ../introduction-methodology.rst:96 msgid "Designing for the cloud" msgstr "" #: ../introduction-methodology.rst:98 msgid "" "Here are some guidelines to keep in mind when designing an application for " "the cloud:" msgstr "" #: ../introduction-methodology.rst:101 msgid "Be a pessimist: Assume everything fails and design backwards." msgstr "" #: ../introduction-methodology.rst:103 msgid "" "Put your eggs in multiple baskets: Leverage multiple providers, geographic " "regions and availability zones to accommodate for local availability issues. " "Design for portability." msgstr "" #: ../introduction-methodology.rst:107 msgid "" "Think efficiency: Inefficient designs will not scale. Efficient designs " "become cheaper as they scale. Kill off unneeded components or capacity." msgstr "" #: ../introduction-methodology.rst:111 msgid "" "Be paranoid: Design for defense in depth and zero tolerance by building in " "security at every level and between every component. Trust no one." msgstr "" #: ../introduction-methodology.rst:115 msgid "" "But not too paranoid: Not every application needs the platinum solution. " "Architect for different SLA's, service tiers, and security levels." msgstr "" #: ../introduction-methodology.rst:119 msgid "" "Manage the data: Data is usually the most inflexible and complex area of a " "cloud and cloud integration architecture. Do not short change the effort in " "analyzing and addressing data needs." msgstr "" #: ../introduction-methodology.rst:123 msgid "" "Hands off: Leverage automation to increase consistency and quality and " "reduce response times." msgstr "" #: ../introduction-methodology.rst:126 msgid "" "Divide and conquer: Pursue partitioning and parallel layering wherever " "possible. Make components as small and portable as possible. Use load " "balancing between layers." msgstr "" #: ../introduction-methodology.rst:130 msgid "" "Think elasticity: Increasing resources should result in a proportional " "increase in performance and scalability. Decreasing resources should have " "the opposite effect." msgstr "" #: ../introduction-methodology.rst:134 msgid "" "Be dynamic: Enable dynamic configuration changes such as auto scaling, " "failure recovery and resource discovery to adapt to changing environments, " "faults, and workload volumes." msgstr "" #: ../introduction-methodology.rst:138 msgid "" "Stay close: Reduce latency by moving highly interactive components and data " "near each other." msgstr "" #: ../introduction-methodology.rst:141 msgid "" "Keep it loose: Loose coupling, service interfaces, separation of concerns, " "abstraction, and well defined API's deliver flexibility." msgstr "" #: ../introduction-methodology.rst:144 msgid "" "Be cost aware: Autoscaling, data transmission, virtual software licenses, " "reserved instances, and similar costs can rapidly increase monthly usage " "charges. Monitor usage closely." msgstr "" #: ../introduction.rst:3 msgid "Introduction" msgstr "" #: ../introduction.rst:13 msgid "" ":term:`OpenStack` is a fully-featured, self-service cloud. This book takes " "you through some of the considerations you have to make when designing your " "cloud." msgstr "" #: ../legal-security-requirements.rst:3 msgid "Security and legal requirements" msgstr "" #: ../legal-security-requirements.rst:5 msgid "" "This chapter discusses the legal and security requirements you need to " "consider for the different OpenStack scenarios." msgstr "" #: ../legal-security-requirements.rst:9 msgid "Legal requirements" msgstr "" #: ../legal-security-requirements.rst:11 msgid "" "Many jurisdictions have legislative and regulatory requirements governing " "the storage and management of data in cloud environments. Common areas of " "regulation include:" msgstr "" #: ../legal-security-requirements.rst:15 msgid "" "Data retention policies ensuring storage of persistent data and records " "management to meet data archival requirements." msgstr "" #: ../legal-security-requirements.rst:17 msgid "" "Data ownership policies governing the possession and responsibility for data." msgstr "" #: ../legal-security-requirements.rst:19 msgid "" "Data sovereignty policies governing the storage of data in foreign countries " "or otherwise separate jurisdictions." msgstr "" #: ../legal-security-requirements.rst:21 msgid "" "Data compliance policies governing certain types of information needing to " "reside in certain locations due to regulatory issues - and more importantly, " "cannot reside in other locations for the same reason." msgstr "" #: ../legal-security-requirements.rst:26 msgid "" "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." msgstr "" #: ../legal-security-requirements.rst:39 msgid "" "When deploying OpenStack in an enterprise as a private cloud, despite " "activating a firewall and binding employees with security agreements, cloud " "architecture should not make assumptions about safety and protection. In " "addition to considering the users, operators, or administrators who will use " "the environment, consider also negative or hostile users who would attack or " "compromise the security of your deployment regardless of firewalls or " "security agreements." msgstr "" #: ../legal-security-requirements.rst:48 msgid "" "Attack vectors increase further in a public facing OpenStack deployment. 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." msgstr "" #: ../legal-security-requirements.rst:55 msgid "" "It is important to understand that user authentication requests encase " "sensitive information such as user names, passwords, and authentication " "tokens. For this reason, place the API services behind hardware that " "performs SSL termination." msgstr "" #: ../legal-security-requirements.rst:62 msgid "" "Be mindful of consistency when utilizing third party clouds to explore " "authentication options." msgstr "" #: ../legal-security-requirements.rst:66 msgid "Security domains" msgstr "" #: ../legal-security-requirements.rst:68 msgid "" "A security domain comprises users, applications, servers or networks that " "share common trust requirements and expectations within a system. Typically, " "security domains have the same authentication and authorization requirements " "and users." msgstr "" #: ../legal-security-requirements.rst:73 msgid "" "You can map security domains individually to the installation, or combine " "them. For example, some deployment topologies combine both guest and data " "domains onto one physical network. In other cases these networks are " "physically separate. Map out the security domains against specific OpenStack " "topologies needs. The domains and their trust requirements depend on whether " "the cloud instance is public, private, or hybrid." msgstr "" #: ../legal-security-requirements.rst:82 msgid "Public security domains" msgstr "" #: ../legal-security-requirements.rst:84 msgid "" "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. For example, " "in a hybrid cloud deployment, any information traversing between and beyond " "the clouds is in the public domain and untrustworthy." msgstr "" #: ../legal-security-requirements.rst:92 msgid "Guest security domains" msgstr "" #: ../legal-security-requirements.rst:94 msgid "" "Typically used for compute instance-to-instance traffic, the guest security " "domain handles compute data generated by instances on the cloud but not " "services that support the operation of the cloud, such as 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 domain to be untrusted. Private cloud " "providers may want to consider this network as internal and therefore " "trusted only if they have controls in place to assert that they trust " "instances and all their tenants." msgstr "" #: ../legal-security-requirements.rst:107 msgid "Management security domains" msgstr "" #: ../legal-security-requirements.rst:109 msgid "" "The management security domain is where services interact. The networks in " "this domain transport confidential data such as configuration parameters, " "user names, and passwords. Trust this domain when it is behind an " "organization's firewall in deployments." msgstr "" #: ../legal-security-requirements.rst:115 msgid "Data security domains" msgstr "" #: ../legal-security-requirements.rst:117 msgid "" "The data security domain is concerned primarily with information pertaining " "to the storage services within OpenStack. The data that crosses this network " "has integrity and confidentiality requirements. Depending on the type of " "deployment there may also be availability requirements. The trust level of " "this network is heavily dependent on deployment decisions and does not have " "a default level of trust." msgstr "" #: ../legal-security-requirements.rst:126 msgid "Hypervisor-security" msgstr "" #: ../legal-security-requirements.rst:128 msgid "" "The hypervisor also requires a security assessment. In a public cloud, " "organizations typically do not have control over the choice of hypervisor. " "Properly securing your hypervisor is important. Attacks made upon the " "unsecured hypervisor are called a **hypervisor breakout**. Hypervisor " "breakout describes the event of a compromised or malicious instance breaking " "out of the resource controls of the hypervisor and gaining access to the " "bare metal operating system and hardware resources." msgstr "" #: ../legal-security-requirements.rst:138 msgid "" "There is not an issue if the security of instances is not important. " "However, enterprises need to avoid vulnerability. The only way to do this is " "to avoid the situation where the instances are running on a public cloud. " "That does not mean that there is a need to own all of the infrastructure on " "which an OpenStack installation operates; it suggests avoiding situations in " "which sharing hardware with others occurs." msgstr "" #: ../legal-security-requirements.rst:147 msgid "Baremetal security" msgstr "" #: ../legal-security-requirements.rst:149 msgid "" "There are other services worth considering that provide a bare metal " "instance instead of a cloud. In other cases, it is possible to replicate a " "second private cloud by integrating with a private Cloud-as-a-Service " "deployment. The organization does not buy the hardware, but also does not " "share with other tenants. It is also possible to use a provider that hosts a " "bare-metal public cloud instance for which the hardware is dedicated only to " "one customer, or a provider that offers private Cloud-as-a-Service." msgstr "" #: ../legal-security-requirements.rst:161 msgid "" "Each cloud implements services differently. What keeps data secure in one " "cloud may not do the same in another. Be sure to know the security " "requirements of every cloud that handles the organization's data or " "workloads." msgstr "" #: ../legal-security-requirements.rst:166 msgid "" "More information on OpenStack Security can be found in the `OpenStack " "Security Guide `_." msgstr "" #: ../legal-security-requirements.rst:170 msgid "Networking security" msgstr "" #: ../legal-security-requirements.rst:172 msgid "" "Consider security implications and requirements before designing the " "physical and logical network topologies. Make sure that the networks are " "properly segregated and traffic flows are going to the correct destinations " "without crossing through locations that are undesirable. Consider the " "following example factors:" msgstr "" #: ../legal-security-requirements.rst:179 msgid "Overlay interconnects for joining separated tenant networks" msgstr "" #: ../legal-security-requirements.rst:180 msgid "Routing through or avoiding specific networks" msgstr "" #: ../legal-security-requirements.rst:182 msgid "" "How networks attach to hypervisors can expose security vulnerabilities. To " "mitigate against exploiting hypervisor breakouts, separate networks from " "other systems and schedule instances for the network onto dedicated compute " "nodes. This prevents attackers from having access to the networks from a " "compromised instance." msgstr "" #: ../legal-security-requirements.rst:189 msgid "Multi-site security" msgstr "" #: ../legal-security-requirements.rst:191 msgid "" "Securing a multi-site OpenStack installation brings extra challenges. " "Tenants may expect a tenant-created network to be secure. In a multi-site " "installation the use of a non-private connection between sites may be " "required. This may mean that traffic would be visible to third parties and, " "in cases where an application requires security, this issue requires " "mitigation. In these instances, install a VPN or encrypted connection " "between sites to conceal sensitive traffic." msgstr "" #: ../legal-security-requirements.rst:200 msgid "" "Another security consideration with regard to multi-site deployments is " "Identity. Centralize authentication within a multi-site deployment. " "Centralization provides a single authentication point for users across the " "deployment, as well as a single point of administration for traditional " "create, read, update, and delete operations. Centralized authentication is " "also useful for auditing purposes because all authentication tokens " "originate from the same source." msgstr "" #: ../legal-security-requirements.rst:209 msgid "" "Just as tenants in a single-site deployment need isolation from each other, " "so do tenants in multi-site installations. The extra challenges in multi-" "site designs revolve around ensuring that tenant networks function across " "regions. OpenStack Networking (neutron) does not presently support a " "mechanism to provide this functionality, therefore an external system may be " "necessary to manage these mappings. Tenant networks may contain sensitive " "information requiring that this mapping be accurate and consistent to ensure " "that a tenant in one site does not connect to a different tenant in another " "site." msgstr "" #: ../legal-security-requirements.rst:224 msgid "" "Most OpenStack installations require a bare minimum set of pieces to " "function. These include OpenStack Identity (keystone) for authentication, " "OpenStack Compute (nova) for compute, OpenStack Image service (glance) for " "image storage, OpenStack Networking (neutron) for networking, and " "potentially an object store in the form of OpenStack Object Storage (swift). " "Bringing multi-site into play also demands extra components in order to " "coordinate between regions. Centralized Identity service is necessary to " "provide the single authentication point. Centralized dashboard is also " "recommended to provide a single login point and a mapped experience to the " "API and CLI options available. If needed, use a centralized Object Storage " "service, installing the required swift proxy service alongside the Object " "Storage service." msgstr "" #: ../legal-security-requirements.rst:239 msgid "" "It may also be helpful to install a few extra options in order to facilitate " "certain use cases. For instance, installing DNS service may assist in " "automatically generating DNS domains for each region with an automatically-" "populated zone full of resource records for each instance. This facilitates " "using DNS as a mechanism for determining which region would be selected for " "certain applications." msgstr "" #: ../legal-security-requirements.rst:247 msgid "" "Another useful tool for managing a multi-site installation is Orchestration " "(heat). The Orchestration service allows the use of templates to define a " "set of instances to be launched together or for scaling existing sets. It " "can set up matching or differentiated groupings based on regions. For " "instance, if an application requires an equally balanced number of nodes " "across sites, the same heat template can be used to cover each site with " "small alterations to only the region name." msgstr "" #: ../massively-scalable-operational-considerations.rst:4 msgid "" "In order to run efficiently at massive scale, automate as many of the " "operational processes as possible. Automation includes the configuration of " "provisioning, monitoring and alerting systems. Part of the automation " "process includes the capability to determine when human intervention is " "required and who should act. The objective is to increase the ratio of " "operational staff to running systems as much as possible in order to reduce " "maintenance costs. In a massively scaled environment, it is very difficult " "for staff to give each system individual care." msgstr "" #: ../massively-scalable-operational-considerations.rst:13 msgid "" "Configuration management tools such as Puppet and Chef enable operations " "staff to categorize systems into groups based on their roles and thus create " "configurations and system states that the provisioning system enforces. " "Systems that fall out of the defined state due to errors or failures are " "quickly removed from the pool of active nodes and replaced." msgstr "" #: ../massively-scalable-operational-considerations.rst:19 msgid "" "At large scale the resource cost of diagnosing failed individual systems is " "far greater than the cost of replacement. It is more economical to replace " "the failed system with a new system, provisioning and configuring it " "automatically and adding it to the pool of active nodes. By automating tasks " "that are labor-intensive, repetitive, and critical to operations, cloud " "operations teams can work more efficiently because fewer resources are " "required for these common tasks. Administrators are then free to tackle " "tasks that are not easy to automate and that have longer-term impacts on the " "business, for example, capacity planning." msgstr "" #: ../massively-scalable-operational-considerations.rst:30 msgid "The bleeding edge" msgstr "" #: ../massively-scalable-operational-considerations.rst:32 msgid "" "Running OpenStack at massive scale requires striking a balance between " "stability and features. For example, it might be tempting to run an older " "stable release branch of OpenStack to make deployments easier. However, when " "running at massive scale, known issues that may be of some concern or only " "have minimal impact in smaller deployments could become pain points. Recent " "releases may address well known issues. The OpenStack community can help " "resolve reported issues by applying the collective expertise of the " "OpenStack developers." msgstr "" #: ../massively-scalable-operational-considerations.rst:41 msgid "" "The number of organizations running at massive scales is a small proportion " "of the OpenStack community, therefore it is important to share related " "issues with the community and be a vocal advocate for resolving them. Some " "issues only manifest when operating at large scale, and the number of " "organizations able to duplicate and validate an issue is small, so it is " "important to document and dedicate resources to their resolution." msgstr "" #: ../massively-scalable-operational-considerations.rst:48 msgid "" "In some cases, the resolution to the problem is ultimately to deploy a more " "recent version of OpenStack. Alternatively, when you must resolve an issue " "in a production environment where rebuilding the entire environment is not " "an option, it is sometimes possible to deploy updates to specific underlying " "components in order to resolve issues or gain significant performance " "improvements. Although this may appear to expose the deployment to increased " "risk and instability, in many cases it could be an undiscovered issue." msgstr "" #: ../massively-scalable-operational-considerations.rst:56 msgid "" "We recommend building a development and operations organization that is " "responsible for creating desired features, diagnosing and resolving issues, " "and building the infrastructure for large scale continuous integration tests " "and continuous deployment. This helps catch bugs early and makes deployments " "faster and easier. In addition to development resources, we also recommend " "the recruitment of experts in the fields of message queues, databases, " "distributed systems, networking, cloud, and storage." msgstr "" #: ../massively-scalable-operational-considerations.rst:65 msgid "Growth and capacity planning" msgstr "" #: ../massively-scalable-operational-considerations.rst:67 msgid "" "An important consideration in running at massive scale is projecting growth " "and utilization trends in order to plan capital expenditures for the short " "and long term. Gather utilization meters for compute, network, and storage, " "along with historical records of these meters. While securing major anchor " "tenants can lead to rapid jumps in the utilization rates of all resources, " "the steady adoption of the cloud inside an organization or by consumers in a " "public offering also creates a steady trend of increased utilization." msgstr "" #: ../massively-scalable-operational-considerations.rst:76 msgid "Skills and training" msgstr "" #: ../massively-scalable-operational-considerations.rst:78 msgid "" "Projecting growth for storage, networking, and compute is only one aspect of " "a growth plan for running OpenStack at massive scale. Growing and nurturing " "development and operational staff is an additional consideration. Sending " "team members to OpenStack conferences, meetup events, and encouraging active " "participation in the mailing lists and committees is a very important way to " "maintain skills and forge relationships in the community. For a list of " "OpenStack training providers in the marketplace, see: http://www.openstack." "org/marketplace/training/." msgstr "" #: ../massively-scalable-technical-considerations.rst:4 msgid "" "Repurposing an existing OpenStack environment to be massively scalable is a " "formidable task. When building a massively scalable environment from the " "ground up, ensure you build the initial deployment with the same principles " "and choices that apply as the environment grows. For example, a good " "approach is to deploy the first site as a multi-site environment. This " "enables you to use the same deployment and segregation methods as the " "environment grows to separate locations across dedicated links or wide area " "networks. In a hyperscale cloud, scale trumps redundancy. Modify " "applications with this in mind, relying on the scale and homogeneity of the " "environment to provide reliability rather than redundant infrastructure " "provided by non-commodity hardware solutions." msgstr "" #: ../massively-scalable-technical-considerations.rst:17 msgid "Infrastructure segregation" msgstr "" #: ../massively-scalable-technical-considerations.rst:19 msgid "" "OpenStack services support massive horizontal scale. Be aware that this is " "not the case for the entire supporting infrastructure. This is particularly " "a problem for the database management systems and message queues that " "OpenStack services use for data storage and remote procedure call " "communications." msgstr "" #: ../massively-scalable-technical-considerations.rst:24 msgid "" "Traditional clustering techniques typically provide high availability and " "some additional scale for these environments. In the quest for massive " "scale, however, you must take additional steps to relieve the performance " "pressure on these components in order to prevent them from negatively " "impacting the overall performance of the environment. Ensure that all the " "components are in balance so that if the massively scalable environment " "fails, all the components are near maximum capacity and a single component " "is not causing the failure." msgstr "" #: ../massively-scalable-technical-considerations.rst:33 msgid "" "Regions segregate completely independent installations linked only by an " "Identity and Dashboard (optional) installation. Services have separate API " "endpoints for each region, and include separate database and queue " "installations. This exposes some awareness of the environment's fault " "domains to users and gives them the ability to ensure some degree of " "application resiliency while also imposing the requirement to specify which " "region to apply their actions to." msgstr "" #: ../massively-scalable-technical-considerations.rst:41 msgid "" "Environments operating at massive scale typically need their regions or " "sites subdivided further without exposing the requirement to specify the " "failure domain to the user. This provides the ability to further divide the " "installation into failure domains while also providing a logical unit for " "maintenance and the addition of new hardware. At hyperscale, instead of " "adding single compute nodes, administrators can add entire racks or even " "groups of racks at a time with each new addition of nodes exposed via one of " "the segregation concepts mentioned herein." msgstr "" #: ../massively-scalable-technical-considerations.rst:50 msgid "" ":term:`Cells ` provide the ability to subdivide the compute portion of " "an OpenStack installation, including regions, while still exposing a single " "endpoint. Each region has an API cell along with a number of compute cells " "where the workloads actually run. Each cell has its own database and message " "queue setup (ideally clustered), providing the ability to subdivide the load " "on these subsystems, improving overall performance." msgstr "" #: ../massively-scalable-technical-considerations.rst:57 msgid "" "Each compute cell provides a complete compute installation, complete with " "full database and queue installations, scheduler, conductor, and multiple " "compute hosts. The cells scheduler handles placement of user requests from " "the single API endpoint to a specific cell from those available. The normal " "filter scheduler then handles placement within the cell." msgstr "" #: ../massively-scalable-technical-considerations.rst:63 msgid "" "Unfortunately, Compute is the only OpenStack service that provides good " "support for cells. In addition, cells do not adequately support some " "standard OpenStack functionality such as security groups and host " "aggregates. Due to their relative newness and specialized use, cells receive " "relatively little testing in the OpenStack gate. Despite these issues, cells " "play an important role in well known OpenStack installations operating at " "massive scale, such as those at CERN and Rackspace." msgstr "" #: ../massively-scalable-technical-considerations.rst:72 msgid "Host aggregates" msgstr "" #: ../massively-scalable-technical-considerations.rst:74 msgid "" "Host aggregates enable partitioning of OpenStack Compute deployments into " "logical groups for load balancing and instance distribution. You can also " "use host aggregates to further partition an availability zone. Consider a " "cloud which might use host aggregates to partition an availability zone into " "groups of hosts that either share common resources, such as storage and " "network, or have a special property, such as trusted computing hardware. You " "cannot target host aggregates explicitly. Instead, select instance flavors " "that map to host aggregate metadata. These flavors target host aggregates " "implicitly." msgstr "" #: ../massively-scalable-technical-considerations.rst:84 msgid "Availability zones" msgstr "" #: ../massively-scalable-technical-considerations.rst:86 msgid "" "Availability zones provide another mechanism for subdividing an installation " "or region. They are, in effect, host aggregates exposed for (optional) " "explicit targeting by users." msgstr "" #: ../massively-scalable-technical-considerations.rst:90 msgid "" "Unlike cells, availability zones do not have their own database server or " "queue broker but represent an arbitrary grouping of compute nodes. " "Typically, nodes are grouped into availability zones using a shared failure " "domain based on a physical characteristic such as a shared power source or " "physical network connections. Users can target exposed availability zones; " "however, this is not a requirement. An alternative approach is to set a " "default availability zone to schedule instances to a non-default " "availability zone of nova." msgstr "" #: ../massively-scalable-technical-considerations.rst:99 msgid "Segregation example" msgstr "" #: ../massively-scalable-technical-considerations.rst:101 msgid "" "In this example, the cloud is divided into two regions, an API cell and " "three child cells for each region, with three availability zones in each " "cell based on the power layout of the data centers. The below figure " "describes the relationship between them within one region." msgstr "" #: ../massively-scalable-technical-considerations.rst:108 msgid "" "A number of host aggregates enable targeting of virtual machine instances " "using flavors, that require special capabilities shared by the target hosts " "such as SSDs, 10 GbE networks, or GPU cards." msgstr "" #: ../massively-scalable-user-requirements.rst:4 msgid "" "Defining user requirements for a massively scalable OpenStack design " "architecture dictates approaching the design from two different, yet " "sometimes opposing, perspectives: the cloud user, and the cloud operator. " "The expectations and perceptions of the consumption and management of " "resources of a massively scalable OpenStack cloud from these two " "perspectives are distinctly different." msgstr "" #: ../massively-scalable-user-requirements.rst:11 msgid "" "Massively scalable OpenStack clouds have the following user requirements:" msgstr "" #: ../massively-scalable-user-requirements.rst:13 msgid "" "The cloud user expects repeatable, dependable, and deterministic processes " "for launching and deploying cloud resources. You could deliver this through " "a web-based interface or publicly available API endpoints. All appropriate " "options for requesting cloud resources must be available through some type " "of user interface, a command-line interface (CLI), or API endpoints." msgstr "" #: ../massively-scalable-user-requirements.rst:19 msgid "" "Cloud users expect a fully self-service and on-demand consumption model. " "When an OpenStack cloud reaches the massively scalable size, expect " "consumption as a service in each and every way." msgstr "" #: ../massively-scalable-user-requirements.rst:23 msgid "" "For a user of a massively scalable OpenStack public cloud, there are no " "expectations for control over security, performance, or availability. Users " "expect only SLAs related to uptime of API services, and very basic SLAs for " "services offered. It is the user's responsibility to address these issues on " "their own. The exception to this expectation is the rare case of a massively " "scalable cloud infrastructure built for a private or government organization " "that has specific requirements." msgstr "" #: ../massively-scalable-user-requirements.rst:31 msgid "" "The cloud user's requirements and expectations that determine the cloud " "design focus on the consumption model. The user expects to consume cloud " "resources in an automated and deterministic way, without any need for " "knowledge of the capacity, scalability, or other attributes of the cloud's " "underlying infrastructure." msgstr "" #: ../massively-scalable-user-requirements.rst:38 msgid "Operator requirements" msgstr "" #: ../massively-scalable-user-requirements.rst:40 msgid "" "While the cloud user can be completely unaware of the underlying " "infrastructure of the cloud and its attributes, the operator must build and " "support the infrastructure for operating at scale. This presents a very " "demanding set of requirements for building such a cloud from the operator's " "perspective:" msgstr "" #: ../massively-scalable-user-requirements.rst:46 msgid "" "Everything must be capable of automation. For example, everything from " "compute hardware, storage hardware, networking hardware, to the installation " "and configuration of the supporting software. Manual processes are " "impractical in a massively scalable OpenStack design architecture." msgstr "" #: ../massively-scalable-user-requirements.rst:51 msgid "" "The cloud operator requires that capital expenditure (CapEx) is minimized at " "all layers of the stack. Operators of massively scalable OpenStack clouds " "require the use of dependable commodity hardware and freely available open " "source software components to reduce deployment costs and operational " "expenses. Initiatives like OpenCompute (more information available at http://" "www.opencompute.org) provide additional information and pointers. To cut " "costs, many operators sacrifice redundancy. For example, using redundant " "power supplies, network connections, and rack switches." msgstr "" #: ../massively-scalable-user-requirements.rst:60 msgid "" "Companies operating a massively scalable OpenStack cloud also require that " "operational expenditures (OpEx) be minimized as much as possible. We " "recommend using cloud-optimized hardware when managing operational overhead. " "Some of the factors to consider include power, cooling, and the physical " "design of the chassis. Through customization, it is possible to optimize the " "hardware and systems for this type of workload because of the scale of these " "implementations." msgstr "" #: ../massively-scalable-user-requirements.rst:68 msgid "" "Massively scalable OpenStack clouds require extensive metering and " "monitoring functionality to maximize the operational efficiency by keeping " "the operator informed about the status and state of the infrastructure. This " "includes full scale metering of the hardware and software status. A " "corresponding framework of logging and alerting is also required to store " "and enable operations to act on the meters provided by the metering and " "monitoring solutions. The cloud operator also needs a solution that uses the " "data provided by the metering and monitoring solution to provide capacity " "planning and capacity trending analysis." msgstr "" #: ../massively-scalable-user-requirements.rst:78 msgid "" "Invariably, massively scalable OpenStack clouds extend over several sites. " "Therefore, the user-operator requirements for a multi-site OpenStack " "architecture design are also applicable here. This includes various legal " "requirements; other jurisdictional legal or compliance requirements; image " "consistency-availability; storage replication and availability (both block " "and file/object storage); and authentication, authorization, and auditing " "(AAA). See :doc:`multi-site` for more details on requirements and " "considerations for multi-site OpenStack clouds." msgstr "" #: ../massively-scalable-user-requirements.rst:87 msgid "" "The design architecture of a massively scalable OpenStack cloud must address " "considerations around physical facilities such as space, floor weight, rack " "height and type, environmental considerations, power usage and power usage " "efficiency (PUE), and physical security." msgstr "" #: ../massively-scalable.rst:3 msgid "Massively scalable" msgstr "" #: ../massively-scalable.rst:12 msgid "" "A massively scalable architecture is a cloud implementation that is either a " "very large deployment, such as a commercial service provider might build, or " "one that has the capability to support user requests for large amounts of " "cloud resources." msgstr "" #: ../massively-scalable.rst:17 msgid "" "An example is an infrastructure in which requests to service 500 or more " "instances at a time is common. A massively scalable infrastructure fulfills " "such a request without exhausting the available cloud infrastructure " "resources. While the high capital cost of implementing such a cloud " "architecture means that it is currently in limited use, many organizations " "are planning for massive scalability in the future." msgstr "" #: ../massively-scalable.rst:25 msgid "" "A massively scalable OpenStack cloud design presents a unique set of " "challenges and considerations. For the most part it is similar to a general " "purpose cloud architecture, as it is built to address a non-specific range " "of potential use cases or functions. Typically, it is rare that particular " "workloads determine the design or configuration of massively scalable " "clouds. The massively scalable cloud is most often built as a platform for a " "variety of workloads. Because private organizations rarely require or have " "the resources for them, massively scalable OpenStack clouds are generally " "built as commercial, public cloud offerings." msgstr "" #: ../massively-scalable.rst:37 msgid "Services provided by a massively scalable OpenStack cloud include:" msgstr "" #: ../massively-scalable.rst:43 msgid "Firewall functionality" msgstr "" #: ../massively-scalable.rst:44 msgid "Load balancing functionality" msgstr "" #: ../massively-scalable.rst:45 msgid "Private (non-routable) and public (floating) IP addresses" msgstr "" #: ../massively-scalable.rst:46 msgid "Virtualized network topologies" msgstr "" #: ../massively-scalable.rst:48 msgid "Virtual compute resources" msgstr "" #: ../massively-scalable.rst:50 msgid "" "Like a general purpose cloud, the instances deployed in a massively scalable " "OpenStack cloud do not necessarily use any specific aspect of the cloud " "offering (compute, network, or storage). As the cloud grows in scale, the " "number of workloads can cause stress on all the cloud components. This adds " "further stresses to supporting infrastructure such as databases and message " "brokers. The architecture design for such a cloud must account for these " "performance pressures without negatively impacting user experience." msgstr "" #: ../multi-site-architecture.rst:5 msgid "" ":ref:`ms-openstack-architecture` illustrates a high level multi-site " "OpenStack architecture. Each site is an OpenStack cloud but it may be " "necessary to architect the sites on different versions. For example, if the " "second site is intended to be a replacement for the first site, they would " "be different. Another common design would be a private OpenStack cloud with " "a replicated site that would be used for high availability or disaster " "recovery. The most important design decision is configuring storage as a " "single shared pool or separate pools, depending on user and technical " "requirements." msgstr "" #: ../multi-site-architecture.rst:19 msgid "**Multi-site OpenStack architecture**" msgstr "" #: ../multi-site-architecture.rst:23 msgid "OpenStack services architecture" msgstr "" #: ../multi-site-architecture.rst:25 msgid "" "The Identity service, which is used by all other OpenStack components for " "authorization and the catalog of service endpoints, supports the concept of " "regions. A region is a logical construct used to group OpenStack services in " "close proximity to one another. The concept of regions is flexible; it may " "contain OpenStack service endpoints located within a distinct geographic " "region or regions. It may be smaller in scope, where a region is a single " "rack within a data center, with multiple regions existing in adjacent racks " "in the same data center." msgstr "" #: ../multi-site-architecture.rst:34 msgid "" "The majority of OpenStack components are designed to run within the context " "of a single region. The Compute service is designed to manage compute " "resources within a region, with support for subdivisions of compute " "resources by using availability zones and cells. The Networking service can " "be used to manage network resources in the same broadcast domain or " "collection of switches that are linked. The OpenStack Block Storage service " "controls storage resources within a region with all storage resources " "residing on the same storage network. Like the OpenStack Compute service, " "the OpenStack Block Storage service also supports the availability zone " "construct which can be used to subdivide storage resources." msgstr "" #: ../multi-site-architecture.rst:46 msgid "" "The OpenStack dashboard, OpenStack Identity, and OpenStack Object Storage " "services are components that can each be deployed centrally in order to " "serve multiple regions." msgstr "" #: ../multi-site-architecture.rst:53 msgid "" "With multiple OpenStack regions, it is recommended to configure a single " "OpenStack Object Storage service endpoint to deliver shared file storage for " "all regions. The Object Storage service internally replicates files to " "multiple nodes which can be used by applications or workloads in multiple " "regions. This simplifies high availability failover and disaster recovery " "rollback." msgstr "" #: ../multi-site-architecture.rst:60 msgid "" "In order to scale the Object Storage service to meet the workload of " "multiple regions, multiple proxy workers are run and load-balanced, storage " "nodes are installed in each region, and the entire Object Storage Service " "can be fronted by an HTTP caching layer. This is done so client requests for " "objects can be served out of caches rather than directly from the storage " "modules themselves, reducing the actual load on the storage network. In " "addition to an HTTP caching layer, use a caching layer like Memcache to " "cache objects between the proxy and storage nodes." msgstr "" #: ../multi-site-architecture.rst:70 msgid "" "If the cloud is designed with a separate Object Storage service endpoint " "made available in each region, applications are required to handle " "synchronization (if desired) and other management operations to ensure " "consistency across the nodes. For some applications, having multiple Object " "Storage Service endpoints located in the same region as the application may " "be desirable due to reduced latency, cross region bandwidth, and ease of " "deployment." msgstr "" #: ../multi-site-architecture.rst:80 msgid "" "For the Block Storage service, the most important decisions are the " "selection of the storage technology, and whether a dedicated network is used " "to carry storage traffic from the storage service to the compute nodes." msgstr "" #: ../multi-site-architecture.rst:86 msgid "Networking" msgstr "" #: ../multi-site-architecture.rst:88 msgid "" "When connecting multiple regions together, there are several design " "considerations. The overlay network technology choice determines how packets " "are transmitted between regions and how the logical network and addresses " "present to the application. If there are security or regulatory " "requirements, encryption should be implemented to secure the traffic between " "regions. For networking inside a region, the overlay network technology for " "tenant networks is equally important. The overlay technology and the network " "traffic that an application generates or receives can be either " "complementary or serve cross purposes. For example, using an overlay " "technology for an application that transmits a large amount of small packets " "could add excessive latency or overhead to each packet if not configured " "properly." msgstr "" #: ../multi-site-architecture.rst:104 msgid "" "The architecture for a multi-site OpenStack installation is dependent on a " "number of factors. One major dependency to consider is storage. When " "designing the storage system, the storage mechanism needs to be determined. " "Once the storage type is determined, how it is accessed is critical. For " "example, we recommend that storage should use a dedicated network. Another " "concern is how the storage is configured to protect the data. For example, " "the Recovery Point Objective (RPO) and the Recovery Time Objective (RTO). " "How quickly recovery from a fault can be completed, determines how often the " "replication of data is required. Ensure that enough storage is allocated to " "support the data protection strategy." msgstr "" #: ../multi-site-architecture.rst:116 msgid "" "Networking decisions include the encapsulation mechanism that can be used " "for the tenant networks, how large the broadcast domains should be, and the " "contracted SLAs for the interconnects." msgstr "" #: ../multi-site-operational-considerations.rst:5 msgid "" "Multi-site OpenStack cloud deployment using regions requires that the " "service catalog contains per-region entries for each service deployed other " "than the Identity service. Most off-the-shelf OpenStack deployment tools " "have limited support for defining multiple regions in this fashion." msgstr "" #: ../multi-site-operational-considerations.rst:11 msgid "" "Deployers should be aware of this and provide the appropriate customization " "of the service catalog for their site either manually, or by customizing " "deployment tools in use." msgstr "" #: ../multi-site-operational-considerations.rst:17 msgid "" "As of the Kilo release, documentation for implementing this feature is in " "progress. See this bug for more information: https://bugs.launchpad.net/" "openstack-manuals/+bug/1340509." msgstr "" #: ../multi-site-operational-considerations.rst:22 msgid "Licensing" msgstr "" #: ../multi-site-operational-considerations.rst:24 msgid "" "Multi-site OpenStack deployments present additional licensing considerations " "over and above regular OpenStack clouds, particularly where site licenses " "are in use to provide cost efficient access to software licenses. The " "licensing for host operating systems, guest operating systems, OpenStack " "distributions (if applicable), software-defined infrastructure including " "network controllers and storage systems, and even individual applications " "need to be evaluated." msgstr "" #: ../multi-site-operational-considerations.rst:32 msgid "Topics to consider include:" msgstr "" #: ../multi-site-operational-considerations.rst:34 msgid "" "The definition of what constitutes a site in the relevant licenses, as the " "term does not necessarily denote a geographic or otherwise physically " "isolated location." msgstr "" #: ../multi-site-operational-considerations.rst:38 msgid "" "Differentiations between \"hot\" (active) and \"cold\" (inactive) sites, " "where significant savings may be made in situations where one site is a cold " "standby for disaster recovery purposes only." msgstr "" #: ../multi-site-operational-considerations.rst:42 msgid "" "Certain locations might require local vendors to provide support and " "services for each site which may vary with the licensing agreement in place." msgstr "" #: ../multi-site-operational-considerations.rst:47 msgid "Logging and monitoring" msgstr "" #: ../multi-site-operational-considerations.rst:49 msgid "" "Logging and monitoring does not significantly differ for a multi-site " "OpenStack cloud. The tools described in the `Logging and monitoring chapter " "`__ " "of the Operations Guide remain applicable. Logging and monitoring can be " "provided on a per-site basis, and in a common centralized location." msgstr "" #: ../multi-site-operational-considerations.rst:55 msgid "" "When attempting to deploy logging and monitoring facilities to a centralized " "location, care must be taken with the load placed on the inter-site " "networking links." msgstr "" #: ../multi-site-operational-considerations.rst:62 msgid "" "In multi-site OpenStack clouds deployed using regions, sites are independent " "OpenStack installations which are linked together using shared centralized " "services such as OpenStack Identity. At a high level the recommended order " "of operations to upgrade an individual OpenStack environment is (see the " "`Upgrades chapter `__ of the Operations Guide for details):" msgstr "" #: ../multi-site-operational-considerations.rst:70 msgid "Upgrade the OpenStack Identity service (keystone)." msgstr "" #: ../multi-site-operational-considerations.rst:72 msgid "Upgrade the OpenStack Image service (glance)." msgstr "" #: ../multi-site-operational-considerations.rst:74 msgid "Upgrade OpenStack Compute (nova), including networking components." msgstr "" #: ../multi-site-operational-considerations.rst:76 msgid "Upgrade OpenStack Block Storage (cinder)." msgstr "" #: ../multi-site-operational-considerations.rst:78 msgid "Upgrade the OpenStack dashboard (horizon)." msgstr "" #: ../multi-site-operational-considerations.rst:80 msgid "" "The process for upgrading a multi-site environment is not significantly " "different:" msgstr "" #: ../multi-site-operational-considerations.rst:83 msgid "Upgrade the shared OpenStack Identity service (keystone) deployment." msgstr "" #: ../multi-site-operational-considerations.rst:85 msgid "Upgrade the OpenStack Image service (glance) at each site." msgstr "" #: ../multi-site-operational-considerations.rst:87 msgid "" "Upgrade OpenStack Compute (nova), including networking components, at each " "site." msgstr "" #: ../multi-site-operational-considerations.rst:90 msgid "Upgrade OpenStack Block Storage (cinder) at each site." msgstr "" #: ../multi-site-operational-considerations.rst:92 msgid "" "Upgrade the OpenStack dashboard (horizon), at each site or in the single " "central location if it is shared." msgstr "" #: ../multi-site-operational-considerations.rst:95 msgid "" "Compute upgrades within each site can also be performed in a rolling " "fashion. Compute controller services (API, Scheduler, and Conductor) can be " "upgraded prior to upgrading of individual compute nodes. This allows " "operations staff to keep a site operational for users of Compute services " "while performing an upgrade." msgstr "" #: ../multi-site-operational-considerations.rst:102 msgid "Quota management" msgstr "" #: ../multi-site-operational-considerations.rst:104 msgid "" "Quotas are used to set operational limits to prevent system capacities from " "being exhausted without notification. They are currently enforced at the " "tenant (or project) level rather than at the user level." msgstr "" #: ../multi-site-operational-considerations.rst:108 msgid "" "Quotas are defined on a per-region basis. Operators can define identical " "quotas for tenants in each region of the cloud to provide a consistent " "experience, or even create a process for synchronizing allocated quotas " "across regions. It is important to note that only the operational limits " "imposed by the quotas will be aligned consumption of quotas by users will " "not be reflected between regions." msgstr "" #: ../multi-site-operational-considerations.rst:115 msgid "" "For example, given a cloud with two regions, if the operator grants a user a " "quota of 25 instances in each region then that user may launch a total of 50 " "instances spread across both regions. They may not, however, launch more " "than 25 instances in any single region." msgstr "" #: ../multi-site-operational-considerations.rst:120 msgid "" "For more information on managing quotas refer to the `Managing projects and " "users chapter `__ of the OpenStack Operators Guide." msgstr "" #: ../multi-site-operational-considerations.rst:126 msgid "Policy management" msgstr "" #: ../multi-site-operational-considerations.rst:128 msgid "" "OpenStack provides a default set of Role Based Access Control (RBAC) " "policies, defined in a ``policy.json`` file, for each service. Operators " "edit these files to customize the policies for their OpenStack installation. " "If the application of consistent RBAC policies across sites is a " "requirement, then it is necessary to ensure proper synchronization of the " "``policy.json`` files to all installations." msgstr "" #: ../multi-site-operational-considerations.rst:135 msgid "" "This must be done using system administration tools such as rsync as " "functionality for synchronizing policies across regions is not currently " "provided within OpenStack." msgstr "" #: ../multi-site-operational-considerations.rst:140 msgid "Documentation" msgstr "" #: ../multi-site-operational-considerations.rst:142 msgid "" "Users must be able to leverage cloud infrastructure and provision new " "resources in the environment. It is important that user documentation is " "accessible by users to ensure they are given sufficient information to help " "them leverage the cloud. As an example, by default OpenStack schedules " "instances on a compute node automatically. However, when multiple regions " "are available, the end user needs to decide in which region to schedule the " "new instance. The dashboard presents the user with the first region in your " "configuration. The API and CLI tools do not execute commands unless a valid " "region is specified. It is therefore important to provide documentation to " "your users describing the region layout as well as calling out that quotas " "are region-specific. If a user reaches his or her quota in one region, " "OpenStack does not automatically build new instances in another. Documenting " "specific examples helps users understand how to operate the cloud, thereby " "reducing calls and tickets filed with the help desk." msgstr "" #: ../multi-site-prescriptive-examples.rst:5 msgid "" "There are multiple ways to build a multi-site OpenStack installation, based " "on the needs of the intended workloads. Below are example architectures " "based on different requirements. These examples are meant as a reference, " "and not a hard and fast rule for deployments. Use the previous sections of " "this chapter to assist in selecting specific components and implementations " "based on specific needs." msgstr "" #: ../multi-site-prescriptive-examples.rst:12 msgid "" "A large content provider needs to deliver content to customers that are " "geographically dispersed. The workload is very sensitive to latency and " "needs a rapid response to end-users. After reviewing the user, technical and " "operational considerations, it is determined beneficial to build a number of " "regions local to the customer's edge. Rather than build a few large, " "centralized data centers, the intent of the architecture is to provide a " "pair of small data centers in locations that are closer to the customer. In " "this use case, spreading applications out allows for different horizontal " "scaling than a traditional compute workload scale. The intent is to scale by " "creating more copies of the application in closer proximity to the users " "that need it most, in order to ensure faster response time to user requests. " "This provider deploys two datacenters at each of the four chosen regions. " "The implications of this design are based around the method of placing " "copies of resources in each of the remote regions. Swift objects, Glance " "images, and block storage need to be manually replicated into each region. " "This may be beneficial for some systems, such as the case of content " "service, where only some of the content needs to exist in some but not all " "regions. A centralized Keystone is recommended to ensure authentication and " "that access to the API endpoints is easily manageable." msgstr "" #: ../multi-site-prescriptive-examples.rst:33 msgid "" "It is recommended that you install an automated DNS system such as " "Designate. Application administrators need a way to manage the mapping of " "which application copy exists in each region and how to reach it, unless an " "external Dynamic DNS system is available. Designate assists by making the " "process automatic and by populating the records in the each region's zone." msgstr "" #: ../multi-site-prescriptive-examples.rst:40 msgid "" "Telemetry for each region is also deployed, as each region may grow " "differently or be used at a different rate. Ceilometer collects each " "region's meters from each of the controllers and report them back to a " "central location. This is useful both to the end user and the administrator " "of the OpenStack environment. The end user will find this method useful, as " "it makes possible to determine if certain locations are experiencing higher " "load than others, and take appropriate action. Administrators also benefit " "by possibly being able to forecast growth per region, rather than expanding " "the capacity of all regions simultaneously, therefore maximizing the cost-" "effectiveness of the multi-site design." msgstr "" #: ../multi-site-prescriptive-examples.rst:52 msgid "" "One of the key decisions of running this infrastructure is whether or not to " "provide a redundancy model. Two types of redundancy and high availability " "models in this configuration can be implemented. The first type is the " "availability of central OpenStack components. Keystone can be made highly " "available in three central data centers that host the centralized OpenStack " "components. This prevents a loss of any one of the regions causing an outage " "in service. It also has the added benefit of being able to run a central " "storage repository as a primary cache for distributing content to each of " "the regions." msgstr "" #: ../multi-site-prescriptive-examples.rst:62 msgid "" "The second redundancy type is the edge data center itself. A second data " "center in each of the edge regional locations house a second region near the " "first region. This ensures that the application does not suffer degraded " "performance in terms of latency and availability." msgstr "" #: ../multi-site-prescriptive-examples.rst:67 msgid "" ":ref:`ms-customer-edge` depicts the solution designed to have both a " "centralized set of core data centers for OpenStack services and paired edge " "data centers:" msgstr "" #: ../multi-site-prescriptive-examples.rst:75 msgid "**Multi-site architecture example**" msgstr "" #: ../multi-site-prescriptive-examples.rst:78 msgid "Geo-redundant load balancing" msgstr "" #: ../multi-site-prescriptive-examples.rst:80 msgid "" "A large-scale web application has been designed with cloud principles in " "mind. The application is designed provide service to application store, on a " "24/7 basis. The company has typical two tier architecture with a web front-" "end servicing the customer requests, and a NoSQL database back end storing " "the information." msgstr "" #: ../multi-site-prescriptive-examples.rst:86 msgid "" "As of late there has been several outages in number of major public cloud " "providers due to applications running out of a single geographical location. " "The design therefore should mitigate the chance of a single site causing an " "outage for their business." msgstr "" #: ../multi-site-prescriptive-examples.rst:96 msgid "" "OpenStack Controller services running, Networking, dashboard, Block Storage " "and Compute running locally in each of the three regions. Identity service, " "Orchestration service, Telemetry service, Image service and Object Storage " "service can be installed centrally, with nodes in each of the region " "providing a redundant OpenStack Controller plane throughout the globe." msgstr "" #: ../multi-site-prescriptive-examples.rst:105 msgid "" "OpenStack Object Storage for serving static objects such as images can be " "used to ensure that all images are standardized across all the regions, and " "replicated on a regular basis." msgstr "" #: ../multi-site-prescriptive-examples.rst:109 msgid "" "A distributed DNS service available to all regions that allows for dynamic " "update of DNS records of deployed instances." msgstr "" #: ../multi-site-prescriptive-examples.rst:112 msgid "" "A geo-redundant load balancing service can be used to service the requests " "from the customers based on their origin." msgstr "" #: ../multi-site-prescriptive-examples.rst:115 msgid "" "An autoscaling heat template can be used to deploy the application in the " "three regions. This template includes:" msgstr "" #: ../multi-site-prescriptive-examples.rst:118 msgid "Web Servers, running Apache." msgstr "" #: ../multi-site-prescriptive-examples.rst:120 msgid "" "Appropriate ``user_data`` to populate the central DNS servers upon instance " "launch." msgstr "" #: ../multi-site-prescriptive-examples.rst:123 msgid "" "Appropriate Telemetry alarms that maintain state of the application and " "allow for handling of region or instance failure." msgstr "" #: ../multi-site-prescriptive-examples.rst:126 msgid "" "Another autoscaling Heat template can be used to deploy a distributed " "MongoDB shard over the three locations, with the option of storing required " "data on a globally available swift container. According to the usage and " "load on the database server, additional shards can be provisioned according " "to the thresholds defined in Telemetry." msgstr "" #: ../multi-site-prescriptive-examples.rst:132 msgid "" "Two data centers would have been sufficient had the requirements been met. " "But three regions are selected here to avoid abnormal load on a single " "region in the event of a failure." msgstr "" #: ../multi-site-prescriptive-examples.rst:136 msgid "" "Orchestration is used because of the built-in functionality of autoscaling " "and auto healing in the event of increased load. Additional configuration " "management tools, such as Puppet or Chef could also have been used in this " "scenario, but were not chosen since Orchestration had the appropriate built-" "in hooks into the OpenStack cloud, whereas the other tools were external and " "not native to OpenStack. In addition, external tools were not needed since " "this deployment scenario was straight forward." msgstr "" #: ../multi-site-prescriptive-examples.rst:145 msgid "" "OpenStack Object Storage is used here to serve as a back end for the Image " "service since it is the most suitable solution for a globally distributed " "storage solution with its own replication mechanism. Home grown solutions " "could also have been used including the handling of replication, but were " "not chosen, because Object Storage is already an intricate part of the " "infrastructure and a proven solution." msgstr "" #: ../multi-site-prescriptive-examples.rst:152 msgid "" "An external load balancing service was used and not the LBaaS in OpenStack " "because the solution in OpenStack is not redundant and does not have any " "awareness of geo location." msgstr "" #: ../multi-site-prescriptive-examples.rst:160 msgid "**Multi-site geo-redundant architecture**" msgstr "" #: ../multi-site-prescriptive-examples.rst:163 msgid "Location-local service" msgstr "" #: ../multi-site-prescriptive-examples.rst:165 msgid "" "A common use for multi-site OpenStack deployment is creating a Content " "Delivery Network. An application that uses a location-local architecture " "requires low network latency and proximity to the user to provide an optimal " "user experience and reduce the cost of bandwidth and transit. The content " "resides on sites closer to the customer, instead of a centralized content " "store that requires utilizing higher cost cross-country links." msgstr "" #: ../multi-site-prescriptive-examples.rst:173 msgid "" "This architecture includes a geo-location component that places user " "requests to the closest possible node. In this scenario, 100% redundancy of " "content across every site is a goal rather than a requirement, with the " "intent to maximize the amount of content available within a minimum number " "of network hops for end users. Despite these differences, the storage " "replication configuration has significant overlap with that of a geo-" "redundant load balancing use case." msgstr "" #: ../multi-site-prescriptive-examples.rst:181 msgid "" "In :ref:`ms-shared-keystone`, the application utilizing this multi-site " "OpenStack install that is location-aware would launch web server or content " "serving instances on the compute cluster in each site. Requests from clients " "are first sent to a global services load balancer that determines the " "location of the client, then routes the request to the closest OpenStack " "site where the application completes the request." msgstr "" #: ../multi-site-prescriptive-examples.rst:192 msgid "**Multi-site shared keystone architecture**" msgstr "" #: ../multi-site-technical-considerations.rst:5 msgid "" "There are many technical considerations to take into account with regard to " "designing a multi-site OpenStack implementation. An OpenStack cloud can be " "designed in a variety of ways to handle individual application needs. A " "multi-site deployment has additional challenges compared to single site " "installations and therefore is a more complex solution." msgstr "" #: ../multi-site-technical-considerations.rst:11 msgid "" "When determining capacity options be sure to take into account not just the " "technical issues, but also the economic or operational issues that might " "arise from specific decisions." msgstr "" #: ../multi-site-technical-considerations.rst:15 msgid "" "Inter-site link capacity describes the capabilities of the connectivity " "between the different OpenStack sites. This includes parameters such as " "bandwidth, latency, whether or not a link is dedicated, and any business " "policies applied to the connection. The capability and number of the links " "between sites determine what kind of options are available for deployment. " "For example, if two sites have a pair of high-bandwidth links available " "between them, it may be wise to configure a separate storage replication " "network between the two sites to support a single Swift endpoint and a " "shared Object Storage capability between them. An example of this technique, " "as well as a configuration walk-through, is available at http://docs." "openstack.org/developer/swift/replication_network.html#dedicated-replication-" "network. Another option in this scenario is to build a dedicated set of " "tenant private networks across the secondary link, using overlay networks " "with a third party mapping the site overlays to each other." msgstr "" #: ../multi-site-technical-considerations.rst:31 msgid "" "The capacity requirements of the links between sites is driven by " "application behavior. If the link latency is too high, certain applications " "that use a large number of small packets, for example RPC calls, may " "encounter issues communicating with each other or operating properly. " "Additionally, OpenStack may encounter similar types of issues. To mitigate " "this, Identity service call timeouts can be tuned to prevent issues " "authenticating against a central Identity service." msgstr "" #: ../multi-site-technical-considerations.rst:39 msgid "" "Another network capacity consideration for a multi-site deployment is the " "amount and performance of overlay networks available for tenant networks. If " "using shared tenant networks across zones, it is imperative that an external " "overlay manager or controller be used to map these overlays together. It is " "necessary to ensure the amount of possible IDs between the zones are " "identical." msgstr "" #: ../multi-site-technical-considerations.rst:48 msgid "" "As of the Kilo release, OpenStack Networking was not capable of managing " "tunnel IDs across installations. So if one site runs out of IDs, but another " "does not, that tenant's network is unable to reach the other site." msgstr "" #: ../multi-site-technical-considerations.rst:53 msgid "" "Capacity can take other forms as well. The ability for a region to grow " "depends on scaling out the number of available compute nodes. This topic is " "covered in greater detail in the section for compute-focused deployments. " "However, it may be necessary to grow cells in an individual region, " "depending on the size of your cluster and the ratio of virtual machines per " "hypervisor." msgstr "" #: ../multi-site-technical-considerations.rst:60 msgid "" "A third form of capacity comes in the multi-region-capable components of " "OpenStack. Centralized Object Storage is capable of serving objects through " "a single namespace across multiple regions. Since this works by accessing " "the object store through swift proxy, it is possible to overload the " "proxies. There are two options available to mitigate this issue:" msgstr "" #: ../multi-site-technical-considerations.rst:67 msgid "" "Deploy a large number of swift proxies. The drawback is that the proxies are " "not load-balanced and a large file request could continually hit the same " "proxy." msgstr "" #: ../multi-site-technical-considerations.rst:71 msgid "" "Add a caching HTTP proxy and load balancer in front of the swift proxies. " "Since swift objects are returned to the requester via HTTP, this load " "balancer would alleviate the load required on the swift proxies." msgstr "" #: ../multi-site-technical-considerations.rst:79 msgid "" "While constructing a multi-site OpenStack environment is the goal of this " "guide, the real test is whether an application can utilize it." msgstr "" #: ../multi-site-technical-considerations.rst:82 msgid "" "The Identity service is normally the first interface for OpenStack users and " "is required for almost all major operations within OpenStack. Therefore, it " "is important that you provide users with a single URL for Identity service " "authentication, and document the configuration of regions within the " "Identity service. Each of the sites defined in your installation is " "considered to be a region in Identity nomenclature. This is important for " "the users, as it is required to define the region name when providing " "actions to an API endpoint or in the dashboard." msgstr "" #: ../multi-site-technical-considerations.rst:91 msgid "" "Load balancing is another common issue with multi-site installations. While " "it is still possible to run HAproxy instances with Load-Balancer-as-a-" "Service, these are defined to a specific region. Some applications can " "manage this using internal mechanisms. Other applications may require the " "implementation of an external system, including global services load " "balancers or anycast-advertised DNS." msgstr "" #: ../multi-site-technical-considerations.rst:98 msgid "" "Depending on the storage model chosen during site design, storage " "replication and availability are also a concern for end-users. If an " "application can support regions, then it is possible to keep the object " "storage system separated by region. In this case, users who want to have an " "object available to more than one region need to perform cross-site " "replication. However, with a centralized swift proxy, the user may need to " "benchmark the replication timing of the Object Storage back end. " "Benchmarking allows the operational staff to provide users with an " "understanding of the amount of time required for a stored or modified object " "to become available to the entire environment." msgstr "" #: ../multi-site-technical-considerations.rst:112 msgid "" "Determining the performance of a multi-site installation involves " "considerations that do not come into play in a single-site deployment. Being " "a distributed deployment, performance in multi-site deployments may be " "affected in certain situations." msgstr "" #: ../multi-site-technical-considerations.rst:117 msgid "" "Since multi-site systems can be geographically separated, there may be " "greater latency or jitter when communicating across regions. This can " "especially impact systems like the OpenStack Identity service when making " "authentication attempts from regions that do not contain the centralized " "Identity implementation. It can also affect applications which rely on " "Remote Procedure Call (RPC) for normal operation. An example of this can be " "seen in high performance computing workloads." msgstr "" #: ../multi-site-technical-considerations.rst:125 msgid "" "Storage availability can also be impacted by the architecture of a multi-" "site deployment. A centralized Object Storage service requires more time for " "an object to be available to instances locally in regions where the object " "was not created. Some applications may need to be tuned to account for this " "effect. Block Storage does not currently have a method for replicating data " "across multiple regions, so applications that depend on available block " "storage need to manually cope with this limitation by creating duplicate " "block storage entries in each region." msgstr "" #: ../multi-site-technical-considerations.rst:137 msgid "" "Most OpenStack installations require a bare minimum set of pieces to " "function. These include the OpenStack Identity (keystone) for " "authentication, OpenStack Compute (nova) for compute, OpenStack Image " "service (glance) for image storage, OpenStack Networking (neutron) for " "networking, and potentially an object store in the form of OpenStack Object " "Storage (swift). Deploying a multi-site installation also demands extra " "components in order to coordinate between regions. A centralized Identity " "service is necessary to provide the single authentication point. A " "centralized dashboard is also recommended to provide a single login point " "and a mapping to the API and CLI options available. A centralized Object " "Storage service may also be used, but will require the installation of the " "swift proxy service." msgstr "" #: ../multi-site-technical-considerations.rst:150 msgid "" "It may also be helpful to install a few extra options in order to facilitate " "certain use cases. For example, installing Designate may assist in " "automatically generating DNS domains for each region with an automatically-" "populated zone full of resource records for each instance. This facilitates " "using DNS as a mechanism for determining which region will be selected for " "certain applications." msgstr "" #: ../multi-site-technical-considerations.rst:157 msgid "" "Another useful tool for managing a multi-site installation is Orchestration " "(heat). The Orchestration service allows the use of templates to define a " "set of instances to be launched together or for scaling existing sets. It " "can also be used to set up matching or differentiated groupings based on " "regions. For instance, if an application requires an equally balanced number " "of nodes across sites, the same heat template can be used to cover each site " "with small alterations to only the region name." msgstr "" #: ../multi-site-user-requirements.rst:6 msgid "Workload characteristics" msgstr "" #: ../multi-site-user-requirements.rst:8 msgid "" "An understanding of the expected workloads for a desired multi-site " "environment and use case is an important factor in the decision-making " "process. In this context, ``workload`` refers to the way the systems are " "used. A workload could be a single application or a suite of applications " "that work together. It could also be a duplicate set of applications that " "need to run in multiple cloud environments. Often in a multi-site " "deployment, the same workload will need to work identically in more than one " "physical location." msgstr "" #: ../multi-site-user-requirements.rst:17 msgid "" "This multi-site scenario likely includes one or more of the other scenarios " "in this book with the additional requirement of having the workloads in two " "or more locations. The following are some possible scenarios:" msgstr "" #: ../multi-site-user-requirements.rst:22 msgid "" "For many use cases the proximity of the user to their workloads has a direct " "influence on the performance of the application and therefore should be " "taken into consideration in the design. Certain applications require zero to " "minimal latency that can only be achieved by deploying the cloud in multiple " "locations. These locations could be in different data centers, cities, " "countries or geographical regions, depending on the user requirement and " "location of the users." msgstr "" #: ../multi-site-user-requirements.rst:31 msgid "Consistency of images and templates across different sites" msgstr "" #: ../multi-site-user-requirements.rst:33 msgid "" "It is essential that the deployment of instances is consistent across the " "different sites and built into the infrastructure. If the OpenStack Object " "Storage is used as a back end for the Image service, it is possible to " "create repositories of consistent images across multiple sites. Having " "central endpoints with multiple storage nodes allows consistent centralized " "storage for every site." msgstr "" #: ../multi-site-user-requirements.rst:40 msgid "" "Not using a centralized object store increases the operational overhead of " "maintaining a consistent image library. This could include development of a " "replication mechanism to handle the transport of images and the changes to " "the images across multiple sites." msgstr "" #: ../multi-site-user-requirements.rst:48 msgid "" "If high availability is a requirement to provide continuous infrastructure " "operations, a basic requirement of high availability should be defined." msgstr "" #: ../multi-site-user-requirements.rst:52 msgid "" "The OpenStack management components need to have a basic and minimal level " "of redundancy. The simplest example is the loss of any single site should " "have minimal impact on the availability of the OpenStack services." msgstr "" #: ../multi-site-user-requirements.rst:57 msgid "" "The `OpenStack High Availability Guide `_ contains more information on how to provide redundancy for the OpenStack " "components." msgstr "" #: ../multi-site-user-requirements.rst:61 msgid "" "Multiple network links should be deployed between sites to provide " "redundancy for all components. This includes storage replication, which " "should be isolated to a dedicated network or VLAN with the ability to assign " "QoS to control the replication traffic or provide priority for this traffic. " "Note that if the data store is highly changeable, the network requirements " "could have a significant effect on the operational cost of maintaining the " "sites." msgstr "" #: ../multi-site-user-requirements.rst:69 msgid "" "The ability to maintain object availability in both sites has significant " "implications on the object storage design and implementation. It also has a " "significant impact on the WAN network design between the sites." msgstr "" #: ../multi-site-user-requirements.rst:74 msgid "" "Connecting more than two sites increases the challenges and adds more " "complexity to the design considerations. Multi-site implementations require " "planning to address the additional topology used for internal and external " "connectivity. Some options include full mesh topology, hub spoke, spine " "leaf, and 3D Torus." msgstr "" #: ../multi-site-user-requirements.rst:80 msgid "" "If applications running in a cloud are not cloud-aware, there should be " "clear measures and expectations to define what the infrastructure can and " "cannot support. An example would be shared storage between sites. It is " "possible, however such a solution is not native to OpenStack and requires a " "third-party hardware vendor to fulfill such a requirement. Another example " "can be seen in applications that are able to consume resources in object " "storage directly. These applications need to be cloud aware to make good use " "of an OpenStack Object Store." msgstr "" #: ../multi-site-user-requirements.rst:92 msgid "" "Some applications are tolerant of the lack of synchronized object storage, " "while others may need those objects to be replicated and available across " "regions. Understanding how the cloud implementation impacts new and existing " "applications is important for risk mitigation, and the overall success of a " "cloud project. Applications may have to be written or rewritten for an " "infrastructure with little to no redundancy, or with the cloud in mind." msgstr "" #: ../multi-site-user-requirements.rst:103 msgid "" "A greater number of sites increase cost and complexity for a multi-site " "deployment. Costs can be broken down into the following categories:" msgstr "" #: ../multi-site-user-requirements.rst:106 msgid "Compute resources" msgstr "" #: ../multi-site-user-requirements.rst:108 msgid "Networking resources" msgstr "" #: ../multi-site-user-requirements.rst:110 msgid "Replication" msgstr "" #: ../multi-site-user-requirements.rst:116 msgid "Operational costs" msgstr "" #: ../multi-site-user-requirements.rst:119 msgid "Site loss and recovery" msgstr "" #: ../multi-site-user-requirements.rst:121 msgid "" "Outages can cause partial or full loss of site functionality. Strategies " "should be implemented to understand and plan for recovery scenarios." msgstr "" #: ../multi-site-user-requirements.rst:124 msgid "" "The deployed applications need to continue to function and, more " "importantly, you must consider the impact on the performance and reliability " "of the application when a site is unavailable." msgstr "" #: ../multi-site-user-requirements.rst:128 msgid "" "It is important to understand what happens to the replication of objects and " "data between the sites when a site goes down. If this causes queues to start " "building up, consider how long these queues can safely exist until an error " "occurs." msgstr "" #: ../multi-site-user-requirements.rst:133 msgid "" "After an outage, ensure the method for resuming proper operations of a site " "is implemented when it comes back online. We recommend you architect the " "recovery to avoid race conditions." msgstr "" #: ../multi-site-user-requirements.rst:138 msgid "Compliance and geo-location" msgstr "" #: ../multi-site-user-requirements.rst:140 msgid "" "An organization may have certain legal obligations and regulatory compliance " "measures which could require certain workloads or data to not be located in " "certain regions." msgstr "" #: ../multi-site-user-requirements.rst:145 msgid "Auditing" msgstr "" #: ../multi-site-user-requirements.rst:147 msgid "" "A well thought-out auditing strategy is important in order to be able to " "quickly track down issues. Keeping track of changes made to security groups " "and tenant changes can be useful in rolling back the changes if they affect " "production. For example, if all security group rules for a tenant " "disappeared, the ability to quickly track down the issue would be important " "for operational and legal reasons." msgstr "" #: ../multi-site-user-requirements.rst:155 msgid "Separation of duties" msgstr "" #: ../multi-site-user-requirements.rst:157 msgid "" "A common requirement is to define different roles for the different cloud " "administration functions. An example would be a requirement to segregate the " "duties and permissions by site." msgstr "" #: ../multi-site-user-requirements.rst:162 msgid "Authentication between sites" msgstr "" #: ../multi-site-user-requirements.rst:164 msgid "" "It is recommended to have a single authentication domain rather than a " "separate implementation for each and every site. This requires an " "authentication mechanism that is highly available and distributed to ensure " "continuous operation. Authentication server locality might be required and " "should be planned for." msgstr "" #: ../multi-site.rst:3 msgid "Multi-site" msgstr "" #: ../multi-site.rst:14 msgid "" "OpenStack is capable of running in a multi-region configuration. This " "enables some parts of OpenStack to effectively manage a group of sites as a " "single cloud." msgstr "" #: ../multi-site.rst:18 msgid "" "Some use cases that might indicate a need for a multi-site deployment of " "OpenStack include:" msgstr "" #: ../multi-site.rst:21 msgid "An organization with a diverse geographic footprint." msgstr "" #: ../multi-site.rst:23 msgid "Geo-location sensitive data." msgstr "" #: ../multi-site.rst:25 msgid "" "Data locality, in which specific data or functionality should be close to " "users." msgstr "" #: ../network-focus-architecture.rst:4 msgid "" "Network-focused OpenStack architectures have many similarities to other " "OpenStack architecture use cases. There are several factors to consider when " "designing for a network-centric or network-heavy application environment." msgstr "" #: ../network-focus-architecture.rst:9 msgid "" "Networks exist to serve as a medium of transporting data between systems. It " "is inevitable that an OpenStack design has inter-dependencies with non-" "network portions of OpenStack as well as on external systems. Depending on " "the specific workload, there may be major interactions with storage systems " "both within and external to the OpenStack environment. For example, in the " "case of content delivery network, there is twofold interaction with storage. " "Traffic flows to and from the storage array for ingesting and serving " "content in a north-south direction. In addition, there is replication " "traffic flowing in an east-west direction." msgstr "" #: ../network-focus-architecture.rst:20 msgid "" "Compute-heavy workloads may also induce interactions with the network. Some " "high performance compute applications require network-based memory mapping " "and data sharing and, as a result, induce a higher network load when they " "transfer results and data sets. Others may be highly transactional and issue " "transaction locks, perform their functions, and revoke transaction locks at " "high rates. This also has an impact on the network performance." msgstr "" #: ../network-focus-architecture.rst:28 msgid "" "Some network dependencies are external to OpenStack. While OpenStack " "Networking is capable of providing network ports, IP addresses, some level " "of routing, and overlay networks, there are some other functions that it " "cannot provide. For many of these, you may require external systems or " "equipment to fill in the functional gaps. Hardware load balancers are an " "example of equipment that may be necessary to distribute workloads or " "offload certain functions. OpenStack Networking provides a tunneling " "feature, however it is constrained to a Networking-managed region. If the " "need arises to extend a tunnel beyond the OpenStack region to either another " "region or an external system, implement the tunnel itself outside OpenStack " "or use a tunnel management system to map the tunnel or overlay to an " "external tunnel." msgstr "" #: ../network-focus-architecture.rst:41 msgid "" "Depending on the selected design, Networking itself might not support the " "required :term:`layer-3 network` functionality. If you " "choose to use the provider networking mode without running the layer-3 " "agent, you must install an external router to provide layer-3 connectivity " "to outside systems." msgstr "" #: ../network-focus-architecture.rst:47 msgid "" "Interaction with orchestration services is inevitable in larger-scale " "deployments. The Orchestration service is capable of allocating network " "resource defined in templates to map to tenant networks and for port " "creation, as well as allocating floating IPs. If there is a requirement to " "define and manage network resources when using orchestration, we recommend " "that the design include the Orchestration service to meet the demands of " "users." msgstr "" #: ../network-focus-architecture.rst:56 msgid "Design impacts" msgstr "" #: ../network-focus-architecture.rst:58 msgid "" "A wide variety of factors can affect a network-focused OpenStack " "architecture. While there are some considerations shared with a general use " "case, specific workloads related to network requirements influence network " "design decisions." msgstr "" #: ../network-focus-architecture.rst:63 msgid "" "One decision includes whether or not to use Network Address Translation " "(NAT) and where to implement it. If there is a requirement for floating IPs " "instead of public fixed addresses then you must use NAT. An example of this " "is a DHCP relay that must know the IP of the DHCP server. In these cases it " "is easier to automate the infrastructure to apply the target IP to a new " "instance rather than to reconfigure legacy or external systems for each new " "instance." msgstr "" #: ../network-focus-architecture.rst:71 msgid "" "NAT for floating IPs managed by Networking resides within the hypervisor but " "there are also versions of NAT that may be running elsewhere. If there is a " "shortage of IPv4 addresses there are two common methods to mitigate this " "externally to OpenStack. The first is to run a load balancer either within " "OpenStack as an instance, or use an external load balancing solution. In the " "internal scenario, Networking's Load-Balancer-as-a-Service (LBaaS) can " "manage load balancing software, for example HAproxy. This is specifically to " "manage the Virtual IP (VIP) while a dual-homed connection from the HAproxy " "instance connects the public network with the tenant private network that " "hosts all of the content servers. In the external scenario, a load balancer " "needs to serve the VIP and also connect to the tenant overlay network " "through external means or through private addresses." msgstr "" #: ../network-focus-architecture.rst:85 msgid "" "Another kind of NAT that may be useful is protocol NAT. In some cases it may " "be desirable to use only IPv6 addresses on instances and operate either an " "instance or an external service to provide a NAT-based transition technology " "such as NAT64 and DNS64. This provides the ability to have a globally " "routable IPv6 address while only consuming IPv4 addresses as necessary or in " "a shared manner." msgstr "" #: ../network-focus-architecture.rst:92 msgid "" "Application workloads affect the design of the underlying network " "architecture. If a workload requires network-level redundancy, the routing " "and switching architecture have to accommodate this. There are differing " "methods for providing this that are dependent on the selected network " "hardware, the performance of the hardware, and which networking model you " "deploy. Examples include Link aggregation (LAG) and Hot Standby Router " "Protocol (HSRP). Also consider whether to deploy OpenStack Networking or " "legacy networking (nova-network), and which plug-in to select for OpenStack " "Networking. If using an external system, configure Networking to run :term:" "`layer-2` with a provider network configuration. For " "example, implement HSRP to terminate layer-3 connectivity." msgstr "" #: ../network-focus-architecture.rst:105 msgid "" "Depending on the workload, overlay networks may not be the best solution. " "Where application network connections are small, short lived, or bursty, " "running a dynamic overlay can generate as much bandwidth as the packets it " "carries. It also can induce enough latency to cause issues with certain " "applications. There is an impact to the device generating the overlay which, " "in most installations, is the hypervisor. This causes performance " "degradation on packet per second and connection per second rates." msgstr "" #: ../network-focus-architecture.rst:114 msgid "" "Overlays also come with a secondary option that may not be appropriate to a " "specific workload. While all of them operate in full mesh by default, there " "might be good reasons to disable this function because it may cause " "excessive overhead for some workloads. Conversely, other workloads operate " "without issue. For example, most web services applications do not have major " "issues with a full mesh overlay network, while some network monitoring tools " "or storage replication workloads have performance issues with throughput or " "excessive broadcast traffic." msgstr "" #: ../network-focus-architecture.rst:123 msgid "" "Many people overlook an important design decision: The choice of layer-3 " "protocols. While OpenStack was initially built with only IPv4 support, " "Networking now supports IPv6 and dual-stacked networks. Some workloads are " "possible through the use of IPv6 and IPv6 to IPv4 reverse transition " "mechanisms such as NAT64 and DNS64 or :term:`6to4`. This alters the " "requirements for any address plan as single-stacked and transitional IPv6 " "deployments can alleviate the need for IPv4 addresses." msgstr "" #: ../network-focus-architecture.rst:131 msgid "" "OpenStack has limited support for dynamic routing, however there are a " "number of options available by incorporating third party solutions to " "implement routing within the cloud including network equipment, hardware " "nodes, and instances. Some workloads perform well with nothing more than " "static routes and default gateways configured at the layer-3 termination " "point. In most cases this is sufficient, however some cases require the " "addition of at least one type of dynamic routing protocol if not multiple " "protocols. Having a form of interior gateway protocol (IGP) available to the " "instances inside an OpenStack installation opens up the possibility of use " "cases for anycast route injection for services that need to use it as a " "geographic location or failover mechanism. Other applications may wish to " "directly participate in a routing protocol, either as a passive observer, as " "in the case of a looking glass, or as an active participant in the form of a " "route reflector. Since an instance might have a large amount of compute and " "memory resources, it is trivial to hold an entire unpartitioned routing " "table and use it to provide services such as network path visibility to " "other applications or as a monitoring tool." msgstr "" #: ../network-focus-architecture.rst:150 msgid "" "Path maximum transmission unit (MTU) failures are lesser known but harder to " "diagnose. The MTU must be large enough to handle normal traffic, overhead " "from an overlay network, and the desired layer-3 protocol. Adding externally " "built tunnels reduces the MTU packet size. In this case, you must pay " "attention to the fully calculated MTU size because some systems ignore or " "drop path MTU discovery packets." msgstr "" #: ../network-focus-architecture.rst:158 msgid "Tunable networking components" msgstr "" #: ../network-focus-architecture.rst:160 msgid "" "Consider configurable networking components related to an OpenStack " "architecture design when designing for network intensive workloads that " "include MTU and QoS. Some workloads require a larger MTU than normal due to " "the transfer of large blocks of data. When providing network service for " "applications such as video streaming or storage replication, we recommend " "that you configure both OpenStack hardware nodes and the supporting network " "equipment for jumbo frames where possible. This allows for better use of " "available bandwidth. Configure jumbo frames across the complete path the " "packets traverse. If one network component is not capable of handling jumbo " "frames then the entire path reverts to the default MTU." msgstr "" #: ../network-focus-architecture.rst:172 msgid "" "Quality of Service (QoS) also has a great impact on network intensive " "workloads as it provides instant service to packets which have a higher " "priority due to the impact of poor network performance. In applications such " "as Voice over IP (VoIP), differentiated services code points are a near " "requirement for proper operation. You can also use QoS in the opposite " "direction for mixed workloads to prevent low priority but high bandwidth " "applications, for example backup services, video conferencing, or file " "sharing, from blocking bandwidth that is needed for the proper operation of " "other workloads. It is possible to tag file storage traffic as a lower " "class, such as best effort or scavenger, to allow the higher priority " "traffic through. In cases where regions within a cloud might be " "geographically distributed it may also be necessary to plan accordingly to " "implement WAN optimization to combat latency or packet loss." msgstr "" #: ../network-focus-operational-considerations.rst:4 msgid "" "Network-focused OpenStack clouds have a number of operational considerations " "that influence the selected design, including:" msgstr "" #: ../network-focus-operational-considerations.rst:7 msgid "Dynamic routing of static routes" msgstr "" #: ../network-focus-operational-considerations.rst:9 msgid "Service level agreements (SLAs)" msgstr "" #: ../network-focus-operational-considerations.rst:11 msgid "Ownership of user management" msgstr "" #: ../network-focus-operational-considerations.rst:13 msgid "" "An initial network consideration is the selection of a telecom company or " "transit provider." msgstr "" #: ../network-focus-operational-considerations.rst:16 msgid "" "Make additional design decisions about monitoring and alarming. This can be " "an internal responsibility or the responsibility of the external provider. " "In the case of using an external provider, service level agreements (SLAs) " "likely apply. In addition, other operational considerations such as " "bandwidth, latency, and jitter can be part of an SLA." msgstr "" #: ../network-focus-operational-considerations.rst:23 msgid "" "Consider the ability to upgrade the infrastructure. As demand for network " "resources increase, operators add additional IP address blocks and add " "additional bandwidth capacity. In addition, consider managing hardware and " "software lifecycle events, for example upgrades, decommissioning, and " "outages, while avoiding service interruptions for tenants." msgstr "" #: ../network-focus-operational-considerations.rst:30 msgid "" "Factor maintainability into the overall network design. This includes the " "ability to manage and maintain IP addresses as well as the use of overlay " "identifiers including VLAN tag IDs, GRE tunnel IDs, and MPLS tags. As an " "example, if you may need to change all of the IP addresses on a network, a " "process known as renumbering, then the design must support this function." msgstr "" #: ../network-focus-operational-considerations.rst:37 msgid "" "Address network-focused applications when considering certain operational " "realities. For example, consider the impending exhaustion of IPv4 addresses, " "the migration to IPv6, and the use of private networks to segregate " "different types of traffic that an application receives or generates. In the " "case of IPv4 to IPv6 migrations, applications should follow best practices " "for storing IP addresses. We recommend you avoid relying on IPv4 features " "that did not carry over to the IPv6 protocol or have differences in " "implementation." msgstr "" #: ../network-focus-operational-considerations.rst:46 msgid "" "To segregate traffic, allow applications to create a private tenant network " "for database and storage network traffic. Use a public network for services " "that require direct client access from the internet. Upon segregating the " "traffic, consider quality of service (QoS) and security to ensure each " "network has the required level of service." msgstr "" #: ../network-focus-operational-considerations.rst:52 msgid "" "Finally, consider the routing of network traffic. For some applications, " "develop a complex policy framework for routing. To create a routing policy " "that satisfies business requirements, consider the economic cost of " "transmitting traffic over expensive links versus cheaper links, in addition " "to bandwidth, latency, and jitter requirements." msgstr "" #: ../network-focus-operational-considerations.rst:58 msgid "" "Additionally, consider how to respond to network events. As an example, how " "load transfers from one link to another during a failure scenario could be a " "factor in the design. If you do not plan network capacity correctly, " "failover traffic could overwhelm other ports or network links and create a " "cascading failure scenario. In this case, traffic that fails over to one " "link overwhelms that link and then moves to the subsequent links until all " "network traffic stops." msgstr "" #: ../network-focus-prescriptive-examples.rst:4 msgid "" "An organization designs a large-scale web application with cloud principles " "in mind. The application scales horizontally in a bursting fashion and " "generates a high instance count. The application requires an SSL connection " "to secure data and must not lose connection state to individual servers." msgstr "" #: ../network-focus-prescriptive-examples.rst:10 msgid "" "The figure below depicts an example design for this workload. In this " "example, a hardware load balancer provides SSL offload functionality and " "connects to tenant networks in order to reduce address consumption. This " "load balancer links to the routing architecture as it services the VIP for " "the application. The router and load balancer use the GRE tunnel ID of the " "application's tenant network and an IP address within the tenant subnet but " "outside of the address pool. This is to ensure that the load balancer can " "communicate with the application's HTTP servers without requiring the " "consumption of a public IP address." msgstr "" #: ../network-focus-prescriptive-examples.rst:20 msgid "" "Because sessions persist until closed, the routing and switching " "architecture provides high availability. Switches mesh to each hypervisor " "and each other, and also provide an MLAG implementation to ensure that " "layer-2 connectivity does not fail. Routers use VRRP and fully mesh with " "switches to ensure layer-3 connectivity. Since GRE is provides an overlay " "network, Networking is present and uses the Open vSwitch agent in GRE tunnel " "mode. This ensures all devices can reach all other devices and that you can " "create tenant networks for private addressing links to the load balancer." msgstr "" #: ../network-focus-prescriptive-examples.rst:32 msgid "" "A web service architecture has many options and optional components. Due to " "this, it can fit into a large number of other OpenStack designs. A few key " "components, however, need to be in place to handle the nature of most web-" "scale workloads. You require the following components:" msgstr "" #: ../network-focus-prescriptive-examples.rst:37 msgid "" "OpenStack Controller services (Image, Identity, Networking and supporting " "services such as MariaDB and RabbitMQ)" msgstr "" #: ../network-focus-prescriptive-examples.rst:40 msgid "OpenStack Compute running KVM hypervisor" msgstr "" #: ../network-focus-prescriptive-examples.rst:42 msgid "OpenStack Object Storage" msgstr "" #: ../network-focus-prescriptive-examples.rst:44 msgid "Orchestration service" msgstr "" #: ../network-focus-prescriptive-examples.rst:46 msgid "Telemetry service" msgstr "" #: ../network-focus-prescriptive-examples.rst:48 msgid "" "Beyond the normal Identity, Compute, Image service, and Object Storage " "components, we recommend the Orchestration service component to handle the " "proper scaling of workloads to adjust to demand. Due to the requirement for " "auto-scaling, the design includes the Telemetry service. Web services tend " "to be bursty in load, have very defined peak and valley usage patterns and, " "as a result, benefit from automatic scaling of instances based upon traffic. " "At a network level, a split network configuration works well with databases " "residing on private tenant networks since these do not emit a large quantity " "of broadcast traffic and may need to interconnect to some databases for " "content." msgstr "" #: ../network-focus-prescriptive-examples.rst:60 msgid "Load balancing" msgstr "" #: ../network-focus-prescriptive-examples.rst:62 msgid "" "Load balancing spreads requests across multiple instances. This workload " "scales well horizontally across large numbers of instances. This enables " "instances to run without publicly routed IP addresses and instead to rely on " "the load balancer to provide a globally reachable service. Many of these " "services do not require direct server return. This aids in address planning " "and utilization at scale since only the virtual IP (VIP) must be public." msgstr "" #: ../network-focus-prescriptive-examples.rst:71 msgid "Overlay networks" msgstr "" #: ../network-focus-prescriptive-examples.rst:73 msgid "" "The overlay functionality design includes OpenStack Networking in Open " "vSwitch GRE tunnel mode. In this case, the layer-3 external routers pair " "with VRRP, and switches pair with an implementation of MLAG to ensure that " "you do not lose connectivity with the upstream routing infrastructure." msgstr "" #: ../network-focus-prescriptive-examples.rst:80 msgid "Performance tuning" msgstr "" #: ../network-focus-prescriptive-examples.rst:82 msgid "" "Network level tuning for this workload is minimal. Quality-of-Service (QoS) " "applies to these workloads for a middle ground Class Selector depending on " "existing policies. It is higher than a best effort queue but lower than an " "Expedited Forwarding or Assured Forwarding queue. Since this type of " "application generates larger packets with longer-lived connections, you can " "optimize bandwidth utilization for long duration TCP. Normal bandwidth " "planning applies here with regards to benchmarking a session's usage " "multiplied by the expected number of concurrent sessions with overhead." msgstr "" #: ../network-focus-prescriptive-examples.rst:93 msgid "Network functions" msgstr "" #: ../network-focus-prescriptive-examples.rst:95 msgid "" "Network functions is a broad category but encompasses workloads that support " "the rest of a system's network. These workloads tend to consist of large " "amounts of small packets that are very short lived, such as DNS queries or " "SNMP traps. These messages need to arrive quickly and do not deal with " "packet loss as there can be a very large volume of them. There are a few " "extra considerations to take into account for this type of workload and this " "can change a configuration all the way to the hypervisor level. For an " "application that generates 10 TCP sessions per user with an average " "bandwidth of 512 kilobytes per second per flow and expected user count of " "ten thousand concurrent users, the expected bandwidth plan is approximately " "4.88 gigabits per second." msgstr "" #: ../network-focus-prescriptive-examples.rst:107 msgid "" "The supporting network for this type of configuration needs to have a low " "latency and evenly distributed availability. This workload benefits from " "having services local to the consumers of the service. Use a multi-site " "approach as well as deploying many copies of the application to handle load " "as close as possible to consumers. Since these applications function " "independently, they do not warrant running overlays to interconnect tenant " "networks. Overlays also have the drawback of performing poorly with rapid " "flow setup and may incur too much overhead with large quantities of small " "packets and therefore we do not recommend them." msgstr "" #: ../network-focus-prescriptive-examples.rst:118 msgid "" "QoS is desirable for some workloads to ensure delivery. DNS has a major " "impact on the load times of other services and needs to be reliable and " "provide rapid responses. Configure rules in upstream devices to apply a " "higher Class Selector to DNS to ensure faster delivery or a better spot in " "queuing algorithms." msgstr "" #: ../network-focus-prescriptive-examples.rst:125 msgid "Cloud storage" msgstr "" #: ../network-focus-prescriptive-examples.rst:127 msgid "" "Another common use case for OpenStack environments is providing a cloud-" "based file storage and sharing service. You might consider this a storage-" "focused use case, but its network-side requirements make it a network-" "focused use case." msgstr "" #: ../network-focus-prescriptive-examples.rst:132 msgid "" "For example, consider a cloud backup application. This workload has two " "specific behaviors that impact the network. Because this workload is an " "externally-facing service and an internally-replicating application, it has " "both :term:`north-south` and :term:`east-west` traffic considerations:" msgstr "" #: ../network-focus-prescriptive-examples.rst:139 msgid "" "When a user uploads and stores content, that content moves into the " "OpenStack installation. When users download this content, the content moves " "out from the OpenStack installation. Because this service operates primarily " "as a backup, most of the traffic moves southbound into the environment. In " "this situation, it benefits you to configure a network to be asymmetrically " "downstream because the traffic that enters the OpenStack installation is " "greater than the traffic that leaves the installation." msgstr "" #: ../network-focus-prescriptive-examples.rst:146 msgid "north-south traffic" msgstr "" #: ../network-focus-prescriptive-examples.rst:149 msgid "" "Likely to be fully symmetric. Because replication originates from any node " "and might target multiple other nodes algorithmically, it is less likely for " "this traffic to have a larger volume in any specific direction. However this " "traffic might interfere with north-south traffic." msgstr "" #: ../network-focus-prescriptive-examples.rst:153 msgid "east-west traffic" msgstr "" #: ../network-focus-prescriptive-examples.rst:157 msgid "" "This application prioritizes the north-south traffic over east-west traffic: " "the north-south traffic involves customer-facing data." msgstr "" #: ../network-focus-prescriptive-examples.rst:160 msgid "" "The network design in this case is less dependent on availability and more " "dependent on being able to handle high bandwidth. As a direct result, it is " "beneficial to forgo redundant links in favor of bonding those connections. " "This increases available bandwidth. It is also beneficial to configure all " "devices in the path, including OpenStack, to generate and pass jumbo frames." msgstr "" #: ../network-focus-technical-considerations.rst:0 msgid "" "**Redundant networking: ToR switch high availability risk " "analysis**" msgstr "" #: ../network-focus-technical-considerations.rst:4 msgid "" "When you design an OpenStack network architecture, you must consider layer-2 " "and layer-3 issues. Layer-2 decisions involve those made at the data-link " "layer, such as the decision to use Ethernet versus Token Ring. Layer-3 " "decisions involve those made about the protocol layer and the point when IP " "comes into the picture. As an example, a completely internal OpenStack " "network can exist at layer 2 and ignore layer 3. In order for any traffic to " "go outside of that cloud, to another network, or to the Internet, however, " "you must use a layer-3 router or switch." msgstr "" #: ../network-focus-technical-considerations.rst:13 msgid "" "The past few years have seen two competing trends in networking. One trend " "leans towards building data center network architectures based on layer-2 " "networking. Another trend treats the cloud environment essentially as a " "miniature version of the Internet. This approach is radically different from " "the network architecture approach in the staging environment: the Internet " "only uses layer-3 routing rather than layer-2 switching." msgstr "" #: ../network-focus-technical-considerations.rst:21 msgid "" "A network designed on layer-2 protocols has advantages over one designed on " "layer-3 protocols. In spite of the difficulties of using a bridge to perform " "the network role of a router, many vendors, customers, and service providers " "choose to use Ethernet in as many parts of their networks as possible. The " "benefits of selecting a layer-2 design are:" msgstr "" #: ../network-focus-technical-considerations.rst:27 msgid "" "Ethernet frames contain all the essentials for networking. These include, " "but are not limited to, globally unique source addresses, globally unique " "destination addresses, and error control." msgstr "" #: ../network-focus-technical-considerations.rst:31 msgid "" "Ethernet frames can carry any kind of packet. Networking at layer-2 is " "independent of the layer-3 protocol." msgstr "" #: ../network-focus-technical-considerations.rst:34 msgid "" "Adding more layers to the Ethernet frame only slows the networking process " "down. This is known as 'nodal processing delay'." msgstr "" #: ../network-focus-technical-considerations.rst:37 msgid "" "You can add adjunct networking features, for example class of service (CoS) " "or multicasting, to Ethernet as readily as IP networks." msgstr "" #: ../network-focus-technical-considerations.rst:40 msgid "VLANs are an easy mechanism for isolating networks." msgstr "" #: ../network-focus-technical-considerations.rst:42 msgid "" "Most information starts and ends inside Ethernet frames. Today this applies " "to data, voice (for example, VoIP), and video (for example, web cameras). " "The concept is that if you can perform more of the end-to-end transfer of " "information from a source to a destination in the form of Ethernet frames, " "the network benefits more from the advantages of Ethernet. Although it is " "not a substitute for IP networking, networking at layer-2 can be a powerful " "adjunct to IP networking." msgstr "" #: ../network-focus-technical-considerations.rst:50 msgid "" "Layer-2 Ethernet usage has these advantages over layer-3 IP network usage:" msgstr "" #: ../network-focus-technical-considerations.rst:53 msgid "Speed" msgstr "" #: ../network-focus-technical-considerations.rst:55 msgid "Reduced overhead of the IP hierarchy." msgstr "" #: ../network-focus-technical-considerations.rst:57 msgid "" "No need to keep track of address configuration as systems move around. " "Whereas the simplicity of layer-2 protocols might work well in a data center " "with hundreds of physical machines, cloud data centers have the additional " "burden of needing to keep track of all virtual machine addresses and " "networks. In these data centers, it is not uncommon for one physical node to " "support 30-40 instances." msgstr "" #: ../network-focus-technical-considerations.rst:66 msgid "" "Networking at the frame level says nothing about the presence or absence of " "IP addresses at the packet level. Almost all ports, links, and devices on a " "network of LAN switches still have IP addresses, as do all the source and " "destination hosts. There are many reasons for the continued need for IP " "addressing. The largest one is the need to manage the network. A device or " "link without an IP address is usually invisible to most management " "applications. Utilities including remote access for diagnostics, file " "transfer of configurations and software, and similar applications cannot run " "without IP addresses as well as MAC addresses." msgstr "" #: ../network-focus-technical-considerations.rst:78 msgid "Layer-2 architecture limitations" msgstr "" #: ../network-focus-technical-considerations.rst:80 msgid "" "Outside of the traditional data center the limitations of layer-2 network " "architectures become more obvious." msgstr "" #: ../network-focus-technical-considerations.rst:83 msgid "Number of VLANs is limited to 4096." msgstr "" #: ../network-focus-technical-considerations.rst:85 msgid "The number of MACs stored in switch tables is limited." msgstr "" #: ../network-focus-technical-considerations.rst:87 msgid "" "You must accommodate the need to maintain a set of layer-4 devices to handle " "traffic control." msgstr "" #: ../network-focus-technical-considerations.rst:90 msgid "" "MLAG, often used for switch redundancy, is a proprietary solution that does " "not scale beyond two devices and forces vendor lock-in." msgstr "" #: ../network-focus-technical-considerations.rst:93 msgid "" "It can be difficult to troubleshoot a network without IP addresses and ICMP." msgstr "" #: ../network-focus-technical-considerations.rst:96 msgid "" "Configuring :term:`ARP
` can be " "complicated on large layer-2 networks." msgstr "" #: ../network-focus-technical-considerations.rst:99 msgid "" "All network devices need to be aware of all MACs, even instance MACs, so " "there is constant churn in MAC tables and network state changes as instances " "start and stop." msgstr "" #: ../network-focus-technical-considerations.rst:103 msgid "" "Migrating MACs (instance migration) to different physical locations are a " "potential problem if you do not set ARP table timeouts properly." msgstr "" #: ../network-focus-technical-considerations.rst:107 msgid "" "It is important to know that layer-2 has a very limited set of network " "management tools. It is very difficult to control traffic, as it does not " "have mechanisms to manage the network or shape the traffic, and network " "troubleshooting is very difficult. One reason for this difficulty is network " "devices have no IP addresses. As a result, there is no reasonable way to " "check network delay in a layer-2 network." msgstr "" #: ../network-focus-technical-considerations.rst:114 msgid "" "On large layer-2 networks, configuring ARP learning can also be complicated. " "The setting for the MAC address timer on switches is critical and, if set " "incorrectly, can cause significant performance problems. As an example, the " "Cisco default MAC address timer is extremely long. Migrating MACs to " "different physical locations to support instance migration can be a " "significant problem. In this case, the network information maintained in the " "switches could be out of sync with the new location of the instance." msgstr "" #: ../network-focus-technical-considerations.rst:123 msgid "" "In a layer-2 network, all devices are aware of all MACs, even those that " "belong to instances. The network state information in the backbone changes " "whenever an instance starts or stops. As a result there is far too much " "churn in the MAC tables on the backbone switches." msgstr "" #: ../network-focus-technical-considerations.rst:129 msgid "Layer-3 architecture advantages" msgstr "" #: ../network-focus-technical-considerations.rst:131 msgid "" "In the layer-3 case, there is no churn in the routing tables due to " "instances starting and stopping. The only time there would be a routing " "state change is in the case of a Top of Rack (ToR) switch failure or a link " "failure in the backbone itself. Other advantages of using a layer-3 " "architecture include:" msgstr "" #: ../network-focus-technical-considerations.rst:137 msgid "" "Layer-3 networks provide the same level of resiliency and scalability as the " "Internet." msgstr "" #: ../network-focus-technical-considerations.rst:140 msgid "Controlling traffic with routing metrics is straightforward." msgstr "" #: ../network-focus-technical-considerations.rst:142 msgid "" "You can configure layer 3 to use :term:`BGP` " "confederation for scalability so core routers have state proportional to the " "number of racks, not to the number of servers or instances." msgstr "" #: ../network-focus-technical-considerations.rst:146 msgid "" "Routing takes instance MAC and IP addresses out of the network core, " "reducing state churn. Routing state changes only occur in the case of a ToR " "switch failure or backbone link failure." msgstr "" #: ../network-focus-technical-considerations.rst:150 msgid "" "There are a variety of well tested tools, for example ICMP, to monitor and " "manage traffic." msgstr "" #: ../network-focus-technical-considerations.rst:153 msgid "" "Layer-3 architectures enable the use of Quality of Service (QoS) to manage " "network performance." msgstr "" #: ../network-focus-technical-considerations.rst:157 msgid "Layer-3 architecture limitations" msgstr "" #: ../network-focus-technical-considerations.rst:159 msgid "" "The main limitation of layer 3 is that there is no built-in isolation " "mechanism comparable to the VLANs in layer-2 networks. Furthermore, the " "hierarchical nature of IP addresses means that an instance is on the same " "subnet as its physical host. This means that you cannot migrate it outside " "of the subnet easily. For these reasons, network virtualization needs to use " "IP :term:`encapsulation` and software at the end hosts for isolation and the " "separation of the addressing in the virtual layer from the addressing in the " "physical layer. Other potential disadvantages of layer 3 include the need to " "design an IP addressing scheme rather than relying on the switches to keep " "track of the MAC addresses automatically and to configure the interior " "gateway routing protocol in the switches." msgstr "" #: ../network-focus-technical-considerations.rst:172 msgid "Network recommendations overview" msgstr "" #: ../network-focus-technical-considerations.rst:174 msgid "" "OpenStack has complex networking requirements for several reasons. Many " "components interact at different levels of the system stack that adds " "complexity. Data flows are complex. Data in an OpenStack cloud moves both " "between instances across the network (also known as East-West), as well as " "in and out of the system (also known as North-South). Physical server nodes " "have network requirements that are independent of instance network " "requirements, which you must isolate from the core network to account for " "scalability. We recommend functionally separating the networks for security " "purposes and tuning performance through traffic shaping." msgstr "" #: ../network-focus-technical-considerations.rst:185 msgid "" "You must consider a number of important general technical and business " "factors when planning and designing an OpenStack network. They include:" msgstr "" #: ../network-focus-technical-considerations.rst:188 msgid "" "A requirement for vendor independence. To avoid hardware or software vendor " "lock-in, the design should not rely on specific features of a vendor's " "router or switch." msgstr "" #: ../network-focus-technical-considerations.rst:192 msgid "" "A requirement to massively scale the ecosystem to support millions of end " "users." msgstr "" #: ../network-focus-technical-considerations.rst:195 msgid "A requirement to support indeterminate platforms and applications." msgstr "" #: ../network-focus-technical-considerations.rst:197 msgid "" "A requirement to design for cost efficient operations to take advantage of " "massive scale." msgstr "" #: ../network-focus-technical-considerations.rst:200 msgid "" "A requirement to ensure that there is no single point of failure in the " "cloud ecosystem." msgstr "" #: ../network-focus-technical-considerations.rst:203 msgid "" "A requirement for high availability architecture to meet customer SLA " "requirements." msgstr "" #: ../network-focus-technical-considerations.rst:206 msgid "A requirement to be tolerant of rack level failure." msgstr "" #: ../network-focus-technical-considerations.rst:208 msgid "" "A requirement to maximize flexibility to architect future production " "environments." msgstr "" #: ../network-focus-technical-considerations.rst:211 msgid "Bearing in mind these considerations, we recommend the following:" msgstr "" #: ../network-focus-technical-considerations.rst:213 msgid "Layer-3 designs are preferable to layer-2 architectures." msgstr "" #: ../network-focus-technical-considerations.rst:215 msgid "" "Design a dense multi-path network core to support multi-directional scaling " "and flexibility." msgstr "" #: ../network-focus-technical-considerations.rst:218 msgid "" "Use hierarchical addressing because it is the only viable option to scale " "network ecosystem." msgstr "" #: ../network-focus-technical-considerations.rst:221 msgid "" "Use virtual networking to isolate instance service network traffic from the " "management and internal network traffic." msgstr "" #: ../network-focus-technical-considerations.rst:224 msgid "Isolate virtual networks using encapsulation technologies." msgstr "" #: ../network-focus-technical-considerations.rst:226 msgid "Use traffic shaping for performance tuning." msgstr "" #: ../network-focus-technical-considerations.rst:228 msgid "Use eBGP to connect to the Internet up-link." msgstr "" #: ../network-focus-technical-considerations.rst:230 msgid "Use iBGP to flatten the internal traffic on the layer-3 mesh." msgstr "" #: ../network-focus-technical-considerations.rst:232 msgid "Determine the most effective configuration for block storage network." msgstr "" #: ../network-focus-technical-considerations.rst:235 msgid "Additional considerations" msgstr "" #: ../network-focus-technical-considerations.rst:237 msgid "" "There are several further considerations when designing a network-focused " "OpenStack cloud." msgstr "" #: ../network-focus-technical-considerations.rst:241 msgid "" "OpenStack Networking versus legacy networking (nova-network) considerations" msgstr "" #: ../network-focus-technical-considerations.rst:243 msgid "" "Selecting the type of networking technology to implement depends on many " "factors. OpenStack Networking (neutron) and legacy networking (nova-network) " "both have their advantages and disadvantages. They are both valid and " "supported options that fit different use cases:" msgstr "" #: ../network-focus-technical-considerations.rst:254 msgid "OpenStack Networking" msgstr "" #: ../network-focus-technical-considerations.rst:255 msgid "Simple, single agent" msgstr "" #: ../network-focus-technical-considerations.rst:256 msgid "Complex, multiple agents" msgstr "" #: ../network-focus-technical-considerations.rst:257 msgid "More mature, established" msgstr "" #: ../network-focus-technical-considerations.rst:258 msgid "Newer, maturing" msgstr "" #: ../network-focus-technical-considerations.rst:259 msgid "Flat or VLAN" msgstr "" #: ../network-focus-technical-considerations.rst:260 msgid "Flat, VLAN, Overlays, L2-L3, SDN" msgstr "" #: ../network-focus-technical-considerations.rst:261 msgid "No plug-in support" msgstr "" #: ../network-focus-technical-considerations.rst:262 msgid "Plug-in support for 3rd parties" msgstr "" #: ../network-focus-technical-considerations.rst:263 msgid "Scales well" msgstr "" #: ../network-focus-technical-considerations.rst:264 msgid "Scaling requires 3rd party plug-ins" msgstr "" #: ../network-focus-technical-considerations.rst:265 msgid "No multi-tier topologies" msgstr "" #: ../network-focus-technical-considerations.rst:266 msgid "Multi-tier topologies" msgstr "" #: ../network-focus-technical-considerations.rst:269 msgid "Redundant networking: ToR switch high availability risk analysis" msgstr "" #: ../network-focus-technical-considerations.rst:271 msgid "" "A technical consideration of networking is the idea that you should install " "switching gear in a data center with backup switches in case of hardware " "failure." msgstr "" #: ../network-focus-technical-considerations.rst:275 msgid "" "Research indicates the mean time between failures (MTBF) on switches is " "between 100,000 and 200,000 hours. This number is dependent on the ambient " "temperature of the switch in the data center. When properly cooled and " "maintained, this translates to between 11 and 22 years before failure. Even " "in the worst case of poor ventilation and high ambient temperatures in the " "data center, the MTBF is still 2-3 years. See http://www.garrettcom.com/" "techsupport/papers/ethernet_switch_reliability.pdf for further information." msgstr "" #: ../network-focus-technical-considerations.rst:284 msgid "" "In most cases, it is much more economical to use a single switch with a " "small pool of spare switches to replace failed units than it is to outfit an " "entire data center with redundant switches. Applications should tolerate " "rack level outages without affecting normal operations, since network and " "compute resources are easily provisioned and plentiful." msgstr "" #: ../network-focus-technical-considerations.rst:292 msgid "Preparing for the future: IPv6 support" msgstr "" #: ../network-focus-technical-considerations.rst:294 msgid "" "One of the most important networking topics today is the impending " "exhaustion of IPv4 addresses. In early 2014, ICANN announced that they " "started allocating the final IPv4 address blocks to the `Regional Internet " "Registries `_. This means the IPv4 " "address space is close to being fully allocated. As a result, it will soon " "become difficult to allocate more IPv4 addresses to an application that has " "experienced growth, or that you expect to scale out, due to the lack of " "unallocated IPv4 address blocks." msgstr "" #: ../network-focus-technical-considerations.rst:304 msgid "" "For network focused applications the future is the IPv6 protocol. IPv6 " "increases the address space significantly, fixes long standing issues in the " "IPv4 protocol, and will become essential for network focused applications in " "the future." msgstr "" #: ../network-focus-technical-considerations.rst:309 msgid "" "OpenStack Networking supports IPv6 when configured to take advantage of it. " "To enable IPv6, create an IPv6 subnet in Networking and use IPv6 prefixes " "when creating security groups." msgstr "" #: ../network-focus-technical-considerations.rst:314 msgid "Asymmetric links" msgstr "" #: ../network-focus-technical-considerations.rst:316 msgid "" "When designing a network architecture, the traffic patterns of an " "application heavily influence the allocation of total bandwidth and the " "number of links that you use to send and receive traffic. Applications that " "provide file storage for customers allocate bandwidth and links to favor " "incoming traffic, whereas video streaming applications allocate bandwidth " "and links to favor outgoing traffic." msgstr "" #: ../network-focus-technical-considerations.rst:326 msgid "" "It is important to analyze the applications' tolerance for latency and " "jitter when designing an environment to support network focused " "applications. Certain applications, for example VoIP, are less tolerant of " "latency and jitter. Where latency and jitter are concerned, certain " "applications may require tuning of QoS parameters and network device queues " "to ensure that they queue for transmit immediately or guarantee minimum " "bandwidth. Since OpenStack currently does not support these functions, " "consider carefully your selected network plug-in." msgstr "" #: ../network-focus-technical-considerations.rst:335 msgid "" "The location of a service may also impact the application or consumer " "experience. If an application serves differing content to different users it " "must properly direct connections to those specific locations. Where " "appropriate, use a multi-site installation for these situations." msgstr "" #: ../network-focus-technical-considerations.rst:340 msgid "" "You can implement networking in two separate ways. Legacy networking (nova-" "network) provides a flat DHCP network with a single broadcast domain. This " "implementation does not support tenant isolation networks or advanced plug-" "ins, but it is currently the only way to implement a distributed :term:" "`layer-3 (L3) agent` using the multi_host configuration. OpenStack " "Networking (neutron) is the official networking implementation and provides " "a pluggable architecture that supports a large variety of network methods. " "Some of these include a layer-2 only provider network model, external device " "plug-ins, or even OpenFlow controllers." msgstr "" #: ../network-focus-technical-considerations.rst:350 msgid "" "Networking at large scales becomes a set of boundary questions. The " "determination of how large a layer-2 domain must be is based on the amount " "of nodes within the domain and the amount of broadcast traffic that passes " "between instances. Breaking layer-2 boundaries may require the " "implementation of overlay networks and tunnels. This decision is a balancing " "act between the need for a smaller overhead or a need for a smaller domain." msgstr "" #: ../network-focus-technical-considerations.rst:358 msgid "" "When selecting network devices, be aware that making this decision based on " "the greatest port density often comes with a drawback. Aggregation switches " "and routers have not all kept pace with Top of Rack switches and may induce " "bottlenecks on north-south traffic. As a result, it may be possible for " "massive amounts of downstream network utilization to impact upstream network " "devices, impacting service to the cloud. Since OpenStack does not currently " "provide a mechanism for traffic shaping or rate limiting, it is necessary to " "implement these features at the network hardware level." msgstr "" #: ../network-focus-user-requirements.rst:4 msgid "" "Network-focused architectures vary from the general-purpose architecture " "designs. Certain network-intensive applications influence these " "architectures. Some of the business requirements that influence the design " "include network latency through slow page loads, degraded video streams, and " "low quality VoIP sessions impacts the user experience." msgstr "" #: ../network-focus-user-requirements.rst:10 msgid "" "Users are often not aware of how network design and architecture affects " "their experiences. Both enterprise customers and end-users rely on the " "network for delivery of an application. Network performance problems can " "result in a negative experience for the end-user, as well as productivity " "and economic loss." msgstr "" #: ../network-focus-user-requirements.rst:17 msgid "High availability issues" msgstr "" #: ../network-focus-user-requirements.rst:19 msgid "" "Depending on the application and use case, network-intensive OpenStack " "installations can have high availability requirements. Financial transaction " "systems have a much higher requirement for high availability than a " "development application. Use network availability technologies, for example " "quality of service (QoS), to improve the network performance of sensitive " "applications such as VoIP and video streaming." msgstr "" #: ../network-focus-user-requirements.rst:26 msgid "" "High performance systems have SLA requirements for a minimum QoS with regard " "to guaranteed uptime, latency, and bandwidth. The level of the SLA can have " "a significant impact on the network architecture and requirements for " "redundancy in the systems." msgstr "" #: ../network-focus-user-requirements.rst:32 msgid "Risks" msgstr "" #: ../network-focus-user-requirements.rst:35 msgid "" "Configuring incorrect IP addresses, VLANs, and routers can cause outages to " "areas of the network or, in the worst-case scenario, the entire cloud " "infrastructure. Automate network configurations to minimize the opportunity " "for operator error as it can cause disruptive problems." msgstr "" #: ../network-focus-user-requirements.rst:39 msgid "Network misconfigurations" msgstr "" #: ../network-focus-user-requirements.rst:42 msgid "" "Cloud networks require management for capacity and growth over time. " "Capacity planning includes the purchase of network circuits and hardware " "that can potentially have lead times measured in months or years." msgstr "" #: ../network-focus-user-requirements.rst:48 msgid "" "Configure cloud networks to minimize link loss, packet loss, packet storms, " "broadcast storms, and loops." msgstr "" #: ../network-focus-user-requirements.rst:49 msgid "Network tuning" msgstr "" #: ../network-focus-user-requirements.rst:52 msgid "" "Consider high availability at the physical and environmental layers. If " "there is a single point of failure due to only one upstream link, or only " "one power supply, an outage can become unavoidable." msgstr "" #: ../network-focus-user-requirements.rst:54 msgid "Single Point Of Failure (SPOF)" msgstr "" #: ../network-focus-user-requirements.rst:57 msgid "" "An overly complex network design can be difficult to maintain and " "troubleshoot. While device-level configuration can ease maintenance concerns " "and automated tools can handle overlay networks, avoid or document non-" "traditional interconnects between functions and specialized hardware to " "prevent outages." msgstr "" #: ../network-focus-user-requirements.rst:61 msgid "Complexity" msgstr "" #: ../network-focus-user-requirements.rst:64 msgid "" "There are additional risks that arise from configuring the cloud network to " "take advantage of vendor specific features. One example is multi-link " "aggregation (MLAG) used to provide redundancy at the aggregator switch level " "of the network. MLAG is not a standard and, as a result, each vendor has " "their own proprietary implementation of the feature. MLAG architectures are " "not interoperable across switch vendors, which leads to vendor lock-in, and " "can cause delays or inability when upgrading components." msgstr "" #: ../network-focus-user-requirements.rst:70 msgid "Non-standard features" msgstr "" #: ../network-focus.rst:3 msgid "Network focused" msgstr "" #: ../network-focus.rst:14 msgid "" "All OpenStack deployments depend on network communication in order to " "function properly due to its service-based nature. In some cases, however, " "the network elevates beyond simple infrastructure. This chapter discusses " "architectures that are more reliant or focused on network services. These " "architectures depend on the network infrastructure and require network " "services that perform reliably in order to satisfy user and application " "requirements." msgstr "" #: ../network-focus.rst:21 msgid "Some possible use cases include:" msgstr "" #: ../network-focus.rst:24 msgid "" "This includes streaming video, viewing photographs, or accessing any other " "cloud-based data repository distributed to a large number of end users. " "Network configuration affects latency, bandwidth, and the distribution of " "instances. Therefore, it impacts video streaming. Not all video streaming is " "consumer-focused. For example, multicast videos (used for media, press " "conferences, corporate presentations, and web conferencing services) can " "also use a content delivery network. The location of the video repository " "and its relationship to end users affects content delivery. Network " "throughput of the back-end systems, as well as the WAN architecture and the " "cache methodology, also affect performance." msgstr "" #: ../network-focus.rst:33 msgid "Content delivery network" msgstr "" #: ../network-focus.rst:36 msgid "" "Use this cloud to provide network service functions built to support the " "delivery of back-end network services such as DNS, NTP, or SNMP." msgstr "" #: ../network-focus.rst:37 msgid "Network management functions" msgstr "" #: ../network-focus.rst:40 msgid "" "Use this cloud to run customer-facing network tools to support services. " "Examples include VPNs, MPLS private networks, and GRE tunnels." msgstr "" #: ../network-focus.rst:41 msgid "Network service offerings" msgstr "" #: ../network-focus.rst:44 msgid "" "Web servers are a common application for cloud services, and we recommend an " "understanding of their network requirements. The network requires scaling " "out to meet user demand and deliver web pages with a minimum latency. " "Depending on the details of the portal architecture, consider the internal " "east-west and north-south network bandwidth." msgstr "" #: ../network-focus.rst:48 msgid "Web portals or web services" msgstr "" #: ../network-focus.rst:51 msgid "" "These types of applications are sensitive to network configurations. " "Examples include financial systems, credit card transaction applications, " "and trading and other extremely high volume systems. These systems are " "sensitive to network jitter and latency. They must balance a high volume of " "East-West and North-South network traffic to maximize efficiency of the data " "delivery. Many of these systems must access large, high performance database " "back ends." msgstr "" #: ../network-focus.rst:56 msgid "High speed and high volume transactional systems" msgstr "" #: ../network-focus.rst:59 msgid "" "These types of use cases are dependent on the proper sizing of the network " "to maintain replication of data between sites for high availability. If one " "site becomes unavailable, the extra sites can serve the displaced load until " "the original site returns to service. It is important to size network " "capacity to handle the desired loads." msgstr "" #: ../network-focus.rst:66 msgid "" "Clouds used for the management and collection of big data (data ingest) have " "a significant demand on network resources. Big data often uses partial " "replicas of the data to maintain integrity over large distributed clouds. " "Other big data applications that require a large amount of network resources " "are Hadoop, Cassandra, NuoDB, Riak, and other NoSQL and distributed " "databases." msgstr "" #: ../network-focus.rst:71 msgid "Big data" msgstr "" #: ../network-focus.rst:74 msgid "" "This use case is sensitive to network congestion, latency, jitter, and other " "network characteristics. Like video streaming, the user experience is " "important. However, unlike video streaming, caching is not an option to " "offset the network issues. VDI requires both upstream and downstream traffic " "and cannot rely on caching for the delivery of the application to the end " "user." msgstr "" #: ../network-focus.rst:79 msgid "Virtual desktop infrastructure (VDI)" msgstr "" #: ../network-focus.rst:82 msgid "" "This is sensitive to network congestion, latency, jitter, and other network " "characteristics. VoIP has a symmetrical traffic pattern and it requires " "network quality of service (QoS) for best performance. In addition, you can " "implement active queue management to deliver voice and multimedia content. " "Users are sensitive to latency and jitter fluctuations and can detect them " "at very low levels." msgstr "" #: ../network-focus.rst:87 msgid "Voice over IP (VoIP)" msgstr "" #: ../network-focus.rst:90 msgid "" "This is sensitive to network congestion, latency, jitter, and other network " "characteristics. Video Conferencing has a symmetrical traffic pattern, but " "unless the network is on an MPLS private network, it cannot use network " "quality of service (QoS) to improve performance. Similar to VoIP, users are " "sensitive to network performance issues even at low levels." msgstr "" #: ../network-focus.rst:94 msgid "Video Conference or web conference" msgstr "" #: ../network-focus.rst:97 msgid "" "This is a complex use case that requires careful consideration of the " "traffic flows and usage patterns to address the needs of cloud clusters. It " "has high east-west traffic patterns for distributed computing, but there can " "be substantial north-south traffic depending on the specific application." msgstr "" #: ../references.rst:3 msgid "References" msgstr "" #: ../references.rst:5 msgid "" "`Data Protection framework of the European Union `_ : Guidance on Data Protection laws governed by " "the EU." msgstr "" #: ../references.rst:9 msgid "" "`Depletion of IPv4 Addresses `_ : " "describing how IPv4 addresses and the migration to IPv6 is inevitable." msgstr "" #: ../references.rst:14 msgid "" "`Ethernet Switch Reliability `_ : Research white paper on Ethernet Switch " "reliability." msgstr "" #: ../references.rst:18 msgid "" "`Financial Industry Regulatory Authority `_ : Requirements of the Financial Industry " "Regulatory Authority in the USA." msgstr "" #: ../references.rst:22 msgid "" "`Image Service property keys `_ : Glance API property keys allows " "the administrator to attach custom characteristics to images." msgstr "" #: ../references.rst:27 msgid "" "`LibGuestFS Documentation `_ : Official LibGuestFS " "documentation." msgstr "" #: ../references.rst:30 msgid "" "`Logging and Monitoring `_ : Official OpenStack Operations documentation." msgstr "" #: ../references.rst:34 msgid "" "`ManageIQ Cloud Management Platform `_ : An Open " "Source Cloud Management Platform for managing multiple clouds." msgstr "" #: ../references.rst:37 msgid "" "`N-Tron Network Availability `_ : Research white paper on network availability." msgstr "" #: ../references.rst:41 msgid "" "`Nested KVM `_ : " "Post on how to nest KVM under KVM." msgstr "" #: ../references.rst:44 msgid "" "`Open Compute Project `_ : The Open Compute " "Project Foundation's mission is to design and enable the delivery of the " "most efficient server, storage and data center hardware designs for scalable " "computing." msgstr "" #: ../references.rst:49 msgid "" "`OpenStack Flavors `_ : Official OpenStack documentation." msgstr "" #: ../references.rst:53 msgid "" "`OpenStack High Availability Guide `_ : " "Information on how to provide redundancy for the OpenStack components." msgstr "" #: ../references.rst:56 msgid "" "`OpenStack Hypervisor Support Matrix `_ : Matrix of supported hypervisors and " "capabilities when used with OpenStack." msgstr "" #: ../references.rst:60 msgid "" "`OpenStack Object Store (Swift) Replication Reference `_ : Developer documentation of " "Swift replication." msgstr "" #: ../references.rst:64 msgid "" "`OpenStack Operations Guide `_ : " "The OpenStack Operations Guide provides information on setting up and " "installing OpenStack." msgstr "" #: ../references.rst:68 msgid "" "`OpenStack Security Guide `_ : " "The OpenStack Security Guide provides information on securing OpenStack " "deployments." msgstr "" #: ../references.rst:72 msgid "" "`OpenStack Training Marketplace `_ : The OpenStack Market for training and Vendors providing " "training on OpenStack." msgstr "" #: ../references.rst:77 msgid "" "`PCI passthrough `_ : The PCI API " "patches extend the servers/os-hypervisor to show PCI information for " "instance and compute node, and also provides a resource endpoint to show PCI " "information." msgstr "" #: ../references.rst:83 msgid "" "`TripleO `_ : TripleO is a program " "aimed at installing, upgrading and operating OpenStack clouds using " "OpenStack's own cloud facilities as the foundation." msgstr "" #: ../specialized-desktop-as-a-service.rst:3 msgid "Desktop-as-a-Service" msgstr "" #: ../specialized-desktop-as-a-service.rst:5 msgid "" "Virtual Desktop Infrastructure (VDI) is a service that hosts user desktop " "environments on remote servers. This application is very sensitive to " "network latency and requires a high performance compute environment. " "Traditionally these types of services do not use cloud environments because " "few clouds support such a demanding workload for user-facing applications. " "As cloud environments become more robust, vendors are starting to provide " "services that provide virtual desktops in the cloud. OpenStack may soon " "provide the infrastructure for these types of deployments." msgstr "" # #-#-#-#-# specialized-desktop-as-a-service.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# specialized-hardware.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# specialized-networking.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# specialized-openstack-on-openstack.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# specialized-software-defined-networking.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../specialized-desktop-as-a-service.rst:16 ../specialized-hardware.rst:12 #: ../specialized-networking.rst:11 #: ../specialized-openstack-on-openstack.rst:18 #: ../specialized-software-defined-networking.rst:15 msgid "Challenges" msgstr "" #: ../specialized-desktop-as-a-service.rst:18 msgid "" "Designing an infrastructure that is suitable to host virtual desktops is a " "very different task to that of most virtual workloads. For example, the " "design must consider:" msgstr "" #: ../specialized-desktop-as-a-service.rst:22 msgid "" "Boot storms, when a high volume of logins occur in a short period of time" msgstr "" #: ../specialized-desktop-as-a-service.rst:23 msgid "The performance of the applications running on virtual desktops" msgstr "" #: ../specialized-desktop-as-a-service.rst:24 msgid "Operating systems and their compatibility with the OpenStack hypervisor" msgstr "" #: ../specialized-desktop-as-a-service.rst:27 msgid "Broker" msgstr "" #: ../specialized-desktop-as-a-service.rst:29 msgid "" "The connection broker determines which remote desktop host users can access. " "Medium and large scale environments require a broker since its service " "represents a central component of the architecture. The broker is a complete " "management product, and enables automated deployment and provisioning of " "remote desktop hosts." msgstr "" # #-#-#-#-# specialized-desktop-as-a-service.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# specialized-networking.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# specialized-software-defined-networking.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../specialized-desktop-as-a-service.rst:36 ../specialized-networking.rst:19 #: ../specialized-software-defined-networking.rst:24 msgid "Possible solutions" msgstr "" #: ../specialized-desktop-as-a-service.rst:38 msgid "" "There are a number of commercial products currently available that provide a " "broker solution. However, no native OpenStack projects provide broker " "services. Not providing a broker is also an option, but managing this " "manually would not suffice for a large scale, enterprise solution." msgstr "" # #-#-#-#-# specialized-desktop-as-a-service.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# specialized-openstack-on-openstack.pot (Architecture Design Guide 0.9) #-#-#-#-# # #-#-#-#-# specialized-software-defined-networking.pot (Architecture Design Guide 0.9) #-#-#-#-# #: ../specialized-desktop-as-a-service.rst:45 #: ../specialized-openstack-on-openstack.rst:67 #: ../specialized-software-defined-networking.rst:37 msgid "Diagram" msgstr "" #: ../specialized-hardware.rst:3 msgid "Specialized hardware" msgstr "" #: ../specialized-hardware.rst:5 msgid "" "Certain workloads require specialized hardware devices that have significant " "virtualization or sharing challenges. Applications such as load balancers, " "highly parallel brute force computing, and direct to wire networking may " "need capabilities that basic OpenStack components do not provide." msgstr "" #: ../specialized-hardware.rst:14 msgid "" "Some applications need access to hardware devices to either improve " "performance or provide capabilities that are not virtual CPU, RAM, network, " "or storage. These can be a shared resource, such as a cryptography " "processor, or a dedicated resource, such as a Graphics Processing Unit " "(GPU). OpenStack can provide some of these, while others may need extra work." msgstr "" #: ../specialized-hardware.rst:22 msgid "Solutions" msgstr "" #: ../specialized-hardware.rst:24 msgid "" "To provide cryptography offloading to a set of instances, you can use Image " "service configuration options. For example, assign the cryptography chip to " "a device node in the guest. The OpenStack Command Line Reference contains " "further information on configuring this solution in the section `Image " "service property keys `_. A challenge, however, is this option " "allows all guests using the configured images to access the hypervisor " "cryptography device." msgstr "" #: ../specialized-hardware.rst:33 msgid "" "If you require direct access to a specific device, PCI pass-through enables " "you to dedicate the device to a single instance per hypervisor. You must " "define a flavor that has the PCI device specifically in order to properly " "schedule instances. More information regarding PCI pass-through, including " "instructions for implementing and using it, is available at `https://wiki." "openstack.org/wiki/Pci_passthrough `_." msgstr "" #: ../specialized-multi-hypervisor.rst:3 msgid "Multi-hypervisor example" msgstr "" #: ../specialized-multi-hypervisor.rst:5 msgid "" "A financial company requires its applications migrated from a traditional, " "virtualized environment to an API driven, orchestrated environment. The new " "environment needs multiple hypervisors since many of the company's " "applications have strict hypervisor requirements." msgstr "" #: ../specialized-multi-hypervisor.rst:11 msgid "" "Currently, the company's vSphere environment runs 20 VMware ESXi " "hypervisors. These hypervisors support 300 instances of various sizes. " "Approximately 50 of these instances must run on ESXi. The remaining 250 or " "so have more flexible requirements." msgstr "" #: ../specialized-multi-hypervisor.rst:16 msgid "" "The financial company decides to manage the overall system with a common " "OpenStack platform." msgstr "" #: ../specialized-multi-hypervisor.rst:22 msgid "" "Architecture planning teams decided to run a host aggregate containing KVM " "hypervisors for the general purpose instances. A separate host aggregate " "targets instances requiring ESXi." msgstr "" #: ../specialized-multi-hypervisor.rst:26 msgid "" "Images in the OpenStack Image service have particular hypervisor metadata " "attached. When a user requests a certain image, the instance spawns on the " "relevant aggregate." msgstr "" #: ../specialized-multi-hypervisor.rst:30 msgid "" "Images for ESXi use the VMDK format. You can convert QEMU disk images to " "VMDK, VMFS Flat Disks. These disk images can also be thin, thick, zeroed-" "thick, and eager-zeroed-thick. After exporting a VMFS thin disk from VMFS to " "the OpenStack Image service (a non-VMFS location), it becomes a preallocated " "flat disk. This impacts the transfer time from the OpenStack Image service " "to the data store since transfers require moving the full preallocated flat " "disk rather than the thin disk." msgstr "" #: ../specialized-multi-hypervisor.rst:39 msgid "" "The VMware host aggregate compute nodes communicate with vCenter rather than " "spawning directly on a hypervisor. The vCenter then requests scheduling for " "the instance to run on an ESXi hypervisor." msgstr "" #: ../specialized-multi-hypervisor.rst:44 msgid "" "This functionality requires that VMware Distributed Resource Scheduler (DRS) " "is enabled on a cluster and set to **Fully Automated**. The vSphere requires " "shared storage because the DRS uses vMotion which is a service that relies " "on shared storage." msgstr "" #: ../specialized-multi-hypervisor.rst:49 msgid "" "This solution to the company's migration uses shared storage to provide " "Block Storage capabilities to the KVM instances while also providing vSphere " "storage. The new environment provides this storage functionality using a " "dedicated data network. The compute hosts should have dedicated NICs to " "support the dedicated data network. vSphere supports OpenStack Block " "Storage. This support gives storage from a VMFS datastore to an instance. " "For the financial company, Block Storage in their new architecture supports " "both hypervisors." msgstr "" #: ../specialized-multi-hypervisor.rst:59 msgid "" "OpenStack Networking provides network connectivity in this new architecture, " "with the VMware NSX plug-in driver configured. legacy networking (nova-" "network) supports both hypervisors in this new architecture example, but has " "limitations. Specifically, vSphere with legacy networking does not support " "security groups. The new architecture uses VMware NSX as a part of the " "design. When users launch an instance within either of the host aggregates, " "VMware NSX ensures the instance attaches to the appropriate network overlay-" "based logical networks." msgstr "" #: ../specialized-multi-hypervisor.rst:68 msgid "" "The architecture planning teams also consider OpenStack Compute integration. " "When running vSphere in an OpenStack environment, nova-compute " "communications with vCenter appear as a single large hypervisor. This " "hypervisor represents the entire ESXi cluster. Multiple nova-compute " "instances can represent multiple ESXi clusters. They can connect to multiple " "vCenter servers. If the process running nova-compute crashes it cuts the " "connection to the vCenter server. Any ESXi clusters will stop running, and " "you will not be able to provision further instances on the vCenter, even if " "you enable high availability. You must monitor the nova-compute service " "connected to vSphere carefully for any disruptions as a result of this " "failure point." msgstr "" #: ../specialized-networking.rst:3 msgid "Specialized networking example" msgstr "" #: ../specialized-networking.rst:5 msgid "" "Some applications that interact with a network require specialized " "connectivity. Applications such as a looking glass require the ability to " "connect to a BGP peer, or route participant applications may need to join a " "network at a layer2 level." msgstr "" #: ../specialized-networking.rst:13 msgid "" "Connecting specialized network applications to their required resources " "alters the design of an OpenStack installation. Installations that rely on " "overlay networks are unable to support a routing participant, and may also " "block layer-2 listeners." msgstr "" #: ../specialized-networking.rst:21 msgid "" "Deploying an OpenStack installation using OpenStack Networking with a " "provider network allows direct layer-2 connectivity to an upstream " "networking device. This design provides the layer-2 connectivity required to " "communicate via Intermediate System-to-Intermediate System (ISIS) protocol " "or to pass packets controlled by an OpenFlow controller. Using the multiple " "layer-2 plug-in with an agent such as :term:`Open vSwitch` allows a private " "connection through a VLAN directly to a specific port in a layer-3 device. " "This allows a BGP point-to-point link to join the autonomous system. Avoid " "using layer-3 plug-ins as they divide the broadcast domain and prevent " "router adjacencies from forming." msgstr "" #: ../specialized-openstack-on-openstack.rst:3 msgid "OpenStack on OpenStack" msgstr "" #: ../specialized-openstack-on-openstack.rst:5 msgid "" "In some cases, users may run OpenStack nested on top of another OpenStack " "cloud. This scenario describes how to manage and provision complete " "OpenStack environments on instances supported by hypervisors and servers, " "which an underlying OpenStack environment controls." msgstr "" #: ../specialized-openstack-on-openstack.rst:11 msgid "" "Public cloud providers can use this technique to manage the upgrade and " "maintenance process on complete OpenStack environments. Developers and those " "testing OpenStack can also use this technique to provision their own " "OpenStack environments on available OpenStack Compute resources, whether " "public or private." msgstr "" #: ../specialized-openstack-on-openstack.rst:20 msgid "" "The network aspect of deploying a nested cloud is the most complicated " "aspect of this architecture. You must expose VLANs to the physical ports on " "which the underlying cloud runs because the bare metal cloud owns all the " "hardware. You must also expose them to the nested levels as well. " "Alternatively, you can use the network overlay technologies on the OpenStack " "environment running on the host OpenStack environment to provide the " "required software defined networking for the deployment." msgstr "" #: ../specialized-openstack-on-openstack.rst:32 msgid "" "In this example architecture, consider which approach you should take to " "provide a nested hypervisor in OpenStack. This decision influences which " "operating systems you use for the deployment of the nested OpenStack " "deployments." msgstr "" #: ../specialized-openstack-on-openstack.rst:39 msgid "Possible solutions: deployment" msgstr "" #: ../specialized-openstack-on-openstack.rst:41 msgid "" "Deployment of a full stack can be challenging but you can mitigate this " "difficulty by creating a Heat template to deploy the entire stack, or a " "configuration management system. After creating the Heat template, you can " "automate the deployment of additional stacks." msgstr "" #: ../specialized-openstack-on-openstack.rst:46 msgid "" "The OpenStack-on-OpenStack project (:term:`TripleO`) addresses this issue. " "Currently, however, the project does not completely cover nested stacks. For " "more information, see https://wiki.openstack.org/wiki/TripleO." msgstr "" #: ../specialized-openstack-on-openstack.rst:52 msgid "Possible solutions: hypervisor" msgstr "" #: ../specialized-openstack-on-openstack.rst:54 msgid "" "In the case of running TripleO, the underlying OpenStack cloud deploys the " "Compute nodes as bare-metal. You then deploy OpenStack on these Compute bare-" "metal servers with the appropriate hypervisor, such as KVM." msgstr "" #: ../specialized-openstack-on-openstack.rst:59 msgid "" "In the case of running smaller OpenStack clouds for testing purposes, where " "performance is not a critical factor, you can use QEMU instead. It is also " "possible to run a KVM hypervisor in an instance (see http://davejingtian." "org/2014/03/30/nested-kvm-just-for-fun/), though this is not a supported " "configuration, and could be a complex solution for such a use case." msgstr "" #: ../specialized-software-defined-networking.rst:3 msgid "Software-defined networking" msgstr "" #: ../specialized-software-defined-networking.rst:5 msgid "" "Software-defined networking (SDN) is the separation of the data plane and " "control plane. SDN is a popular method of managing and controlling packet " "flows within networks. SDN uses overlays or directly controlled layer-2 " "devices to determine flow paths, and as such presents challenges to a cloud " "environment. Some designers may wish to run their controllers within an " "OpenStack installation. Others may wish to have their installations " "participate in an SDN-controlled network." msgstr "" #: ../specialized-software-defined-networking.rst:17 msgid "" "SDN is a relatively new concept that is not yet standardized, so SDN systems " "come in a variety of different implementations. Because of this, a truly " "prescriptive architecture is not feasible. Instead, examine the differences " "between an existing and a planned OpenStack design and determine where " "potential conflicts and gaps exist." msgstr "" #: ../specialized-software-defined-networking.rst:26 msgid "" "If an SDN implementation requires layer-2 access because it directly " "manipulates switches, we do not recommend running an overlay network or a " "layer-3 agent. If the controller resides within an OpenStack installation, " "it may be necessary to build an ML2 plug-in and schedule the controller " "instances to connect to tenant VLANs that they can talk directly to the " "switch hardware. Alternatively, depending on the external device support, " "use a tunnel that terminates at the switch hardware itself." msgstr "" #: ../specialized-software-defined-networking.rst:39 msgid "OpenStack hosted SDN controller:" msgstr "" #: ../specialized-software-defined-networking.rst:43 msgid "OpenStack participating in an SDN controller network:" msgstr "" #: ../specialized.rst:3 msgid "Specialized cases" msgstr "" #: ../specialized.rst:15 msgid "" "Although most OpenStack architecture designs fall into one of the seven " "major scenarios outlined in other sections (compute focused, network " "focused, storage focused, general purpose, multi-site, hybrid cloud, and " "massively scalable), there are a few use cases that do not fit into these " "categories. This section discusses these specialized cases and provide some " "additional details and design considerations for each use case:" msgstr "" #: ../specialized.rst:23 msgid "" ":doc:`Specialized networking `: describes running " "networking-oriented software that may involve reading packets directly from " "the wire or participating in routing protocols." msgstr "" #: ../specialized.rst:26 msgid "" ":doc:`Software-defined networking (SDN) `: describes both running an SDN controller from within OpenStack " "as well as participating in a software-defined network." msgstr "" #: ../specialized.rst:30 msgid "" ":doc:`Desktop-as-a-Service `: describes " "running a virtualized desktop environment in a cloud (:term:`Desktop-as-a-" "Service`). This applies to private and public clouds." msgstr "" #: ../specialized.rst:34 msgid "" ":doc:`OpenStack on OpenStack `: " "describes building a multi-tiered cloud by running OpenStack on top of an " "OpenStack installation." msgstr "" #: ../specialized.rst:37 msgid "" ":doc:`Specialized hardware `: describes the use of " "specialized hardware devices from within the OpenStack environment." msgstr "" #: ../storage-focus-architecture.rst:4 msgid "Consider the following factors when selecting storage hardware:" msgstr "" #: ../storage-focus-architecture.rst:10 msgid "Reliability" msgstr "" #: ../storage-focus-architecture.rst:12 msgid "" "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." msgstr "" #: ../storage-focus-architecture.rst:17 msgid "" "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:" msgstr "" #: ../storage-focus-architecture.rst:22 msgid "" "The cost of components affects which storage architecture and hardware you " "choose." msgstr "" #: ../storage-focus-architecture.rst:26 msgid "" "The latency of storage I/O requests indicates performance. Performance " "requirements affect which solution you choose." msgstr "" #: ../storage-focus-architecture.rst:30 msgid "" "Scalability refers to how the storage solution performs as it expands to its " "maximum size. Storage solutions that perform well in small configurations " "but have degraded performance in large configurations are not scalable. A " "solution that performs well at maximum expansion is scalable. Large " "deployments require a storage solution that performs well as it expands." msgstr "" #: ../storage-focus-architecture.rst:37 msgid "" "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." msgstr "" #: ../storage-focus-architecture.rst:43 msgid "" "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." msgstr "" #: ../storage-focus-architecture.rst:51 msgid "" "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." msgstr "" #: ../storage-focus-architecture.rst:56 msgid "" "Considerations affecting storage architecture (and corresponding storage " "hardware) of a Storage-focused OpenStack cloud include:" msgstr "" #: ../storage-focus-architecture.rst:60 msgid "" "Based on the selected storage solution, ensure the connectivity matches the " "storage solution requirements. We recommended confirming that the network " "characteristics minimize latency to boost the overall performance of the " "design." msgstr "" #: ../storage-focus-architecture.rst:66 msgid "Determine if the use case has consistent or highly variable latency." msgstr "" #: ../storage-focus-architecture.rst:66 msgid "Latency" msgstr "" #: ../storage-focus-architecture.rst:69 msgid "" "Ensure that the storage solution throughput is optimized for your " "application requirements." msgstr "" #: ../storage-focus-architecture.rst:70 msgid "Throughput" msgstr "" #: ../storage-focus-architecture.rst:73 msgid "" "Use of DAS impacts the server hardware choice and affects host density, " "instance density, power density, OS-hypervisor, and management tools." msgstr "" #: ../storage-focus-architecture.rst:78 msgid "Compute (server) hardware selection" msgstr "" #: ../storage-focus-architecture.rst:80 msgid "" "Four opposing factors determine the compute (server) hardware selection:" msgstr "" #: ../storage-focus-architecture.rst:87 msgid "" "The number of CPU cores, how much RAM, or how much storage a given server " "delivers." msgstr "" #: ../storage-focus-architecture.rst:91 msgid "" "The number of additional resources you can add to a server before it reaches " "capacity." msgstr "" #: ../storage-focus-architecture.rst:95 msgid "" "The relative cost of the hardware weighed against the level of design effort " "needed to build the system." msgstr "" #: ../storage-focus-architecture.rst:98 msgid "" "You must weigh the dimensions against each other to determine the best " "design for the desired purpose. For example, increasing server density can " "mean sacrificing resource capacity or expandability. Increasing resource " "capacity and expandability can increase cost but decrease server density. " "Decreasing cost often means decreasing supportability, server density, " "resource capacity, and expandability." msgstr "" #: ../storage-focus-architecture.rst:105 msgid "" "Compute capacity (CPU cores and RAM capacity) is a secondary consideration " "for selecting server hardware. As a result, the required server hardware " "must supply adequate CPU sockets, additional CPU cores, and more RAM; " "network connectivity and storage capacity are not as critical. The hardware " "needs to provide enough network connectivity and storage capacity to meet " "the user requirements, however they are not the primary consideration." msgstr "" #: ../storage-focus-architecture.rst:113 msgid "" "Some server hardware form factors are better suited to storage-focused " "designs than others. The following is a list of these form factors:" msgstr "" #: ../storage-focus-architecture.rst:116 msgid "" "Most blade servers support dual-socket multi-core CPUs. Choose either full " "width or full height blades to avoid the limit. High density blade servers " "support up to 16 servers in only 10 rack units using half height or half " "width blades." msgstr "" #: ../storage-focus-architecture.rst:123 msgid "" "This decreases density by 50% (only 8 servers in 10 U) if a full width or " "full height option is used." msgstr "" #: ../storage-focus-architecture.rst:126 msgid "" "1U rack-mounted servers have the ability to offer greater server density " "than a blade server solution, but are often limited to dual-socket, multi-" "core CPU configurations." msgstr "" #: ../storage-focus-architecture.rst:132 msgid "" "Due to cooling requirements, it is rare to see 1U rack-mounted servers with " "more than 2 CPU sockets." msgstr "" #: ../storage-focus-architecture.rst:135 msgid "" "To obtain greater than dual-socket support in a 1U rack-mount form factor, " "customers need to buy their systems from Original Design Manufacturers " "(ODMs) or second-tier manufacturers." msgstr "" #: ../storage-focus-architecture.rst:141 msgid "" "This may cause issues for organizations that have preferred vendor policies " "or concerns with support and hardware warranties of non-tier 1 vendors." msgstr "" #: ../storage-focus-architecture.rst:145 msgid "" "2U rack-mounted servers provide quad-socket, multi-core CPU support but with " "a corresponding decrease in server density (half the density offered by 1U " "rack-mounted servers)." msgstr "" #: ../storage-focus-architecture.rst:149 msgid "" "Larger rack-mounted servers, such as 4U servers, often provide even greater " "CPU capacity. Commonly supporting four or even eight CPU sockets. These " "servers have greater expandability but such servers have much lower server " "density and usually greater hardware cost." msgstr "" #: ../storage-focus-architecture.rst:154 msgid "" "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." msgstr "" #: ../storage-focus-architecture.rst:158 msgid "" "Other factors that influence server hardware selection for a storage-focused " "OpenStack design architecture include:" msgstr "" #: ../storage-focus-architecture.rst:162 msgid "" "In this architecture, instance density and CPU-RAM oversubscription are " "lower. You require more hosts to support the anticipated scale, especially " "if the design uses dual-socket hardware designs." msgstr "" #: ../storage-focus-architecture.rst:167 msgid "" "Another option to address the higher 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 and cooling requirements." msgstr "" #: ../storage-focus-architecture.rst:174 msgid "" "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." msgstr "" #: ../storage-focus-architecture.rst:179 msgid "" "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 including cost, power, cooling, physical rack and floor space, " "support-warranty, and manageability." msgstr "" #: ../storage-focus-architecture.rst:187 msgid "Networking hardware selection" msgstr "" #: ../storage-focus-architecture.rst:189 msgid "Key considerations for the selection of networking hardware include:" msgstr "" #: ../storage-focus-architecture.rst:192 msgid "" "The user requires networking hardware that has the requisite port count." msgstr "" #: ../storage-focus-architecture.rst:196 msgid "" "The physical space required to provide the requisite port count affects the " "network design. A switch that provides 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 domains and power density. Finally, higher density switches are more " "expensive, therefore it is important not to over design the network." msgstr "" #: ../storage-focus-architecture.rst:210 msgid "" "User requirements for high availability and cost considerations influence " "the required level of network hardware redundancy. Achieve network " "redundancy by adding redundant power supplies or paired switches." msgstr "" #: ../storage-focus-architecture.rst:217 msgid "" "If this is a requirement, the hardware must support this configuration. User " "requirements determine if a completely redundant network infrastructure is " "required." msgstr "" #: ../storage-focus-architecture.rst:222 msgid "" "Ensure that the physical data center provides the necessary power for the " "selected network hardware. This is not 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." msgstr "" #: ../storage-focus-architecture.rst:228 msgid "" "It is possible to gain 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." msgstr "" #: ../storage-focus-architecture.rst:231 msgid "Protocol support" msgstr "" #: ../storage-focus-architecture.rst:236 msgid "" "Factors that influence the software selection for a storage-focused " "OpenStack architecture design include:" msgstr "" #: ../storage-focus-architecture.rst:245 msgid "" "Design decisions made in each of these areas impacts the rest of the " "OpenStack architecture design." msgstr "" #: ../storage-focus-architecture.rst:251 msgid "" "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." msgstr "" #: ../storage-focus-architecture.rst:256 msgid "Operating system and hypervisor selection affect the following areas:" msgstr "" #: ../storage-focus-architecture.rst:259 msgid "" "Selecting a commercially supported hypervisor, such as Microsoft Hyper-V, " "results in a different cost model than a community-supported open source " "hypervisor like Kinstance or Xen. Similarly, choosing Ubuntu over Red Hat " "(or vice versa) impacts cost due to support contracts. However, business or " "application requirements might dictate a specific or commercially supported " "hypervisor." msgstr "" #: ../storage-focus-architecture.rst:268 msgid "" "Staff must have training with the chosen hypervisor. Consider the cost of " "training when choosing a solution. The support of a commercial product such " "as Red Hat, SUSE, or Windows, is the responsibility of the OS vendor. If an " "open source platform is chosen, the support comes from in-house resources." msgstr "" #: ../storage-focus-architecture.rst:275 msgid "" "Ubuntu and Kinstance use different management tools than VMware vSphere. " "Although both OS and hypervisor combinations are supported by OpenStack, " "there are varying impacts to the rest of the design as a result of the " "selection of one combination versus the other." msgstr "" #: ../storage-focus-architecture.rst:281 msgid "" "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 meet the targeted instance-host ratios " "with the selected OS-hypervisor combination." msgstr "" #: ../storage-focus-architecture.rst:288 msgid "" "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 proposed OS-hypervisor combination " "impacts performance and the patch installation process could affect " "maintenance windows." msgstr "" #: ../storage-focus-architecture.rst:295 msgid "" "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." msgstr "" #: ../storage-focus-architecture.rst:302 msgid "" "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 from the " "tools used for another OS-hypervisor combination. As a result, the design " "must address if the two sets of tools need to interoperate." msgstr "" #: ../storage-focus-architecture.rst:312 msgid "" "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 be required. As an example, a certain design may not require the " "Orchestration service. 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." msgstr "" #: ../storage-focus-architecture.rst:322 msgid "" "A storage-focused design might require the ability to use Orchestration to " "launch instances with Block Storage volumes to perform storage-intensive " "processing." msgstr "" #: ../storage-focus-architecture.rst:326 msgid "" "A storage-focused OpenStack design architecture uses the following " "components:" msgstr "" #: ../storage-focus-architecture.rst:329 msgid "OpenStack Identity (keystone)" msgstr "" #: ../storage-focus-architecture.rst:331 msgid "OpenStack dashboard (horizon)" msgstr "" #: ../storage-focus-architecture.rst:334 msgid "OpenStack Compute (nova) (including the use of multiple hypervisor" msgstr "" #: ../storage-focus-architecture.rst:334 msgid "drivers)" msgstr "" #: ../storage-focus-architecture.rst:336 msgid "OpenStack Object Storage (swift) (or another object storage solution)" msgstr "" #: ../storage-focus-architecture.rst:338 msgid "OpenStack Block Storage (cinder)" msgstr "" #: ../storage-focus-architecture.rst:340 msgid "OpenStack Image service (glance)" msgstr "" #: ../storage-focus-architecture.rst:342 msgid "OpenStack Networking (neutron) or legacy networking (nova-network)" msgstr "" #: ../storage-focus-architecture.rst:344 msgid "" "Excluding certain OpenStack components may limit or constrain the " "functionality of other components. If a design opts to include Orchestration " "but exclude Telemetry, then the design cannot 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, we " "strongly recommend including Orchestration in a compute-focused architecture " "design." msgstr "" #: ../storage-focus-architecture.rst:356 msgid "" "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). The OpenStack High Availability Guide describes some of these " "software packages, HAProxy in particular. See the `Network controller " "cluster stack chapter `_ of the OpenStack High Availability Guide." msgstr "" #: ../storage-focus-architecture.rst:369 msgid "Management software includes software for providing:" msgstr "" #: ../storage-focus-architecture.rst:371 msgid "Clustering" msgstr "" #: ../storage-focus-architecture.rst:373 msgid "Logging" msgstr "" #: ../storage-focus-architecture.rst:377 msgid "Alerting" msgstr "" #: ../storage-focus-architecture.rst:381 msgid "" "The factors for determining which software packages in this category to " "select is outside the scope of this design guide." msgstr "" #: ../storage-focus-architecture.rst:384 msgid "" "The availability design requirements determine the selection of Clustering " "Software, such as Corosync or Pacemaker. The availability of the cloud " "infrastructure and the complexity of supporting the configuration after " "deployment determines the impact of including these software packages. The " "OpenStack High Availability Guide provides more details on the installation " "and configuration of Corosync and Pacemaker." msgstr "" #: ../storage-focus-architecture.rst:391 msgid "" "Operational considerations determine the requirements for logging, " "monitoring, and alerting. Each of these sub-categories includes options. For " "example, in the logging sub-category you could select Logstash, Splunk, Log " "Insight, or another log aggregation-consolidation tool. Store logs in a " "centralized location to facilitate performing analytics against the data. " "Log data analytics engines can also provide automation and issue " "notification, by providing a mechanism to both alert and automatically " "attempt to remediate some of the more commonly known issues." msgstr "" #: ../storage-focus-architecture.rst:401 msgid "" "If you require any of these software packages, the design must account for " "the additional resource consumption. Some other potential design impacts " "include:" msgstr "" #: ../storage-focus-architecture.rst:405 msgid "" "OS-Hypervisor combination: Ensure that the selected logging, monitoring, or " "alerting tools support the proposed OS-hypervisor combination." msgstr "" #: ../storage-focus-architecture.rst:415 msgid "" "Most OpenStack components require access to back-end database services to " "store state and configuration information. Choose an appropriate back-end " "database which satisfies the availability and fault tolerance requirements " "of the OpenStack services." msgstr "" #: ../storage-focus-architecture.rst:420 msgid "" "MySQL is the default database for OpenStack, but other compatible databases " "are available." msgstr "" #: ../storage-focus-architecture.rst:425 msgid "Telemetry uses MongoDB." msgstr "" #: ../storage-focus-architecture.rst:427 msgid "" "The chosen high availability database solution changes according to the " "selected database. MySQL, for example, provides several options. Use a " "replication technology such as Galera for active-active clustering. For " "active-passive use some form of shared storage. Each of these potential " "solutions has an impact on the design:" msgstr "" #: ../storage-focus-architecture.rst:433 msgid "" "Solutions that employ Galera/MariaDB require at least three MySQL nodes." msgstr "" #: ../storage-focus-architecture.rst:436 msgid "MongoDB has its own design considerations for high availability." msgstr "" #: ../storage-focus-architecture.rst:438 msgid "" "OpenStack design, generally, does not include shared storage. However, for " "some high availability designs, certain components might require it " "depending on the specific implementation." msgstr "" #: ../storage-focus-operational-considerations.rst:2 msgid "Operational Considerations" msgstr "" #: ../storage-focus-operational-considerations.rst:4 msgid "" "Several operational factors affect the design choices for a general purpose " "cloud. Operations staff receive tasks regarding the maintenance of cloud " "environments for larger installations, including:" msgstr "" #: ../storage-focus-operational-considerations.rst:9 msgid "" "The storage solution should take into account storage maintenance and the " "impact on underlying workloads." msgstr "" #: ../storage-focus-operational-considerations.rst:10 msgid "Maintenance tasks" msgstr "" #: ../storage-focus-operational-considerations.rst:13 msgid "" "Reliability and availability depend on wide area network availability and on " "the level of precautions taken by the service provider." msgstr "" #: ../storage-focus-operational-considerations.rst:15 msgid "Reliability and availability" msgstr "" #: ../storage-focus-operational-considerations.rst:18 msgid "" "Organizations need to have the flexibility to choose between off-premise and " "on-premise cloud storage options. This relies on relevant decision criteria " "with potential cost savings. For example, continuity of operations, disaster " "recovery, security, records retention laws, regulations, and policies." msgstr "" #: ../storage-focus-operational-considerations.rst:22 msgid "Flexibility" msgstr "" #: ../storage-focus-operational-considerations.rst:24 msgid "" "Monitoring and alerting services are vital in cloud environments with high " "demands on storage resources. These services provide a real-time view into " "the health and performance of the storage systems. An integrated management " "console, or other dashboards capable of visualizing SNMP data, is helpful " "when discovering and resolving issues that arise within the storage cluster." msgstr "" #: ../storage-focus-operational-considerations.rst:31 msgid "A storage-focused cloud design should include:" msgstr "" #: ../storage-focus-operational-considerations.rst:33 msgid "Monitoring of physical hardware resources." msgstr "" #: ../storage-focus-operational-considerations.rst:35 msgid "Monitoring of environmental resources such as temperature and humidity." msgstr "" #: ../storage-focus-operational-considerations.rst:38 msgid "" "Monitoring of storage resources such as available storage, memory, and CPU." msgstr "" #: ../storage-focus-operational-considerations.rst:41 msgid "" "Monitoring of advanced storage performance data to ensure that storage " "systems are performing as expected." msgstr "" #: ../storage-focus-operational-considerations.rst:44 msgid "" "Monitoring of network resources for service disruptions which would affect " "access to storage." msgstr "" #: ../storage-focus-operational-considerations.rst:47 msgid "Centralized log collection." msgstr "" #: ../storage-focus-operational-considerations.rst:49 msgid "Log analytics capabilities." msgstr "" #: ../storage-focus-operational-considerations.rst:51 msgid "" "Ticketing system (or integration with a ticketing system) to track issues." msgstr "" #: ../storage-focus-operational-considerations.rst:54 msgid "" "Alerting and notification of responsible teams or automated systems which " "remediate problems with storage as they arise." msgstr "" #: ../storage-focus-operational-considerations.rst:57 msgid "" "Network Operations Center (NOC) staffed and always available to resolve " "issues." msgstr "" #: ../storage-focus-operational-considerations.rst:61 msgid "Application awareness" msgstr "" #: ../storage-focus-operational-considerations.rst:63 msgid "" "Well-designed applications should be aware of underlying storage subsystems " "in order to use cloud storage solutions effectively." msgstr "" #: ../storage-focus-operational-considerations.rst:66 msgid "" "If natively available replication is not available, operations personnel " "must be able to modify the application so that they can provide their own " "replication service. In the event that replication is unavailable, " "operations personnel can design applications to react such that they can " "provide their own replication services. An application designed to detect " "underlying storage systems can function in a wide variety of " "infrastructures, and still have the same basic behavior regardless of the " "differences in the underlying infrastructure." msgstr "" #: ../storage-focus-operational-considerations.rst:76 msgid "Fault tolerance and availability" msgstr "" #: ../storage-focus-operational-considerations.rst:78 msgid "" "Designing for fault tolerance and availability of storage systems in an " "OpenStack cloud is vastly different when comparing the Block Storage and " "Object Storage services." msgstr "" #: ../storage-focus-operational-considerations.rst:83 msgid "Block Storage fault tolerance and availability" msgstr "" #: ../storage-focus-operational-considerations.rst:85 msgid "" "Configure Block Storage resource nodes with advanced RAID controllers and " "high performance disks to provide fault tolerance at the hardware level." msgstr "" #: ../storage-focus-operational-considerations.rst:89 msgid "" "Deploy high performing storage solutions such as SSD disk drives or flash " "storage systems for applications requiring extreme performance out of Block " "Storage devices." msgstr "" #: ../storage-focus-operational-considerations.rst:93 msgid "" "In environments that place extreme demands on Block Storage, we recommend " "using multiple storage pools. In this case, each pool of devices should have " "a similar hardware design and disk configuration across all hardware nodes " "in that pool. This allows for a design that provides applications with " "access to a wide variety of Block Storage pools, each with their own " "redundancy, availability, and performance characteristics. When deploying " "multiple pools of storage it is also important to consider the impact on the " "Block Storage scheduler which is responsible for provisioning storage across " "resource nodes. Ensuring that applications can schedule volumes in multiple " "regions, each with their own network, power, and cooling infrastructure, can " "give tenants the ability to build fault tolerant applications that are " "distributed across multiple availability zones." msgstr "" #: ../storage-focus-operational-considerations.rst:107 msgid "" "In addition to the Block Storage resource nodes, it is important to design " "for high availability and redundancy of the APIs, and related services that " "are responsible for provisioning and providing access to storage. We " "recommend designing a layer of hardware or software load balancers in order " "to achieve high availability of the appropriate REST API services to provide " "uninterrupted service. In some cases, it may also be necessary to deploy an " "additional layer of load balancing to provide access to back-end database " "services responsible for servicing and storing the state of Block Storage " "volumes. We also recommend designing a highly available database solution to " "store the Block Storage databases. Leverage highly available database " "solutions such as Galera and MariaDB to help keep database services online " "for uninterrupted access, so that tenants can manage Block Storage volumes." msgstr "" #: ../storage-focus-operational-considerations.rst:121 msgid "" "In a cloud with extreme demands on Block Storage, the network architecture " "should take into account the amount of East-West bandwidth required for " "instances to make use of the available storage resources. The selected " "network devices should support jumbo frames for transferring large blocks of " "data. In some cases, it may be necessary to create an additional back-end " "storage network dedicated to providing connectivity between instances and " "Block Storage resources so that there is no contention of network resources." msgstr "" #: ../storage-focus-operational-considerations.rst:131 msgid "Object Storage fault tolerance and availability" msgstr "" #: ../storage-focus-operational-considerations.rst:133 msgid "" "While consistency and partition tolerance are both inherent features of the " "Object Storage service, it is important to design the overall storage " "architecture to ensure that the implemented system meets those goals. The " "OpenStack Object Storage service places a specific number of data replicas " "as objects on resource nodes. These replicas are distributed throughout the " "cluster based on a consistent hash ring which exists on all nodes in the " "cluster." msgstr "" #: ../storage-focus-operational-considerations.rst:141 msgid "" "Design the Object Storage system with a sufficient number of zones to " "provide quorum for the number of replicas defined. For example, with three " "replicas configured in the Swift cluster, the recommended number of zones to " "configure within the Object Storage cluster in order to achieve quorum is " "five. While it is possible to deploy a solution with fewer zones, the " "implied risk of doing so is that some data may not be available and API " "requests to certain objects stored in the cluster might fail. For this " "reason, ensure you properly account for the number of zones in the Object " "Storage cluster." msgstr "" #: ../storage-focus-operational-considerations.rst:151 msgid "" "Each Object Storage zone should be self-contained within its own " "availability zone. Each availability zone should have independent access to " "network, power and cooling infrastructure to ensure uninterrupted access to " "data. In addition, a pool of Object Storage proxy servers providing access " "to data stored on the object nodes should service each availability zone. " "Object proxies in each region should leverage local read and write affinity " "so that local storage resources facilitate access to objects wherever " "possible. We recommend deploying upstream load balancing to ensure that " "proxy services are distributed across the multiple zones and, in some cases, " "it may be necessary to make use of third-party solutions to aid with " "geographical distribution of services." msgstr "" #: ../storage-focus-operational-considerations.rst:163 msgid "" "A zone within an Object Storage cluster is a logical division. Any of the " "following may represent a zone:" msgstr "" #: ../storage-focus-operational-considerations.rst:166 msgid "A disk within a single node" msgstr "" #: ../storage-focus-operational-considerations.rst:168 msgid "One zone per node" msgstr "" #: ../storage-focus-operational-considerations.rst:170 msgid "Zone per collection of nodes" msgstr "" #: ../storage-focus-operational-considerations.rst:172 msgid "Multiple racks" msgstr "" #: ../storage-focus-operational-considerations.rst:174 msgid "Multiple DCs" msgstr "" #: ../storage-focus-operational-considerations.rst:176 msgid "" "Selecting the proper zone design is crucial for allowing the Object Storage " "cluster to scale while providing an available and redundant storage system. " "It may be necessary to configure storage policies that have different " "requirements with regards to replicas, retention and other factors that " "could heavily affect the design of storage in a specific zone." msgstr "" #: ../storage-focus-operational-considerations.rst:184 msgid "Scaling storage services" msgstr "" #: ../storage-focus-operational-considerations.rst:186 msgid "" "Adding storage capacity and bandwidth is a very different process when " "comparing the Block and Object Storage services. While adding Block Storage " "capacity is a relatively simple process, adding capacity and bandwidth to " "the Object Storage systems is a complex task that requires careful planning " "and consideration during the design phase." msgstr "" #: ../storage-focus-operational-considerations.rst:193 msgid "Scaling Block Storage" msgstr "" #: ../storage-focus-operational-considerations.rst:195 msgid "" "You can upgrade Block Storage pools to add storage capacity without " "interrupting the overall Block Storage service. Add nodes to the pool by " "installing and configuring the appropriate hardware and software and then " "allowing that node to report in to the proper storage pool via the message " "bus. This is because Block Storage nodes report into the scheduler service " "advertising their availability. After the node is online and available, " "tenants can make use of those storage resources instantly." msgstr "" #: ../storage-focus-operational-considerations.rst:204 msgid "" "In some cases, the demand on Block Storage from instances may exhaust the " "available network bandwidth. As a result, design network infrastructure that " "services Block Storage resources in such a way that you can add capacity and " "bandwidth easily. This often involves the use of dynamic routing protocols " "or advanced networking solutions to add capacity to downstream devices " "easily. Both the front-end and back-end storage network designs should " "encompass the ability to quickly and easily add capacity and bandwidth." msgstr "" #: ../storage-focus-operational-considerations.rst:214 msgid "Scaling Object Storage" msgstr "" #: ../storage-focus-operational-considerations.rst:216 msgid "" "Adding back-end storage capacity to an Object Storage cluster requires " "careful planning and consideration. In the design phase, it is important to " "determine the maximum partition power required by the Object Storage " "service, which determines the maximum number of partitions which can exist. " "Object Storage distributes data among all available storage, but a partition " "cannot span more than one disk, so the maximum number of partitions can only " "be as high as the number of disks." msgstr "" #: ../storage-focus-operational-considerations.rst:224 msgid "" "For example, a system that starts with a single disk and a partition power " "of 3 can have 8 (2^3) partitions. Adding a second disk means that each has 4 " "partitions. The one-disk-per-partition limit means that this system can " "never have more than 8 disks, limiting its scalability. However, a system " "that starts with a single disk and a partition power of 10 can have up to " "1024 (2^10) disks." msgstr "" #: ../storage-focus-operational-considerations.rst:231 msgid "" "As you add back-end storage capacity to the system, the partition maps " "redistribute data amongst the storage nodes. In some cases, this replication " "consists of extremely large data sets. In these cases, we recommend using " "back-end replication links that do not contend with tenants' access to data." msgstr "" #: ../storage-focus-operational-considerations.rst:237 msgid "" "As more tenants begin to access data within the cluster and their data sets " "grow, it is necessary to add front-end bandwidth to service data access " "requests. Adding front-end bandwidth to an Object Storage cluster requires " "careful planning and design of the Object Storage proxies that tenants use " "to gain access to the data, along with the high availability solutions that " "enable easy scaling of the proxy layer. We recommend designing a front-end " "load balancing layer that tenants and consumers use to gain access to data " "stored within the cluster. This load balancing layer may be distributed " "across zones, regions or even across geographic boundaries, which may also " "require that the design encompass geo-location solutions." msgstr "" #: ../storage-focus-operational-considerations.rst:249 msgid "" "In some cases, you must add bandwidth and capacity to the network resources " "servicing requests between proxy servers and storage nodes. For this reason, " "the network architecture used for access to storage nodes and proxy servers " "should make use of a design which is scalable." msgstr "" #: ../storage-focus-prescriptive-examples.rst:2 msgid "Prescriptive Examples" msgstr "" #: ../storage-focus-prescriptive-examples.rst:4 msgid "" "Storage-focused architecture depends on specific use cases. This section " "discusses three example use cases:" msgstr "" #: ../storage-focus-prescriptive-examples.rst:7 msgid "An object store with a RESTful interface" msgstr "" #: ../storage-focus-prescriptive-examples.rst:9 msgid "Compute analytics with parallel file systems" msgstr "" #: ../storage-focus-prescriptive-examples.rst:11 msgid "High performance database" msgstr "" #: ../storage-focus-prescriptive-examples.rst:13 msgid "" "The example below shows a REST interface without a high performance " "requirement." msgstr "" #: ../storage-focus-prescriptive-examples.rst:16 msgid "" "Swift is a highly scalable object store that is part of the OpenStack " "project. This diagram explains the example architecture:" msgstr "" #: ../storage-focus-prescriptive-examples.rst:21 msgid "" "The example REST interface, presented as a traditional Object store running " "on traditional spindles, does not require a high performance caching tier." msgstr "" #: ../storage-focus-prescriptive-examples.rst:25 msgid "This example uses the following components:" msgstr "" #: ../storage-focus-prescriptive-examples.rst:27 #: ../storage-focus-prescriptive-examples.rst:116 msgid "Network:" msgstr "" #: ../storage-focus-prescriptive-examples.rst:29 msgid "" "10 GbE horizontally scalable spine leaf back-end storage and front end " "network." msgstr "" #: ../storage-focus-prescriptive-examples.rst:32 #: ../storage-focus-prescriptive-examples.rst:121 msgid "Storage hardware:" msgstr "" #: ../storage-focus-prescriptive-examples.rst:34 msgid "" "10 storage servers each with 12x4 TB disks equaling 480 TB total space with " "approximately 160 TB of usable space after replicas." msgstr "" #: ../storage-focus-prescriptive-examples.rst:37 msgid "Proxy:" msgstr "" #: ../storage-focus-prescriptive-examples.rst:39 #: ../storage-focus-prescriptive-examples.rst:131 msgid "3x proxies" msgstr "" #: ../storage-focus-prescriptive-examples.rst:41 #: ../storage-focus-prescriptive-examples.rst:133 msgid "2x10 GbE bonded front end" msgstr "" #: ../storage-focus-prescriptive-examples.rst:43 #: ../storage-focus-prescriptive-examples.rst:135 msgid "2x10 GbE back-end bonds" msgstr "" #: ../storage-focus-prescriptive-examples.rst:45 #: ../storage-focus-prescriptive-examples.rst:137 msgid "Approximately 60 Gb of total bandwidth to the back-end storage cluster" msgstr "" #: ../storage-focus-prescriptive-examples.rst:50 msgid "" "It may be necessary to implement a 3rd-party caching layer for some " "applications to achieve suitable performance." msgstr "" #: ../storage-focus-prescriptive-examples.rst:54 msgid "Compute analytics with Data processing service" msgstr "" #: ../storage-focus-prescriptive-examples.rst:56 msgid "" "Analytics of large data sets are dependent on the performance of the storage " "system. Clouds using storage systems such as Hadoop Distributed File System " "(HDFS) have inefficiencies which can cause performance issues." msgstr "" #: ../storage-focus-prescriptive-examples.rst:61 msgid "" "One potential solution to this problem is the implementation of storage " "systems designed for performance. Parallel file systems have previously " "filled this need in the HPC space and are suitable for large scale " "performance-orientated systems." msgstr "" #: ../storage-focus-prescriptive-examples.rst:66 msgid "" "OpenStack has integration with Hadoop to manage the Hadoop cluster within " "the cloud. The following diagram shows an OpenStack store with a high " "performance requirement:" msgstr "" #: ../storage-focus-prescriptive-examples.rst:72 msgid "" "The hardware requirements and configuration are similar to those of the High " "Performance Database example below. In this case, the architecture uses " "Ceph's Swift-compatible REST interface, features that allow for connecting a " "caching pool to allow for acceleration of the presented pool." msgstr "" #: ../storage-focus-prescriptive-examples.rst:79 msgid "High performance database with Database service" msgstr "" #: ../storage-focus-prescriptive-examples.rst:81 msgid "" "Databases are a common workload that benefit from high performance storage " "back ends. Although enterprise storage is not a requirement, many " "environments have existing storage that OpenStack cloud can use as back " "ends. You can create a storage pool to provide block devices with OpenStack " "Block Storage for instances as well as object interfaces. In this example, " "the database I-O requirements are high and demand storage presented from a " "fast SSD pool." msgstr "" #: ../storage-focus-prescriptive-examples.rst:89 msgid "" "A storage system presents a LUN backed by a set of SSDs using a traditional " "storage array with OpenStack Block Storage integration or a storage platform " "such as Ceph or Gluster." msgstr "" #: ../storage-focus-prescriptive-examples.rst:93 msgid "" "This system can provide additional performance. For example, in the database " "example below, a portion of the SSD pool can act as a block device to the " "Database server. In the high performance analytics example, the inline SSD " "cache layer accelerates the REST interface." msgstr "" #: ../storage-focus-prescriptive-examples.rst:100 msgid "" "In this example, Ceph presents a Swift-compatible REST interface, as well as " "a block level storage from a distributed storage cluster. It is highly " "flexible and has features that enable reduced cost of operations such as " "self healing and auto balancing. Using erasure coded pools are a suitable " "way of maximizing the amount of usable space." msgstr "" #: ../storage-focus-prescriptive-examples.rst:108 msgid "" "There are special considerations around erasure coded pools. For example, " "higher computational requirements and limitations on the operations allowed " "on an object; erasure coded pools do not support partial writes." msgstr "" #: ../storage-focus-prescriptive-examples.rst:113 msgid "" "Using Ceph as an applicable example, a potential architecture would have the " "following requirements:" msgstr "" #: ../storage-focus-prescriptive-examples.rst:118 msgid "" "10 GbE horizontally scalable spine leaf back-end storage and front-end " "network" msgstr "" #: ../storage-focus-prescriptive-examples.rst:123 msgid "5 storage servers for caching layer 24x1 TB SSD" msgstr "" #: ../storage-focus-prescriptive-examples.rst:125 msgid "" "10 storage servers each with 12x4 TB disks which equals 480 TB total space " "with about approximately 160 TB of usable space after 3 replicas" msgstr "" #: ../storage-focus-prescriptive-examples.rst:129 msgid "REST proxy:" msgstr "" #: ../storage-focus-prescriptive-examples.rst:140 msgid "" "Using an SSD cache layer, you can present block devices directly to " "hypervisors or instances. The REST interface can also use the SSD cache " "systems as an inline cache." msgstr "" #: ../storage-focus-technical-considerations.rst:4 msgid "" "Some of the key technical considerations that are critical to a storage-" "focused OpenStack design architecture include:" msgstr "" #: ../storage-focus-technical-considerations.rst:8 msgid "" "Input-Output performance requirements require researching and modeling " "before deciding on a final storage framework. Running benchmarks for Input-" "Output performance provides a baseline for expected performance levels. If " "these tests include details, then the resulting data can help model behavior " "and results during different workloads. Running scripted smaller benchmarks " "during the lifecycle of the architecture helps record the system health at " "different points in time. The data from these scripted benchmarks assist in " "future scoping and gaining a deeper understanding of an organization's needs." msgstr "" #: ../storage-focus-technical-considerations.rst:17 msgid "Input-Output requirements" msgstr "" #: ../storage-focus-technical-considerations.rst:20 msgid "" "Scaling storage solutions in a storage-focused OpenStack architecture design " "is driven by initial requirements, including :term:`IOPS`, capacity, " "bandwidth, and future needs. Planning capacity based on projected needs over " "the course of a budget cycle is important for a design. The architecture " "should balance cost and capacity, while also allowing flexibility to " "implement new technologies and methods as they become available." msgstr "" #: ../storage-focus-technical-considerations.rst:26 msgid "Scale" msgstr "" #: ../storage-focus-technical-considerations.rst:29 msgid "" "Designing security around data has multiple points of focus that vary " "depending on SLAs, legal requirements, industry regulations, and " "certifications needed for systems or people. Consider compliance with HIPPA, " "ISO9000, and SOX based on the type of data. For certain organizations, " "multiple levels of access control are important." msgstr "" #: ../storage-focus-technical-considerations.rst:36 msgid "" "Interoperability and integration with OpenStack can be paramount in deciding " "on a storage hardware and storage management platform. Interoperability and " "integration includes factors such as OpenStack Block Storage " "interoperability, OpenStack Object Storage compatibility, and hypervisor " "compatibility (which affects the ability to use storage for ephemeral " "instance storage)." msgstr "" #: ../storage-focus-technical-considerations.rst:41 msgid "OpenStack compatibility" msgstr "" #: ../storage-focus-technical-considerations.rst:44 msgid "" "You must address a range of storage management-related considerations in the " "design of a storage-focused OpenStack cloud. These considerations include, " "but are not limited to, backup strategy (and restore strategy, since a " "backup that cannot be restored is useless), data valuation-hierarchical " "storage management, retention strategy, data placement, and workflow " "automation." msgstr "" #: ../storage-focus-technical-considerations.rst:50 msgid "Storage management" msgstr "" #: ../storage-focus-technical-considerations.rst:53 msgid "" "Data grids are helpful when answering questions around data valuation. Data " "grids improve decision making through correlation of access patterns, " "ownership, and business-unit revenue with other metadata values to deliver " "actionable information about data." msgstr "" #: ../storage-focus-technical-considerations.rst:56 msgid "Data grids" msgstr "" #: ../storage-focus-technical-considerations.rst:58 msgid "" "When building a storage-focused OpenStack architecture, strive to build a " "flexible design based on an industry standard core. One way of accomplishing " "this might be through the use of different back ends serving different use " "cases." msgstr "" #: ../storage-focus.rst:3 msgid "Storage focused" msgstr "" #: ../storage-focus.rst:13 msgid "" "Cloud storage is a model of data storage that stores digital data in logical " "pools and physical storage that spans across multiple servers and locations. " "Cloud storage commonly refers to a hosted object storage service, however " "the term also includes other types of data storage that are available as a " "service, for example block storage." msgstr "" #: ../storage-focus.rst:19 msgid "" "Cloud storage runs on virtualized infrastructure and resembles broader cloud " "computing in terms of accessible interfaces, elasticity, scalability, multi-" "tenancy, and metered resources. You can use cloud storage services from an " "off-premises service or deploy on-premises." msgstr "" #: ../storage-focus.rst:24 msgid "" "Cloud storage consists of many distributed, synonymous resources, which are " "often referred to as integrated storage clouds. Cloud storage is highly " "fault tolerant through redundancy and the distribution of data. It is highly " "durable through the creation of versioned copies, and can be consistent with " "regard to data replicas." msgstr "" #: ../storage-focus.rst:30 msgid "" "At large scale, management of data operations is a resource intensive " "process for an organization. Hierarchical storage management (HSM) systems " "and data grids help annotate and report a baseline data valuation to make " "intelligent decisions and automate data decisions. HSM enables automated " "tiering and movement, as well as orchestration of data operations. A data " "grid is an architecture, or set of services evolving technology, that brings " "together sets of services enabling users to manage large data sets." msgstr "" #: ../storage-focus.rst:39 msgid "Example applications deployed with cloud storage characteristics:" msgstr "" #: ../storage-focus.rst:41 msgid "Active archive, backups and hierarchical storage management." msgstr "" #: ../storage-focus.rst:43 msgid "" "General content storage and synchronization. An example of this is private " "dropbox." msgstr "" #: ../storage-focus.rst:46 msgid "Data analytics with parallel file systems." msgstr "" #: ../storage-focus.rst:48 msgid "" "Unstructured data store for services. For example, social media back-end " "storage." msgstr "" #: ../storage-focus.rst:51 msgid "Persistent block storage." msgstr "" #: ../storage-focus.rst:53 msgid "Operating system and application image store." msgstr "" #: ../storage-focus.rst:55 msgid "Media streaming." msgstr "" #: ../storage-focus.rst:57 msgid "Databases." msgstr "" #: ../storage-focus.rst:59 msgid "Content distribution." msgstr "" #: ../storage-focus.rst:61 msgid "Cloud storage peering." msgstr ""