diff --git a/doc/admin-guide-cloud/locale/admin-guide-cloud.pot b/doc/admin-guide-cloud/locale/admin-guide-cloud.pot index b094d89612..c9be7a49e6 100644 --- a/doc/admin-guide-cloud/locale/admin-guide-cloud.pot +++ b/doc/admin-guide-cloud/locale/admin-guide-cloud.pot @@ -1,7 +1,7 @@ msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" -"POT-Creation-Date: 2014-08-01 06:09+0000\n" +"POT-Creation-Date: 2014-08-05 06:09+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" @@ -875,134 +875,134 @@ msgid "Building blocks" msgstr "" #: ./doc/admin-guide-cloud/ch_compute.xml:317(para) -msgid "In OpenStack the base operating system is usually copied from an image stored in the OpenStack Image Service. This is the most common case and results in an ephemeral instance that starts from a known template state and loses all accumulated states on shutdown. It is also possible to put an operating system on a persistent volume in the Nova-Volume or Cinder volume system. This gives a more traditional persistent system that accumulates states, which are preserved across restarts. To get a list of available images on your system run: " +msgid "In OpenStack the base operating system is usually copied from an image stored in the OpenStack Image Service. This is the most common case and results in an ephemeral instance that starts from a known template state and loses all accumulated states on virtual machine deletion. It is also possible to put an operating system on a persistent volume in the Cinder volume system. This gives a more traditional persistent system that accumulates states, which are preserved on the Cinder volume across the deletion and re-creation of the virutal machine. To get a list of available images on your system run: " msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:336(para) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:24(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:337(para) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:24(para) msgid "The displayed image attributes are:" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:339(literal) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:27(literal) ./doc/admin-guide-cloud/compute/section_compute-networking-nova.xml:518(replaceable) +#: ./doc/admin-guide-cloud/ch_compute.xml:340(literal) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:27(literal) ./doc/admin-guide-cloud/compute/section_compute-networking-nova.xml:518(replaceable) msgid "ID" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:341(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:342(para) msgid "Automatically generated UUID of the image" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:346(literal) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:33(literal) +#: ./doc/admin-guide-cloud/ch_compute.xml:347(literal) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:33(literal) msgid "Name" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:348(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:349(para) msgid "Free form, human-readable name for image" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:353(literal) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:39(literal) +#: ./doc/admin-guide-cloud/ch_compute.xml:354(literal) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:39(literal) msgid "Status" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:355(para) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:41(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:356(para) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:41(para) msgid "The status of the image. Images marked ACTIVE are available for use." msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:361(literal) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:47(literal) +#: ./doc/admin-guide-cloud/ch_compute.xml:362(literal) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:47(literal) msgid "Server" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:363(para) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:49(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:364(para) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:49(para) msgid "For images that are created as snapshots of running instances, this is the UUID of the instance the snapshot derives from. For uploaded images, this field is blank." msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:370(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:371(para) msgid "Virtual hardware templates are called flavors. The default installation provides five flavors. By default, these are configurable by admin users, however that behavior can be changed by redefining the access controls for compute_extension:flavormanage in /etc/nova/policy.json on the compute-api server." msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:378(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:379(para) msgid "For a list of flavors that are available on your system:" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:393(title) +#: ./doc/admin-guide-cloud/ch_compute.xml:394(title) msgid "Compute service architecture" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:394(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:395(para) msgid "The following basic categories describe the service architecture and what's going on within the cloud controller." msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:397(title) +#: ./doc/admin-guide-cloud/ch_compute.xml:398(title) msgid "API server" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:398(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:399(para) msgid "At the heart of the cloud framework is an API server. This API server makes command and control of the hypervisor, storage, and networking programmatically available to users." msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:401(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:402(para) msgid "The API endpoints are basic HTTP web services which handle authentication, authorization, and basic command and control functions using various API interfaces under the Amazon, Rackspace, and related models. This enables API compatibility with multiple existing tool sets created for interaction with offerings from other vendors. This broad compatibility prevents vendor lock-in." msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:412(title) +#: ./doc/admin-guide-cloud/ch_compute.xml:413(title) msgid "Message queue" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:413(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:414(para) msgid "A messaging queue brokers the interaction between compute nodes (processing), the networking controllers (software which controls network infrastructure), API endpoints, the scheduler (determines which physical hardware to allocate to a virtual resource), and similar components. Communication to and from the cloud controller is by HTTP requests through multiple API endpoints." msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:422(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:423(para) msgid "A typical message passing event begins with the API server receiving a request from a user. The API server authenticates the user and ensures that the user is permitted to issue the subject command. The availability of objects implicated in the request is evaluated and, if available, the request is routed to the queuing engine for the relevant workers. Workers continually listen to the queue based on their role, and occasionally their type host name. When an applicable work request arrives on the queue, the worker takes assignment of the task and begins its execution. Upon completion, a response is dispatched to the queue which is received by the API server and relayed to the originating user. Database entries are queried, added, or removed as necessary throughout the process." msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:434(title) +#: ./doc/admin-guide-cloud/ch_compute.xml:435(title) msgid "Compute worker" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:435(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:436(para) msgid "Compute workers manage computing instances on host machines. The API dispatches commands to compute workers to complete these tasks:" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:440(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:441(para) msgid "Run instances" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:443(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:444(para) msgid "Terminate instances" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:446(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:447(para) msgid "Reboot instances" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:449(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:450(para) msgid "Attach volumes" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:452(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:453(para) msgid "Detach volumes" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:455(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:456(para) msgid "Get console output" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:460(title) +#: ./doc/admin-guide-cloud/ch_compute.xml:461(title) msgid "Network Controller" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:461(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:462(para) msgid "The Network Controller manages the networking resources on host machines. The API server dispatches commands through the message queue, which are subsequently processed by Network Controllers. Specific operations include:" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:468(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:469(para) msgid "Allocate fixed IP addresses" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:471(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:472(para) msgid "Configuring VLANs for projects" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:474(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:475(para) msgid "Configuring networks for compute nodes" msgstr "" @@ -6675,7 +6675,7 @@ msgid "If you plan to decommission a block storage node, you must stop the NOVA-INST-DIR/instancesSettingUpNFSHowTo or CentOS / Redhat: Setup NFS v4.0 File Server" +msgid "For more information, see: SettingUpNFSHowTo or CentOS / Red Hat: Setup NFS v4.0 File Server" msgstr "" #: ./doc/admin-guide-cloud/compute/section_compute-configure-migrations.xml:144(para) diff --git a/doc/arch-design/locale/arch-design.pot b/doc/arch-design/locale/arch-design.pot index 29b3a86335..b3b2488c7b 100644 --- a/doc/arch-design/locale/arch-design.pot +++ b/doc/arch-design/locale/arch-design.pot @@ -1,7 +1,7 @@ msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" -"POT-Creation-Date: 2014-08-04 06:09+0000\n" +"POT-Creation-Date: 2014-08-05 06:09+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" @@ -13,6 +13,30 @@ msgstr "" 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 "Specialized Networking: 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:26(para) +msgid "Software-Defined Networking: 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:32(para) +msgid "Desktop-as-a-Service: 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:38(para) +msgid "OpenStack on OpenStack: 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:44(para) +msgid "Specialized Hardware: Some highly specialized situations will require the use of specialized hardware devices from within the OpenStack environment." +msgstr "" + #: ./doc/arch-design/ch_glossary.xml:7(title) msgid "Glossary" msgstr "" @@ -361,30 +385,298 @@ msgstr "" msgid "Massively scalable" msgstr "" +#: ./doc/arch-design/ch_massively_scalable.xml:9(para) +msgid "A massively scalable architecture is defined as a cloud implementation that is either a very large deployment, such as one that would be built by a commercial service provider, or one that has the capability to support user requests for large amounts of cloud resources. An example would be an infrastructure in which requests to service 500 instances or more at a time is not uncommon. In a massively scalable infrastructure, such a request is fulfilled without completely consuming all of the available cloud infrastructure resources. While the high capital cost of implementing such a cloud architecture makes it cost prohibitive and is only spearheaded by few organizations, many organizations are planning for massive scalability moving toward the future." +msgstr "" + +#: ./doc/arch-design/ch_massively_scalable.xml:22(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 massively scalable clouds are designed or specialized for particular workloads. Like the general purpose cloud, the massively scalable cloud is most often built as a platform for a variety of workloads. Massively scalable OpenStack clouds are generally built as commercial public cloud offerings since single private organizations rarely have the resources or need for this scale." +msgstr "" + +#: ./doc/arch-design/ch_massively_scalable.xml:34(para) +msgid "Services provided by a massively scalable OpenStack cloud will include:" +msgstr "" + +#: ./doc/arch-design/ch_massively_scalable.xml:38(para) ./doc/arch-design/ch_generalpurpose.xml:40(para) +msgid "Virtual-machine disk image library" +msgstr "" + +#: ./doc/arch-design/ch_massively_scalable.xml:41(para) ./doc/arch-design/ch_generalpurpose.xml:43(para) +msgid "Raw block storage" +msgstr "" + +#: ./doc/arch-design/ch_massively_scalable.xml:44(para) ./doc/arch-design/ch_generalpurpose.xml:46(para) +msgid "File or object storage" +msgstr "" + +#: ./doc/arch-design/ch_massively_scalable.xml:47(para) +msgid "Firewall functionality" +msgstr "" + +#: ./doc/arch-design/ch_massively_scalable.xml:50(para) +msgid "Load balancing functionality" +msgstr "" + +#: ./doc/arch-design/ch_massively_scalable.xml:53(para) +msgid "Private (non-routable) and public (floating) IP addresses" +msgstr "" + +#: ./doc/arch-design/ch_massively_scalable.xml:57(para) +msgid "Virtualized network topologies" +msgstr "" + +#: ./doc/arch-design/ch_massively_scalable.xml:60(para) ./doc/arch-design/ch_generalpurpose.xml:62(para) +msgid "Software bundles" +msgstr "" + +#: ./doc/arch-design/ch_massively_scalable.xml:63(para) +msgid "Virtual compute resources" +msgstr "" + +#: ./doc/arch-design/ch_massively_scalable.xml:66(para) +msgid "Like a general purpose cloud, the instances deployed in a massively scalable OpenStack cloud will not necessarily use any specific aspect of the cloud offering (compute, network, or storage). As the cloud grows in scale, the scale of the number of workloads can cause stress on all of the cloud components. Additional stresses are introduced to supporting infrastructure including 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_introduction.xml:7(title) ./doc/arch-design/multi_site/section_introduction_multi_site.xml:7(title) ./doc/arch-design/network_focus/section_introduction_network_focus.xml:7(title) ./doc/arch-design/generalpurpose/section_introduction_generalpurpose.xml:7(title) ./doc/arch-design/compute_focus/section_introduction_compute_focus.xml:7(title) ./doc/arch-design/specialized/section_introduction_specialized.xml:7(title) ./doc/arch-design/hybrid/section_introduction_hybrid.xml:7(title) ./doc/arch-design/massively_scalable/section_introduction_massively_scalable.xml:7(title) ./doc/arch-design/storage_focus/section_introduction_storage_focus.xml:7(title) +#: ./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 section 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(para) +msgid "Content Delivery Network: 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:40(para) +msgid "Network Management Functions: 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:47(para) +msgid "Network Service Offerings: 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:53(para) +msgid "Web portals / Web Services: Web servers are a common application for cloud services and it is recommended to have 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:63(para) +msgid "High Speed and High Volume Transactional Systems: 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:77(para) +msgid "High Availability: 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:87(para) +msgid "Big Data: 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:98(para) +msgid "Virtual Desktop Infrastructure (VDI): 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:109(para) +msgid "Voice over IP (VoIP): 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:120(para) +msgid "Video Conference / Web Conference: 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:130(para) +msgid "High Performance Computing (HPC): 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. To truly reap those benefits, however, 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, but 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, and each of them has its own particular requirements and architectural peculiarities." +msgstr "" + +#: ./doc/arch-design/ch_introduction.xml:26(para) +msgid "This book is designed to look at some of the most common uses for OpenStack clouds (and even some that are less common, but provide a good example) and explain what issues need to be considered and why, along with a wealth of knowledge and advice to help an organization to design and build a well-architected OpenStack cloud that will 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 "Hybrid cloud, 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). Bursting 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:20(para) +msgid "Some situations that could involve hybrid cloud architecture include:" +msgstr "" + +#: ./doc/arch-design/ch_hybrid.xml:24(para) +msgid "Bursting from a private cloud to a public cloud" +msgstr "" + +#: ./doc/arch-design/ch_hybrid.xml:28(para) +msgid "Disaster recovery" +msgstr "" + +#: ./doc/arch-design/ch_hybrid.xml:31(para) +msgid "Development and testing" +msgstr "" + +#: ./doc/arch-design/ch_hybrid.xml:34(para) +msgid "Federated cloud, enabling users to choose resources from multiple providers" +msgstr "" + +#: ./doc/arch-design/ch_hybrid.xml:38(para) +msgid "Hybrid clouds built to support legacy systems as they transition to cloud" +msgstr "" + +#: ./doc/arch-design/ch_hybrid.xml:42(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:48(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:59(para) +msgid "There are commercially available options, such as Rightscale, and open source options, such as ManageIQ (http://manageiq.org/), 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, however they share some common needs. OpenStack is capable of running in a multi-region configuration allowing some parts of OpenStack to effectively manage a grouping of sites as a single cloud. With some 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 where digital data is stored 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 has extended to include 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 is based on virtualized infrastructure and resembles broader cloud computing in terms of accessible interfaces, elasticity, scalability, multi-tenancy, and metered resources. Cloud storage services can be utilized from an off-premises service or deployed on-premises." +msgstr "" + +#: ./doc/arch-design/ch_storage_focus.xml:20(para) +msgid "Cloud storage is made up of many distributed, yet still synonymous resources, and is 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 a certain scale, management of data operations can become a resource intensive process to an organization. Hierarchical storage management (HSM) systems and data grids can help annotate and report a baseline data valuation to make intelligent decisions and automate data decisions. HSM allows for automating 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 allowing users to manage large data sets." +msgstr "" + +#: ./doc/arch-design/ch_storage_focus.xml:35(para) +msgid "Examples of applications that can be deployed with cloud storage characteristics are:" +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:9(para) +msgid "An OpenStack general purpose cloud is often considered a starting point for building a cloud deployment. General purpose clouds, by their nature, balance the components and do not emphasize (or heavily emphasize) any particular aspect of the overall computing environment. The expectation is that the compute, network, and storage components will be given equal weight in the design. General purpose clouds can be found in private, public, and hybrid environments. They lend themselves to many different use cases but, since they are homogeneous deployments, they are not suited to specialized environments or edge case situations. Common uses to consider for a general purpose cloud could be, but are not limited to, providing a simple database, a web application runtime environment, a shared application development platform, or lab test bed. In other words, any use case that would benefit from a scale-out rather than a scale-up approach is a good candidate for a general purpose cloud architecture." +msgstr "" + +#: ./doc/arch-design/ch_generalpurpose.xml:26(para) +msgid "A general purpose cloud, by definition, is something that is designed to have a range of potential uses or functions; not specialized for a specific use. General purpose architecture is largely considered a scenario that would address 80% of the potential use cases. The infrastructure, in itself, is a specific use case. It is also a good place to start the design process. As the most basic cloud service model, general purpose clouds are designed to be platforms suited for general purpose applications." +msgstr "" + +#: ./doc/arch-design/ch_generalpurpose.xml:35(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:49(para) ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:174(para) +msgid "Firewalls" +msgstr "" + +#: ./doc/arch-design/ch_generalpurpose.xml:52(para) +msgid "Load balancers" +msgstr "" + +#: ./doc/arch-design/ch_generalpurpose.xml:55(para) +msgid "IP addresses" +msgstr "" + +#: ./doc/arch-design/ch_generalpurpose.xml:58(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 "" @@ -433,6 +725,34 @@ msgstr "" 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:21(para) +msgid "High performance computing (HPC)" +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:152(title) msgid "References" msgstr "" @@ -530,139 +850,139 @@ msgid "Deployers must be aware of this and provide the appropriate customization msgstr "" #: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:19(para) -msgid "Note that, as of the Icehouse release, documentation for implementing this feature is in progress. See this bug for more information: https://bugs.launchpad.net/openstack-manuals/+bug/1340509" +msgid "Note that, as of the Icehouse release, documentation for implementing this feature is in progress. See this bug for more information: https://bugs.launchpad.net/openstack-manuals/+bug/1340509." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:23(title) +#: ./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:24(para) +#: ./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:33(para) +#: ./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:36(para) +#: ./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:43(para) +#: ./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:49(para) +#: ./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:56(title) +#: ./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:57(para) -msgid "Logging and monitoring does not significantly differ for a multi-site OpenStack cloud. The same well known tools described in the Operations Guide (http://docs.openstack.org/openstack-ops/content/logging_monitoring.html) remain applicable. Logging and monitoring can be provided both on a per-site basis and in a common centralized location." +#: ./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 Logging and monitoring chapter of the Operations Guide 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:64(para) +#: ./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:68(title) ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:52(title) +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:72(title) ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:52(title) msgid "Upgrades" msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:69(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 (http://docs.openstack.org/openstack-ops/content/ops_upgrades-general-steps.html):" +#: ./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 Upgrades chapter of the Operations Guide for details):" msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:78(para) -msgid "Upgrade the OpenStack Identity Service (Keystone)." +#: ./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:82(para) -msgid "Upgrade the OpenStack Image Service (Glance)." +#: ./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:85(para) -msgid "Upgrade OpenStack Compute (Nova), including networking components." -msgstr "" - -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:89(para) -msgid "Upgrade OpenStack Block Storage (Cinder)." -msgstr "" - -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:92(para) -msgid "Upgrade the OpenStack dashboard.(Horizon)" +#: ./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:99(para) -msgid "Upgrade the shared OpenStack Identity Service (Keystone) deployment." +#: ./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:103(para) +#: ./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:107(para) -msgid "Upgrade OpenStack Compute (Nova), including networking components, at each site." +#: ./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:111(para) -msgid "Upgrade OpenStack Block Storage (Cinder) at each site." +#: ./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:115(para) -msgid "Upgrade the OpenStack dashboard (Horizon), at each site - or in the single central location if it is shared." +#: ./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:120(para) +#: ./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:128(title) +#: ./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:129(para) +#: ./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:134(para) +#: ./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:141(para) +#: ./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:146(para) -msgid "For more information on managing quotas refer to Chapter 9. Managing Projects and Users (http://docs.openstack.org/openstack-ops/content/projects_users.html) of the OpenStack Operators Guide." +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:152(para) +msgid "For more information on managing quotas refer to the Managing projects and users chapter of the OpenStack Operators Guide." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:151(title) +#: ./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:152(para) +#: ./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 policy.json file, for each service. Operators edit these files to customize the policies for their OpenStack installation. If the application of consistent RBAC policies across sites is considered a requirement, then it is necessary to ensure proper synchronization of the policy.json files to all installations." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:160(para) +#: ./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:164(title) +#: ./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:165(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 will schedule 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. Horizon will present the user with the first region in your configuration. The API and CLI tools will 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 will not automatically build new instances in another. Documenting specific examples will help users understand how to operate the cloud, thereby reducing calls and tickets filed with the help desk." +#: ./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 will schedule 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 will present the user with the first region in your configuration. The API and CLI tools will 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 will not automatically build new instances in another. Documenting specific examples will help 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. @@ -688,19 +1008,19 @@ msgid "The OpenStack Identity service, which is used by all other OpenStack comp 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." +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 Service, and OpenStack Object Storage services are components that can each be deployed centrally in order to serve multiple regions." +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:153(para) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:22(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) +#: ./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/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." +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) @@ -735,26 +1055,6 @@ msgstr "" msgid "Networking decisions include the encapsulation mechanism that will 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_introduction_multi_site.xml:8(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, however they share some common needs. OpenStack is capable of running in a multi-region configuration allowing some parts of OpenStack to effectively manage a grouping of sites as a single cloud. With some 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/multi_site/section_introduction_multi_site.xml:18(para) -msgid "Some use cases that might indicate a need for a multi-site deployment of OpenStack include:" -msgstr "" - -#: ./doc/arch-design/multi_site/section_introduction_multi_site.xml:22(para) -msgid "An organization with a diverse geographic footprint." -msgstr "" - -#: ./doc/arch-design/multi_site/section_introduction_multi_site.xml:26(para) -msgid "Geo-location sensitive data." -msgstr "" - -#: ./doc/arch-design/multi_site/section_introduction_multi_site.xml:29(para) -msgid "Data locality, in which specific data or functionality should be close to users." -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/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 "" @@ -784,296 +1084,296 @@ msgid "Data compliance policies governing types of information that needs to res 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 (http://ec.europa.eu/justice/data-protection) and the requirements of the Financial Industry Regulatory Authority (http://www.finra.org/Industry/Regulation/FINRARules) in the United States. Consult a local regulatory body for more information." +msgid "Examples of such legal frameworks include the data protection framework of the European Union (http://ec.europa.eu/justice/data-protection) and the requirements of the Financial Industry Regulatory Authority (http://ec.europa.eu/justice/data-protection) in the United States. Consult a local regulatory body for more information." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:46(title) +#: ./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:47(para) +#: ./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:58(para) +#: ./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:62(para) +#: ./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:71(title) +#: ./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:73(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 OpenStack Object Store is used as a back end for Glance, it is possible to create repositories of consistent images across multiple sites. Having a central endpoint with multiple storage nodes will allow for a consistent centralized storage for each and every site." +#: ./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 OpenStack Object Store is used as a back end for the Image Service, it is possible to create repositories of consistent images across multiple sites. Having a central endpoint with multiple storage nodes will allow for a consistent centralized storage for each and every site." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:80(para) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:81(para) msgid "Not using a centralized object store will increase 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:85(title) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:86(title) msgid "High availability" msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:86(para) -msgid "If high availability is a requirement to provide continuous infrastructure operations, a basic requirement of High Availability should be defined." +#: ./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:89(para) +#: ./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:94(para) -msgid "The OpenStack High Availability Guide (http://docs.openstack.org/high-availability-guide/content/) contains more information on how to provide redundancy for the OpenStack components." +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:95(para) +msgid "The OpenStack High Availability Guide contains more information on how to provide redundancy for the OpenStack components." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:98(para) +#: ./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:106(para) +#: ./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 will also have a significant impact on the WAN network design between the sites." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:110(para) +#: ./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:116(para) +#: ./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:127(title) ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:37(title) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:129(title) ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:37(title) msgid "Application readiness" msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:128(para) +#: ./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:137(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:72(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:234(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:637(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/hybrid/section_user_requirements_hybrid.xml:19(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:16(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:40(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:184(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:417(term) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:139(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:72(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:234(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:637(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/hybrid/section_user_requirements_hybrid.xml:19(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:16(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:40(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:184(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:417(term) msgid "Cost" msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:138(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" +#: ./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:144(para) -msgid "Compute Resources" +#: ./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:147(para) +#: ./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:150(para) +#: ./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:156(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:664(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:286(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:126(para) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:158(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:664(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:286(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:126(para) msgid "Management" msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:159(para) +#: ./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:163(title) +#: ./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:164(para) +#: ./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:169(para) +#: ./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:176(para) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:178(para) msgid "It is important to understand what will happen to replication of objects and data between the sites when a site goes down. If this causes queues to start building up, considering how long these queues can safely exist until something explodes." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:183(para) +#: ./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. It is recommended to architect the recovery to avoid race conditions." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:190(title) +#: ./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:191(para) +#: ./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:195(title) +#: ./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:196(para) +#: ./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:204(title) +#: ./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:205(para) +#: ./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:210(title) +#: ./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:211(para) +#: ./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 will, of course, require 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:82(None) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:86(None) msgid "@@image: '../images/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:185(None) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:190(None) msgid "@@image: '../images/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:217(None) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:222(None) msgid "@@image: '../images/Multi-Site_shared_keystone1.png'; md5=07e063d95e8b20f7458af5152d7536cb" msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:8(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) +#: ./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:9(para) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:13(para) msgid "Based on the needs of the intended workloads, there are multiple ways to build a multi-site OpenStack installation. 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:16(para) +#: ./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 will deploy 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 will 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:40(para) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:44(para) msgid "Installation of an automated DNS system such as Designate is highly recommended. Unless an external Dynamic DNS system is available, application administrators will need a way to manage the mapping of which application copy exists in each region and how to reach it. Designate will assist 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:47(para) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:51(para) msgid "Telemetry for each region is also deployed, as each region may grow differently or be used at a different rate. Ceilometer will run to collect each region's metrics 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, in that it is possible to determine if certain locations are experiencing higher load than others, and take appropriate action. Administrators will 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:60(para) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:64(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 will be implemented. The first type revolves around the availability of the central OpenStack components. Keystone will be made highly available in three central data centers that will 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:71(para) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:75(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 will house a second region near the first. This ensures that the application will not suffer degraded performance in terms of latency and availability." msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:76(para) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:80(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:86(title) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:90(title) msgid "Geo-redundant load balancing" msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:87(para) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:91(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:93(para) -msgid "As of late there has been several outages in number of major public cloud providers - usually 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." +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:97(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:98(para) ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:32(para) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:102(para) ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:32(para) msgid "The solution would consist of the following OpenStack components:" msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:102(para) ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:36(para) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:106(para) ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:36(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:106(para) -msgid "OpenStack Controller services running, Networking, Horizon, Cinder and Nova compute running locally in each of the three regions. The other services, Identity, Orchestration, Telemetry, Image Service and Block Storage will be installed centrally - with nodes in each of the region providing a redundant OpenStack Controller plane throughout the globe." +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:110(para) +msgid "OpenStack Controller services running, Networking, Horizon, Cinder and Nova compute running locally in each of the three regions. The other services, Identity, Orchestration, Telemetry, Image Service and Block Storage will 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:116(para) ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:47(para) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:120(para) ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:47(para) msgid "OpenStack Compute nodes running the KVM hypervisor." msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:120(para) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:124(para) msgid "OpenStack Object Storage for serving static objects such as images will 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:126(para) -msgid "A Distributed DNS service available to all regions - that allows for dynamic update of DNS records of deployed instances." +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:130(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:131(para) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:135(para) msgid "A geo-redundant load balancing service will 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:136(para) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:140(para) msgid "An autoscaling heat template will used to deploy the application in the three regions. This template will include:" msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:141(para) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:145(para) msgid "Web Servers, running Apache." msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:144(para) -msgid "Appropriate user_data to populate the central DNS servers upon instance launch." -msgstr "" - #: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:148(para) -msgid "Appropriate Ceilometer alarms that maintain state of the application and allow for handling of region or instance failure." +msgid "Appropriate user_data to populate the central DNS servers upon instance launch." msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:153(para) -msgid "Another autoscaling Heat template will be used to deploy a distributed MongoDB shard over the three locations - with the option of storing required data on a globally available Swift container. according to the usage and load on the database server - additional shards will be provisioned according to the thresholds defined in Ceilometer." +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:152(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:159(para) -msgid "The reason that 3 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." +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:157(para) +msgid "Another autoscaling Heat template will 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 will be provisioned according to the thresholds defined in Telemetry." msgstr "" #: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:163(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 cloud - whereas the other tools were external and not native to OpenStack. In addition - since this deployment scenario was relatively straight forward - the external tools were not needed." +msgid "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." msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:172(para) -msgid "Swift is used here to serve as a back end for Glance and Object storage since was the most suitable solution for a globally distributed storage solution - with its own replication mechanism. Home grown solutions could also have been used including the handling of replication - but were not chosen, because Swift is already an intricate part of the infrastructure - and proven solution." +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:167(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:179(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 have any awareness of geo location." +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:176(para) +msgid "OpenStack Object Storage is used here to serve as a back end for the Image Service since was 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:188(title) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:184(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:193(title) msgid "Location-local service" msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:189(para) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:194(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 will require 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 would require utilizing higher cost cross country links." msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:198(para) +#: ./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:207(para) +#: ./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 will first be 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 "" @@ -1090,11 +1390,11 @@ msgid "When determining capacity options be sure to take into account not just t 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 will determine what kind of options may be available for deployment. For example, if two sites have a pair of high-bandwidth links available between them, it may be wise to configure a separate storage replication network between the two sites to support a single Swift endpoint and a shared object storage capability between them. (An example of this technique, as well as a configuration walk-through, is available at http://docs.openstack.org/developer/swift/replication_network.html#dedicated-replication-network). Another option in this scenario is to build a dedicated set of tenant private networks across the secondary link using overlay networks with a third party mapping the site overlays to each other." +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 will determine what kind of options may be available for deployment. For example, if two sites have a pair of high-bandwidth links available between them, it may be wise to configure a separate storage replication network between the two sites to support a single Swift endpoint and a shared object storage capability between them. (An example of this technique, as well as a configuration walk-through, is available at http://docs.openstack.org/developer/swift/replication_network.html#dedicated-replication-network). Another option in this scenario is to build a dedicated set of tenant private networks across the secondary link using overlay networks with a third party mapping the site overlays to each other." msgstr "" #: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:38(para) -msgid "The capacity requirements of the links between sites will be 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 Keystone call timeouts may be necessary to prevent issues authenticating against a central Identity Service." +msgid "The capacity requirements of the links between sites will be 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) @@ -1118,18 +1418,18 @@ msgid "While constructing a multi-site OpenStack environment is the goal of this 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 Keystone is required for almost all major operations within OpenStack. Therefore, it is important to ensure that you provide users with a single URL for Keystone authentication. Equally important is proper documentation and configuration of regions within Keystone. Each of the sites defined in your installation is considered to be a region in Keystone nomenclature. This is important for the users of the system, when reading Keystone documentation, as it is required to define the Region name when providing actions to an API endpoint or in Horizon." +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 will be 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." +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 will be 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 will also be 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 will 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 Swift 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." +msgid "Depending on the storage model chosen during site design, storage replication and availability will also be 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 will 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:399(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:249(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:420(term) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:130(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:474(title) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:96(term) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:257(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:253(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:19(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:48(term) +#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:114(title) ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:406(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:249(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:420(term) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:130(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:474(title) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:96(term) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:257(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:253(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:19(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:48(term) msgid "Performance" msgstr "" @@ -1138,14 +1438,14 @@ msgid "Determining the performance of a multi-site installation involves conside 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 Keystone 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." +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 will need to manually cope with this limitation by creating duplicate block storage entries in each region." +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 will 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:142(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:684(term) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:199(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:650(title) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:160(term) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:268(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:107(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:471(term) +#: ./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:684(term) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:199(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:650(title) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:160(term) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:268(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:107(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:471(term) msgid "Security" msgstr "" @@ -1166,67 +1466,15 @@ 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 Keystone for authentication, Nova for compute, Glance for image storage, Neutron for networking, and potentially an object store in the form of Swift. Bringing multi-site into play also demands extra components in order to coordinate between regions. Centralized Keystone is necessary to provide the single authentication point. Centralized Horizon is also recommended to provide a single login point and a mapped experience to the API and CLI options available. If necessary, a centralized Swift may be used and will require the installation of the Swift proxy service." +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:182(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." +#: ./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:189(para) -msgid "Another useful tool for managing a multi-site installation is Orchestration. Heat 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_introduction_network_focus.xml:8(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 section 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/network_focus/section_introduction_network_focus.xml:18(para) -msgid "Some possible use cases include:" -msgstr "" - -#: ./doc/arch-design/network_focus/section_introduction_network_focus.xml:21(para) -msgid "Content Delivery Network: 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/network_focus/section_introduction_network_focus.xml:39(para) -msgid "Network Management Functions: 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/network_focus/section_introduction_network_focus.xml:46(para) -msgid "Network Service Offerings: 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/network_focus/section_introduction_network_focus.xml:52(para) -msgid "Web portals / Web Services: Web servers are a common application for cloud services and it is recommended to have 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/network_focus/section_introduction_network_focus.xml:62(para) -msgid "High Speed and High Volume Transactional Systems: 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/network_focus/section_introduction_network_focus.xml:76(para) -msgid "High Availability: 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/network_focus/section_introduction_network_focus.xml:86(para) -msgid "Big Data: 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/network_focus/section_introduction_network_focus.xml:97(para) -msgid "Virtual Desktop Infrastructure (VDI): 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/network_focus/section_introduction_network_focus.xml:108(para) -msgid "Voice over IP (VoIP): 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/network_focus/section_introduction_network_focus.xml:119(para) -msgid "Video Conference / Web Conference: 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/network_focus/section_introduction_network_focus.xml:129(para) -msgid "High Performance Computing (HPC): 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." +#: ./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) @@ -1269,315 +1517,315 @@ msgstr "" msgid "The basic reasoning behind using layer 2 Ethernet over layer 3 IP networks is the speed, the reduced overhead of the IP hierarchy, and the lack of requirement to keep track of IP 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:81(para) -msgid "Important Note: 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." +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:82(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:93(title) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:96(title) msgid "Layer 2 architecture limitations" msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:94(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:97(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:98(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:101(para) msgid "Number of VLANs is limited to 4096." msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:101(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:104(para) msgid "The number of MACs stored in switch tables is limited." msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:105(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:108(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:109(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:112(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:114(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:117(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:118(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:121(para) msgid "Configuring ARP is considered complicated on large layer 2 networks." msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:122(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:125(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:128(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:131(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:133(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:136(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:140(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:143(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:149(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:152(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:155(title) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:158(title) msgid "Layer 3 architecture advantages" msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:156(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:159(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:164(para) -msgid "layer 3 networks provide the same level of resiliency and scalability as the Internet." +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:167(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:168(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:171(para) msgid "Controlling traffic with routing metrics is straightforward." msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:172(para) -msgid "layer 3 can be configured to use BGP confederation for scalability so core routers have state proportional to number of racks, not to the number of servers or instances." +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:175(para) +msgid "Layer 3 can be configured to use BGP confederation for scalability so core routers have state proportional to number of racks, not to the number of servers or instances." msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:178(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:181(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:184(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:187(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:188(para) -msgid "layer 3 architectures allow for the use of Quality of Service (QoS) to manage network performance." +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:191(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:193(title) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:196(title) msgid "Layer 3 architecture limitations" msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:194(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:197(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 encapsulation 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:209(title) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:212(title) msgid "Network recommendations overview" msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:210(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:213(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:221(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:224(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:226(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:229(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:232(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:235(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:236(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:239(para) msgid "A requirement to support indeterminate platforms and applications." msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:240(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:243(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:244(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:247(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:248(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:251(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:252(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:255(para) msgid "A requirement to be tolerant of rack level failure." msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:256(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:259(para) msgid "A requirement to maximize flexibility to architect future production environments." msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:260(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:263(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:264(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:267(para) msgid "Layer 3 designs are preferred over layer 2 architectures." msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:268(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:271(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:272(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:275(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:276(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:279(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:281(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:284(para) msgid "Isolate virtual networks using encapsulation technologies." msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:285(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:288(para) msgid "Use traffic shaping for performance tuning." msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:288(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:291(para) msgid "Use eBGP to connect to the Internet up-link." msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:291(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:294(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:295(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:298(para) msgid "Determine the most effective configuration for block storage network." msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:300(title) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:303(title) msgid "Additional considerations" msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:301(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:304(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:304(title) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:307(title) msgid "OpenStack Networking versus Nova network considerations" msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:306(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:309(para) msgid "Selecting the type of networking technology to implement depends on many factors. OpenStack Networking (Neutron) and 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:315(th) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:318(th) msgid "Nova Network" msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:316(th) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:319(th) msgid "OpenStack Networking" msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:320(td) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:323(td) msgid "Simple, single agent" msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:321(td) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:324(td) msgid "Complex, multiple agents" msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:324(td) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:327(td) msgid "More mature, established" msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:325(td) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:328(td) msgid "Newer, maturing" msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:328(td) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:331(td) msgid "Flat or VLAN" msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:329(td) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:332(td) msgid "Flat, VLAN, Overlays, L2-L3, SDN" msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:331(td) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:334(td) msgid "No plug-in support" msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:332(td) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:335(td) msgid "Plug-in support for 3rd parties" msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:335(td) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:338(td) msgid "Scales well" msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:336(td) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:339(td) msgid "Scaling requires 3rd party plug-ins" msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:339(td) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:342(td) msgid "No multi-tier topologies" msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:340(td) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:343(td) msgid "Multi-tier topologies" msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:346(title) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:349(title) msgid "Redundant networking: ToR switch high availability risk analysis" msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:348(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:351(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:351(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 http://www.garrettcom.com/techsupport/papers/ethernet_switch_reliability.pdf and http://www.n-tron.com/pdf/network_availability.pdf" +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:354(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 http://www.garrettcom.com/techsupport/papers/ethernet_switch_reliability.pdf and http://www.n-tron.com/pdf/network_availability.pdf." msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:361(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:367(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:369(title) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:375(title) msgid "Preparing for the future: IPv6 support" msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:370(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 http://www.internetsociety.org/deploy360/blog/2014/05/goodbye-ipv4-iana-starts-allocating-final-address-blocks/. 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." +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:376(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 (http://www.internetsociety.org/deploy360/blog/2014/05/goodbye-ipv4-iana-starts-allocating-final-address-blocks/). 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:380(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:387(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 an essential for network focused applications in the future." msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:385(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:392(para) msgid "Neutron supports IPv6 when configured to take advantage of the feature. To enable it, simply create an IPv6 subnet in OpenStack Neutron and use IPv6 prefixes when creating security groups." msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:390(title) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:397(title) msgid "Asymmetric links" msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:391(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:398(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:400(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:407(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:410(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:417(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:416(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:423(para) msgid "OpenStack networking can be implemented in two separate ways. The legacy 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. Neutron is the official current implementation of OpenStack Networking. It 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:427(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:434(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:435(para) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:442(para) msgid "When selecting network devices, be aware that making this decision based on largest 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 "" @@ -1598,66 +1846,86 @@ msgid "Data compliance policies governing where information needs to reside in c 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 (http://ec.europa.eu/justice/data-protection/ ) and the requirements of the Financial Industry Regulatory Authority (http://www.finra.org/Industry/Regulation/FINRARules) in the United States. Consult a local regulatory body for more information." +msgid "Examples of such legal frameworks include the data protection framework of the European Union (http://ec.europa.eu/justice/data-protection/) and the requirements of the Financial Industry Regulatory Authority (http://www.finra.org/Industry/Regulation/FINRARules) in the United States. Consult a local regulatory body for more information." msgstr "" -#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:75(title) +#: ./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:76(para) +#: ./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:84(para) +#: ./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:89(title) +#: ./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:92(para) -msgid "Network Misconfigurations: 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." +#: ./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:100(para) -msgid "Capacity Planning: 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." +#: ./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:108(para) -msgid "Network Tuning: Cloud networks need to be configured to minimize link loss, packet loss, packet storms, broadcast storms, and loops." +#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:105(term) ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:96(title) ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:89(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:72(title) +msgid "Capacity planning" msgstr "" -#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:113(para) -msgid "Single Point Of Failure (SPOF): 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." +#: ./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:120(para) -msgid "Complexity: 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." +#: ./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:129(para) -msgid "Non-standard features: 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." +#: ./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:143(para) +#: ./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:153(para) ./doc/arch-design/generalpurpose/section_introduction_generalpurpose.xml:48(para) -msgid "Firewalls" -msgstr "" - -#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:156(para) +#: ./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:160(para) +#: ./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:163(para) +#: ./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 "" @@ -1669,7 +1937,7 @@ 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:178(None) +#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:180(None) msgid "@@image: '../images/Network_Cloud_Storage2.png'; md5=3cd3ce6b19b20ecd7d22af03731cc7cd" msgstr "" @@ -1710,74 +1978,74 @@ msgid "Telemetry module" msgstr "" #: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:69(para) -msgid "Beyond the normal Keystone, Nova, Glance and Swift components, Heat is a recommended component to handle properly scaling the workloads to adjust to demand. Ceilometer will also need to be included in the design due to the requirement for auto-scaling. 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." +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. The Telemetry module will also need to be included in the design due to the requirement for auto-scaling. 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:82(title) +#: ./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:83(para) +#: ./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:92(title) +#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:94(title) msgid "Overlay networks" msgstr "" -#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:93(para) +#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:95(para) msgid "OpenStack Networking using the Open vSwitch GRE tunnel mode was included in the design to provide overlay functionality. In this case, the layer 3 external routers will be in a pair with VRRP and switches should be paired with an implementation of MLAG running to ensure that there is no loss of connectivity with the upstream routing infrastructure." msgstr "" -#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:100(title) +#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:102(title) msgid "Performance tuning" msgstr "" -#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:101(para) +#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:103(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:113(title) +#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:115(title) msgid "Network functions" msgstr "" -#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:114(para) +#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:116(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:127(para) +#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:129(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:138(para) +#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:140(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:145(title) +#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:147(title) msgid "Cloud storage" msgstr "" -#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:146(para) +#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:148(para) msgid "Another common use case for OpenStack environments is to provide a cloud based file storage and sharing service. While this may initially be considered to be a storage focused use case there are also major requirements on the network side that place it in the realm of requiring a network focused architecture. An example for this application is cloud backup." msgstr "" -#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:153(para) +#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:155(para) msgid "There are two specific behaviors of this workload that have major and different impacts on the network. Since this is both an externally facing service and internally replicating application there are both North-South and East-West traffic considerations." msgstr "" -#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:158(para) +#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:160(para) msgid "North-South traffic is primarily user facing. This means that when a user uploads content for storage it will be coming into the OpenStack installation. Users who download this content will be drawing traffic from the OpenStack installation. Since the service is intended primarily as a backup the majority of the traffic will be southbound into the environment. In this case it is beneficial to configure a network to be asymmetric downstream as the traffic entering the OpenStack installation will be greater than traffic leaving." msgstr "" -#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:168(para) +#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:170(para) msgid "East-West traffic is likely to be fully symmetric. Since replication will originate from any node and may target multiple other nodes algorithmically, it is less likely for this traffic to have a larger volume in any specific direction. However this traffic may interfere with north-south traffic." msgstr "" -#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:181(para) +#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:183(para) msgid "This application will prioritize the North-South traffic over East-West traffic as it is the customer-facing data. QoS is implemented on East-West traffic to be a lower priority Class Selector, while North-South traffic requires a higher level in the priority queue because of this." msgstr "" -#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:186(para) +#: ./doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml:188(para) msgid "The network design in this case is less dependant on availability and more dependant 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 "" @@ -2453,46 +2721,6 @@ msgstr "" 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, general purpose cloud is not considered an appropriate choice." msgstr "" -#: ./doc/arch-design/generalpurpose/section_introduction_generalpurpose.xml:8(para) -msgid "An OpenStack general purpose cloud is often considered a starting point for building a cloud deployment. General purpose clouds, by their nature, balance the components and do not emphasize (or heavily emphasize) any particular aspect of the overall computing environment. The expectation is that the compute, network, and storage components will be given equal weight in the design. General purpose clouds can be found in private, public, and hybrid environments. They lend themselves to many different use cases but, since they are homogeneous deployments, they are not suited to specialized environments or edge case situations. Common uses to consider for a general purpose cloud could be, but are not limited to, providing a simple database, a web application runtime environment, a shared application development platform, or lab test bed. In other words, any use case that would benefit from a scale-out rather than a scale-up approach is a good candidate for a general purpose cloud architecture." -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_introduction_generalpurpose.xml:25(para) -msgid "A general purpose cloud, by definition, is something that is designed to have a range of potential uses or functions; not specialized for a specific use. General purpose architecture is largely considered a scenario that would address 80% of the potential use cases. The infrastructure, in itself, is a specific use case. It is also a good place to start the design process. As the most basic cloud service model, general purpose clouds are designed to be platforms suited for general purpose applications." -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_introduction_generalpurpose.xml:34(para) -msgid "General purpose clouds are limited to the most basic components, but they can include additional resources such as:" -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_introduction_generalpurpose.xml:39(para) ./doc/arch-design/massively_scalable/section_introduction_massively_scalable.xml:37(para) -msgid "Virtual-machine disk image library" -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_introduction_generalpurpose.xml:42(para) ./doc/arch-design/massively_scalable/section_introduction_massively_scalable.xml:40(para) -msgid "Raw block storage" -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_introduction_generalpurpose.xml:45(para) ./doc/arch-design/massively_scalable/section_introduction_massively_scalable.xml:43(para) -msgid "File or object storage" -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_introduction_generalpurpose.xml:51(para) -msgid "Load balancers" -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_introduction_generalpurpose.xml:54(para) -msgid "IP addresses" -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_introduction_generalpurpose.xml:57(para) -msgid "Network overlays or virtual local area networks (VLANs)" -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_introduction_generalpurpose.xml:61(para) ./doc/arch-design/massively_scalable/section_introduction_massively_scalable.xml:59(para) -msgid "Software bundles" -msgstr "" - #: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:9(para) msgid "Many operational factors will affect general purpose cloud design choices. In larger installations, it is not uncommon for operations staff to be tasked with maintaining cloud environments. This differs from the operations staff that is responsible for building or designing the infrastructure. It is important to include the operations function in the planning and design phases of the build out." msgstr "" @@ -2549,10 +2777,6 @@ msgstr "" msgid "An example of an operational consideration is the recovery of a failed compute host. This might mean requiring the restoration of instances from a snapshot or respawning an instance on another available compute host. This could have consequences on the overall application design. A general purpose cloud should not need to provide an ability to migrate instances from one host to another. If the expectation is that the application will be designed to tolerate failure, additional considerations need to be made around supporting instance migration. In this scenario, extra supporting services, including shared storage attached to compute hosts, might need to be deployed." msgstr "" -#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:96(title) ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:89(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:72(title) -msgid "Capacity planning" -msgstr "" - #: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:97(para) msgid "Capacity planning for future growth is a critically important and often overlooked consideration. Capacity constraints in a general purpose cloud environment include compute and storage limits. There is a relationship between the size of the compute environment and the supporting OpenStack infrastructure controller nodes required to support it. As the size of the supporting compute environment increases, the network traffic and messages will increase which will add load to the controller or networking nodes. While no hard and fast rule exists, effective monitoring of the environment will help with capacity decisions on when to scale the back-end infrastructure as part of the scaling of the compute resources." msgstr "" @@ -3044,10 +3268,10 @@ 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 Operations Guide http://docs.openstack.org/openstack-ops." +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 OpenStack Operations Guide (http://docs.openstack.org/openstack-ops)." msgstr "" -#: ./doc/arch-design/introduction/section_intended_audience.xml:13(para) +#: ./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 "" @@ -3072,7 +3296,7 @@ msgid "This book was written in five days during July 2014 while exhausting the 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 think Anne Gentle and Kenneth Hui for all of their shepherding and organization in making this happen." +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) @@ -3266,66 +3490,66 @@ msgid "Durability and resilience" msgstr "" #: ./doc/arch-design/introduction/section_methodology.xml:197(para) -msgid "Despite the existence of SLAs, the one reality of the cloud is that Things Break. Servers go down, network connections are disrupted, other tenants on a server ramp up the load to make the server unusable. Any number of things can happen, and an application that isn't built to withstand this kind of disruption isn't going to work properly." +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:212(title) +#: ./doc/arch-design/introduction/section_methodology.xml:209(title) msgid "Designing for the cloud" msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:213(para) +#: ./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:217(para) +#: ./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:221(para) +#: ./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:227(para) +#: ./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:232(para) +#: ./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:237(para) +#: ./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:242(para) +#: ./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:248(para) +#: ./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:252(para) +#: ./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:258(para) +#: ./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:264(para) +#: ./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:270(para) +#: ./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:274(para) +#: ./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:279(para) +#: ./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 "" @@ -3397,58 +3621,6 @@ msgstr "" 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:114(para) -msgid "A Glossary covers the terms and phrases used in the book." -msgstr "" - -#: ./doc/arch-design/introduction/section_introduction_to_openstack_architecture_design_guide.xml:7(title) -msgid "Introduction to the OpenStack Architecture Design Guide" -msgstr "" - -#: ./doc/arch-design/introduction/section_introduction_to_openstack_architecture_design_guide.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. To truly reap those benefits, however, the cloud must be designed and architected properly." -msgstr "" - -#: ./doc/arch-design/introduction/section_introduction_to_openstack_architecture_design_guide.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, but 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/introduction/section_introduction_to_openstack_architecture_design_guide.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, and each of them has its own particular requirements and architectural peculiarities." -msgstr "" - -#: ./doc/arch-design/introduction/section_introduction_to_openstack_architecture_design_guide.xml:26(para) -msgid "This book is designed to look at some of the most common uses for OpenStack clouds (and even some that are less common, but provide a good example) and explain what issues need to be considered and why, along with a wealth of knowledge and advice to help an organization to design and build a well-architected OpenStack cloud that will fit its unique requirements." -msgstr "" - -#: ./doc/arch-design/compute_focus/section_introduction_compute_focus.xml:8(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/compute_focus/section_introduction_compute_focus.xml:20(para) -msgid "High performance computing (HPC)" -msgstr "" - -#: ./doc/arch-design/compute_focus/section_introduction_compute_focus.xml:23(para) -msgid "Big data analytics using Hadoop or other distributed data stores" -msgstr "" - -#: ./doc/arch-design/compute_focus/section_introduction_compute_focus.xml:27(para) -msgid "Continuous integration/continuous deployment (CI/CD)" -msgstr "" - -#: ./doc/arch-design/compute_focus/section_introduction_compute_focus.xml:30(para) -msgid "Platform-as-a-Service (PaaS)" -msgstr "" - -#: ./doc/arch-design/compute_focus/section_introduction_compute_focus.xml:33(para) -msgid "Signal processing for Network Function Virtualization (NFV)" -msgstr "" - -#: ./doc/arch-design/compute_focus/section_introduction_compute_focus.xml:36(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/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 "" @@ -4423,30 +4595,6 @@ msgstr "" 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 Open vSwitch 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 "" -#: ./doc/arch-design/specialized/section_introduction_specialized.xml:8(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/specialized/section_introduction_specialized.xml:19(para) -msgid "Specialized Networking: This describes running networking-oriented software that may involve reading packets directly from the wire or participating in routing protocols." -msgstr "" - -#: ./doc/arch-design/specialized/section_introduction_specialized.xml:25(para) -msgid "Software-Defined Networking: 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/specialized/section_introduction_specialized.xml:31(para) -msgid "Desktop-as-a-Service: 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/specialized/section_introduction_specialized.xml:37(para) -msgid "OpenStack on OpenStack: 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/specialized/section_introduction_specialized.xml:43(para) -msgid "Specialized Hardware: Some highly specialized situations will require the use of specialized hardware devices from within the OpenStack environment." -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:74(None) @@ -4697,46 +4845,6 @@ msgstr "" 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 "" -#: ./doc/arch-design/hybrid/section_introduction_hybrid.xml:8(para) -msgid "Hybrid cloud, 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). Bursting 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/hybrid/section_introduction_hybrid.xml:19(para) -msgid "Some situations that could involve hybrid cloud architecture include:" -msgstr "" - -#: ./doc/arch-design/hybrid/section_introduction_hybrid.xml:23(para) -msgid "Bursting from a private cloud to a public cloud" -msgstr "" - -#: ./doc/arch-design/hybrid/section_introduction_hybrid.xml:27(para) -msgid "Disaster recovery" -msgstr "" - -#: ./doc/arch-design/hybrid/section_introduction_hybrid.xml:30(para) -msgid "Development and testing" -msgstr "" - -#: ./doc/arch-design/hybrid/section_introduction_hybrid.xml:33(para) -msgid "Federated cloud, enabling users to choose resources from multiple providers" -msgstr "" - -#: ./doc/arch-design/hybrid/section_introduction_hybrid.xml:37(para) -msgid "Hybrid clouds built to support legacy systems as they transition to cloud" -msgstr "" - -#: ./doc/arch-design/hybrid/section_introduction_hybrid.xml:41(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/hybrid/section_introduction_hybrid.xml:47(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/hybrid/section_introduction_hybrid.xml:58(para) -msgid "There are commercially available options, such as Rightscale, and open source options, such as ManageIQ (http://manageiq.org/), 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 "" - #. 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:25(None) ./doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml:84(None) @@ -5211,42 +5319,6 @@ msgstr "" msgid "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 must also be addressed by the design architecture of a massively scalable OpenStack cloud." msgstr "" -#: ./doc/arch-design/massively_scalable/section_introduction_massively_scalable.xml:8(para) -msgid "A massively scalable architecture is defined as a cloud implementation that is either a very large deployment, such as one that would be built by a commercial service provider, or one that has the capability to support user requests for large amounts of cloud resources. An example would be an infrastructure in which requests to service 500 instances or more at a time is not uncommon. In a massively scalable infrastructure, such a request is fulfilled without completely consuming all of the available cloud infrastructure resources. While the high capital cost of implementing such a cloud architecture makes it cost prohibitive and is only spearheaded by few organizations, many organizations are planning for massive scalability moving toward the future." -msgstr "" - -#: ./doc/arch-design/massively_scalable/section_introduction_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 massively scalable clouds are designed or specialized for particular workloads. Like the general purpose cloud, the massively scalable cloud is most often built as a platform for a variety of workloads. Massively scalable OpenStack clouds are generally built as commercial public cloud offerings since single private organizations rarely have the resources or need for this scale." -msgstr "" - -#: ./doc/arch-design/massively_scalable/section_introduction_massively_scalable.xml:33(para) -msgid "Services provided by a massively scalable OpenStack cloud will include:" -msgstr "" - -#: ./doc/arch-design/massively_scalable/section_introduction_massively_scalable.xml:46(para) -msgid "Firewall functionality" -msgstr "" - -#: ./doc/arch-design/massively_scalable/section_introduction_massively_scalable.xml:49(para) -msgid "Load balancing functionality" -msgstr "" - -#: ./doc/arch-design/massively_scalable/section_introduction_massively_scalable.xml:52(para) -msgid "Private (non-routable) and public (floating) IP addresses" -msgstr "" - -#: ./doc/arch-design/massively_scalable/section_introduction_massively_scalable.xml:56(para) -msgid "Virtualized network topologies" -msgstr "" - -#: ./doc/arch-design/massively_scalable/section_introduction_massively_scalable.xml:62(para) -msgid "Virtual compute resources" -msgstr "" - -#: ./doc/arch-design/massively_scalable/section_introduction_massively_scalable.xml:65(para) -msgid "Like a general purpose cloud, the instances deployed in a massively scalable OpenStack cloud will not necessarily use any specific aspect of the cloud offering (compute, network, or storage). As the cloud grows in scale, the scale of the number of workloads can cause stress on all of the cloud components. Additional stresses are introduced to supporting infrastructure including 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/massively_scalable/section_operational_considerations_massively_scalable.xml:9(para) msgid "In order to run at massive scale, it is important to plan on the automation of 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 to reduce maintenance costs. In a massively scaled environment, it is impossible for staff to give each system individual care." msgstr "" @@ -5565,66 +5637,6 @@ msgstr "" msgid "In some cases, adding bandwidth and capacity to the network resources servicing requests between proxy servers and storage nodes will be required. 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 "" -#: ./doc/arch-design/storage_focus/section_introduction_storage_focus.xml:8(para) -msgid "Cloud storage is a model of data storage where digital data is stored 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 has extended to include other types of data storage that are available as a service, for example block storage." -msgstr "" - -#: ./doc/arch-design/storage_focus/section_introduction_storage_focus.xml:14(para) -msgid "Cloud storage is based on virtualized infrastructure and resembles broader cloud computing in terms of accessible interfaces, elasticity, scalability, multi-tenancy, and metered resources. Cloud storage services can be utilized from an off-premises service or deployed on-premises." -msgstr "" - -#: ./doc/arch-design/storage_focus/section_introduction_storage_focus.xml:19(para) -msgid "Cloud storage is made up of many distributed, yet still synonymous resources, and is 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/storage_focus/section_introduction_storage_focus.xml:25(para) -msgid "At a certain scale, management of data operations can become a resource intensive process to an organization. Hierarchical storage management (HSM) systems and data grids can help annotate and report a baseline data valuation to make intelligent decisions and automate data decisions. HSM allows for automating 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 allowing users to manage large data sets." -msgstr "" - -#: ./doc/arch-design/storage_focus/section_introduction_storage_focus.xml:34(para) -msgid "Examples of applications that can be deployed with cloud storage characteristics are:" -msgstr "" - -#: ./doc/arch-design/storage_focus/section_introduction_storage_focus.xml:38(para) -msgid "Active archive, backups and hierarchical storage management." -msgstr "" - -#: ./doc/arch-design/storage_focus/section_introduction_storage_focus.xml:42(para) -msgid "General content storage and synchronization. An example of this is private dropbox." -msgstr "" - -#: ./doc/arch-design/storage_focus/section_introduction_storage_focus.xml:46(para) -msgid "Data analytics with parallel file systems." -msgstr "" - -#: ./doc/arch-design/storage_focus/section_introduction_storage_focus.xml:49(para) -msgid "Unstructured data store for services. For example, social media back-end storage." -msgstr "" - -#: ./doc/arch-design/storage_focus/section_introduction_storage_focus.xml:53(para) -msgid "Persistent block storage." -msgstr "" - -#: ./doc/arch-design/storage_focus/section_introduction_storage_focus.xml:56(para) -msgid "Operating system and application image store." -msgstr "" - -#: ./doc/arch-design/storage_focus/section_introduction_storage_focus.xml:59(para) -msgid "Media streaming." -msgstr "" - -#: ./doc/arch-design/storage_focus/section_introduction_storage_focus.xml:62(para) -msgid "Databases." -msgstr "" - -#: ./doc/arch-design/storage_focus/section_introduction_storage_focus.xml:65(para) -msgid "Content distribution." -msgstr "" - -#: ./doc/arch-design/storage_focus/section_introduction_storage_focus.xml:68(para) -msgid "Cloud storage peering." -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:26(None) @@ -5936,7 +5948,7 @@ msgid "Selection of a commercially supported hypervisor, such as Microsoft Hyper msgstr "" #: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:433(para) -msgid "Whichever hypervisor is chosen, the staff needs to have appropriate training and knowledge to support the selected OS and hypervisor combination. If they do not training will need to be provided, which could have a cost impact on the design. Another aspect to consider would be the support for the OS-hypervisor. The support of a commercial product such as Redhat, Suse, or Windows, is the responsibility of the OS vendor. If an Open Source platform is chosen, the support comes from in-house resources. Either decision has a cost that will have an impact on the design." +msgid "Whichever hypervisor is chosen, the staff needs to have appropriate training and knowledge to support the selected OS and hypervisor combination. If they do not training will need to be provided, which could have a cost impact on the design. Another aspect to consider would be the support for the OS-hypervisor. 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. Either decision has a cost that will have an impact on the design." msgstr "" #: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:450(para) diff --git a/doc/common/locale/fr.po b/doc/common/locale/fr.po index 5658fbbc72..0937423c1d 100644 --- a/doc/common/locale/fr.po +++ b/doc/common/locale/fr.po @@ -18,8 +18,8 @@ msgid "" msgstr "" "Project-Id-Version: OpenStack Manuals\n" -"POT-Creation-Date: 2014-08-03 23:07+0000\n" -"PO-Revision-Date: 2014-08-03 22:58+0000\n" +"POT-Creation-Date: 2014-08-04 20:36+0000\n" +"PO-Revision-Date: 2014-08-04 15:51+0000\n" "Last-Translator: openstackjenkins \n" "Language-Team: French (http://www.transifex.com/projects/p/openstack-manuals-i18n/language/fr/)\n" "MIME-Version: 1.0\n" @@ -6584,7 +6584,7 @@ msgstr "" #: ./doc/common/section_cli_overview.xml106(td) msgid "Data Processing" -msgstr "" +msgstr "Traitement des données en cours" #: ./doc/common/section_cli_overview.xml108(package) msgid "python-saharaclient" diff --git a/doc/glossary/locale/ja.po b/doc/glossary/locale/ja.po index 1bca296ab7..6550e0cbe0 100644 --- a/doc/glossary/locale/ja.po +++ b/doc/glossary/locale/ja.po @@ -6,9 +6,9 @@ msgid "" msgstr "" "Project-Id-Version: OpenStack Manuals\n" -"POT-Creation-Date: 2014-08-01 17:08+0000\n" -"PO-Revision-Date: 2014-08-01 12:22+0000\n" -"Last-Translator: openstackjenkins \n" +"POT-Creation-Date: 2014-08-04 20:36+0000\n" +"PO-Revision-Date: 2014-08-05 04:00+0000\n" +"Last-Translator: Tomoyuki KATO \n" "Language-Team: Japanese (http://www.transifex.com/projects/p/openstack-manuals-i18n/language/ja/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -6182,7 +6182,7 @@ msgstr "" #: ./doc/glossary/glossary-terms.xml6647(glossterm) msgid "role" -msgstr "" +msgstr "ロール" #: ./doc/glossary/glossary-terms.xml6649(primary) #: ./doc/glossary/glossary-terms.xml6664(primary) @@ -6548,13 +6548,13 @@ msgstr "" #: ./doc/glossary/glossary-terms.xml7031(glossterm) #: ./doc/glossary/glossary-terms.xml7035(secondary) msgid "session back end" -msgstr "" +msgstr "セッションバックエンド" #: ./doc/glossary/glossary-terms.xml7033(primary) #: ./doc/glossary/glossary-terms.xml7047(primary) #: ./doc/glossary/glossary-terms.xml7062(primary) msgid "sessions" -msgstr "" +msgstr "セッション" #: ./doc/glossary/glossary-terms.xml7039(para) msgid "" diff --git a/doc/image-guide/locale/ja.po b/doc/image-guide/locale/ja.po index aa178d702b..1b1dac4a35 100644 --- a/doc/image-guide/locale/ja.po +++ b/doc/image-guide/locale/ja.po @@ -5,8 +5,8 @@ msgid "" msgstr "" "Project-Id-Version: OpenStack Manuals\n" -"POT-Creation-Date: 2014-08-03 23:07+0000\n" -"PO-Revision-Date: 2014-08-04 05:40+0000\n" +"POT-Creation-Date: 2014-08-04 20:36+0000\n" +"PO-Revision-Date: 2014-08-05 03:50+0000\n" "Last-Translator: Tomoyuki KATO \n" "Language-Team: Japanese (http://www.transifex.com/projects/p/openstack-manuals-i18n/language/ja/)\n" "MIME-Version: 1.0\n" @@ -298,7 +298,7 @@ msgid "" " command to edit it, and the command to " "make it executable. We add the following line to the file " "and save it:Then we set to executable: " -msgstr "" +msgstr "このイメージの起動時に 8021q カーネルを読み込むために、イメージを編集したい場合、/etc/sysconfig/modules/ ディレクトリに実行可能なスクリプトを作成する必要があります。 guestfish コマンドを使用して空のファイルを作成し、 コマンドを使用して編集できます。そして、 コマンドを使用して実行可能にします。以下の行をファイルに追加し、保存します。続けて、実行可能にします。" #: ./doc/image-guide/ch_modifying_images.xml108(para) msgid "" @@ -317,7 +317,7 @@ msgid "" "you read the guestfs-recipes documentation page for a sense of what is possible" " with these tools." -msgstr "" +msgstr "guestfish には、非常にさまざまな機能がありますが、このドキュメントの範囲を超えています。これらのツールを用いて実行できることは、\nguestfs-recipes を参照することを推奨します。" #: ./doc/image-guide/ch_modifying_images.xml124(title) msgid "guestmount" @@ -328,7 +328,7 @@ msgid "" "For some types of changes, you may find it easier to mount the image's file " "system directly in the guest. The program, also from the " "libguestfs project, allows you to do so." -msgstr "" +msgstr "いくつかの種類の変更の場合、イメージのファイルシステムを直接マウントするほうが簡単かもしれません。libguestfs プロジェクトの プログラムにより実行できます。" #: ./doc/image-guide/ch_modifying_images.xml129(para) msgid "" @@ -535,7 +535,7 @@ msgstr "1 番目のブロックデバイス (/dev/nbd0) が msgid "" "If the image has, say three partitions (/boot, /, swap), there should be one" " new device created for each partition:" -msgstr "" +msgstr "イメージがいわゆる 3 パーティション (/boot、/、swap) を持つ場合、パーティションごとに 1 つの新しいデバイスにすべきです。" #: ./doc/image-guide/ch_modifying_images.xml357(para) msgid "" @@ -2211,7 +2211,7 @@ msgid "" "(/boot, /, swap), and this will " "work fine. Alternatively, you may wish to create a single ext4 partition, " "mounted to \"/\", should also work fine." -msgstr "" +msgstr "ディスクのパーティションは、さまざまな選択肢があります。デフォルトは、うまく動作する LVM パーティションを使用し、3 つのパーティション (/boot、/、swap) を作成します。この代わりに、単一の ext4 パーティション を作成し、/ にマウントすることもうまく動作するでしょう。" #: ./doc/image-guide/section_ubuntu-example.xml67(para) msgid "" @@ -3054,11 +3054,11 @@ msgstr "" msgid "" "To verify that the libvirt \"default\" network is enabled, use the " " command and verify that the \"default\" network is active:" -msgstr "" +msgstr "libvirt の「default」ネットワークが有効化されていることを確認するために、 コマンドを使用して、「default」ネットワークが有効であることを確認します。" #: ./doc/image-guide/ch_creating_images_manually.xml50(para) msgid "If the network is not active, start it by doing:" -msgstr "" +msgstr "ネットワークが動作していない場合、以下を実行して起動します。" #: ./doc/image-guide/ch_creating_images_manually.xml54(title) msgid "Use the virt-manager X11 GUI"