Imported Translations from Transifex
Change-Id: Id87fe7f853241ab9886ddc55ad822a5848c51af7
This commit is contained in:
OpenStack Proposal Bot
parent
5b8222aeb1
commit
d699ac35c2
@ -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-03 06:09+0000\n"
|
||||
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
|
||||
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
|
||||
"Language-Team: LANGUAGE <LL@li.org>\n"
|
||||
@ -1161,7 +1161,7 @@ msgstr ""
|
||||
msgid "Just as tenants in a single-site deployment need isolation from each other, so do tenants in multi-site installations. The extra challenges in multi-site designs revolve around ensuring that tenant networks function across regions. Unfortunately, OpenStack Networking does not presently support a mechanism to provide this functionality, therefore an external system may be necessary to manage these mappings. Tenant networks may contain sensitive information requiring that this mapping be accurate and consistent to ensure that a tenant in one site does not connect to a different tenant in another site."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:169(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:611(para) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:725(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:404(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:526(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:665(title) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:360(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:394(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:512(title)
|
||||
#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:169(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:611(para) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:725(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:404(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:311(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:396(title) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:360(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:394(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:512(title)
|
||||
msgid "OpenStack components"
|
||||
msgstr ""
|
||||
|
||||
@ -2117,7 +2117,7 @@ msgstr ""
|
||||
msgid "Object storage resource nodes have no requirements for hardware fault tolerance or RAID controllers. It is not necessary to plan for fault tolerance within the object storage hardware because the object storage service provides replication between zones as a feature of the service. Block storage nodes, compute nodes and cloud controllers should all have fault tolerance built in at the hardware level by making use of hardware RAID controllers and varying levels of RAID configuration. The level of RAID chosen should be consistent with the performance and availability requirements of the cloud."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:461(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:403(title)
|
||||
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:461(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:241(title)
|
||||
msgid "Selecting networking hardware"
|
||||
msgstr ""
|
||||
|
||||
@ -2129,7 +2129,7 @@ msgstr ""
|
||||
msgid "As an example, selecting Cisco networking hardware implies that the architecture will be using Cisco networking software like IOS or NX-OS. Conversely, selecting Arista networking hardware means the network devices will use the Arista networking software called Extensible Operating System (EOS). In addition, there are more subtle design impacts that need to be considered. The selection of certain networking hardware (and therefore the networking software) could affect the management tools that can be used. There are exceptions to this; the rise of \"open\" networking software that supports a range of networking hardware means that there are instances where the relationship between networking hardware and networking software are not as tightly defined. An example of this type of software is Cumulus Linux, which is capable of running on a number of switch vendor’s hardware solutions."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:487(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:404(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:315(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:487(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:242(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:315(para)
|
||||
msgid "Some of the key considerations that should be included in the selection of networking hardware include:"
|
||||
msgstr ""
|
||||
|
||||
@ -2193,7 +2193,7 @@ msgstr ""
|
||||
msgid "To ensure that access to nodes within the cloud is not interrupted, it is recommended that the network architecture identify any single points of failure and provide some level of redundancy or fault tolerance. With regard to the network infrastructure itself, this often involves use of networking protocols such as LACP, VRRP or others to achieve a highly available network connection. In addition, it is important to consider the networking implications on API availability. In order to ensure that the APIs, and potentially other services in the cloud are highly available, it is recommended to design load balancing solutions within the network architecture to accommodate for these requirements."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:603(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:294(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:515(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:386(title)
|
||||
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:603(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:294(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:303(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:386(title)
|
||||
msgid "Software selection"
|
||||
msgstr ""
|
||||
|
||||
@ -2201,15 +2201,15 @@ msgstr ""
|
||||
msgid "Software selection for a general purpose OpenStack architecture design needs to include these three areas:"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:608(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:523(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:391(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:608(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:308(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:391(para)
|
||||
msgid "Operating system (OS) and hypervisor"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:614(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:435(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:529(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:739(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:397(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:562(title)
|
||||
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:614(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:435(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:314(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:448(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:397(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:562(title)
|
||||
msgid "Supplemental software"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:619(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:538(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:403(title)
|
||||
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:619(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:321(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:403(title)
|
||||
msgid "Operating system and hypervisor"
|
||||
msgstr ""
|
||||
|
||||
@ -2217,7 +2217,7 @@ msgstr ""
|
||||
msgid "The selection of operating system (OS) and hypervisor has a tremendous impact on the overall design. Selecting a particular operating system and hypervisor can also directly affect server hardware selection. It is recommended to make sure the storage hardware selection and topology support the selected operating system and hypervisor combination. Finally, it is important to ensure that the networking hardware selection and topology will work with the chosen operating system and hypervisor combination. For example, if the design uses Link Aggregation Control Protocol (LACP), the OS and hypervisor both need to support it."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:632(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:554(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:413(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:632(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:332(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:413(para)
|
||||
msgid "Some areas that could be impacted by the selection of OS and hypervisor include:"
|
||||
msgstr ""
|
||||
|
||||
@ -2285,7 +2285,7 @@ msgstr ""
|
||||
msgid "While OpenStack is a fairly complete collection of software projects for building a platform for cloud services, there are invariably additional pieces of software that need to be considered in any given OpenStack design."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:755(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:747(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:568(title)
|
||||
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:755(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:454(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:568(title)
|
||||
msgid "Networking software"
|
||||
msgstr ""
|
||||
|
||||
@ -2297,11 +2297,11 @@ msgstr ""
|
||||
msgid "For a general purpose OpenStack cloud, the OpenStack infrastructure components will need to be highly available. If the design does not include hardware load balancing, networking software packages like HAProxy will need to be included."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:774(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:771(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:585(title)
|
||||
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:774(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:468(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:585(title)
|
||||
msgid "Management software"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:775(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:772(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:775(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:469(para)
|
||||
msgid "The selected supplemental software solution impacts and affects the overall OpenStack cloud design. This includes software for providing clustering, logging, monitoring and alerting."
|
||||
msgstr ""
|
||||
|
||||
@ -2321,11 +2321,11 @@ msgstr ""
|
||||
msgid "OS-hypervisor combination: Ensure that the selected logging, monitoring, or alerting tools support the proposed OS-hypervisor combination."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:813(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:834(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:625(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:813(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:500(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:625(para)
|
||||
msgid "Network hardware: The network hardware selection needs to be supported by the logging, monitoring, and alerting software."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:820(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:843(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:631(title)
|
||||
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:820(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:506(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:631(title)
|
||||
msgid "Database software"
|
||||
msgstr ""
|
||||
|
||||
@ -2505,7 +2505,7 @@ msgstr ""
|
||||
msgid "Guarantees for API availability imply multiple infrastructure services combined with highly available load balancers."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:32(para) ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:26(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:32(para) ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:24(para)
|
||||
msgid "Network uptime guarantees will affect the switch design and might require redundant switching and power."
|
||||
msgstr ""
|
||||
|
||||
@ -2513,7 +2513,7 @@ msgstr ""
|
||||
msgid "Network security policies requirements need to be factored in to deployments."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:42(title) ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:39(title)
|
||||
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:42(title) ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:36(title)
|
||||
msgid "Support and maintainability"
|
||||
msgstr ""
|
||||
|
||||
@ -2529,7 +2529,7 @@ msgstr ""
|
||||
msgid "Consider incorporating features into the architecture and design that reduce the operations burden. This is accomplished by automating some of the operations functions. In some cases it may be beneficial to use a third party management company with special expertise in managing OpenStack deployments."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:64(title) ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:61(title) ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:126(title)
|
||||
#: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:64(title) ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:59(title) ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:126(title)
|
||||
msgid "Monitoring"
|
||||
msgstr ""
|
||||
|
||||
@ -3425,27 +3425,27 @@ msgstr ""
|
||||
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:22(para)
|
||||
#: ./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:25(para)
|
||||
#: ./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:29(para)
|
||||
#: ./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:33(para)
|
||||
#: ./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:36(para)
|
||||
#: ./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:40(para)
|
||||
#: ./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 ""
|
||||
|
||||
@ -3453,47 +3453,47 @@ msgstr ""
|
||||
msgid "Operationally, there are a number of considerations that affect the design of compute-focused OpenStack clouds. Some examples might include enforcing strict API availability requirements, understanding and dealing with failure scenarios, or managing host maintenance schedules."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:14(para)
|
||||
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:13(para)
|
||||
msgid "Service-level agreements (SLAs) are a contractual obligation that gives assurances around availability of a provided service. As such, factoring in promises of availability implies a certain level of redundancy and resiliency when designing an OpenStack cloud."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:21(para)
|
||||
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:19(para)
|
||||
msgid "Guarantees for API availability imply multiple infrastructure services combined with appropriately high available load balancers."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:31(para)
|
||||
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:28(para)
|
||||
msgid "Network security policy requirements need to be factored in to deployments."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:35(para)
|
||||
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:32(para)
|
||||
msgid "Knowing when and where to implement redundancy and high availability (HA) is directly affected by terms contained in any associated SLA, if one is present."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:40(para)
|
||||
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:37(para)
|
||||
msgid "OpenStack cloud management requires operations staff to be able to understand and comprehend design architecture content on some level. The level of skills and the level of separation of the operations and engineering staff is dependent on the size and purpose of the installation. A large cloud service provider or a telecom provider is more inclined to be managed by specially trained dedicated operations organization. A smaller implementation is more inclined to rely on a smaller support staff that might need to take on the combined engineering, design and operations functions."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:50(para)
|
||||
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:47(para)
|
||||
msgid "Maintaining OpenStack installations require a variety of technical skills. Some of these skills may include the ability to debug Python log output to a basic level as well as an understanding of networking concepts."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:54(para)
|
||||
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:51(para)
|
||||
msgid "Consider incorporating features into the architecture and design that reduce the operational burden. Some examples include automating some of the operations functions, or alternatively exploring the possibility of using a third party management company with special expertise in managing OpenStack deployments."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:62(para)
|
||||
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:60(para)
|
||||
msgid "Like any other infrastructure deployment, OpenStack clouds need an appropriate monitoring platform to ensure errors are caught and managed appropriately. Consider leveraging any existing monitoring system to see if it will be able to effectively monitor an OpenStack environment. While there are many aspects that need to be monitored, specific metrics that are critically important to capture include image disk utilization, or response time to the Compute API."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:71(title)
|
||||
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:70(title)
|
||||
msgid "Expected and unexpected server downtime"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:72(para)
|
||||
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:71(para)
|
||||
msgid "At some point, servers will fail. The SLAs in place affect how the design has to address recovery time. Recovery of a failed host may mean restoring instances from a snapshot, or respawning that instance on another available host, which then has consequences on the overall application design running on the OpenStack cloud."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:78(para)
|
||||
#: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:77(para)
|
||||
msgid "It might be acceptable to design a compute-focused cloud without the ability to migrate instances from one host to another, because the expectation is that the application developer must handle failure within the application itself. Conversely, a compute-focused cloud might be provisioned to provide extra resilience as a requirement of that business. In this scenario, it is expected that extra supporting services are also deployed, such as shared storage attached to hosts to aid in recovery and resiliency of services in order to meet strict SLAs."
|
||||
msgstr ""
|
||||
|
||||
@ -3573,275 +3573,275 @@ msgstr ""
|
||||
msgid "In a compute-focused OpenStack cloud the hardware selection must reflect the workloads being compute intensive. Compute-focused is defined as having extreme demands on processor and memory resources. The hardware selection for a compute-focused OpenStack architecture design must reflect this preference for compute-intensive workloads, as these workloads are not storage intensive, nor are they consistently network intensive. The network and storage may be heavily utilized while loading a data set into the computational cluster, but they are not otherwise intensive."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:39(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:156(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:30(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:156(para)
|
||||
msgid "Compute (server) hardware must be evaluated against four opposing dimensions:"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:45(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:34(para)
|
||||
msgid "Server density: A measure of how many servers can fit into a given measure of physical space, such as a rack unit [U]."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:52(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:38(para)
|
||||
msgid "Resource capacity: The number of CPU cores, how much RAM, or how much storage a given server will deliver."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:59(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:42(para)
|
||||
msgid "Expandability: The number of additional resources that can be added to a server before it has reached its limit."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:66(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:46(para)
|
||||
msgid "Cost: The relative purchase price of the hardware weighted against the level of design effort needed to build the system."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:73(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:50(para)
|
||||
msgid "The dimensions need to be weighted against each other to determine the best design for the desired purpose. For example, increasing server density means sacrificing resource capacity or expandability. Increasing resource capacity and expandability can increase cost but decreases server density. Decreasing cost can mean decreasing supportability, server density, resource capacity, and expandability."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:86(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:56(para)
|
||||
msgid "Selection of hardware for a compute-focused cloud should have an emphasis on server hardware that can offer more CPU sockets, more CPU cores, and more RAM; network connectivity and storage capacity are less critical. The hardware will need to be configured to provide enough network connectivity and storage capacity to meet minimum user requirements, but they are not the primary consideration."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:99(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:62(para)
|
||||
msgid "Some server hardware form factors are better suited than others, as CPU and RAM capacity have the highest priority."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:106(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:66(para)
|
||||
msgid "Most blade servers can support dual-socket multi-core CPUs. To avoid the limit means selecting \"full width\" or \"full height\" blades, which consequently loses server density. As an example, using high density blade servers including HP BladeSystem and Dell PowerEdge M1000e) which support up to 16 servers in only 10 rack units using half-height blades, suddenly decreases the density by 50% by selecting full-height blades resulting in only 8 servers per 10 rack units."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:125(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:76(para)
|
||||
msgid "1U rack-mounted servers (servers that occupy only a single rack unit) may be able to offer greater server density than a blade server solution. It is possible to place 40 servers in a rack, providing space for the top of rack [ToR] switches, versus 32 \"full width\" or \"full height\" blade servers in a rack), but often are limited to dual-socket, multi-core CPU configurations. Note that, as of the Icehouse release, neither HP, IBM, nor Dell offered 1U rack servers with more than 2 CPU sockets. To obtain greater than dual-socket support in a 1U rack-mount form factor, customers need to buy their systems from Original Design Manufacturers (ODMs) or second-tier manufacturers. This may cause issues for organizations that have preferred vendor policies or concerns with support and hardware warranties of non-tier 1 vendors."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:153(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:91(para)
|
||||
msgid "2U rack-mounted servers provide quad-socket, multi-core CPU support, but with a corresponding decrease in server density (half the density offered by 1U rack-mounted servers)."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:162(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:96(para)
|
||||
msgid "Larger rack-mounted servers, such as 4U servers, often provide even greater CPU capacity, commonly supporting four or even eight CPU sockets. These servers have greater expandability, but such servers have much lower server density and usually greater hardware cost."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:173(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:103(para)
|
||||
msgid "\"Sled servers\" (rack-mounted servers that support multiple independent servers in a single 2U or 3U enclosure) deliver increased density as compared to typical 1U or 2U rack-mounted servers. For example, many sled servers offer four independent dual-socket nodes in 2U for a total of 8 CPU sockets in 2U. However, the dual-socket limitation on individual nodes may not be sufficient to offset their additional cost and configuration complexity."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:191(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:112(para)
|
||||
msgid "The following facts will strongly influence server hardware selection for a compute-focused OpenStack design architecture:"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:197(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:117(para)
|
||||
msgid "Instance density: In this architecture instance density is considered lower; therefore CPU and RAM over-subscription ratios are also lower. More hosts will be required to support the anticipated scale due to instance density being lower, especially if the design uses dual-socket hardware designs."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:210(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:124(para)
|
||||
msgid "Host density: Another option to address the higher host count that might be needed with dual socket designs is to use a quad socket platform. Taking this approach will decrease host density, which increases rack count. This configuration may affect the network requirements, the number of power connections, and possibly impact the cooling requirements."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:223(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:132(para)
|
||||
msgid "Power and cooling density: The power and cooling density requirements might be lower than with blade, sled, or 1U server designs because of lower host density (by using 2U, 3U or even 4U server designs). For data centers with older infrastructure, this may be a desirable feature."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:235(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:139(para)
|
||||
msgid "Compute-focused OpenStack design architecture server hardware selection results in a \"scale up\" versus \"scale out\" decision. Selecting a better solution, smaller number of larger hosts, or a larger number of smaller hosts depends on a combination of factors: cost, power, cooling, physical rack and floor space, support-warranty, and manageability."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:248(title)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:146(title)
|
||||
msgid "Storage hardware selection"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:249(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:147(para)
|
||||
msgid "For a compute-focused OpenStack design architecture, the selection of storage hardware is not critical as it is not primary criteria, however it is still important. There are a number of different factors that a cloud architect must consider:"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:259(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:153(para)
|
||||
msgid "Cost: The overall cost of the solution will play a major role in what storage architecture (and resulting storage hardware) is selected."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:265(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:158(para)
|
||||
msgid "Performance: The performance of the solution is also a big role and can be measured by observing the latency of storage I-O requests. In a compute-focused OpenStack cloud, storage latency can be a major consideration. In some compute-intensive workloads, minimizing the delays that the CPU experiences while fetching data from the storage can have a significant impact on the overall performance of the application."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:279(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:167(para)
|
||||
msgid "Scalability: This section will refer to the term \"scalability\" to refer to how well the storage solution performs as it is expanded up to its maximum size. A storage solution that performs well in small configurations but has degrading performance as it expands would not be considered scalable. On the other hand, a solution that continues to perform well at maximum expansion would be considered scalable."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:293(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:176(para)
|
||||
msgid "Expandability: Expandability refers to the overall ability of the solution to grow. A storage solution that expands to 50 PB is considered more expandable than a solution that only scales to 10PB. Note that this metric is related to, but different from, scalability, which is a measure of the solution's performance as it expands."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:306(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:184(para)
|
||||
msgid "For a compute-focused OpenStack cloud, latency of storage is a major consideration. Using solid-state disks (SSDs) to minimize latency for instance storage and reduce CPU delays caused by waiting for the storage will increase performance. Consider using RAID controller cards in compute hosts to improve the performance of the underlying disk subsystem."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:318(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:190(para)
|
||||
msgid "The selection of storage architecture, and the corresponding storage hardware (if there is the option), is determined by evaluating possible solutions against the key factors listed above. This will determine if a scale-out solution (such as Ceph, GlusterFS, or similar) should be used, or if a single, highly expandable and scalable centralized storage array would be a better choice. If a centralized storage array is the right fit for the requirements, the hardware will be determined by the array vendor. It is also possible to build a storage array using commodity hardware with Open Source software, but there needs to be access to people with expertise to build such a system. Conversely, a scale-out storage solution that uses direct-attached storage (DAS) in the servers may be an appropriate choice. If so, then the server hardware needs to be configured to support the storage solution."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:348(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:204(para)
|
||||
msgid "The following lists some of the potential impacts that may affect a particular storage architecture, and the corresponding storage hardware, of a compute-focused OpenStack cloud:"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:356(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:209(para)
|
||||
msgid "Connectivity: Based on the storage solution selected, ensure the connectivity matches the storage solution requirements. If a centralized storage array is selected, it is important to determine how the hypervisors will connect to the storage array. Connectivity could affect latency and thus performance, so check that the network characteristics will minimize latency to boost the overall performance of the design."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:370(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:218(para)
|
||||
msgid "Latency: Determine if the use case will have consistent or highly variable latency."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:375(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:222(para)
|
||||
msgid "Throughput: To improve overall performance, make sure that the storage solution throughout is optimized. While it is not likely that a compute-focused cloud will have major data I-O to and from storage, this is an important factor to consider."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:382(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:228(para)
|
||||
msgid "Server Hardware: If the solution uses DAS, this impacts, and is not limited to, the server hardware choice that will ripple into host density, instance density, power density, OS-hypervisor, and management tools."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:391(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:234(para)
|
||||
msgid "Where instances need to be made highly available, or they need to be capable of migration between hosts, use of a shared storage file-system to store instance ephemeral data should be employed to ensure that compute services can run uninterrupted in the event of a node failure."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:410(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:246(para)
|
||||
msgid "Port count: The design will require networking hardware that has the requisite port count."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:416(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:250(para)
|
||||
msgid "Port density: The network design will be affected by the physical space that is required to provide the requisite port count. A switch that can provide 48 10 GbE ports in 1U has a much higher port density than a switch that provides 24 10 GbE ports in 2U. A higher port density is preferred, as it leaves more rack space for compute or storage components that might be required by the design. This also leads into concerns about fault domains and power density that must also be considered. Higher density switches are more expensive and should also be considered, as it is important not to over design the network if it is not required."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:440(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:262(para)
|
||||
msgid "Port speed: The networking hardware must support the proposed network speed, for example: 1 GbE, 10 GbE, or 40 GbE (or even 100 GbE)."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:448(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:267(para)
|
||||
msgid "Redundancy: The level of network hardware redundancy required is influenced by the user requirements for high availability and cost considerations. Network redundancy can be achieved by adding redundant power supplies or paired switches. If this is a requirement, the hardware will need to support this configuration. User requirements will determine if a completely redundant network infrastructure is required."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:464(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:276(para)
|
||||
msgid "Power requirements: Ensure that the physical data center provides the necessary power for the selected network hardware. This is not an issue for top of rack (ToR) switches, but may be an issue for spine switches in a leaf and spine fabric, or end of row (EoR) switches."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:476(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:283(para)
|
||||
msgid "It is important to first understand additional factors as well as the use case because these additional factors heavily influence the cloud network architecture. Once these key considerations have been decided, the proper network can be designed to best serve the workloads being placed in the cloud."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:487(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:288(para)
|
||||
msgid "It is recommended that the network architecture is designed using a scalable network model that makes it easy to add capacity and bandwidth. A good example of such a model is the leaf-spline model. In this type of network design, it is possible to easily add additional bandwidth as well as scale out to additional racks of gear. It is important to select network hardware that will support the required port count, port speed and port density while also allowing for future growth as workload demands increase. It is also important to evaluate where in the network architecture it is valuable to provide redundancy. Increased network availability and redundancy comes at a cost, therefore it is recommended to weigh the cost versus the benefit gained from utilizing and deploying redundant network switches and using bonded interfaces at the host level."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:516(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:304(para)
|
||||
msgid "Selecting software to be included in a compute-focused OpenStack architecture design must include three main areas:"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:532(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:317(para)
|
||||
msgid "Design decisions made in each of these areas impact the rest of the OpenStack architecture design."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:539(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:322(para)
|
||||
msgid "The selection of operating system (OS) and hypervisor has a significant impact on the end point design. Selecting a particular operating system and hypervisor could affect server hardware selection. For example, a selected combination needs to be supported on the selected hardware. Ensuring the storage hardware selection and topology supports the selected operating system and hypervisor combination should also be considered. Additionally, make sure that the networking hardware selection and topology will work with the chosen operating system and hypervisor combination. For example, if the design uses Link Aggregation Control Protocol (LACP), the hypervisor needs to support it."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:559(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:336(para)
|
||||
msgid "Cost: Selecting a commercially supported hypervisor such as Microsoft Hyper-V will result in a different cost model rather than chosen a community-supported open source hypervisor like Kinstance or Xen. Even within the ranks of open source solutions, choosing Ubuntu over Red Hat (or vice versa) will have an impact on cost due to support contracts. On the other hand, business or application requirements might dictate a specific or commercially supported hypervisor."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:577(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:346(para)
|
||||
msgid "Supportability: Depending on the selected hypervisor, the staff should have the appropriate training and knowledge to support the selected OS and hypervisor combination. If they do not, training will need to be provided which could have a cost impact on the design."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:590(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:353(para)
|
||||
msgid "Management tools: The management tools used for Ubuntu and Kinstance differ from the management tools for VMware vSphere. Although both OS and hypervisor combinations are supported by OpenStack, there will be very different impacts to the rest of the design as a result of the selection of one combination versus the other."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:604(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:361(para)
|
||||
msgid "Scale and performance: Ensure that selected OS and hypervisor combinations meet the appropriate scale and performance requirements. The chosen architecture will need to meet the targeted instance-host ratios with the selected OS-hypervisor combination."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:615(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:368(para)
|
||||
msgid "Security: Ensure that the design can accommodate the regular periodic installation of application security patches while maintaining the required workloads. The frequency of security patches for the proposed OS - hypervisor combination will have an impact on performance and the patch installation process could affect maintenance windows."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:629(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:376(para)
|
||||
msgid "Supported features: Determine what features of OpenStack are required. This will often determine the selection of the OS-hypervisor combination. Certain features are only available with specific OSs or hypervisors. For example, if certain features are not available, the design might need to be modified to meet the user requirements."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:644(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:384(para)
|
||||
msgid "Interoperability: Consideration should be given to the ability of the selected OS-hypervisor combination to interoperate or co-exist with other OS-hypervisors, or other software solutions in the overall design (if required). Operational and troubleshooting tools for one OS-hypervisor combination may differ from the tools used for another OS-hypervisor combination and, as a result, the design will need to address if the two sets of tools need to interoperate."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:666(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:397(para)
|
||||
msgid "The selection of which OpenStack components will actually be included in the design and deployed has significant impact. There are certain components that will always be present, (Nova and Glance, for example) yet there are other services that might not need to be present. For example, a certain design may not require the Orchestration module. Omitting Heat would not typically have a significant impact on the overall design. However, if the architecture uses a replacement for OpenStack Swift for its storage component, this could potentially have significant impacts on the rest of the design."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:683(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:406(para)
|
||||
msgid "For a compute-focused OpenStack design architecture, the following components would be used:"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:688(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:410(para)
|
||||
msgid "Identity (Keystone)"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:691(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:413(para)
|
||||
msgid "Dashboard (Horizon)"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:694(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:416(para)
|
||||
msgid "Compute (Nova)"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:697(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:419(para)
|
||||
msgid "Object Storage (Swift, Ceph or a commercial solution)"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:702(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:422(para)
|
||||
msgid "Image (Glance)"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:705(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:425(para)
|
||||
msgid "Networking (Neutron)"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:708(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:428(para)
|
||||
msgid "Orchestration (Heat)"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:711(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:431(para)
|
||||
msgid "OpenStack Block Storage would potentially not be incorporated into a compute-focused design due to persistent block storage not being a significant requirement for the types of workloads that would be deployed onto instances running in a compute-focused cloud. However, there may be some situations where the need for performance dictates that a block storage component be used to improve data I-O."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:724(para)
|
||||
msgid "The exclusion of certain OpenStack components might also limit or constrain the functionality of other components. If a design opts to include the Orchestration module but exclude the Telemetry module, then the design will not be able to take advantage of Orchestration's auto scaling functionality (which relies on information from Telemetry). Due to the fact that you can use Orchestration to spin up a large number of instances to perform the compute-intensive processing, including Orchestration in a compute-focused architecture design is strongly recommended."
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:437(para)
|
||||
msgid "The exclusion of certain OpenStack components might also limit or constrain the functionality of other components. If a design opts to include the Orchestration module but exclude the Telemetry module, then the design will not be able to take advantage of Orchestration's aut scaling functionality (which relies on information from Telemetry). Due to the fact that you can use Orchestration to spin up a large number of instances to perform the compute-intensive processing, including Orchestration in a compute-focused architecture design is strongly recommended."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:740(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:449(para)
|
||||
msgid "While OpenStack is a fairly complete collection of software projects for building a platform for cloud services, there are invariably additional pieces of software that might need to be added to any given OpenStack design."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:748(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:455(para)
|
||||
msgid "OpenStack Networking provides a wide variety of networking services for instances. There are many additional networking software packages that might be useful to manage the OpenStack components themselves. Some examples include software to provide load balancing, network redundancy protocols, and routing daemons. Some of these software packages are described in more detail in the OpenStack HA Guide (refer to Chapter 8 of the OpenStack High Availability Guide)."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:761(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:462(para)
|
||||
msgid "For a compute-focused OpenStack cloud, the OpenStack infrastructure components will need to be highly available. If the design does not include hardware load balancing, networking software packages like HAProxy will need to be included."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:779(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:472(para)
|
||||
msgid "Inclusion of clustering Software, such as Corosync or Pacemaker, is determined primarily by the availability design requirements. Therefore, the impact of including (or not including) these software packages is primarily determined by the availability of the cloud infrastructure and the complexity of supporting the configuration after it is deployed. The OpenStack High Availability Guide provides more details on the installation and configuration of Corosync and Pacemaker, should these packages need to be included in the design."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:796(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:480(para)
|
||||
msgid "Requirements for logging, monitoring, and alerting are determined by operational considerations. Each of these sub-categories includes a number of various options. For example, in the logging sub-category one might consider Logstash, Splunk, Log Insight, or some other log aggregation-consolidation tool. Logs should be stored in a centralized location to make it easier to perform analytics against the data. Log data analytics engines can also provide automation and issue notification by providing a mechanism to both alert and automatically attempt to remediate some of the more commonly known issues."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:815(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:613(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:489(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:613(para)
|
||||
msgid "If any of these software packages are needed, then the design must account for the additional resource consumption (CPU, RAM, storage, and network bandwidth for a log aggregation solution, for example). Some other potential design impacts include:"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:826(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:495(para)
|
||||
msgid "OS - Hypervisor combination: Ensure that the selected logging, monitoring, or alerting tools support the proposed OS-hypervisor combination."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:844(para)
|
||||
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:507(para)
|
||||
msgid "A large majority of the OpenStack components require access to back-end database services to store state and configuration information. Selection of an appropriate back-end database that will satisfy the availability and fault tolerance requirements of the OpenStack services is required. OpenStack services support connecting to any database that is supported by the sqlalchemy Python drivers, however most common database deployments make use of mySQL or some variation of it. It is recommended that the database which provides back-end service within a general purpose cloud be made highly available using an available technology which can accomplish that goal. Some of the more common software solutions used include Galera, MariaDB and mySQL with multi-master replication."
|
||||
msgstr ""
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
msgid ""
|
||||
msgstr ""
|
||||
"Project-Id-Version: PACKAGE VERSION\n"
|
||||
"POT-Creation-Date: 2014-07-28 06:07+0000\n"
|
||||
"POT-Creation-Date: 2014-08-03 06:09+0000\n"
|
||||
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
|
||||
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
|
||||
"Language-Team: LANGUAGE <LL@li.org>\n"
|
||||
@ -922,7 +922,7 @@ msgid "Choose URL as the installation method."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/image-guide/section_centos-example.xml:87(para)
|
||||
msgid "Depending on the version of CentOS, the net installer requires that the user specify either a URL or the web site and a CentOS directory that corresponds to one of the CentOS mirrors. If the installer asks for a single URL, a valid URL might be <literal>http://mirror.umd/centos/6/os/x86_64</literal>."
|
||||
msgid "Depending on the version of CentOS, the net installer requires that the user specify either a URL or the web site and a CentOS directory that corresponds to one of the CentOS mirrors. If the installer asks for a single URL, a valid URL might be <literal>http://mirror.umd.edu/centos/6/os/x86_64</literal>."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/image-guide/section_centos-example.xml:92(para)
|
||||
|
||||
@ -5,8 +5,8 @@
|
||||
msgid ""
|
||||
msgstr ""
|
||||
"Project-Id-Version: OpenStack Manuals\n"
|
||||
"POT-Creation-Date: 2014-07-31 21:35+0000\n"
|
||||
"PO-Revision-Date: 2014-08-01 04:00+0000\n"
|
||||
"POT-Creation-Date: 2014-08-02 20:14+0000\n"
|
||||
"PO-Revision-Date: 2014-08-03 01:00+0000\n"
|
||||
"Last-Translator: Tomoyuki KATO <tomo@dream.daynight.jp>\n"
|
||||
"Language-Team: Japanese (http://www.transifex.com/projects/p/openstack-manuals-i18n/language/ja/)\n"
|
||||
"MIME-Version: 1.0\n"
|
||||
@ -287,7 +287,7 @@ msgid ""
|
||||
"remove the <literal>HWADDR</literal> line. The <placeholder-2/> command will"
|
||||
" copy the file to the host, invoke your editor, and then copy the file back."
|
||||
" <placeholder-3/>"
|
||||
msgstr ""
|
||||
msgstr "<placeholder-1/> <literal>HWADDR</literal> 行を削除するために、 <filename>ifcfg-eth0</filename> ファイルを編集したいです。<placeholder-2/> コマンドは、ファイルをホストにコピーし、エディターを実行し、ファイルを書き戻します。<placeholder-3/>"
|
||||
|
||||
#: ./doc/image-guide/ch_modifying_images.xml94(para)
|
||||
msgid ""
|
||||
@ -663,7 +663,7 @@ msgstr ""
|
||||
msgid ""
|
||||
"You now have a VM that boots from the downloaded install ISO and is "
|
||||
"connected to the blank virtual disk that you created previously."
|
||||
msgstr ""
|
||||
msgstr "これで、ダウンロードしたインストール ISO から起動し、前に作成した空の仮想ディスクを接続した、仮想マシンができました。"
|
||||
|
||||
#: ./doc/image-guide/section_freebsd-example.xml76(para)
|
||||
msgid ""
|
||||
@ -678,14 +678,14 @@ msgstr "プロンプト表示時、<guibutton>Install</guibutton> モードで I
|
||||
#: ./doc/image-guide/section_freebsd-example.xml84(para)
|
||||
msgid ""
|
||||
"Accept the default keymap or select an appropriate mapping for your needs."
|
||||
msgstr ""
|
||||
msgstr "デフォルトのキーマップを使用するか、必要に応じて適切なキーマップを選択します。"
|
||||
|
||||
#: ./doc/image-guide/section_freebsd-example.xml88(para)
|
||||
msgid ""
|
||||
"Provide a host name for your image. If you use <application>bsd-"
|
||||
"cloudinit</application>, it overrides this value with the name provided by "
|
||||
"OpenStack when an instance boots from this image."
|
||||
msgstr ""
|
||||
msgstr "イメージのホスト名を指定します。<application>bsd-cloudinit</application> を使用する場合、このイメージからインスタンスを起動するとき、OpenStack により提供される名前でこの名前を上書きします。"
|
||||
|
||||
#: ./doc/image-guide/section_freebsd-example.xml94(para)
|
||||
msgid ""
|
||||
@ -1081,7 +1081,7 @@ msgstr "AKI (Amazon Kernel Image)"
|
||||
msgid ""
|
||||
"A kernel file that the hypervisor will load initially to boot the image. For"
|
||||
" a Linux machine, this would be a <emphasis>vmlinuz</emphasis> file."
|
||||
msgstr ""
|
||||
msgstr "ハイパーバイザーがイメージを起動するために最初に読み込むカーネルファイル。Linux の場合、これは <emphasis>vmlinuz</emphasis> でしょう。"
|
||||
|
||||
#: ./doc/image-guide/ch_introduction.xml73(para)
|
||||
msgid "ARI (Amazon Ramdisk Image)"
|
||||
@ -1091,7 +1091,7 @@ msgstr "ARI (Amazon Ramdisk Image)"
|
||||
msgid ""
|
||||
"An optional ramdisk file mounted at boot time. For a Linux machine, this "
|
||||
"would be an <emphasis>initrd</emphasis> file."
|
||||
msgstr ""
|
||||
msgstr "起動時にマウントされる、オプションのラムディスクファイル。Linux の場合、これは <emphasis>initrd</emphasis> ファイルでしょう。"
|
||||
|
||||
#: ./doc/image-guide/ch_introduction.xml55(para)
|
||||
msgid ""
|
||||
@ -1356,8 +1356,8 @@ msgid ""
|
||||
" specify either a URL or the web site and a CentOS directory that "
|
||||
"corresponds to one of the CentOS mirrors. If the installer asks for a single"
|
||||
" URL, a valid URL might be "
|
||||
"<literal>http://mirror.umd/centos/6/os/x86_64</literal>."
|
||||
msgstr "CentOS のバージョンに依存して、ネットインストーラーは、ユーザーが CentOS ミラーのどれかに対応する、URL、または Web サイトと CentOS ディレクトリを指定する必要があります。インストーラーが URL の入力を求めた場合、<literal>http://mirror.umd/centos/6/os/x86_64</literal> が有効です。"
|
||||
"<literal>http://mirror.umd.edu/centos/6/os/x86_64</literal>."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/image-guide/section_centos-example.xml92(para)
|
||||
msgid ""
|
||||
|
||||
Loading…
Reference in New Issue
Block a user