openstack/openstack-manuals
Code Issues Proposed changes
30d3d29eea
openstack-manuals/doc/arch-design/locale/arch-design.pot
OpenStack Proposal Bot aa91021764 Imported Translations from Transifex 
For more information about this automatic import see:
https://wiki.openstack.org/wiki/Translations/Infrastructure

Change-Id: Ie98fac06c166c8ca22ee6ea1b5e8a239daf9b678
2015-04-11 06:10:36 +00:00

6331 lines
533 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2015-04-11 06:07+0000\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ./doc/arch-design/ch_specialized.xml:7(title)
msgid "Specialized cases"
msgstr ""
#: ./doc/arch-design/ch_specialized.xml:9(para)
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 other use cases that are unique enough they can't be neatly categorized into one of the other major sections. This section discusses some of these unique use cases with some additional details and design considerations for each use case:"
msgstr ""
#: ./doc/arch-design/ch_specialized.xml:20(para)
msgid "<link linkend=\"specialized-networking-example\">Specialized Networking</link>: This describes running networking-oriented software that may involve reading packets directly from the wire or participating in routing protocols."
msgstr ""
#: ./doc/arch-design/ch_specialized.xml:30(para)
msgid "<link linkend=\"software-defined-networking-sdn\">Software-defined networking (SDN)</link>: This use case details both running an SDN controller from within OpenStack as well as participating in a software-defined network."
msgstr ""
#: ./doc/arch-design/ch_specialized.xml:39(para)
msgid "<link linkend=\"desktop-as-a-service\">Desktop-as-a-Service</link>: This is for organizations that want to run a virtualized desktop environment on a cloud. This can apply to private or public clouds."
msgstr ""
#: ./doc/arch-design/ch_specialized.xml:48(para)
msgid "<link linkend=\"arch-guide-openstack-on-openstack\">OpenStack on OpenStack</link>: Some organizations are finding that it makes technical sense to build a multi-tiered cloud by running OpenStack on top of an OpenStack installation."
msgstr ""
#: ./doc/arch-design/ch_specialized.xml:58(para)
msgid "<link linkend=\"specialized-hardware\">Specialized hardware</link>: Some highly specialized situations will require the use of specialized hardware devices from within the OpenStack environment."
msgstr ""
#: ./doc/arch-design/ch_massively_scalable.xml:7(title)
msgid "Massively scalable"
msgstr ""
#: ./doc/arch-design/ch_massively_scalable.xml:9(para)
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. 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 ""
#: ./doc/arch-design/ch_massively_scalable.xml:21(para)
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. Like the general purpose cloud, 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 ""
#: ./doc/arch-design/ch_massively_scalable.xml:32(para)
msgid "Services provided by a massively scalable OpenStack cloud include:"
msgstr ""
#: ./doc/arch-design/ch_massively_scalable.xml:36(para) ./doc/arch-design/ch_generalpurpose.xml:63(para)
msgid "Virtual-machine disk image library"
msgstr ""
#: ./doc/arch-design/ch_massively_scalable.xml:39(para) ./doc/arch-design/ch_generalpurpose.xml:66(para)
msgid "Raw block storage"
msgstr ""
#: ./doc/arch-design/ch_massively_scalable.xml:42(para) ./doc/arch-design/ch_generalpurpose.xml:69(para)
msgid "File or object storage"
msgstr ""
#: ./doc/arch-design/ch_massively_scalable.xml:45(para)
msgid "Firewall functionality"
msgstr ""
#: ./doc/arch-design/ch_massively_scalable.xml:48(para)
msgid "Load balancing functionality"
msgstr ""
#: ./doc/arch-design/ch_massively_scalable.xml:51(para)
msgid "Private (non-routable) and public (floating) IP addresses"
msgstr ""
#: ./doc/arch-design/ch_massively_scalable.xml:55(para)
msgid "Virtualized network topologies"
msgstr ""
#: ./doc/arch-design/ch_massively_scalable.xml:58(para) ./doc/arch-design/ch_generalpurpose.xml:85(para)
msgid "Software bundles"
msgstr ""
#: ./doc/arch-design/ch_massively_scalable.xml:61(para)
msgid "Virtual compute resources"
msgstr ""
#: ./doc/arch-design/ch_massively_scalable.xml:64(para)
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 ""
#: ./doc/arch-design/ch_network_focus.xml:7(title)
msgid "Network focused"
msgstr ""
#: ./doc/arch-design/ch_network_focus.xml:9(para)
msgid "All OpenStack deployments are dependent, to some extent, on network communication in order to function properly due to a service-based nature. In some cases, however, use cases dictate that the network is elevated beyond simple infrastructure. This chapter is a discussion of architectures that are more reliant or focused on network services. These architectures are heavily dependent on the network infrastructure and need to be architected so that the network services perform and are reliable in order to satisfy user and application requirements."
msgstr ""
#: ./doc/arch-design/ch_network_focus.xml:19(para)
msgid "Some possible use cases include:"
msgstr ""
#: ./doc/arch-design/ch_network_focus.xml:22(term)
msgid "Content delivery network"
msgstr ""
#: ./doc/arch-design/ch_network_focus.xml:24(para)
msgid "This could include streaming video, photographs or any other cloud based repository of data that is distributed to a large number of end users. Mass market streaming video will be very heavily affected by the network configurations that would affect latency, bandwidth, and the distribution of instances. Not all video streaming is consumer focused. For example, multicast videos (used for media, press conferences, corporate presentations, web conferencing services, and so on) can also utilize a content delivery network. Content delivery will be affected by the location of the video repository and its relationship to end users. Performance is also affected by network throughput of the backend systems, as well as the WAN architecture and the cache methodology."
msgstr ""
#: ./doc/arch-design/ch_network_focus.xml:43(term)
msgid "Network management functions"
msgstr ""
#: ./doc/arch-design/ch_network_focus.xml:45(para)
msgid "A cloud that provides network service functions would be built to support the delivery of back-end network services such as DNS, NTP or SNMP and would be used by a company for internal network management."
msgstr ""
#: ./doc/arch-design/ch_network_focus.xml:53(term)
msgid "Network service offerings"
msgstr ""
#: ./doc/arch-design/ch_network_focus.xml:55(para)
msgid "A cloud can be used to run customer facing network tools to support services. For example, VPNs, MPLS private networks, GRE tunnels and others."
msgstr ""
#: ./doc/arch-design/ch_network_focus.xml:62(term)
msgid "Web portals or web services"
msgstr ""
#: ./doc/arch-design/ch_network_focus.xml:64(para)
msgid "Web servers are a common application for cloud services and we recommend an understanding of the network requirements. The network will need to be able to scale out to meet user demand and deliver webpages with a minimum of latency. Internal east-west and north-south network bandwidth must be considered depending on the details of the portal architecture."
msgstr ""
#: ./doc/arch-design/ch_network_focus.xml:75(term)
msgid "High speed and high volume transactional systems"
msgstr ""
#: ./doc/arch-design/ch_network_focus.xml:77(para)
msgid "These types of applications are very sensitive to network configurations. Examples include many financial systems, credit card transaction applications, trading and other extremely high volume systems. These systems are sensitive to network jitter and latency. They also have a high volume of both east-west and north-south network traffic that needs to be balanced to maximize efficiency of the data delivery. Many of these systems have large high performance database back ends that need to be accessed."
msgstr ""
#: ./doc/arch-design/ch_network_focus.xml:92(term) ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:86(title)
msgid "High availability"
msgstr ""
#: ./doc/arch-design/ch_network_focus.xml:94(para)
msgid "These types of use cases are highly 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 will be able to serve the displaced load until the original site returns to service. It is important to size network capacity to handle the loads that are desired."
msgstr ""
#: ./doc/arch-design/ch_network_focus.xml:105(term)
msgid "Big data"
msgstr ""
#: ./doc/arch-design/ch_network_focus.xml:107(para)
msgid "Clouds that will be used for the management and collection of big data (data ingest) will have a significant demand on network resources. Big data often uses partial replicas of the data to maintain data integrity over large distributed clouds. Other big data applications that require a large amount of network resources are Hadoop, Cassandra, NuoDB, RIAK and other No-SQL and distributed databases."
msgstr ""
#: ./doc/arch-design/ch_network_focus.xml:119(term)
msgid "Virtual desktop infrastructure (VDI)"
msgstr ""
#: ./doc/arch-design/ch_network_focus.xml:121(para)
msgid "This use case is very sensitive to network congestion, latency, jitter and other network characteristics. Like video streaming, the user experience is very 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 ""
#: ./doc/arch-design/ch_network_focus.xml:133(term)
msgid "Voice over IP (VoIP)"
msgstr ""
#: ./doc/arch-design/ch_network_focus.xml:135(para)
msgid "This is extremely 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. It may also require an active queue management implementation to ensure delivery. Users are very sensitive to latency and jitter fluctuations and can detect them at very low levels."
msgstr ""
#: ./doc/arch-design/ch_network_focus.xml:147(term)
msgid "Video Conference or web conference"
msgstr ""
#: ./doc/arch-design/ch_network_focus.xml:149(para)
msgid "This also is extremely sensitive to network congestion, latency, jitter and other network flaws. 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 will be sensitive to network performance issues even at low levels."
msgstr ""
#: ./doc/arch-design/ch_network_focus.xml:160(term) ./doc/arch-design/ch_compute_focus.xml:21(para)
msgid "High performance computing (HPC)"
msgstr ""
#: ./doc/arch-design/ch_network_focus.xml:162(para)
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 ""
#: ./doc/arch-design/ch_introduction.xml:7(title)
msgid "Introduction"
msgstr ""
#: ./doc/arch-design/ch_introduction.xml:9(para)
msgid "OpenStack is a leader in the cloud technology gold rush, as organizations of all stripes discover the increased flexibility and speed to market that self-service cloud and Infrastructure-as-a-Service (IaaS) provides. However, in order to reap those benefits, the cloud must be designed and architected properly."
msgstr ""
#: ./doc/arch-design/ch_introduction.xml:15(para)
msgid "A well-architected cloud provides a stable IT environment that offers easy access to needed resources, usage-based expenses, extra capacity on demand, disaster recovery, and a secure environment. A well-architected cloud does not magically build itself. It requires careful consideration of a multitude of factors both technical and non-technical."
msgstr ""
#: ./doc/arch-design/ch_introduction.xml:21(para)
msgid "There is no single architecture that is \"right\" for an OpenStack cloud deployment. OpenStack can be used for any number of different purposes, each with its own particular requirements and architectural peculiarities."
msgstr ""
#: ./doc/arch-design/ch_introduction.xml:26(para)
msgid "This book is designed to examine some of the most common uses for OpenStack clouds (and some less common uses) and to provide knowledge and advice to help explain the issues that require consideration. These examples, coupled with a wealth of knowledge and advice will help an organization design and build a well-architected OpenStack cloud to fit its unique requirements."
msgstr ""
#: ./doc/arch-design/ch_hybrid.xml:7(title)
msgid "Hybrid"
msgstr ""
#: ./doc/arch-design/ch_hybrid.xml:9(para)
msgid "<glossterm baseform=\"hybrid cloud\">Hybrid cloud</glossterm>, by definition, means that the design spans more than one cloud. An example of this kind of architecture may include a situation in which the design involves more than one OpenStack cloud (for example, an OpenStack-based private cloud and an OpenStack-based public cloud), or it may be a situation incorporating an OpenStack cloud and a non-OpenStack cloud (for example, an OpenStack-based private cloud that interacts with Amazon Web Services). <glossterm baseform=\"bursting\">Bursting</glossterm> into an external cloud is the practice of creating new instances to alleviate extra load where there is no available capacity in the private cloud."
msgstr ""
#: ./doc/arch-design/ch_hybrid.xml:22(para)
msgid "Some situations that could involve hybrid cloud architecture include:"
msgstr ""
#: ./doc/arch-design/ch_hybrid.xml:26(para)
msgid "Bursting from a private cloud to a public cloud"
msgstr ""
#: ./doc/arch-design/ch_hybrid.xml:30(para)
msgid "Disaster recovery"
msgstr ""
#: ./doc/arch-design/ch_hybrid.xml:33(para)
msgid "Development and testing"
msgstr ""
#: ./doc/arch-design/ch_hybrid.xml:36(para)
msgid "Federated cloud, enabling users to choose resources from multiple providers"
msgstr ""
#: ./doc/arch-design/ch_hybrid.xml:40(para)
msgid "Hybrid clouds built to support legacy systems as they transition to cloud"
msgstr ""
#: ./doc/arch-design/ch_hybrid.xml:44(para)
msgid "As a hybrid cloud design deals with systems that are outside of the control of the cloud architect or organization, a hybrid cloud architecture requires considering aspects of the architecture that might not have otherwise been necessary. For example, the design may need to deal with hardware, software, and APIs under the control of a separate organization."
msgstr ""
#: ./doc/arch-design/ch_hybrid.xml:50(para)
msgid "Similarly, the degree to which the architecture is OpenStack-based will have an effect on the cloud operator or cloud consumer's 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, users, operators and consumers will need an overarching tool known as a cloud management platform (CMP). Any organization that is working with multiple clouds already has a CMP, even if that CMP is the operator who logs into an external web portal and launches a public cloud instance."
msgstr ""
#: ./doc/arch-design/ch_hybrid.xml:61(para)
msgid "There are commercially available options, such as Rightscale, and open source options, such as ManageIQ (<link href=\"http://manageiq.org\">http://manageiq.org</link>), but there is no single CMP that can address all needs in all scenarios. Whereas most of the sections of this book talk about the aspects of OpenStack, an architect needs to consider when designing an OpenStack architecture. This section will also discuss the things the architect must address when choosing or building a CMP to run a hybrid cloud design, even if the CMP will be a manually built solution."
msgstr ""
#: ./doc/arch-design/ch_multi_site.xml:7(title)
msgid "Multi-site"
msgstr ""
#: ./doc/arch-design/ch_multi_site.xml:9(para)
msgid "A multi-site OpenStack environment is one in which services, located in more than one data center, are used to provide the overall solution. Usage requirements of different multi-site clouds may vary widely, but they share some common needs. 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. With careful planning in the design phase, OpenStack can act as an excellent multi-site cloud solution for a multitude of needs."
msgstr ""
#: ./doc/arch-design/ch_multi_site.xml:19(para)
msgid "Some use cases that might indicate a need for a multi-site deployment of OpenStack include:"
msgstr ""
#: ./doc/arch-design/ch_multi_site.xml:23(para)
msgid "An organization with a diverse geographic footprint."
msgstr ""
#: ./doc/arch-design/ch_multi_site.xml:27(para)
msgid "Geo-location sensitive data."
msgstr ""
#: ./doc/arch-design/ch_multi_site.xml:30(para)
msgid "Data locality, in which specific data or functionality should be close to users."
msgstr ""
#: ./doc/arch-design/ch_storage_focus.xml:7(title)
msgid "Storage focused"
msgstr ""
#: ./doc/arch-design/ch_storage_focus.xml:9(para)
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 ""
#: ./doc/arch-design/ch_storage_focus.xml:15(para)
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 ""
#: ./doc/arch-design/ch_storage_focus.xml:20(para)
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 ""
#: ./doc/arch-design/ch_storage_focus.xml:26(para)
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 ""
#: ./doc/arch-design/ch_storage_focus.xml:35(para)
msgid "Example applications deployed with cloud storage characteristics:"
msgstr ""
#: ./doc/arch-design/ch_storage_focus.xml:39(para)
msgid "Active archive, backups and hierarchical storage management."
msgstr ""
#: ./doc/arch-design/ch_storage_focus.xml:43(para)
msgid "General content storage and synchronization. An example of this is private dropbox."
msgstr ""
#: ./doc/arch-design/ch_storage_focus.xml:47(para)
msgid "Data analytics with parallel file systems."
msgstr ""
#: ./doc/arch-design/ch_storage_focus.xml:50(para)
msgid "Unstructured data store for services. For example, social media back-end storage."
msgstr ""
#: ./doc/arch-design/ch_storage_focus.xml:54(para)
msgid "Persistent block storage."
msgstr ""
#: ./doc/arch-design/ch_storage_focus.xml:57(para)
msgid "Operating system and application image store."
msgstr ""
#: ./doc/arch-design/ch_storage_focus.xml:60(para)
msgid "Media streaming."
msgstr ""
#: ./doc/arch-design/ch_storage_focus.xml:63(para)
msgid "Databases."
msgstr ""
#: ./doc/arch-design/ch_storage_focus.xml:66(para)
msgid "Content distribution."
msgstr ""
#: ./doc/arch-design/ch_storage_focus.xml:69(para)
msgid "Cloud storage peering."
msgstr ""
#: ./doc/arch-design/ch_generalpurpose.xml:7(title)
msgid "General purpose"
msgstr ""
#: ./doc/arch-design/ch_generalpurpose.xml:8(para)
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 ""
#: ./doc/arch-design/ch_generalpurpose.xml:18(para)
msgid "General purpose clouds are homogeneous deployments and are not suited to specialized environments or edge case situations."
msgstr ""
#: ./doc/arch-design/ch_generalpurpose.xml:23(para)
msgid "Common uses of a general purpose cloud include:"
msgstr ""
#: ./doc/arch-design/ch_generalpurpose.xml:28(para)
msgid "Providing a simple database"
msgstr ""
#: ./doc/arch-design/ch_generalpurpose.xml:33(para)
msgid "A web application runtime environment"
msgstr ""
#: ./doc/arch-design/ch_generalpurpose.xml:38(para)
msgid "A shared application development platform"
msgstr ""
#: ./doc/arch-design/ch_generalpurpose.xml:43(para)
msgid "Lab test bed"
msgstr ""
#: ./doc/arch-design/ch_generalpurpose.xml:48(para)
msgid "Use cases that benefit from scale-out rather than scale-up approaches are good candidates for general purpose cloud architecture."
msgstr ""
#: ./doc/arch-design/ch_generalpurpose.xml:51(para)
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. General purpose clouds are designed to be platforms that are suited for general purpose applications."
msgstr ""
#: ./doc/arch-design/ch_generalpurpose.xml:58(para)
msgid "General purpose clouds are limited to the most basic components, but they can include additional resources such as:"
msgstr ""
#: ./doc/arch-design/ch_generalpurpose.xml:72(para) ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:174(para)
msgid "Firewalls"
msgstr ""
#: ./doc/arch-design/ch_generalpurpose.xml:75(para)
msgid "Load balancers"
msgstr ""
#: ./doc/arch-design/ch_generalpurpose.xml:78(para)
msgid "IP addresses"
msgstr ""
#: ./doc/arch-design/ch_generalpurpose.xml:81(para)
msgid "Network overlays or virtual local area networks (VLANs)"
msgstr ""
#: ./doc/arch-design/bk-openstack-arch-design.xml:7(title)
msgid "OpenStack Architecture Design Guide"
msgstr ""
#: ./doc/arch-design/bk-openstack-arch-design.xml:9(titleabbrev)
msgid "Architecture Guide"
msgstr ""
#: ./doc/arch-design/bk-openstack-arch-design.xml:17(orgname) ./doc/arch-design/bk-openstack-arch-design.xml:23(holder)
msgid "OpenStack Foundation"
msgstr ""
#: ./doc/arch-design/bk-openstack-arch-design.xml:21(year)
msgid "2014"
msgstr ""
#: ./doc/arch-design/bk-openstack-arch-design.xml:22(year)
msgid "2015"
msgstr ""
#: ./doc/arch-design/bk-openstack-arch-design.xml:25(releaseinfo)
msgid "current"
msgstr ""
#: ./doc/arch-design/bk-openstack-arch-design.xml:26(productname)
msgid "OpenStack"
msgstr ""
#: ./doc/arch-design/bk-openstack-arch-design.xml:30(remark)
msgid "Copyright details are filled in by the template."
msgstr ""
#: ./doc/arch-design/bk-openstack-arch-design.xml:36(remark)
msgid "Remaining licensing details are filled in by the template."
msgstr ""
#: ./doc/arch-design/bk-openstack-arch-design.xml:41(para)
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 ""
#: ./doc/arch-design/bk-openstack-arch-design.xml:49(date)
msgid "2014-10-15"
msgstr ""
#: ./doc/arch-design/bk-openstack-arch-design.xml:53(para)
msgid "Incorporate edits to follow OpenStack style."
msgstr ""
#: ./doc/arch-design/bk-openstack-arch-design.xml:60(date)
msgid "2014-07-21"
msgstr ""
#: ./doc/arch-design/bk-openstack-arch-design.xml:64(para)
msgid "Initial release."
msgstr ""
#: ./doc/arch-design/ch_compute_focus.xml:7(title)
msgid "Compute focused"
msgstr ""
#: ./doc/arch-design/ch_compute_focus.xml:9(para)
msgid "A compute-focused cloud is a specialized subset of the general purpose OpenStack cloud architecture. Unlike the general purpose OpenStack architecture, which is built to host a wide variety of workloads and applications and does not heavily tax any particular computing aspect, a compute-focused cloud is built and designed specifically to support compute intensive workloads. As such, the design must be specifically tailored to support hosting compute intensive workloads. Compute intensive workloads may be CPU intensive, RAM intensive, or both. However, they are not typically storage intensive or network intensive. Compute-focused workloads may include the following use cases:"
msgstr ""
#: ./doc/arch-design/ch_compute_focus.xml:24(para)
msgid "Big data analytics using Hadoop or other distributed data stores"
msgstr ""
#: ./doc/arch-design/ch_compute_focus.xml:28(para)
msgid "Continuous integration/continuous deployment (CI/CD)"
msgstr ""
#: ./doc/arch-design/ch_compute_focus.xml:31(para)
msgid "Platform-as-a-Service (PaaS)"
msgstr ""
#: ./doc/arch-design/ch_compute_focus.xml:34(para)
msgid "Signal processing for network function virtualization (NFV)"
msgstr ""
#: ./doc/arch-design/ch_compute_focus.xml:37(para)
msgid "Based on the use case requirements, such clouds might need to provide additional services such as a virtual machine disk library, file or object storage, firewalls, load balancers, IP addresses, and network connectivity in the form of overlays or virtual local area networks (VLANs). A compute-focused OpenStack cloud will not typically use raw block storage services since the applications hosted on a compute-focused OpenStack cloud generally do not need persistent block storage."
msgstr ""
#: ./doc/arch-design/ch_references.xml:8(title) ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:153(title)
msgid "References"
msgstr ""
#: ./doc/arch-design/ch_references.xml:9(para)
msgid "<link href=\"http://ec.europa.eu/justice/data-protection/\">Data Protection framework of the European Union</link>: Guidance on Data Protection laws governed by the EU."
msgstr ""
#: ./doc/arch-design/ch_references.xml:15(para)
msgid "<link href=\"http://www.internetsociety.org/deploy360/blog/2014/05/goodbye-ipv4-iana-starts-allocating-final-address-blocks/\">Depletion of IPv4 Addresses</link>: describing how IPv4 addresses and the migration to IPv6 is inevitable."
msgstr ""
#: ./doc/arch-design/ch_references.xml:21(para)
msgid "<link href=\"http://www.garrettcom.com/techsupport/papers/ethernet_switch_reliability.pdf\">Ethernet Switch Reliability</link>: ​Research white paper on Ethernet Switch reliability."
msgstr ""
#: ./doc/arch-design/ch_references.xml:27(para)
msgid "<link href=\"http://www.finra.org/Industry/Regulation/FINRARules/\">Financial Industry Regulatory Authority</link>: ​Requirements of the Financial Industry Regulatory Authority in the USA."
msgstr ""
#: ./doc/arch-design/ch_references.xml:33(para)
msgid "<link href=\"http://docs.openstack.org/cli-reference/content/chapter_cli-glance-property.html\">Image Service property keys</link>: Glance API property keys allows the administrator to attach custom characteristics to images."
msgstr ""
#: ./doc/arch-design/ch_references.xml:39(para)
msgid "<link href=\"http://libguestfs.org\">LibGuestFS Documentation</link>: Official LibGuestFS documentation."
msgstr ""
#: ./doc/arch-design/ch_references.xml:43(para)
msgid "<link href=\"http://docs.openstack.org/openstack-ops/content/logging_monitoring.html\">Logging and Monitoring</link>: Official OpenStack Operations documentation."
msgstr ""
#: ./doc/arch-design/ch_references.xml:49(para)
msgid "<link href=\"http://manageiq.org/\">ManageIQ Cloud Management Platform</link>: An Open Source Cloud Management Platform for managing multiple clouds."
msgstr ""
#: ./doc/arch-design/ch_references.xml:54(para)
msgid "<link href=\"http://www.n-tron.com/pdf/network_availability.pdf\">N-Tron Network Availability</link>: Research white paper on network availability."
msgstr ""
#: ./doc/arch-design/ch_references.xml:60(para)
msgid "<link href=\"http://davejingtian.org/2014/03/30/nested-kvm-just-for-fun\">Nested KVM</link>: Post on how to nest KVM under KVM."
msgstr ""
#: ./doc/arch-design/ch_references.xml:65(para)
msgid "<link href=\"http://www.opencompute.org/\">Open Compute Project</link>: 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 ""
#: ./doc/arch-design/ch_references.xml:72(para)
msgid "<link href=\"http://docs.openstack.org/openstack-ops/content/flavors.html\">OpenStack Flavors</link>: Official OpenStack documentation."
msgstr ""
#: ./doc/arch-design/ch_references.xml:77(para)
msgid "<link href=\"http://docs.openstack.org/high-availability-guide/content/\">OpenStack High Availability Guide</link>: Information on how to provide redundancy for the OpenStack components."
msgstr ""
#: ./doc/arch-design/ch_references.xml:83(para)
msgid "<link href=\"https://wiki.openstack.org/wiki/HypervisorSupportMatrix\">OpenStack Hypervisor Support Matrix</link>: ​Matrix of supported hypervisors and capabilities when used with OpenStack."
msgstr ""
#: ./doc/arch-design/ch_references.xml:89(para)
msgid "<link href=\"http://docs.openstack.org/developer/swift/replication_network.html\">OpenStack Object Store (Swift) Replication Reference</link>: Developer documentation of Swift replication."
msgstr ""
#: ./doc/arch-design/ch_references.xml:95(para)
msgid "<link href=\"http://docs.openstack.org/openstack-ops/\">OpenStack Operations Guide</link>: The OpenStack Operations Guide provides information on setting up and installing OpenStack."
msgstr ""
#: ./doc/arch-design/ch_references.xml:101(para)
msgid "<link href=\"http://docs.openstack.org/security-guide/\">OpenStack Security Guide</link>: The OpenStack Security Guide provides information on securing OpenStack deployments."
msgstr ""
#: ./doc/arch-design/ch_references.xml:107(para)
msgid "<link href=\"http://www.openstack.org/marketplace/training\">OpenStack Training Marketplace</link>: The OpenStack Market for training and Vendors providing training on OpenStack."
msgstr ""
#: ./doc/arch-design/ch_references.xml:113(para)
msgid "<link href=\"https://wiki.openstack.org/wiki/Pci_passthrough#How_to_check_PCI_status_with_PCI_api_paches\">PCI passthrough</link>: 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 ""
#: ./doc/arch-design/ch_references.xml:121(para)
msgid "<link href=\"https://wiki.openstack.org/wiki/TripleO\">TripleO</link>: TripleO is a program aimed at installing, upgrading and operating OpenStack clouds using OpenStack's own cloud facilities as the foundation."
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:8(title) ./doc/arch-design/network_focus/section_operational_considerations_network_focus.xml:8(title) ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:8(title) ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:8(title) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:175(title) ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:8(title) ./doc/arch-design/massively_scalable/section_operational_considerations_massively_scalable.xml:8(title) ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:8(title)
msgid "Operational considerations"
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:9(para)
msgid "Deployment of a multi-site OpenStack cloud using regions requires that the service catalog contains per-region entries for each service deployed other than the Identity service itself. There is limited support amongst currently available off-the-shelf OpenStack deployment tools for defining multiple regions in this fashion."
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:15(para)
msgid "Deployers must be aware of this and provide the appropriate customization of the service catalog for their site either manually or via customization of the deployment tools in use."
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:19(para)
msgid "As of the Icehouse release, documentation for implementing this feature is in progress. See this bug for more information: <link href=\"https://bugs.launchpad.net/openstack-manuals/+bug/1340509\">https://bugs.launchpad.net/openstack-manuals/+bug/1340509</link>."
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:26(title)
msgid "Licensing"
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:27(para)
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 in light of the multi-site nature of the cloud."
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:36(para)
msgid "Topics to consider include:"
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:39(para)
msgid "The specific definition of what constitutes a site in the relevant licenses, as the term does not necessarily denote a geographic or otherwise physically isolated location in the traditional sense."
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:46(para)
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 ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:52(para)
msgid "Certain locations might require local vendors to provide support and services for each site provides challenges, but will vary on the licensing agreement in place."
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:59(title)
msgid "Logging and monitoring"
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:60(para)
msgid "Logging and monitoring does not significantly differ for a multi-site OpenStack cloud. The same well known tools described in the <link href=\"http://docs.openstack.org/openstack-ops/content/logging_monitoring.html\">Logging and monitoring chapter</link> of the <citetitle>Operations Guide</citetitle> remain applicable. Logging and monitoring can be provided both on a per-site basis and in a common centralized location."
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:68(para)
msgid "When attempting to deploy logging and monitoring facilities to a centralized location, care must be taken with regards to the load placed on the inter-site networking links."
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:72(title) ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:56(title)
msgid "Upgrades"
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:73(para)
msgid "In multi-site OpenStack clouds deployed using regions each site is, effectively, an independent OpenStack installation which is linked to the others by using centralized services such as Identity which are shared between sites. At a high level the recommended order of operations to upgrade an individual OpenStack environment is (see the <link href=\"http://docs.openstack.org/openstack-ops/content/ops_upgrades-general-steps.html\">Upgrades chapter</link> of the <citetitle>Operations Guide</citetitle> for details):"
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:84(para)
msgid "Upgrade the OpenStack Identity service (keystone)."
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:88(para)
msgid "Upgrade the OpenStack Image Service (glance)."
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:91(para)
msgid "Upgrade OpenStack Compute (nova), including networking components."
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:95(para)
msgid "Upgrade OpenStack Block Storage (cinder)."
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:98(para)
msgid "Upgrade the OpenStack dashboard (horizon)."
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:101(para)
msgid "The process for upgrading a multi-site environment is not significantly different:"
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:105(para)
msgid "Upgrade the shared OpenStack Identity service (keystone) deployment."
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:109(para)
msgid "Upgrade the OpenStack Image Service (glance) at each site."
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:113(para)
msgid "Upgrade OpenStack Compute (nova), including networking components, at each site."
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:117(para)
msgid "Upgrade OpenStack Block Storage (cinder) at each site."
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:121(para)
msgid "Upgrade the OpenStack dashboard (horizon), at each site or in the single central location if it is shared."
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:126(para)
msgid "Note that, as of the OpenStack Icehouse release, 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 maximizes the ability of operations staff to keep a site operational for users of compute services while performing an upgrade."
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:134(title)
msgid "Quota management"
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:135(para)
msgid "To prevent system capacities from being exhausted without notification, OpenStack provides operators with the ability to define quotas. Quotas are used to set operational limits and are currently enforced at the tenant (or project) level rather than at the user level."
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:140(para)
msgid "Quotas are defined on a per-region basis. Operators may wish to 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 ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:147(para)
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 ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:152(para)
msgid "For more information on managing quotas refer to the <link href=\"http://docs.openstack.org/openstack-ops/content/projects_users.html\">Managing projects and users chapter</link> of the <citetitle>OpenStack Operators Guide</citetitle>."
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:159(title)
msgid "Policy management"
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:160(para)
msgid "OpenStack provides a default set of Role Based Access Control (RBAC) policies, defined in a <filename>policy.json</filename> 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 considered a requirement, then it is necessary to ensure proper synchronization of the <filename>policy.json</filename> files to all installations."
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:168(para)
msgid "This must be done using normal system administration tools such as rsync as no functionality for synchronizing policies across regions is currently provided within OpenStack."
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:172(title)
msgid "Documentation"
msgstr ""
#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:173(para)
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 of the cloud infrastructure 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, it is left to the end user 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 ""
#. When image changes, this message will be marked fuzzy or untranslated for you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:21(None)
msgid "@@image: '../figures/Multi-Site_shared_keystone_horizon_swift1.png'; md5=fb80511b491731906fb54d5a1f029f91"
msgstr ""
#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:8(title) ./doc/arch-design/network_focus/section_architecture_network_focus.xml:7(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:12(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:8(title) ./doc/arch-design/hybrid/section_architecture_hybrid.xml:8(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:11(title)
msgid "Architecture"
msgstr ""
#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:9(para)
msgid "This graphic is a high level diagram of a 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 replicated site that would be used for high availability or disaster recovery. The most important design decision is how to configure the storage. It can be configured as a single shared pool or separate pools, depending on the user and technical requirements."
msgstr ""
#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:25(title)
msgid "OpenStack services architecture"
msgstr ""
#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:26(para)
msgid "The OpenStack 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 that can be used to group OpenStack services that are in close proximity to one another. The concept of regions is flexible; it may can 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 or even a single blade chassis, with multiple regions existing in adjacent racks in the same data center."
msgstr ""
#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:36(para)
msgid "The majority of OpenStack components are designed to run within the context of a single region. The OpenStack 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 OpenStack 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 ""
#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:48(para)
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 ""
#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:53(title) ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:155(para) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:22(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:27(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:51(para) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:131(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:18(para)
msgid "Storage"
msgstr ""
#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:54(para)
msgid "With multiple OpenStack regions, having a single OpenStack Object Storage service endpoint that delivers shared file storage for all regions is desirable. The Object Storage service internally replicates files to multiple nodes. The advantages of this are that, if a file placed into the Object Storage service is visible to all regions, it can be used by applications or workloads in any or all of the regions. This simplifies high availability failover and disaster recovery rollback."
msgstr ""
#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:62(para)
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 ""
#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:71(para)
msgid "If the cloud is designed without a single Object Storage Service endpoint for multiple regions, and instead a separate Object Storage Service endpoint is 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 ""
#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:80(para)
msgid "For the Block Storage service, the most important decisions are the selection of the storage technology and whether or not a dedicated network is used to carry storage traffic from the storage service to the compute nodes."
msgstr ""
#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:86(title) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:417(para)
msgid "Networking"
msgstr ""
#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:87(para)
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 of an application generates or receives can be either complementary or be at cross purpose. 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 ""
#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:102(title) ./doc/arch-design/introduction/section_methodology.xml:166(term)
msgid "Dependencies"
msgstr ""
#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:103(para)
msgid "The architecture for a multi-site installation of OpenStack 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 can the recovery from a fault be completed, determines how often the replication of data is required. Ensure that enough storage is allocated to support the data protection strategy."
msgstr ""
#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:115(para)
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 ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:8(title) ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:8(title) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:8(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:416(term) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:12(title) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:8(title) ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:8(title) ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:52(title) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:8(title)
msgid "User requirements"
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:9(para)
msgid "A multi-site architecture is complex and has its own risks and considerations, therefore it is important to make sure when contemplating the design such an architecture that it meets the user and business requirements."
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:13(para) ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:42(para) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:78(para) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:55(para) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:83(para) ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:17(para) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:54(para)
msgid "Many jurisdictions have legislative and regulatory requirements governing the storage and management of data in cloud environments. Common areas of regulation include:"
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:18(para) ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:47(para) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:83(para) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:60(para) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:88(para) ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:22(para)
msgid "Data retention policies ensuring storage of persistent data and records management to meet data archival requirements."
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:23(para) ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:52(para) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:88(para) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:65(para) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:93(para) ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:27(para)
msgid "Data ownership policies governing the possession and responsibility for data."
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:27(para) ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:56(para) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:92(para) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:69(para) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:97(para) ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:31(para)
msgid "Data sovereignty policies governing the storage of data in foreign countries or otherwise separate jurisdictions."
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:32(para)
msgid "Data compliance policies governing types of information that needs to reside in certain locations due to regular issues and, more importantly, cannot reside in other locations for the same reason."
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:38(para)
msgid "Examples of such legal frameworks include the data protection framework of the European Union (<link href=\"http://ec.europa.eu/justice/data-protection\">http://ec.europa.eu/justice/data-protection</link>) and the requirements of the Financial Industry Regulatory Authority (<link href=\"http://www.finra.org/Industry/Regulation/FINRARules\">http://www.finra.org/Industry/Regulation/FINRARules</link>) in the United States. Consult a local regulatory body for more information."
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:47(title)
msgid "Workload characteristics"
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:48(para)
msgid "The expected workload is a critical requirement that needs to be captured to guide decision-making. An understanding of the workloads in the context of the desired multi-site environment and use case is important. Another way of thinking about a workload is to think of it as 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 ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:59(para)
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 ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:63(para)
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 ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:72(title)
msgid "Consistency of images and templates across different sites"
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:74(para)
msgid "It is essential that the deployment of instances is consistent across the different sites. This needs to be 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 each and every site."
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:81(para)
msgid "Not using a centralized object store increases operational overhead so that a consistent image library can be maintained. This could include development of a replication mechanism to handle the transport of images and the changes to the images across multiple sites."
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:87(para)
msgid "If high availability is a requirement to provide continuous infrastructure operations, a basic requirement of high availability should be defined."
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:90(para)
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 has no significant impact on the availability of the OpenStack services of the entire infrastructure."
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:95(para)
msgid "The <link href=\"http://docs.openstack.org/high-availability-guide/content/\"><citetitle>OpenStack High Availability Guide</citetitle></link> contains more information on how to provide redundancy for the OpenStack components."
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:100(para)
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 ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:108(para)
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 ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:112(para)
msgid "Connecting more than two sites increases the challenges and adds more complexity to the design considerations. Multi-site implementations require extra planning to address the additional topology complexity used for internal and external connectivity. Some options include full mesh topology, hub spoke, spine leaf, or 3d Torus."
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:118(para)
msgid "Not all the applications running in a cloud are cloud-aware. If that is the case, there should be clear measures and expectations to define what the infrastructure can support and, more importantly, what it cannot. 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 ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:129(title) ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:39(title)
msgid "Application readiness"
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:130(para)
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 of 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 to expect an infrastructure with little to no redundancy. Existing applications not developed with the cloud in mind may need to be rewritten."
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:139(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:99(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:259(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:583(term) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:24(term) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:20(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:56(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:169(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:391(term) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:19(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:15(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:35(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:162(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:400(term) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:31(term)
msgid "Cost"
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:140(para)
msgid "The requirement of having more than one site has a cost attached to it. The greater the number of sites, the greater the cost and complexity. Costs can be broken down into the following categories:"
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:146(para)
msgid "Compute resources"
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:149(para)
msgid "Networking resources"
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:152(para)
msgid "Replication"
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:158(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:792(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:286(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:113(para)
msgid "Management"
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:161(para)
msgid "Operational costs"
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:165(title)
msgid "Site loss and recovery"
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:166(para)
msgid "Outages can cause loss of partial or full functionality of a site. Strategies should be implemented to understand and plan for recovery scenarios."
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:171(para)
msgid "The deployed applications need to continue to function and, more importantly, consideration should be taken of the impact on the performance and reliability of the application when a site is unavailable."
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:178(para)
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 something explodes."
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:185(para)
msgid "Ensure determination of the method for resuming proper operations of a site when it comes back online after a disaster. We recommend you architect the recovery to avoid race conditions."
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:192(title)
msgid "Compliance and geo-location"
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:193(para)
msgid "An organization could have certain legal obligations and regulatory compliance measures which could require certain workloads or data to not be located in certain regions."
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:197(title)
msgid "Auditing"
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:198(para)
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 ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:206(title)
msgid "Separation of duties"
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:207(para)
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 ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:212(title)
msgid "Authentication between sites"
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:213(para)
msgid "Ideally it is best to have a single authentication domain and not need a separate implementation for each and every site. This, of course, requires an authentication mechanism that is highly available and distributed to ensure continuous operation. Authentication server locality is also something that might be needed as well and should be planned for."
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:85(None)
msgid "@@image: '../figures/Multi-Site_Customer_Edge.png'; md5=01850cf774e7075bd7202c6e7f087f36"
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:191(None)
msgid "@@image: '../figures/Multi-site_Geo_Redundant_LB.png'; md5=c94a96f6084c2e50a0eb6846f6fde479"
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:222(None)
msgid "@@image: '../figures/Multi-Site_shared_keystone1.png'; md5=eaef18e7f04eec7e3f8968ad69aed7d3"
msgstr ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:12(title) ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:8(title) ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:8(title) ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:8(title) ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:8(title)
msgid "Prescriptive examples"
msgstr ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:13(para)
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 ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:20(para)
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. In this case 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 ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:44(para)
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 ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:50(para)
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 ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:63(para)
msgid "One of the key decisions of running this sort of 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 revolves around the availability of the 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 ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:74(para)
msgid "The second redundancy topic is that of the edge data center itself. A second data center in each of the edge regional locations house a second region near the first. This ensures that the application does not suffer degraded performance in terms of latency and availability."
msgstr ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:79(para)
msgid "This figure depicts the solution designed to have both a centralized set of core data centers for OpenStack services and paired edge data centers:"
msgstr ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:89(title)
msgid "Geo-redundant load balancing"
msgstr ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:90(para)
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 2-tier architecture with a web front-end servicing the customer requests and a NoSQL database back end storing the information."
msgstr ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:96(para)
msgid "As of late there has been several outages in number of major public cloud providersusually due to the fact these applications were 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 ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:101(para) ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:30(para)
msgid "The solution would consist of the following OpenStack components:"
msgstr ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:105(para) ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:34(para)
msgid "A firewall, switches and load balancers on the public facing network connections."
msgstr ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:109(para)
msgid "OpenStack Controller services running, Networking, dashboard, Block Storage and Compute running locally in each of the three regions. The other services, Identity, Orchestration, Telemetry, Image Service and Object Storage can be installed centrallywith nodes in each of the region providing a redundant OpenStack Controller plane throughout the globe."
msgstr ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:119(para) ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:44(para)
msgid "OpenStack Compute nodes running the KVM hypervisor."
msgstr ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:123(para)
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 ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:129(para)
msgid "A Distributed DNS service available to all regionsthat allows for dynamic update of DNS records of deployed instances."
msgstr ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:134(para)
msgid "A geo-redundant load balancing service can be used to service the requests from the customers based on their origin."
msgstr ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:139(para)
msgid "An autoscaling heat template can be used to deploy the application in the three regions. This template includes:"
msgstr ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:143(para)
msgid "Web Servers, running Apache."
msgstr ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:146(para)
msgid "Appropriate <literal>user_data</literal> to populate the central DNS servers upon instance launch."
msgstr ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:150(para)
msgid "Appropriate Telemetry alarms that maintain state of the application and allow for handling of region or instance failure."
msgstr ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:155(para)
msgid "Another autoscaling Heat template can be used to deploy a distributed MongoDB shard over the three locationswith the option of storing required data on a globally available swift container. According to the usage and load on the database serveradditional shards can be provisioned according to the thresholds defined in Telemetry."
msgstr ""
#. <para>The reason that three regions were selected here was because of
#. the fear of having abnormal load on a single region in the
#. event of a failure. Two data center would have been sufficient
#. had the requirements been met.</para>
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:165(para)
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 ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:168(para)
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 due to the fact that Orchestration had the appropriate built-in hooks into the OpenStack cloudwhereas the other tools were external and not native to OpenStack. In additionsince this deployment scenario was relatively straight forwardthe external tools were not needed."
msgstr ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:177(para)
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 solutionwith its own replication mechanism. Home grown solutions could also have been used including the handling of replicationbut were not chosen, because Object Storage is already an intricate part of the infrastructureand proven solution."
msgstr ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:185(para)
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 ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:194(title)
msgid "Location-local service"
msgstr ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:195(para)
msgid "A common use for a multi-site deployment of OpenStack, is for creating a Content Delivery Network. An application that uses a location-local architecture requires low network latency and proximity to the user, in order to provide an optimal user experience, in addition to reducing the cost of bandwidth and transit, since the content resides on sites closer to the customer, instead of a centralized content store that requires utilizing higher cost cross-country links."
msgstr ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:203(para)
msgid "This architecture usually includes a geo-location component that places user requests at the closest possible node. In this scenario, 100% redundancy of content across every site is a goal rather than a requirement, with the intent being to maximize the amount of content available that is within a minimum number of network hops for any given end user. Despite these differences, the storage replication configuration has significant overlap with that of a geo-redundant load balancing use case."
msgstr ""
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:212(para)
msgid "In this example, 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 ""
#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:8(title) ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:8(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:12(title) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:90(title) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:12(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:12(title) ./doc/arch-design/massively_scalable/section_tech_considerations_massively_scalable.xml:12(title) ./doc/arch-design/storage_focus/section_tech_considerations_storage_focus.xml:8(title)
msgid "Technical considerations"
msgstr ""
#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:9(para)
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 ""
#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:16(para)
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 ""
#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:20(para)
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 <link href=\"http://docs.openstack.org/developer/swift/replication_network.html#dedicated-replication-network\">http://docs.openstack.org/developer/swift/replication_network.html#dedicated-replication-network</link>). 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 ""
#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:38(para)
msgid "The capacity requirements of the links between sites is driven by application behavior. If the latency of the links 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, tuning of the Identity service call timeouts may be necessary to prevent issues authenticating against a central Identity service."
msgstr ""
#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:47(para)
msgid "Another capacity consideration when it comes to networking for a multi-site deployment is the available amount and performance of overlay networks 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. Note that, as of the Icehouse release, OpenStack Networking was not capable of managing tunnel IDs across installations. This means that if one site runs out of IDs, but other does not, that tenant's network is unable to reach the other site."
msgstr ""
#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:58(para)
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 should be noted that cells may be necessary to grow an individual region beyond a certain point. This point depends on the size of your cluster and the ratio of virtual machines per hypervisor."
msgstr ""
#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:66(para)
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 via swift proxy, it is possible to overload the proxies. There are two options available to mitigate this issue. The first is to deploy a large number of swift proxies. The drawback to this is that the proxies are not load-balanced and a large file request could continually hit the same proxy. The other way to mitigate this is to front-end the proxies with a caching HTTP proxy and load balancer. Since swift objects are returned to the requester via HTTP, this load balancer would alleviate the load required on the swift proxies."
msgstr ""
#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:79(title) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:215(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:204(title)
msgid "Utilization"
msgstr ""
#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:80(para)
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 ""
#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:83(para)
msgid "Identity is normally the first interface for the majority of OpenStack users. Interacting with the Identity service is required for almost all major operations within OpenStack. Therefore, it is important to ensure that you provide users with a single URL for Identity service authentication. Equally important is proper documentation and 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 of the system, when reading Identity documentation, as it is required to define the region name when providing actions to an API endpoint or in the dashboard."
msgstr ""
#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:94(para)
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 local to a specific region. Some applications may be able to cope with this via internal mechanisms. Others, however, may require the implementation of an external system including global services load balancers or anycast-advertised DNS."
msgstr ""
#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:102(para)
msgid "Depending on the storage model chosen during site design, storage replication and availability are also a concern for end-users. If an application is capable of understanding 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 do the cross-site replication themselves. With a centralized swift proxy, however, 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 ""
#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:114(title) ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:432(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:387(term) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:120(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:590(title) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:96(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:177(term) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:257(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:236(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:18(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:42(term) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:12(para) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:119(term)
msgid "Performance"
msgstr ""
#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:115(para)
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, multi-site deployments incur a few extra penalties to performance in certain situations."
msgstr ""
#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:120(para)
msgid "Since multi-site systems can be geographically separated, they may have worse than normal 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 certain applications which rely on remote procedure call (RPC) for normal operation. An example of this can be seen in High Performance Computing workloads."
msgstr ""
#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:129(para)
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 ""
#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:139(title) ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:163(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:630(term) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:191(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:778(title) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:160(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:435(term) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:268(title) ./doc/arch-design/hybrid/section_architecture_hybrid.xml:132(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:98(title) ./doc/arch-design/storage_focus/section_tech_considerations_storage_focus.xml:47(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:448(term) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:136(term)
msgid "Security"
msgstr ""
#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:140(para)
msgid "Securing a multi-site OpenStack installation also 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. Installing a VPN or encrypted connection between sites is recommended in such instances."
msgstr ""
#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:148(para)
msgid "Another security consideration with regard to multi-site deployments is Identity. Authentication in a multi-site deployment should be centralized. 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 ""
#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:157(para)
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. Unfortunately, OpenStack Networking 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 ""
#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:169(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:560(para) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:667(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:505(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:366(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:472(title) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:360(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:378(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:488(title)
msgid "OpenStack components"
msgstr ""
#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:170(para)
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). 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 necessary, a centralized Object Storage service may be used and will require the installation of the swift proxy service."
msgstr ""
#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:184(para)
msgid "It may also be helpful to install a few extra options in order to facilitate certain use cases. For instance, 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 would be selected for certain applications."
msgstr ""
#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:191(para)
msgid "Another useful tool for managing a multi-site installation is Orchestration (heat). The Orchestration module 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 setup 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 ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:9(para)
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 however, in order for any traffic to go outside of that cloud, to another network, or to the Internet, a layer-3 router or switch must be involved."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:19(para)
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 that is used in the staging environment: the Internet is based entirely on layer-3 routing rather than layer-2 switching."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:29(para)
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 ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:39(para)
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 ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:45(para)
msgid "Ethernet frames can carry any kind of packet. Networking at layer 2 is independent of the layer-3 protocol."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:50(para)
msgid "More layers added to the Ethernet frame only slow the networking process down. This is known as 'nodal processing delay'."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:55(para)
msgid "Adjunct networking features, for example class of service (CoS) or multicasting, can be added to Ethernet as readily as IP networks."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:60(para)
msgid "VLANs are an easy mechanism for isolating networks."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:64(para)
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 more of the end-to-end transfer of information from a source to a destination can be done in the form of Ethernet frames, more of the benefits of Ethernet can be realized on the network. Though it is not a substitute for IP networking, networking at layer 2 can be a powerful adjunct to IP networking."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:73(para)
msgid "Layer-2 Ethernet usage has these advantages over layer-3 IP network usage:"
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:79(para)
msgid "Speed"
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:84(para)
msgid "Reduced overhead of the IP hierarchy."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:89(para)
msgid "No need to keep track of address configuration as systems are moved 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 ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:102(para)
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 ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:116(title)
msgid "Layer-2 architecture limitations"
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:117(para)
msgid "Outside of the traditional data center the limitations of layer-2 network architectures become more obvious."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:121(para)
msgid "Number of VLANs is limited to 4096."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:124(para)
msgid "The number of MACs stored in switch tables is limited."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:128(para)
msgid "The need to maintain a set of layer-4 devices to handle traffic control must be accommodated."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:132(para)
msgid "MLAG, often used for switch redundancy, is a proprietary solution that does not scale beyond two devices and forces vendor lock-in."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:137(para)
msgid "It can be difficult to troubleshoot a network without IP addresses and ICMP."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:141(para)
msgid "Configuring <glossterm baseform=\"Address Resolution Protocol (ARP)\">ARP</glossterm> is considered complicated on large layer-2 networks."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:147(para)
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 are started or stopped."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:153(para)
msgid "Migrating MACs (instance migration) to different physical locations are a potential problem if ARP table timeouts are not set properly."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:158(para)
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 ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:165(para)
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 ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:174(para)
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 is started or stopped. As a result there is far too much churn in the MAC tables on the backbone switches."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:180(title)
msgid "Layer-3 architecture advantages"
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:181(para)
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 would be 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 ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:189(para)
msgid "Layer-3 networks provide the same level of resiliency and scalability as the Internet."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:193(para)
msgid "Controlling traffic with routing metrics is straightforward."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:197(para)
msgid "Layer 3 can be configured to use <glossterm baseform=\"Border Gateway Protocol (BGP)\">BGP</glossterm> confederation for scalability so core routers have state proportional to the number of racks, not to the number of servers or instances."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:204(para)
msgid "Routing ensures that 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 ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:210(para)
msgid "There are a variety of well tested tools, for example ICMP, to monitor and manage traffic."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:214(para)
msgid "Layer-3 architectures allow for the use of Quality of Service (QoS) to manage network performance."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:219(title)
msgid "Layer-3 architecture limitations"
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:220(para)
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 will also be on the same subnet as its physical host. This means that it cannot be migrated outside of the subnet easily. For these reasons, network virtualization needs to use IP <glossterm>encapsulation</glossterm> and software at the end hosts for both isolation, as well as for separation of the addressing in the virtual layer from 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 automatically keep track of the MAC addresses and to configure the interior gateway routing protocol in the switches."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:238(title)
msgid "Network recommendations overview"
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:239(para)
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 those used by instances which need to be isolated from the core network to account for scalability. It is also recommended to functionally separate the networks for security purposes and tune performance through traffic shaping."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:250(para)
msgid "A number of important general technical and business factors need to be taken into consideration when planning and designing an OpenStack network. They include:"
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:255(para)
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 ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:261(para)
msgid "A requirement to massively scale the ecosystem to support millions of end users."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:265(para)
msgid "A requirement to support indeterminate platforms and applications."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:269(para)
msgid "A requirement to design for cost efficient operations to take advantage of massive scale."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:273(para)
msgid "A requirement to ensure that there is no single point of failure in the cloud ecosystem."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:277(para)
msgid "A requirement for high availability architecture to meet customer SLA requirements."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:281(para)
msgid "A requirement to be tolerant of rack level failure."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:285(para)
msgid "A requirement to maximize flexibility to architect future production environments."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:289(para)
msgid "Keeping all of these in mind, the following network design recommendations can be made:"
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:293(para)
msgid "Layer-3 designs are preferred over layer-2 architectures."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:297(para)
msgid "Design a dense multi-path network core to support multi-directional scaling and flexibility."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:301(para)
msgid "Use hierarchical addressing because it is the only viable option to scale network ecosystem."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:305(para)
msgid "Use virtual networking to isolate instance service network traffic from the management and internal network traffic."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:310(para)
msgid "Isolate virtual networks using encapsulation technologies."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:314(para)
msgid "Use traffic shaping for performance tuning."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:317(para)
msgid "Use eBGP to connect to the Internet up-link."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:320(para)
msgid "Use iBGP to flatten the internal traffic on the layer-3 mesh."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:324(para)
msgid "Determine the most effective configuration for block storage network."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:329(title)
msgid "Additional considerations"
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:330(para)
msgid "There are numerous topics to consider when designing a network-focused OpenStack cloud."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:333(title)
msgid "OpenStack Networking versus legacy networking (nova-network) considerations"
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:335(para)
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 as described in the following table."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:344(th) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:176(term)
msgid "Legacy networking (nova-network)"
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:345(th)
msgid "OpenStack Networking"
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:349(td)
msgid "Simple, single agent"
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:350(td)
msgid "Complex, multiple agents"
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:353(td)
msgid "More mature, established"
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:354(td)
msgid "Newer, maturing"
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:357(td)
msgid "Flat or VLAN"
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:358(td)
msgid "Flat, VLAN, Overlays, L2-L3, SDN"
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:360(td)
msgid "No plug-in support"
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:361(td)
msgid "Plug-in support for 3rd parties"
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:364(td)
msgid "Scales well"
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:365(td)
msgid "Scaling requires 3rd party plug-ins"
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:368(td)
msgid "No multi-tier topologies"
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:369(td)
msgid "Multi-tier topologies"
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:375(title)
msgid "Redundant networking: ToR switch high availability risk analysis"
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:377(para)
msgid "A technical consideration of networking is the idea that switching gear in the data center that should be installed with backup switches in case of hardware failure."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:380(para)
msgid "Research into 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. This is based on published research found at <link href=\"http://www.garrettcom.com/techsupport/papers/ethernet_switch_reliability.pdf\">http://www.garrettcom.com/techsupport/papers/ethernet_switch_reliability.pdf</link> and <link href=\"http://www.n-tron.com/pdf/network_availability.pdf\">http://www.n-tron.com/pdf/network_availability.pdf</link>."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:393(para)
msgid "In most cases, it is much more economical to only 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 also be able to tolerate rack level outages without affecting normal operations since network and compute resources are easily provisioned and plentiful."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:401(title)
msgid "Preparing for the future: IPv6 support"
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:402(para)
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 (<link href=\"http://www.internetsociety.org/deploy360/blog/2014/05/goodbye-ipv4-iana-starts-allocating-final-address-blocks/\">http://www.internetsociety.org/deploy360/blog/2014/05/goodbye-ipv4-iana-starts-allocating-final-address-blocks/</link>). 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 is expected to scale out, due to the lack of unallocated IPv4 address blocks."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:413(para)
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 ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:418(para)
msgid "OpenStack Networking supports IPv6 when configured to take advantage of the feature. To enable it, simply create an IPv6 subnet in Networking and use IPv6 prefixes when creating security groups."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:423(title)
msgid "Asymmetric links"
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:424(para)
msgid "When designing a network architecture, the traffic patterns of an application will heavily influence the allocation of total bandwidth and the number of links that are used to send and receive traffic. Applications that provide file storage for customers will allocate bandwidth and links to favor incoming traffic, whereas video streaming applications will allocate bandwidth and links to favor outgoing traffic."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:433(para)
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 are queued for transmit immediately or guaranteed minimum bandwidth. Since OpenStack currently does not support these functions, some considerations may need to be made for the network plug-in selected."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:443(para)
msgid "The location of a service may also impact the application or consumer experience. If an application is designed to serve differing content to differing users it will need to be designed to properly direct connections to those specific locations. Use a multi-site installation for these situations, where appropriate."
msgstr ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:449(para)
msgid "Networking can be implemented in two separate ways. The 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 layer-3 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 ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:460(para)
msgid "Networking at large scales becomes a set of boundary questions. The determination of how large a layer-2 domain needs to 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 ""
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:468(para)
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 ""
#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:9(para)
msgid "Network focused architectures vary from the general purpose designs. They are heavily influenced by a specific subset of applications that interact with the network in a more impacting way. Some of the business requirements that will influence the design include:"
msgstr ""
#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:16(para)
msgid "User experience: User experience is impacted by network latency through slow page loads, degraded video streams, and low quality VoIP sessions. 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 provide a negative experience for the end-user, as well as productivity and economic loss."
msgstr ""
#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:28(para)
msgid "Regulatory requirements: Networks need to take into consideration any regulatory requirements about the physical location of data as it traverses the network. For example, Canadian medical records cannot pass outside of Canadian sovereign territory. Another network consideration is maintaining network segregation of private data flows and ensuring that the network between cloud locations is encrypted where required. Network architectures are affected by regulatory requirements for encryption and protection of data in flight as the data moves through various networks."
msgstr ""
#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:61(para)
msgid "Data compliance policies governing where information needs to reside in certain locations due to regular issues and, more importantly, where it cannot reside in other locations for the same reason."
msgstr ""
#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:67(para)
msgid "Examples of such legal frameworks include the data protection framework of the European Union (<link href=\"http://ec.europa.eu/justice/data-protection/\">http://ec.europa.eu/justice/data-protection/</link>) and the requirements of the Financial Industry Regulatory Authority (<link href=\"http://www.finra.org/Industry/Regulation/FINRARules\">http://www.finra.org/Industry/Regulation/FINRARules</link>) in the United States. Consult a local regulatory body for more information."
msgstr ""
#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:76(title)
msgid "High availability issues"
msgstr ""
#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:77(para)
msgid "OpenStack installations with high demand on network resources have high availability requirements that are determined by the application and use case. Financial transaction systems will have a much higher requirement for high availability than a development application. Forms of network availability, for example quality of service (QoS), can be used to improve the network performance of sensitive applications, for example VoIP and video streaming."
msgstr ""
#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:85(para)
msgid "Often, high performance systems will 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 ""
#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:91(title)
msgid "Risks"
msgstr ""
#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:94(term)
msgid "Network misconfigurations"
msgstr ""
#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:96(para)
msgid "Configuring incorrect IP addresses, VLANs, and routes can cause outages to areas of the network or, in the worst-case scenario, the entire cloud infrastructure. Misconfigurations can cause disruptive problems and should be automated to minimize the opportunity for operator error."
msgstr ""
#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:105(term) ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:107(title) ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:89(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:66(title)
msgid "Capacity planning"
msgstr ""
#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:107(para)
msgid "Cloud networks need to be managed for capacity and growth over time. There is a risk that the network will not grow to support the workload. Capacity planning includes the purchase of network circuits and hardware that can potentially have lead times measured in months or more."
msgstr ""
#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:116(term)
msgid "Network tuning"
msgstr ""
#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:118(para)
msgid "Cloud networks need to be configured to minimize link loss, packet loss, packet storms, broadcast storms, and loops."
msgstr ""
#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:124(term)
msgid "Single Point Of Failure (SPOF)"
msgstr ""
#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:126(para)
msgid "High availability must be taken into account even 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 becomes unavoidable."
msgstr ""
#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:134(term)
msgid "Complexity"
msgstr ""
#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:136(para)
msgid "An overly complex network design becomes difficult to maintain and troubleshoot. While automated tools that handle overlay networks or device level configuration can mitigate this, non-traditional interconnects between functions and specialized hardware need to be well documented or avoided to prevent outages."
msgstr ""
#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:146(term)
msgid "Non-standard features"
msgstr ""
#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:148(para)
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) that is being 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 ""
#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:164(para)
msgid "Security is often overlooked or added after a design has been implemented. Consider security implications and requirements before designing the physical and logical network topologies. Some of the factors that need to be addressed include making sure the networks are properly segregated and traffic flows are going to the correct destinations without crossing through locations that are undesirable. Some examples of factors that need to be taken into consideration are:"
msgstr ""
#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:177(para)
msgid "Overlay interconnects for joining separated tenant networks"
msgstr ""
#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:181(para)
msgid "Routing through or avoiding specific networks"
msgstr ""
#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:184(para)
msgid "Another security vulnerability that must be taken into account is how networks are attached to hypervisors. If a network must be separated from other systems at all costs, it may be necessary to schedule instances for that network onto dedicated compute nodes. This may also be done to mitigate against exploiting a hypervisor breakout allowing the attacker access to networks from a compromised instance."
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:42(None)
msgid "@@image: '../figures/Network_Web_Services1.png'; md5=7ad46189444753336edd957108a1a92b"
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:201(None)
msgid "@@image: '../figures/Network_Cloud_Storage2.png'; md5=3cd3ce6b19b20ecd7d22af03731cc7cd"
msgstr ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:9(para)
msgid "A large-scale web application has been designed with cloud principles in mind. The application is designed to scale horizontally in a bursting fashion and will generate a high instance count. The application requires an SSL connection to secure data and must not lose connection state to individual servers."
msgstr ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:15(para)
msgid "An example design for this workload is depicted in the figure below. In this example, a hardware load balancer is configured to provide SSL offload functionality and to connect to tenant networks in order to reduce address consumption. This load balancer is linked to the routing architecture as it will service the VIP for the application. The router and load balancer are configured with GRE tunnel ID of the application's tenant network and provided 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 ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:27(para)
msgid "Because sessions persist until they are closed, the routing and switching architecture is designed for high availability. Switches are meshed to each hypervisor and each other, and also provide an MLAG implementation to ensure that layer-2 connectivity does not fail. Routers are configured with VRRP and fully meshed with switches to ensure layer-3 connectivity. Since GRE is used as an overlay network, Networking is installed and configured to use the Open vSwitch agent in GRE tunnel mode. This ensures all devices can reach all other devices and that tenant networks can be created for private addressing links to the load balancer. <placeholder-1/>"
msgstr ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:45(para)
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 however a few key components will need to be in place to handle the nature of most web-scale workloads. The user needs the following components:"
msgstr ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:52(para)
msgid "OpenStack Controller services (Image, Identity, Networking and supporting services such as MariaDB and RabbitMQ)"
msgstr ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:57(para)
msgid "OpenStack Compute running KVM hypervisor"
msgstr ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:60(para)
msgid "OpenStack Object Storage"
msgstr ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:63(para)
msgid "Orchestration module"
msgstr ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:66(para)
msgid "Telemetry module"
msgstr ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:69(para)
msgid "Beyond the normal Identity, Compute, Image Service and Object Storage components, the Orchestration module is a recommended component to handle properly scaling the workloads to adjust to demand. Due to the requirement for auto-scaling, the design includes the Telemetry module. 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 will work 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 ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:84(title)
msgid "Load balancing"
msgstr ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:85(para)
msgid "Load balancing was included in this design to spread requests across multiple instances. This workload scales well horizontally across large numbers of instances. This allows instances to run without publicly routed IP addresses and simply rely on the load balancer for the service to be globally reachable. 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 ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:96(title)
msgid "Overlay networks"
msgstr ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:97(para)
msgid "The overlay functionality design includes OpenStack Networking in Open vSwitch GRE tunnel mode. In this case, the layer-3 external routers are paired with VRRP and switches should be paired with an implementation of MLAG running to ensure that you do not lose connectivity with the upstream routing infrastructure."
msgstr ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:107(title)
msgid "Performance tuning"
msgstr ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:108(para)
msgid "Network level tuning for this workload is minimal. Quality-of-Service (QoS) will be applied to these workloads for a middle ground Class Selector depending on existing policies. It will be 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, bandwidth utilization can be optimized 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 ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:120(title)
msgid "Network functions"
msgstr ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:121(para)
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 ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:134(para)
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. A multi-site approach is used 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 are therefore not recommended."
msgstr ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:145(para)
msgid "QoS is desired 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. It is to 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 ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:152(title)
msgid "Cloud storage"
msgstr ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:153(para)
msgid "Another common use case for OpenStack environments is to provide 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 ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:158(para)
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 <glossterm baseform=\"north-south traffic\">north-south</glossterm> and <glossterm>east-west traffic</glossterm> considerations, as follows:"
msgstr ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:169(term)
msgid "north-south traffic"
msgstr ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:171(para)
msgid "When a user uploads and stores content, that content moves into the OpenStack installation. When users download this content, the content moves from the OpenStack installation. Because this service is intended 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 ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:185(term)
msgid "east-west traffic"
msgstr ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:187(para)
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 ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:204(para)
msgid "This application prioritizes the north-south traffic over east-west traffic: the north-south traffic involves customer-facing data."
msgstr ""
#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:209(para)
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 forego 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 ""
#: ./doc/arch-design/network_focus/section_architecture_network_focus.xml:8(para)
msgid "Network focused OpenStack architectures have many similarities to other OpenStack architecture use cases. There are a number of very specific considerations to keep in mind when designing for a network-centric or network-heavy application environment."
msgstr ""
#: ./doc/arch-design/network_focus/section_architecture_network_focus.xml:13(para)
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, if the workload is a content delivery network, then the interactions with storage will be two-fold. There will be traffic flowing 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 ""
#: ./doc/arch-design/network_focus/section_architecture_network_focus.xml:25(para)
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, will 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 rescind transaction locks at very high rates. This also has an impact on the network performance."
msgstr ""
#: ./doc/arch-design/network_focus/section_architecture_network_focus.xml:33(para)
msgid "Some network dependencies are going to be 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, external systems or equipment may be required 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. Note that, as of the Icehouse release, dynamic routing is currently in its infancy within OpenStack and may need to be implemented either by an external device or a specialized service instance within OpenStack. Tunneling is a feature provided by OpenStack Networking, 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, it is necessary to implement the tunnel itself outside OpenStack or by using a tunnel management system to map the tunnel or overlay to an external tunnel. OpenStack does not currently provide quotas for network resources. Where network quotas are required, it is necessary to implement quality of service management outside of OpenStack. In many of these instances, similar solutions for traffic shaping or other network functions will be needed."
msgstr ""
#: ./doc/arch-design/network_focus/section_architecture_network_focus.xml:57(para)
msgid "Depending on the selected design, Networking itself might not even support the required <glossterm baseform=\"Layer-3 network\">layer-3 network</glossterm> 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 ""
#: ./doc/arch-design/network_focus/section_architecture_network_focus.xml:66(para)
msgid "Interaction with orchestration services is inevitable in larger-scale deployments. The Orchestration module 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 in using orchestration, we recommend that the design include the Orchestration module to meet the demands of users."
msgstr ""
#: ./doc/arch-design/network_focus/section_architecture_network_focus.xml:75(title)
msgid "Design impacts"
msgstr ""
#: ./doc/arch-design/network_focus/section_architecture_network_focus.xml:76(para)
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 will influence network design decisions."
msgstr ""
#: ./doc/arch-design/network_focus/section_architecture_network_focus.xml:81(para)
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 to be available instead of using public fixed addresses then NAT is required. This can be seen in network management applications that rely on an IP endpoint. An example of this is a DHCP relay that needs to know the IP of the actual DHCP server. In these cases it is easier to automate the infrastructure to apply the target IP to a new instance rather than reconfigure legacy or external systems for each new instance."
msgstr ""
#: ./doc/arch-design/network_focus/section_architecture_network_focus.xml:91(para)
msgid "NAT for floating IPs managed by Networking will reside 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, load balancing software, such as HAproxy, can be managed with Networking's Load-Balancer-as-a-Service (LBaaS). 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 would need to serve the VIP and also be joined to the tenant overlay network through external means or routed to it via private addresses."
msgstr ""
#: ./doc/arch-design/network_focus/section_architecture_network_focus.xml:107(para)
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 ""
#: ./doc/arch-design/network_focus/section_architecture_network_focus.xml:114(para)
msgid "Application workloads will affect the design of the underlying network architecture. If a workload requires network-level redundancy, the routing and switching architecture will have to accommodate this. There are differing methods for providing this that are dependent on the network hardware selected, the performance of the hardware, and which networking model is deployed. Some examples of this are the use of Link aggregation (LAG) or Hot Standby Router Protocol (HSRP). There are also the considerations of whether to deploy OpenStack Networking or legacy networking (nova-network) and which plug-in to select for OpenStack Networking. If using an external system, Networking will need to be configured to run <glossterm baseform=\"Layer-2 network\">layer 2</glossterm> with a provider network configuration. For example, it may be necessary to implement HSRP to terminate layer-3 connectivity."
msgstr ""
#: ./doc/arch-design/network_focus/section_architecture_network_focus.xml:131(para)
msgid "Depending on the workload, overlay networks may or may not be a recommended configuration. 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, will be the hypervisor. This will cause performance degradation on packet per second and connection per second rates."
msgstr ""
#: ./doc/arch-design/network_focus/section_architecture_network_focus.xml:140(para)
msgid "Overlays also come with a secondary option that may or may not be appropriate to a specific workload. While all of them will 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 will operate without issue. For example, most web services applications will not have major issues with a full mesh overlay network, while some network monitoring tools or storage replication workloads will have performance issues with throughput or excessive broadcast traffic."
msgstr ""
#: ./doc/arch-design/network_focus/section_architecture_network_focus.xml:150(para)
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. Note that, as of the Icehouse release, this only includes stateless address auto configuration but work is in progress to support stateless and stateful DHCPv6 as well as IPv6 floating IPs without NAT. Some workloads become possible through the use of IPv6 and IPv6 to IPv4 reverse transition mechanisms such as NAT64 and DNS64 or <glossterm>6to4</glossterm>, because these options are available. This will alter the requirements for any address plan as single-stacked and transitional IPv6 deployments can alleviate the need for IPv4 addresses."
msgstr ""
#: ./doc/arch-design/network_focus/section_architecture_network_focus.xml:164(para)
msgid "As of the Icehouse release, 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 will perform well with nothing more than static routes and default gateways configured at the layer-3 termination point. In most cases this will suffice, 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 ""
#: ./doc/arch-design/network_focus/section_architecture_network_focus.xml:186(para)
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. When you add externally built tunnels, the MTU packet size is reduced. In this case, you must pay attention to the fully calculated MTU size because some systems are configured to ignore or drop path MTU discovery packets."
msgstr ""
#: ./doc/arch-design/network_focus/section_architecture_network_focus.xml:197(title)
msgid "Tunable networking components"
msgstr ""
#: ./doc/arch-design/network_focus/section_architecture_network_focus.xml:198(para)
msgid "Consider configurable networking components related to an OpenStack architecture design when designing for network intensive workloads include MTU and QoS. Some workloads will require a larger MTU than normal based on a requirement to transfer large blocks of data. When providing network service for applications such as video streaming or storage replication, it is recommended to ensure that both OpenStack hardware nodes and the supporting network equipment are configured for jumbo frames where possible. This will allow for a better utilization of available bandwidth. Configuration of jumbo frames should be done across the complete path the packets will traverse. If one network component is not capable of handling jumbo frames then the entire path will revert to the default MTU."
msgstr ""
#: ./doc/arch-design/network_focus/section_architecture_network_focus.xml:210(para)
msgid "Quality of Service (QoS) also has a great impact on network intensive workloads by providing instant service to packets which have a higher priority due to their ability to be impacted by poor network performance. In applications such as Voice over IP (VoIP) differentiated services code points are a near requirement for proper operation. QoS can also be used 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 ""
#: ./doc/arch-design/network_focus/section_operational_considerations_network_focus.xml:9(para)
msgid "Network focused OpenStack clouds have a number of operational considerations that will influence the selected design. Topics including, but not limited to, dynamic routing of static routes, service level agreements, and ownership of user management all need to be considered."
msgstr ""
#: ./doc/arch-design/network_focus/section_operational_considerations_network_focus.xml:14(para)
msgid "One of the first required decisions is the selection of a telecom company or transit provider. This is especially true if the network requirements include external or site-to-site network connectivity."
msgstr ""
#: ./doc/arch-design/network_focus/section_operational_considerations_network_focus.xml:18(para)
msgid "Additional design decisions need to be made about monitoring and alarming. These can be an internal responsibility or the responsibility of the external provider. In the case of using an external provider, SLAs will likely apply. In addition, other operational considerations such as bandwidth, latency, and jitter can be part of a service level agreement."
msgstr ""
#: ./doc/arch-design/network_focus/section_operational_considerations_network_focus.xml:24(para)
msgid "The ability to upgrade the infrastructure is another subject for consideration. As demand for network resources increase, operators will be required to add additional IP address blocks and add additional bandwidth capacity. Managing hardware and software life cycle events, for example upgrades, decommissioning, and outages while avoiding service interruptions for tenants, will also need to be considered."
msgstr ""
#: ./doc/arch-design/network_focus/section_operational_considerations_network_focus.xml:32(para)
msgid "Maintainability will also need to be factored 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 all of the IP addresses have to be changed on a network, a process known as renumbering, then the design needs to support the ability to do so."
msgstr ""
#: ./doc/arch-design/network_focus/section_operational_considerations_network_focus.xml:39(para)
msgid "Network focused applications themselves need to be addressed when concerning certain operational realities. For example, the impending exhaustion of IPv4 addresses, the migration to IPv6 and the utilization 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. It is further recommended to avoid relying on IPv4 features that were not carried over to the IPv6 protocol or have differences in implementation."
msgstr ""
#: ./doc/arch-design/network_focus/section_operational_considerations_network_focus.xml:49(para)
msgid "When using private networks to segregate traffic, applications should create private tenant networks for database and data storage network traffic, and utilize public networks for client-facing traffic. By segregating this traffic, quality of service and security decisions can be made to ensure that each network has the correct level of service that it requires."
msgstr ""
#: ./doc/arch-design/network_focus/section_operational_considerations_network_focus.xml:56(para)
msgid "Finally, decisions must be made about the routing of network traffic. For some applications, a more complex policy framework for routing must be developed. The economic cost of transmitting traffic over expensive links versus cheaper links, in addition to bandwidth, latency, and jitter requirements, can be used to create a routing policy that will satisfy business requirements."
msgstr ""
#: ./doc/arch-design/network_focus/section_operational_considerations_network_focus.xml:63(para)
msgid "How to respond to network events must also be taken into consideration. As an example, how load is transferred from one link to another during a failure scenario could be a factor in the design. If network capacity is not planned 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 the all network traffic stops."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:13(para)
msgid "Hardware selection involves three key areas:"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:16(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:17(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:41(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:12(para)
msgid "Compute"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:19(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:22(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:46(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:15(para)
msgid "Network"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:25(para)
msgid "Selecting hardware for a general purpose OpenStack cloud should reflect a cloud with no pre-defined usage model. General purpose clouds are designed to run a wide variety of applications with varying resource usage requirements. These applications include any of the following:"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:32(para)
msgid "RAM-intensive"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:37(para)
msgid "CPU-intensive"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:42(para)
msgid "Storage-intensive"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:47(para)
msgid "Choosing hardware for a general purpose OpenStack cloud must provide balanced access to all major resources."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:49(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:55(para)
msgid "Equal (or nearly equal) balance of compute capacity (RAM and CPU)"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:60(para)
msgid "Network capacity (number and speed of links)"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:65(para)
msgid "Storage capacity (gigabytes or terabytes as well as Input/Output Operations Per Second (<glossterm>IOPS</glossterm>)"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:71(para)
msgid "Server hardware is evaluated around four conflicting dimensions."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:75(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:35(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:140(term)
msgid "Server density"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:77(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:142(para)
msgid "A measure of how many servers can fit into a given measure of physical space, such as a rack unit [U]."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:83(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:42(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:148(term)
msgid "Resource capacity"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:85(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:44(para)
msgid "The number of CPU cores, how much RAM, or how much storage a given server will deliver."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:91(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:285(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:49(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:201(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:61(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:155(term)
msgid "Expandability"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:93(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:51(para)
msgid "The number of additional resources that can be added to a server before it has reached its limit."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:101(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:58(para)
msgid "The relative purchase price of the hardware weighted against the level of design effort needed to build the system."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:107(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:117(para)
msgid "Blade servers typically support dual-socket multi-core CPUs, which is the configuration generally considered to be the \"sweet spot\" for a general purpose cloud deployment. Blades also offer outstanding density. As an example, both HP BladeSystem and Dell PowerEdge M1000e support up to 16 servers in only 10 rack units. However, the blade servers themselves often have limited storage and networking capacity. Additionally, the expandability of many blade servers can be limited."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:129(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:137(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:144(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:153(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:162(para)
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 will apply 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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:172(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:124(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:254(term)
msgid "Instance density"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:174(para)
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 metric used in sizing the deployment. The selected server hardware needs to support the expected or anticipated instance density."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:184(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:134(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:264(term)
msgid "Host density"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:186(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:199(term)
msgid "Power density"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:201(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:211(term)
msgid "Network connectivity"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:213(para)
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. For architectures requiring even more redundancy, it might be necessary to confirm that the network connections are from diverse telecom providers. Many data centers have that capacity available."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:227(para)
msgid "The selection of form factors or architectures affects the selection of server hardware. For example, if the design is a scale-out storage architecture, then the server hardware selection will require careful consideration when matching the requirements set to the commercial solution."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:231(para)
msgid "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. For example, if a centralized storage solution is required, such as a centralized storage array from a storage vendor that has InfiniBand or FDDI connections, the server hardware will need to have appropriate network adapters installed to be compatible with the storage array vendor's specifications."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:240(para)
msgid "Similarly, the network architecture will have an impact on the server hardware selection and vice versa. For example, make sure that the server is configured with enough additional network ports and expansion cards to support all of the networks required. There is variability in network expansion cards, so it is important to be aware of potential impacts or interoperability issues with other components in the architecture."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:249(title)
msgid "Selecting storage hardware"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:250(para)
msgid "Storage hardware architecture is largely determined by the selected storage architecture. The selection of storage architecture, as well as the corresponding storage hardware, is determined by evaluating possible solutions against the critical factors, the user requirements, technical considerations, and operational considerations. Factors that need to be incorporated into the storage architecture include:"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:261(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:273(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:521(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:189(term) ./doc/arch-design/hybrid/section_architecture_hybrid.xml:137(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:49(term)
msgid "Scalability"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:275(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:287(para)
msgid "Expandability is a major architecture factor for storage solutions with general purpose OpenStack cloud. A storage solution that expands to 50PB is considered more expandable than a solution that only scales to 10PB. This metric is related to, but different, from scalability, which is a measure of the solution's performance as it expands. For example, the storage architecture for a cloud that is intended for a development platform may not have the same expandability and scalability requirements as a cloud that is intended for a commercial product."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:301(para)
msgid "Using a scale-out storage solution with direct-attached storage (DAS) in the servers is well suited for a general purpose OpenStack cloud. For example, it is possible to populate storage in either the compute hosts similar to a grid computing solution, or into hosts dedicated to providing block storage exclusively. When deploying storage in the compute hosts appropriate hardware, that can support both the storage and compute services on the same hardware, will be required."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:309(para)
msgid "Understanding the requirements of cloud services will help determine what scale-out solution should be used. Determining if a single, highly expandable and highly vertical, scalable, centralized storage array should be included in the design. Once an approach has been determined, the storage hardware needs to be selected based on this criteria."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:315(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:321(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:508(term) ./doc/arch-design/introduction/section_methodology.xml:182(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:237(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:96(term)
msgid "Connectivity"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:323(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:332(term)
msgid "Usage"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:334(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:343(term)
msgid "Instance and image locations"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:345(para)
msgid "Where instances and images will be stored will influence the architecture."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:351(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:124(term)
msgid "Server hardware"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:353(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:362(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:368(term)
msgid "Capacity"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:370(para)
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 destroyed storage devices."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:389(para)
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. If compute pools are expected to have a high utilization of ephemeral storage, or requires very high performance, it would be advantageous to deploy similar hardware solutions to block storage."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:404(term)
msgid "Fault tolerance"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:406(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:424(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:281(title)
msgid "Selecting networking hardware"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:425(para)
msgid "Selecting network architecture determines which network hardware will be used. Networking software is determined by the selected networking hardware. For example, selecting networking hardware that only supports Gigabit Ethernet (GbE) will impact the overall design. Similarly, deciding to use 10 Gigabit Ethernet (10GbE) will have a number of impacts on various areas of the overall design."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:432(para)
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. An example of this type of software is Cumulus Linux, which is capable of running on a number of switch vendor's hardware solutions."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:442(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:282(para)
msgid "Some of the key considerations that should be included in the selection of networking hardware include:"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:446(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:286(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:300(term)
msgid "Port count"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:448(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:288(para)
msgid "The design will require networking hardware that has the requisite port count."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:453(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:293(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:307(term)
msgid "Port density"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:455(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:468(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:308(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:323(term)
msgid "Port speed"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:470(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:325(para)
msgid "The networking hardware must support the proposed network speed, for example: 1GbE, 10GbE, or 40GbE (or even 100GbE)."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:477(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:316(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:331(term)
msgid "Redundancy"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:479(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:488(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:328(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:346(term)
msgid "Power requirements"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:490(para)
msgid "Ensure that the physical data center provides the necessary power for the selected network hardware."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:494(para)
msgid "This may be an issue for spine switches in a leaf and spine fabric, or end of row (EoR) switches."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:501(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:510(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:523(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:531(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:696(title) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:127(term)
msgid "Availability"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:533(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:552(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:343(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:358(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:370(title)
msgid "Software selection"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:553(para)
msgid "Software selection for a general purpose OpenStack architecture design needs to include these three areas:"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:557(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:363(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:375(para)
msgid "Operating system (OS) and hypervisor"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:563(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:549(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:369(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:524(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:381(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:540(title)
msgid "Supplemental software"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:568(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:376(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:389(title)
msgid "Operating system and hypervisor"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:569(para)
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. For example, if the design uses Link Aggregation Control Protocol (LACP), the OS and hypervisor both need to support it."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:579(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:387(para)
msgid "Some areas that could be impacted by the selection of OS and hypervisor include:"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:585(para)
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 <glossterm baseform=\"kernel-based VM (KVM)\">KVM</glossterm>, Kinstance or <glossterm>Xen</glossterm>. 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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:597(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:404(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:414(term)
msgid "Supportability"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:599(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:608(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:414(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:426(term)
msgid "Management tools"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:610(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:416(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:620(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:425(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:437(term)
msgid "Scale and performance"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:622(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:632(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:642(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:446(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:460(term)
msgid "Supported features"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:644(para)
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 OSs or hypervisors. For example, if certain features are not available, the design might need to be modified to meet the user requirements."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:653(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:431(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:457(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:472(term)
msgid "Interoperability"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:655(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:668(para)
msgid "Selecting which OpenStack components are included in the overall design can have a significant impact. Some OpenStack components, like compute and Image Service, are required in every architecture. Other components, like Orchestration, are not always required."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:672(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:680(title)
msgid "Supplemental components"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:681(para)
msgid "While OpenStack is a fairly complete collection of software projects for building a platform for cloud services, there are invariably additional pieces of software that need to be considered in any given OpenStack design."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:688(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:530(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:547(title)
msgid "Networking software"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:689(para)
msgid "OpenStack Networking 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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:695(para)
msgid "Software to provide load balancing"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:700(para)
msgid "Network redundancy protocols"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:705(para)
msgid "Routing daemons"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:710(para)
msgid "Some of these software packages are described in more detail in the <citetitle>OpenStack High Availability Guide</citetitle> (refer to the <link href=\"http://docs.openstack.org/high-availability-guide/content/ch-network.html\">Network controller cluster stack chapter</link> of the OpenStack High Availability Guide)."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:716(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:723(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:546(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:561(title)
msgid "Management software"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:724(para)
msgid "Selected supplemental software solution impacts and affects the overall OpenStack cloud design. This includes software for providing clustering, logging, monitoring and alerting."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:728(para)
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 <link href=\"http://docs.openstack.org/high-availability-guide/\"><citetitle>OpenStack High Availability Guide</citetitle></link> provides more details on the installation and configuration of Corosync and Pacemaker, should these packages need to be included in the design."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:739(para)
msgid "Requirements for logging, monitoring, and alerting are determined by operational considerations. Each of these sub-categories includes a number of various options. For example, in the logging sub-category one might consider Logstash, Splunk, instanceware Log Insight, or some other log aggregation-consolidation tool. Logs should be stored in a centralized location to make it easier to perform 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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:749(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:755(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:573(para)
msgid "OS-hypervisor combination: Ensure that the selected logging, monitoring, or alerting tools support the proposed OS-hypervisor combination."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:760(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:578(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:621(para)
msgid "Network hardware: The network hardware selection needs to be supported by the logging, monitoring, and alerting software."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:767(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:584(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:629(title)
msgid "Database software"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:768(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:782(title)
msgid "Addressing performance-sensitive workloads"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:783(para)
msgid "Although one of the key defining factors for a general purpose OpenStack cloud is that performance is not a determining factor, there may still be some performance-sensitive workloads deployed on the general purpose OpenStack cloud. For design guidance on performance-sensitive workloads, we recommend that you refer to the focused scenarios later in this guide. The resource-focused guides can be used as a supplement to this guide to help with decisions regarding performance-sensitive workloads."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:795(title)
msgid "Compute-focused workloads"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:796(para)
msgid "In an OpenStack cloud that is compute-focused, there are some design choices that can help accommodate those workloads. Compute-focused workloads demand more CPU and memory resources with lower priority given to storage and network performance. For guidance on designing for this type of cloud, please refer to <xref linkend=\"compute_focus\"/>."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:804(title)
msgid "Network-focused workloads"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:805(para)
msgid "In a network-focused OpenStack cloud, some design choices can improve the performance of these types of workloads. Network-focused workloads have extreme demands on network bandwidth and services that require specialized consideration and planning. For guidance on designing for this type of cloud, please refer to <xref linkend=\"network_focus\"/>."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:813(title)
msgid "Storage-focused workloads"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:814(para)
msgid "Storage focused OpenStack clouds need to be designed to accommodate workloads that have extreme demands on either object or block storage services. For guidance on designing for this type of cloud, please refer to <xref linkend=\"storage_focus\"/>."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:9(para)
msgid "When building a general purpose cloud, you should follow the <glossterm baseform=\"IaaS\">Infrastructure-as-a-Service (IaaS)</glossterm> 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 ""
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:17(para)
msgid "The following user considerations are written from the perspective of the cloud builder, not from the perspective of the end user."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:26(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:39(term) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:31(term) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:46(term)
msgid "Time to market"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:41(para)
msgid "The ability to deliver services or products within a flexible time frame is a common business factor when building a general purpose cloud. In today's high-speed business world, the ability to deliver 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 ""
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:53(term) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:40(term) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:33(term)
msgid "Revenue opportunity"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:55(para)
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. For example, a small cloud service provider (CSP) might want to build a general purpose cloud rather than a massively scalable cloud because they do not have the deep financial resources needed, or because they do not, or will not, know in advance the purposes for which their customers are going to use the cloud. For some users, the advantages cloud itself offers mean an enhancement of revenue opportunity. For others, the fact that a general purpose cloud provides only baseline functionality will be a disincentive for use, leading to a potential stagnation of potential revenue opportunities."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:77(title) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:54(title) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:82(title) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:41(term) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:53(title)
msgid "Legal requirements"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:97(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:103(para) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:80(para) ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:42(para) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:58(para)
msgid "Examples of such legal frameworks include the <link href=\"http://ec.europa.eu/justice/data-protection/\">data protection framework</link> of the European Union and the requirements of the <link href=\"http://www.finra.org/Industry/Regulation/FINRARules/\">Financial Industry Regulatory Authority</link> in the United States. Consult a local regulatory body for more information."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:114(title) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:104(title)
msgid "Technical requirements"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:115(para)
msgid "Technical cloud architecture requirements should be weighted against the business requirements."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:122(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:131(term)
msgid "No predefined usage model"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:133(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:142(term)
msgid "On-demand and self-service application"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:144(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:157(term)
msgid "Public cloud"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:159(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:168(term)
msgid "Internal consumption (private) cloud"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:170(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:175(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:183(para)
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 <xref linkend=\"multi_site\"/>."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:193(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:9(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:14(para)
msgid "Knowing when and where to implement redundancy and high availability is directly affected by expectations set by the terms of the Service Level Agreements (SLAs). 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 ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:20(para)
msgid "SLA terms that will affect the design include:"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:23(para)
msgid "API availability guarantees implying multiple infrastructure services, and highly available load balancers."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:28(para)
msgid "Network uptime guarantees affecting switch design, which might require redundant switching and power."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:33(para)
msgid "Network security policies requirements need to be factored in to deployments."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:38(title) ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:36(title)
msgid "Support and maintainability"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:39(para)
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 a specially trained, dedicated operations organization. Smaller implementations are more likely to rely on support staff that need to take on combined engineering, design and operations functions."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:48(para)
msgid "Maintaining OpenStack installations requires a variety of technical skills. For example, if you are to incorporate features into an architecture and design that reduce the operations burden, it is advised to automate the operations functions. It may, however, be beneficial to use third party management companies with special expertise in managing OpenStack deployment."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:56(title) ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:59(title) ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:127(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:575(para)
msgid "Monitoring"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:57(para)
msgid "OpenStack clouds require appropriate monitoring platforms to ensure errors are caught and managed appropriately. Specific metrics that are critically important to monitor include:"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:62(para)
msgid "Image disk utilization"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:67(para)
msgid "Response time to the Compute API"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:72(para)
msgid "Leveraging existing monitoring systems is an effective check to ensure OpenStack environments can be monitored."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:77(title)
msgid "Downtime"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:78(para)
msgid "To effectively run cloud installations, initial downtime planning includes creating processes and architectures that support the following:"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:83(para)
msgid "Planned (maintenance)"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:88(para)
msgid "Unplanned (system faults)"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:93(para)
msgid "Resiliency of overall system and individual components are going to be dictated by the requirements of the SLA, meaning designing for high availability (HA) can have cost ramifications."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:96(para)
msgid "For example, if a compute host failed, this would be an operational consideration; requiring the restoration of instances from a snapshot or re-spawning an instance. The overall application design is impacted, general purpose clouds should not need to provide abilities to migrate instances from one host to another. Additional considerations need to be made around supporting instance migration if the expectation is that the application will be designed to tolerate failure. Extra support services, including shared storage attached to compute hosts, might need to be deployed in this example."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:108(para)
msgid "Capacity constraints for a general purpose cloud environment include:"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:112(para)
msgid "Compute limits"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:117(para)
msgid "Storage limits"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:122(para)
msgid "A relationship exists between the size of the compute environment and the supporting OpenStack infrastructure controller nodes requiring support."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:125(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:129(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:137(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:143(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:149(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:157(para)
msgid "For a deeper discussion on many of these topics, refer to the <link href=\"http://docs.openstack.org/ops\"><citetitle>OpenStack Operations Guide</citetitle></link>."
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:59(None)
msgid "@@image: '../figures/General_Architecture3.png'; md5=278d469e1d026634b3682209c454bff1"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:8(title)
msgid "Prescriptive example"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:9(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:18(para)
msgid "Between 120 and 140 installations of Nginx and Tomcat, each with 2 vCPUs and 4 GB of RAM"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:22(para)
msgid "A three-node MariaDB and Galera cluster, each with 4 vCPUs and 8 GB RAM"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:26(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:38(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:48(para)
msgid "OpenStack Block Storage for use by compute instances, requiring persistent storage (such as databases for dynamic sites)."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:53(para)
msgid "OpenStack Object Storage for serving static objects (such as images)."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:60(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:66(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:70(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:75(para)
msgid "Logs from the web application servers are shipped to OpenStack Object Storage for processing and archiving."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:78(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:83(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:90(para)
msgid "Leveraging Orchestration and Telemetry modules is also a potential issue when providing auto-scaling, orchestrated web application environments. Defining the web applications in <glossterm baseform=\"Heat Orchestration Template (HOT)\">Heat Orchestration Templates (HOT)</glossterm> negates the reliance on the current scripted Puppet solution."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:95(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:13(para)
msgid "General purpose clouds are often expected to include these base services:"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:32(para)
msgid "Each of these services has 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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:35(para)
msgid "Consider the unique aspects of each service that requires design since individual characteristics and service mass can impact the hardware selection process. Hardware designs are generated for each type of the following resource pools:"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:56(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:61(title)
msgid "Designing compute resources"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:62(para)
msgid "When designing compute resource pools, a number of factors can impact your design decisions. For example, decisions related to processors, memory, and storage within each hypervisor are just one element of designing compute resources. In addition, decide whether to provide compute resources in a single pool or in multiple pools. We recommend the compute design allocates multiple pools of resources to be addressed on-demand."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:70(para)
msgid "A compute design that allocates multiple pools of resources makes best use of application resources running in the cloud. Each independent resource pool should be designed to provide service for specific flavors of instances or groupings of flavors. Designing multiple resource pools helps to ensure that, as instances are scheduled onto compute hypervisors, each independent node's resources will be allocated to make the most efficient use of available hardware. This is commonly referred to as bin packing."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:78(para)
msgid "Using a consistent hardware design among the nodes that are placed within a resource pool also helps support bin packing. Hardware nodes selected for being a part of a compute resource pool should share a common processor, memory, and storage layout. By choosing a common hardware design, it becomes easier to deploy, support and maintain those nodes throughout their life cycle in the cloud."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:85(para)
msgid "An <firstterm>overcommit ratio</firstterm> is the ratio of available virtual resources, compared to the available physical resources. OpenStack is able to configure the overcommit ratio 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 for both of these options during the design phase is important as it has a direct impact on the hardware layout of your compute nodes."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:92(para)
msgid "For example, consider a m1.small instance uses 1 vCPU, 20GB of ephemeral storage and 2,048MB of RAM. When designing a hardware node as a compute resource pool to service instances, take into consideration the number of processor cores available on the node as well as the required disk and memory to service instances running at capacity. For a server with 2 CPUs of 10 cores each, with hyperthreading turned on, the default CPU overcommit ratio of 16:1 would allow for 640 (2 10 2 16) total m1.small instances. By the same reasoning, using the default memory overcommit ratio of 1.5:1 you can determine that the server will need at least 853GB (640 2,048MB / 1.5) of RAM. When sizing nodes for memory, it is also important to consider the additional memory required to service operating system and service needs."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:106(para)
msgid "Processor selection is an extremely important consideration in hardware design, especially when comparing the features and performance characteristics of different processors. Processors can include features specific to virtualized compute hosts including 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 running in the cloud."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:113(para)
msgid "It is also important to consider the compute requirements of resource nodes within the cloud. Resource nodes refer to non-hypervisor nodes providing the following in the cloud:"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:118(para)
msgid "Controller"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:123(para)
msgid "Object storage"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:128(para)
msgid "Block storage"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:133(para)
msgid "Networking services"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:138(para)
msgid "The number of processor cores and threads has a direct correlation to the number of worker threads which can be run on a resource node. As a result, you must make design decisions relating directly to the service, as well as provide a balanced infrastructure for all services."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:142(para)
msgid "Workload profiles are unpredictable in a general purpose cloud. Additional compute resource pools can be added to the cloud later, reducing the stress of unpredictability. In some cases, the demand on certain instance types or flavors may not justify individual hardware design. In either of these cases, initiate the design by allocating hardware designs that are capable of servicing the most common instances requests. If you are looking to add additional hardware designs to the overall architecture, this can be done at a later time."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:154(title)
msgid "Designing network resources"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:155(para)
msgid "OpenStack clouds traditionally have multiple network segments, each of which provides access to resources within the cloud to both operators and tenants. 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, we recommend planning for a physical or logical separation of network segments that will be used by operators and tenants. We further suggest the creation of an additional network segment for access to internal services such as the message bus and databse used by the various cloud services. Segregating these services onto separate networks helps to protect sensitive data and protects against unauthorized access to services."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:167(para)
msgid "Based on the requirements of instances being serviced in the cloud, the choice of network service will be the next decision that affects your design architecture."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:170(para)
msgid "The choice between legacy networking (nova-network), as a part of OpenStack Compute, and OpenStack Networking (neutron), has a huge impact on the architecture and design of the cloud network infrastructure."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:178(para)
msgid "The legacy networking (nova-network) service is primarily a layer-2 networking service that functions in two modes. In legacy networking, the two modes differ in their use of VLANs. When using legacy networking 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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:185(para)
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. These limitations place hard limits 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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:199(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:208(term)
msgid "OpenStack Networking (neutron)"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:210(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:222(para)
msgid "Initially, it is suggested to design at least three network segments, the first of which will be used for access to the cloud's REST APIs by tenants and operators. This is referred to as a public network. In most cases, the controller nodes and swift proxies within the cloud will be the only devices necessary to connect to this network segment. In some cases, this network might also be serviced by hardware load balancers and other network devices."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:230(para)
msgid "The next segment is used by cloud administrators to manage hardware resources and is also used by configuration management tools when 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, to communicate with each other. Due to the highly secure nature of this network segment, it may be desirable to secure this network from unauthorized access. This network will likely need to communicate with every hardware node within the cloud."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:240(para)
msgid "The last network segment is used by applications and consumers to provide access to the physical network and also for users accessing applications running within the cloud. This network is generally 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 will need to communicate on this network segment, as will any network gateway services which allow application data to access the physical network outside of the cloud."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:253(title)
msgid "Designing storage resources"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:254(para)
msgid "OpenStack has two independent storage services to consider, each with its own specific design requirements and goals. In addition to services which provide storage as their primary function, there are additional design considerations with regard to compute and controller nodes which will affect the overall cloud architecture."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:263(title)
msgid "Designing OpenStack Object Storage"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:264(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:273(para)
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 will ensure that data stays up to date and survives hardware faults without the use of any specialized data replication devices."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:279(para)
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. Many server chassis on the market can hold 60 or more drives in 4U of rack space, therefore we recommend maximizing the amount of storage per rack unit at the best cost per terabyte. Furthermore, we do not recommend the use of RAID controllers in an object storage node."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:289(para)
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 defult 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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:298(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:306(title)
msgid "Designing OpenStack Block Storage"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:307(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:316(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:325(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:344(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:349(para)
msgid "Choice of operating system"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:354(para)
msgid "Selection of OpenStack software components"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:359(para)
msgid "Choice of hypervisor"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:364(para)
msgid "Selection of supplemental software"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:369(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:374(para)
msgid "Ubuntu"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:379(para)
msgid "Red Hat Enterprise Linux (RHEL)"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:384(para)
msgid "CentOS"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:389(para)
msgid "SUSE Linux Enterprise Server (SLES)"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:395(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:404(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:412(para)
msgid "The primary factors that play into OS-hypervisor selection include:"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:418(para)
msgid "The selection of OS-hypervisor combination first and foremost needs to support the user requirements."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:424(term)
msgid "Support"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:426(para)
msgid "The selected OS-hypervisor combination needs to be supported by OpenStack."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:433(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:443(title) ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:37(title)
msgid "Hypervisor"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:444(para)
msgid "OpenStack supports a wide variety of hypervisors, one or more of which can be used in a single cloud. These hypervisors include:"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:449(para)
msgid "KVM (and QEMU)"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:452(para)
msgid "XCP/XenServer"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:455(para)
msgid "vSphere (vCenter and ESXi)"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:458(para)
msgid "Hyper-V"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:461(para)
msgid "LXC"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:464(para)
msgid "Docker"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:467(para)
msgid "Bare-metal"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:470(para)
msgid "A complete list of supported hypervisors and their capabilities can be found at <link href=\"https://wiki.openstack.org/wiki/HypervisorSupportMatrix\">OpenStack Hypervisor Support Matrix</link>."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:474(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:481(para)
msgid "The features offered through the OpenStack cloud platform determine the best choice of a hypervisor. As an example, for a general purpose cloud that predominantly supports a Microsoft-based migration, or is managed by staff that has a particular skill for managing certain hypervisors and operating systems, Hyper-V would be the best available choice. While the decision to use Hyper-V does not limit the ability to run alternative operating systems, be mindful of those that are deemed supported. Each different hypervisor also has their own hardware requirements which may affect the decisions around designing a general purpose cloud. For example, to utilize the live migration feature of VMware, vMotion, this requires an installation of vCenter/vSphere and the use of the ESXi hypervisor, which increases the infrastructure requirements."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:496(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:506(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:512(para)
msgid "OpenStack <glossterm>Compute</glossterm> (<glossterm>nova</glossterm>)"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:516(para)
msgid "OpenStack <glossterm>Networking</glossterm> (<glossterm>neutron</glossterm>)"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:520(para)
msgid "OpenStack <glossterm>Image Service</glossterm> (<glossterm>glance</glossterm>)"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:524(para)
msgid "OpenStack <glossterm>Identity</glossterm> (<glossterm>keystone</glossterm>)"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:528(para)
msgid "OpenStack <glossterm>dashboard</glossterm> (<glossterm>horizon</glossterm>)"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:532(para)
msgid "<glossterm>Telemetry</glossterm> module (<glossterm>ceilometer</glossterm>)"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:536(para)
msgid "A general purpose cloud may also include OpenStack <glossterm>Object Storage</glossterm> (<glossterm>swift</glossterm>). OpenStack <glossterm>Block Storage</glossterm> (<glossterm>cinder</glossterm>). These may be selected to provide storage to applications and instances."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:543(para)
msgid "However, depending on the use case, these could be optional."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:550(para)
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. Therefore, the underlying database nodes, for example, should consist of at least 3 nodes to account for the recovery of a failed Galera node. When increasing the number of nodes to support a feature of the software, consideration of rack space and switch port density becomes important."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:565(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:578(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:591(para)
msgid "Performance of an OpenStack deployment is dependent on a number of factors related to the infrastructure and controller services. The user requirements can be split into general network performance, performance of compute resources, and performance of storage systems."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:599(title)
msgid "Controller infrastructure"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:600(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:615(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:628(title)
msgid "Network performance"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:629(para)
msgid "In a general purpose OpenStack cloud, the requirements of the network help determine performance capabilities. For example, small deployments may employ 1 Gigabit Ethernet (GbE) networking, whereas larger installations serving multiple departments or many users would be better architected with 10GbE networking. The performance of the running instances will be limited by these speeds. 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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:640(para)
msgid "For example, web application instances may run on a public network presented through OpenStack Networking that has 1 GbE capability, whereas the back-end database uses an OpenStack Networking network that has 10GbE capability to replicate its data or, in some cases, the design may incorporate link aggregation for greater throughput."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:646(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:656(title)
msgid "Compute host"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:657(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:673(title)
msgid "Storage performance"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:674(para)
msgid "When considering performance of OpenStack 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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:685(para)
msgid "When considering performance of OpenStack 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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:697(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:706(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:711(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:720(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:731(para)
msgid "When using OpenStack 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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:743(para)
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 <citetitle><link href=\"http://docs.openstack.org/openstack-ops/content/network_design.html#network_deployment_options\">OpenStack Operations Guide</link></citetitle>."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:750(para)
msgid "Ensure your deployment has adequate back-up capabilities. As an example, in a deployment that has two infrastructure controller nodes, the design should include controller availability. In the event of the loss of a single controller, cloud services will run from a single controller in the event of failure. Where the design has higher availability requirements, it is important to meet those requirements by designing the proper redundancy and availability of controller nodes."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:759(para)
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. Conversely, 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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:771(para)
msgid "For more information on high availability in OpenStack, see the <link href=\"http://docs.openstack.org/high-availability-guide\"><citetitle>OpenStack High Availability Guide</citetitle></link>."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:779(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:272(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:783(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:277(para)
msgid "These security domains are:"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:786(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:280(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:107(para)
msgid "Public"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:789(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:283(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:110(para)
msgid "Guest"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:795(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:289(para) ./doc/arch-design/hybrid/section_architecture_hybrid.xml:186(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:116(para)
msgid "Data"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:798(para)
msgid "These security domains can be mapped to an OpenStack deployment individually, or combined. For example, some deployment topologies combine both guest and data domains onto one physical network, whereas in other cases these networks are physically separated. 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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:808(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:812(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:823(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:318(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:828(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:835(para)
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, traditionally, 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. For example, the API endpoints, along with the software behind them, become vulnerable to bad actors wanting to gain unauthorized access or prevent access to services, which could lead to loss of data, functionality, and reputation. These services must be protected against through auditing and appropriate filtering."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:849(para)
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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:855(para)
msgid "It's 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 ""
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:860(para)
msgid "For more information OpenStack Security, see the <link href=\"http://docs.openstack.org/security-guide/\"><citetitle>OpenStack Security Guide</citetitle></link>"
msgstr ""
#: ./doc/arch-design/introduction/section_intended_audience.xml:7(title)
msgid "Intended audience"
msgstr ""
#: ./doc/arch-design/introduction/section_intended_audience.xml:8(para)
msgid "This book has been written for architects and designers of OpenStack clouds. This book is not intended for people who are deploying OpenStack. For a guide on deploying and operating OpenStack, please refer to the <citetitle>OpenStack Operations Guide</citetitle> (<link href=\"http://docs.openstack.org/openstack-ops\">http://docs.openstack.org/openstack-ops</link>)."
msgstr ""
#: ./doc/arch-design/introduction/section_intended_audience.xml:15(para)
msgid "The reader should have 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 ""
#: ./doc/arch-design/introduction/section_how_this_book_was_written.xml:7(title)
msgid "Why and how we wrote this book"
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_was_written.xml:8(para)
msgid "The velocity at which OpenStack environments are moving from proof-of-concepts to production deployments is leading to increasing questions and issues related to architecture design considerations. By and large these considerations are not addressed in the existing documentation, which typically focuses on the specifics of deployment and configuration options or operational considerations, rather than the bigger picture."
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_was_written.xml:16(para)
msgid "We wrote this book to guide readers in designing an OpenStack architecture that meets the needs of their organization. This guide concentrates on identifying important design considerations for common cloud use cases and provides examples based on these design guidelines. This guide does not aim to provide explicit instructions for installing and configuring the cloud, but rather focuses on design principles as they relate to user requirements as well as technical and operational considerations. For specific guidance with installation and configuration there are a number of resources already available in the OpenStack documentation that help in that area."
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_was_written.xml:28(para)
msgid "This book was written in a book sprint format, which is a facilitated, rapid development production method for books. For more information, see the Book Sprints website (www.booksprints.net)."
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_was_written.xml:32(para)
msgid "This book was written in five days during July 2014 while exhausting the M&amp;M, Mountain Dew and healthy options supply, complete with juggling entertainment during lunches at VMware's headquarters in Palo Alto. The event was also documented on Twitter using the #OpenStackDesign hashtag. The Book Sprint was facilitated by Faith Bosworth and Adam Hyde."
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_was_written.xml:39(para)
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 ""
#: ./doc/arch-design/introduction/section_how_this_book_was_written.xml:46(para)
msgid "The author team includes:"
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_was_written.xml:49(para)
msgid "Kenneth Hui (EMC) <link href=\"http://twitter.com/hui_kenneth\">@hui_kenneth</link>"
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_was_written.xml:54(para)
msgid "Alexandra Settle (Rackspace) <link href=\"http://twitter.com/dewsday\">@dewsday</link>"
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_was_written.xml:59(para)
msgid "Anthony Veiga (Comcast) <link href=\"http://twitter.com/daaelar\">@daaelar</link>"
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_was_written.xml:64(para)
msgid "Beth Cohen (Verizon) <link href=\"http://twitter.com/bfcohen\">@bfcohen</link>"
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_was_written.xml:69(para)
msgid "Kevin Jackson (Rackspace) <link href=\"http://twitter.com/itarchitectkev\">@itarchitectkev</link>"
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_was_written.xml:74(para)
msgid "Maish Saidel-Keesing (Cisco) <link href=\"http://twitter.com/maishsk\">@maishsk</link>"
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_was_written.xml:79(para)
msgid "Nick Chase (Mirantis) <link href=\"http://twitter.com/NickChase\">@NickChase</link>"
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_was_written.xml:84(para)
msgid "Scott Lowe (VMware) <link href=\"http://twitter.com/scott_lowe\">@scott_lowe</link>"
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_was_written.xml:89(para)
msgid "Sean Collins (Comcast) <link href=\"http://twitter.com/sc68cal\">@sc68cal</link>"
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_was_written.xml:94(para)
msgid "Sean Winn (Cloudscaling) <link href=\"http://twitter.com/seanmwinn\">@seanmwinn</link>"
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_was_written.xml:99(para)
msgid "Sebastian Gutierrez (Red Hat) <link href=\"http://twitter.com/gutseb\">@gutseb</link>"
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_was_written.xml:104(para)
msgid "Stephen Gordon (Red Hat) <link href=\"http://twitter.com/xsgordon\">@xsgordon</link>"
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_was_written.xml:109(para)
msgid "Vinny Valdez (Red Hat) <link href=\"http://twitter.com/VinnyValdez\">@VinnyValdez</link>"
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/arch-design/introduction/section_methodology.xml:21(None)
msgid "@@image: '../figures/Methodology.png'; md5=6b187c6b7bf846d86f60b062461e7bdf"
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:11(title)
msgid "Methodology"
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:12(para)
msgid "The magic of the cloud is that it can do anything. It is both robust and flexible, the best of both worlds. Yes, the cloud is highly flexible and it can do almost anything, but to get the most out of a cloud investment, it is important to define how the cloud will be used by creating and testing use cases. This is the chapter that describes the thought process behind how to design a cloud architecture that best suits the intended use."
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:24(para)
msgid "The diagram shows at a very abstract level the process for capturing requirements and building use cases. Once a set of use cases has been defined, it can then be used to design the cloud architecture."
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:27(para)
msgid "Use case planning can seem counter-intuitive. After all, it takes about five minutes to sign up for a server with Amazon. Amazon does not know in advance what any given user is planning on doing with it, right? Wrong. Amazon's product management department spends plenty of time figuring out exactly what would be attractive to their typical customer and honing the service to deliver it. For the enterprise, the planning process is no different, but instead of planning for an external paying customer, for example, the use could be for internal application developers or a web portal. The following is a list of the high level objectives that need to be incorporated into the thinking about creating a use case."
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:38(para)
msgid "Overall business objectives"
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:41(para)
msgid "Develop clear definition of business goals and requirements"
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:45(para)
msgid "Increase project support and engagement with business, customers and end users."
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:49(para)
msgid "Technology"
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:52(para)
msgid "Coordinate the OpenStack architecture across the project and leverage OpenStack community efforts more effectively."
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:56(para)
msgid "Architect for automation as much as possible to speed development and deployment."
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:60(para)
msgid "Use the appropriate tools for the development effort."
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:63(para)
msgid "Create better and more test metrics and test harnesses to support continuous and integrated development, test processes and automation."
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:68(para)
msgid "Organization"
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:71(para)
msgid "Better messaging of management support of team efforts"
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:74(para)
msgid "Develop better cultural understanding of Open Source, cloud architectures, Agile methodologies, continuous development, test and integration, overall development concepts in general"
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:79(para)
msgid "As an example of how this works, consider a business goal of using the cloud for the company's E-commerce website. This goal means planning for applications that will support thousands of sessions per second, variable workloads, and lots of complex and changing data. By identifying the key metrics, such as number of concurrent transactions per second, size of database, and so on, it is possible to then build a method for testing the assumptions."
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:87(title)
msgid "Develop functional user scenarios"
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:88(para)
msgid "Develop functional user scenarios that can be used to develop test cases that can be used to measure overall project trajectory. If the organization is not ready to commit to an application or applications that can be used to develop user requirements, it needs to create requirements to build valid test harnesses and develop usable metrics. Once the metrics are established, as requirements change, it is easier to respond to the changes quickly without having to worry overly much about setting the exact requirements in advance. Think of this as creating ways to configure the system, rather than redesigning it every time there is a requirements change."
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:104(title)
msgid "Limit cloud feature set"
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:105(para)
msgid "Create requirements that address the pain points, but do not recreate the entire OpenStack tool suite. The requirement to build OpenStack, only better, is self-defeating. It is important to limit scope creep by concentrating on developing a platform that will address tool limitations for the requirements, but not recreating the entire suite of tools. Work with technical product owners to establish critical features that are needed for a successful cloud deployment."
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:118(title)
msgid "Application cloud readiness"
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:119(para)
msgid "Although the cloud is designed to make things easier, it is important to realize that \"using cloud\" is more than just firing up an instance and dropping an application on it. The \"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 ""
#: ./doc/arch-design/introduction/section_methodology.xml:125(para)
msgid "In traditional environments, with traditional enterprise applications, the applications and the servers that run on them are \"pets\". They're 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 ""
#: ./doc/arch-design/introduction/section_methodology.xml:131(para)
msgid "In cloud environments, on the other hand, 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, naturally will suffer outages, lost data, or worse."
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:137(para)
msgid "There are other reasons to design applications with cloud in mind. Some are defensive, such as the fact that 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, so applications need to be designed in such a way that they can take advantage of those and other opportunities."
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:146(title)
msgid "Determining whether an application is cloud-ready"
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:147(para)
msgid "There are several factors to take into consideration when looking at whether an application is a good fit for the cloud."
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:151(term)
msgid "Structure"
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:153(para)
msgid "A large, monolithic, single-tiered legacy application typically isn't 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 ""
#: ./doc/arch-design/introduction/section_methodology.xml:168(para)
msgid "Applications that depend on specific hardwaresuch as a particular chip set or an external device such as a fingerprint readermight 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 ""
#: ./doc/arch-design/introduction/section_methodology.xml:184(para)
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, work around these issues with custom network setup, but how well this works depends on the chosen cloud environment."
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:195(term)
msgid "Durability and resilience"
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:197(para)
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 ""
#: ./doc/arch-design/introduction/section_methodology.xml:209(title)
msgid "Designing for the cloud"
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:210(para)
msgid "Here are some guidelines to keep in mind when designing an application for the cloud:"
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:214(para)
msgid "Be a pessimist: Assume everything fails and design backwards. Love your chaos monkey."
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:218(para)
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 ""
#: ./doc/arch-design/introduction/section_methodology.xml:224(para)
msgid "Think efficiency: Inefficient designs will not scale. Efficient designs become cheaper as they scale. Kill off unneeded components or capacity."
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:229(para)
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 ""
#: ./doc/arch-design/introduction/section_methodology.xml:234(para)
msgid "But not too paranoid: Not every application needs the platinum solution. Architect for different SLA's, service tiers and security levels."
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:239(para)
msgid "Manage the data: Data is usually the most inflexible and complex area of a cloud and cloud integration architecture. Don't short change the effort in analyzing and addressing data needs."
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:245(para)
msgid "Hands off: Leverage automation to increase consistency and quality and reduce response times."
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:249(para)
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 ""
#: ./doc/arch-design/introduction/section_methodology.xml:255(para)
msgid "Think elasticity: Increasing resources should result in a proportional increase in performance and scalability. Decreasing resources should have the opposite effect."
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:261(para)
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 ""
#: ./doc/arch-design/introduction/section_methodology.xml:267(para)
msgid "Stay close: Reduce latency by moving highly interactive components and data near each other."
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:271(para)
msgid "Keep it loose: Loose coupling, service interfaces, separation of concerns, abstraction and well defined API's deliver flexibility."
msgstr ""
#: ./doc/arch-design/introduction/section_methodology.xml:276(para)
msgid "Be cost aware: Autoscaling, data transmission, virtual software licenses, reserved instances, and so on can rapidly increase monthly usage charges. Monitor usage closely."
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:7(title)
msgid "How this book is organized"
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:8(para)
msgid "This book has been organized into various chapters that help define the use cases associated with making architectural choices related to an <glossterm>OpenStack</glossterm> cloud installation. Each chapter is intended to stand alone to encourage individual chapter readability, however each chapter is designed to contain useful information that may be applicable in situations covered by other chapters. 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. When choosing to read specific use cases, note that it may be necessary to read more than one section of the guide to formulate a complete design for the cloud. The use cases covered in this guide include:"
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:25(para)
msgid "<link linkend=\"generalpurpose\">General purpose</link>: A cloud built with common components that should address 80% of common use cases."
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:32(para)
msgid "<link linkend=\"compute_focus\">Compute focused</link>: A cloud designed to address compute intensive workloads such as high performance computing (HPC)."
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:39(para)
msgid "<link linkend=\"storage_focus\">Storage focused</link>: A cloud focused on storage intensive workloads such as data analytics with parallel file systems."
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:46(para)
msgid "<link linkend=\"network_focus\">Network focused</link>: A cloud depending on high performance and reliable networking, such as a <glossterm>content delivery network (CDN)</glossterm>."
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:54(para)
msgid "<link linkend=\"multi_site\">Multi-site</link>: A cloud built with multiple sites available for application deployments for geographical, reliability or data locality reasons."
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:62(para)
msgid "<link linkend=\"hybrid\">Hybrid cloud</link>: An architecture where multiple disparate clouds are connected either for failover, hybrid cloud bursting, or availability."
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:70(para)
msgid "<link linkend=\"massively_scalable\">Massively scalable</link>: An architecture that is intended for cloud service providers or other extremely large installations."
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:78(para)
msgid "A chapter titled <link linkend=\"specialized\">Specialized cases</link> provides information on architectures that have not previously been covered in the defined use cases."
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:83(para)
msgid "Each chapter in the guide is then further broken down into the following sections:"
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:87(para)
msgid "Introduction: Provides an overview of the architectural use case."
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:91(para)
msgid "User requirements: Defines the set of user considerations that typically come into play for that use case."
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:96(para)
msgid "Technical considerations: Covers the technical issues that must be accounted when dealing with this use case."
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:101(para)
msgid "Operational considerations: Covers the ongoing operational tasks associated with this use case and architecture."
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:106(para)
msgid "Architecture: Covers the overall architecture associated with the use case."
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:110(para)
msgid "Prescriptive examples: Presents one or more scenarios where this architecture could be deployed."
msgstr ""
#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:115(para)
msgid "A glossary covers the terms used in the book."
msgstr ""
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:9(para)
msgid "Operationally, there are a number of considerations that affect the design of compute-focused OpenStack clouds. Some examples might include enforcing strict API availability requirements, understanding and dealing with failure scenarios, or managing host maintenance schedules."
msgstr ""
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:13(para)
msgid "Service-level agreements (SLAs) are a contractual obligation that gives assurances around the availability of a provided service. As such, factoring in promises of availability implies a certain level of redundancy and resiliency when designing an OpenStack cloud."
msgstr ""
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:19(para)
msgid "Guarantees for API availability imply multiple infrastructure services combined with appropriately high available load balancers."
msgstr ""
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:24(para)
msgid "Network uptime guarantees will affect the switch design and might require redundant switching and power."
msgstr ""
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:28(para)
msgid "Network security policy requirements need to be factored in to deployments."
msgstr ""
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:32(para)
msgid "Knowing when and where to implement redundancy and high availability (HA) is directly affected by the terms contained in any associated SLA, if one is present."
msgstr ""
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:37(para)
msgid "OpenStack cloud management requires operations staff to be able to understand and comprehend design architecture content on some level. The level of skills and the level of separation of the operations and engineering staff is dependent on the size and purpose of the installation. A large cloud service provider or a telecom provider is more inclined to be managed by a specially trained dedicated operations organization. A smaller implementation is more inclined to rely on a smaller support staff that might need to take on the combined engineering, design and operations functions."
msgstr ""
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:47(para)
msgid "Maintaining OpenStack installations require a variety of technical skills. Some of these skills may include the ability to debug Python log output to a basic level as well as an understanding of networking concepts."
msgstr ""
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:51(para)
msgid "Consider incorporating features into the architecture and design that reduce the operational burden. Some examples include automating some of the operations functions, or alternatively exploring the possibility of using a third party management company with special expertise in managing OpenStack deployments."
msgstr ""
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:60(para)
msgid "Like any other infrastructure deployment, OpenStack clouds need an appropriate monitoring platform to ensure errors are caught and managed appropriately. Consider leveraging any existing monitoring system to see if it will be able to effectively monitor an OpenStack environment. While there are many aspects that need to be monitored, specific metrics that are critically important to capture include image disk utilization, or response time to the Compute API."
msgstr ""
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:70(title)
msgid "Expected and unexpected server downtime"
msgstr ""
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:71(para)
msgid "At some point, servers will fail. The SLAs in place affect how the design has to address recovery time. Recovery of a failed host may mean restoring instances from a snapshot, or respawning that instance on another available host, which then has consequences on the overall application design running on the OpenStack cloud."
msgstr ""
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:77(para)
msgid "It might be acceptable to design a compute-focused cloud without the ability to migrate instances from one host to another, because the expectation is that the application developer must handle failure within the application itself. Conversely, a compute-focused cloud might be provisioned to provide extra resilience as a requirement of that business. In this scenario, it is expected that extra supporting services are also deployed, such as shared storage attached to hosts to aid in recovery and resiliency of services in order to meet strict SLAs."
msgstr ""
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:90(para)
msgid "Adding extra capacity to an OpenStack cloud is an easy horizontally scaling process, as consistently configured nodes automatically attach to an OpenStack cloud. Be mindful, however, of any additional work to place the nodes into appropriate Availability Zones and Host Aggregates if necessary. The same (or very similar) CPUs are recommended when adding extra nodes to the environment because it reduces the chance to break any live-migration features if they are present. Scaling out hypervisor hosts also has a direct effect on network and other data center resources, so factor in this increase when reaching rack capacity or when extra network switches are required."
msgstr ""
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:102(para)
msgid "Compute hosts can also have internal components changed to account for increases in demand, a process also known as vertical scaling. Swapping a CPU for one with more cores, or increasing the memory in a server, can help add extra needed capacity depending on whether the running applications are more CPU intensive or memory based (as would be expected in a compute-focused OpenStack cloud)."
msgstr ""
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:109(para)
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. While only appropriate in some environments, it's important to remember that changing the CPU overcommit ratio can have a detrimental effect and cause a potential increase in a noisy neighbor. The added risk of increasing the overcommit ratio is that more instances will fail when a compute host fails. In a compute-focused OpenStack design architecture, increasing the CPU overcommit ratio increases the potential for noisy neighbor issues and is not recommended."
msgstr ""
#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:13(para)
msgid "Compute intensive workloads are defined by their high utilization of CPU, RAM, or both. User requirements will determine if a cloud must be built to accommodate anticipated performance demands."
msgstr ""
#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:22(para)
msgid "Cost is not generally a primary concern for a compute-focused cloud, however some organizations might be concerned with cost avoidance. Repurposing existing resources to tackle compute-intensive tasks instead of needing to acquire additional resources may offer cost reduction opportunities."
msgstr ""
#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:33(para)
msgid "Compute-focused clouds can be used to deliver products more quickly, for example, speeding up a company's software development life cycle (SDLC) for building products and applications."
msgstr ""
#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:42(para)
msgid "Companies that are interested in building services or products that rely on the power of the compute resources will benefit from a compute-focused cloud. Examples include the analysis of large data sets (via Hadoop or Cassandra) or completing computational intensive tasks such as rendering, scientific computation, or simulations."
msgstr ""
#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:74(para)
msgid "Data compliancecertain types of information needs to reside in certain locations due to regular issuesand more important cannot reside in other locations for the same reason."
msgstr ""
#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:91(para)
msgid "The following are some technical requirements that need to be incorporated into the architecture design."
msgstr ""
#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:98(para)
msgid "If a primary technical concern is for the environment to deliver high performance capability, then a compute-focused design is an obvious choice because it is specifically designed to host compute-intensive workloads."
msgstr ""
#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:106(term)
msgid "Workload persistence"
msgstr ""
#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:108(para)
msgid "Workloads can be either short-lived or long running. Short-lived workloads might include continuous integration and continuous deployment (CI-CD) jobs, where large numbers of compute instances are created simultaneously to perform a set of compute-intensive tasks. The results or artifacts are then copied from the instance into long-term storage before the instance is destroyed. Long-running workloads, like a Hadoop or high-performance computing (HPC) cluster, typically ingest large data sets, perform the computational work on those data sets, then push the results into long term storage. Unlike short-lived workloads, when the computational work is completed, they will remain idle until the next job is pushed to them. Long-running workloads are often larger and more complex, so the effort of building them is mitigated by keeping them active between jobs. Another example of long running workloads is legacy applications that typically are persistent over time."
msgstr ""
#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:133(para)
msgid "Workloads targeted for a compute-focused OpenStack cloud generally do not require any persistent block storage (although some usages of Hadoop with HDFS may dictate the use of persistent block storage). A shared filesystem or object store will maintain the initial data set(s) and serve as the destination for saving the computational results. By avoiding the input-output (IO) overhead, workload performance is significantly enhanced. Depending on the size of the data set(s), it might be necessary to scale the object store or shared file system to match the storage demand."
msgstr ""
#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:148(term)
msgid "User interface"
msgstr ""
#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:150(para)
msgid "Like any other cloud architecture, a compute-focused OpenStack cloud requires an on-demand and self-service user interface. End users must be able to provision computing power, storage, networks and software simply and flexibly. This includes scaling the infrastructure up to a substantial level without disrupting host operations."
msgstr ""
#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:162(para)
msgid "Security is going to be highly dependent on the business requirements. For example, a computationally intense drug discovery application will obviously have much higher security requirements than a cloud that is designed for processing market data for a retailer. As a general start, the security recommendations and guidelines provided in the OpenStack Security Guide are applicable."
msgstr ""
#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:176(para)
msgid "The compute intensive cloud from the operational perspective is similar to the requirements for the general-purpose cloud. More details on operational requirements can be found in the general-purpose design section."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:9(para)
msgid "The hardware selection covers three areas:"
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:21(para)
msgid "An OpenStack cloud with extreme demands on processor and memory resources is considered to be compute-focused, and requires hardware that can handle these demands. This can mean choosing hardware which might not perform as well on storage or network capabilities. In a compute- focused architecture, storage and networking are required while loading a data set into the computational cluster, but are not otherwise in heavy demand."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:30(para)
msgid "Compute (server) hardware must be evaluated against four dimensions:"
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:37(para)
msgid "A measure of how many servers can fit into a given amount of physical space, such as a rack unit (U)."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:63(para)
msgid "The dimensions need to be weighed against each other to determine the best design for the desired purpose. For example, increasing server density means sacrificing resource capacity or expandability. Increasing resource capacity and expandability can increase cost but decreases server density. Decreasing cost can mean decreasing supportability, server density, resource capacity, and expandability."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:69(para)
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. The hardware will need to be configured to provide enough network connectivity and storage capacity to meet minimum user requirements, but they are not the primary consideration."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:75(para)
msgid "Some server hardware form factors are better suited than others, as CPU and RAM capacity have the highest priority. Some considerations for selecting hardware:"
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:80(para)
msgid "Most blade servers can support dual-socket multi-core CPUs. To avoid this CPU limit, select \"full width\" or \"full height\" blades, however this will also decrease the server density. For example, high density blade servers (like HP BladeSystem or Dell PowerEdge M1000e) which 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 ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:89(para)
msgid "1U rack-mounted servers (servers that occupy only a single rack unit) may be able to 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. However, as of the Icehouse release, 1U servers from the major vendors are limited to dual-socket, multi-core CPU configurations. To obtain greater than dual-socket support in a 1U rack-mount form factor, you will need to buy systems from original design (ODMs) or second-tier manufacturers."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:100(para)
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 ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:105(para)
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 ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:111(para)
msgid "\"Sled servers\" (rack-mounted servers that support multiple independent servers in a single 2U or 3U enclosure) deliver increased 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. However, the dual-socket limitation on individual nodes may not be sufficient to offset their additional cost and configuration complexity."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:120(para)
msgid "Consider these facts when choosing server hardware for a compute- focused OpenStack design architecture:"
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:126(para)
msgid "In a compute-focused architecture, instance density is lower, which means CPU and RAM over-subscription ratios are also lower. More hosts will be required to support the anticipated scale due to instance density being lower, especially if the design uses dual-socket hardware designs."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:136(para)
msgid "Another option to address the higher host count that might be needed with dual socket designs is to use a quad socket platform. Taking this approach will decrease host density, which increases rack count. This configuration may affect the network requirements, the number of power connections, and possibly impact the cooling requirements."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:145(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:275(term)
msgid "Power and cooling density"
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:147(para)
msgid "The power and cooling density requirements might be lower than with blade, sled, or 1U server designs because of lower host density (by using 2U, 3U or even 4U server designs). For data centers with older infrastructure, this may be a desirable feature."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:155(para)
msgid "Compute-focused OpenStack design architecture server hardware selection results in a \"scale up\" versus \"scale out\" decision. Selecting a better solution, 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 ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:162(title)
msgid "Storage hardware selection"
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:163(para)
msgid "For a compute-focused OpenStack design architecture, the selection of storage hardware is not critical as it is not primary criteria, however it is still important. There are a number of different factors that a cloud architect must consider:"
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:171(para)
msgid "The overall cost of the solution will play a major role in what storage architecture (and resulting storage hardware) is selected."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:179(para)
msgid "The performance of the solution is also a big role and can be measured by observing the latency of storage I-O requests. In a compute-focused OpenStack cloud, storage latency can be a major consideration. In some compute-intensive workloads, minimizing the delays that the CPU experiences while fetching data from the storage can have a significant impact on the overall performance of the application."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:191(para)
msgid "This section will refer to the term \"scalability\" to refer to how well the storage solution performs as it is expanded up to its maximum size. A storage solution that performs well in small configurations but has degrading performance as it expands would not be considered scalable. On the other hand, a solution that continues to perform well at maximum expansion would be considered scalable."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:203(para)
msgid "Expandability refers to the overall ability of the solution to grow. A storage solution that expands to 50 PB is considered more expandable than a solution that only scales to 10PB. Note that this metric is related to, but different from, scalability, which is a measure of the solution's performance as it expands."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:212(para)
msgid "For a compute-focused OpenStack cloud, latency of storage is a major consideration. Using solid-state disks (SSDs) to minimize latency for instance storage and reduce CPU delays caused by waiting for the storage will increase performance. Consider using RAID controller cards in compute hosts to improve the performance of the underlying disk subsystem."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:218(para)
msgid "The selection of storage architecture, and the corresponding storage hardware (if there is the option), is determined by evaluating possible solutions against the key factors listed above. This will determine if a scale-out solution (such as Ceph, GlusterFS, or similar) should be used, or if a single, highly expandable and scalable centralized storage array would be a better choice. If a centralized storage array is the right fit for the requirements, the hardware will be determined by the array vendor. It is also possible to build a storage array using commodity hardware with Open Source software, but there needs to be access to people with expertise to build such a system. Conversely, a scale-out storage solution that uses direct-attached storage (DAS) in the servers may be an appropriate choice. If so, then the server hardware needs to be configured to support the storage solution."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:232(para)
msgid "The following lists some of the potential impacts that may affect a particular storage architecture, and the corresponding storage hardware, of a compute-focused OpenStack cloud:"
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:239(para)
msgid "Based on the storage solution selected, ensure the connectivity matches the storage solution requirements. If a centralized storage array is selected, it is important to determine how the hypervisors will connect to the storage array. Connectivity could affect latency and thus performance, so check that the network characteristics will minimize latency to boost the overall performance of the design."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:249(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:109(term)
msgid "Latency"
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:251(para)
msgid "Determine if the use case will have consistent or highly variable latency."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:256(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:116(term)
msgid "Throughput"
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:258(para)
msgid "To improve overall performance, make sure that the storage solution throughout is optimized. While it is not likely that a compute-focused cloud will have major data I-O to and from storage, this is an important factor to consider."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:265(term)
msgid "Server Hardware"
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:267(para)
msgid "If the solution uses DAS, this impacts, and is not limited to, the server hardware choice that will ripple into host density, instance density, power density, OS-hypervisor, and management tools."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:274(para)
msgid "Where instances need to be made highly available, or they need to be capable of migration between hosts, use of a shared storage file-system to store instance ephemeral data should be employed to ensure that compute services can run uninterrupted in the event of a node failure."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:295(para)
msgid "The network design will be affected by the physical space that is required to provide the requisite port count. A switch that can provide 48 10 GbE ports in 1U has a much higher port density than a switch that provides 24 10 GbE ports in 2U. A higher port density is preferred, as it leaves more rack space for compute or storage components that might be required by the design. This also leads into concerns about fault domains and power density that must also 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 ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:310(para)
msgid "The networking hardware must support the proposed network speed, for example: 1 GbE, 10 GbE, or 40 GbE (or even 100 GbE)."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:318(para)
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. User requirements will determine if a completely redundant network infrastructure is required."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:330(para)
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 ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:338(para)
msgid "It is important to first understand additional factors as well as the use case because these additional factors heavily influence the cloud network architecture. Once these key considerations have been decided, the proper network can be designed to best serve the workloads being placed in the cloud."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:343(para)
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 will support 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. Increased network availability and redundancy comes at a cost, therefore we recommend to weigh the cost versus the benefit gained from utilizing and deploying redundant network switches and using bonded interfaces at the host level."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:359(para)
msgid "Selecting software to be included in a compute-focused OpenStack architecture design must include three main areas:"
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:372(para)
msgid "Design decisions made in each of these areas impact the rest of the OpenStack architecture design."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:377(para)
msgid "The selection of operating system (OS) and hypervisor has a significant impact on the end point design. Selecting a particular operating system and hypervisor could affect server hardware selection. For example, a selected combination needs to be supported on the selected hardware. Ensuring the storage hardware selection and topology supports the selected operating system and hypervisor combination should also be considered. Additionally, make sure that the networking hardware selection and topology will work with the chosen operating system and hypervisor combination. For example, if the design uses Link Aggregation Control Protocol (LACP), the hypervisor needs to support it."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:393(para)
msgid "Selecting a commercially supported hypervisor such as Microsoft Hyper-V will result in a different cost model rather than choosing a community-supported open source hypervisor like Kinstance or Xen. Even within the ranks of open source solutions, choosing Ubuntu over Red Hat (or vice versa) will have an impact on cost due to support contracts. On the other hand, business or application requirements might dictate a specific or commercially supported hypervisor."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:406(para)
msgid "Depending on the selected hypervisor, the 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 ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:427(para)
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 combination."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:437(para)
msgid "Ensure that the design can accommodate the regular periodic installation of application security patches while maintaining the required workloads. The frequency of security patches for the proposed OS-hypervisor combination will have an impact on performance and the patch installation process could affect maintenance windows."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:448(para)
msgid "Determine what features of OpenStack are required. This will often determine the selection of the OS-hypervisor combination. Certain features are only available with specific OSs or hypervisors. For example, if certain features are not available, the design might need to be modified to meet the user requirements."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:459(para)
msgid "Consideration should be given to the ability of the selected OS-hypervisor combination to interoperate or co-exist with other OS-hypervisors, or other software solutions in the overall design (if required). Operational and 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 ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:473(para)
msgid "The selection of which OpenStack components will actually be included in the design and deployed has significant impact. There are certain components that will always be present, (Compute and Image Service, for example) yet there are other services that might not need to be present. For example, a certain design may not require the Orchestration module. Omitting Heat 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 ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:482(para)
msgid "For a compute-focused OpenStack design architecture, the following components would be used:"
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:486(para)
msgid "Identity (keystone)"
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:489(para)
msgid "Dashboard (horizon)"
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:492(para)
msgid "Compute (nova)"
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:495(para)
msgid "Object Storage (swift, ceph or a commercial solution)"
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:498(para)
msgid "Image (glance)"
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:501(para)
msgid "Networking (neutron)"
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:504(para)
msgid "Orchestration (heat)"
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:507(para)
msgid "OpenStack Block Storage would potentially not be incorporated into a compute-focused design due to persistent block storage not being a significant requirement for the types of workloads that would be deployed onto instances running in a compute-focused cloud. However, there may be some situations where the need for performance dictates that a block storage component be used to improve data I-O."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:513(para)
msgid "The exclusion of certain OpenStack components might also limit or constrain the functionality of other components. If a design opts to include the Orchestration module but excludes the Telemetry module, then the design will not be able to take advantage of Orchestration's auto scaling functionality (which relies on information from Telemetry). This is due to the fact that you can use Orchestration to spin up a large number of instances to perform the compute-intensive processing. This includes Orchestration in a compute-focused architecture design, which is strongly recommended."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:525(para)
msgid "While OpenStack is a fairly complete collection of software projects for building a platform for cloud services, there are invariably additional pieces of software that might need to be added to any given OpenStack design."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:531(para)
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. Some examples include software to provide load balancing, network redundancy protocols, and routing daemons. Some of these software packages are described in more detail in the <citetitle>OpenStack High Availability Guide</citetitle> (<link href=\"http://docs.openstack.org/high-availability-guide/content\">http://docs.openstack.org/high-availability-guide/content</link>)."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:540(para)
msgid "For a compute-focused OpenStack cloud, the OpenStack infrastructure components will 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 ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:547(para)
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 ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:550(para)
msgid "Inclusion of clustering Software, such as Corosync or Pacemaker, is determined primarily by the availability design requirements. Therefore, 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 ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:558(para)
msgid "Requirements for logging, monitoring, and alerting are determined by operational considerations. Each of these sub-categories includes a number of various options. For example, in the logging sub-category one might consider Logstash, Splunk, Log Insight, or some other log aggregation-consolidation tool. Logs should be stored in a centralized location to make it easier to perform 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 ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:567(para)
msgid "If any of these software packages are needed, then the design must account for the additional resource consumption (CPU, RAM, storage, and network bandwidth for a log aggregation solution, for example). Some other potential design impacts include:"
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:585(para)
msgid "A large majority of the OpenStack components require access to back-end database services to store state and configuration information. Selection of an appropriate back-end database that will satisfy the availability and fault tolerance requirements of the OpenStack services is required. OpenStack services support connecting to any database that is supported by the SQLAlchemy Python drivers, however most common database deployments make use of MySQL or some variation of it. We recommend that the database which provides back-end services within a general-purpose cloud, be made highly available using an available technology which can accomplish that goal. Some of the more common software solutions used include Galera, MariaDB and MySQL with multi-master replication."
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:233(None)
msgid "@@image: '../figures/Compute_Tech_Bin_Packing_General1.png'; md5=34f2f0b656a66124016d2484fb96068b"
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:242(None)
msgid "@@image: '../figures/Compute_Tech_Bin_Packing_CPU_optimized1.png'; md5=45084140c29e59a459d6b0af9b47642a"
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:13(para)
msgid "In a compute-focused OpenStack cloud, the type of instance workloads being provisioned heavily influences technical decision making. For example, specific use cases that demand multiple short running jobs present different requirements than those that specify long-running jobs, even though both situations are considered \"compute focused.\""
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:19(para)
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 consistently performant. This process is important because, when a service becomes a critical part of a user's infrastructure, the user's fate becomes wedded to the SLAs of the cloud itself. In cloud computing, a service's performance will not be measured by its average speed but rather by the consistency of its speed."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:29(para)
msgid "There are two aspects of capacity planning to consider: planning the initial deployment footprint, and planning expansion of it to stay ahead of the demands of cloud users."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:33(para)
msgid "Planning the initial footprint for an OpenStack deployment is typically done based on existing infrastructure workloads and estimates based on expected uptake."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:36(para)
msgid "The starting point is the core count of the cloud. By applying relevant ratios, the user can gather information about:"
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:41(para)
msgid "The number of instances expected to be available concurrently: (overcommit fraction × cores) / virtual cores per instance"
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:46(para)
msgid "How much storage is required: flavor disk size × number of instances"
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:50(para)
msgid "These ratios can be used to 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 ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:58(para)
msgid "1600 = (16 (number of physical cores)) / 2"
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:61(para)
msgid "storage required = 50GB 1600"
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:64(para)
msgid "On the surface, the equations reveal the need for 200 physical cores and 80TB 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 ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:71(para)
msgid "Consider, for example, the differences between a cloud that supports a managed web-hosting platform with one running integration tests for a development project that creates one instance per code commit. In the former, the heavy work of creating an instance happens only every few months, whereas the latter puts constant heavy load on the cloud controller. The average instance lifetime must be considered, as a larger number generally means less load on the cloud controller."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:80(para)
msgid "Aside from the creation and termination of instances, the impact of users must be considered when accessing the service, particularly on nova-api and its associated database. Listing instances garners 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 ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:90(para)
msgid "Consideration of these factors can help determine how many cloud controller cores are required. A server with 8 CPU cores and 8 GB of RAM server would be sufficient for up to a rack of compute nodes, given the above caveats."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:94(para)
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 ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:100(para)
msgid "The cloud resource calculator is a useful tool in examining the impacts of different hardware and instance load outs. It is available at: <link href=\"https://github.com/noslzzp/cloud-resource-calculator/blob/master/cloud-resource-calculator.ods\">https://github.com/noslzzp/cloud-resource-calculator/blob/master/cloud-resource-calculator.ods</link>"
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:105(title)
msgid "Expansion planning"
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:106(para)
msgid "A key challenge faced when planning the expansion of cloud compute services is the elastic nature of cloud infrastructure demands. Previously, new users or customers would be forced to plan for and request the infrastructure they required ahead of time, allowing time for reactive procurement processes. Cloud computing users have come to expect the agility provided by having instant access to new resources as they are required. Consequently, this means planning should be delivered for typical usage, but also more importantly, for sudden bursts in usage."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:116(para)
msgid "Planning for expansion can be a delicate 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 underutilization of the cloud and funds spent on operating infrastructure that is not being used efficiently."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:122(para)
msgid "The key is to carefully monitor the spikes and valleys in cloud usage over time. The intent is to measure the consistency with which services can be delivered, not the average speed or capacity of the cloud. Using this information to model performance results in capacity enables users to more accurately determine the current and future capacity of the cloud."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:129(title)
msgid "CPU and RAM"
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:130(para)
msgid "(Adapted from: <link href=\"http://docs.openstack.org/openstack-ops/content/compute_nodes.html#cpu_choice\">http://docs.openstack.org/openstack-ops/content/compute_nodes.html#cpu_choice</link>)"
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:132(para)
msgid "In current generations, CPUs have up to 12 cores. If an Intel CPU supports Hyper-Threading, those 12 cores are doubled to 24 cores. If a server is purchased that supports multiple CPUs, the number of cores is further multiplied. Hyper-Threading is Intel's proprietary simultaneous multi-threading implementation, used to improve parallelization on their CPUs. Consider enabling Hyper-Threading to improve the performance of multithreaded applications."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:141(para)
msgid "Whether the user should enable Hyper-Threading on a CPU depends upon the use case. For example, disabling Hyper-Threading can be beneficial in intense computing environments. Performance testing conducted by running local workloads with both Hyper-Threading on and off can help determine what is more appropriate in any particular case."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:148(para)
msgid "If the Libvirt/KVM hypervisor driver are the intended use cases, then the CPUs used in the compute nodes must support virtualization by way of the VT-x extensions for Intel chips and AMD-v extensions for AMD chips to provide full performance."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:153(para)
msgid "OpenStack enables the user 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 ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:160(para)
msgid "CPU allocation ratio: 16:1"
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:163(para)
msgid "RAM allocation ratio: 1.5:1"
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:166(para)
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 ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:172(para)
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 ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:177(para)
msgid "For example, if a physical node has 48 GB of RAM, the scheduler allocates instances to that node until the sum of the RAM associated with the instances reaches 72 GB (such as nine instances, in the case where each instance has 8 GB of RAM)."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:182(para)
msgid "The appropriate CPU and RAM allocation ratio must be selected based on particular use cases."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:185(title)
msgid "Additional hardware"
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:186(para)
msgid "Certain use cases may benefit from exposure to additional devices on the compute node. Examples might include:"
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:190(para)
msgid "High performance computing jobs that benefit from the availability of graphics processing units (GPUs) for general-purpose computing."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:197(para)
msgid "Cryptographic routines that benefit from the availability of hardware random number generators to avoid entropy starvation."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:202(para)
msgid "Database management systems that benefit from the availability of SSDs for ephemeral storage to maximize read/write time when it is required."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:207(para)
msgid "Host aggregates are used to 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 careful consideration must be given to whether all compute nodes, or just a subset which is targetable using flavors, need the additional customization to support the desired workloads."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:216(para)
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 ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:221(para)
msgid "In order to facilitate packing of virtual machines onto physical hosts, the default selection of flavors are constructed so that the second largest flavor 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. As a result, packing a server for general purpose computing might look conceptually something like this figure: <placeholder-1/>"
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:236(para)
msgid "On the other hand, a CPU optimized packed server might look like the following figure: <placeholder-1/>"
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:245(para)
msgid "These default flavors are well suited to typical load outs for commodity server hardware. To maximize utilization, however, it may be necessary to customize the flavors or create new ones, to better align instance sizes to the available hardware."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:250(para)
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 ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:254(para)
msgid "For more information on Flavors refer to: <link href=\"http://docs.openstack.org/openstack-ops/content/flavors.html\">http://docs.openstack.org/openstack-ops/content/flavors.html</link>"
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:258(para)
msgid "The infrastructure of a cloud should not be shared, so that it is possible for the workloads to consume as many resources as are made available, and accommodations should be made to provide large scale workloads."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:262(para)
msgid "The duration of batch processing differs depending on individual workloads that are launched. Time limits range from seconds, minutes to hours, and as a result it is considered difficult to predict when resources will be used, for how long, and even which resources will be used."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:269(para)
msgid "The security considerations needed for this scenario are similar to those of the other scenarios discussed in this book."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:292(para)
msgid "These security domains can be mapped individually to the installation, or they can also be combined. For example, some deployment topologies combine both guest and data domains onto one physical network, whereas in other cases these networks are physically separated. In each case, the cloud operator should be aware of the appropriate security concerns. Security domains should be mapped out against specific OpenStack deployment topology. The domains and their trust requirements depend upon whether the cloud instance is public, private, or hybrid."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:302(para)
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 the user has no authority. This domain should always be considered untrusted."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:307(para)
msgid "Typically used for compute instance-to-instance traffic, the guest security domain handles compute data generated by instances on the cloud; not services that support the operation of the cloud, for example API calls. Public cloud providers and private cloud providers who do not have stringent controls on instance use or who allow unrestricted Internet access to instances should consider this 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 ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:323(para)
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 there may also be strong availability requirements. The trust level of this network is heavily dependent on deployment decisions and as such we do not assign this any default level of trust."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:331(para)
msgid "When deploying OpenStack in an enterprise as a private cloud it is assumed to be behind a firewall and within the trusted network alongside existing systems. Users of the cloud are typically employees or trusted individuals that are bound by the security requirements set forth by the company. This tends to push most of the security domains towards a more trusted model. However, when deploying OpenStack in a public-facing role, no assumptions can be made and the attack vectors significantly increase. For example, the API endpoints and the software behind it will be vulnerable to potentially hostile entities wanting to gain unauthorized access or prevent access to services. This can result in loss of reputation and must be protected against through auditing and appropriate filtering."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:345(para)
msgid "Consideration must be taken when managing the users of the system, whether it is the operation of public or private clouds. The identity service allows for LDAP to be part of the authentication process, and includes such systems as an OpenStack deployment that may ease user management if integrated into existing systems."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:351(para)
msgid "It is strongly recommended that the API services are placed behind hardware that performs SSL termination. API services transmit user names, passwords, and generated tokens between client machines and API endpoints and therefore must be secured."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:356(para)
msgid "More information on OpenStack Security can be found at <link href=\"http://docs.openstack.org/security-guide/\">http://docs.openstack.org/security-guide/</link>"
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:361(para)
msgid "Due to the nature of the workloads that will be used in this scenario, a number of components will be highly beneficial in a Compute-focused cloud. This includes the typical OpenStack components:"
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:367(para)
msgid "OpenStack Compute (nova)"
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:370(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:522(para)
msgid "OpenStack Image Service (glance)"
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:373(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:506(para)
msgid "OpenStack Identity (keystone)"
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:376(para)
msgid "Also consider several specialized components:"
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:379(para)
msgid "<glossterm>Orchestration</glossterm> module (<glossterm>heat</glossterm>)"
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:383(para)
msgid "It is safe to assume that, given the nature of the applications involved in this scenario, these will be heavily automated deployments. Making use of Orchestration will be highly beneficial in this case. Deploying a batch of instances and running an automated set of tests can be scripted, however it makes sense to use the Orchestration module to handle all these actions."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:392(para)
msgid "Telemetry module (ceilometer)"
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:395(para)
msgid "Telemetry and the alarms it generates are required to support autoscaling of instances using Orchestration. Users that are not using the Orchestration module do not need to deploy the Telemetry module and may choose to use other external solutions to fulfill their metering and monitoring requirements."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:401(para)
msgid "See also: <link href=\"http://docs.openstack.org/openstack-ops/content/logging_monitoring.html\">http://docs.openstack.org/openstack-ops/content/logging_monitoring.html</link>"
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:405(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:519(para)
msgid "OpenStack Block Storage (cinder)"
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:408(para)
msgid "Due to the burst-able nature of the workloads and the applications and instances that will be used for batch processing, this cloud will utilize mainly memory or CPU, so the need for add-on storage to each instance is not a likely requirement. This does not mean that OpenStack Block Storage (cinder) will not be used in the infrastructure, but typically it will not be used as a central component."
msgstr ""
#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:420(para)
msgid "When choosing a networking platform, ensure that it either works with all desired hypervisor and container technologies and their OpenStack drivers, or includes an implementation of an ML2 mechanism driver. Networking platforms that provide ML2 mechanisms drivers can be mixed."
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:78(None)
msgid "@@image: '../figures/Generic_CERN_Example.png'; md5=268e2171493d49ff3cc791071a98b49e"
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:139(None)
msgid "@@image: '../figures/Generic_CERN_Architecture.png'; md5=f5ec57432a0b3bd35efeaa25e84d9947"
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:9(para)
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 ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:13(para)
msgid "As of 2011 CERN operated these two compute centers in Europe with plans to add a third."
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:19(th)
msgid "Data center"
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:19(th)
msgid "Approximate capacity"
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:23(td)
msgid "Geneva, Switzerland"
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:26(para)
msgid "3.5 Mega Watts"
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:27(para)
msgid "91000 cores"
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:28(para)
msgid "120 PB HDD"
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:29(para)
msgid "100 PB Tape"
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:30(para)
msgid "310 TB Memory"
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:35(td)
msgid "Budapest, Hungary"
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:38(para)
msgid "2.5 Mega Watts"
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:39(para)
msgid "20000 cores"
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:40(para)
msgid "6 PB HDD"
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:46(para)
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 an additional data center in 2013 while maintaining the same levels of compute staff."
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:54(para)
msgid "The CERN solution uses <glossterm baseform=\"cell\">cells</glossterm> for segregation of compute resources and to transparently scale between different data centers. This decision meant trading off support for security groups and live migration. In addition some details like flavors needed to be manually replicated across cells. In spite of these drawbacks cells were determined to provide the required scale while exposing a single public API endpoint to users."
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:63(para)
msgid "A compute cell was created for each of the two original data centers and a third was created when a new data center was added in 2013. Each cell contains three availability zones to further segregate compute resources and at least three RabbitMQ message brokers configured to be clustered with mirrored queues for high availability."
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:69(para)
msgid "The API cell, which resides behind a HAProxy load balancer, is located 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 be directed to a specific data center or \"all\" data centers with cell selection determined by cell RAM availability in the latter case."
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:81(para)
msgid "There is also some customization of the filter scheduler that handles placement within the cells:"
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:84(para)
msgid "ImagePropertiesFilter - To provide special handling depending on the guest operating system in use (Linux-based or Windows-based)."
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:88(para)
msgid "ProjectsToAggregateFilter - To provide special handling depending on the project the instance is associated with."
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:92(para)
msgid "default_schedule_zones - Allows the selection of multiple default availability zones, rather than a single default."
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:97(para)
msgid "The MySQL database server in each cell is managed by a central database team and configured in an active/passive configuration with a NetApp storage back end. Backups are performed ever 6 hours."
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:102(title)
msgid "Network architecture"
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:103(para)
msgid "To integrate with existing CERN networking infrastructure customizations were made 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 ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:107(para)
msgid "The driver facilitates selection of a MAC address and IP for new instances based on the compute node the scheduler places the instance on"
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:110(para)
msgid "The driver considers the compute node that the scheduler placed an instance on and then selects a MAC address and IP from the pre-registered list associated with that node in the database. The database is then updated to reflect the instance the addresses were assigned to."
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:116(title)
msgid "Storage architecture"
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:117(para)
msgid "The OpenStack Image Service is deployed in the API cell and configured to expose version 1 (V1) of the API. As a result the image registry is also required. The storage back end in use is a 3 PB Ceph cluster."
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:121(para)
msgid "A small set of \"golden\" Scientific Linux 5 and 6 images are maintained which applications can in turn be placed on using orchestration tools. Puppet is used for instance configuration management and customization but Orchestration deployment is expected."
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:128(para)
msgid "Although direct billing is not required, the Telemetry module is used to perform metering for the purposes of adjusting project quotas. A sharded, replicated, MongoDB back end is used. To spread API load, instances of the nova-api service were deployed within the child cells for Telemetry to query against. This also meant that some supporting services including keystone, glance-api and glance-registry needed to also be configured in the child cells."
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:142(para)
msgid "Additional monitoring tools in use include <link href=\"http://flume.apache.org/\">Flume</link>, <link href=\"http://www.elasticsearch.org/\">Elastic Search</link>, <link href=\"http://www.elasticsearch.org/overview/kibana/\">Kibana</link>, and the CERN developed <link href=\"http://lemon.web.cern.ch/lemon/index.shtml\">Lemon</link> project."
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:154(para)
msgid "The authors of the Architecture Design Guide would like to thank CERN for publicly documenting their OpenStack deployment in these resources, which formed the basis for this chapter:"
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:159(link)
msgid "http://openstack-in-production.blogspot.fr"
msgstr ""
#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:163(link)
msgid "Deep dive into the CERN Cloud Infrastructure"
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/arch-design/specialized/section_hardware_specialized.xml:49(None)
msgid "@@image: '../figures/Specialized_Hardware2.png'; md5=f8477d5d015f4c6d4fcd56d511f14ef9"
msgstr ""
#: ./doc/arch-design/specialized/section_hardware_specialized.xml:8(title)
msgid "Specialized hardware"
msgstr ""
#: ./doc/arch-design/specialized/section_hardware_specialized.xml:9(para)
msgid "Certain workloads require specialized hardware devices that are either difficult to virtualize or impossible to share. 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 ""
#: ./doc/arch-design/specialized/section_hardware_specialized.xml:16(title) ./doc/arch-design/specialized/section_desktop_as_a_service_specialized.xml:22(title) ./doc/arch-design/specialized/section_networking_specialized.xml:15(title) ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:25(title) ./doc/arch-design/specialized/section_software_defined_networking_specialized.xml:19(title)
msgid "Challenges"
msgstr ""
#: ./doc/arch-design/specialized/section_hardware_specialized.xml:17(para)
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. OpenStack has ways of providing some of these, while others may need extra work."
msgstr ""
#: ./doc/arch-design/specialized/section_hardware_specialized.xml:26(title)
msgid "Solutions"
msgstr ""
#: ./doc/arch-design/specialized/section_hardware_specialized.xml:27(para)
msgid "In order to provide cryptography offloading to a set of instances, it is possible to use Image Service configuration options to assign the cryptography chip to a device node in the guest. The <citetitle>OpenStack Command Line Reference</citetitle> contains further information on configuring this solution in the chapter <link href=\"http://docs.openstack.org/cli-reference/content/chapter_cli-glance-property.html\">Image Service property keys</link> , but it allows all guests using the configured images to access the hypervisor cryptography device."
msgstr ""
#: ./doc/arch-design/specialized/section_hardware_specialized.xml:37(para)
msgid "If direct access to a specific device is required, it can be dedicated to a single instance per hypervisor through the use of PCI pass-through. The OpenStack administrator needs to define a flavor that specifically has the PCI device in order to properly schedule instances. More information regarding PCI pass-through, including instructions for implementing and using it, is available at <link href=\"https://wiki.openstack.org/wiki/Pci_passthrough#How_to_check_PCI_status_with_PCI_api_patches\"> https://wiki.openstack.org/wiki/Pci_passthrough</link>."
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/arch-design/specialized/section_multi_hypervisor_specialized.xml:26(None)
msgid "@@image: '../figures/Compute_NSX.png'; md5=1745487faf16b74b13f80ffd837f43a0"
msgstr ""
#: ./doc/arch-design/specialized/section_multi_hypervisor_specialized.xml:8(title)
msgid "Multi-hypervisor example"
msgstr ""
#: ./doc/arch-design/specialized/section_multi_hypervisor_specialized.xml:9(para)
msgid "A financial company requires a migration of its applications from a traditional virtualized environment to an API driven, orchestrated environment. A number of their applications have strict support requirements which limit what hypervisors they are supported on, however the rest do not have such restrictions and do not need the same features. Because of these requirements, the overall target environment needs multiple hypervisors."
msgstr ""
#: ./doc/arch-design/specialized/section_multi_hypervisor_specialized.xml:17(para)
msgid "The current environment consists of a vSphere environment with 20 VMware ESXi hypervisors supporting 300 instances of various sizes. Approximately 50 of the instances must be run on ESXi but the rest have more flexible requirements."
msgstr ""
#: ./doc/arch-design/specialized/section_multi_hypervisor_specialized.xml:21(para)
msgid "The company has decided to bring the management of the overall system into a common platform provided by OpenStack."
msgstr ""
#: ./doc/arch-design/specialized/section_multi_hypervisor_specialized.xml:29(para)
msgid "The approach is to run a host aggregate consisting of KVM hypervisors for the general purpose instances and a separate host aggregate for instances requiring ESXi. This way, workloads that must be run on ESXi can be targeted at those hypervisors, but the rest can be targeted at the KVM hypervisors."
msgstr ""
#: ./doc/arch-design/specialized/section_multi_hypervisor_specialized.xml:35(para)
msgid "Images in the OpenStack Image Service have particular hypervisor metadata attached so that when a user requests a certain image, the instance will spawn on the relevant aggregate. Images for ESXi are stored in VMDK format. QEMU disk images can be converted to VMDK, VMFS Flat Disks, which includes thin, thick, zeroed-thick, and eager-zeroed-thick. Note that once a VMFS thin disk is exported from VMFS to a non-VMFS location, like the OpenStack Image Service, it becomes a preallocated flat disk. This impacts the transfer time from the OpenStack Image Service to the data store when the full preallocated flat disk, rather than the thin disk, must be transferred."
msgstr ""
#: ./doc/arch-design/specialized/section_multi_hypervisor_specialized.xml:47(para)
msgid "This example has the additional complication that, rather than being spawned directly on a hypervisor simply by calling a specific host aggregate using the metadata of the image, the VMware host aggregate compute nodes communicate with vCenter which then requests that the instance be scheduled to run on an ESXi hypervisor. As of the Icehouse release, this functionality requires that VMware Distributed Resource Scheduler (DRS) be enabled on a cluster and set to \"Fully Automated\"."
msgstr ""
#: ./doc/arch-design/specialized/section_multi_hypervisor_specialized.xml:56(para)
msgid "Due to the DRS requirement, note that vSphere requires shared storage (DRS uses vMotion, which requires shared storage). The solution uses shared storage to provide Block Storage capabilities to the KVM instances while also providing the storage for vSphere. The environment uses a dedicated data network to provide this functionality, therefore the compute hosts should have dedicated NICs to support this dedicated traffic. vSphere supports the use of OpenStack Block Storage to present storage from a VMFS datastore to an instance, so the use of Block Storage in this architecture supports both hypervisors."
msgstr ""
#: ./doc/arch-design/specialized/section_multi_hypervisor_specialized.xml:67(para)
msgid "In this case, network connectivity is provided by OpenStack Networking with the VMware NSX plug-in driver configured. Alternatively, the system could use legacy networking (nova-network), which is supported by both hypervisors used in this design, but has limitations. Specifically, security groups are not supported on vSphere with legacy networking. With VMware NSX as part of the design, however, when a user launches an instance within either of the host aggregates, the instances are attached to appropriate network overlay-based logical networks as defined by the user."
msgstr ""
#: ./doc/arch-design/specialized/section_multi_hypervisor_specialized.xml:77(para)
msgid "Note that care must be taken with this approach, as there are design considerations around the OpenStack Compute integration. When using vSphere with OpenStack, the nova-compute service that is configured to communicate with vCenter shows up as a single large hypervisor representing the entire ESXi cluster (multiple instances of nova-compute can be run to represent multiple ESXi clusters or to connect to multiple vCenter servers). If the process running the nova-compute service crashes, the connection to that particular vCenter Server-and any ESXi clusters behind it-are severed and it will not be possible to provision more instances on that vCenter, despite the fact that vSphere itself could be configured for high availability. Therefore, it is important to monitor the nova-compute service that connects to vSphere for any disruptions."
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/arch-design/specialized/section_desktop_as_a_service_specialized.xml:65(None)
msgid "@@image: '../figures/Specialized_VDI1.png'; md5=77729426d59881476de9a03e1ee8a22c"
msgstr ""
#: ./doc/arch-design/specialized/section_desktop_as_a_service_specialized.xml:8(title)
msgid "Desktop-as-a-Service"
msgstr ""
#: ./doc/arch-design/specialized/section_desktop_as_a_service_specialized.xml:9(para)
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 environments have not been put on cloud environments because few clouds are built to support such a demanding workload that is so exposed to end users. Recently, as cloud environments become more robust, vendors are starting to provide services that allow virtual desktops to be hosted in the cloud. In the not too distant future, OpenStack could be used as the underlying infrastructure to run a virtual infrastructure environment, either in-house or in the cloud."
msgstr ""
#: ./doc/arch-design/specialized/section_desktop_as_a_service_specialized.xml:23(para)
msgid "Designing an infrastructure that is suitable to host virtual desktops is a very different task to that of most virtual workloads. The infrastructure will need to be designed, for example:"
msgstr ""
#: ./doc/arch-design/specialized/section_desktop_as_a_service_specialized.xml:29(para)
msgid "Boot storms: What happens when hundreds or thousands of users log in during shift changes, affects the storage design."
msgstr ""
#: ./doc/arch-design/specialized/section_desktop_as_a_service_specialized.xml:34(para)
msgid "The performance of the applications running in these virtual desktops"
msgstr ""
#: ./doc/arch-design/specialized/section_desktop_as_a_service_specialized.xml:38(para)
msgid "Operating system and compatibility with the OpenStack hypervisor"
msgstr ""
#: ./doc/arch-design/specialized/section_desktop_as_a_service_specialized.xml:44(title)
msgid "Broker"
msgstr ""
#: ./doc/arch-design/specialized/section_desktop_as_a_service_specialized.xml:45(para)
msgid "The connection broker is a central component of the architecture that determines which remote desktop host will be assigned or connected to the user. The broker is often a full-blown management product allowing for the automated deployment and provisioning of remote desktop hosts."
msgstr ""
#: ./doc/arch-design/specialized/section_desktop_as_a_service_specialized.xml:52(title) ./doc/arch-design/specialized/section_networking_specialized.xml:23(title) ./doc/arch-design/specialized/section_software_defined_networking_specialized.xml:28(title)
msgid "Possible solutions"
msgstr ""
#: ./doc/arch-design/specialized/section_desktop_as_a_service_specialized.xml:53(para)
msgid "There are a number of commercial products available today that provide such a broker solution but nothing that is native in the OpenStack project. Not providing a broker is also an option, but managing this manually would not suffice as a large scale, enterprise solution."
msgstr ""
#: ./doc/arch-design/specialized/section_desktop_as_a_service_specialized.xml:62(title) ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:76(title) ./doc/arch-design/specialized/section_software_defined_networking_specialized.xml:40(title)
msgid "Diagram"
msgstr ""
#: ./doc/arch-design/specialized/section_networking_specialized.xml:8(title)
msgid "Specialized networking example"
msgstr ""
#: ./doc/arch-design/specialized/section_networking_specialized.xml:9(para)
msgid "Some applications that interact with a network require more 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 layer 2 level."
msgstr ""
#: ./doc/arch-design/specialized/section_networking_specialized.xml:16(para)
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 ""
#: ./doc/arch-design/specialized/section_networking_specialized.xml:24(para)
msgid "Deploying an OpenStack installation using OpenStack Networking with a provider network will allow 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 via an OpenFlow controller. Using the multiple layer-2 plug-in with an agent such as <glossterm>Open vSwitch</glossterm> would allow a private connection through a VLAN directly to a specific port in a layer-3 device. This would allow a BGP point to point link to exist that will join the autonomous system. Avoid using layer-3 plug-ins as they will divide the broadcast domain and prevent router adjacencies from forming."
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:80(None)
msgid "@@image: '../figures/Specialized_OOO.png'; md5=65a8e3666ebf09a0145c61bc1d472144"
msgstr ""
#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:12(title)
msgid "OpenStack on OpenStack"
msgstr ""
#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:13(para)
msgid "In some cases it is necessary to run OpenStack nested on top of another OpenStack cloud. This scenario allows for complete OpenStack cloud environments to be managed and provisioned on instances running on hypervisors and servers controlled by the underlying OpenStack cloud. Public cloud providers can use this technique to effectively manage the upgrade and maintenance process on complete OpenStack-based clouds. Developers and those testing OpenStack can also use the guidance to provision their own OpenStack environments on available OpenStack Compute resources, whether public or private."
msgstr ""
#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:26(para)
msgid "The network aspect of deploying a nested cloud is the most complicated aspect of this architecture. When using VLANs, these will need to be exposed to the physical ports on which the undercloud runs, as the bare metal cloud owns all the hardware, but they also need to be exposed to the nested levels as well. Alternatively, network overlay technologies can be used on the overcloud (the OpenStack cloud running on OpenStack) to provide the required software defined networking for the deployment."
msgstr ""
#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:38(para)
msgid "A key question to address in this scenario is the decision about which approach should be taken to provide a nested hypervisor in OpenStack. This decision influences which operating systems can be used for the deployment of the nested OpenStack deployments."
msgstr ""
#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:45(title)
msgid "Possible solutions: deployment"
msgstr ""
#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:46(para)
msgid "Deployment of a full stack can be challenging but this difficulty can be readily be mitigated by creating a Heat template to deploy the entire stack or a configuration management system. Once the Heat template is created, deploying additional stacks will be a trivial thing and can be performed in an automated fashion."
msgstr ""
#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:52(para)
msgid "The OpenStack-on-OpenStack project (<glossterm>TripleO</glossterm>) addresses this issuecurrently, however, the project does not completely cover nested stacks. For more information, see https://wiki.openstack.org/wiki/TripleO."
msgstr ""
#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:61(title)
msgid "Possible solutions: hypervisor"
msgstr ""
#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:62(para)
msgid "In the case of running TripleO, the underlying OpenStack cloud deploys the Compute nodes as bare-metal. OpenStack would then be deployed on these Compute bare-metal servers with the appropriate hypervisor, such as KVM."
msgstr ""
#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:66(para)
msgid "In the case of running smaller OpenStack clouds for testing purposes, and performance would not be a critical factor, QEMU can be utilized instead. It is also possible to run a KVM hypervisor in an instance (see <link href=\"http://davejingtian.org/2014/03/30/nested-kvm-just-for-fun/\"> http://davejingtian.org/2014/03/30/nested-kvm-just-for-fun/</link>), though this is not a supported configuration, and could be a complex solution for such a use case."
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/arch-design/specialized/section_software_defined_networking_specialized.xml:44(None)
msgid "@@image: '../figures/Special_case_SDN_hosted.png'; md5=93f5e5b90b5aea50d24a098ba80c805d"
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/arch-design/specialized/section_software_defined_networking_specialized.xml:51(None)
msgid "@@image: '../figures/Special_case_SDN_external.png'; md5=12d9e840a0a10a5abcf1a2c1f6f80965"
msgstr ""
#: ./doc/arch-design/specialized/section_software_defined_networking_specialized.xml:8(title)
msgid "Software-defined networking"
msgstr ""
#: ./doc/arch-design/specialized/section_software_defined_networking_specialized.xml:9(para)
msgid "Software-defined networking (SDN) is the separation of the data plane and control plane. SDN has become 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 ""
#: ./doc/arch-design/specialized/section_software_defined_networking_specialized.xml:20(para)
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 or intended OpenStack design and determine where the potential conflict and gaps can be found."
msgstr ""
#: ./doc/arch-design/specialized/section_software_defined_networking_specialized.xml:29(para)
msgid "If an SDN implementation requires layer-2 access because it directly manipulates switches, then running an overlay network or a layer-3 agent may not be advisable. 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 then talk directly to the switch hardware. Alternatively, depending on the external device support, use a tunnel that terminates at the switch hardware itself."
msgstr ""
#: ./doc/arch-design/specialized/section_software_defined_networking_specialized.xml:41(para)
msgid "OpenStack hosted SDN controller: <placeholder-1/>"
msgstr ""
#: ./doc/arch-design/specialized/section_software_defined_networking_specialized.xml:48(para)
msgid "OpenStack participating in an SDN controller network: <placeholder-1/>"
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:9(para)
msgid "Hybrid cloud architectures introduce additional complexities, particularly those that use heterogeneous cloud platforms. As a result, it is important to make sure that design choices match requirements in such a way that the benefits outweigh the inherent additional complexity and risks."
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:15(para)
msgid "Business considerations to make when designing a hybrid cloud deployment include:"
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:21(para)
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 ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:35(para)
msgid "Revenue opportunities vary greatly based on the intent and use case of the cloud. If it is being built as a commercial customer-facing product, consider the drivers for building it over multiple platforms and whether the use of multiple platforms make the design more attractive to target customers, thus enhancing the revenue opportunity."
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:48(para)
msgid "One of the most common reasons to use cloud platforms is to speed the time to market of a new product or application. A business requirement to use multiple cloud platforms may be because there is an existing investment in several applications and it is faster to tie them together rather than migrating components and refactoring to a single platform."
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:59(term)
msgid "Business or technical diversity"
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:61(para)
msgid "Organizations already leveraging cloud-based services may wish to embrace business diversity and utilize a hybrid cloud design to spread their workloads across multiple cloud providers so that no application is hosted in a single cloud provider."
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:70(term)
msgid "Application momentum"
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:72(para)
msgid "A business with existing applications that are already in production on multiple cloud environments may find that it is more cost effective to integrate the applications on multiple cloud platforms rather than migrate them to a single platform."
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:102(para) ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:36(para)
msgid "Data compliance policies governing certain types of information needs to reside in certain locations due to regular issues and, more importantly, cannot reside in other locations for the same reason."
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:108(para)
msgid "Examples of such legal frameworks include the data protection framework of the European Union (<link href=\"http://ec.europa.eu/justice/data-protection/\">http://ec.europa.eu/justice/data-protection/</link>) and the requirements of the Financial Industry Regulatory Authority (<link href=\"http://www.finra.org/Industry/Regulation/FINRARules/\">http://www.finra.org/Industry/Regulation/FINRARules/</link>) in the United States. Consult a local regulatory body for more information."
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:118(title)
msgid "Workload considerations"
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:119(para)
msgid "Defining what the word \"workload\" means in the context of a hybrid cloud environment is important. Workload can be defined as the intended way the systems will be utilized, which is often referred to as a \"use case\". A workload can be a single application or a suite of applications that work in concert. 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 will often need 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 ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:131(para)
msgid "Some possible use cases for a hybrid cloud architecture include:"
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:135(para)
msgid "Dynamic resource expansion or \"bursting\": Another common reason to use a multiple cloud architecture is a \"bursty\" application that needs additional resources at times. An example of this case could be a retailer that needs additional resources during the holiday selling season, but does not want to build expensive cloud resources to meet the peak demand. They might have an OpenStack private cloud but want to burst to AWS or some other public cloud for these peak load periods. These bursts could be for long or short cycles ranging from hourly, monthly or yearly."
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:148(para)
msgid "Disaster recovery-business continuity: The cheaper storage and instance management makes a good case for using the cloud as a secondary site. The public cloud is already heavily used for these purposes in combination with an OpenStack public or private cloud."
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:156(para)
msgid "Federated hypervisor-instance management: Adding self-service, charge back and transparent delivery of the right 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 ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:165(para)
msgid "Application portfolio integration: An enterprise cloud delivers better application portfolio management and more efficient deployment by leveraging self-service features and rules for deployments based on types of use. A common driver for building hybrid cloud architecture is to stitch together multiple existing cloud environments that are already in production or development."
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:179(para)
msgid "Migration scenarios: A common reason to create a hybrid cloud architecture is to allow the migration of applications between different clouds. This may be because the application will be migrated permanently to a new platform, or it might be because the application needs to be supported on multiple platforms going forward."
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:188(para)
msgid "High availability: Another important reason for wanting a multiple cloud architecture is to address the needs for high availability. By using a combination of multiple locations and platforms, a design can achieve a level of availability that is not possible with a single platform. This approach does add a significant amount of complexity."
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:197(para)
msgid "In addition to thinking about how the workload will work on a single cloud, the design must accommodate the added complexity of needing the workload to run on multiple cloud platforms. The complexity of transferring workloads across clouds needs to be explored at the application, instance, cloud platform, hypervisor, and network levels."
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:204(title)
msgid "Tools considerations"
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:205(para)
msgid "When working with designs spanning multiple clouds, the design must incorporate tools to facilitate working across those multiple clouds. Some of the user requirements drive the need for tools that will do the following functions:"
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:211(para)
msgid "Broker between clouds: Since the multiple cloud architecture assumes that there will be at least two different and possibly incompatible platforms that are likely to have different costs, brokering software is designed to evaluate relative costs between different cloud platforms. These solutions are sometimes referred to as Cloud Management Platforms (CMPs). Examples include Rightscale, Gravitent, Scalr, CloudForms, and ManageIQ. These tools allow the designer to determine the right location for the workload based on predetermined criteria."
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:224(para)
msgid "Facilitate orchestration across the clouds: CMPs are tools are used to tie everything together. Cloud orchestration tools are used to improve the management of IT application portfolios as they migrate onto public, private, and hybrid cloud platforms. These tools are an important consideration. Cloud orchestration tools are used for managing a diverse portfolio of installed systems across multiple cloud platforms. The typical enterprise IT application portfolio is still comprised of a few thousand applications scattered over legacy hardware, virtualized infrastructure, and now dozens of disjointed shadow public Infrastructure-as-a-Service (IaaS) and Software-as-a-Service (SaaS) providers and offerings."
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:242(title)
msgid "Network considerations"
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:243(para)
msgid "The network services functionality is an important factor to assess when choosing a CMP and cloud provider. Considerations are functionality, security, scalability and HA. Verification and ongoing testing of the critical features of the cloud endpoint used by the architecture are important tasks."
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:250(para)
msgid "Once the network functionality framework has been decided, a minimum functionality test should be designed. This will ensure testing and functionality persists during and after upgrades."
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:256(para)
msgid "Scalability across multiple cloud providers may dictate which underlying network framework you will choose in different cloud providers. It is important to have the network API functions presented and to verify that functionality persists across all cloud endpoints chosen."
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:264(para)
msgid "High availability implementations vary in functionality and design. Examples of some common methods are active-hot-standby, active-passive and active-active. High availability and a test framework needs to be developed to insure that the functionality and limitations are well understood."
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:272(para)
msgid "Security considerations include how data is secured between client and endpoint and any traffic that traverses the multiple clouds, from eavesdropping to DoS activities."
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:279(title)
msgid "Risk mitigation and management considerations"
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:281(para)
msgid "Hybrid cloud architectures introduce additional risk because they add additional complexity and potentially conflicting or incompatible components or tools. However, they also reduce risk by spreading workloads over multiple providers. This means, if one was to go out of business, the organization could remain operational."
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:287(para)
msgid "Risks that will be heightened by using a hybrid cloud architecture include:"
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:291(term)
msgid "Provider availability or implementation details"
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:293(para)
msgid "This can range from the company going out of business to the company changing how it delivers its services. Cloud architectures are inherently designed to be flexible and changeable; paradoxically, the cloud is both perceived to be rock solid and ever flexible at the same time."
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:303(term)
msgid "Differing SLAs"
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:305(para)
msgid "Users of hybrid cloud environments potentially encounter some losses through differences in service level agreements. A hybrid cloud design needs to accommodate the different SLAs provided by the various clouds involved in the design, and must address the actual enforceability of the providers' SLAs."
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:315(term)
msgid "Security levels"
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:317(para)
msgid "Securing multiple cloud environments is more complex than securing a single cloud environment. Concerns need to be addressed at, but not limited to, the application, network, and cloud platform levels. One issue is that different cloud platforms approach security differently, and a hybrid cloud design must address and compensate for differences in security approaches. For example, AWS uses a relatively simple model that relies on user privilege combined with firewalls."
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:330(term)
msgid "Provider API changes"
msgstr ""
#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:332(para)
msgid "APIs are crucial in a hybrid cloud environment. As a consumer of a provider's cloud services, an organization will rarely have any control over provider changes to APIs. Cloud services that might have previously had compatible APIs may no longer work. This is particularly a problem with AWS and OpenStack AWS-compatible APIs. OpenStack was originally planned to maintain compatibility with changes in AWS APIs. However, over time, the APIs have become more divergent in functionality. One way to address this issue is to focus on using only the most common and basic APIs to minimize potential conflicts."
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:24(None) ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:88(None)
msgid "@@image: '../figures/Multi-Cloud_Priv-AWS4.png'; md5=3bba96b0b6ac0341a05581b00160ff17"
msgstr ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:9(para)
msgid "As a first step, map out the dependencies of the expected workloads and the cloud infrastructures that are required to support them. Mapping the applications to targeted cloud environments allows you to architect a solution for the broadest compatibility between cloud platforms, minimizing the need to create workarounds and processes to fill identified gaps."
msgstr ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:17(para)
msgid "For your chosen cloud management platform, note the relative levels of support for both monitoring and orchestration."
msgstr ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:29(title)
msgid "Image portability"
msgstr ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:30(para)
msgid "The majority of cloud workloads currently run on instances using hypervisor technologies such as KVM, Xen, or ESXi. The challenge is that each of these hypervisors uses an image format that may or may not be compatible with one another. Mitigation in a private or hybrid cloud solution can be standardized on the same hypervisor and instance image format. However this is not always feasible. This is particularly evident if one of the clouds in the architecture is a public cloud that is outside of the control of the designers."
msgstr ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:40(para)
msgid "Examples of available conversion tools:"
msgstr ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:44(link)
msgid "virt-p2v and virt-v2v"
msgstr ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:49(link)
msgid "virt-edit - Edit a file in a virtual machine"
msgstr ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:54(para)
msgid "The listed tools cannot serve beyond basic cloud instance specifications. 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. Use a commercial image migration tool as another option. If you intend to use the portable images for disaster recovery, application diversity, or high availability, your users could move the images and instances between cloud platforms regularly."
msgstr ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:67(title)
msgid "Upper-layer services"
msgstr ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:68(para)
msgid "Many clouds offer complementary services over and above the basic compute, network, and storage components. These additional services are often used to simplify the deployment and management of applications on a cloud platform."
msgstr ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:72(para)
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 ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:76(para)
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 ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:79(para)
msgid "There are a number of options that are appropriate for the hybrid cloud use case:"
msgstr ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:83(para)
msgid "Creating a baseline of upper-layer services that are implemented 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 ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:88(para)
msgid "For example, through the <glossterm>Database Service</glossterm> for OpenStack (<glossterm>trove</glossterm>), OpenStack supports MySQL as a service but not NoSQL databases in production. To either move from or run alongside AWS, a NoSQL workload must use an automation tool, such as the Orchestration module (heat), to recreate the NoSQL database on top of OpenStack."
msgstr ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:98(para)
msgid "Deploying a <glossterm>Platform-as-a-Service (PaaS)</glossterm> technology such as Cloud Foundry or OpenShift 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 ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:107(para)
msgid "Use automation tools to create the required upper-layer services that are portable across all cloud platforms."
msgstr ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:109(para)
msgid "For example, instead of using any database services that are inherent in the cloud platforms, launch cloud instances and deploy the databases on those instances using scripts or various configuration and application deployment tools."
msgstr ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:119(title)
msgid "Network services"
msgstr ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:120(para)
msgid "Network services functionality is a barrier for multiple cloud architectures. It could be an important factor to assess when choosing a CMP and cloud provider. Some considerations you should take into account:"
msgstr ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:127(para)
msgid "Functionality"
msgstr ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:142(para)
msgid "High availability (HA)"
msgstr ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:147(para)
msgid "Verify and test critical cloud endpoint features."
msgstr ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:150(para)
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 ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:155(para)
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 ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:161(para)
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 ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:168(para)
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 ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:176(para)
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."
msgstr ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:187(para)
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 ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:194(para)
msgid "Organizations must find the right balance between data integrity and data availability. Replication strategy may also influence the disaster recovery methods."
msgstr ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:197(para)
msgid "Replication across different racks, data centers, and geographical regions has led to the increased focus of 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, for example, Hadoop running in a cloud. The user either runs with a native HDF or on a separate parallel file system. Examples would be Hitachi and IBM."
msgstr ""
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:206(para)
msgid "Take special consideration when running embedded object store methods to not cause extra data replication, which can create unnecessary performance issues."
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:49(None)
msgid "@@image: '../figures/Multi-Cloud_Priv-Pub3.png'; md5=8fdb44f876665e2aa1bd793607c4537e"
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:129(None)
msgid "@@image: '../figures/Multi-Cloud_failover2.png'; md5=5a7be4a15d381288659c7268dff6724b"
msgstr ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:9(para)
msgid "Multi-cloud environments are designed for these use cases:"
msgstr ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:13(para)
msgid "Bursting workloads from private to public OpenStack clouds"
msgstr ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:17(para)
msgid "Bursting workloads from private to public non-OpenStack clouds"
msgstr ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:21(para)
msgid "High availability across clouds (for technical diversity)"
msgstr ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:25(para)
msgid "This chapter discusses examples of environments that address each of these use cases."
msgstr ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:27(para)
msgid "Company A's data center is running dangerously low on capacity. The option of expanding the data center will not be possible in the foreseeable future. In order to accommodate the continuously growing need for development resources in the organisation, Company A decided to use resources in the public cloud."
msgstr ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:33(para)
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 ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:36(para)
msgid "The company has an internal cloud management platform that will direct requests to the appropriate cloud, depending on the local capacity."
msgstr ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:40(para)
msgid "This is a custom in-house application written for this specific purpose."
msgstr ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:43(para)
msgid "This solution is described in the figure below."
msgstr ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:52(para)
msgid "This example shows two clouds, with a Cloud Management Platform (CMP) connecting them."
msgstr ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:55(para)
msgid "This guide does not attempt to cover a specific CMP, but describes how the Orchestration and Telemetry services handle, manage, and control workloads. This is shown in the diagram above."
msgstr ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:60(para)
msgid "The private OpenStack cloud has at least one controller, and at least one compute node. It includes metering provided by the Telemetry module. The Telemetry module 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 ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:71(para)
msgid "In this example, \"Company A\" decided not to direct the deployment to an external public cloud over concerns regarding resource control, security, and increase operational expense"
msgstr ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:77(title)
msgid "Bursting to a public non-OpenStack cloud"
msgstr ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:78(para)
msgid "The second example looks into bursting workloads from the private cloud into a non-OpenStack public cloud using Amazon Web Services (AWS) to take advantage of additional capacity and scale applications."
msgstr ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:82(para)
msgid "For an OpenStack-to-AWS hybrid cloud, the architecture looks similar to the figure below:"
msgstr ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:91(para)
msgid "Company B states that the developers were already using AWS and did not want to change the cloud provider."
msgstr ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:94(para)
msgid "If the CMP is capable of connecting an external cloud provider with the appropriate API, the workflow process will remain 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 will perform actions in the public cloud using applicable API calls."
msgstr ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:100(para)
msgid "If the public cloud is AWS, the CMP would use the EC2 API to create a new instance and assign an Elastic IP. That IP can then be added to HAProxy in the private cloud. The CMP can also reference AWS-specific tools such as CloudWatch and CloudFormation."
msgstr ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:105(para)
msgid "Several open source tool kits for building CMPs are available and can handle this kind of translation. This includes ManageIQ, jClouds, and JumpGate."
msgstr ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:111(title)
msgid "High availability/disaster recovery"
msgstr ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:112(para)
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 is designed to support the failure of large components of the system, yet ensuring that the system will continue to deliver services. While the services remain available to users, the failed components are restored in the background based on standard best practice DR policies. To achieve the objectives, data is replicated to a second cloud, in a geographically distant location. The logical diagram of the system is described in the figure below:"
msgstr ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:132(para)
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 is so that the data is available to the users at all times. The details of the method for protecting each of these sources of data differs."
msgstr ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:140(para)
msgid "Object Storage relies on the replication capabilities of the Object Storage provider. OpenStack Object Storage is enabled so that it creates geographically separated replicas that take advantage of this feature. It is configured so that at least one replica exists in each cloud. In order to make this work, a single array spanning both clouds is configured with OpenStack Identity. Using Federated Identity, it talks to both clouds, communicating with OpenStack Object Storage through the Swift proxy."
msgstr ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:149(para)
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. The 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: <link href=\"https://blueprints.launchpad.net/cinder/+spec/cinder-backup-volume-metadata-support\"> https://blueprints.launchpad.net/cinder/+spec/cinder-backup-volume-metadata-support</link>."
msgstr ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:164(para)
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 was done by creating volumes through the CMP. The CMP knows to create identical volumes in both clouds. Once this is configured, a solution, involving DRDB, is used to synchronize the actual physical drives."
msgstr ""
#: ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:171(para)
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 was not an option. It was decided 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 just as any other Block Storage."
msgstr ""
#: ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:9(para)
msgid "Hybrid cloud deployments present complex operational challenges. There are several factors to consider that affect the way each cloud is deployed and how users and operators will interact with each cloud. Each cloud provider implements infrastructure components differently. This can lead to incompatible interactions with workloads, or a specific Cloud Management Platform (CMP). Different cloud providers may also offer different levels of integration with competing cloud offerings."
msgstr ""
#: ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:18(para)
msgid "Monitoring is an important aspect to consider when selecting a CMP. Gaining valuable insight into each cloud is critical to gaining a holistic view of all involved clouds. It is vital to determine whether an existing CMP supports monitoring of all the clouds involved, or if compatible APIs are available to be queried for necessary information. Gather all the information about each cloud, you can now take appropriate actions on the offline data to avoid impacting workloads."
msgstr ""
#: ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:28(title)
msgid "Agility"
msgstr ""
#: ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:29(para)
msgid "The implemention of a hybrid cloud solution provides 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 quickly spin up new instances in the case of capacity issues or complete unavailability of a single cloud installation."
msgstr ""
#: ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:40(para)
msgid "It is important to understand the type of application workload that is to be deployed across a hybrid cloud environment. Enterprise workloads that depend on the underlying infrastructure for availability are not designed to run on OpenStack. Although these types of applications can run on an OpenStack cloud, if the application is not able to tolerate infrastructure failures, it is likely to require significant operator intervention to recover. However, cloud workloads are designed to handle fault tolerance. The SLA of the application is not tied to the underlying infrastructure. Ideally, cloud applications are designed to recover when entire racks and even data centers full of infrastructure experience an outage."
msgstr ""
#: ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:57(para)
msgid "If the deployment includes a public cloud, predicting upgrades may not be possible. Examine the advertised SLA for any public cloud provider being used."
msgstr ""
#: ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:61(para)
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 at short notice."
msgstr ""
#: ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:66(para)
msgid "When upgrading private cloud deployments, care must be taken to 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 ""
#: ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:71(para)
msgid "Upgrades to the CMP may need to be completed in coordination with any of the hybrid cloud upgrades. This is necessary whenever API changes are made."
msgstr ""
#: ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:77(title)
msgid "Network Operation Center"
msgstr ""
#: ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:78(para)
msgid "It is important to recognize control over infrastructure particulates 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, situations of conflict may arise in which multiple providers have differing points of view on the way infrastructure must be managed and exposed. This can lead to delays in root cause and analysis where each insists the blame lies with the other provider."
msgstr ""
#: ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:89(para)
msgid "It is important to ensure that the structure put in place enables connection of the networking of both clouds to form an 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 ""
#: ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:98(title)
msgid "Maintainability"
msgstr ""
#: ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:99(para)
msgid "Operating hybrid clouds is a situation in which there is a greater reliance on third party systems and processes. As a result of a lack of control of various pieces of a hybrid cloud environment, it is not possible to guarantee proper maintenance of the overall system. Instead, the user must be prepared to abandon workloads and spin them up again in an improved state. Having a hybrid cloud deployment does, however, provide agility for these situations by allowing the migration of workloads to alternative clouds in response to cloud-specific issues."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:13(para)
msgid "A hybrid cloud environment requires inspection and understanding of technical issues that are not only outside of an organization's data center, but potentially outside of an organization's control. In many cases, it is necessary to ensure that the architecture and CMP chosen are adaptable. All of these factors influence and add complexity to the design of the hybrid cloud architecture."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:20(para)
msgid "Incompatibilities with other cloud platforms are inevitable, however, clouds using the same version and distribution of OpenStack are unlikely to experience any issues."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:23(para)
msgid "Clouds that exclusively use the same versions of OpenStack should have no issues, regardless of distribution. The newer the distribution in question, the less likely it is that there will be incompatibilities between versions. An OpenStack community initiative defines core functions that need to remain backward compatible between supported versions."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:30(para)
msgid "For example, the DefCore initiative defines basic functions that every distribution must support in order to bear the name <productname>OpenStack</productname>."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:34(para)
msgid "Vendors can add proprietary customization to their distributions. If an application or architecture makes use of these features, it will be difficult to migrate to or use other types of environments."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:38(para)
msgid "Anyone planning to use older versions of OpenStack prior to Havana should consider carefully before attempting to incorporate functionality between versions. Internal differences in older versions may be so great that the best approach might be to consider the versions to be essentially diverse platforms, as different as OpenStack is from Amazon Web Services or Microsoft Azure."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:45(para)
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 implementation of services. Some situations in which these incompatibilities can arise include differences between the way in which a cloud:"
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:52(para)
msgid "Deploys instances"
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:55(para)
msgid "Manages networks"
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:58(para)
msgid "Treats applications"
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:61(para)
msgid "Implements services"
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:67(para)
msgid "One of the primary reasons many organizations turn to a hybrid cloud system is to increase capacity without having to make large capital investments."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:70(para)
msgid "Capacity, and the placement of workloads, accounts for the design of a mostly internally-operated cloud. The long-term capacity plan for this design must incorporate growth over time to prevent permanent consumption of a more expensive external cloud. In order to avoid this scenario, we recommend accounting for the future applications' capacity requirements and plan growth appropriately."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:78(para)
msgid "Unpredictability is a consideration for capacity planning. It is difficult to predict the amount of load a particular application might incur if the number of users fluctuate, or the application experiences an unexpected increase in popularity. 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 metric or even the same oversubscription rates."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:85(para)
msgid "Oversubscription is a method to emulate more capacity than may physically be present. For example, a physical hypervisor node with 32GB RAM may host 24 instances, each provisioned with 2GB RAM. As long as all 24 instances are not concurrently utilizing 2 full gigabytes, this arrangement is a non-issue. However, some hosts take oversubscription to extremes and, as a result, performance can frequently be inconsistent. If at all possible, determine what the oversubscription rates of each host are and plan capacity accordingly."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:99(para)
msgid "Security domains are an important distinction when planning for a hybrid cloud environment and its capabilities. A security domain comprises users, applications, servers or networks that share common trust requirements and expectations within a system."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:104(para)
msgid "The security domains are:"
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:119(para)
msgid "You can map the security domains individually to the organization's installation or combine them. For example, some deployment topologies combine both guest and data domains onto one physical network, whereas other topologies physically separate the networks. In each case, the cloud operator should be aware of the appropriate security concerns. We recommend mapping security domains against the specific OpenStack deployment topology. The domains and their trust requirements depend upon whether the cloud instance is public, private, or hybrid."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:129(para)
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 an organization has no authority. Do not trust this domain. For example, in a hybrid cloud deployment, any information traversing between and beyond the clouds is of the public domain and untrustworthy."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:135(para)
msgid "The guest security domain handles compute data. Instances on the cloud generate the data, but not services that support the operation of the cloud, such as API calls. We recommend not to trust this domain if you are a public cloud provider that uses hybrid cloud configurations, or a private cloud provider who does not have controls on instance use and allows unrestricted internet access to instances. Private cloud providers, however, can use this network as an internally trusted network if controls are in place."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:143(para)
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 ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:147(para)
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 ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:154(para)
msgid "When operating or utilizing public or private clouds, consider the management of the users. The identity service allows for LDAP to be part of the authentication process. Including these systems in your OpenStack deployments may ease user management if integrating into existing systems."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:160(para)
msgid "Be mindful of consistency when utilizing third party clouds to explore authentication options."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:163(para)
msgid "Due to the passing of user names, passwords, and tokens between client machines and API endpoints, we recommend the placement of API services behind hardware to perform SSL termination."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:166(para)
msgid "The hypervisor also requires a security assessment. In a public cloud, organizations typically do not have control over the choice of hypervisor. For example, Amazon uses its own particular version of Xen. 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 ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:175(para)
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 ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:182(para)
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 ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:191(para)
msgid "It is important to realize that 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 ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:196(para)
msgid "More information on OpenStack Security can be found in the <link href=\"http://docs.openstack.org/security-guide\"><citetitle>OpenStack Security Guide</citetitle></link>."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:205(para)
msgid "When it comes to utilization, it is important that the CMP understands 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. The internal cloud may only be for development and stressing it is undesirable. In most cases, a cost model of various scenarios helps with this decision. However, internal priorities influence this analysis. To improve efficiency, make these decisions programmatically."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:216(para)
msgid "The Telemetry module (ceilometer) provides information on the usage of various OpenStack components. There are two limitations to consider:"
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:221(para)
msgid "If there is to be a large amount of data (for example, if monitoring a large cloud, or a very active one) it is desirable to use a NoSQL back end for Ceilometer, such as MongoDB."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:228(para)
msgid "You must monitor connections to non-OpenStack clouds and report this information to the CMP."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:237(para)
msgid "Performance is of the upmost importance in the design of a cloud. When it comes to a hybrid cloud deployment, many of the same issues for multi-site deployments apply, such as network latency between sites. It is also important to think about the speed at which a workload can be spun up in another cloud, and how to reduce the time necessary to accomplish the task. This may mean moving data closer to applications or applications closer to the data they process, including a grouping functionality so that connections that require low latency take place over a single cloud rather than spanning clouds. This may also mean ensuring that the CMP has the intelligence to know which cloud can most efficiently run which types of workloads."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:250(para)
msgid "As with utilization, native OpenStack tools are available to assist. Ceilometer can measure performance and, if necessary, the Orchestration (heat) module can react to changes in demand by spinning up more resources."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:255(para)
msgid "It is important to note, however, that Orchestration requires special configurations in the client to enable functioning with solution offerings from Amazon Web Services. When dealing with other types of clouds, it is necessary to rely on the features of the CMP."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:265(title)
msgid "Components"
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:266(para)
msgid "The number and types of native OpenStack components that are available for use is dependent on whether the deployment is exclusively an OpenStack cloud or not."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:269(para)
msgid "Using more than one cloud in any situation requires consideration of four OpenStack tools:"
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:273(para)
msgid "OpenStack Compute (nova): Regardless of deployment location, hypervisor choice has a direct effect on how difficult it is to integrate with one or more additional clouds. For example, integrating a Hyper-V based OpenStack cloud with Azure has less compatibility issues than if KVM is used."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:281(para)
msgid "Networking (neutron): Whether OpenStack Networking or legacy networking (nova-network) is used, the network is one place where understanding integration capabilities is necessary in order to connect between clouds."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:287(para)
msgid "Telemetry module (ceilometer): Use of Telemetry depends, in large part, on what the other parts of the cloud are using."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:292(para)
msgid "Orchestration module (heat): Similarly, Orchestration can be a valuable tool in orchestrating tasks a CMP decides are necessary in an OpenStack-based cloud."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:301(title)
msgid "Special considerations"
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:302(para)
msgid "Hybrid cloud deployments also involve two more issues that are not common in other situations:"
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:306(para)
msgid "Image portability: Note that, as of the Icehouse release, there is no single common image format that is usable by all clouds. Conversion or the recreation of images is necessary if porting between clouds. To make things simpler, launch the smallest and simplest images feasible, installing only what is necessary preferably using a deployment manager such as Chef or Puppet. Do not use golden images for speeding up the process. However, if you repeat the deployment of the same images, we recommend utilizing this technique instead of provisioning applications on lighter images each time."
msgstr ""
#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:318(para)
msgid "API differences: Avoid using a hybrid cloud deployment with more than just OpenStack (or with different versions of OpenStack). The APIs need to perform certain functions that are different. The CMP needs to know how to handle all necessary versions. To get around this issue, some implementers build portals to achieve a hybrid cloud environment, but a heavily developer-focused organization may benefit more from a hybrid cloud broker SDK such as jClouds."
msgstr ""
#: ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:9(para)
msgid "More so than other scenarios, 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 the user point of view is distinctly different from that of the cloud operator."
msgstr ""
#: ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:53(para)
msgid "Massively scalable OpenStack clouds have the following user requirements:"
msgstr ""
#: ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:57(para)
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 ""
#: ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:67(para)
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 ""
#: ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:74(para)
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 ""
#: ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:86(para)
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 ""
#: ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:94(title)
msgid "Operator requirements"
msgstr ""
#: ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:95(para)
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 ""
#: ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:102(para)
msgid "First and foremost, everything must be capable of automation. From the deployment of new hardware, compute hardware, storage hardware, or networking hardware, to the installation and configuration of the supporting software, everything must be capable of automation. Manual processes are impractical in a massively scalable OpenStack design architecture."
msgstr ""
#: ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:112(para)
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 <link href=\"http://www.opencompute.org\">http://www.opencompute.org</link>) provide additional information and pointers. To cut costs, many operators sacrifice redundancy. For example, redundant power supplies, redundant network connections, and redundant rack switches."
msgstr ""
#: ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:127(para)
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 ""
#: ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:139(para)
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 ""
#: ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:154(para)
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 for data storage, data placement, and data retention; 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 <xref linkend=\"multi_site\"/> for more details on requirements and considerations for multi-site OpenStack clouds."
msgstr ""
#: ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:169(para)
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 ""
#: ./doc/arch-design/massively_scalable/section_operational_considerations_massively_scalable.xml:9(para)
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 impossible for staff to give each system individual care."
msgstr ""
#: ./doc/arch-design/massively_scalable/section_operational_considerations_massively_scalable.xml:19(para)
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 ""
#: ./doc/arch-design/massively_scalable/section_operational_considerations_massively_scalable.xml:26(para)
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 then quickly 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 ""
#: ./doc/arch-design/massively_scalable/section_operational_considerations_massively_scalable.xml:39(title)
msgid "The bleeding edge"
msgstr ""
#: ./doc/arch-design/massively_scalable/section_operational_considerations_massively_scalable.xml:40(para)
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 ""
#: ./doc/arch-design/massively_scalable/section_operational_considerations_massively_scalable.xml:49(para)
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 ""
#: ./doc/arch-design/massively_scalable/section_operational_considerations_massively_scalable.xml:57(para)
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 ""
#: ./doc/arch-design/massively_scalable/section_operational_considerations_massively_scalable.xml:67(para)
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 ""
#: ./doc/arch-design/massively_scalable/section_operational_considerations_massively_scalable.xml:77(title)
msgid "Growth and capacity planning"
msgstr ""
#: ./doc/arch-design/massively_scalable/section_operational_considerations_massively_scalable.xml:78(para)
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 metrics for compute, network, and storage, along with historical records of these metrics. 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 ""
#: ./doc/arch-design/massively_scalable/section_operational_considerations_massively_scalable.xml:89(title)
msgid "Skills and training"
msgstr ""
#: ./doc/arch-design/massively_scalable/section_operational_considerations_massively_scalable.xml:90(para)
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: <link href=\"http://www.openstack.org/marketplace/training/\">http://www.openstack.org/marketplace/training/</link>."
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/arch-design/massively_scalable/section_tech_considerations_massively_scalable.xml:128(None)
msgid "@@image: '../figures/Massively_Scalable_Cells_+_regions_+_azs.png'; md5=87d08365fefde431d6d055daf17d7d0e"
msgstr ""
#: ./doc/arch-design/massively_scalable/section_tech_considerations_massively_scalable.xml:13(para)
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 ""
#: ./doc/arch-design/massively_scalable/section_tech_considerations_massively_scalable.xml:28(title)
msgid "Infrastructure segregation"
msgstr ""
#: ./doc/arch-design/massively_scalable/section_tech_considerations_massively_scalable.xml:29(para)
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 ""
#: ./doc/arch-design/massively_scalable/section_tech_considerations_massively_scalable.xml:34(para)
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."
msgstr ""
#: ./doc/arch-design/massively_scalable/section_tech_considerations_massively_scalable.xml:43(para)
msgid "Regions segregate completely independent installations linked only by an Identity and Dashboard (optional) installation. Services have separate API endpoints for each region, an 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 ""
#: ./doc/arch-design/massively_scalable/section_tech_considerations_massively_scalable.xml:52(para)
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 ""
#: ./doc/arch-design/massively_scalable/section_tech_considerations_massively_scalable.xml:62(para)
msgid "<glossterm baseform=\"cell\">Cells</glossterm> 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 ""
#: ./doc/arch-design/massively_scalable/section_tech_considerations_massively_scalable.xml:71(para)
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 ""
#: ./doc/arch-design/massively_scalable/section_tech_considerations_massively_scalable.xml:78(para)
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 ""
#: ./doc/arch-design/massively_scalable/section_tech_considerations_massively_scalable.xml:88(title)
msgid "Host aggregates"
msgstr ""
#: ./doc/arch-design/massively_scalable/section_tech_considerations_massively_scalable.xml:89(para)
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 ""
#: ./doc/arch-design/massively_scalable/section_tech_considerations_massively_scalable.xml:101(title)
msgid "Availability zones"
msgstr ""
#: ./doc/arch-design/massively_scalable/section_tech_considerations_massively_scalable.xml:102(para)
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 ""
#: ./doc/arch-design/massively_scalable/section_tech_considerations_massively_scalable.xml:106(para)
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 ""
#: ./doc/arch-design/massively_scalable/section_tech_considerations_massively_scalable.xml:116(title)
msgid "Segregation example"
msgstr ""
#: ./doc/arch-design/massively_scalable/section_tech_considerations_massively_scalable.xml:117(para)
msgid "In this example the cloud is divided into two regions, one for each site, with two availability zones in each based on the power layout of the data centers. 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, 10GbE networks, or GPU cards."
msgstr ""
#: ./doc/arch-design/storage_focus/section_tech_considerations_storage_focus.xml:9(para)
msgid "Some of the key technical considerations that are critical to a storage-focused OpenStack design architecture include:"
msgstr ""
#: ./doc/arch-design/storage_focus/section_tech_considerations_storage_focus.xml:14(term)
msgid "Input-output requirements"
msgstr ""
#: ./doc/arch-design/storage_focus/section_tech_considerations_storage_focus.xml:16(para)
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 life cycle 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 ""
#: ./doc/arch-design/storage_focus/section_tech_considerations_storage_focus.xml:32(term)
msgid "Scale"
msgstr ""
#: ./doc/arch-design/storage_focus/section_tech_considerations_storage_focus.xml:34(para)
msgid "Scaling storage solutions in a storage-focused OpenStack architecture design is driven by initial requirements, including <glossterm>IOPS</glossterm>, 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 ""
#: ./doc/arch-design/storage_focus/section_tech_considerations_storage_focus.xml:49(para)
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, levels of access control are important."
msgstr ""
#: ./doc/arch-design/storage_focus/section_tech_considerations_storage_focus.xml:58(term)
msgid "OpenStack compatibility"
msgstr ""
#: ./doc/arch-design/storage_focus/section_tech_considerations_storage_focus.xml:60(para)
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 ""
#: ./doc/arch-design/storage_focus/section_tech_considerations_storage_focus.xml:71(term)
msgid "Storage management"
msgstr ""
#: ./doc/arch-design/storage_focus/section_tech_considerations_storage_focus.xml:73(para)
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 can not be restored is useless), data valuation-hierarchical storage management, retention strategy, data placement, and workflow automation."
msgstr ""
#: ./doc/arch-design/storage_focus/section_tech_considerations_storage_focus.xml:85(term)
msgid "Data grids"
msgstr ""
#: ./doc/arch-design/storage_focus/section_tech_considerations_storage_focus.xml:87(para)
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 ""
#: ./doc/arch-design/storage_focus/section_tech_considerations_storage_focus.xml:95(para)
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 ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:9(para)
msgid "Operational factors affect the design choices for a general purpose cloud, and operations staff receive tasks regarding the maintenance of cloud environments for larger installations."
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:14(term)
msgid "Maintenance tasks"
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:16(para)
msgid "The storage solution should take into account storage maintenance and the impact on underlying workloads."
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:22(term)
msgid "Reliability and availability"
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:24(para)
msgid "Reliability and availability depend on wide area network availability and on the level of precautions taken by the service provider."
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:31(term)
msgid "Flexibility"
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:33(para)
msgid "Organizations need to have the flexibility to choose between off-premise and on-premise cloud storage options. This concept relies on relevant decision criteria that is complementary to initial direct cost savings potential. For example, continuity of operations, disaster recovery, security, and records retention laws, regulations, and policies."
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:44(para)
msgid "Monitoring and alerting services are vitally important 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 ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:51(para)
msgid "A storage-focused cloud design should include:"
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:54(para)
msgid "Monitoring of physical hardware resources."
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:57(para)
msgid "Monitoring of environmental resources such as temperature and humidity."
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:61(para)
msgid "Monitoring of storage resources such as available storage, memory and CPU."
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:65(para)
msgid "Monitoring of advanced storage performance data to ensure that storage systems are performing as expected."
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:70(para)
msgid "Monitoring of network resources for service disruptions which would affect access to storage."
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:75(para)
msgid "Centralized log collection."
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:78(para)
msgid "Log analytics capabilities."
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:81(para)
msgid "Ticketing system (or integration with a ticketing system) to track issues."
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:85(para)
msgid "Alerting and notification of responsible teams or automated systems which remediate problems with storage as they arise."
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:90(para)
msgid "Network Operations Center (NOC) staffed and always available to resolve issues."
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:96(title)
msgid "Management efficiency"
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:97(para)
msgid "Operations personnel are often required to replace failed drives or nodes and provide ongoing maintenance of the storage hardware."
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:99(para)
msgid "Provisioning and configuration of new or upgraded storage is another important consideration when it comes to management of resources. The ability to easily deploy, configure, and manage storage hardware results in a solution that is easy to manage. This also makes use of management systems that can automate other pieces of the overall solution. For example, replication, retention, data backup and recovery."
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:109(title)
msgid "Application awareness"
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:110(para)
msgid "Well-designed applications should be aware of underlying storage subsystems, in order to use cloud storage solutions effectively."
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:112(para)
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 ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:124(title)
msgid "Fault tolerance and availability"
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:125(para)
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. The Object Storage service design features consistency and partition tolerance as a function of the application. Therefore, it does not have any reliance on hardware RAID controllers to provide redundancy for physical disks."
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:134(title)
msgid "Block Storage fault tolerance and availability"
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:135(para)
msgid "Block Storage resource nodes are commonly configured with advanced RAID controllers and high performance disks to provide fault tolerance at the hardware level."
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:138(para)
msgid "Deploy high performing storage solutions such as SSD disk drives or flash storage systems in cases where applications require extreme performance out of Block Storage devices."
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:141(para)
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 ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:156(para)
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. A number of highly available database solutions such as Galera and MariaDB can be leveraged to help keep database services online to provide uninterrupted access so that tenants can manage Block Storage volumes."
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:172(para)
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 ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:183(title)
msgid "Object Storage fault tolerance and availability"
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:184(para)
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 ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:192(para)
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 5. 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 ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:202(para)
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 ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:215(para)
msgid "A zone within an Object Storage cluster is a logical division. Any of the following may represent a zone:"
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:219(para)
msgid "A disk within a single node"
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:224(para)
msgid "One zone per node"
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:229(para)
msgid "Zone per collection of nodes"
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:234(para)
msgid "Multiple racks"
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:239(para)
msgid "Multiple DCs"
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:244(para)
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 ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:255(title)
msgid "Scaling storage services"
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:256(para)
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 ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:263(title)
msgid "Scaling Block Storage"
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:264(para)
msgid "You can upgrade Block Storage pools to add storage capacity without interruption to 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. Once the node is online and available tenants can make use of those storage resources instantly."
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:274(para)
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 ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:286(title)
msgid "Scaling Object Storage"
msgstr ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:287(para)
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 ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:296(para)
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 ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:303(para)
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 ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:309(para)
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 ""
#: ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:322(para)
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 ""
#. When image changes, this message will be marked fuzzy or untranslated for you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:37(None)
msgid "@@image: '../figures/Storage_Object.png'; md5=ad0b4ee39c96ab081a368ef7857479a5"
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:98(None)
msgid "@@image: '../figures/Storage_Hadoop3.png'; md5=bdc6373caede70b37209de260616b255"
msgstr ""
#. When image changes, this message will be marked fuzzy or untranslated for you.
#. It doesn't matter what you translate it to: it's not used at all.
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:131(None)
msgid "@@image: '../figures/Storage_Database_+_Object5.png'; md5=a0cb2374c3515b8f3203ebdc7bb7dbbf"
msgstr ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:9(para)
msgid "Storage-focused architecture highly depends on the specific use case. This section discusses three specific example use cases:"
msgstr ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:14(para)
msgid "An object store with a RESTful interface"
msgstr ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:19(para)
msgid "Compute analytics with parallel file systems"
msgstr ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:24(para)
msgid "High performance database"
msgstr ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:29(para)
msgid "The example below shows a REST interface without a high performance requirement."
msgstr ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:31(para)
msgid "Swift is a highly scalable object store that is part of the OpenStack project. This diagram explains the example architecture: <placeholder-1/>"
msgstr ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:41(para)
msgid "The example REST interface, presented as a traditional Object store running on traditional spindles, does not require a high performance caching tier."
msgstr ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:44(para)
msgid "This example uses the following components:"
msgstr ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:45(para) ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:149(para)
msgid "Network:"
msgstr ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:48(para)
msgid "10 GbE horizontally scalable spine leaf back-end storage and front end network."
msgstr ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:52(para) ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:156(para)
msgid "Storage hardware:"
msgstr ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:55(para)
msgid "10 storage servers each with 12x4 TB disks equaling 480 TB total space with approximately 160 TB of usable space after replicas."
msgstr ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:60(para)
msgid "Proxy:"
msgstr ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:63(para) ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:171(para)
msgid "3x proxies"
msgstr ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:66(para) ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:174(para)
msgid "2x10 GbE bonded front end"
msgstr ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:69(para) ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:177(para)
msgid "2x10 GbE back-end bonds"
msgstr ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:72(para) ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:180(para)
msgid "Approximately 60 Gb of total bandwidth to the back-end storage cluster"
msgstr ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:77(para)
msgid "It may be necessary to implement a 3rd-party caching layer for some applications to achieve suitable performance."
msgstr ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:82(title)
msgid "Compute analytics with Data processing service"
msgstr ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:83(para)
msgid "Analytics of large data sets are highly 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 ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:88(para)
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 ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:92(para)
msgid "OpenStack has integration with Hadoop to manage the Hadoop cluster within the cloud. This diagram shows an OpenStack store with a high performance requirement: <placeholder-1/>"
msgstr ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:102(para)
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 ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:112(title)
msgid "High performance database with Database service"
msgstr ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:113(para)
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 ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:120(para)
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 ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:124(para)
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 ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:134(para)
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 ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:141(para)
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 ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:147(para)
msgid "Using Ceph as an applicable example, a potential architecture would have the following requirements:"
msgstr ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:152(para)
msgid "10 GbE horizontally scalable spine leaf back-end storage and front-end network"
msgstr ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:159(para)
msgid "5 storage servers for caching layer 24x1 TB SSD"
msgstr ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:163(para)
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 ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:168(para)
msgid "REST proxy:"
msgstr ""
#: ./doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml:184(para)
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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:12(para)
msgid "There are three areas to consider when selecting storage hardware:"
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:21(para)
msgid "Reliability"
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:24(para)
msgid "Storage-focused OpenStack clouds must reflect that the workloads are storage intensive. These workloads are not compute intensive, nor are they consistently network intensive. The network may be heavily utilized to transfer storage, but they are not otherwise network intensive."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:29(para)
msgid "For a storage-focused OpenStack design architecture, the selection of storage hardware determines the overall performance and scalability of the design architecture. Several factors impact the design process:"
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:37(para)
msgid "The cost of components affects which storage architecture and hardware you choose."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:44(para)
msgid "The latency of storage I/O requests indicates performance. Performance requirements affect which solution you choose."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:51(para)
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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:63(para)
msgid "Expandability is the overall ability of the solution to grow. A storage solution that expands to 50 PB is more expandable than a solution that only scales to 10 PB."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:67(para)
msgid "This metric is related to scalability."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:73(para)
msgid "Latency is a key consideration in a storage-focused OpenStack cloud. Using solid-state disks (SSDs) to minimize latency for instance storage, and to reduce CPU delays caused by waiting for the storage, increases performance. We recommend evaluating the gains from using RAID controller cards in compute hosts to improve the performance of the underlying disk subsystem."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:81(para)
msgid "The selection of storage architecture determines if a scale-out solution should be used or if a single, highly expandable and scalable centralized storage array would be a better choice. If a centralized storage array is the right fit for the requirements then the array vendor determines the hardware selection. It is possible to build a storage array using commodity hardware with Open Source software, but requires people with expertise to build such a system."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:88(para)
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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:92(para)
msgid "Considerations affecting storage architecture (and corresponding storage hardware) of a Storage-focused OpenStack cloud:"
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:98(para)
msgid "Based on the selected storage solution, ensure the connectivity matches the storage solution requirements. If selecting centralized storage array, determine how the hypervisors connect to the storage array. Connectivity can affect latency and thus performance. We recommended confirming that the network characteristics minimize latency to boost the overall performance of the design."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:111(para)
msgid "Determine if the use case has consistent or highly variable latency."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:118(para)
msgid "Ensure that the storage solution throughput is optimized based on application requirements."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:126(para)
msgid "Use of DAS impacts the server hardware choice and affects host density, instance density, power density, OS-hypervisor, and management tools."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:135(title)
msgid "Compute (server) hardware selection"
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:136(para)
msgid "Evaluate Compute (server) hardware four opposing dimensions:"
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:150(para)
msgid "The number of CPU cores, how much RAM, or how much storage a given server delivers."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:157(para)
msgid "The number of additional resources you can add to a server before it reaches capacity."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:164(para)
msgid "The relative of the hardware weighted against the level of design effort needed to build the system."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:170(para)
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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:178(para)
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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:186(para)
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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:191(para)
msgid "Most blade servers typically 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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:197(para)
msgid "This decreases density by 50% (only 8 servers in 10 U) if a full width or full height option is used."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:203(para)
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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:207(para)
msgid "As of the Icehouse release, neither HP, IBM, nor Dell offered 1U rack servers with more than 2 CPU sockets."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:212(para)
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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:217(para)
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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:224(para)
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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:230(para)
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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:238(para)
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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:242(para)
msgid "For example, many sled servers offer four independent dual-socket nodes in 2U for a total of 8 CPU sockets in 2U. However, the dual-socket limitation on individual nodes may not be sufficient to offset their additional cost and configuration complexity."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:249(para)
msgid "Other factors strongly influence server hardware selection for a storage-focused OpenStack design architecture. The following is a list of these factors:"
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:256(para)
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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:266(para)
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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:277(para)
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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:286(para)
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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:296(title)
msgid "Networking hardware selection"
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:297(para)
msgid "Key considerations for the selection of networking hardware include:"
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:302(para)
msgid "The user requires networking hardware that has the requisite port count."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:309(para)
msgid "The physical space required to provide the requisite port count affects the network design. A switch that provides 48 10GbE ports in 1U has a much higher port density than a switch that provides 24 10GbE 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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:333(para)
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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:338(para)
msgid "If this is a requirement, the hardware must support this configuration. User requirements determine if a completely redundant network infrastructure is required."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:348(para)
msgid "Ensure that the physical data center provides the necessary power for the selected network hardware. This is not typically an issue for top of rack (ToR) switches, but may be an issue for spine switches in a leaf and spine fabric, or end of row (EoR) switches."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:357(term)
msgid "Protocol support"
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:359(para)
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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:371(para)
msgid "Selecting software for a storage-focused OpenStack architecture design includes three areas:"
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:384(para)
msgid "Design decisions made in each of these areas impacts the rest of the OpenStack architecture design."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:390(para)
msgid "Selecting the OS and hypervisor has a significant impact on the overall design and also affects server hardware selection. Ensure that the selected operating system and hypervisor combination support the storage hardware and work with the networking hardware selection and topology. For example, Link Aggregation Control Protocol (LACP) requires support from both the OS and hypervisor."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:397(para)
msgid "OS and hypervisor selection affect the following areas:"
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:402(para)
msgid "Selection of 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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:416(para)
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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:428(para)
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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:439(para)
msgid "Ensure that 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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:450(para)
msgid "Ensure that the design can accommodate the regular periodic installation of application security patches while maintaining the required workloads. The frequency of security patches for the proposed OS-hypervisor combination impacts performance and the patch installation process could affect maintenance windows."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:462(para)
msgid "Determine the required features of OpenStack. This often determines the selection of the OS-hypervisor combination. Certain features are only available with specific OSes or hypervisors. For example, if certain features are not available, you might need to modify the design to meet user requirements."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:474(para)
msgid "Any chosen 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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:489(para)
msgid "Which OpenStack components you choose can have a significant impact on the overall design. While there are certain components that are always present, Compute and Image Service, for example, there are other services that may not need to be present. As an example, a certain design may not require the Orchestration module. Omitting Orchestration would not typically have a significant impact on the overall design, however, if the architecture uses a replacement for OpenStack Object Storage for its storage component, this could potentially have significant impacts on the rest of the design."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:499(para)
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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:502(para)
msgid "A storage-focused OpenStack design architecture typically uses the following components:"
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:509(para)
msgid "OpenStack dashboard (horizon)"
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:512(para)
msgid "OpenStack Compute (nova) (including the use of multiple hypervisor drivers)"
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:516(para)
msgid "OpenStack Object Storage (swift) (or another object storage solution)"
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:525(para)
msgid "OpenStack Networking (neutron) or legacy networking (nova-network)"
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:528(para)
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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:541(para)
msgid "While OpenStack is a fairly complete collection of software projects for building a platform for cloud services, you may need to add other pieces of software."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:548(para)
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 <citetitle>OpenStack High Availability Guide</citetitle> describes some of these software packages, HAProxy in particular. See the <link href=\"http://docs.openstack.org/high-availability-guide/content/ch-network.html\">Network controller cluster stack chapter</link> of the OpenStack High Availability Guide."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:562(para)
msgid "Management software includes software for providing:"
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:565(para)
msgid "Clustering"
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:570(para)
msgid "Logging"
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:580(para)
msgid "Alerting"
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:586(para)
msgid "The factors for determining which software packages in this category to select is outside the scope of this design guide."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:590(para)
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 <citetitle>OpenStack High Availability Guide</citetitle> provides more details on the installation and configuration of Corosync and Pacemaker."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:598(para)
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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:609(para)
msgid "If you require any of these software packages, the design must account for the additional resource consumption (CPU, RAM, storage, and network bandwidth for a log aggregation solution, for example). Some other potential design impacts include:"
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:616(para)
msgid "OS-Hypervisor combination: Ensure that the selected logging, monitoring, or alerting tools support the proposed OS-hypervisor combination."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:630(para)
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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:635(para)
msgid "MySQL is the default database for OpenStack, but other compatible databases are available."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:638(para)
msgid "Telemetry uses MongoDB."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:642(para)
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 ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:650(para)
msgid "Solutions that employ Galera/MariaDB require at least three MySQL nodes."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:654(para)
msgid "MongoDB has its own design considerations for high availability."
msgstr ""
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:658(para)
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 ""
#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:9(para)
msgid "Requirements for data define storage-focused clouds. These include:"
msgstr ""
#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:17(para)
msgid "Access patterns"
msgstr ""
#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:22(para)
msgid "Data structures"
msgstr ""
#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:27(para)
msgid "A balance between cost and user requirements dictate what methods and technologies to use in a cloud architecture."
msgstr ""
#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:33(para)
msgid "The user pays only for the storage they actually use. This limit typically reflects average user consumption during a month. This does not mean that cloud storage is less expensive, only that it incurs operating expenses rather than capital expenses."
msgstr ""
#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:43(para)
msgid "Multiple jurisdictions have legislative and regulatory requirements governing the storage and management of data in cloud environments. Common areas of regulation include data retention policies and data ownership policies."
msgstr ""
#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:69(term)
msgid "Data retention"
msgstr ""
#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:71(para)
msgid "Policies ensuring storage of persistent data and records management to meet data archival requirements."
msgstr ""
#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:77(term)
msgid "Data ownership"
msgstr ""
#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:79(para)
msgid "Policies governing the possession and responsibility for data."
msgstr ""
#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:84(term)
msgid "Data sovereignty"
msgstr ""
#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:86(para)
msgid "Policies governing the storage of data in foreign countries or otherwise separate jurisdictions."
msgstr ""
#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:92(term)
msgid "Data compliance"
msgstr ""
#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:94(para)
msgid "Policies governing types of information that must reside in certain locations due to regulatory issues and cannot reside in other locations for the same reason."
msgstr ""
#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:105(para)
msgid "You can incorporate the following technical requirements into the architecture design:"
msgstr ""
#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:109(term)
msgid "Storage proximity"
msgstr ""
#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:111(para)
msgid "In order to provide high performance or large amounts of storage space, the design may have to accommodate storage that is attached to each hypervisor or served from a central storage device."
msgstr ""
#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:121(para)
msgid "To boost performance, the organization may want to make use of different technologies to cache disk activity."
msgstr ""
#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:129(para)
msgid "Specific requirements regarding availability influence the technology used to store and protect data. These requirements influence cost and the implemented solution."
msgstr ""
#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:138(para)
msgid "You must protect data both in transit and at rest."
msgstr ""
#. Put one translator per line, in the form of NAME <EMAIL>, YEAR1, YEAR2
#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:0(None)
msgid "translator-credits"
msgstr ""
View Git Blame Copy Permalink