Imported Translations from Transifex

For more information about this automatic import see:
https://wiki.openstack.org/wiki/Translations/Infrastructure

Change-Id: I149c2b1db33982f209acd6f7526689c07737c13e
This commit is contained in:
OpenStack Proposal Bot 2014-12-15 06:11:43 +00:00
parent a9080c1c9b
commit 25578bdedb
10 changed files with 294 additions and 224 deletions

View File

@ -1,7 +1,7 @@
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2014-12-13 06:12+0000\n"
"POT-Creation-Date: 2014-12-15 06:10+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"
@ -883,7 +883,7 @@ msgstr ""
msgid "Some applications are tolerant of the lack of synchronized object storage, while others may need those objects to be replicated and available across regions. Understanding of how the cloud implementation impacts new and existing applications is important for risk mitigation and the overall success of a cloud project. Applications may have to be written to expect an infrastructure with little to no redundancy. Existing applications not developed with the cloud in mind may need to be rewritten."
msgstr ""
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:139(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml: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:25(term) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:20(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:55(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:174(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:396(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/storage_focus/section_user_requirements_storage_focus.xml:16(term)
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:139(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:103(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:263(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:587(term) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:25(term) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:20(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:55(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:174(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:396(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/storage_focus/section_user_requirements_storage_focus.xml:16(term)
msgid "Cost"
msgstr ""
@ -1157,7 +1157,7 @@ msgstr ""
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:432(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:131(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:493(title) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:96(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:182(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/storage_focus/section_user_requirements_storage_focus.xml:105(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:432(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:391(term) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:131(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:493(title) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:96(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:182(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/storage_focus/section_user_requirements_storage_focus.xml:105(term)
msgid "Performance"
msgstr ""
@ -1173,7 +1173,7 @@ msgstr ""
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:163(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:686(term) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:200(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:671(title) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:160(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:440(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_tech_considerations_storage_focus.xml:50(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:471(term) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:123(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:634(term) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:200(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:671(title) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:160(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:440(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_tech_considerations_storage_focus.xml:50(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:471(term) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:123(term)
msgid "Security"
msgstr ""
@ -1189,7 +1189,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:727(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:414(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:371(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:477(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:564(para) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:671(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:414(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:371(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:477(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 ""
@ -1926,459 +1926,503 @@ msgid "Network"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:25(para)
msgid "For each of these areas, the selection of hardware for a general purpose OpenStack cloud must reflect the fact that a the cloud has no pre-defined usage model. This means that there will be a wide variety of applications running on this cloud that will have varying resource usage requirements. Some applications will be RAM-intensive, some applications will be CPU-intensive, while others will be storage-intensive. Therefore, choosing hardware for a general purpose OpenStack cloud must provide balanced access to all major resources."
msgid "Selecting hardware for a general purpose OpenStack cloud should reflect a cloud with no pre-defined usage model. General purpose clouds are designed to run a wide variety of applications with varying resource usage requirements. These applications include any of the following:"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:35(para)
msgid "Certain hardware form factors may be better suited for use in a general purpose OpenStack cloud because of the need for an equal or nearly equal balance of resources. Server hardware for a general purpose OpenStack architecture design must provide an equal or nearly equal balance of compute capacity (RAM and CPU), network capacity (number and speed of links), and storage capacity (gigabytes or terabytes as well as Input/Output Operations Per Second (<glossterm>IOPS</glossterm>)."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:32(para)
msgid "RAM-intensive"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:43(para)
msgid "Server hardware is evaluated around four conflicting dimensions:"
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:37(para)
msgid "CPU-intensive"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:48(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:34(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:160(term)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:42(para)
msgid "Storage-intensive"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:47(para)
msgid "Choosing hardware for a general purpose OpenStack cloud must provide balanced access to all major resources."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:49(para)
msgid "Certain hardware form factors may better suit a general purpose OpenStack cloud due to the requirement for equal (or nearly equal) balance of resources. Server hardware must provide the following:"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:55(para)
msgid "Equal (or nearly equal) balance of compute capacity (RAM and CPU)"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:60(para)
msgid "Network capacity (number and speed of links)"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:65(para)
msgid "Storage capacity (gigabytes or terabytes as well as Input/Output Operations Per Second (<glossterm>IOPS</glossterm>)"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:75(para)
msgid "Server hardware is evaluated around four conflicting dimensions."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:79(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:34(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:160(term)
msgid "Server density"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:50(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:36(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:162(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:81(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:36(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:162(para)
msgid "A measure of how many servers can fit into a given measure of physical space, such as a rack unit [U]."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:56(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:41(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:168(term)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:87(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:41(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:168(term)
msgid "Resource capacity"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:58(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:43(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:170(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:89(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:43(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:170(para)
msgid "The number of CPU cores, how much RAM, or how much storage a given server will deliver."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:64(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:281(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:48(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:206(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:76(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:176(term)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:95(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:289(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:48(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:206(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:76(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:176(term)
msgid "Expandability"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:66(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:50(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:178(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:97(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:50(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:178(para)
msgid "The number of additional resources that can be added to a server before it has reached its limit."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:74(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:57(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:105(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:57(para)
msgid "The relative purchase price of the hardware weighted against the level of design effort needed to build the system."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:80(para)
msgid "Increasing server density means sacrificing resource capacity or expandability, however, increasing resource capacity and expandability increases cost and decreases server density. As a result, determining the best server hardware for a general purpose OpenStack architecture means understanding how choice of form factor will impact the rest of the design."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:111(para)
msgid "Increasing server density means sacrificing resource capacity or expandability, however, increasing resource capacity and expandability increases cost and decreases server density. As a result, determining the best server hardware for a general purpose OpenStack architecture means understanding how choice of form factor will impact the rest of the design. The following list outlines the form factors to choose from:"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:89(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:121(para)
msgid "Blade servers typically support dual-socket multi-core CPUs, which is the configuration generally considered to be the \"sweet spot\" for a general purpose cloud deployment. Blades also offer outstanding density. As an example, both HP BladeSystem and Dell PowerEdge M1000e support up to 16 servers in only 10 rack units. However, the blade servers themselves often have limited storage and networking capacity. Additionally, the expandability of many blade servers can be limited."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:101(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:133(para)
msgid "1U rack-mounted servers occupy only a single rack unit. Their benefits include high density, support for dual-socket multi-core CPUs, and support for reasonable RAM amounts. This form factor offers limited storage capacity, limited network capacity, and limited expandability."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:109(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:141(para)
msgid "2U rack-mounted servers offer the expanded storage and networking capacity that 1U servers tend to lack, but with a corresponding decrease in server density (half the density offered by 1U rack-mounted servers)."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:116(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:148(para)
msgid "Larger rack-mounted servers, such as 4U servers, will tend to offer even greater CPU capacity, often supporting four or even eight CPU sockets. These servers often have much greater expandability so will provide the best option for upgradability. This means, however, that the servers have a much lower server density and a much greater hardware cost."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:125(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:157(para)
msgid "\"Sled servers\" are rack-mounted servers that support multiple independent servers in a single 2U or 3U enclosure. This form factor offers increased density over typical 1U-2U rack-mounted servers but tends to suffer from limitations in the amount of storage or network capacity each individual server supports."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:134(para)
msgid "Given the wide selection of hardware and general user requirements, the best form factor for the server hardware supporting a general purpose OpenStack cloud is driven by outside business and cost factors. No single reference architecture will apply to all implementations; the decision must flow out of the user requirements, technical considerations, and operational considerations. Here are some of the key factors that influence the selection of server hardware:"
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:166(para)
msgid "The best form factor for server hardware supporting a general purpose OpenStack cloud is driven by outside business and cost factors. No single reference architecture will apply to all implementations; the decision must flow from user requirements, technical considerations, and operational considerations. Here are some of the key factors that influence the selection of server hardware:"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:146(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:129(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:274(term)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:176(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:129(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:274(term)
msgid "Instance density"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:148(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:178(para)
msgid "Sizing is an important consideration for a general purpose OpenStack cloud. The expected or anticipated number of instances that each hypervisor can host is a common metric used in sizing the deployment. The selected server hardware needs to support the expected or anticipated instance density."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:158(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:139(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:284(term)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:188(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:139(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:284(term)
msgid "Host density"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:160(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:190(para)
msgid "Physical data centers have limited physical space, power, and cooling. The number of hosts (or hypervisors) that can be fitted into a given metric (rack, rack unit, or floor tile) is another important method of sizing. Floor weight is an often overlooked consideration. The data center floor must be able to support the weight of the proposed number of hosts within a rack or set of racks. These factors need to be applied as part of the host density calculation and server hardware selection."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:173(term)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:203(term)
msgid "Power density"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:175(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:205(para)
msgid "Data centers have a specified amount of power fed to a given rack or set of racks. Older data centers may have a power density as power as low as 20 AMPs per rack, while more recent data centers can be architected to support power densities as high as 120 AMP per rack. The selected server hardware must take power density into account."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:185(term)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:215(term)
msgid "Network connectivity"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:187(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:217(para)
msgid "The selected server hardware must have the appropriate number of network connections, as well as the right type of network connections, in order to support the proposed architecture. Ensure that, at a minimum, there are at least two diverse network connections coming into each rack. For architectures requiring even more redundancy, it might be necessary to confirm that the network connections are from diverse telecom providers. Many data centers have that capacity available."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:201(para)
msgid "The selection of certain form factors or architectures will affect the selection of server hardware. For example, if the design calls for a scale-out storage architecture (such as leveraging Ceph, Gluster, or a similar commercial solution), then the server hardware selection will need to be carefully considered to match the requirements set by the commercial solution. Ensure that the selected server hardware is configured to support enough storage capacity (or storage expandability) to match the requirements of selected scale-out storage solution. For example, if a centralized storage solution is required, such as a centralized storage array from a storage vendor that has InfiniBand or FDDI connections, the server hardware will need to have appropriate network adapters installed to be compatible with the storage array vendor's specifications."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:231(para)
msgid "The selection of form factors or architectures affects the selection of server hardware. For example, if the design is a scale-out storage architecture, then the server hardware selection will require careful consideration when matching the requirements set to the commercial solution."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:216(para)
msgid "Similarly, the network architecture will have an impact on the server hardware selection and vice versa. For example, make sure that the server is configured with enough additional network ports and expansion cards to support all of the networks required. There is variability in network expansion cards, so it is important to be aware of potential impacts or interoperability issues with other components in the architecture. This is especially true if the architecture uses InfiniBand or another less commonly used networking protocol."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:235(para)
msgid "Ensure that the selected server hardware is configured to support enough storage capacity (or storage expandability) to match the requirements of selected scale-out storage solution. For example, if a centralized storage solution is required, such as a centralized storage array from a storage vendor that has InfiniBand or FDDI connections, the server hardware will need to have appropriate network adapters installed to be compatible with the storage array vendor's specifications."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:227(title)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:244(para)
msgid "Similarly, the network architecture will have an impact on the server hardware selection and vice versa. For example, make sure that the server is configured with enough additional network ports and expansion cards to support all of the networks required. There is variability in network expansion cards, so it is important to be aware of potential impacts or interoperability issues with other components in the architecture."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:253(title)
msgid "Selecting storage hardware"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:228(para)
msgid "The selection of storage hardware is largely determined by the proposed storage architecture. Factors that need to be incorporated into the storage architecture include:"
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:254(para)
msgid "Storage hardware architecture is largely determined by the selected storage architecture. The selection of storage architecture, as well as the corresponding storage hardware, is determined by evaluating possible solutions against the critical factors, the user requirements, technical considerations, and operational considerations. Factors that need to be incorporated into the storage architecture include:"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:236(para)
msgid "Storage can be a significant portion of the overall system cost that should be factored into the design decision. For an organization that is concerned with vendor support, a commercial storage solution is advisable, although it is comes with a higher price tag. If initial capital expenditure requires minimization, designing a system based on commodity hardware would apply. The trade-off is potentially higher support costs and a greater risk of incompatibility and interoperability issues."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:265(para)
msgid "Storage can be a significant portion of the overall system cost. For an organization that is concerned with vendor support, a commercial storage solution is advisable, although it comes with a higher price tag. If initial capital expenditure requires minimization, designing a system based on commodity hardware would apply. The trade-off is potentially higher support costs and a greater risk of incompatibility and interoperability issues."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:251(para)
msgid "Storage performance, measured by observing the latency of storage I-O requests, is not a critical factor for a general purpose OpenStack cloud as overall systems performance is not a design priority."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:259(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:572(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:194(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:62(term)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:277(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:525(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:194(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:62(term)
msgid "Scalability"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:261(para)
msgid "The term \"scalability\" refers to how well the storage solution performs as it expands up to its maximum designed size. A solution that continues to perform well at maximum expansion is considered scalable. A storage solution that performs well in small configurations but has degrading performance as it expands was not designed to be not scalable. Scalability, along with expandability, is a major consideration in a general purpose OpenStack cloud. It might be difficult to predict the final intended size of the implementation because there are no established usage patterns for a general purpose cloud. Therefore, it may become necessary to expand the initial deployment in order to accommodate growth and user demand. The ability of the storage solution to continue to perform well as it expands is important."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:279(para)
msgid "Scalability, along with expandability, is a major consideration in a general purpose OpenStack cloud. It might be difficult to predict the final intended size of the implementation as there are no established usage patterns for a general purpose cloud. It might become necessary to expand the initial deployment in order to accommodate growth and user demand."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:283(para)
msgid "This refers to the overall ability of the solution to grow. A storage solution that expands to 50PB is considered more expandable than a solution that only scales to 10PB. This metric is related to, but different, from scalability, which is a measure of the solution's performance as it expands. Expandability is a major architecture factor for storage solutions with general purpose OpenStack cloud. For example, the storage architecture for a cloud that is intended for a development platform may not have the same expandability and scalability requirements as a cloud that is intended for a commercial product."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:291(para)
msgid "Expandability is a major architecture factor for storage solutions with general purpose OpenStack cloud. A storage solution that expands to 50PB is considered more expandable than a solution that only scales to 10PB. This metric is related to, but different, from scalability, which is a measure of the solution's performance as it expands. For example, the storage architecture for a cloud that is intended for a development platform may not have the same expandability and scalability requirements as a cloud that is intended for a commercial product."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:299(para)
msgid "Storage hardware architecture is largely determined by the selected storage architecture. The selection of storage architecture, as well as the corresponding storage hardware, is determined by evaluating possible solutions against the critical factors, the user requirements, technical considerations, and operational considerations. A combination of all the factors and considerations will determine which approach will be best."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:305(para)
msgid "Using a scale-out storage solution with direct-attached storage (DAS) in the servers is well suited for a general purpose OpenStack cloud. For example, it is possible to populate storage in either the compute hosts similar to a grid computing solution, or into hosts dedicated to providing block storage exclusively. When deploying storage in the compute hosts appropriate hardware, that can support both the storage and compute services on the same hardware, will be required."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:307(para)
msgid "Using a scale-out storage solution with direct-attached storage (DAS) in the servers is well suited for a general purpose OpenStack cloud. In this scenario, it is possible to populate storage in either the compute hosts similar to a grid computing solution or into hosts dedicated to providing block storage exclusively. When deploying storage in the compute hosts, appropriate hardware which can support both the storage and compute services on the same hardware will be required. This approach is referred to as a grid computing architecture because there is a grid of modules that have both compute and storage in a single box."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:313(para)
msgid "Understanding the requirements of cloud services will help determine what scale-out solution should be used. Determining if a single, highly expandable and highly vertical, scalable, centralized storage array should be included in the design. Once an approach has been determined, the storage hardware needs to be selected based on this criteria."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:318(para)
msgid "Understanding the requirements of cloud services will help determine if Ceph, Gluster, or a similar scale-out solution should be used. It can then be further determined if a single, highly expandable and highly vertical, scalable, centralized storage array should be included in the design. Once the approach has been determined, the storage hardware needs to be chosen based on this criteria. If a centralized storage array fits the requirements best, then the array vendor will determine the hardware. For cost reasons it may be decided to build an open source storage array using solutions such as OpenFiler, Nexenta Open Source, or BackBlaze Open Source."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:330(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:319(para)
msgid "This list expands upon the potential impacts for including a particular storage architecture (and corresponding storage hardware) into the design for a general purpose OpenStack cloud:"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:337(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:559(term) ./doc/arch-design/introduction/section_methodology.xml:182(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:242(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:116(term)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:325(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:512(term) ./doc/arch-design/introduction/section_methodology.xml:182(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:242(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:116(term)
msgid "Connectivity"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:339(para)
msgid "Ensure that, if storage protocols other than Ethernet are part of the storage solution, the appropriate hardware has been selected. Some examples include InfiniBand, FDDI and Fibre Channel. If a centralized storage array is selected, ensure that the hypervisor will be able to connect to that storage array for image storage."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:327(para)
msgid "Ensure that, if storage protocols other than Ethernet are part of the storage solution, the appropriate hardware has been selected. If a centralized storage array is selected, ensure that the hypervisor will be able to connect to that storage array for image storage."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:349(term)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:336(term)
msgid "Usage"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:351(para)
msgid "How the particular storage architecture will be used is critical for determining the architecture. Some of the configurations that will influence the architecture include whether it will be used by the hypervisors for ephemeral instance storage or if OpenStack Object Storage will use it for object storage. All of these usage models are affected by the selection of particular storage architecture and the corresponding storage hardware to support that architecture."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:338(para)
msgid "How the particular storage architecture will be used is critical for determining the architecture. Some of the configurations that will influence the architecture include whether it will be used by the hypervisors for ephemeral instance storage or if OpenStack Object Storage will use it for object storage."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:363(term)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:347(term)
msgid "Instance and image locations"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:365(para)
msgid "Where instances and images will be stored will influence the architecture. For example, instances can be stored in a number of options. OpenStack Block Storage is a good location for instances because it is persistent block storage, however, OpenStack Object Storage can be used if storage latency is less of a concern. The same argument applies to the appropriate image storage location."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:349(para)
msgid "Where instances and images will be stored will influence the architecture."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:378(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:145(term)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:355(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:145(term)
msgid "Server hardware"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:380(para)
msgid "If the solution is a scale-out storage architecture that includes DAS, naturally that will affect the server hardware selection. This could ripple into the decisions that affect host density, instance density, power density, OS-hypervisor, management tools and others."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:357(para)
msgid "If the solution is a scale-out storage architecture that includes DAS, it will affect the server hardware selection. This could ripple into the decisions that affect host density, instance density, power density, OS-hypervisor, management tools and others."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:389(para)
msgid "General purpose OpenStack cloud has multiple options. As a result, there is no single decision that will apply to all implementations. The key factors that will have an influence on selection of storage hardware for a general purpose OpenStack cloud are as follows:"
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:366(para)
msgid "General purpose OpenStack cloud has multiple options. The key factors that will have an influence on selection of storage hardware for a general purpose OpenStack cloud are as follows:"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:397(term)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:372(term)
msgid "Capacity"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:399(para)
msgid "Hardware resources selected for the resource nodes should be capable of supporting enough storage for the cloud services that will use them. It is important to clearly define the initial requirements and ensure that the design can support adding capacity as resources are used in the cloud, as workloads are relatively unknown. Hardware nodes selected for object storage should be capable of supporting a large number of inexpensive disks and should not have any reliance on RAID controller cards. Hardware nodes selected for block storage should be capable of supporting higher speed storage solutions and RAID controller cards to provide performance and redundancy to storage at the hardware level. Selecting hardware RAID controllers that can automatically repair damaged arrays will further assist with replacing and repairing degraded or destroyed storage devices within the cloud."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:374(para)
msgid "Hardware resources selected for the resource nodes should be capable of supporting enough storage for the cloud services. Defining the initial requirements and ensuring the design can support adding capacity is important. Hardware nodes selected for object storage should be capable of support a large number of inexpensive disks with no reliance on RAID controller cards. Hardware nodes selected for block storage should be capable of supporting high speed storage solutions and RAID controller cards to provide performance and redundancy to storage at a hardware level. Selecting hardware RAID controllers that automatically repair damaged arrays will assist with the replacement and repair of degraded or destroyed storage devices."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:422(para)
msgid "Disks selected for the object storage service do not need to be fast performing disks. We recommend that object storage nodes take advantage of the best cost per terabyte available for storage at the time of acquisition and avoid enterprise class drives. In contrast, disks chosen for the block storage service should take advantage of performance boosting features and may entail the use of SSDs or flash storage to provide for high performing block storage pools. Storage performance of ephemeral disks used for instances should also be taken into consideration. If compute pools are expected to have a high utilization of ephemeral storage or requires very high performance, it would be advantageous to deploy similar hardware solutions to block storage in order to increase the storage performance."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:393(para)
msgid "Disks selected for object storage services do not need to be fast performing disks. We recommend that object storage nodes take advantage of the best cost per terabyte available for storage. Contrastingly, disks chosen for block storage sevices should take advantage of performance boosting features that may entail the use of SSDs or flash storage to provide high performance block storage pools. Storage performance of ephemeral disks used for instances should also be taken into consideration. If compute pools are expected to have a high utilization of ephemeral storage, or requires very high performance, it would be advantageous to deploy similar hardware solutions to block storage."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:441(term)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:408(term)
msgid "Fault tolerance"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:443(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:410(para)
msgid "Object storage resource nodes have no requirements for hardware fault tolerance or RAID controllers. It is not necessary to plan for fault tolerance within the object storage hardware because the object storage service provides replication between zones as a feature of the service. Block storage nodes, compute nodes and cloud controllers should all have fault tolerance built in at the hardware level by making use of hardware RAID controllers and varying levels of RAID configuration. The level of RAID chosen should be consistent with the performance and availability requirements of the cloud."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:461(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:286(title)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:428(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:286(title)
msgid "Selecting networking hardware"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:462(para)
msgid "As is the case with storage architecture, selecting a network architecture often determines which network hardware will be used. The networking software in use is determined by the selected networking hardware. Some design impacts are obvious, for example, selecting networking hardware that only supports Gigabit Ethernet (GbE) will naturally have an impact on many different areas of the overall design. Similarly, deciding to use 10 Gigabit Ethernet (10GbE) has a number of impacts on various areas of the overall design."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:429(para)
msgid "Selecting network architecture determines which network hardware will be used. Networking software is determined by the selected networking hardware. For example, selecting networking hardware that only supports Gigabit Ethernet (GbE) will impact the overall design. Similarly, deciding to use 10 Gigabit Ethernet (10GbE) will have a number of impacts on various areas of the overall design."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:471(para)
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 vendors hardware solutions."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:436(para)
msgid "There are more subtle design impacts that need to be considered. The selection of certain networking hardware (and the networking software) affects the management tools that can be used. There are exceptions to this; the rise of \"open\" networking software that supports a range of networking hardware means that there are instances where the relationship between networking hardware and networking software are not as tightly defined. An example of this type of software is Cumulus Linux, which is capable of running on a number of switch vendors hardware solutions."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:487(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:287(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:315(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:446(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:287(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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:492(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:291(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:319(term)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:450(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:291(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:319(term)
msgid "Port count"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:494(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:293(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:452(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:293(para)
msgid "The design will require networking hardware that has the requisite port count."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:499(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:298(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:326(term)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:457(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:298(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:326(term)
msgid "Port density"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:501(para)
msgid "The network design will be affected by the physical space that is required to provide the requisite port count. A switch that can provide 48 10GbE ports in 1U has a much higher port density than a switch that provides 24 10GbE ports in 2U. A higher port density is preferred, as it leaves more rack space for compute or storage components that may be required by the design. This can also lead into concerns about fault domains and power density that should be considered. Higher density switches are more expensive and should also be considered, as it is important not to over design the network if it is not required."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:459(para)
msgid "The network design will be affected by the physical space that is required to provide the requisite port count. A higher port density is preferred, as it leaves more rack space for compute or storage components that may be required by the design. This can also lead into concerns about fault domains and power density that should be considered. Higher density switches are more expensive and should also be considered, as it is important not to over design the network if it is not required."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:517(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:313(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:342(term)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:472(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:313(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:342(term)
msgid "Port speed"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:519(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:344(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:474(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:344(para)
msgid "The networking hardware must support the proposed network speed, for example: 1GbE, 10GbE, or 40GbE (or even 100GbE)."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:527(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:321(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:350(term)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:481(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:321(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:350(term)
msgid "Redundancy"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:529(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:323(para)
msgid "The level of network hardware redundancy required is influenced by the user requirements for high availability and cost considerations. Network redundancy can be achieved by adding redundant power supplies or paired switches. If this is a requirement, the hardware will need to support this configuration. User requirements will determine if a completely redundant network infrastructure is required."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:483(para)
msgid "The level of network hardware redundancy required is influenced by the user requirements for high availability and cost considerations. Network redundancy can be achieved by adding redundant power supplies or paired switches. If this is a requirement, the hardware will need to support this configuration."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:540(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:333(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:363(term)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:492(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:333(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:363(term)
msgid "Power requirements"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:542(para)
msgid "Make sure 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."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:494(para)
msgid "Ensure that the physical data center provides the necessary power for the selected network hardware."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:551(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:498(para)
msgid "This may be an issue for spine switches in a leaf and spine fabric, or end of row (EoR) switches."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:505(para)
msgid "There is no single best practice architecture for the networking hardware supporting a general purpose OpenStack cloud that will apply to all implementations. Some of the key factors that will have a strong influence on selection of networking hardware include:"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:561(para)
msgid "All nodes within an OpenStack cloud require some form of network connectivity. In some cases, nodes require access to more than one network segment. The design must encompass sufficient network capacity and bandwidth to ensure that all communications within the cloud, both north-south and east-west traffic have sufficient resources available."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:514(para)
msgid "All nodes within an OpenStack cloud require network connectivity. In some cases, nodes require access to more than one network segment. The design must encompass sufficient network capacity and bandwidth to ensure that all communications within the cloud, both north-south and east-west traffic have sufficient resources available."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:574(para)
msgid "The chosen network design should encompass a physical and logical network design that can be easily expanded upon. Network hardware should offer the appropriate types of interfaces and speeds that are required by the hardware nodes."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:527(para)
msgid "The network design should encompass a physical and logical network design that can be easily expanded upon. Network hardware should offer the appropriate types of interfaces and speeds that are required by the hardware nodes."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:582(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:588(title) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:113(term)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:535(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:588(title) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:113(term)
msgid "Availability"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:584(para)
msgid "To ensure that access to nodes within the cloud is not interrupted, we recommend that the network architecture identify any single points of failure and provide some level of redundancy or fault tolerance. With regard to the network infrastructure itself, this often involves use of networking protocols such as LACP, VRRP or others to achieve a highly available network connection. In addition, it is important to consider the networking implications on API availability. In order to ensure that the APIs, and potentially other services in the cloud are highly available, we recommend you design load balancing solutions within the network architecture to accommodate for these requirements."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:537(para)
msgid "To ensure that access to nodes within the cloud is not interrupted, we recommend that the network architecture identify any single points of failure and provide some level of redundancy or fault tolerance. With regard to the network infrastructure itself, this often involves use of networking protocols such as LACP, VRRP or others to achieve a highly available network connection. In addition, it is important to consider the networking implications on API availability. In order to ensure that the APIs, and potentially other services in the cloud are highly available, we recommend you design load balancing solution 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:363(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:386(title)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:556(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:294(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:363(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:386(title)
msgid "Software selection"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:604(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:557(para)
msgid "Software selection for a general purpose OpenStack architecture design needs to include these three areas:"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:608(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:368(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:391(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:561(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:368(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:454(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:374(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:529(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:567(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:454(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:374(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:529(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:381(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:403(title)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:572(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:381(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:403(title)
msgid "Operating system and hypervisor"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:620(para)
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. We recommend you 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."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:573(para)
msgid "The operating system (OS) and hypervisor have a significant impact on the overall design. Selecting a particular operating system and hypervisor can directly affect server hardware selection. Make sure the storage hardware and topology support the selected operating system and hypervisor combination. Also ensure the networking hardware selection and topology will work with the chosen operating system and hypervisor combination. For example, if the design uses Link Aggregation Control Protocol (LACP), the OS and hypervisor both need to support it."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:632(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:392(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:413(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:583(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:392(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 ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:639(para)
msgid "Selecting a commercially supported hypervisor, such as Microsoft Hyper-V, will result in a different cost model rather than community-supported open source hypervisors including <glossterm baseform=\"kernel-based VM (KVM)\">KVM</glossterm>, Kinstance or <glossterm>Xen</glossterm>. When comparing open source OS solutions, choosing Ubuntu over Red Hat (or vice versa) will have an impact on cost due to support contracts. On the other hand, business or application requirements may dictate a specific or commercially supported hypervisor."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:589(para)
msgid "Selecting a commercially supported hypervisor, such as Microsoft Hyper-V, will result in a different cost model rather than community-supported open source hypervisors including <glossterm baseform=\"kernel-based VM (KVM)\">KVM</glossterm>, Kinstance or <glossterm>Xen</glossterm>. When comparing open source OS solutions, choosing Ubuntu over Red Hat (or vice versa) will have an impact on cost due to support contracts."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:653(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:409(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:431(term)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:601(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:409(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:431(term)
msgid "Supportability"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:655(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:411(para)
msgid "Depending on the selected hypervisor, the staff should have the appropriate training and knowledge to support the selected OS and hypervisor combination. If they do not, training will need to be provided which could have a cost impact on the design."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:603(para)
msgid "Depending on the selected hypervisor, staff should have the appropriate training and knowledge to support the selected OS and hypervisor combination. If they do not, training will need to be provided which could have a cost impact on the design."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:664(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:419(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:448(term)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:612(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:419(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:448(term)
msgid "Management tools"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:666(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:421(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:614(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:421(para)
msgid "The management tools used for Ubuntu and Kinstance differ from the management tools for VMware vSphere. Although both OS and hypervisor combinations are supported by OpenStack, there will be very different impacts to the rest of the design as a result of the selection of one combination versus the other."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:676(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:430(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:460(term)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:624(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:430(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:460(term)
msgid "Scale and performance"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:678(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:626(para)
msgid "Ensure that selected OS and hypervisor combinations meet the appropriate scale and performance requirements. The chosen architecture will need to meet the targeted instance-host ratios with the selected OS-hypervisor combinations."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:688(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:442(para)
msgid "Ensure that the design can accommodate the regular periodic installation of application security patches while maintaining the required workloads. The frequency of security patches for the proposed OS-hypervisor combination will have an impact on performance and the patch installation process could affect maintenance windows."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:636(para)
msgid "Ensure that the design can accommodate regular periodic installations of application security patches while maintaining required workloads. The frequency of security patches for the proposed OS-hypervisor combination will have an impact on performance and the patch installation process could affect maintenance windows."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:698(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:451(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:483(term)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:646(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:451(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:483(term)
msgid "Supported features"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:700(para)
msgid "Determine which 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."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:648(para)
msgid "Determine which features of OpenStack are required. This will often determine the selection of the OS-hypervisor combination. Some features are only available with specific OSs or hypervisors. For example, if certain features are not available, the design might need to be modified to meet the user requirements."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:710(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:343(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:462(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:495(term)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:657(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:343(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:462(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:495(term)
msgid "Interoperability"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:712(para)
msgid "Consideration should be given to the ability of the selected OS-hypervisor combination to interoperate or co-exist with other OS-hypervisors as well as other software solutions in the overall design (if required). Operational troubleshooting tools for one OS-hypervisor combination may differ from the tools used for another OS-hypervisor combination and, as a result, the design will need to address if the two sets of tools need to interoperate."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:659(para)
msgid "You will need to consider how the OS and hypervisor combination interactions with other operating systems and hypervisors, including other software solutions. Operational troubleshooting tools for one OS-hypervisor combination may differ from the tools used for another OS-hypervisor combination and, as a result, the design will need to address if the two sets of tools need to interoperate."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:728(para)
msgid "The selection of which OpenStack components are included has a significant impact on the overall design. While there are certain components that will always be present, (Compute and Image Service, for example) there are other services that may not be required. As an example, a certain design might not need <glossterm>Orchestration</glossterm>. Omitting Orchestration would not have a significant impact on the overall design of a cloud; however, if the architecture uses a replacement for OpenStack Object Storage for its storage component, it could potentially have significant impacts on the rest of the design."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:672(para)
msgid "Selecting which OpenStack components are included in the overall design can have a significant impact. Some OpenStack components, like compute and Image Service, are required in every architecture. Other components, like Orchestration, are not always required."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:739(para)
msgid "The exclusion of certain OpenStack components might also limit or constrain the functionality of other components. If the architecture includes Orchestration but excludes Telemetry, then the design will not be able to take advantage of Orchestrations' auto scaling functionality (which relies on information from Telemetry). It is important to research the component interdependencies in conjunction with the technical requirements before deciding what components need to be included and what components can be dropped from the final architecture."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:676(para)
msgid "Excluding certain OpenStack components can limit or constrain the functionality of other components. For example, if the architecture includes Orchestration but excludes Telemetry, then the design will not be able to take advantage of Orchestrations' auto scaling functionality. It is important to research the component interdependencies in conjunction with the technicalrequirements before deciding on the final architecture."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:751(title)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:684(title)
msgid "Supplemental components"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:752(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:685(para)
msgid "While OpenStack is a fairly complete collection of software projects for building a platform for cloud services, there are invariably additional pieces of software that need to be considered in any given OpenStack design."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:758(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:535(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:568(title)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:692(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:535(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:568(title)
msgid "Networking software"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:759(para)
msgid "OpenStack Networking provides a wide variety of networking services for instances. There are many additional networking software packages that might be useful to manage the OpenStack components themselves. Some examples include software to provide load balancing, network redundancy protocols, and routing daemons. Some of these software packages are described in more detail in the <citetitle>OpenStack High Availability Guide</citetitle> (refer to the <link href=\"http://docs.openstack.org/high-availability-guide/content/ch-network.html\">Network controller cluster stack chapter</link> of the OpenStack High Availability Guide)."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:693(para)
msgid "OpenStack Networking provides a wide variety of networking services for instances. There are many additional networking software packages that can be useful when managing OpenStack components. Some examples include:"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:770(para)
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."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:699(para)
msgid "Software to provide load balancing"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:777(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:551(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:585(title)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:704(para)
msgid "Network redundancy protocols"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:709(para)
msgid "Routing daemons"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:714(para)
msgid "Some of these software packages are described in more detail in the <citetitle>OpenStack High Availability Guide</citetitle> (refer to the <link href=\"http://docs.openstack.org/high-availability-guide/content/ch-network.html\">Network controller cluster stack chapter</link> of the OpenStack High Availability Guide)."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:720(para)
msgid "For a general purpose OpenStack cloud, the OpenStack infrastructure components need to be highly available. If the design does not include hardware load balancing, networking software packages like HAProxy will need to be included."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:727(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:551(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:778(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:552(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."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:728(para)
msgid "Selected supplemental software solution impacts and affects the overall OpenStack cloud design. This includes software for providing clustering, logging, monitoring and alerting."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:782(para)
msgid "Inclusion of clustering software, such as Corosync or Pacemaker, is determined primarily by the availability 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 <link href=\"http://docs.openstack.org/high-availability-guide/\"><citetitle>OpenStack High Availability Guide</citetitle></link> provides more details on the installation and configuration of Corosync and Pacemaker, should these packages need to be included in the design."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:732(para)
msgid "Inclusion of clustering software, such as Corosync or Pacemaker, is determined primarily by the availability requirements. The impact of including (or not including) these software packages is primarily determined by the availability of the cloud infrastructure and the complexity of supporting the configuration after it is deployed. The <link href=\"http://docs.openstack.org/high-availability-guide/\"><citetitle>OpenStack High Availability Guide</citetitle></link> provides more details on the installation and configuration of Corosync and Pacemaker, should these packages need to be included in the design."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:793(para)
msgid "Requirements for logging, monitoring, and alerting are determined by operational considerations. Each of these sub-categories includes a number of various options. For example, in the logging sub-category one might consider Logstash, Splunk, instanceware Log Insight, or some other log aggregation-consolidation tool. Logs should be stored in a centralized location to make it easier to perform analytics against the data. Log data analytics engines can also provide automation and issue notification by providing a mechanism to both alert and automatically attempt to remediate some of the more commonly known issues."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:743(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 loggin sub-category one might consider Logstach, Splunk, instanceware Log Insight, or some other log aggregation-consolidation tool. Logs should be stored in a centralized location to make it easier to perform analytics against the data. Log data analytics engines can also provide automation and issue notification by providing a mechanism to both alert and automatically attempt to remediate some of the more commonly known issues."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:804(para)
msgid "If any of these software packages are required, 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:"
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:753(para)
msgid "If these software packages are required, the design must account for the additional resource consumption (CPU, RAM, storage, and network bandwidth). Some other potential design impacts include:"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:811(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:578(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:759(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:578(para)
msgid "OS-hypervisor combination: Ensure that the selected logging, monitoring, or alerting tools support the proposed OS-hypervisor combination."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:816(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:583(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:625(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:764(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:583(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:823(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:589(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:631(title)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:771(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:589(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:631(title)
msgid "Database software"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:824(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 supports connecting to any database that is supported by the SQLAlchemy python drivers, however, most common database deployments make use of MySQL or variations of it. We recommend that the database which provides back-end service within a general purpose cloud be made highly available when using an available technology which can accomplish that goal. Some of the more common software solutions used include Galera, MariaDB and MySQL with multi-master replication."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:772(para)
msgid "OpenStack components often require access to back-end database services to store state and configuration information. Selecting an appropriate back-end database that satisfies the availability and fault tolerance requirements of the OpenStack services is required. OpenStack services supports connecting to a database that is supported by the SQLAlchemy python drivers, however, most common database deployments make use of MySQL or variations of it. We recommend that the database, which provides back-end service within a general purpose cloud, be made highly available when using an available technology which can accomplish that goal."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:840(title)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:786(title)
msgid "Addressing performance-sensitive workloads"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:841(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:787(para)
msgid "Although one of the key defining factors for a general purpose OpenStack cloud is that performance is not a determining factor, there may still be some performance-sensitive workloads deployed on the general purpose OpenStack cloud. For design guidance on performance-sensitive workloads, we recommend that you refer to the focused scenarios later in this guide. The resource-focused guides can be used as a supplement to this guide to help with decisions regarding performance-sensitive workloads."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:853(title)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:799(title)
msgid "Compute-focused workloads"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:854(para)
msgid "In an OpenStack cloud that is compute-focused, there are some design choices that can help accommodate those workloads. Compute-focused workloads are generally those that would place a higher demand on CPU and memory resources with lower priority given to storage and network performance, other than what is required to support the intended compute workloads. For guidance on designing for this type of cloud, please refer to <xref linkend=\"compute_focus\"/>."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:800(para)
msgid "In an OpenStack cloud that is compute-focused, there are some design choices that can help accommodate those workloads. Compute-focused workloads demand more CPU and memory resources with lower priority given to storage and network performance. For guidance on designing for this type of cloud, please refer to <xref linkend=\"compute_focus\"/>."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:864(title)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:808(title)
msgid "Network-focused workloads"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:865(para)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:809(para)
msgid "In a network-focused OpenStack cloud some design choices can improve the performance of these types of workloads. Network-focused workloads have extreme demands on network bandwidth and services that require specialized consideration and planning. For guidance on designing for this type of cloud, please refer to <xref linkend=\"network_focus\"/>."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:873(title)
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:817(title)
msgid "Storage-focused workloads"
msgstr ""
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:874(para)
msgid "Storage focused OpenStack clouds need to be designed to accommodate workloads that have extreme demands on either object or block storage services that require specialized consideration and planning. For guidance on designing for this type of cloud, please refer to <xref linkend=\"storage_focus\"/>."
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:818(para)
msgid "Storage focused OpenStack clouds need to be designed to accommodate workloads that have extreme demands on either object or block storage services. For guidance on designing for this type of cloud, please refer to <xref linkend=\"storage_focus\"/>."
msgstr ""
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:9(para)
@ -3681,6 +3725,10 @@ msgstr ""
msgid "The networking hardware must support the proposed network speed, for example: 1 GbE, 10 GbE, or 40 GbE (or even 100 GbE)."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:323(para)
msgid "The level of network hardware redundancy required is influenced by the user requirements for high availability and cost considerations. Network redundancy can be achieved by adding redundant power supplies or paired switches. If this is a requirement, the hardware will need to support this configuration. User requirements will determine if a completely redundant network infrastructure is required."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:335(para)
msgid "Ensure that the physical data center provides the necessary power for the selected network hardware. This is not an issue for top of rack (ToR) switches, but may be an issue for spine switches in a leaf and spine fabric, or end of row (EoR) switches."
msgstr ""
@ -3709,10 +3757,18 @@ msgstr ""
msgid "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:411(para)
msgid "Depending on the selected hypervisor, the staff should have the appropriate training and knowledge to support the selected OS and hypervisor combination. If they do not, training will need to be provided which could have a cost impact on the design."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:432(para)
msgid "Ensure that selected OS and hypervisor combinations meet the appropriate scale and performance requirements. The chosen architecture will need to meet the targeted instance-host ratios with the selected OS-hypervisor combination."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:442(para)
msgid "Ensure that the design can accommodate the regular periodic installation of application security patches while maintaining the required workloads. The frequency of security patches for the proposed OS-hypervisor combination will have an impact on performance and the patch installation process could affect maintenance windows."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:453(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:485(para)
msgid "Determine what features of OpenStack are required. This will often determine the selection of the OS-hypervisor combination. Certain features are only available with specific OSs or hypervisors. For example, if certain features are not available, the design might need to be modified to meet the user requirements."
msgstr ""
@ -3777,6 +3833,10 @@ msgstr ""
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:552(para)
msgid "The selected supplemental software solution impacts and affects the overall OpenStack cloud design. This includes software for providing clustering, logging, monitoring and alerting."
msgstr ""
#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:555(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 ""

View File

@ -1,7 +1,7 @@
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2014-12-14 06:10+0000\n"
"POT-Creation-Date: 2014-12-15 06:10+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"
@ -5264,7 +5264,7 @@ msgstr ""
msgid "Object Store"
msgstr ""
#: ./doc/common/section_dashboard_access.xml:188(guilabel) ./doc/common/section_dashboard_access.xml:195(guilabel)
#: ./doc/common/section_dashboard_access.xml:188(guilabel)
msgid "Containers"
msgstr ""
@ -5272,6 +5272,10 @@ msgstr ""
msgid "Create and manage containers and objects."
msgstr ""
#: ./doc/common/section_dashboard_access.xml:195(guilabel)
msgid "Stacks"
msgstr ""
#: ./doc/common/section_dashboard_access.xml:196(para)
msgid "Use the REST API to orchestrate multiple composite cloud applications."
msgstr ""

View File

@ -19,8 +19,8 @@
msgid ""
msgstr ""
"Project-Id-Version: OpenStack Manuals\n"
"POT-Creation-Date: 2014-12-14 01:11+0000\n"
"PO-Revision-Date: 2014-12-14 01:20+0000\n"
"POT-Creation-Date: 2014-12-15 00:16+0000\n"
"PO-Revision-Date: 2014-12-15 00:30+0000\n"
"Last-Translator: openstackjenkins <jenkins@openstack.org>\n"
"Language-Team: French (http://www.transifex.com/projects/p/openstack-manuals-i18n/language/fr/)\n"
"MIME-Version: 1.0\n"
@ -7918,7 +7918,6 @@ msgid "Object Store"
msgstr "Stockage d'objet"
#: ./doc/common/section_dashboard_access.xml188(guilabel)
#: ./doc/common/section_dashboard_access.xml195(guilabel)
msgid "Containers"
msgstr "Conteneurs"
@ -7926,6 +7925,10 @@ msgstr "Conteneurs"
msgid "Create and manage containers and objects."
msgstr ""
#: ./doc/common/section_dashboard_access.xml195(guilabel)
msgid "Stacks"
msgstr "Stacks"
#: ./doc/common/section_dashboard_access.xml196(para)
msgid "Use the REST API to orchestrate multiple composite cloud applications."
msgstr ""

View File

@ -7,8 +7,8 @@
msgid ""
msgstr ""
"Project-Id-Version: OpenStack Manuals\n"
"POT-Creation-Date: 2014-12-14 01:11+0000\n"
"PO-Revision-Date: 2014-12-14 01:20+0000\n"
"POT-Creation-Date: 2014-12-15 00:16+0000\n"
"PO-Revision-Date: 2014-12-15 00:30+0000\n"
"Last-Translator: openstackjenkins <jenkins@openstack.org>\n"
"Language-Team: Japanese (http://www.transifex.com/projects/p/openstack-manuals-i18n/language/ja/)\n"
"MIME-Version: 1.0\n"
@ -7906,7 +7906,6 @@ msgid "Object Store"
msgstr "オブジェクトストア"
#: ./doc/common/section_dashboard_access.xml188(guilabel)
#: ./doc/common/section_dashboard_access.xml195(guilabel)
msgid "Containers"
msgstr "コンテナー"
@ -7914,6 +7913,10 @@ msgstr "コンテナー"
msgid "Create and manage containers and objects."
msgstr "コンテナーとオブジェクトを作成、管理します。"
#: ./doc/common/section_dashboard_access.xml195(guilabel)
msgid "Stacks"
msgstr "スタック"
#: ./doc/common/section_dashboard_access.xml196(para)
msgid "Use the REST API to orchestrate multiple composite cloud applications."
msgstr "複数のコンポジットクラウドアプリケーションをオーケストレーションするために REST API を使用します。"

View File

@ -6,8 +6,8 @@
msgid ""
msgstr ""
"Project-Id-Version: OpenStack Manuals\n"
"POT-Creation-Date: 2014-12-12 04:44+0000\n"
"PO-Revision-Date: 2014-12-12 04:50+0000\n"
"POT-Creation-Date: 2014-12-15 00:16+0000\n"
"PO-Revision-Date: 2014-12-15 01:50+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"
@ -1190,7 +1190,7 @@ msgid ""
"subject (owner) of the certificate and the party relying upon the "
"certificate. CAs are characteristic of many public key infrastructure (PKI) "
"schemes."
msgstr ""
msgstr "認証局。暗号において、電子証明書を発行するエンティティー。電子証明書は、証明書の発行先の名前により公開鍵の所有者を証明する。これにより、他の信頼される機関が証明書を信頼できるようになる。また、証明された公開鍵に対応する秘密鍵による表明を信頼できるようになる。この信頼関係のモデルにおいて、CA は証明書の発行先と証明書を信頼している機関の両方に対する信頼された第三者機関である。CA は、多くの公開鍵基盤 (PKI) スキームの特徴である。"
#: ./doc/glossary/glossary-terms.xml1228(glossterm)
msgid "cache pruner"
@ -1615,7 +1615,7 @@ msgstr "Cloudbase-Init"
msgid ""
"A Windows project providing guest initialization features, similar to cloud-"
"init."
msgstr ""
msgstr "cloud-init 同様のゲスト初期化機能を提供する Windows プロジェクト。"
#: ./doc/glossary/glossary-terms.xml1692(glossterm)
#: ./doc/glossary/glossary-terms.xml1694(primary)
@ -2635,7 +2635,7 @@ msgstr ""
msgid ""
"The Compute RabbitMQ message exchange that remains active when the server "
"restarts."
msgstr ""
msgstr "サーバーの再起動時に有効なままになる Compute の RabbitMQ メッセージ交換。"
#: ./doc/glossary/glossary-terms.xml2733(glossterm)
#: ./doc/glossary/glossary-terms.xml2735(primary)
@ -2656,7 +2656,7 @@ msgstr "動的ホスト設定プロトコルDHCP"
msgid ""
"A method to automatically configure networking for a host at boot time. "
"Provided by both Networking and Compute."
msgstr ""
msgstr "ホストの起動時にネットワークを自動的に設定する方式。Networking と Compute により提供される。"
#: ./doc/glossary/glossary-terms.xml2754(glossterm)
msgid "Dynamic HyperText Markup Language (DHTML)"
@ -4969,7 +4969,7 @@ msgid ""
"Linux kernel feature that provides independent virtual networking instances "
"on a single host with separate routing tables and interfaces. Similar to "
"virtual routing and forwarding (VRF) services on physical network equipment."
msgstr ""
msgstr "別々のルーティングテーブルとインターフェースを持つ単一のホストにおいて、独立した仮想ネットワークインターフェースを提供する Linux カーネル機能。物理ネットワーク環境における仮想ルーティングおよびフォワーディング (VRF) サービスと似ている。"
#: ./doc/glossary/glossary-terms.xml5330(glossterm)
#: ./doc/glossary/glossary-terms.xml5332(primary)
@ -6183,7 +6183,7 @@ msgstr "radvd"
msgid ""
"The router advertisement daemon, used by the Compute VLAN manager and "
"FlatDHCP manager to provide routing services for VM instances."
msgstr ""
msgstr "ルーター通知デーモン。仮想マシンインスタンスにルーティングサービスを提供するために、Compute の VLAN マネージャーと FlatDHCP マネージャーにより使用される。"
#: ./doc/glossary/glossary-terms.xml6714(glossterm)
#: ./doc/glossary/glossary-terms.xml6716(primary)
@ -6909,7 +6909,7 @@ msgstr "サービス登録"
msgid ""
"An Identity Service feature that enables services, such as Compute, to "
"automatically register with the catalog."
msgstr ""
msgstr "自動的にカタログに登録するために、Compute などのサービスを有効化する、Identity の機能。"
#: ./doc/glossary/glossary-terms.xml7474(glossterm)
#: ./doc/glossary/glossary-terms.xml7476(primary)
@ -6930,7 +6930,7 @@ msgstr "サービストークン"
msgid ""
"An administrator-defined token used by Compute to communicate securely with "
"the Identity Service."
msgstr ""
msgstr "Identity と安全に通信するために Compute により使用される、管理者により定義されたトークン。"
#: ./doc/glossary/glossary-terms.xml7498(glossterm)
#: ./doc/glossary/glossary-terms.xml7502(secondary)
@ -7825,7 +7825,7 @@ msgid ""
"A generic term for virtualization of network functions such as switching, "
"routing, load balancing, and security using a combination of VMs and "
"overlays on physical network infrastructure."
msgstr ""
msgstr "複数の仮想マシンを使用して、物理ネットワーク上にオーバーレイされる、スイッチング、ルーティング、負荷分散、セキュリティなどのネットワーク機能の仮想化に関する一般的な用語。"
#: ./doc/glossary/glossary-terms.xml8539(glossterm)
#: ./doc/glossary/glossary-terms.xml8541(primary)

View File

@ -7,9 +7,9 @@
msgid ""
msgstr ""
"Project-Id-Version: OpenStack Manuals\n"
"POT-Creation-Date: 2014-12-04 23:29+0000\n"
"PO-Revision-Date: 2014-12-04 20:38+0000\n"
"Last-Translator: openstackjenkins <jenkins@openstack.org>\n"
"POT-Creation-Date: 2014-12-15 00:16+0000\n"
"PO-Revision-Date: 2014-12-14 14:20+0000\n"
"Last-Translator: Sungjin Kang <potopro@gmail.com>\n"
"Language-Team: Korean (Korea) (http://www.transifex.com/projects/p/openstack-manuals-i18n/language/ko_KR/)\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
@ -484,7 +484,7 @@ msgid ""
"API. API endpoints can provide any number of services, such as "
"authentication, sales data, performance metrics, Compute VM commands, census"
" data, and so on."
msgstr ""
msgstr "클라이언트와 통신하는 데몬, 작업자, 서비스는 API를 이용하여 접근할 수 있습니다. API 엔드 포인트는 서비스의 번호, 인증, 판매 데이터, 성능 측정, Compute VM 명령, 조사 데이터 등을 제공합니다."
#: ./doc/glossary/glossary-terms.xml453(glossterm)
#: ./doc/glossary/glossary-terms.xml457(secondary)
@ -669,39 +669,39 @@ msgid ""
"The process of connecting a VIF or vNIC to a L2 network in Networking. In "
"the context of Compute, this process connects a storage volume to an "
"instance."
msgstr ""
msgstr "네트워킹에서 L2 네트워크와 vNIC이나 VIF의 연결 프로세스를 나타냅니다. Compute의 콘텍스트에서 이 프로세서는 인스턴스 스토리지 볼륨과 연결됩니다."
#: ./doc/glossary/glossary-terms.xml666(glossterm)
#: ./doc/glossary/glossary-terms.xml668(primary)
msgid "attachment (network)"
msgstr "부착물 (네트워크)"
msgstr "연결 (네트워크)"
#: ./doc/glossary/glossary-terms.xml672(para)
msgid ""
"Association of an interface ID to a logical port. Plugs an interface into a "
"port."
msgstr ""
msgstr "논리적 포트에 인터페이스 ID 모음. 포트에 인터페이스를 연결합니다."
#: ./doc/glossary/glossary-terms.xml678(glossterm)
#: ./doc/glossary/glossary-terms.xml680(primary)
msgid "auditing"
msgstr ""
msgstr "감사"
#: ./doc/glossary/glossary-terms.xml684(para)
msgid "Provided in Compute through the system usage data facility."
msgstr ""
msgstr "시스템이 사용하는 데이터 기능을 사용해서 Compute에 제공합니다."
#: ./doc/glossary/glossary-terms.xml690(glossterm)
#: ./doc/glossary/glossary-terms.xml692(primary)
msgid "auditor"
msgstr ""
msgstr "auditor"
#: ./doc/glossary/glossary-terms.xml696(para)
msgid ""
"A worker process that verifies the integrity of Object Storage objects, "
"containers, and accounts. Auditors is the collective term for the Object "
"Storage account auditor, container auditor, and object auditor."
msgstr ""
msgstr "오프젝트 스토리지 오브젝트, 컨테이너, 계정의 무결성을 검사하는 프로세스입니다. Auditors는 오브젝트 스토리지 계정 auditor, 컨테이너 auditor, 오브젝트 auditor에 대한 전체를 다 말합니다."
#: ./doc/glossary/glossary-terms.xml704(glossterm)
#: ./doc/glossary/glossary-terms.xml706(primary)
@ -712,7 +712,7 @@ msgstr "Austin"
msgid ""
"The code name for the initial release of OpenStack. The first design summit "
"took place in Austin, Texas, US."
msgstr ""
msgstr "OpenStack의 초기 릴리즈 코드 이름. 첫 디자인 서밋을 한 곳인 미국 텍사스 Austin을 나타냅니다."
#: ./doc/glossary/glossary-terms.xml717(glossterm)
#: ./doc/glossary/glossary-terms.xml719(primary)
@ -721,7 +721,7 @@ msgstr "auth 노드"
#: ./doc/glossary/glossary-terms.xml723(para)
msgid "Alternative term for an Object Storage authorization node."
msgstr ""
msgstr "오브젝트 스토리지 인증 노드의 줄임말입니다."
#: ./doc/glossary/glossary-terms.xml729(glossterm)
#: ./doc/glossary/glossary-terms.xml731(primary)

View File

@ -5,9 +5,9 @@
msgid ""
msgstr ""
"Project-Id-Version: OpenStack Manuals\n"
"POT-Creation-Date: 2014-12-14 01:11+0000\n"
"PO-Revision-Date: 2014-12-14 01:07+0000\n"
"Last-Translator: openstackjenkins <jenkins@openstack.org>\n"
"POT-Creation-Date: 2014-12-15 00:16+0000\n"
"PO-Revision-Date: 2014-12-15 00:30+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"
"Content-Type: text/plain; charset=UTF-8\n"
@ -935,7 +935,7 @@ msgid ""
"command with the <parameter>--os-endpoint</parameter> option or set the "
"temporary <envar>OS_SERVICE_ENDPOINT</envar> environment variable. This "
"guide uses environment variables to reduce command length."
msgstr ""
msgstr "<placeholder-1/> コマンドの <parameter>--os-token</parameter> オプションに管理トークンの値を渡せます。または、一時的な <envar>OS_SERVICE_TOKEN</envar> 環境変数を設定します。同様に、<placeholder-2/> コマンドの <parameter>--os-endpoint</parameter> オプションに Identity のサービスの場所を渡せます。または、一時的な <envar>OS_SERVICE_ENDPOINT</envar> 環境変数を設定します。このガイドは、環境変数を使用して、コマンドを短くします。"
#: ./doc/install-guide/section_keystone-users.xml25(para)
msgid ""
@ -1120,7 +1120,7 @@ msgid ""
"Telemetry is composed of an API service, a collector and a range of "
"disparate agents. This section explains how to install and configure the "
"agent that runs on the compute node."
msgstr ""
msgstr "Telemetry は、API サービス、コレクター、さまざまな個別エージェントから構成されます。このセクションは、コンピュートノードで動作するエージェントをインストールして設定する方法を説明します。"
#: ./doc/install-guide/section_ceilometer-nova.xml15(para)
msgid "Install the package:"
@ -1193,7 +1193,7 @@ msgstr "RABBIT_PASS"
msgid ""
"Replace <replaceable>RABBIT_PASS</replaceable> with the password you chose "
"for the guest account in RabbitMQ."
msgstr ""
msgstr "<replaceable>RABBIT_PASS</replaceable> を RabbitMQ のゲストアカウント用に選択したパスワードで置き換えます。"
#: ./doc/install-guide/section_ceilometer-nova.xml65(para)
msgid ""
@ -1214,14 +1214,14 @@ msgstr "CEILOMETER_PASS"
msgid ""
"Replace <replaceable>CEILOMETER_PASS</replaceable> with the password you "
"chose for the Telemetry module database."
msgstr ""
msgstr "<replaceable>CEILOMETER_PASS</replaceable> を Telemetry 用モジュールデータベース用に選択したパスワードで置き換えます。"
#: ./doc/install-guide/section_ceilometer-nova.xml76(para)
msgid ""
"Comment out the <literal>auth_host</literal>, <literal>auth_port</literal>, "
"and <literal>auth_protocol</literal> keys, since they are replaced by the "
"<literal>identity_uri</literal> and <literal>auth_uri</literal> keys."
msgstr ""
msgstr "<literal>auth_host</literal>、<literal>auth_port</literal>、<literal>auth_protocol</literal> キーは、<literal>identity_uri</literal> と <literal>auth_uri</literal> キーにより置き換えるので、コメントアウトします。"
#: ./doc/install-guide/section_ceilometer-nova.xml83(para)
#: ./doc/install-guide/section_ceilometer-controller.xml249(para)
@ -1229,7 +1229,7 @@ msgstr ""
msgid ""
"In the <literal>[service_credentials]</literal> section, configure service "
"credentials:"
msgstr ""
msgstr "<literal>[service_credentials]</literal> セクションに、サービスのクレデンシャルを設定します。"
#: ./doc/install-guide/section_ceilometer-nova.xml91(para)
msgid ""
@ -1291,7 +1291,7 @@ msgid ""
"packages for Ubuntu. Documentation will be updated once the packages are "
"available. The rest of this document assumes that you have the sahara "
"service packages installed on the system."
msgstr ""
msgstr "必要なパッケージをインストールする必要があります。今のところ、sahara は Ubuntu 向けのパッケージがありません。パッケージが利用可能になれば、ドキュメントが更新されます。このドキュメントの残りは、sahara のパッケージがシステムにインストールされていることを仮定します。"
#: ./doc/install-guide/section_sahara-install.xml39(para)
msgid "Edit <filename>/etc/sahara/sahara.conf</filename> configuration file"
@ -1363,7 +1363,7 @@ msgid ""
"You must register the Data processing service with the Identity service so "
"that other OpenStack services can locate it. Register the service and "
"specify the endpoint: <placeholder-1/>"
msgstr ""
msgstr "他のサービスから利用できるよう、Data processing を Identity に登録する必要があります。サービスを登録し、エンドポイントを指定します。<placeholder-1/>"
#: ./doc/install-guide/section_sahara-install.xml102(para)
msgid "Start the sahara service: <placeholder-1/><placeholder-2/>"
@ -1373,7 +1373,7 @@ msgstr "sahara サービスを起動します。<placeholder-1/><placeholder-2/>
msgid ""
"(Optional) Enable the Data processing service to start on boot "
"<placeholder-1/><placeholder-2/>"
msgstr ""
msgstr "(オプション) Data processing が起動時に開始するよう有効化します。 <placeholder-1/><placeholder-2/>"
#: ./doc/install-guide/section_ceilometer-cinder.xml8(title)
msgid "Add the Block Storage service agent for Telemetry"
@ -2084,7 +2084,7 @@ msgstr "Horizon により、ダッシュボードのブランドをカスタマ
#: ./doc/install-guide/ch_horizon.xml17(para)
msgid ""
"Horizon provides a set of core classes and reusable templates and tools."
msgstr ""
msgstr "Horizon は、コアなクラス、再利用可能なテンプレートやツールを提供します。"
#: ./doc/install-guide/ch_horizon.xml18(para)
msgid "This example deployment uses an Apache web server."
@ -2101,7 +2101,7 @@ msgstr "OpenStack 環境にダッシュボードが追加されました。<link
msgid ""
"After you install and configure the dashboard, you can complete the "
"following tasks:"
msgstr ""
msgstr "Dashboard をインストールして設定した後、以下の作業を実行します。"
#: ./doc/install-guide/ch_horizon.xml32(para)
msgid ""
@ -2127,7 +2127,7 @@ msgstr ""
#: ./doc/install-guide/section_keystone-verify.xml8(para)
msgid ""
"This section describes how to verify operation of the Identity service."
msgstr ""
msgstr "このセクションは、Identity の動作を検証する方法を説明します。"
#: ./doc/install-guide/section_keystone-verify.xml12(para)
msgid ""

View File

@ -11,8 +11,8 @@
msgid ""
msgstr ""
"Project-Id-Version: OpenStack Manuals\n"
"POT-Creation-Date: 2014-12-14 01:11+0000\n"
"PO-Revision-Date: 2014-12-14 01:20+0000\n"
"POT-Creation-Date: 2014-12-15 00:16+0000\n"
"PO-Revision-Date: 2014-12-15 00:17+0000\n"
"Last-Translator: openstackjenkins <jenkins@openstack.org>\n"
"Language-Team: French (http://www.transifex.com/projects/p/openstack-manuals-i18n/language/fr/)\n"
"MIME-Version: 1.0\n"
@ -9872,7 +9872,7 @@ msgid ""
msgstr ""
#: ./doc/user-guide/hot/section_environment.xml88(para)
msgid "You can use wilcards to map multiple resources:"
msgid "You can use wildcards to map multiple resources:"
msgstr ""
#: ./doc/user-guide/hot/section_environment.xml91(para)

View File

@ -7,8 +7,8 @@
msgid ""
msgstr ""
"Project-Id-Version: OpenStack Manuals\n"
"POT-Creation-Date: 2014-12-14 01:11+0000\n"
"PO-Revision-Date: 2014-12-14 01:20+0000\n"
"POT-Creation-Date: 2014-12-15 00:16+0000\n"
"PO-Revision-Date: 2014-12-15 00:17+0000\n"
"Last-Translator: openstackjenkins <jenkins@openstack.org>\n"
"Language-Team: Japanese (http://www.transifex.com/projects/p/openstack-manuals-i18n/language/ja/)\n"
"MIME-Version: 1.0\n"
@ -9868,7 +9868,7 @@ msgid ""
msgstr ""
#: ./doc/user-guide/hot/section_environment.xml88(para)
msgid "You can use wilcards to map multiple resources:"
msgid "You can use wildcards to map multiple resources:"
msgstr ""
#: ./doc/user-guide/hot/section_environment.xml91(para)

View File

@ -1,7 +1,7 @@
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2014-12-14 06:10+0000\n"
"POT-Creation-Date: 2014-12-15 06:10+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"
@ -7179,7 +7179,7 @@ msgid "The following example maps the new <literal>OS::Networking::FloatingIP</l
msgstr ""
#: ./doc/user-guide/hot/section_environment.xml:88(para)
msgid "You can use wilcards to map multiple resources:"
msgid "You can use wildcards to map multiple resources:"
msgstr ""
#: ./doc/user-guide/hot/section_environment.xml:91(para)