Imported Translations from Transifex
For more information about this automatic import see: https://wiki.openstack.org/wiki/Translations/Infrastructure Change-Id: I9f949fb4980149976b0ef8166e0ad5ab62a97e81
This commit is contained in:
OpenStack Proposal Bot
parent
aa0b7663fe
commit
f22caf8bc3
@ -8,7 +8,7 @@ msgid ""
|
||||
msgstr ""
|
||||
"Project-Id-Version: Cloud Administrator Guide 0.9\n"
|
||||
"Report-Msgid-Bugs-To: \n"
|
||||
"POT-Creation-Date: 2015-08-19 06:15+0000\n"
|
||||
"POT-Creation-Date: 2015-08-21 06:19+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"
|
||||
@ -1171,7 +1171,7 @@ msgstr ""
|
||||
msgid "**provider network**"
|
||||
msgstr ""
|
||||
|
||||
#: ../compute-service-groups.rst:62
|
||||
#: ../compute-service-groups.rst:63
|
||||
msgid "**python-zookeeper**"
|
||||
msgstr ""
|
||||
|
||||
@ -4444,7 +4444,7 @@ msgid ""
|
||||
"49152 to 49261 is used for the KVM communications. Based on the secure "
|
||||
"remote access TCP configuration you chose, be careful which ports you open, "
|
||||
"and always understand who has access. For information about ports that are "
|
||||
"used with libvirt, see `the libvirt documentation <http://libvirt.org/remote."
|
||||
"used with libvirt, see the `libvirt documentation <http://libvirt.org/remote."
|
||||
"html#Remote_libvirtd_configuration>`_."
|
||||
msgstr ""
|
||||
|
||||
@ -6685,6 +6685,14 @@ msgid ""
|
||||
"BIOS."
|
||||
msgstr ""
|
||||
|
||||
#: ../compute-service-groups.rst:82
|
||||
msgid ""
|
||||
"For Compute Service groups customization options, see the `OpenStack "
|
||||
"Configuration Reference Guide <http://docs.openstack.org/kilo/config-"
|
||||
"reference/ content/list-of-compute-config-options."
|
||||
"html#config_table_nova_zookeeper>`_."
|
||||
msgstr ""
|
||||
|
||||
#: ../networking_config-agents.rst:247
|
||||
msgid ""
|
||||
"For DHCP namespace the configuration key: ``dhcp_delete_namespaces = True``. "
|
||||
@ -9972,7 +9980,7 @@ msgstr ""
|
||||
msgid "Mediates token authentication."
|
||||
msgstr ""
|
||||
|
||||
#: ../compute-service-groups.rst:92
|
||||
#: ../compute-service-groups.rst:89
|
||||
msgid "Memcache ServiceGroup driver"
|
||||
msgstr ""
|
||||
|
||||
@ -15934,7 +15942,7 @@ msgid ""
|
||||
"data."
|
||||
msgstr ""
|
||||
|
||||
#: ../compute-service-groups.rst:94
|
||||
#: ../compute-service-groups.rst:91
|
||||
msgid ""
|
||||
"The memcache ServiceGroup driver uses memcached, a distributed memory object "
|
||||
"caching system that is used to increase site performance. For more details, "
|
||||
@ -16115,7 +16123,7 @@ msgid ""
|
||||
"suffix directories."
|
||||
msgstr ""
|
||||
|
||||
#: ../compute-service-groups.rst:64
|
||||
#: ../compute-service-groups.rst:63
|
||||
msgid "The official Zookeeper Python binding"
|
||||
msgstr ""
|
||||
|
||||
@ -17279,13 +17287,13 @@ msgid ""
|
||||
"imbalanced zones or too many partitions recently moved)."
|
||||
msgstr ""
|
||||
|
||||
#: ../compute-service-groups.rst:73
|
||||
#: ../compute-service-groups.rst:71
|
||||
msgid ""
|
||||
"These values in the :file:`/etc/nova/nova.conf` file are required on every "
|
||||
"node for the ZooKeeper driver:"
|
||||
msgstr ""
|
||||
|
||||
#: ../compute-service-groups.rst:103
|
||||
#: ../compute-service-groups.rst:100
|
||||
msgid ""
|
||||
"These values in the :file:`/etc/nova/nova.conf` file are required on every "
|
||||
"node for the memcache driver:"
|
||||
@ -17472,7 +17480,7 @@ msgid ""
|
||||
"different Domain."
|
||||
msgstr ""
|
||||
|
||||
#: ../compute-service-groups.rst:70
|
||||
#: ../compute-service-groups.rst:68
|
||||
msgid ""
|
||||
"This example assumes the ZooKeeper server addresses and ports are "
|
||||
"``192.168.2.1:2181``, ``192.168.2.2:2181``, and ``192.168.2.3:2181``."
|
||||
@ -17690,7 +17698,7 @@ msgid ""
|
||||
"hashes to compare."
|
||||
msgstr ""
|
||||
|
||||
#: ../compute-service-groups.rst:68
|
||||
#: ../compute-service-groups.rst:66
|
||||
msgid "This library makes the binding work with the eventlet threading model."
|
||||
msgstr ""
|
||||
|
||||
@ -18224,12 +18232,6 @@ msgid ""
|
||||
"lvm 1` command six times::"
|
||||
msgstr ""
|
||||
|
||||
#: ../compute-service-groups.rst:84
|
||||
msgid ""
|
||||
"To customize the Compute Service groups, use these configuration option "
|
||||
"settings:"
|
||||
msgstr ""
|
||||
|
||||
#: ../compute-remote-console-access.rst:139
|
||||
msgid ""
|
||||
"To customize the VNC console, use the following configuration options in "
|
||||
@ -18753,7 +18755,7 @@ msgid ""
|
||||
"both the Compute and OpenStack Network security group APIs at the same time."
|
||||
msgstr ""
|
||||
|
||||
#: ../compute-service-groups.rst:98
|
||||
#: ../compute-service-groups.rst:95
|
||||
msgid ""
|
||||
"To use the memcache driver, you must install memcached. You might already "
|
||||
"have it installed, as the same driver is also used for the OpenStack Object "
|
||||
@ -20611,8 +20613,10 @@ msgstr ""
|
||||
#: ../compute-configuring-migrations.rst:236
|
||||
msgid ""
|
||||
"You can now configure options for live migration. In most cases, you will "
|
||||
"not need to configure any options. The following chart is for advanced users "
|
||||
"only."
|
||||
"not need to configure any options. For advanced configuration options, see "
|
||||
"the `OpenStack Configuration Reference Guide <http://docs.openstack.org/ "
|
||||
"kilo/config-reference/content/list-of-compute-config-options.html "
|
||||
"#config_table_nova_livemigration>`_."
|
||||
msgstr ""
|
||||
|
||||
# #-#-#-#-# blockstorage_glusterfs_backend.pot (Cloud Administrator Guide 0.9) #-#-#-#-#
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
msgid ""
|
||||
msgstr ""
|
||||
"Project-Id-Version: PACKAGE VERSION\n"
|
||||
"POT-Creation-Date: 2015-08-19 06:15+0000\n"
|
||||
"POT-Creation-Date: 2015-08-21 06:19+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"
|
||||
@ -97,27 +97,27 @@ msgstr ""
|
||||
msgid "This chapter discusses the legal and security requirements you need to consider for the different OpenStack scenarios."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/ch_legal-security-requirements.xml:12(title) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:77(title)
|
||||
#: ./doc/arch-design/ch_legal-security-requirements.xml:12(title)
|
||||
msgid "Legal requirements"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/ch_legal-security-requirements.xml:13(para) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:78(para)
|
||||
#: ./doc/arch-design/ch_legal-security-requirements.xml:13(para)
|
||||
msgid "Many jurisdictions have legislative and regulatory requirements governing the storage and management of data in cloud environments. Common areas of regulation include:"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/ch_legal-security-requirements.xml:18(para) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:83(para)
|
||||
#: ./doc/arch-design/ch_legal-security-requirements.xml:18(para)
|
||||
msgid "Data retention policies ensuring storage of persistent data and records management to meet data archival requirements."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/ch_legal-security-requirements.xml:23(para) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:88(para)
|
||||
#: ./doc/arch-design/ch_legal-security-requirements.xml:23(para)
|
||||
msgid "Data ownership policies governing the possession and responsibility for data."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/ch_legal-security-requirements.xml:27(para) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:92(para)
|
||||
#: ./doc/arch-design/ch_legal-security-requirements.xml:27(para)
|
||||
msgid "Data sovereignty policies governing the storage of data in foreign countries or otherwise separate jurisdictions."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/ch_legal-security-requirements.xml:32(para) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:97(para)
|
||||
#: ./doc/arch-design/ch_legal-security-requirements.xml:32(para)
|
||||
msgid "Data compliance policies governing certain types of information needing to reside in certain locations due to regulatory issues - and more importantly, cannot reside in other locations for the same reason."
|
||||
msgstr ""
|
||||
|
||||
@ -125,7 +125,7 @@ msgstr ""
|
||||
msgid "Examples of such legal frameworks include the <link xlink:href=\"http://ec.europa.eu/justice/data-protection/\">data protection framework</link> of the European Union and the requirements of the <link xlink:href=\"http://www.finra.org/Industry/Regulation/FINRARules/\"> Financial Industry Regulatory Authority</link> in the United States. Consult a local regulatory body for more information."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/ch_legal-security-requirements.xml:48(title) ./doc/arch-design/storage_focus/section_tech_considerations_storage_focus.xml:47(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:432(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:154(para) ./doc/arch-design/hybrid/section_architecture_hybrid.xml:112(para) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:630(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:760(title) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:191(term)
|
||||
#: ./doc/arch-design/ch_legal-security-requirements.xml:48(title) ./doc/arch-design/storage_focus/section_tech_considerations_storage_focus.xml:47(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:432(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:154(para) ./doc/arch-design/hybrid/section_architecture_hybrid.xml:112(para) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:630(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:713(title) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:154(term)
|
||||
msgid "Security"
|
||||
msgstr ""
|
||||
|
||||
@ -158,7 +158,7 @@ msgid "You can map security domains individually to the installation, or combine
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/ch_legal-security-requirements.xml:88(title)
|
||||
msgid "Public security somains"
|
||||
msgid "Public security domains"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/ch_legal-security-requirements.xml:89(para)
|
||||
@ -169,7 +169,7 @@ msgstr ""
|
||||
msgid "Guest security domains"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/ch_legal-security-requirements.xml:99(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:794(para)
|
||||
#: ./doc/arch-design/ch_legal-security-requirements.xml:99(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:747(para)
|
||||
msgid "Typically used for compute instance-to-instance traffic, the guest security domain handles compute data generated by instances on the cloud but not services that support the operation of the cloud, such as API calls. Public cloud providers and private cloud providers who do not have stringent controls on instance use or who allow unrestricted Internet access to instances should consider this domain to be untrusted. Private cloud providers may want to consider this network as internal and therefore trusted only if they have controls in place to assert that they trust instances and all their tenants."
|
||||
msgstr ""
|
||||
|
||||
@ -257,7 +257,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/ch_legal-security-requirements.xml:226(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:361(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:470(title) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:219(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:166(title) ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:144(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:560(para) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:667(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:487(title)
|
||||
#: ./doc/arch-design/ch_legal-security-requirements.xml:226(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:361(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:470(title) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:219(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:166(title) ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:144(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:560(para) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:667(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:440(title)
|
||||
msgid "OpenStack components"
|
||||
msgstr ""
|
||||
|
||||
@ -1281,7 +1281,7 @@ msgstr ""
|
||||
msgid "Selecting the type of networking technology to implement depends on many factors. OpenStack Networking (neutron) and legacy networking (nova-network) both have their advantages and disadvantages. They are both valid and supported options that fit different use cases:"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:330(th) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:158(term)
|
||||
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:330(th) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:120(term)
|
||||
msgid "Legacy networking (nova-network)"
|
||||
msgstr ""
|
||||
|
||||
@ -1377,7 +1377,7 @@ msgstr ""
|
||||
msgid "When designing a network architecture, the traffic patterns of an application heavily influence the allocation of total bandwidth and the number of links that you use to send and receive traffic. Applications that provide file storage for customers allocate bandwidth and links to favor incoming traffic, whereas video streaming applications allocate bandwidth and links to favor outgoing traffic."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:415(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:18(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:42(term) ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:118(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:108(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:387(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:572(title) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:120(term)
|
||||
#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:415(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:18(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:42(term) ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:118(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:108(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:387(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:525(title) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:83(term)
|
||||
msgid "Performance"
|
||||
msgstr ""
|
||||
|
||||
@ -1401,7 +1401,7 @@ msgstr ""
|
||||
msgid "When selecting network devices, be aware that making this decision based on the greatest port density often comes with a drawback. Aggregation switches and routers have not all kept pace with Top of Rack switches and may induce bottlenecks on north-south traffic. As a result, it may be possible for massive amounts of downstream network utilization to impact upstream network devices, impacting service to the cloud. Since OpenStack does not currently provide a mechanism for traffic shaping or rate limiting, it is necessary to implement these features at the network hardware level."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:8(title) ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:8(title) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:8(title) ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:8(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:398(term) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:8(title)
|
||||
#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:8(title) ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:8(title) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:8(title) ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:8(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:351(term) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:8(title)
|
||||
msgid "User requirements"
|
||||
msgstr ""
|
||||
|
||||
@ -2171,7 +2171,7 @@ msgstr ""
|
||||
msgid "It is possible to gain more performance out of a single storage system by using specialized network technologies such as RDMA, SRP, iSER and SCST. The specifics for using these technologies is beyond the scope of this book."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:353(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:552(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:325(title)
|
||||
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:353(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:552(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:278(title)
|
||||
msgid "Software selection"
|
||||
msgstr ""
|
||||
|
||||
@ -2183,7 +2183,7 @@ msgstr ""
|
||||
msgid "Operating system (OS) and hypervisor"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:364(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:524(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:563(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:531(title)
|
||||
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:364(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:524(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:563(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:484(title)
|
||||
msgid "Supplemental software"
|
||||
msgstr ""
|
||||
|
||||
@ -2243,7 +2243,7 @@ msgstr ""
|
||||
msgid "Selecting the OS-hypervisor combination often determines the required features of OpenStack. Certain features are only available with specific OSes or hypervisors. For example, if certain features are not available, you might need to modify the design to meet user requirements."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:454(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:160(para) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:653(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:413(term)
|
||||
#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:454(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:160(para) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:653(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:366(term)
|
||||
msgid "Interoperability"
|
||||
msgstr ""
|
||||
|
||||
@ -3353,7 +3353,7 @@ msgstr ""
|
||||
msgid "Replication"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:117(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:774(para)
|
||||
#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:117(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:727(para)
|
||||
msgid "Management"
|
||||
msgstr ""
|
||||
|
||||
@ -3484,7 +3484,7 @@ msgid "A firewall, switches and load balancers on the public facing network conn
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:112(para)
|
||||
msgid "OpenStack Controller services running, Networking, dashboard, Block Storage and Compute running locally in each of the three regions. Identity service, Orchestration service, Telemetry service, Image service and Object Storage can be installed centrally, with nodes in each of the region providing a redundant OpenStack Controller plane throughout the globe."
|
||||
msgid "OpenStack Controller services running, Networking, dashboard, Block Storage and Compute running locally in each of the three regions. Identity service, Orchestration module, Telemetry module, Image service and Object Storage service can be installed centrally, with nodes in each of the region providing a redundant OpenStack Controller plane throughout the globe."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:121(para) ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:44(para)
|
||||
@ -4185,7 +4185,7 @@ msgstr ""
|
||||
msgid "It is imperative to address security considerations. For example, addressing how data is secured between client and endpoint and any traffic that traverses the multiple clouds. Business and regulatory requirements dictate what security approach to take. For more information, see the <link linkend=\"security-overview\">Security Requirements Chapter</link>"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:168(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:777(para)
|
||||
#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:168(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:730(para)
|
||||
msgid "Data"
|
||||
msgstr ""
|
||||
|
||||
@ -4577,7 +4577,7 @@ msgstr ""
|
||||
msgid "The network aspect of deploying a nested cloud is the most complicated aspect of this architecture. You must expose VLANs to the physical ports on which the underlying cloud runs because the bare metal cloud owns all the hardware. You must also expose them to the nested levels as well. Alternatively, you can use the network overlay technologies on the OpenStack environment running on the host OpenStack environment to provide the required software defined networking for the deployment."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:37(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:425(title)
|
||||
#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:37(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:378(title)
|
||||
msgid "Hypervisor"
|
||||
msgstr ""
|
||||
|
||||
@ -5127,7 +5127,7 @@ msgstr ""
|
||||
msgid "The network design should encompass a physical and logical network design that can be easily expanded upon. Network hardware should offer the appropriate types of interfaces and speeds that are required by the hardware nodes."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:531(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:678(title)
|
||||
#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:531(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:631(title)
|
||||
msgid "Availability"
|
||||
msgstr ""
|
||||
|
||||
@ -5380,470 +5380,454 @@ msgid "For a deeper discussion on many of these topics, refer to the <link xlink
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:13(para)
|
||||
msgid "General purpose clouds are often expected to include these base services:"
|
||||
msgid "General purpose clouds are expected to include these base services:"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:32(para)
|
||||
msgid "Each of these services have different resource requirements. As a result, you must make design decisions relating directly to the service, as well as provide a balanced infrastructure for all services."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:35(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:36(para)
|
||||
msgid "Take into consideration the unique aspects of each service, as individual characteristics and service mass can impact the hardware selection process. Hardware designs should be generated for each of the services."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:38(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:40(para)
|
||||
msgid "Hardware decisions are also made in relation to network architecture and facilities planning. These factors play heavily into the overall architecture of an OpenStack cloud."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:43(title)
|
||||
msgid "Designing compute resources"
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:45(title)
|
||||
msgid "Compute resource design"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:44(para)
|
||||
msgid "When designing compute resource pools, a number of factors can impact your design decisions. For example, decisions related to processors, memory, and storage within each hypervisor are just one element of designing compute resources. In addition, decide whether to provide compute resources in a single pool or in multiple pools. We recommend the compute design allocates multiple pools of resources to be addressed on-demand."
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:46(para)
|
||||
msgid "When designing compute resource pools, a number of factors can impact your design decisions. Factors such as number of processors, amount of memory, and the quantity of storage required for each hypervisor must be taken into account."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:52(para)
|
||||
msgid "A compute design that allocates multiple pools of resources makes best use of application resources running in the cloud. Each independent resource pool should be designed to provide service for specific flavors of instances or groupings of flavors. Designing multiple resource pools helps to ensure that, as instances are scheduled onto compute hypervisors, each independent node's resources will be allocated to make the most efficient use of available hardware. This is commonly referred to as bin packing."
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:50(para)
|
||||
msgid "You will also need to decide whether to provide compute resources in a single pool or in multiple pools. In most cases, multiple pools of resources can be allocated and addressed on demand. A compute design that allocates multiple pools of resources makes best use of application resources, and is commonly referred to as <firstterm>bin packing</firstterm>."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:60(para)
|
||||
msgid "Using a consistent hardware design among the nodes that are placed within a resource pool also helps support bin packing. Hardware nodes selected for being a part of a compute resource pool should share a common processor, memory, and storage layout. By choosing a common hardware design, it becomes easier to deploy, support and maintain those nodes throughout their life cycle in the cloud."
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:56(para)
|
||||
msgid "In a bin packing design, each independent resource pool provides service for specific flavors. This helps to ensure that, as instances are scheduled onto compute hypervisors, each independent node's resources will be allocated in a way that makes the most efficient use of the available hardware. Bin packing also requires a common hardware design, with all hardware nodes within a compute resource pool sharing a common processor, memory, and storage layout. This makes it easier to deploy, support, and maintain nodes throughout their life cycle."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:67(para)
|
||||
msgid "An <firstterm>overcommit ratio</firstterm> is the ratio of available virtual resources, compared to the available physical resources. OpenStack is able to configure the overcommit ratio for CPU and memory. The default CPU overcommit ratio is 16:1 and the default memory overcommit ratio is 1.5:1. Determining the tuning of the overcommit ratios for both of these options during the design phase is important as it has a direct impact on the hardware layout of your compute nodes."
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:64(para)
|
||||
msgid "An <firstterm>overcommit ratio</firstterm> is the ratio of available virtual resources to available physical resources. This ratio is configurable for CPU and memory. The default CPU overcommit ratio is 16:1, and the default memory overcommit ratio is 1.5:1. Determining the tuning of the overcommit ratios during the design phase is important as it has a direct impact on the hardware layout of your compute nodes."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:74(para)
|
||||
msgid "For example, consider a m1.small instance uses 1 vCPU, 20GB of ephemeral storage and 2,048MB of RAM. When designing a hardware node as a compute resource pool to service instances, take into consideration the number of processor cores available on the node as well as the required disk and memory to service instances running at capacity. For a server with 2 CPUs of 10 cores each, with hyperthreading turned on, the default CPU overcommit ratio of 16:1 would allow for 640 (2 10 2 16) total m1.small instances. By the same reasoning, using the default memory overcommit ratio of 1.5:1 you can determine that the server will need at least 853GB (640 2,048MB / 1.5) of RAM. When sizing nodes for memory, it is also important to consider the additional memory required to service operating system and service needs."
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:70(para)
|
||||
msgid "For example, if you wanted to design a hardware node as a compute resource pool to service instances, consider the number of processor cores available on the node as well as the required disk and memory to service instances running at capacity. For a server with 2 CPUs of 10 cores each, with hyperthreading turned on, the default CPU overcommit ratio of 16:1 would allow for 640 (2 10 2 16) total m1.small instances, where each instance uses 1 vCPU, 20GB of ephemeral storage and 2,048MB of RAM. By the same reasoning, using the default memory overcommit ratio of 1.5:1 you can determine that the server will need at least 853GB (640 2,048MB / 1.5) of RAM. When sizing nodes for memory, it is also important to consider the additional memory required to service operating system and service needs."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:88(para)
|
||||
msgid "Processor selection is an extremely important consideration in hardware design, especially when comparing the features and performance characteristics of different processors. Processors can include features specific to virtualized compute hosts including hardware assisted virtualization and technology related to memory paging (also known as EPT shadowing). These types of features can have a significant impact on the performance of your virtual machine running in the cloud."
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:82(para)
|
||||
msgid "When selecting a processor, compare features and performance characteristics. Some processors include features specific to virtualized compute hosts, such as hardware-assisted virtualization, and technology related to memory paging (also known as EPT shadowing). These types of features can have a significant impact on the performance of your virtual machine."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:95(para)
|
||||
msgid "It is also important to consider the compute requirements of resource nodes within the cloud. Resource nodes refer to non-hypervisor nodes providing the following in the cloud:"
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:87(para)
|
||||
msgid "You will also need to consider the compute requirements of non-hypervisor nodes (sometimes referred to as resource nodes). This includes controller, object storage, and block storage nodes, and networking services."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:100(para)
|
||||
msgid "Controller"
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:90(para)
|
||||
msgid "The number of processor cores and threads impacts the number of worker threads which can be run on a resource node. Design decisions must relate directly to the service being run on it, as well as provide a balanced infrastructure for all services."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:105(para)
|
||||
msgid "Object storage"
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:94(para)
|
||||
msgid "Workload can be unpredictable in a general purpose cloud, so consider including the ability to add additional compute resource pools on demand. In some cases, however, the demand for certain instance types or flavors may not justify individual hardware design. In either case, start by allocating hardware designs that are capable of servicing the most common instance requests. If you want to add additional hardware to the overall architecture, this can be done later."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:110(para)
|
||||
msgid "Block storage"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:115(para)
|
||||
msgid "Networking services"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:120(para)
|
||||
msgid "The number of processor cores and threads has a direct correlation to the number of worker threads which can be run on a resource node. As a result, you must make design decisions relating directly to the service, as well as provide a balanced infrastructure for all services."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:124(para)
|
||||
msgid "Workload profiles are unpredictable in a general purpose cloud. Additional compute resource pools can be added to the cloud later, reducing the stress of unpredictability. In some cases, the demand on certain instance types or flavors may not justify individual hardware design. In either of these cases, initiate the design by allocating hardware designs that are capable of servicing the most common instances requests. If you are looking to add additional hardware designs to the overall architecture, this can be done at a later time."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:136(title)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:104(title)
|
||||
msgid "Designing network resources"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:137(para)
|
||||
msgid "OpenStack clouds traditionally have multiple network segments, each of which provides access to resources within the cloud to both operators and tenants. The network services themselves also require network communication paths which should be separated from the other networks. When designing network services for a general purpose cloud, we recommend planning for a physical or logical separation of network segments that will be used by operators and tenants. We further suggest the creation of an additional network segment for access to internal services such as the message bus and databse used by the various cloud services. Segregating these services onto separate networks helps to protect sensitive data and protects against unauthorized access to services."
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:105(para)
|
||||
msgid "OpenStack clouds generally have multiple network segments, with each segment providing access to particular resources. The network services themselves also require network communication paths which should be separated from the other networks. When designing network services for a general purpose cloud, plan for either a physical or logical separation of network segments used by operators and tenants. You can also create an additional network segment for access to internal services such as the message bus and database used by various services. Segregating these services onto separate networks helps to protect sensitive data and protects against unauthorized access to services."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:149(para)
|
||||
msgid "Based on the requirements of instances being serviced in the cloud, the choice of network service will be the next decision that affects your design architecture."
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:115(para)
|
||||
msgid "Choose a networking service based on the requirements of your instances. The architecture and design of your cloud will impact whether you choose OpenStack Networking(neutron), or legacy networking (nova-network)."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:152(para)
|
||||
msgid "The choice between legacy networking (nova-network), as a part of OpenStack Compute, and OpenStack Networking (neutron), has a huge impact on the architecture and design of the cloud network infrastructure."
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:122(para)
|
||||
msgid "The legacy networking (nova-network) service is primarily a layer-2 networking service that functions in two modes, which use VLANs in different ways. In a flat network mode, all network hardware nodes and devices throughout the cloud are connected to a single layer-2 network segment that provides access to application data."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:160(para)
|
||||
msgid "The legacy networking (nova-network) service is primarily a layer-2 networking service that functions in two modes. In legacy networking, the two modes differ in their use of VLANs. When using legacy networking in a flat network mode, all network hardware nodes and devices throughout the cloud are connected to a single layer-2 network segment that provides access to application data."
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:128(para)
|
||||
msgid "When the network devices in the cloud support segmentation using VLANs, legacy networking can operate in the second mode. In this design model, each tenant within the cloud is assigned a network subnet which is mapped to a VLAN on the physical network. It is especially important to remember the maximum number of 4096 VLANs which can be used within a spanning tree domain. This places a hard limit on the amount of growth possible within the data center. When designing a general purpose cloud intended to support multiple tenants, we recommend the use of legacy networking with VLANs, and not in flat network mode."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:167(para)
|
||||
msgid "When the network devices in the cloud support segmentation using VLANs, legacy networking can operate in the second mode. In this design model, each tenant within the cloud is assigned a network subnet which is mapped to a VLAN on the physical network. It is especially important to remember the maximum number of 4096 VLANs which can be used within a spanning tree domain. These limitations place hard limits on the amount of growth possible within the data center. When designing a general purpose cloud intended to support multiple tenants, we recommend the use of legacy networking with VLANs, and not in flat network mode."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:181(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:142(para)
|
||||
msgid "Another consideration regarding network is the fact that legacy networking is entirely managed by the cloud operator; tenants do not have control over network resources. If tenants require the ability to manage and create network resources such as network segments and subnets, it will be necessary to install the OpenStack Networking service to provide network access to instances."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:190(term)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:151(term)
|
||||
msgid "OpenStack Networking (neutron)"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:192(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:153(para)
|
||||
msgid "OpenStack Networking (neutron) is a first class networking service that gives full control over creation of virtual network resources to tenants. This is often accomplished in the form of tunneling protocols which will establish encapsulated communication paths over existing network infrastructure in order to segment tenant traffic. These methods vary depending on the specific implementation, but some of the more common methods include tunneling over GRE, encapsulating with VXLAN, and VLAN tags."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:204(para)
|
||||
msgid "Initially, it is suggested to design at least three network segments, the first of which will be used for access to the cloud's REST APIs by tenants and operators. This is referred to as a public network. In most cases, the controller nodes and swift proxies within the cloud will be the only devices necessary to connect to this network segment. In some cases, this network might also be serviced by hardware load balancers and other network devices."
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:165(para)
|
||||
msgid "Initially, we recommend you design at least three network segments."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:212(para)
|
||||
msgid "The next segment is used by cloud administrators to manage hardware resources and is also used by configuration management tools when deploying software and services onto new hardware. In some cases, this network segment might also be used for internal services, including the message bus and database services, to communicate with each other. Due to the highly secure nature of this network segment, it may be desirable to secure this network from unauthorized access. This network will likely need to communicate with every hardware node within the cloud."
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:166(para)
|
||||
msgid "The first segment is a public network, used for access to REST APIs by tenants and operators. Generally, the controller nodes and swift proxies will be the only devices connecting to this network segment. In some cases, this network might also be serviced by hardware load balancers and other network devices."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:222(para)
|
||||
msgid "The last network segment is used by applications and consumers to provide access to the physical network and also for users accessing applications running within the cloud. This network is generally segregated from the one used to access the cloud APIs and is not capable of communicating directly with the hardware resources in the cloud. Compute resource nodes will need to communicate on this network segment, as will any network gateway services which allow application data to access the physical network outside of the cloud."
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:171(para)
|
||||
msgid "The second segment is used by administrators to manage hardware resources. It is also used by configuration management tools for deploying software and services onto new hardware. In some cases, this network segment might also be used for internal services, including the message bus and database services. This network will probably need to communicate with every hardware node. Due to the highly secure nature of this network segment, you will also need to secure this network from unauthorized access."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:235(title)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:178(para)
|
||||
msgid "The third network segment is used by applications and consumers to access the physical network, and for users to access applications. This network is generally segregated from the one used to access the cloud APIs and is not capable of communicating directly with the hardware resources in the cloud. Compute resource nodes will need to communicate on this network segment, as will any network gateway services which allow application data to access the physical network from outside of the cloud."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:188(title)
|
||||
msgid "Designing storage resources"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:236(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:189(para)
|
||||
msgid "OpenStack has two independent storage services to consider, each with its own specific design requirements and goals. In addition to services which provide storage as their primary function, there are additional design considerations with regard to compute and controller nodes which will affect the overall cloud architecture."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:245(title)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:198(title)
|
||||
msgid "Designing OpenStack Object Storage"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:246(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:199(para)
|
||||
msgid "When designing hardware resources for OpenStack Object Storage, the primary goal is to maximize the amount of storage in each resource node while also ensuring that the cost per terabyte is kept to a minimum. This often involves utilizing servers which can hold a large number of spinning disks. Whether choosing to use 2U server form factors with directly attached storage or an external chassis that holds a larger number of drives, the main goal is to maximize the storage available in each node."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:255(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:208(para)
|
||||
msgid "We do not recommended investing in enterprise class drives for an OpenStack Object Storage cluster. The consistency and partition tolerance characteristics of OpenStack Object Storage will ensure that data stays up to date and survives hardware faults without the use of any specialized data replication devices."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:261(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:214(para)
|
||||
msgid "One of the benefits of OpenStack Object Storage is the ability to mix and match drives by making use of weighting within the swift ring. When designing your swift storage cluster, we recommend making use of the most cost effective storage solution available at the time. Many server chassis on the market can hold 60 or more drives in 4U of rack space, therefore we recommend maximizing the amount of storage per rack unit at the best cost per terabyte. Furthermore, we do not recommend the use of RAID controllers in an object storage node."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:271(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:224(para)
|
||||
msgid "To achieve durability and availability of data stored as objects it is important to design object storage resource pools to ensure they can provide the suggested availability. Considering rack-level and zone-level designs to accommodate the number of replicas configured to be stored in the Object Storage service (the defult number of replicas is three) is important when designing beyond the hardware node level. Each replica of data should exist in its own availability zone with its own power, cooling, and network resources available to service that specific zone."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:280(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:233(para)
|
||||
msgid "Object storage nodes should be designed so that the number of requests does not hinder the performance of the cluster. The object storage service is a chatty protocol, therefore making use of multiple processors that have higher core counts will ensure the IO requests do not inundate the server."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:288(title)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:241(title)
|
||||
msgid "Designing OpenStack Block Storage"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:289(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:242(para)
|
||||
msgid "When designing OpenStack Block Storage resource nodes, it is helpful to understand the workloads and requirements that will drive the use of block storage in the cloud. We recommend designing block storage pools so that tenants can choose appropriate storage solutions for their applications. By creating multiple storage pools of different types, in conjunction with configuring an advanced storage scheduler for the block storage service, it is possible to provide tenants with a large catalog of storage services with a variety of performance levels and redundancy options."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:298(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:251(para)
|
||||
msgid "Block storage also takes advantage of a number of enterprise storage solutions. These are addressed via a plug-in driver developed by the hardware vendor. A large number of enterprise storage plug-in drivers ship out-of-the-box with OpenStack Block Storage (and many more available via third party channels). General purpose clouds are more likely to use directly attached storage in the majority of block storage nodes, deeming it necessary to provide additional levels of service to tenants which can only be provided by enterprise class storage solutions."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:307(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:260(para)
|
||||
msgid "Redundancy and availability requirements impact the decision to use a RAID controller card in block storage nodes. The input-output per second (IOPS) demand of your application will influence whether or not you should use a RAID controller, and which level of RAID is required. Making use of higher performing RAID volumes is suggested when considering performance. However, where redundancy of block storage volumes is more important we recommend making use of a redundant RAID configuration such as RAID 5 or RAID 6. Some specialized features, such as automated replication of block storage volumes, may require the use of third-party plug-ins and enterprise block storage solutions in order to provide the high demand on storage. Furthermore, where extreme performance is a requirement it may also be necessary to make use of high speed SSD disk drives' high performing flash storage solutions."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:326(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:279(para)
|
||||
msgid "The software selection process plays a large role in the architecture of a general purpose cloud. The following have a large impact on the design of the cloud:"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:331(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:284(para)
|
||||
msgid "Choice of operating system"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:336(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:289(para)
|
||||
msgid "Selection of OpenStack software components"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:341(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:294(para)
|
||||
msgid "Choice of hypervisor"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:346(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:299(para)
|
||||
msgid "Selection of supplemental software"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:351(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:304(para)
|
||||
msgid "Operating system (OS) selection plays a large role in the design and architecture of a cloud. There are a number of OSes which have native support for OpenStack including:"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:356(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:309(para)
|
||||
msgid "Ubuntu"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:361(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:314(para)
|
||||
msgid "Red Hat Enterprise Linux (RHEL)"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:366(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:319(para)
|
||||
msgid "CentOS"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:371(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:324(para)
|
||||
msgid "SUSE Linux Enterprise Server (SLES)"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:377(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:330(para)
|
||||
msgid "Native support is not a constraint on the choice of OS; users are free to choose just about any Linux distribution (or even Microsoft Windows) and install OpenStack directly from source (or compile their own packages). However, many organizations will prefer to install OpenStack from distribution-supplied packages or repositories (although using the distribution vendor's OpenStack packages might be a requirement for support)."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:386(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:339(para)
|
||||
msgid "OS selection also directly influences hypervisor selection. A cloud architect who selects Ubuntu, RHEL, or SLES has some flexibility in hypervisor; KVM, Xen, and LXC are supported virtualization methods available under OpenStack Compute (nova) on these Linux distributions. However, a cloud architect who selects Hyper-V is limited to Windows Servers. Similarly, a cloud architect who selects XenServer is limited to the CentOS-based dom0 operating system provided with XenServer."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:394(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:347(para)
|
||||
msgid "The primary factors that play into OS-hypervisor selection include:"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:400(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:353(para)
|
||||
msgid "The selection of OS-hypervisor combination first and foremost needs to support the user requirements."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:406(term)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:359(term)
|
||||
msgid "Support"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:408(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:361(para)
|
||||
msgid "The selected OS-hypervisor combination needs to be supported by OpenStack."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:415(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:368(para)
|
||||
msgid "The OS-hypervisor needs to be interoperable with other features and services in the OpenStack design in order to meet the user requirements."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:426(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:379(para)
|
||||
msgid "OpenStack supports a wide variety of hypervisors, one or more of which can be used in a single cloud. These hypervisors include:"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:431(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:384(para)
|
||||
msgid "KVM (and QEMU)"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:434(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:387(para)
|
||||
msgid "XCP/XenServer"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:437(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:390(para)
|
||||
msgid "vSphere (vCenter and ESXi)"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:440(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:393(para)
|
||||
msgid "Hyper-V"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:443(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:396(para)
|
||||
msgid "LXC"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:446(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:399(para)
|
||||
msgid "Docker"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:449(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:402(para)
|
||||
msgid "Bare-metal"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:452(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:405(para)
|
||||
msgid "A complete list of supported hypervisors and their capabilities can be found at <link xlink:href=\"https://wiki.openstack.org/wiki/HypervisorSupportMatrix\">OpenStack Hypervisor Support Matrix</link>."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:456(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:409(para)
|
||||
msgid "We recommend general purpose clouds use hypervisors that support the most general purpose use cases, such as KVM and Xen. More specific hypervisors should be chosen to account for specific functionality or a supported feature requirement. In some cases, there may also be a mandated requirement to run software on a certified hypervisor including solutions from VMware, Microsoft, and Citrix."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:463(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:416(para)
|
||||
msgid "The features offered through the OpenStack cloud platform determine the best choice of a hypervisor. As an example, for a general purpose cloud that predominantly supports a Microsoft-based migration, or is managed by staff that has a particular skill for managing certain hypervisors and operating systems, Hyper-V would be the best available choice. While the decision to use Hyper-V does not limit the ability to run alternative operating systems, be mindful of those that are deemed supported. Each different hypervisor also has their own hardware requirements which may affect the decisions around designing a general purpose cloud. For example, to utilize the live migration feature of VMware, vMotion, this requires an installation of vCenter/vSphere and the use of the ESXi hypervisor, which increases the infrastructure requirements."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:478(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:431(para)
|
||||
msgid "In a mixed hypervisor environment, specific aggregates of compute resources, each with defined capabilities, enable workloads to utilize software and hardware specific to their particular requirements. This functionality can be exposed explicitly to the end user, or accessed through defined metadata within a particular flavor of an instance."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:488(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:441(para)
|
||||
msgid "A general purpose OpenStack cloud design should incorporate the core OpenStack services to provide a wide range of services to end-users. The OpenStack core services recommended in a general purpose cloud are:"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:494(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:447(para)
|
||||
msgid "OpenStack <glossterm>Compute</glossterm> (<glossterm>nova</glossterm>)"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:498(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:451(para)
|
||||
msgid "OpenStack <glossterm>Networking</glossterm> (<glossterm>neutron</glossterm>)"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:502(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:455(para)
|
||||
msgid "OpenStack <glossterm>Image service</glossterm> (<glossterm>glance</glossterm>)"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:506(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:459(para)
|
||||
msgid "OpenStack <glossterm>Identity</glossterm> (<glossterm>keystone</glossterm>)"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:510(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:463(para)
|
||||
msgid "OpenStack <glossterm>dashboard</glossterm> (<glossterm>horizon</glossterm>)"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:514(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:467(para)
|
||||
msgid "<glossterm>Telemetry</glossterm> module (<glossterm>ceilometer</glossterm>)"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:518(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:471(para)
|
||||
msgid "A general purpose cloud may also include OpenStack <glossterm>Object Storage</glossterm> (<glossterm>swift</glossterm>). OpenStack <glossterm>Block Storage</glossterm> (<glossterm>cinder</glossterm>). These may be selected to provide storage to applications and instances."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:525(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:478(para)
|
||||
msgid "However, depending on the use case, these could be optional."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:532(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:485(para)
|
||||
msgid "A general purpose OpenStack deployment consists of more than just OpenStack-specific components. A typical deployment involves services that provide supporting functionality, including databases and message queues, and may also involve software to provide high availability of the OpenStack environment. Design decisions around the underlying message queue might affect the required number of controller services, as well as the technology to provide highly resilient database functionality, such as MariaDB with Galera. In such a scenario, replication of services relies on quorum. Therefore, the underlying database nodes, for example, should consist of at least 3 nodes to account for the recovery of a failed Galera node. When increasing the number of nodes to support a feature of the software, consideration of rack space and switch port density becomes important."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:547(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:500(para)
|
||||
msgid "Where many general purpose deployments use hardware load balancers to provide highly available API access and SSL termination, software solutions, for example HAProxy, can also be considered. It is vital to ensure that such software implementations are also made highly available. High availability can be achieved by using software such as Keepalived or Pacemaker with Corosync. Pacemaker and Corosync can provide active-active or active-passive highly available configuration depending on the specific service in the OpenStack environment. Using this software can affect the design as it assumes at least a 2-node controller infrastructure where one of those nodes may be running certain services in standby mode."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:560(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:513(para)
|
||||
msgid "Memcached is a distributed memory object caching system, and Redis is a key-value store. Both are deployed on general purpose clouds to assist in alleviating load to the Identity service. The memcached service caches tokens, and due to its distributed nature it can help alleviate some bottlenecks to the underlying authentication system. Using memcached or Redis does not affect the overall design of your architecture as they tend to be deployed onto the infrastructure nodes providing the OpenStack services."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:573(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:526(para)
|
||||
msgid "Performance of an OpenStack deployment is dependent on a number of factors related to the infrastructure and controller services. The user requirements can be split into general network performance, performance of compute resources, and performance of storage systems."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:581(title)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:534(title)
|
||||
msgid "Controller infrastructure"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:582(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:535(para)
|
||||
msgid "The Controller infrastructure nodes provide management services to the end-user as well as providing services internally for the operating of the cloud. The Controllers run message queuing services that carry system messages between each service. Performance issues related to the message bus would lead to delays in sending that message to where it needs to go. The result of this condition would be delays in operation functions such as spinning up and deleting instances, provisioning new storage volumes and managing network resources. Such delays could adversely affect an application’s ability to react to certain conditions, especially when using auto-scaling features. It is important to properly design the hardware used to run the controller infrastructure as outlined above in the Hardware Selection section."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:597(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:550(para)
|
||||
msgid "Performance of the controller services is not limited to processing power, but restrictions may emerge in serving concurrent users. Ensure that the APIs and Horizon services are load tested to ensure that you are able to serve your customers. Particular attention should be made to the OpenStack Identity Service (Keystone), which provides the authentication and authorization for all services, both internally to OpenStack itself and to end-users. This service can lead to a degradation of overall performance if this is not sized appropriately."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:610(title)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:563(title)
|
||||
msgid "Network performance"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:611(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:564(para)
|
||||
msgid "In a general purpose OpenStack cloud, the requirements of the network help determine performance capabilities. For example, small deployments may employ 1 Gigabit Ethernet (GbE) networking, whereas larger installations serving multiple departments or many users would be better architected with 10GbE networking. The performance of the running instances will be limited by these speeds. It is possible to design OpenStack environments that run a mix of networking capabilities. By utilizing the different interface speeds, the users of the OpenStack environment can choose networks that are fit for their purpose."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:622(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:575(para)
|
||||
msgid "For example, web application instances may run on a public network presented through OpenStack Networking that has 1 GbE capability, whereas the back-end database uses an OpenStack Networking network that has 10GbE capability to replicate its data or, in some cases, the design may incorporate link aggregation for greater throughput."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:628(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:581(para)
|
||||
msgid "Network performance can be boosted considerably by implementing hardware load balancers to provide front-end service to the cloud APIs. The hardware load balancers also perform SSL termination if that is a requirement of your environment. When implementing SSL offloading, it is important to understand the SSL offloading capabilities of the devices selected."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:638(title)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:591(title)
|
||||
msgid "Compute host"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:639(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:592(para)
|
||||
msgid "The choice of hardware specifications used in compute nodes including CPU, memory and disk type directly affects the performance of the instances. Other factors which can directly affect performance include tunable parameters within the OpenStack services, for example the overcommit ratio applied to resources. The defaults in OpenStack Compute set a 16:1 over-commit of the CPU and 1.5 over-commit of the memory. Running at such high ratios leads to an increase in \"noisy-neighbor\" activity. Care must be taken when sizing your Compute environment to avoid this scenario. For running general purpose OpenStack environments it is possible to keep to the defaults, but make sure to monitor your environment as usage increases."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:655(title)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:608(title)
|
||||
msgid "Storage performance"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:656(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:609(para)
|
||||
msgid "When considering performance of OpenStack Block Storage, hardware and architecture choice is important. Block Storage can use enterprise back-end systems such as NetApp or EMC, scale out storage such as GlusterFS and Ceph, or simply use the capabilities of directly attached storage in the nodes themselves. Block Storage may be deployed so that traffic traverses the host network, which could affect, and be adversely affected by, the front-side API traffic performance. As such, consider using a dedicated data storage network with dedicated interfaces on the Controller and Compute hosts."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:667(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:620(para)
|
||||
msgid "When considering performance of OpenStack Object Storage, a number of design choices will affect performance. A user’s access to the Object Storage is through the proxy services, which sit behind hardware load balancers. By the very nature of a highly resilient storage system, replication of the data would affect performance of the overall system. In this case, 10 GbE (or better) networking is recommended throughout the storage network architecture."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:679(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:632(para)
|
||||
msgid "In OpenStack, the infrastructure is integral to providing services and should always be available, especially when operating with SLAs. Ensuring network availability is accomplished by designing the network architecture so that no single point of failure exists. A consideration of the number of switches, routes and redundancies of power should be factored into core infrastructure, as well as the associated bonding of networks to provide diverse routes to your highly available switch infrastructure."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:688(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:641(para)
|
||||
msgid "The OpenStack services themselves should be deployed across multiple servers that do not represent a single point of failure. Ensuring API availability can be achieved by placing these services behind highly available load balancers that have multiple OpenStack servers as members."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:693(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:646(para)
|
||||
msgid "OpenStack lends itself to deployment in a highly available manner where it is expected that at least 2 servers be utilized. These can run all the services involved from the message queuing service, for example RabbitMQ or QPID, and an appropriately deployed database service such as MySQL or MariaDB. As services in the cloud are scaled out, back-end services will need to scale too. Monitoring and reporting on server utilization and response times, as well as load testing your systems, will help determine scale out decisions."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:702(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:655(para)
|
||||
msgid "Care must be taken when deciding network functionality. Currently, OpenStack supports both the legacy networking (nova-network) system and the newer, extensible OpenStack Networking (neutron). Both have their pros and cons when it comes to providing highly available access. Legacy networking, which provides networking access maintained in the OpenStack Compute code, provides a feature that removes a single point of failure when it comes to routing, and this feature is currently missing in OpenStack Networking. The effect of legacy networking’s multi-host functionality restricts failure domains to the host running that instance."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:713(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:666(para)
|
||||
msgid "When using OpenStack Networking, the OpenStack controller servers or separate Networking hosts handle routing. For a deployment that requires features available in only Networking, it is possible to remove this restriction by using third party software that helps maintain highly available L3 routes. Doing so allows for common APIs to control network hardware, or to provide complex multi-tier web applications in a secure manner. It is also possible to completely remove routing from Networking, and instead rely on hardware routing capabilities. In this case, the switching infrastructure must support L3 routing."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:725(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:678(para)
|
||||
msgid "OpenStack Networking and legacy networking both have their advantages and disadvantages. They are both valid and supported options that fit different network deployment models described in the <citetitle><link xlink:href=\"http://docs.openstack.org/openstack-ops/content/network_design.html#network_deployment_options\">OpenStack Operations Guide</link></citetitle>."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:732(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:685(para)
|
||||
msgid "Ensure your deployment has adequate back-up capabilities. As an example, in a deployment that has two infrastructure controller nodes, the design should include controller availability. In the event of the loss of a single controller, cloud services will run from a single controller in the event of failure. Where the design has higher availability requirements, it is important to meet those requirements by designing the proper redundancy and availability of controller nodes."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:741(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:694(para)
|
||||
msgid "Application design must also be factored into the capabilities of the underlying cloud infrastructure. If the compute hosts do not provide a seamless live migration capability, then it must be expected that when a compute host fails, that instance and any data local to that instance will be deleted. Conversely, when providing an expectation to users that instances have a high-level of uptime guarantees, the infrastructure must be deployed in a way that eliminates any single point of failure when a compute host disappears. This may include utilizing shared file systems on enterprise storage or OpenStack Block storage to provide a level of guarantee to match service features."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:753(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:706(para)
|
||||
msgid "For more information on high availability in OpenStack, see the <link xlink:href=\"http://docs.openstack.org/high-availability-guide\"><citetitle>OpenStack High Availability Guide</citetitle></link>."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:761(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:714(para)
|
||||
msgid "A security domain comprises users, applications, servers or networks that share common trust requirements and expectations within a system. Typically they have the same authentication and authorization requirements and users."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:765(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:718(para)
|
||||
msgid "These security domains are:"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:768(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:721(para)
|
||||
msgid "Public"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:771(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:724(para)
|
||||
msgid "Guest"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:780(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:733(para)
|
||||
msgid "These security domains can be mapped to an OpenStack deployment individually, or combined. For example, some deployment topologies combine both guest and data domains onto one physical network, whereas in other cases these networks are physically separated. In each case, the cloud operator should be aware of the appropriate security concerns. Security domains should be mapped out against your specific OpenStack deployment topology. The domains and their trust requirements depend upon whether the cloud instance is public, private, or hybrid."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:790(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:743(para)
|
||||
msgid "The public security domain is an entirely untrusted area of the cloud infrastructure. It can refer to the Internet as a whole or simply to networks over which you have no authority. This domain should always be considered untrusted."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:805(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:758(para)
|
||||
msgid "The management security domain is where services interact. Sometimes referred to as the \"control plane\", the networks in this domain transport confidential data such as configuration parameters, user names, and passwords. In most deployments this domain is considered trusted."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:810(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:763(para)
|
||||
msgid "The data security domain is concerned primarily with information pertaining to the storage services within OpenStack. Much of the data that crosses this network has high integrity and confidentiality requirements and, depending on the type of deployment, may also have strong availability requirements. The trust level of this network is heavily dependent on other deployment decisions."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:817(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:770(para)
|
||||
msgid "When deploying OpenStack in an enterprise as a private cloud it is usually behind the firewall and within the trusted network alongside existing systems. Users of the cloud are, traditionally, employees that are bound by the security requirements set forth by the company. This tends to push most of the security domains towards a more trusted model. However, when deploying OpenStack in a public facing role, no assumptions can be made and the attack vectors significantly increase. For example, the API endpoints, along with the software behind them, become vulnerable to bad actors wanting to gain unauthorized access or prevent access to services, which could lead to loss of data, functionality, and reputation. These services must be protected against through auditing and appropriate filtering."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:831(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:784(para)
|
||||
msgid "Consideration must be taken when managing the users of the system for both public and private clouds. The identity service allows for LDAP to be part of the authentication process. Including such systems in an OpenStack deployment may ease user management if integrating into existing systems."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:837(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:790(para)
|
||||
msgid "It's important to understand that user authentication requests include sensitive information including user names, passwords and authentication tokens. For this reason, placing the API services behind hardware that performs SSL termination is strongly recommended."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:842(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:795(para)
|
||||
msgid "For more information OpenStack Security, see the <link xlink:href=\"http://docs.openstack.org/security-guide/\"><citetitle>OpenStack Security Guide</citetitle></link>"
|
||||
msgstr ""
|
||||
|
||||
@ -5941,63 +5925,59 @@ msgstr ""
|
||||
msgid "Revenue opportunities for a cloud will vary greatly based on the intended use case of that particular cloud. Some general purpose clouds are built for commercial customer facing products, but there are alternatives that might make the general purpose cloud the right choice. For example, a small cloud service provider (CSP) might want to build a general purpose cloud rather than a massively scalable cloud because they do not have the deep financial resources needed, or because they do not, or will not, know in advance the purposes for which their customers are going to use the cloud. For some users, the advantages cloud itself offers mean an enhancement of revenue opportunity. For others, the fact that a general purpose cloud provides only baseline functionality will be a disincentive for use, leading to a potential stagnation of potential revenue opportunities."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:103(para)
|
||||
msgid "Examples of such legal frameworks include the <link xlink:href=\"http://ec.europa.eu/justice/data-protection/\">data protection framework</link> of the European Union and the requirements of the <link xlink:href=\"http://www.finra.org/Industry/Regulation/FINRARules/\">Financial Industry Regulatory Authority</link> in the United States. Consult a local regulatory body for more information."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:114(title)
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:77(title)
|
||||
msgid "Technical requirements"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:115(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:78(para)
|
||||
msgid "Technical cloud architecture requirements should be weighted against the business requirements."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:122(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:85(para)
|
||||
msgid "As a baseline product, general purpose clouds do not provide optimized performance for any particular function. While a general purpose cloud should provide enough performance to satisfy average user considerations, performance is not a general purpose cloud customer driver."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:131(term)
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:94(term)
|
||||
msgid "No predefined usage model"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:133(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:96(para)
|
||||
msgid "The lack of a pre-defined usage model enables the user to run a wide variety of applications without having to know the application requirements in advance. This provides a degree of independence and flexibility that no other cloud scenarios are able to provide."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:142(term)
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:105(term)
|
||||
msgid "On-demand and self-service application"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:144(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:107(para)
|
||||
msgid "By definition, a cloud provides end users with the ability to self-provision computing power, storage, networks, and software in a simple and flexible way. The user must be able to scale their resources up to a substantial level without disrupting the underlying host operations. One of the benefits of using a general purpose cloud architecture is the ability to start with limited resources and increase them over time as the user demand grows."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:157(term)
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:120(term)
|
||||
msgid "Public cloud"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:159(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:122(para)
|
||||
msgid "For a company interested in building a commercial public cloud offering based on OpenStack, the general purpose architecture model might be the best choice. Designers are not always going to know the purposes or workloads for which the end users will use the cloud."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:168(term)
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:131(term)
|
||||
msgid "Internal consumption (private) cloud"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:170(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:133(para)
|
||||
msgid "Organizations need to determine if it is logical to create their own clouds internally. Using a private cloud, organizations are able to maintain complete control over architectural and cloud components."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:175(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:138(para)
|
||||
msgid "Users will want to combine using the internal cloud with access to an external cloud. If that case is likely, it might be worth exploring the possibility of taking a multi-cloud approach with regard to at least some of the architectural elements."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:183(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:146(para)
|
||||
msgid "Designs that incorporate the use of multiple clouds, such as a private cloud and a public cloud offering, are described in the \"Multi-Cloud\" scenario, see <xref linkend=\"multi_site\"/>."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:193(para)
|
||||
#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:156(para)
|
||||
msgid "Security should be implemented according to asset, threat, and vulnerability risk assessment matrices. For cloud domains that require increased computer security, network security, or information security, a general purpose cloud is not considered an appropriate choice."
|
||||
msgstr ""
|
||||
|
||||
|
||||
@ -9,8 +9,8 @@
|
||||
msgid ""
|
||||
msgstr ""
|
||||
"Project-Id-Version: OpenStack Manuals\n"
|
||||
"POT-Creation-Date: 2015-08-19 01:35+0000\n"
|
||||
"PO-Revision-Date: 2015-08-19 01:37+0000\n"
|
||||
"POT-Creation-Date: 2015-08-21 03:08+0000\n"
|
||||
"PO-Revision-Date: 2015-08-20 05:19+0000\n"
|
||||
"Last-Translator: openstackjenkins <jenkins@openstack.org>\n"
|
||||
"Language-Team: Chinese (China) (http://www.transifex.com/openstack/openstack-"
|
||||
"manuals-i18n/language/zh_CN/)\n"
|
||||
@ -450,20 +450,6 @@ msgstr ""
|
||||
"wiki.openstack.org/wiki/HypervisorSupportMatrix\\\">https://wiki.openstack."
|
||||
"org/wiki/HypervisorSupportMatrix</link>页面找到。"
|
||||
|
||||
msgid ""
|
||||
"A compute design that allocates multiple pools of resources makes best use "
|
||||
"of application resources running in the cloud. Each independent resource "
|
||||
"pool should be designed to provide service for specific flavors of instances "
|
||||
"or groupings of flavors. Designing multiple resource pools helps to ensure "
|
||||
"that, as instances are scheduled onto compute hypervisors, each independent "
|
||||
"node's resources will be allocated to make the most efficient use of "
|
||||
"available hardware. This is commonly referred to as bin packing."
|
||||
msgstr ""
|
||||
"一个计算设计在多个池中分配资源，会使云中运行的应用资源利用的最为充分。每个独"
|
||||
"立的资源池应该被设计为特定的类型的实例或一组实例提供服务，设计多个资源池可帮"
|
||||
"助确保这样，当实例被调度到hypervisor节点，每个独立的节点资源将会被分配到最合"
|
||||
"适的可用的硬件。这就是常见的集装箱模式。"
|
||||
|
||||
msgid "A disk within a single node"
|
||||
msgstr "单个节点上的一块磁盘"
|
||||
|
||||
@ -779,20 +765,6 @@ msgstr ""
|
||||
"后面针对专用场景的描述。某些针对不同资源的向导可以帮助解决性能敏感负载的问"
|
||||
"题。"
|
||||
|
||||
msgid ""
|
||||
"An <firstterm>overcommit ratio</firstterm> is the ratio of available virtual "
|
||||
"resources, compared to the available physical resources. OpenStack is able "
|
||||
"to configure the overcommit ratio for CPU and memory. The default CPU "
|
||||
"overcommit ratio is 16:1 and the default memory overcommit ratio is 1.5:1. "
|
||||
"Determining the tuning of the overcommit ratios for both of these options "
|
||||
"during the design phase is important as it has a direct impact on the "
|
||||
"hardware layout of your compute nodes."
|
||||
msgstr ""
|
||||
"OpenStack支持配置<firstterm>资源超分配比例</firstterm>，即虚拟资源比实际的物"
|
||||
"理资源，目前支持CPU和内存。默认的CPU超分配比例是16：1，默认的内存超分配比例是"
|
||||
"1.5：1。在设计阶段就要想要是否决定调整此超分配比例，因为这会直接影响到用户计"
|
||||
"算节点的硬件布局。"
|
||||
|
||||
msgid ""
|
||||
"An OpenStack general purpose cloud is often considered a starting point for "
|
||||
"building a cloud deployment. They are designed to balance the components and "
|
||||
@ -1024,14 +996,6 @@ msgstr ""
|
||||
msgid "Bare-metal"
|
||||
msgstr "裸金属"
|
||||
|
||||
msgid ""
|
||||
"Based on the requirements of instances being serviced in the cloud, the "
|
||||
"choice of network service will be the next decision that affects your design "
|
||||
"architecture."
|
||||
msgstr ""
|
||||
"基于云中实例提供的服务的需求，网络服务的选择将会是影响用户设计架构的下一个决"
|
||||
"定。"
|
||||
|
||||
msgid ""
|
||||
"Be a pessimist: Assume everything fails and design backwards. Love your "
|
||||
"chaos monkey."
|
||||
@ -1105,9 +1069,6 @@ msgstr ""
|
||||
"块存储资源节点通常都配备有高级的 RAID 控制器以及高性能的磁盘，被设计为能够在"
|
||||
"硬件层面上提供容错。"
|
||||
|
||||
msgid "Block storage"
|
||||
msgstr "块存储"
|
||||
|
||||
msgid ""
|
||||
"Block storage also takes advantage of a number of enterprise storage "
|
||||
"solutions. These are addressed via a plug-in driver developed by the "
|
||||
@ -1439,9 +1400,6 @@ msgstr "内容分发。"
|
||||
msgid "Continuous integration/continuous deployment (CI/CD)"
|
||||
msgstr "持续集成/持续部署(CI/CD)"
|
||||
|
||||
msgid "Controller"
|
||||
msgstr "控制器"
|
||||
|
||||
msgid "Controller infrastructure"
|
||||
msgstr "控制器基础设施"
|
||||
|
||||
@ -1608,9 +1566,6 @@ msgstr ""
|
||||
"设计一个适用于运行虚拟桌面的基础设施是一个与为其它大部分虚拟化任务进行设计大"
|
||||
"不相同的工作。该基础设施设计时必须考虑到各种因素，比如以下例子："
|
||||
|
||||
msgid "Designing compute resources"
|
||||
msgstr "规划计算资源"
|
||||
|
||||
msgid ""
|
||||
"Designing for fault tolerance and availability of storage systems in an "
|
||||
"OpenStack cloud is vastly different when comparing the Block Storage and "
|
||||
@ -1991,27 +1946,6 @@ msgstr ""
|
||||
"超过8块磁盘，它的扩展性受限。因此，一个系统开始时使用单个磁盘，且partition "
|
||||
"power是10的话可以使用1024(2^10)个磁盘。"
|
||||
|
||||
msgid ""
|
||||
"For example, consider a m1.small instance uses 1 vCPU, 20GB of ephemeral "
|
||||
"storage and 2,048MB of RAM. When designing a hardware node as a compute "
|
||||
"resource pool to service instances, take into consideration the number of "
|
||||
"processor cores available on the node as well as the required disk and "
|
||||
"memory to service instances running at capacity. For a server with 2 CPUs of "
|
||||
"10 cores each, with hyperthreading turned on, the default CPU overcommit "
|
||||
"ratio of 16:1 would allow for 640 (2 10 2 16) total m1.small instances. By "
|
||||
"the same reasoning, using the default memory overcommit ratio of 1.5:1 you "
|
||||
"can determine that the server will need at least 853GB (640 2,048MB / 1.5) "
|
||||
"of RAM. When sizing nodes for memory, it is also important to consider the "
|
||||
"additional memory required to service operating system and service needs."
|
||||
msgstr ""
|
||||
"举例说明，想像一下，现在有一个m1.small类型的实例，使用的是1 vCPU,20GB的临时存"
|
||||
"储，2048MB的内存。当设计为此类实例提供计算资源池的硬件节点时，考虑节点需要多"
|
||||
"少个处理器、多大的磁盘、内存大小才可以满足容量需求。对于一个有2颗10个核的"
|
||||
"CPU，并开启超线程的服务器，基于默认的CPU超分配比例16：1来计算的话，它总共能运"
|
||||
"行640(2x10x2x16)个m1.small类型的实例。同样，基于默认的内存超分配比例1.5：1来"
|
||||
"计算的话，用户则需要至少853GB(640x2048/1.5x1048)内存。当基于内存来丈量服务器"
|
||||
"节点时，考虑操作系统本身和其服务所需要使用的内存也是非常重要的。"
|
||||
|
||||
msgid ""
|
||||
"For example, given a cloud with two regions, if the operator grants a user a "
|
||||
"quota of 25 instances in each region then that user may launch a total of 50 "
|
||||
@ -2124,10 +2058,6 @@ msgid ""
|
||||
"can include additional resources such as:"
|
||||
msgstr "通用型云被限制在了大部分的基本组件，但是可以包含下面增加的资源，例如："
|
||||
|
||||
msgid ""
|
||||
"General purpose clouds are often expected to include these base services:"
|
||||
msgstr "通用型云通常实现所包括的基本服务："
|
||||
|
||||
msgid "Geneva, Switzerland"
|
||||
msgstr "瑞士日内瓦"
|
||||
|
||||
@ -2673,19 +2603,6 @@ msgstr ""
|
||||
msgid "Initial release."
|
||||
msgstr "初始版"
|
||||
|
||||
msgid ""
|
||||
"Initially, it is suggested to design at least three network segments, the "
|
||||
"first of which will be used for access to the cloud's REST APIs by tenants "
|
||||
"and operators. This is referred to as a public network. In most cases, the "
|
||||
"controller nodes and swift proxies within the cloud will be the only devices "
|
||||
"necessary to connect to this network segment. In some cases, this network "
|
||||
"might also be serviced by hardware load balancers and other network devices."
|
||||
msgstr ""
|
||||
"首先建议的设计是至少划分三个网段，第一个是给租户和运维人员用于访问云的REST 应"
|
||||
"用程序接口。这也是通常说的公有网络。在多数的用例中，控制节点和swift代理是唯一"
|
||||
"的需要连接到此网段的设备。也有一些用例中，此网段也许服务于硬件的负载均衡或其"
|
||||
"他网络设备。"
|
||||
|
||||
msgid ""
|
||||
"Input-Output performance requirements require researching and modeling "
|
||||
"before deciding on a final storage framework. Running benchmarks for Input-"
|
||||
@ -2757,14 +2674,6 @@ msgid ""
|
||||
"It can be difficult to troubleshoot a network without IP addresses and ICMP."
|
||||
msgstr "解决一个没有 IP 地址和 ICMP 的网络上的问题可能会很困难。"
|
||||
|
||||
msgid ""
|
||||
"It is also important to consider the compute requirements of resource nodes "
|
||||
"within the cloud. Resource nodes refer to non-hypervisor nodes providing the "
|
||||
"following in the cloud:"
|
||||
msgstr ""
|
||||
"考虑到云中计算需求的资源节点也是很重要的，资源节点即非hypervisor节点，在云中"
|
||||
"提供下列服务："
|
||||
|
||||
msgid ""
|
||||
"It is important to know that layer 2 has a very limited set of network "
|
||||
"management tools. It is very difficult to control traffic, as it does not "
|
||||
@ -3339,9 +3248,6 @@ msgstr "网络硬件选择"
|
||||
msgid "Networking resources"
|
||||
msgstr "网络资源"
|
||||
|
||||
msgid "Networking services"
|
||||
msgstr "联网服务"
|
||||
|
||||
msgid "Networking software"
|
||||
msgstr "联网软件"
|
||||
|
||||
@ -3404,9 +3310,6 @@ msgstr "对象存储(Swift)"
|
||||
msgid "Object Storage fault tolerance and availability"
|
||||
msgstr "对象存储容错和可用性"
|
||||
|
||||
msgid "Object storage"
|
||||
msgstr "对象存储"
|
||||
|
||||
msgid ""
|
||||
"Object storage nodes should be designed so that the number of requests does "
|
||||
"not hinder the performance of the cluster. The object storage service is a "
|
||||
@ -3647,26 +3550,6 @@ msgstr ""
|
||||
"OpenStack云需要合适的检测平台来确保错误可以及时捕获，能够更好的管理。一些特别"
|
||||
"的计量值需要重点监测的有："
|
||||
|
||||
msgid ""
|
||||
"OpenStack clouds traditionally have multiple network segments, each of which "
|
||||
"provides access to resources within the cloud to both operators and tenants. "
|
||||
"The network services themselves also require network communication paths "
|
||||
"which should be separated from the other networks. When designing network "
|
||||
"services for a general purpose cloud, we recommend planning for a physical "
|
||||
"or logical separation of network segments that will be used by operators and "
|
||||
"tenants. We further suggest the creation of an additional network segment "
|
||||
"for access to internal services such as the message bus and databse used by "
|
||||
"the various cloud services. Segregating these services onto separate "
|
||||
"networks helps to protect sensitive data and protects against unauthorized "
|
||||
"access to services."
|
||||
msgstr ""
|
||||
"传统的OpenStack云是有多个网段的，每个网段都提供在云中访问不仅是操作人员还可以"
|
||||
"是租户的资源。此外，网络服务本身也需要网络通讯路径以和其他网络隔离。当为通用"
|
||||
"型云设计网络服务时，强烈建议规划不论是物理的还是逻辑的都要将操作人员和租户隔"
|
||||
"离为不同的网段。进一步的建议，划分出另外一个网段，专门用于访问内部资源，诸如"
|
||||
"消息队列、数据库等各种云服务。利用不同网段隔离这些服务对于保护敏感数据以及对"
|
||||
"付没有认证的访问很有帮助。"
|
||||
|
||||
msgid "OpenStack compatibility"
|
||||
msgstr "OpenStack 兼容性"
|
||||
|
||||
@ -3934,20 +3817,6 @@ msgstr "示例"
|
||||
msgid "Private (non-routable) and public (floating) IP addresses"
|
||||
msgstr "私有(不可路由到达)及公有(浮动) IP 地址"
|
||||
|
||||
msgid ""
|
||||
"Processor selection is an extremely important consideration in hardware "
|
||||
"design, especially when comparing the features and performance "
|
||||
"characteristics of different processors. Processors can include features "
|
||||
"specific to virtualized compute hosts including hardware assisted "
|
||||
"virtualization and technology related to memory paging (also known as EPT "
|
||||
"shadowing). These types of features can have a significant impact on the "
|
||||
"performance of your virtual machine running in the cloud."
|
||||
msgstr ""
|
||||
"处理器的选择对于硬件设计来讲实在是太过重要了，尤其是对比不同处理器之间的特性"
|
||||
"和性能。一些近来发布的处理器，拥有针对虚拟化的特性，如硬件增强虚拟化，或者是"
|
||||
"内存分页技术(著名的EPT影子页表)。这些特性对于在云中运行的虚拟机来说，有着非常"
|
||||
"关键的影响。"
|
||||
|
||||
msgid ""
|
||||
"Projecting growth for storage, networking, and compute is only one aspect of "
|
||||
"a growth plan for running OpenStack at massive scale. Growing and nurturing "
|
||||
@ -4816,14 +4685,6 @@ msgstr ""
|
||||
msgid "The bleeding edge"
|
||||
msgstr "最前沿"
|
||||
|
||||
msgid ""
|
||||
"The choice between legacy networking (nova-network), as a part of OpenStack "
|
||||
"Compute, and OpenStack Networking (neutron), has a huge impact on the "
|
||||
"architecture and design of the cloud network infrastructure."
|
||||
msgstr ""
|
||||
"在作为OpenStack计算组件的部分遗留网络(nova-network)和OpenStack网络(neutron)之"
|
||||
"间作出选择，会极大的影响到云网络基础设施的架构和设计。"
|
||||
|
||||
msgid ""
|
||||
"The choice of hardware specifications used in compute nodes including CPU, "
|
||||
"memory and disk type directly affects the performance of the instances. "
|
||||
@ -4998,39 +4859,11 @@ msgstr ""
|
||||
"应用。这里（OpenStack 通用型云，译者注）提供的独立性和灵活性的深度，也就只能"
|
||||
"是这么多了，不能提供更多的云场景。"
|
||||
|
||||
msgid ""
|
||||
"The last network segment is used by applications and consumers to provide "
|
||||
"access to the physical network and also for users accessing applications "
|
||||
"running within the cloud. This network is generally segregated from the one "
|
||||
"used to access the cloud APIs and is not capable of communicating directly "
|
||||
"with the hardware resources in the cloud. Compute resource nodes will need "
|
||||
"to communicate on this network segment, as will any network gateway services "
|
||||
"which allow application data to access the physical network outside of the "
|
||||
"cloud."
|
||||
msgstr ""
|
||||
"第三个网段用于为应用程序和消费者访问物理网络，也为最终用户访问云中运行的应用"
|
||||
"程序提供网络。此网络是隔离能够访问云API的网络，并不能够直接和云中的硬件资源通"
|
||||
"信。计算资源节点需要基于此网段通信，以及任何的网络网关服务将允许应用程序的数"
|
||||
"据可通过物理网络到云的外部。"
|
||||
|
||||
msgid ""
|
||||
"The latency of storage I/O requests indicates performance. Performance "
|
||||
"requirements affect which solution you choose."
|
||||
msgstr "存储I/O请求的延迟影响着性能。解决方案的选择会影响到性能的需求。"
|
||||
|
||||
msgid ""
|
||||
"The legacy networking (nova-network) service is primarily a layer-2 "
|
||||
"networking service that functions in two modes. In legacy networking, the "
|
||||
"two modes differ in their use of VLANs. When using legacy networking in a "
|
||||
"flat network mode, all network hardware nodes and devices throughout the "
|
||||
"cloud are connected to a single layer-2 network segment that provides access "
|
||||
"to application data."
|
||||
msgstr ""
|
||||
"遗留的网络服务(nova-network)主要是一个二层的网络服务，有两种模式的功能实现。"
|
||||
"在遗留网络中，两种模式的区别是它们使用VLAN的方式不同。当使用遗留网络用于浮动"
|
||||
"网络模式时，所有的网络硬件节点和设备通过一个二层的网段来连接，提供应用数据的"
|
||||
"访问。"
|
||||
|
||||
msgid ""
|
||||
"The level of network hardware redundancy required is influenced by the user "
|
||||
"requirements for high availability and cost considerations. Network "
|
||||
@ -5109,21 +4942,6 @@ msgid ""
|
||||
msgstr ""
|
||||
"网络硬件必须支持常见的网络速度，例如：1GbE、10GbE 或者 40GbE(甚至是 100GbE)。"
|
||||
|
||||
msgid ""
|
||||
"The next segment is used by cloud administrators to manage hardware "
|
||||
"resources and is also used by configuration management tools when deploying "
|
||||
"software and services onto new hardware. In some cases, this network segment "
|
||||
"might also be used for internal services, including the message bus and "
|
||||
"database services, to communicate with each other. Due to the highly secure "
|
||||
"nature of this network segment, it may be desirable to secure this network "
|
||||
"from unauthorized access. This network will likely need to communicate with "
|
||||
"every hardware node within the cloud."
|
||||
msgstr ""
|
||||
"第二个网段用于云管理员管理硬件资源，也用于在新的硬件上部署软件和服务的配置管"
|
||||
"理工具。在某些情况下，此网段也许用于内部服务间的通信，包括消息总线和数据库服"
|
||||
"务。介于此网段拥有高度安全的本质，需要将此网络设置为未经授权不得访问。此网段"
|
||||
"在云中的所有硬件节点需要互联互通。"
|
||||
|
||||
msgid ""
|
||||
"The number of CPU cores, how much RAM, or how much storage a given server "
|
||||
"delivers."
|
||||
@ -5161,15 +4979,6 @@ msgstr ""
|
||||
"景下才会出现，所以能够重现和验证该问题的组织是为数不多的，因此将问题良好地文"
|
||||
"档化并且为问题的解决贡献一些必要的资源，是尤为重要的。"
|
||||
|
||||
msgid ""
|
||||
"The number of processor cores and threads has a direct correlation to the "
|
||||
"number of worker threads which can be run on a resource node. As a result, "
|
||||
"you must make design decisions relating directly to the service, as well as "
|
||||
"provide a balanced infrastructure for all services."
|
||||
msgstr ""
|
||||
"处理器核数和线程数和在资源节点可以运行多少任务线程是有直接关联的。结果就是，"
|
||||
"用户必须作出设计决定，直接关联的服务，以及为所有服务提供平衡的基础设施。"
|
||||
|
||||
msgid ""
|
||||
"The operating system (OS) and hypervisor have a significant impact on the "
|
||||
"overall design. Selecting a particular operating system and hypervisor can "
|
||||
@ -5742,18 +5551,6 @@ msgid ""
|
||||
"following requirements:"
|
||||
msgstr "跟上面的例子相关的 Ceph 的一个可能架构需要如下组件："
|
||||
|
||||
msgid ""
|
||||
"Using a consistent hardware design among the nodes that are placed within a "
|
||||
"resource pool also helps support bin packing. Hardware nodes selected for "
|
||||
"being a part of a compute resource pool should share a common processor, "
|
||||
"memory, and storage layout. By choosing a common hardware design, it becomes "
|
||||
"easier to deploy, support and maintain those nodes throughout their life "
|
||||
"cycle in the cloud."
|
||||
msgstr ""
|
||||
"使用一致的硬件来设计资源池中的节点对装箱起到积极作用。选择硬件节点当作计算资"
|
||||
"源池的一部分最好是拥有一样的处理器、内存以及存储类型。选择一致的硬件设计，将"
|
||||
"会在云的整个生命周期展现出更加容易部署、支持和维护的好处。"
|
||||
|
||||
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, "
|
||||
@ -5981,19 +5778,6 @@ msgstr ""
|
||||
"调度相结合，才可能为租户提供基于多种不同性能级别和冗余属性的大型目录存储服"
|
||||
"务。"
|
||||
|
||||
msgid ""
|
||||
"When designing compute resource pools, a number of factors can impact your "
|
||||
"design decisions. For example, decisions related to processors, memory, and "
|
||||
"storage within each hypervisor are just one element of designing compute "
|
||||
"resources. In addition, decide whether to provide compute resources in a "
|
||||
"single pool or in multiple pools. We recommend the compute design allocates "
|
||||
"multiple pools of resources to be addressed on-demand."
|
||||
msgstr ""
|
||||
"当设计计算资源池时，有很多情形会影响到用户的设计决策。例如，和每种hypervisor"
|
||||
"相关的处理器、内存和存储仅仅是设计计算资源时考虑的一个因素。另外，将计算资源"
|
||||
"用户单一的池还是用户多个池也是有必要考虑的，我们建议用户设计将计算资源设计为"
|
||||
"资源池，实现按需使用。"
|
||||
|
||||
msgid ""
|
||||
"When designing hardware resources for OpenStack Object Storage, the primary "
|
||||
"goal is to maximize the amount of storage in each resource node while also "
|
||||
@ -6032,23 +5816,6 @@ msgstr ""
|
||||
"OpenStack 目前并未提供流量整形或者速度限制的机制，有必要在网络硬件的级别上实"
|
||||
"现这些特性。"
|
||||
|
||||
msgid ""
|
||||
"When the network devices in the cloud support segmentation using VLANs, "
|
||||
"legacy networking can operate in the second mode. In this design model, each "
|
||||
"tenant within the cloud is assigned a network subnet which is mapped to a "
|
||||
"VLAN on the physical network. It is especially important to remember the "
|
||||
"maximum number of 4096 VLANs which can be used within a spanning tree "
|
||||
"domain. These limitations place hard limits on the amount of growth possible "
|
||||
"within the data center. When designing a general purpose cloud intended to "
|
||||
"support multiple tenants, we recommend the use of legacy networking with "
|
||||
"VLANs, and not in flat network mode."
|
||||
msgstr ""
|
||||
"当云中的网络设备可通过VLANs支持分段时，遗留网络的第二种模式就可操作了。此模式"
|
||||
"中，云中的每个组户都被分配一个网络子网，其是映射到物理网络的VLAN中的。尤其重"
|
||||
"要的一点，要记得在一个生成树域里VLANs的最大数量是4096.在数据中心此限制成为了"
|
||||
"可能成长的一个硬性限制。当设计一个支持多租户的通用型云时，特别要记住使用和"
|
||||
"VLANs一起使用遗留网络，而且不使用浮动网络模式。"
|
||||
|
||||
msgid ""
|
||||
"When using OpenStack Networking, the OpenStack controller servers or "
|
||||
"separate Networking hosts handle routing. For a deployment that requires "
|
||||
@ -6155,22 +5922,6 @@ msgstr ""
|
||||
msgid "Workload considerations"
|
||||
msgstr "负载考虑"
|
||||
|
||||
msgid ""
|
||||
"Workload profiles are unpredictable in a general purpose cloud. Additional "
|
||||
"compute resource pools can be added to the cloud later, reducing the stress "
|
||||
"of unpredictability. In some cases, the demand on certain instance types or "
|
||||
"flavors may not justify individual hardware design. In either of these "
|
||||
"cases, initiate the design by allocating hardware designs that are capable "
|
||||
"of servicing the most common instances requests. If you are looking to add "
|
||||
"additional hardware designs to the overall architecture, this can be done at "
|
||||
"a later time."
|
||||
msgstr ""
|
||||
"在通用型云中负载是不可预测的，所以能将每个特别的用例都做到胸有成竹是非常困难"
|
||||
"的。在未来给云增加计算资源池，这种不可预测是不会带来任何问题的。在某些情况"
|
||||
"下，在确定了实例类型的需求可能不足以需要单独的硬件设计。综合来看，硬件设计方"
|
||||
"案是先满足大多数通用的实例来启动的，至于以后，寻求增加额外的硬件设计将贯穿整"
|
||||
"个多样的硬件节点设计和资源池的架构。"
|
||||
|
||||
msgid "XCP/XenServer"
|
||||
msgstr "XCP/XenServer"
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
msgid ""
|
||||
msgstr ""
|
||||
"Project-Id-Version: PACKAGE VERSION\n"
|
||||
"POT-Creation-Date: 2015-08-19 06:16+0000\n"
|
||||
"POT-Creation-Date: 2015-08-21 06:19+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"
|
||||
@ -6179,6 +6179,14 @@ msgstr ""
|
||||
msgid "If you try to access the dashboard through HTTP, the browser redirects you to the HTTPS page."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/common/section_dashboard-configure-https.xml:114(para)
|
||||
msgid "Configuring the dashboard for HTTPS also requires enabling SSL for the noVNC proxy service. On the controller node, add the following additional options to the <filename>[DEFAULT]</filename> section of the <filename>/etc/nova/nova.conf</filename> file: <placeholder-1/>"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/common/section_dashboard-configure-https.xml:126(para)
|
||||
msgid "On the compute nodes, ensure the <code>nonvncproxy_base_url</code> option points to a URL with an HTTPS scheme:"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/common/section_dashboard_customizing.xml:7(title)
|
||||
msgid "Customize the dashboard"
|
||||
msgstr ""
|
||||
|
||||
@ -8,9 +8,9 @@
|
||||
msgid ""
|
||||
msgstr ""
|
||||
"Project-Id-Version: OpenStack Manuals\n"
|
||||
"POT-Creation-Date: 2015-08-06 05:15+0000\n"
|
||||
"PO-Revision-Date: 2015-08-05 16:32+0000\n"
|
||||
"Last-Translator: openstackjenkins <jenkins@openstack.org>\n"
|
||||
"POT-Creation-Date: 2015-08-21 03:09+0000\n"
|
||||
"PO-Revision-Date: 2015-08-20 13:49+0000\n"
|
||||
"Last-Translator: Ian Y. Choi <ianyrchoi@gmail.com>\n"
|
||||
"Language-Team: Korean (Korea) (http://www.transifex.com/openstack/openstack-"
|
||||
"manuals-i18n/language/ko_KR/)\n"
|
||||
"MIME-Version: 1.0\n"
|
||||
@ -51,6 +51,9 @@ msgstr ""
|
||||
"오브젝트 스토리지 계정 및 관련 메타데이터를 포함하고 계정 서버가 접근하는 "
|
||||
"SQLite 데이터베이스입니다."
|
||||
|
||||
msgid "A collection of hypervisors grouped together through host aggregates."
|
||||
msgstr "호스트 집합을 통하여 그룹화된 하이퍼바이저 집합"
|
||||
|
||||
msgid ""
|
||||
"A collection of specifications used to access a service, application, or "
|
||||
"program. Includes service calls, required parameters for each call, and the "
|
||||
@ -245,7 +248,7 @@ msgstr ""
|
||||
"와 혼동하지 마십시오."
|
||||
|
||||
msgid "An Object Storage node that provides authorization services."
|
||||
msgstr "인증 서비스를 제공하는 오브젝트 스토리지 노드"
|
||||
msgstr "허가 서비스를 제공하는 오브젝트 스토리지 노드"
|
||||
|
||||
msgid ""
|
||||
"An Object Storage worker that scans for and deletes account databases and "
|
||||
@ -286,6 +289,9 @@ msgstr "응용 프로그램 프로그래밍 인터페이스 (API)"
|
||||
msgid "Application Service Provider (ASP)"
|
||||
msgstr "어플리케이션 서비스 프로바이더 (ASP)"
|
||||
|
||||
msgid "Application catalog"
|
||||
msgstr "응용 프로그램 카탈로그"
|
||||
|
||||
msgid "Application programming interface."
|
||||
msgstr "응용프로그램 프로그래밍 인터페이스"
|
||||
|
||||
@ -717,6 +723,16 @@ msgstr "오픈스택 용어집"
|
||||
msgid "OpenStack project that provides a message service to applications."
|
||||
msgstr "메시지 서비스를 응용프로그램에 제공하는 OpenStack 프로젝트입니다."
|
||||
|
||||
msgid ""
|
||||
"OpenStack project that provides an application catalog service so that users "
|
||||
"can compose and deploy composite environments on an application abstraction "
|
||||
"level while managing the application lifecycle. The code name of the project "
|
||||
"is murano."
|
||||
msgstr ""
|
||||
"응용 프로그램 카탈로그 서비스를 제공하여 사용자가 응용 프로그램 수명주기를 관"
|
||||
"리하는 동안 응용 프로그램 추상화 레벨에서 복합 환경을 작성하고 배포 가능하도"
|
||||
"록 제공하는 OpenStack 프로젝트입니다. 프로젝트 코드 이름은 murano입니다."
|
||||
|
||||
msgid "Orchestration"
|
||||
msgstr "Orchestration"
|
||||
|
||||
@ -835,6 +851,12 @@ msgstr ""
|
||||
"Compute 서비스가 이벤트 통지 및 시스템 사용량 데이터 기능을 통해 계정 정보를 "
|
||||
"제공합니다."
|
||||
|
||||
msgid "The Identity component that provides high-level authorization services."
|
||||
msgstr "높은 수준의 인증 서비스를 제공하는 Identity 구성요소."
|
||||
|
||||
msgid "The Identity service component that provides authentication services."
|
||||
msgstr "인증 서비스를 제공하는 Identity 서비스 컴포넌트입니다."
|
||||
|
||||
msgid ""
|
||||
"The Object Storage context of an account. Do not confuse with a user account "
|
||||
"from an authentication service, such as Active Directory, /etc/passwd, "
|
||||
@ -850,7 +872,9 @@ msgstr "Compute에 의해서 지원되는 Xen 관리 API."
|
||||
msgid ""
|
||||
"The act of verifying that a user, process, or client is authorized to "
|
||||
"perform an action."
|
||||
msgstr "사용자, 프로세스, 클라이언트의 인증에 대한 검증과 "
|
||||
msgstr ""
|
||||
"사용자, 프로세스, 클라이언트가 어떤 행동을 수행하는 데 있어 g허가되었는지를 "
|
||||
"검증하는 것"
|
||||
|
||||
msgid ""
|
||||
"The code name for the initial release of OpenStack. The first design summit "
|
||||
@ -859,6 +883,16 @@ msgstr ""
|
||||
"OpenStack의 초기 릴리즈 코드 이름. 첫 디자인 서밋을 한 곳인 미국 텍사스 "
|
||||
"Austin을 나타냅니다."
|
||||
|
||||
msgid ""
|
||||
"The daemon, worker, or service that a client communicates with to access an "
|
||||
"API. API endpoints can provide any number of services, such as "
|
||||
"authentication, sales data, performance meters, Compute VM commands, census "
|
||||
"data, and so on."
|
||||
msgstr ""
|
||||
"클라이언트가 API에 접근하기 위해 통신을 수행하는 데몬, 워커 또는 서비스. API "
|
||||
"엔드 포인트는 인증, 데이터 세일즈, 성능 측정, Compute VM 명령어, 인구 조사 데"
|
||||
"이터 등과 같은 임의의 서비스에 제공합니다."
|
||||
|
||||
msgid "The most common web server software currently used on the Internet."
|
||||
msgstr "현재 인터넷에서 사용되고 있는 가장 일반적인 웹 서버 소프트웨어"
|
||||
|
||||
@ -1163,10 +1197,10 @@ msgid "authentication tokens"
|
||||
msgstr "인증 토큰들"
|
||||
|
||||
msgid "authorization"
|
||||
msgstr "인증"
|
||||
msgstr "허가"
|
||||
|
||||
msgid "authorization node"
|
||||
msgstr "인증 노드"
|
||||
msgstr "허가 노드"
|
||||
|
||||
msgid "auto declare"
|
||||
msgstr "자동 선언"
|
||||
@ -1357,6 +1391,9 @@ msgstr "horizon"
|
||||
msgid "host"
|
||||
msgstr "호스트"
|
||||
|
||||
msgid "host aggregate"
|
||||
msgstr "호스트 집합"
|
||||
|
||||
msgid "http://www.apache.org/licenses/LICENSE-2.0"
|
||||
msgstr "http://www.apache.org/licenses/LICENSE-2.0"
|
||||
|
||||
@ -1390,6 +1427,9 @@ msgstr "Keystone"
|
||||
msgid "live migration"
|
||||
msgstr "실시간 마이그레이션"
|
||||
|
||||
msgid "murano"
|
||||
msgstr "murano"
|
||||
|
||||
msgid "network"
|
||||
msgstr "네트워크"
|
||||
|
||||
|
||||
@ -8,7 +8,7 @@ msgid ""
|
||||
msgstr ""
|
||||
"Project-Id-Version: Installation Guide 0.1\n"
|
||||
"Report-Msgid-Bugs-To: \n"
|
||||
"POT-Creation-Date: 2015-08-19 06:16+0000\n"
|
||||
"POT-Creation-Date: 2015-08-21 06:20+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"
|
||||
@ -19,14 +19,12 @@ msgstr ""
|
||||
# #-#-#-#-# ceilometer-nova.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# cinder-storage-node.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# glance-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# heat-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# neutron-network-node.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# nova-compute-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# nova-controller-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
#: ../ceilometer-nova.rst:110 ../cinder-controller-node.rst:282
|
||||
#: ../cinder-storage-node.rst:340 ../glance-install.rst:236
|
||||
#: ../glance-install.rst:304 ../heat-install.rst:324
|
||||
#: ../cinder-storage-node.rst:340 ../heat-install.rst:324
|
||||
#: ../neutron-network-node.rst:259 ../neutron-network-node.rst:284
|
||||
#: ../neutron-network-node.rst:389 ../nova-compute-install.rst:194
|
||||
#: ../nova-controller-install.rst:280
|
||||
@ -375,10 +373,6 @@ msgstr ""
|
||||
msgid "Add the ``admin`` role to the ``cinder`` user:"
|
||||
msgstr ""
|
||||
|
||||
#: ../glance-install.rst:77
|
||||
msgid "Add the ``admin`` role to the ``glance`` user and ``service`` project:"
|
||||
msgstr ""
|
||||
|
||||
#: ../heat-install.rst:64
|
||||
msgid "Add the ``admin`` role to the ``heat`` user:"
|
||||
msgstr ""
|
||||
@ -484,7 +478,7 @@ msgid ""
|
||||
"this guide only show Internet access for OpenStack services."
|
||||
msgstr ""
|
||||
|
||||
#: ../dashboard-install.rst:85
|
||||
#: ../dashboard-install.rst:99
|
||||
msgid "Allow all hosts to access the dashboard::"
|
||||
msgstr ""
|
||||
|
||||
@ -735,12 +729,6 @@ msgid ""
|
||||
"database, service credentials, and API endpoint."
|
||||
msgstr ""
|
||||
|
||||
#: ../glance-install.rst:20
|
||||
msgid ""
|
||||
"Before you install and configure the Image service, you must create a "
|
||||
"database, service credentials, and API endpoint."
|
||||
msgstr ""
|
||||
|
||||
#: ../glance.rst:26
|
||||
msgid ""
|
||||
"Before you proceed, ensure that the controller node has at least several "
|
||||
@ -821,7 +809,7 @@ msgid ""
|
||||
"because the ``identity_uri`` option replaces them."
|
||||
msgstr ""
|
||||
|
||||
#: ../dashboard-install.rst:100
|
||||
#: ../dashboard-install.rst:114
|
||||
msgid "Comment out any other session storage configuration."
|
||||
msgstr ""
|
||||
|
||||
@ -833,11 +821,9 @@ msgstr ""
|
||||
|
||||
# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# cinder-storage-node.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# glance-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# nova-compute-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# nova-controller-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
#: ../cinder-controller-node.rst:262 ../cinder-storage-node.rst:264
|
||||
#: ../glance-install.rst:208 ../glance-install.rst:287
|
||||
#: ../nova-compute-install.rst:114 ../nova-controller-install.rst:218
|
||||
msgid ""
|
||||
"Comment out or remove any other options in the ``[keystone_authtoken]`` "
|
||||
@ -866,7 +852,7 @@ msgstr ""
|
||||
msgid "Configure OpenStack with debconf"
|
||||
msgstr ""
|
||||
|
||||
#: ../dashboard-install.rst:110
|
||||
#: ../dashboard-install.rst:124
|
||||
msgid ""
|
||||
"Configure ``user`` as the default role for users that you create via the "
|
||||
"dashboard::"
|
||||
@ -904,7 +890,7 @@ msgstr ""
|
||||
msgid "Configure the Object Storage service"
|
||||
msgstr ""
|
||||
|
||||
#: ../dashboard-install.rst:89
|
||||
#: ../dashboard-install.rst:103
|
||||
msgid "Configure the ``memcached`` session storage service::"
|
||||
msgstr ""
|
||||
|
||||
@ -912,7 +898,7 @@ msgstr ""
|
||||
msgid "Configure the authentication token:"
|
||||
msgstr ""
|
||||
|
||||
#: ../dashboard-install.rst:80
|
||||
#: ../dashboard-install.rst:94
|
||||
msgid ""
|
||||
"Configure the dashboard to use OpenStack services on the ``controller`` "
|
||||
"node::"
|
||||
@ -1103,10 +1089,6 @@ msgstr ""
|
||||
msgid "Create the Identity service API endpoint:"
|
||||
msgstr ""
|
||||
|
||||
#: ../glance-install.rst:106
|
||||
msgid "Create the Image service API endpoint:"
|
||||
msgstr ""
|
||||
|
||||
#: ../cinder-storage-node.rst:111
|
||||
msgid "Create the LVM physical volume :file:`/dev/sdb1`:"
|
||||
msgstr ""
|
||||
@ -1171,18 +1153,6 @@ msgstr ""
|
||||
msgid "Create the ``demo`` user:"
|
||||
msgstr ""
|
||||
|
||||
#: ../glance-install.rst:32
|
||||
msgid "Create the ``glance`` database:"
|
||||
msgstr ""
|
||||
|
||||
#: ../glance-install.rst:90
|
||||
msgid "Create the ``glance`` service entity:"
|
||||
msgstr ""
|
||||
|
||||
#: ../glance-install.rst:60
|
||||
msgid "Create the ``glance`` user:"
|
||||
msgstr ""
|
||||
|
||||
#: ../heat-install.rst:76
|
||||
msgid "Create the ``heat_stack_owner`` role:"
|
||||
msgstr ""
|
||||
@ -1343,15 +1313,14 @@ msgstr ""
|
||||
msgid "Database password of Identity service"
|
||||
msgstr ""
|
||||
|
||||
# #-#-#-#-# glance-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# nova-compute-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# nova-controller-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# swift-controller-node.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# swift-finalize-installation.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# swift-storage-node.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
#: ../glance-install.rst:134 ../nova-compute-install.rst:36
|
||||
#: ../nova-controller-install.rst:123 ../swift-controller-node.rst:110
|
||||
#: ../swift-finalize-installation.rst:9 ../swift-storage-node.rst:183
|
||||
#: ../nova-compute-install.rst:36 ../nova-controller-install.rst:123
|
||||
#: ../swift-controller-node.rst:110 ../swift-finalize-installation.rst:9
|
||||
#: ../swift-storage-node.rst:183
|
||||
msgid ""
|
||||
"Default configuration files vary by distribution. You might need to add "
|
||||
"these sections and options rather than modifying existing sections and "
|
||||
@ -1485,18 +1454,6 @@ msgid ""
|
||||
"registry.conf` files and complete the following actions:"
|
||||
msgstr ""
|
||||
|
||||
#: ../glance-install.rst:167
|
||||
msgid ""
|
||||
"Edit the :file:`/etc/glance/glance-api.conf` file and complete the following "
|
||||
"actions:"
|
||||
msgstr ""
|
||||
|
||||
#: ../glance-install.rst:246
|
||||
msgid ""
|
||||
"Edit the :file:`/etc/glance/glance-registry.conf` file and complete the "
|
||||
"following actions:"
|
||||
msgstr ""
|
||||
|
||||
#: ../heat-install.rst:237
|
||||
msgid ""
|
||||
"Edit the :file:`/etc/heat/heat.conf` file and complete the following actions:"
|
||||
@ -1582,14 +1539,13 @@ msgid "Example using ``192.168.1.0/24``:"
|
||||
msgstr ""
|
||||
|
||||
# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# glance-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# heat-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# keystone-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# neutron-controller-node.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# nova-controller-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
#: ../cinder-controller-node.rst:42 ../glance-install.rst:49
|
||||
#: ../heat-install.rst:36 ../keystone-install.rst:43
|
||||
#: ../neutron-controller-node.rst:35 ../nova-controller-install.rst:39
|
||||
#: ../cinder-controller-node.rst:42 ../heat-install.rst:36
|
||||
#: ../keystone-install.rst:43 ../neutron-controller-node.rst:35
|
||||
#: ../nova-controller-install.rst:39
|
||||
msgid "Exit the database access client."
|
||||
msgstr ""
|
||||
|
||||
@ -1884,10 +1840,6 @@ msgstr ""
|
||||
msgid "Grant proper access to the ``cinder`` database:"
|
||||
msgstr ""
|
||||
|
||||
#: ../glance-install.rst:38
|
||||
msgid "Grant proper access to the ``glance`` database:"
|
||||
msgstr ""
|
||||
|
||||
#: ../heat-install.rst:27
|
||||
msgid "Grant proper access to the ``heat`` database::"
|
||||
msgstr ""
|
||||
@ -2183,13 +2135,6 @@ msgstr ""
|
||||
msgid "In the ``[DEFAULT]`` section, configure the ``my_ip`` option:"
|
||||
msgstr ""
|
||||
|
||||
#: ../glance-install.rst:222 ../glance-install.rst:290
|
||||
msgid ""
|
||||
"In the ``[DEFAULT]`` section, configure the ``noop`` notification driver to "
|
||||
"disable notifications because they only pertain to the optional Telemetry "
|
||||
"service:"
|
||||
msgstr ""
|
||||
|
||||
#: ../cinder-storage-node.rst:323
|
||||
msgid ""
|
||||
"In the ``[DEFAULT]`` section, configure the location of the Image service:"
|
||||
@ -2227,11 +2172,9 @@ msgstr ""
|
||||
# #-#-#-#-# ceilometer-controller-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# cinder-storage-node.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# glance-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# heat-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
#: ../ceilometer-controller-install.rst:352 ../cinder-controller-node.rst:208
|
||||
#: ../cinder-storage-node.rst:210 ../glance-install.rst:170
|
||||
#: ../glance-install.rst:249 ../heat-install.rst:240
|
||||
#: ../cinder-storage-node.rst:210 ../heat-install.rst:240
|
||||
msgid "In the ``[database]`` section, configure database access:"
|
||||
msgstr ""
|
||||
|
||||
@ -2251,24 +2194,12 @@ msgid ""
|
||||
"In the ``[glance]`` section, configure the location of the Image service:"
|
||||
msgstr ""
|
||||
|
||||
#: ../glance-install.rst:211
|
||||
msgid ""
|
||||
"In the ``[glance_store]`` section, configure the local file system store and "
|
||||
"location of image files:"
|
||||
msgstr ""
|
||||
|
||||
#: ../heat-install.rst:271
|
||||
msgid ""
|
||||
"In the ``[keystone_authtoken]`` and ``[ec2authtoken]`` sections, configure "
|
||||
"Identity service access:"
|
||||
msgstr ""
|
||||
|
||||
#: ../glance-install.rst:182 ../glance-install.rst:261
|
||||
msgid ""
|
||||
"In the ``[keystone_authtoken]`` and ``[paste_deploy]`` sections, configure "
|
||||
"Identity service access:"
|
||||
msgstr ""
|
||||
|
||||
#: ../ceilometer-nova.rst:69
|
||||
msgid ""
|
||||
"In the ``[keystone_authtoken]`` section, configure Identity service access:"
|
||||
@ -3032,7 +2963,7 @@ msgid ""
|
||||
"all endpoint variations and the default ``RegionOne`` region."
|
||||
msgstr ""
|
||||
|
||||
#: ../dashboard-install.rst:115
|
||||
#: ../dashboard-install.rst:129
|
||||
msgid "Optionally, configure the time zone::"
|
||||
msgstr ""
|
||||
|
||||
@ -3395,22 +3326,6 @@ msgid ""
|
||||
"addresses."
|
||||
msgstr ""
|
||||
|
||||
#: ../glance-install.rst:47
|
||||
msgid "Replace ``GLANCE_DBPASS`` with a suitable password."
|
||||
msgstr ""
|
||||
|
||||
#: ../glance-install.rst:179 ../glance-install.rst:258
|
||||
msgid ""
|
||||
"Replace ``GLANCE_DBPASS`` with the password you chose for the Image service "
|
||||
"database."
|
||||
msgstr ""
|
||||
|
||||
#: ../glance-install.rst:203 ../glance-install.rst:282
|
||||
msgid ""
|
||||
"Replace ``GLANCE_PASS`` with the password you chose for the ``glance`` user "
|
||||
"in the Identity service."
|
||||
msgstr ""
|
||||
|
||||
#: ../heat-install.rst:34
|
||||
msgid "Replace ``HEAT_DBPASS`` with a suitable password."
|
||||
msgstr ""
|
||||
@ -3592,7 +3507,7 @@ msgid ""
|
||||
"with it, typically the \".1\" IP address."
|
||||
msgstr ""
|
||||
|
||||
#: ../dashboard-install.rst:119
|
||||
#: ../dashboard-install.rst:133
|
||||
msgid ""
|
||||
"Replace ``TIME_ZONE`` with an appropriate time zone identifier. For more "
|
||||
"information, see the `list of time zones <http://en.wikipedia.org/wiki/"
|
||||
@ -3740,7 +3655,6 @@ msgstr ""
|
||||
# #-#-#-#-# ceilometer-verify.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# cinder-verify.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# glance-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# glance-verify.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# heat-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# neutron-compute-node.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
@ -3751,11 +3665,11 @@ msgstr ""
|
||||
# #-#-#-#-# swift-controller-node.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
#: ../ceilometer-controller-install.rst:228 ../ceilometer-verify.rst:11
|
||||
#: ../cinder-controller-node.rst:44 ../cinder-verify.rst:23
|
||||
#: ../glance-install.rst:51 ../glance-verify.rst:24 ../heat-install.rst:38
|
||||
#: ../heat-install.rst:336 ../neutron-compute-node.rst:371
|
||||
#: ../neutron-controller-node.rst:37 ../neutron-controller-node.rst:473
|
||||
#: ../neutron-network-node.rst:560 ../nova-controller-install.rst:41
|
||||
#: ../nova-verify.rst:11 ../swift-controller-node.rst:29
|
||||
#: ../glance-verify.rst:24 ../heat-install.rst:38 ../heat-install.rst:336
|
||||
#: ../neutron-compute-node.rst:371 ../neutron-controller-node.rst:37
|
||||
#: ../neutron-controller-node.rst:473 ../neutron-network-node.rst:560
|
||||
#: ../nova-controller-install.rst:41 ../nova-verify.rst:11
|
||||
#: ../swift-controller-node.rst:29
|
||||
msgid ""
|
||||
"Source the ``admin`` credentials to gain access to admin-only CLI commands:"
|
||||
msgstr ""
|
||||
@ -4102,12 +4016,6 @@ msgid ""
|
||||
"to users with the ``heat_stack_owner`` role."
|
||||
msgstr ""
|
||||
|
||||
#: ../glance-install.rst:233 ../glance-install.rst:301
|
||||
msgid ""
|
||||
"The Telemetry chapter provides an Image service configuration that enables "
|
||||
"notifications."
|
||||
msgstr ""
|
||||
|
||||
#: ../ceilometer-swift.rst:11
|
||||
msgid ""
|
||||
"The Telemetry service requires access to the Object Storage service using "
|
||||
@ -4770,20 +4678,19 @@ msgstr ""
|
||||
# #-#-#-#-# ceilometer-swift.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# cinder-storage-node.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# glance-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# heat-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# nova-controller-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# swift-controller-node.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# swift-storage-node.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
#: ../ceilometer-cinder.rst:10 ../ceilometer-controller-install.rst:11
|
||||
#: ../ceilometer-swift.rst:9 ../cinder-controller-node.rst:11
|
||||
#: ../cinder-storage-node.rst:17 ../glance-install.rst:18
|
||||
#: ../heat-install.rst:9 ../nova-controller-install.rst:8
|
||||
#: ../swift-controller-node.rst:15 ../swift-storage-node.rst:18
|
||||
#: ../cinder-storage-node.rst:17 ../heat-install.rst:9
|
||||
#: ../nova-controller-install.rst:8 ../swift-controller-node.rst:15
|
||||
#: ../swift-storage-node.rst:18
|
||||
msgid "To configure prerequisites"
|
||||
msgstr ""
|
||||
|
||||
#: ../dashboard-install.rst:53
|
||||
#: ../dashboard-install.rst:67
|
||||
msgid "To configure the dashboard"
|
||||
msgstr ""
|
||||
|
||||
@ -4796,14 +4703,13 @@ msgid "To create the Identity service credentials, complete these steps:"
|
||||
msgstr ""
|
||||
|
||||
# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# glance-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# heat-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# keystone-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# neutron-controller-node.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# nova-controller-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
#: ../cinder-controller-node.rst:16 ../glance-install.rst:23
|
||||
#: ../heat-install.rst:14 ../keystone-install.rst:17
|
||||
#: ../neutron-controller-node.rst:10 ../nova-controller-install.rst:13
|
||||
#: ../cinder-controller-node.rst:16 ../heat-install.rst:14
|
||||
#: ../keystone-install.rst:17 ../neutron-controller-node.rst:10
|
||||
#: ../nova-controller-install.rst:13
|
||||
msgid "To create the database, complete these steps:"
|
||||
msgstr ""
|
||||
|
||||
@ -4818,13 +4724,12 @@ msgstr ""
|
||||
|
||||
# #-#-#-#-# ceilometer-controller-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# glance-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# heat-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# neutron-controller-node.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# nova-controller-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
#: ../ceilometer-controller-install.rst:235 ../cinder-controller-node.rst:51
|
||||
#: ../glance-install.rst:58 ../heat-install.rst:45
|
||||
#: ../neutron-controller-node.rst:44 ../nova-controller-install.rst:48
|
||||
#: ../heat-install.rst:45 ../neutron-controller-node.rst:44
|
||||
#: ../nova-controller-install.rst:48
|
||||
msgid "To create the service credentials, complete these steps:"
|
||||
msgstr ""
|
||||
|
||||
@ -4847,7 +4752,7 @@ msgstr ""
|
||||
# #-#-#-#-# nova-controller-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
#: ../ceilometer-controller-install.rst:474 ../ceilometer-nova.rst:139
|
||||
#: ../cinder-controller-node.rst:298 ../cinder-storage-node.rst:350
|
||||
#: ../dashboard-install.rst:124 ../glance-install.rst:323
|
||||
#: ../dashboard-install.rst:138 ../glance-install.rst:349
|
||||
#: ../heat-install.rst:361 ../nova-compute-install.rst:218
|
||||
#: ../nova-controller-install.rst:306
|
||||
msgid "To finalize installation"
|
||||
@ -4871,7 +4776,7 @@ msgstr ""
|
||||
msgid "To install and configure the Compute hypervisor components"
|
||||
msgstr ""
|
||||
|
||||
#: ../glance-install.rst:130
|
||||
#: ../glance-install.rst:132
|
||||
msgid "To install and configure the Image service components"
|
||||
msgstr ""
|
||||
|
||||
@ -5033,14 +4938,13 @@ msgid ""
|
||||
msgstr ""
|
||||
|
||||
# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# glance-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# heat-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# keystone-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# neutron-controller-node.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
# #-#-#-#-# nova-controller-install.pot (Installation Guide 0.1) #-#-#-#-#
|
||||
#: ../cinder-controller-node.rst:18 ../glance-install.rst:25
|
||||
#: ../heat-install.rst:16 ../keystone-install.rst:19
|
||||
#: ../neutron-controller-node.rst:12 ../nova-controller-install.rst:15
|
||||
#: ../cinder-controller-node.rst:18 ../heat-install.rst:16
|
||||
#: ../keystone-install.rst:19 ../neutron-controller-node.rst:12
|
||||
#: ../nova-controller-install.rst:15
|
||||
msgid ""
|
||||
"Use the database access client to connect to the database server as the "
|
||||
"``root`` user:"
|
||||
|
||||
Loading…
Reference in New Issue
Block a user