diff --git a/doc/admin-guide-cloud/locale/admin-guide-cloud.pot b/doc/admin-guide-cloud/locale/admin-guide-cloud.pot index fbe625385e..fb25c64d16 100644 --- a/doc/admin-guide-cloud/locale/admin-guide-cloud.pot +++ b/doc/admin-guide-cloud/locale/admin-guide-cloud.pot @@ -1,7 +1,7 @@ msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" -"POT-Creation-Date: 2014-07-25 06:08+0000\n" +"POT-Creation-Date: 2014-07-28 06:07+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" "Language-Team: LANGUAGE <LL@li.org>\n" @@ -5721,7 +5721,7 @@ msgid "Establish the relationship among the tenant, user, and role:" msgstr "" #: ./doc/admin-guide-cloud/networking/section_networking-config-identity.xml:99(para) -msgid "For information about how to create service entries and users, see the <citetitle>OpenStack Installation Guide</citetitle> for your distribution (<link href=\"docs.openstack.org\">docs.openstack.org</link>)." +msgid "For information about how to create service entries and users, see the <citetitle>OpenStack Installation Guide</citetitle> for your distribution (<link href=\"http://docs.openstack.org\">docs.openstack.org</link>)." msgstr "" #: ./doc/admin-guide-cloud/networking/section_networking-config-identity.xml:104(para) @@ -8481,7 +8481,7 @@ msgid "Installing the <package>python-novaclient</package> package gives you a < msgstr "" #: ./doc/admin-guide-cloud/compute/section_compute-system-admin.xml:173(para) -msgid "To install <package>python-novaclient</package>, download the tarball from <link href=\"http://pypi.python.org/pypi/python-novaclient/2.6.3#downloads\">http://pypi.python.org/pypi/python-novaclient/2.6.3#downloads</link> and then install it in your favorite python environment." +msgid "To install <package>python-novaclient</package>, download the tarball from <link href=\"http://pypi.python.org/pypi/python-novaclient/#downloads\">http://pypi.python.org/pypi/python-novaclient/#downloads</link> and then install it in your favorite python environment." msgstr "" #: ./doc/admin-guide-cloud/compute/section_compute-system-admin.xml:181(para) diff --git a/doc/arch-design/locale/arch-design.pot b/doc/arch-design/locale/arch-design.pot index aa85a48f16..74542ad4c2 100644 --- a/doc/arch-design/locale/arch-design.pot +++ b/doc/arch-design/locale/arch-design.pot @@ -1,7 +1,7 @@ msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" -"POT-Creation-Date: 2014-07-27 06:09+0000\n" +"POT-Creation-Date: 2014-07-28 06:07+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" "Language-Team: LANGUAGE <LL@li.org>\n" @@ -434,86 +434,86 @@ msgid "References" msgstr "" #: ./doc/arch-design/ch_references.xml:9(para) -msgid "Data Protection framework of the European Union: http://ec.europa.eu/justice/data-protection/Guidance on Data Protection laws governed by the EU" +msgid "<link href=\"http://ec.europa.eu/justice/data-protection/\">Data Protection framework of the European Union</link>: Guidance on Data Protection laws governed by the EU." msgstr "" -#: ./doc/arch-design/ch_references.xml:12(para) -msgid "Depletion of IPv4 Addresses: http://www.internetsociety.org/deploy360/blog/2014/05/goodbye-ipv4-iana-starts-allocating-final-address-blocks/Article describing how IPv4 addresses and the migration to IPv6 is inevitable" +#: ./doc/arch-design/ch_references.xml:15(para) +msgid "<link href=\"http://www.internetsociety.org/deploy360/blog/2014/05/goodbye-ipv4-iana-starts-allocating-final-address-blocks/Article\">Depletion of IPv4 Addresses</link>: describing how IPv4 addresses and the migration to IPv6 is inevitable." msgstr "" -#: ./doc/arch-design/ch_references.xml:16(para) -msgid "Ethernet Switch Reliability: http://www.garrettcom.com/techsupport/papers/ethernet_switch_reliability.pdf Research white paper on Ethernet Switch reliability" +#: ./doc/arch-design/ch_references.xml:21(para) +msgid "<link href=\"http://www.garrettcom.com/techsupport/papers/ethernet_switch_reliability.pdf\">Ethernet Switch Reliability</link>: Research white paper on Ethernet Switch reliability." msgstr "" -#: ./doc/arch-design/ch_references.xml:19(para) -msgid "Financial Industry Regulatory Authority: http://www.finra.org/Industry/Regulation/FINRARules/ Requirements of the Financial Industry Regulatory Authority in the USA" +#: ./doc/arch-design/ch_references.xml:27(para) +msgid "<link href=\"http://www.finra.org/Industry/Regulation/FINRARules/\">Financial Industry Regulatory Authority</link>: Requirements of the Financial Industry Regulatory Authority in the USA." msgstr "" -#: ./doc/arch-design/ch_references.xml:22(para) -msgid "Image Service property keys: http://docs.openstack.org/cli-reference/content/chapter_cli-glance-property.html Glance API property keys allows the administrator to attach custom characteristics to images" +#: ./doc/arch-design/ch_references.xml:33(para) +msgid "<link href=\"http://docs.openstack.org/cli-reference/content/chapter_cli-glance-property.html\">Image Service property keys</link>: Glance API property keys allows the administrator to attach custom characteristics to images." msgstr "" -#: ./doc/arch-design/ch_references.xml:26(para) -msgid "LibGuestFS Documentation: http://libguestfs.orgOfficial LibGuestFS documentation" +#: ./doc/arch-design/ch_references.xml:39(para) +msgid "<link href=\"http://libguestfs.org\">LibGuestFS Documentation</link>: Official LibGuestFS documentation." msgstr "" -#: ./doc/arch-design/ch_references.xml:28(para) -msgid "Logging and Monitoring http://docs.openstack.org/openstack-ops/content/logging_monitoring.html Official OpenStack Operations documentation" +#: ./doc/arch-design/ch_references.xml:43(para) +msgid "<link href=\"http://docs.openstack.org/openstack-ops/content/logging_monitoring.html\">Logging and Monitoring</link>: Official OpenStack Operations documentation." msgstr "" -#: ./doc/arch-design/ch_references.xml:31(para) -msgid "ManageIQ Cloud Management Platform: http://manageiq.org/ An Open Source Cloud Management Platform for managing multiple clouds" -msgstr "" - -#: ./doc/arch-design/ch_references.xml:34(para) -msgid "N-Tron Network Availability: http://www.n-tron.com/pdf/network_availability.pdfResearch white paper on network availability" -msgstr "" - -#: ./doc/arch-design/ch_references.xml:37(para) -msgid "Nested KVM: http://davejingtian.org/2014/03/30/nested-kvm-just-for-funBlog Post on how to nest KVM under KVM." -msgstr "" - -#: ./doc/arch-design/ch_references.xml:40(para) -msgid "Open Compute Project: http://www.opencompute.org/The Open Compute Project Foundation’s mission is to design and enable the delivery of the most efficient server, storage and data center hardware designs for scalable computing." -msgstr "" - -#: ./doc/arch-design/ch_references.xml:44(para) -msgid "OpenStack Flavors: http://docs.openstack.org/openstack-ops/content/flavors.htmlOfficial OpenStack documentation" -msgstr "" - -#: ./doc/arch-design/ch_references.xml:47(para) -msgid "OpenStack High Availability Guide: http://docs.openstack.org/high-availability-guide/content/Information on how to provide redundancy for the OpenStack components" -msgstr "" - -#: ./doc/arch-design/ch_references.xml:50(para) -msgid "OpenStack Hypervisor Support Matrix:https://wiki.openstack.org/wiki/HypervisorSupportMatrix Matrix of supported hypervisors and capabilities when used with OpenStack" +#: ./doc/arch-design/ch_references.xml:49(para) +msgid "<link href=\"http://manageiq.org/\">ManageIQ Cloud Management Platform</link>: An Open Source Cloud Management Platform for managing multiple clouds." msgstr "" #: ./doc/arch-design/ch_references.xml:54(para) -msgid "OpenStack Object Store (Swift) Replication Reference: http://docs.openstack.org/developer/swift/replication_network.html Developer documentation of Swift replication" +msgid "<link href=\"http://www.n-tron.com/pdf/network_availability.pdf\">N-Tron Network Availability</link>: Research white paper on network availability." msgstr "" -#: ./doc/arch-design/ch_references.xml:57(para) -msgid "OpenStack Operations Guide: http://docs.openstack.org/openstack-ops/The OpenStack Operations Guide provides information on setting up and installing OpenStack" -msgstr "" - -#: ./doc/arch-design/ch_references.xml:61(para) -msgid "OpenStack Security Guide:http://docs.openstack.org/security-guide/The OpenStack Security Guide provides information on securing OpenStack deployments" +#: ./doc/arch-design/ch_references.xml:60(para) +msgid "<link href=\"http://davejingtian.org/2014/03/30/nested-kvm-just-for-funBlog\">Nested KVM</link>: Post on how to nest KVM under KVM." msgstr "" #: ./doc/arch-design/ch_references.xml:65(para) -msgid "OpenStack Training Marketplace: http://www.openstack.org/marketplace/trainingThe OpenStack Market for training and Vendors providing training on OpenStack." +msgid "<link href=\"http://www.opencompute.org/\">Open Compute Project</link>: The Open Compute Project Foundation’s mission is to design and enable the delivery of the most efficient server, storage and data center hardware designs for scalable computing." msgstr "" -#: ./doc/arch-design/ch_references.xml:68(para) -msgid "PCI passthrough: https://wiki.openstack.org/wiki/Pci_passthrough#How_to_check_PCI_status_with_PCI_api_paches The PCI api patches extends the servers/os-hypervisor to show PCI information for instance and compute node, and also provides a resource endpoint to show PCI information." +#: ./doc/arch-design/ch_references.xml:72(para) +msgid "<link href=\"http://docs.openstack.org/openstack-ops/content/flavors.html\">OpenStack Flavors</link>: Official OpenStack documentation." msgstr "" -#: ./doc/arch-design/ch_references.xml:73(para) -msgid "TripleO: https://wiki.openstack.org/wiki/TripleOTripleO is a program aimed at installing, upgrading and operating OpenStack clouds using OpenStack's own cloud facilities as the foundation." +#: ./doc/arch-design/ch_references.xml:77(para) +msgid "<link href=\"http://docs.openstack.org/high-availability-guide/content/\">OpenStack High Availability Guide</link>: Information on how to provide redundancy for the OpenStack components." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:8(title) ./doc/arch-design/network_focus/section_operational_considerations_network_focus.xml:8(title) ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:8(title) ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:8(title) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:142(title) ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:8(title) ./doc/arch-design/massively_scalable/section_operational_considerations_massively_scalable.xml:8(title) ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:8(title) +#: ./doc/arch-design/ch_references.xml:83(para) +msgid "<link href=\"https://wiki.openstack.org/wiki/HypervisorSupportMatrix\">OpenStack Hypervisor Support Matrix</link>: Matrix of supported hypervisors and capabilities when used with OpenStack." +msgstr "" + +#: ./doc/arch-design/ch_references.xml:89(para) +msgid "<link href=\"http://docs.openstack.org/developer/swift/replication_network.html\">OpenStack Object Store (Swift) Replication Reference</link>: Developer documentation of Swift replication." +msgstr "" + +#: ./doc/arch-design/ch_references.xml:95(para) +msgid "<link href=\"http://docs.openstack.org/openstack-ops/\">OpenStack Operations Guide</link>: The OpenStack Operations Guide provides information on setting up and installing OpenStack." +msgstr "" + +#: ./doc/arch-design/ch_references.xml:101(para) +msgid "<link href=\"http://docs.openstack.org/security-guide/\">OpenStack Security Guide</link>: The OpenStack Security Guide provides information on securing OpenStack deployments." +msgstr "" + +#: ./doc/arch-design/ch_references.xml:107(para) +msgid "<link href=\"http://www.openstack.org/marketplace/training\">OpenStack Training Marketplace</link>: The OpenStack Market for training and Vendors providing training on OpenStack." +msgstr "" + +#: ./doc/arch-design/ch_references.xml:113(para) +msgid "<link href=\"https://wiki.openstack.org/wiki/Pci_passthrough#How_to_check_PCI_status_with_PCI_api_paches\">PCI passthrough</link>: The PCI API patches extend the servers/os-hypervisor to show PCI information for instance and compute node, and also provides a resource endpoint to show PCI information." +msgstr "" + +#: ./doc/arch-design/ch_references.xml:121(para) +msgid "<link href=\"https://wiki.openstack.org/wiki/TripleO\">TripleO</link>: TripleO is a program aimed at installing, upgrading and operating OpenStack clouds using OpenStack's own cloud facilities as the foundation." +msgstr "" + +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:8(title) ./doc/arch-design/network_focus/section_operational_considerations_network_focus.xml:8(title) ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:8(title) ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:8(title) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:175(title) ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:8(title) ./doc/arch-design/massively_scalable/section_operational_considerations_massively_scalable.xml:8(title) ./doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml:8(title) msgid "Operational considerations" msgstr "" @@ -667,7 +667,7 @@ msgstr "" msgid "@@image: '../images/Multi-Site_shared_keystone_horizon_swift1.png'; md5=c443da33089971595104cd918f40d339" msgstr "" -#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:8(title) ./doc/arch-design/network_focus/section_architecture_network_focus.xml:7(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:8(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:8(title) ./doc/arch-design/hybrid/section_architecture_hybrid.xml:8(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:7(title) +#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:8(title) ./doc/arch-design/network_focus/section_architecture_network_focus.xml:7(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:12(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:8(title) ./doc/arch-design/hybrid/section_architecture_hybrid.xml:8(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:11(title) msgid "Architecture" msgstr "" @@ -691,7 +691,7 @@ msgstr "" msgid "The OpenStack Dashboard, OpenStack Identity Service, and OpenStack Object Storage services are components that can each be deployed centrally in order to serve multiple regions." msgstr "" -#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:53(title) ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:153(para) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:18(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:18(para) +#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:53(title) ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:153(para) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:22(para) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:131(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:18(para) msgid "Storage" msgstr "" @@ -711,7 +711,7 @@ msgstr "" msgid "For the Block Storage service, the most important decisions are the selection of the storage technology and whether or not a dedicated network is used to carry storage traffic from the storage service to the compute nodes." msgstr "" -#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:86(title) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:415(para) +#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:86(title) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:416(para) msgid "Networking" msgstr "" @@ -719,7 +719,7 @@ msgstr "" msgid "When connecting multiple regions together there are several design considerations. The overlay network technology choice determines how packets are transmitted between regions and how the logical network and addresses present to the application. If there are security or regulatory requirements, encryption should be implemented to secure the traffic between regions. For networking inside a region, the overlay network technology for tenant networks is equally important. The overlay technology and the network traffic of an application generates or receives can be either complementary or be at cross purpose. For example, using an overlay technology for an application that transmits a large amount of small packets could add excessive latency or overhead to each packet if not configured properly." msgstr "" -#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:102(title) +#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:102(title) ./doc/arch-design/introduction/section_methodology.xml:166(term) msgid "Dependencies" msgstr "" @@ -751,7 +751,7 @@ msgstr "" msgid "Data locality, in which specific data or functionality should be close to users." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:8(title) ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:8(title) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:8(title) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml: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/massively_scalable/section_user_requirements_massively_scalable.xml:50(title) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:8(title) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:8(title) ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:8(title) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:8(title) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:12(title) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:8(title) ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:8(title) ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:50(title) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:8(title) msgid "User requirements" msgstr "" @@ -759,19 +759,19 @@ msgstr "" msgid "A multi-site architecture is complex and has its own risks and considerations, therefore it is important to make sure when contemplating the design such an architecture that it meets the user and business requirements." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:13(para) ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:42(para) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:78(para) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:41(para) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:68(para) ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:17(para) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:36(para) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:13(para) ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:42(para) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:88(para) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:55(para) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:68(para) ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:17(para) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:36(para) msgid "Many jurisdictions have legislative and regulatory requirements governing the storage and management of data in cloud environments. Common areas of regulation include:" msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:18(para) ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:47(para) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:83(para) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:46(para) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:73(para) ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:22(para) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:18(para) ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:47(para) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:93(para) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:60(para) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:73(para) ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:22(para) msgid "Data retention policies ensuring storage of persistent data and records management to meet data archival requirements." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:23(para) ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:52(para) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:88(para) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:51(para) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:78(para) ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:27(para) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:23(para) ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:52(para) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:98(para) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:65(para) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:78(para) ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:27(para) msgid "Data ownership policies governing the possession and responsibility for data." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:27(para) ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:56(para) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:92(para) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:55(para) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:82(para) ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:31(para) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:27(para) ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:56(para) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:102(para) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:69(para) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:82(para) ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:31(para) msgid "Data sovereignty policies governing the storage of data in foreign countries or otherwise separate jurisdictions." msgstr "" @@ -851,7 +851,7 @@ msgstr "" msgid "Some applications are tolerant of the lack of synchronized object storage, while others may need those objects to be replicated and available across regions. Understanding of how the cloud implementation impacts new and existing applications is important for risk mitigation and the overall success of a cloud project. Applications may have to be written to expect an infrastructure with little to no redundancy. Existing applications not developed with the cloud in mind may need to be rewritten." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:137(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:12(para) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:137(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:72(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:234(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:637(term) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:24(term) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:20(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:16(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:40(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:184(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:417(term) msgid "Cost" msgstr "" @@ -871,7 +871,7 @@ msgstr "" msgid "Replication" msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:156(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:654(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:285(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:122(para) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:156(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:662(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:286(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:122(para) msgid "Management" msgstr "" @@ -1073,7 +1073,7 @@ msgstr "" msgid "In this example, the application utilizing this multi-site OpenStack install that is location aware would launch web server or content serving instances on the compute cluster in each site. Requests from clients will first be sent to a global services load balancer that determines the location of the client, then routes the request to the closest OpenStack site where the application completes the request." msgstr "" -#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:8(title) ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:8(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:8(title) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:74(title) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:8(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:8(title) ./doc/arch-design/massively_scalable/section_tech_considerations_massively_scalable.xml:8(title) ./doc/arch-design/storage_focus/section_tech_considerations_storage_focus.xml:8(title) +#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:8(title) ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:8(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:12(title) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:90(title) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:12(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:8(title) ./doc/arch-design/massively_scalable/section_tech_considerations_massively_scalable.xml:8(title) ./doc/arch-design/storage_focus/section_tech_considerations_storage_focus.xml:8(title) msgid "Technical considerations" msgstr "" @@ -1105,7 +1105,7 @@ msgstr "" msgid "A third form of capacity comes in the multi-region-capable components of OpenStack. Centralized Object Storage is capable of serving objects through a single namespace across multiple regions. Since this works by accessing the object store via swift proxy, it is possible to overload the proxies. There are two options available to mitigate this issue. The first is to deploy a large number of swift proxies. The drawback to this is that the proxies are not load-balanced and a large file request could continually hit the same proxy. The other way to mitigate this is to front-end the proxies with a caching HTTP proxy and load balancer. Since swift objects are returned to the requester via HTTP, this load balancer would alleviate the load required on the swift proxies." msgstr "" -#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:79(title) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:214(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:222(title) +#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:79(title) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:215(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:222(title) msgid "Utilization" msgstr "" @@ -1125,7 +1125,7 @@ msgstr "" msgid "Depending on the storage model chosen during site design, storage replication and availability will also be a concern for end-users. If an application is capable of understanding regions, then it is possible to keep the object storage system separated by region. In this case, users who want to have an object available to more than one region will need to do the cross-site replication themselves. With a centralized swift proxy, however, the user may need to benchmark the replication timing of the Swift back end. Benchmarking allows the operational staff to provide users with an understanding of the amount of time required for a stored or modified object to become available to the entire environment." msgstr "" -#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:114(title) ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:365(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:469(title) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:256(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:245(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:15(para) +#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:114(title) ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:365(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:249(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:420(term) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:130(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:474(title) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:96(term) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:257(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:245(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:19(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:48(term) msgid "Performance" msgstr "" @@ -1141,7 +1141,7 @@ msgstr "" msgid "Storage availability can also be impacted by the architecture of a multi-site deployment. A centralized Object Storage Service requires more time for an object to be available to instances locally in regions where the object was not created. Some applications may need to be tuned to account for this effect. Block storage does not currently have a method for replicating data across multiple regions, so applications that depend on available block storage will need to manually cope with this limitation by creating duplicate block storage entries in each region." msgstr "" -#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:139(title) ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:142(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:640(title) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:267(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:103(title) +#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:139(title) ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:142(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:684(term) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:199(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:648(title) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:160(term) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:268(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:103(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:471(term) msgid "Security" msgstr "" @@ -1157,7 +1157,7 @@ msgstr "" msgid "Just as tenants in a single-site deployment need isolation from each other, so do tenants in multi-site installations. The extra challenges in multi-site designs revolve around ensuring that tenant networks function across regions. Unfortunately, OpenStack Networking does not presently support a mechanism to provide this functionality, therefore an external system may be necessary to manage these mappings. Tenant networks may contain sensitive information requiring that this mapping be accurate and consistent to ensure that a tenant in one site does not connect to a different tenant in another site." msgstr "" -#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:169(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:515(para) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:607(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:399(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:526(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:665(title) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:359(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:328(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:424(title) +#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:169(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:611(para) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:725(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:404(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:526(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:665(title) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:360(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:394(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:512(title) msgid "OpenStack components" msgstr "" @@ -1837,372 +1837,472 @@ msgstr "" msgid "How to respond to network events must also be taken into consideration. As an example, how load is transferred from one link to another during a failure scenario could be a factor in the design. If network capacity is not planned correctly, failover traffic could overwhelm other ports or network links and create a cascading failure scenario. In this case, traffic that fails over to one link overwhelms that link and then moves to the subsequent links until the all network traffic stops." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:9(para) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:13(para) msgid "Hardware selection involves three key areas:" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:12(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:12(para) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:16(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:12(para) msgid "Compute" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:15(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:15(para) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:19(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:15(para) msgid "Network" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:21(para) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:25(para) msgid "For each of these areas, the selection of hardware for a general purpose OpenStack cloud must reflect the fact that a the cloud has no pre-defined usage model. This means that there will be a wide variety of applications running on this cloud that will have varying resource usage requirements. Some applications will be RAM-intensive, some applications will be CPU-intensive, while others will be storage-intensive. Therefore, choosing hardware for a general purpose OpenStack cloud must provide balanced access to all major resources." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:31(para) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:35(para) msgid "Certain hardware form factors may be better suited for use in a general purpose OpenStack cloud because of the need for an equal or nearly equal balance of resources. Server hardware for a general purpose OpenStack architecture design must provide an equal or nearly equal balance of compute capacity (RAM and CPU), network capacity (number and speed of links), and storage capacity (gigabytes or terabytes as well as I-O Operations Per Second (IOPS)." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:39(para) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:43(para) msgid "Server hardware is evaluated around four conflicting dimensions:" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:43(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:45(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:134(para) -msgid "Server density: A measure of how many servers can fit into a given measure of physical space, such as a rack unit [U]." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:48(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:160(term) +msgid "Server density" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:48(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:52(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:139(para) -msgid "Resource capacity: The number of CPU cores, how much RAM, or how much storage a given server will deliver." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:50(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:162(para) +msgid "A measure of how many servers can fit into a given measure of physical space, such as a rack unit [U]." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:53(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:59(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:144(para) -msgid "Expandability: The number of additional resources that can be added to a server before it has reached its limit." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:56(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:168(term) +msgid "Resource capacity" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:58(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:66(para) -msgid "Cost: The relative purchase price of the hardware weighted against the level of design effort needed to build the system." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:58(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:170(para) +msgid "The number of CPU cores, how much RAM, or how much storage a given server will deliver." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:63(para) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:64(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:281(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:76(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:176(term) +msgid "Expandability" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:66(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:178(para) +msgid "The number of additional resources that can be added to a server before it has reached its limit." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:74(para) +msgid "The relative purchase price of the hardware weighted against the level of design effort needed to build the system." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:80(para) msgid "Increasing server density means sacrificing resource capacity or expandability, however, increasing resource capacity and expandability increases cost and decreases server density. As a result, determining the best server hardware for a general purpose OpenStack architecture means understanding how choice of form factor will impact the rest of the design." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:72(para) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:89(para) msgid "Blade servers typically support dual-socket multi-core CPUs, which is the configuration generally considered to be the \"sweet spot\" for a general purpose cloud deployment. Blades also offer outstanding density. As an example, both HP BladeSystem and Dell PowerEdge M1000e support up to 16 servers in only 10 rack units. However, the blade servers themselves often have limited storage and networking capacity. Additionally, the expandability of many blade servers can be limited." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:84(para) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:101(para) msgid "1U rack-mounted servers occupy only a single rack unit. Their benefits include high density, support for dual-socket multi-core CPUs, and support for reasonable RAM amounts. This form factor offers limited storage capacity, limited network capacity, and limited expandability." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:92(para) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:109(para) msgid "2U rack-mounted servers offer the expanded storage and networking capacity that 1U servers tend to lack, but with a corresponding decrease in server density (half the density offered by 1U rack-mounted servers)." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:99(para) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:116(para) msgid "Larger rack-mounted servers, such as 4U servers, will tend to offer even greater CPU capacity, often supporting four or even eight CPU sockets. These servers often have much greater expandability so will provide the best option for upgradability. This means, however, that the servers have a much lower server density and a much greater hardware cost." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:108(para) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:125(para) msgid "\"Sled servers\" are rack-mounted servers that support multiple independent servers in a single 2U or 3U enclosure. This form factor offers increased density over typical 1U-2U rack-mounted servers but tends to suffer from limitations in the amount of storage or network capacity each individual server supports." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:117(para) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:134(para) msgid "Given the wide selection of hardware and general user requirements, the best form factor for the server hardware supporting a general purpose OpenStack cloud is driven by outside business and cost factors. No single reference architecture will apply to all implementations; the decision must flow out of the user requirements, technical considerations, and operational considerations. Here are some of the key factors that influence the selection of server hardware:" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:128(para) -msgid "Instance density: Sizing is an important consideration for a general purpose OpenStack cloud. The expected or anticipated number of instances that each hypervisor can host is a common metric used in sizing the deployment. The selected server hardware needs to support the expected or anticipated instance density." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:146(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:274(term) +msgid "Instance density" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:137(para) -msgid "Host density: Physical data centers have limited physical space, power, and cooling. The number of hosts (or hypervisors) that can be fitted into a given metric (rack, rack unit, or floor tile) is another important method of sizing. Floor weight is an often overlooked consideration. The data center floor must be able to support the weight of the proposed number of hosts within a rack or set of racks. These factors need to be applied as part of the host density calculation and server hardware selection." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:148(para) +msgid "Sizing is an important consideration for a general purpose OpenStack cloud. The expected or anticipated number of instances that each hypervisor can host is a common metric used in sizing the deployment. The selected server hardware needs to support the expected or anticipated instance density." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:149(para) -msgid "Power density: Data centers have a specified amount of power fed to a given rack or set of racks. Older data centers may have a power density as power as low as 20 AMPs per rack, while more recent data centers can be architected to support power densities as high as 120 AMP per rack. The selected server hardware must take power density into account." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:158(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:284(term) +msgid "Host density" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:158(para) -msgid "Network connectivity: The selected server hardware must have the appropriate number of network connections, as well as the right type of network connections, in order to support the proposed architecture. Ensure that, at a minimum, there are at least two diverse network connections coming into each rack. For architectures requiring even more redundancy, it might be necessary to confirm that the network connections are from diverse telecom providers. Many data centers have that capacity available." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:160(para) +msgid "Physical data centers have limited physical space, power, and cooling. The number of hosts (or hypervisors) that can be fitted into a given metric (rack, rack unit, or floor tile) is another important method of sizing. Floor weight is an often overlooked consideration. The data center floor must be able to support the weight of the proposed number of hosts within a rack or set of racks. These factors need to be applied as part of the host density calculation and server hardware selection." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:171(para) -msgid "The selection of certain form factors or architectures will affect the selection of server hardware. For example, if the design calls for a scale-out storage architecture (For example, leveraging Ceph, Gluster, or a similar commercial solution), then the server hardware selection will need to be carefully considered to match the requirements set by the commercial solution. Ensure that the selected server hardware is configured to support enough storage capacity (or storage expandability) to match the requirements of selected scale-out storage solution. For example, if a centralized storage solution is required, such as a centralized storage array from a storage vendor that has infiniBand or FDDI connections, the server hardware will need to have appropriate network adapters installed to be compatible with the storage array vendor's specifications." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:173(term) +msgid "Power density" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:186(para) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:175(para) +msgid "Data centers have a specified amount of power fed to a given rack or set of racks. Older data centers may have a power density as power as low as 20 AMPs per rack, while more recent data centers can be architected to support power densities as high as 120 AMP per rack. The selected server hardware must take power density into account." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:185(term) +msgid "Network connectivity" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:187(para) +msgid "The selected server hardware must have the appropriate number of network connections, as well as the right type of network connections, in order to support the proposed architecture. Ensure that, at a minimum, there are at least two diverse network connections coming into each rack. For architectures requiring even more redundancy, it might be necessary to confirm that the network connections are from diverse telecom providers. Many data centers have that capacity available." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:201(para) +msgid "The selection of certain form factors or architectures will affect the selection of server hardware. For example, if the design calls for a scale-out storage architecture (such as leveraging Ceph, Gluster, or a similar commercial solution), then the server hardware selection will need to be carefully considered to match the requirements set by the commercial solution. Ensure that the selected server hardware is configured to support enough storage capacity (or storage expandability) to match the requirements of selected scale-out storage solution. For example, if a centralized storage solution is required, such as a centralized storage array from a storage vendor that has infiniBand or FDDI connections, the server hardware will need to have appropriate network adapters installed to be compatible with the storage array vendor's specifications." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:216(para) msgid "Similarly, the network architecture will have an impact on the server hardware selection and vice versa. For example, make sure that the server is configured with enough additional network ports and expansion cards to support all of the networks required. There is variability in network expansion cards, so it is important to be aware of potential impacts or interoperability issues with other components in the architecture. This is especially true if the architecture uses InfiniBand or another less commonly used networking protocol." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:197(title) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:227(title) msgid "Selecting storage hardware" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:198(para) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:228(para) msgid "The selection of storage hardware is largely determined by the proposed storage architecture. Factors that need to be incorporated into the storage architecture include:" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:203(para) -msgid "Cost: Storage can be a significant portion of the overall system cost that should be factored into the design decision. For an organization that is concerned with vendor support, a commercial storage solution is advisable, although it is comes with a higher price tag. If initial capital expenditure requires minimization, designing a system based on commodity hardware would apply. The trade-off is potentially higher support costs and a greater risk of incompatibility and interoperability issues." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:236(para) +msgid "Storage can be a significant portion of the overall system cost that should be factored into the design decision. For an organization that is concerned with vendor support, a commercial storage solution is advisable, although it is comes with a higher price tag. If initial capital expenditure requires minimization, designing a system based on commodity hardware would apply. The trade-off is potentially higher support costs and a greater risk of incompatibility and interoperability issues." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:215(para) -msgid "Performance: Storage performance, measured by observing the latency of storage I-O requests, is not a critical factor for a general purpose OpenStack cloud as overall systems performance is not a design priority." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:251(para) +msgid "Storage performance, measured by observing the latency of storage I-O requests, is not a critical factor for a general purpose OpenStack cloud as overall systems performance is not a design priority." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:222(para) -msgid "Scalability: The term \"scalability\" refers to how well the storage solution performs as it expands up to its maximum designed size. A solution that continues to perform well at maximum expansion is considered scalable. A storage solution that performs well in small configurations but has degrading performance as it expands was not designed to be not scalable. Scalability, along with expandability, is a major consideration in a general purpose OpenStack cloud. It might be difficult to predict the final intended size of the implementation because there are no established usage patterns for a general purpose cloud. Therefore, it may become necessary to expand the initial deployment in order to accommodate growth and user demand. The ability of the storage solution to continue to perform well as it expands is important." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:259(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:572(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:62(term) +msgid "Scalability" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:241(para) -msgid "Expandability: This refers to the overall ability of the solution to grow. A storage solution that expands to 50 PB is considered more expandable than a solution that only scales to 10 PB. This metric is related to, but different, from scalability, which is a measure of the solution's performance as it expands. Expandability is a major architecture factor for storage solutions with general purpose OpenStack cloud. For example, the storage architecture for a cloud that is intended for a development platform may not have the same expandability and scalability requirements as a cloud that is intended for a commercial product." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:261(para) +msgid "The term \"scalability\" refers to how well the storage solution performs as it expands up to its maximum designed size. A solution that continues to perform well at maximum expansion is considered scalable. A storage solution that performs well in small configurations but has degrading performance as it expands was not designed to be not scalable. Scalability, along with expandability, is a major consideration in a general purpose OpenStack cloud. It might be difficult to predict the final intended size of the implementation because there are no established usage patterns for a general purpose cloud. Therefore, it may become necessary to expand the initial deployment in order to accommodate growth and user demand. The ability of the storage solution to continue to perform well as it expands is important." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:256(para) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:283(para) +msgid "This refers to the overall ability of the solution to grow. A storage solution that expands to 50PB is considered more expandable than a solution that only scales to 10PB. This metric is related to, but different, from scalability, which is a measure of the solution's performance as it expands. Expandability is a major architecture factor for storage solutions with general purpose OpenStack cloud. For example, the storage architecture for a cloud that is intended for a development platform may not have the same expandability and scalability requirements as a cloud that is intended for a commercial product." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:299(para) msgid "Storage hardware architecture is largely determined by the selected storage architecture. The selection of storage architecture, as well as the corresponding storage hardware, is determined by evaluating possible solutions against the critical factors, the user requirements, technical considerations, and operational considerations. A combination of all the factors and considerations will determine which approach will be best." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:264(para) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:307(para) msgid "Using a scale-out storage solution with direct-attached storage (DAS) in the servers is well suited for a general purpose OpenStack cloud. In this scenario, it is possible to populate storage in either the compute hosts similar to a grid computing solution or into hosts dedicated to providing block storage exclusively. When deploying storage in the compute hosts, appropriate hardware which can support both the storage and compute services on the same hardware will be required. This approach is referred to as a grid computing architecture because there is a grid of modules that have both compute and storage in a single box." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:275(para) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:318(para) msgid "Understanding the requirements of cloud services will help determine if Ceph, Gluster, or a similar scale-out solution should be used. It can then be further determined if a single, highly expandable and highly vertical, scalable, centralized storage array should be included in the design. Once the approach has been determined, the storage hardware needs to be chosen based on this criteria. If a centralized storage array fits the requirements best, then the array vendor will determine the hardware. For cost reasons it may be decided to build an open source storage array using solutions such as OpenFiler, Nexenta Open Source, or BackBlaze Open Source." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:287(para) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:330(para) msgid "This list expands upon the potential impacts for including a particular storage architecture (and corresponding storage hardware) into the design for a general purpose OpenStack cloud:" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:293(para) -msgid "Connectivity: Ensure that, if storage protocols other than Ethernet are part of the storage solution, the appropriate hardware has been selected. Some examples include InfiniBand, FDDI and Fibre Channel. If a centralized storage array is selected, ensure that the hypervisor will be able to connect to that storage array for image storage." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:337(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:559(term) ./doc/arch-design/introduction/section_methodology.xml:182(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:116(term) +msgid "Connectivity" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:302(para) -msgid "Usage: How the particular storage architecture will be used is critical for determining the architecture. Some of the configurations that will influence the architecture include whether it will be used by the hypervisors for ephemeral instance storage or if OpenStack Swift will use it for object storage. All of these usage models are affected by the selection of particular storage architecture and the corresponding storage hardware to support that architecture." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:339(para) +msgid "Ensure that, if storage protocols other than Ethernet are part of the storage solution, the appropriate hardware has been selected. Some examples include InfiniBand, FDDI and Fibre Channel. If a centralized storage array is selected, ensure that the hypervisor will be able to connect to that storage array for image storage." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:313(para) -msgid "Instance and image locations: Where instances and images will be stored will influence the architecture. For example, instances can be stored in a number of options. OpenStack Cinder is a good location for instances because it is persistent block storage, however, Swift can be used if storage latency is less of a concern. The same argument applies to the appropriate image storage location." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:349(term) +msgid "Usage" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:323(para) -msgid "Server Hardware: If the solution is a scale-out storage architecture that includes DAS, naturally that will affect the server hardware selection. This could ripple into the decisions that affect host density, instance density, power density, OS-hypervisor, management tools and others." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:351(para) +msgid "How the particular storage architecture will be used is critical for determining the architecture. Some of the configurations that will influence the architecture include whether it will be used by the hypervisors for ephemeral instance storage or if OpenStack Object Storage will use it for object storage. All of these usage models are affected by the selection of particular storage architecture and the corresponding storage hardware to support that architecture." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:331(para) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:363(term) +msgid "Instance and image locations" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:365(para) +msgid "Where instances and images will be stored will influence the architecture. For example, instances can be stored in a number of options. OpenStack Block Storage is a good location for instances because it is persistent block storage, however, OpenStack Object Storage can be used if storage latency is less of a concern. The same argument applies to the appropriate image storage location." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:378(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:145(term) +msgid "Server hardware" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:380(para) +msgid "If the solution is a scale-out storage architecture that includes DAS, naturally that will affect the server hardware selection. This could ripple into the decisions that affect host density, instance density, power density, OS-hypervisor, management tools and others." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:389(para) msgid "General purpose OpenStack cloud has multiple options. As a result, there is no single decision that will apply to all implementations. The key factors that will have an influence on selection of storage hardware for a general purpose OpenStack cloud are as follows:" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:338(para) -msgid "Capacity: Hardware resources selected for the resource nodes should be capable of supporting enough storage for the cloud services that will use them. It is important to clearly define the initial requirements and ensure that the design can support adding capacity as resources are used in the cloud, as workloads are relatively unknown. Hardware nodes selected for object storage should be capable of supporting a large number of inexpensive disks and should not have any reliance on RAID controller cards. Hardware nodes selected for block storage should be capable of supporting higher speed storage solutions and RAID controller cards to provide performance and redundancy to storage at the hardware level. Selecting hardware RAID controllers that can automatically repair damaged arrays will further assist with replacing and repairing degraded or destroyed storage devices within the cloud." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:397(term) +msgid "Capacity" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:358(para) -msgid "Performance: Disks selected for the object storage service do not need to be fast performing disks. It is recommended that object storage nodes take advantage of the best cost per terabyte available for storage at the time of acquisition and avoid enterprise class drives. In contrast, disks chosen for the block storage service should take advantage of performance boosting features and may entail the use of SSDs or flash storage to provide for high performing block storage pools. Storage performance of ephemeral disks used for instances should also be taken into consideration. If compute pools are expected to have a high utilization of ephemeral storage or requires very high performance, it would be advantageous to deploy similar hardware solutions to block storage in order to increase the storage performance." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:399(para) +msgid "Hardware resources selected for the resource nodes should be capable of supporting enough storage for the cloud services that will use them. It is important to clearly define the initial requirements and ensure that the design can support adding capacity as resources are used in the cloud, as workloads are relatively unknown. Hardware nodes selected for object storage should be capable of supporting a large number of inexpensive disks and should not have any reliance on RAID controller cards. Hardware nodes selected for block storage should be capable of supporting higher speed storage solutions and RAID controller cards to provide performance and redundancy to storage at the hardware level. Selecting hardware RAID controllers that can automatically repair damaged arrays will further assist with replacing and repairing degraded or destroyed storage devices within the cloud." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:376(para) -msgid "Fault Tolerance: Object storage resource nodes have no requirements for hardware fault tolerance or RAID controllers. It is not necessary to plan for fault tolerance within the object storage hardware because the object storage service provides replication between zones as a feature of the service. Block storage nodes, compute nodes and cloud controllers should all have fault tolerance built in at the hardware level by making use of hardware RAID controllers and varying levels of RAID configuration. The level of RAID chosen should be consistent with the performance and availability requirements of the cloud." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:422(para) +msgid "Disks selected for the object storage service do not need to be fast performing disks. It is recommended that object storage nodes take advantage of the best cost per terabyte available for storage at the time of acquisition and avoid enterprise class drives. In contrast, disks chosen for the block storage service should take advantage of performance boosting features and may entail the use of SSDs or flash storage to provide for high performing block storage pools. Storage performance of ephemeral disks used for instances should also be taken into consideration. If compute pools are expected to have a high utilization of ephemeral storage or requires very high performance, it would be advantageous to deploy similar hardware solutions to block storage in order to increase the storage performance." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:393(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:403(title) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:441(term) +msgid "Fault tolerance" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:443(para) +msgid "Object storage resource nodes have no requirements for hardware fault tolerance or RAID controllers. It is not necessary to plan for fault tolerance within the object storage hardware because the object storage service provides replication between zones as a feature of the service. Block storage nodes, compute nodes and cloud controllers should all have fault tolerance built in at the hardware level by making use of hardware RAID controllers and varying levels of RAID configuration. The level of RAID chosen should be consistent with the performance and availability requirements of the cloud." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:461(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:403(title) msgid "Selecting networking hardware" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:394(para) -msgid "As is the case with storage architecture, selecting a network architecture often determines which network hardware will be used. The networking software in use is determined by the selected networking hardware. Some design impacts are obvious, for example, selecting networking hardware that only supports Gigabit Ethernet (GbE) will naturally have an impact on many different areas of the overall design. Similarly, deciding to use 10 Gigabit Ethernet (10 GbE) has a number of impacts on various areas of the overall design." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:462(para) +msgid "As is the case with storage architecture, selecting a network architecture often determines which network hardware will be used. The networking software in use is determined by the selected networking hardware. Some design impacts are obvious, for example, selecting networking hardware that only supports Gigabit Ethernet (GbE) will naturally have an impact on many different areas of the overall design. Similarly, deciding to use 10 Gigabit Ethernet (10GbE) has a number of impacts on various areas of the overall design." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:403(para) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:471(para) msgid "As an example, selecting Cisco networking hardware implies that the architecture will be using Cisco networking software like IOS or NX-OS. Conversely, selecting Arista networking hardware means the network devices will use the Arista networking software called Extensible Operating System (EOS). In addition, there are more subtle design impacts that need to be considered. The selection of certain networking hardware (and therefore the networking software) could affect the management tools that can be used. There are exceptions to this; the rise of \"open\" networking software that supports a range of networking hardware means that there are instances where the relationship between networking hardware and networking software are not as tightly defined. An example of this type of software is Cumulus Linux, which is capable of running on a number of switch vendor’s hardware solutions." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:419(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:404(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:268(para) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:487(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:404(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:315(para) msgid "Some of the key considerations that should be included in the selection of networking hardware include:" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:423(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:410(para) -msgid "Port count: The design will require networking hardware that has the requisite port count." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:492(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:319(term) +msgid "Port count" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:427(para) -msgid "Port density: The network design will be affected by the physical space that is required to provide the requisite port count. A switch that can provide 48 10 GbE ports in 1U has a much higher port density than a switch that provides 24 10 GbE ports in 2U. A higher port density is preferred, as it leaves more rack space for compute or storage components that may be required by the design. This can also lead into concerns about fault domains and power density that should be considered. Higher density switches are more expensive and should also be considered, as it is important not to over design the network if it is not required." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:494(para) +msgid "The design will require networking hardware that has the requisite port count." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:442(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:440(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:289(para) -msgid "Port speed: The networking hardware must support the proposed network speed, for example: 1 GbE, 10 GbE, or 40 GbE (or even 100 GbE)." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:499(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:326(term) +msgid "Port density" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:447(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:448(para) -msgid "Redundancy: The level of network hardware redundancy required is influenced by the user requirements for high availability and cost considerations. Network redundancy can be achieved by adding redundant power supplies or paired switches. If this is a requirement, the hardware will need to support this configuration. User requirements will determine if a completely redundant network infrastructure is required." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:501(para) +msgid "The network design will be affected by the physical space that is required to provide the requisite port count. A switch that can provide 48 10GbE ports in 1U has a much higher port density than a switch that provides 24 10GbE ports in 2U. A higher port density is preferred, as it leaves more rack space for compute or storage components that may be required by the design. This can also lead into concerns about fault domains and power density that should be considered. Higher density switches are more expensive and should also be considered, as it is important not to over design the network if it is not required." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:457(para) -msgid "Power requirements: Make sure that the physical data center provides the necessary power for the selected network hardware. This is not an issue for top of rack (ToR) switches, but may be an issue for spine switches in a leaf and spine fabric, or end of row (EoR) switches." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:517(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:342(term) +msgid "Port speed" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:465(para) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:519(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:344(para) +msgid "The networking hardware must support the proposed network speed, for example: 1GbE, 10GbE, or 40GbE (or even 100GbE)." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:527(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:350(term) +msgid "Redundancy" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:529(para) +msgid "The level of network hardware redundancy required is influenced by the user requirements for high availability and cost considerations. Network redundancy can be achieved by adding redundant power supplies or paired switches. If this is a requirement, the hardware will need to support this configuration. User requirements will determine if a completely redundant network infrastructure is required." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:540(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:363(term) +msgid "Power requirements" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:542(para) +msgid "Make sure that the physical data center provides the necessary power for the selected network hardware. This is not an issue for top of rack (ToR) switches, but may be an issue for spine switches in a leaf and spine fabric, or end of row (EoR) switches." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:551(para) msgid "There is no single best practice architecture for the networking hardware supporting a general purpose OpenStack cloud that will apply to all implementations. Some of the key factors that will have a strong influence on selection of networking hardware include:" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:472(para) -msgid "Connectivity: All nodes within an OpenStack cloud require some form of network connectivity. In some cases, nodes require access to more than one network segment. The design must encompass sufficient network capacity and bandwidth to ensure that all communications within the cloud, both north-south and east-west traffic have sufficient resources available." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:561(para) +msgid "All nodes within an OpenStack cloud require some form of network connectivity. In some cases, nodes require access to more than one network segment. The design must encompass sufficient network capacity and bandwidth to ensure that all communications within the cloud, both north-south and east-west traffic have sufficient resources available." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:482(para) -msgid "Scalability: The chosen network design should encompass a physical and logical network design that can be easily expanded upon. Network hardware should offer the appropriate types of interfaces and speeds that are required by the hardware nodes." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:574(para) +msgid "The chosen network design should encompass a physical and logical network design that can be easily expanded upon. Network hardware should offer the appropriate types of interfaces and speeds that are required by the hardware nodes." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:489(para) -msgid "Availability: To ensure that access to nodes within the cloud is not interrupted, it is recommended that the network architecture identify any single points of failure and provide some level of redundancy or fault tolerance. With regard to the network infrastructure itself, this often involves use of networking protocols such as LACP, VRRP or others to achieve a highly available network connection. In addition, it is important to consider the networking implications on API availability. In order to ensure that the APIs, and potentially other services in the cloud are highly available, it is recommended to design load balancing solutions within the network architecture to accommodate for these requirements." -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:507(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:290(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:515(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:320(title) -msgid "Software selection" -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:508(para) -msgid "Software selection for a general purpose OpenStack architecture design needs to include these three areas:" -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:512(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:523(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:325(para) -msgid "Operating system (OS) and hypervisor" -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:518(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:430(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:529(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:743(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:331(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:474(title) -msgid "Supplemental software" -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:523(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:538(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:337(title) -msgid "Operating system and hypervisor" -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:524(para) -msgid "The selection of operating system (OS) and hypervisor has a tremendous impact on the overall design. Selecting a particular operating system and hypervisor can also directly affect server hardware selection. It is recommended to make sure the storage hardware selection and topology support the selected operating system and hypervisor combination. Finally, it is important to ensure that the networking hardware selection and topology will work with the chosen operating system and hypervisor combination. For example, if the design uses Link Aggregation Control Protocol (LACP), the OS and hypervisor both need to support it." -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:536(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:554(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:347(para) -msgid "Some areas that could be impacted by the selection of OS and hypervisor include:" -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:540(para) -msgid "Cost: Selecting a commercially supported hypervisor, such as Microsoft Hyper-V, will result in a different cost model rather than community-supported open source hypervisors including KVM, Kinstance or Xen. When comparing open source OS solutions, choosing Ubuntu over Red Hat (or vice versa) will have an impact on cost due to support contracts. On the other hand, business or application requirements may dictate a specific or commercially supported hypervisor." -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:551(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:577(para) -msgid "Supportability: Depending on the selected hypervisor, the staff should have the appropriate training and knowledge to support the selected OS and hypervisor combination. If they do not, training will need to be provided which could have a cost impact on the design." -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:559(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:590(para) -msgid "Management tools: The management tools used for Ubuntu and Kinstance differ from the management tools for VMware vSphere. Although both OS and hypervisor combinations are supported by OpenStack, there will be very different impacts to the rest of the design as a result of the selection of one combination versus the other." -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:568(para) -msgid "Scale and performance: Ensure that selected OS and hypervisor combinations meet the appropriate scale and performance requirements. The chosen architecture will need to meet the targeted instance-host ratios with the selected OS-hypervisor combinations." -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:575(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:615(para) -msgid "Security: Ensure that the design can accommodate the regular periodic installation of application security patches while maintaining the required workloads. The frequency of security patches for the proposed OS - hypervisor combination will have an impact on performance and the patch installation process could affect maintenance windows." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:582(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:569(title) +msgid "Availability" msgstr "" #: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:584(para) -msgid "Supported features: Determine which features of OpenStack are required. This will often determine the selection of the OS-hypervisor combination. Certain features are only available with specific OSs or hypervisors. For example, if certain features are not available, the design might need to be modified to meet the user requirements." +msgid "To ensure that access to nodes within the cloud is not interrupted, it is recommended that the network architecture identify any single points of failure and provide some level of redundancy or fault tolerance. With regard to the network infrastructure itself, this often involves use of networking protocols such as LACP, VRRP or others to achieve a highly available network connection. In addition, it is important to consider the networking implications on API availability. In order to ensure that the APIs, and potentially other services in the cloud are highly available, it is recommended to design load balancing solutions within the network architecture to accommodate for these requirements." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:593(para) -msgid "Interoperability: Consideration should be given to the ability of the selected OS-hypervisor combination to interoperate or co-exist with other OS-hypervisors as well as other software solutions in the overall design (if required). Operational troubleshooting tools for one OS-hypervisor combination may differ from the tools used for another OS-hypervisor combination and, as a result, the design will need to address if the two sets of tools need to interoperate." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:603(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:294(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:515(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:386(title) +msgid "Software selection" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:608(para) -msgid "The selection of which OpenStack components are included has a significant impact on the overall design. While there are certain components that will always be present, (Nova and Glance, for example) there are other services that may not be required. As an example, a certain design might not need OpenStack Heat. Omitting Heat would not have a significant impact on the overall design of a cloud; however, if the architecture uses a replacement for OpenStack Swift for its storage component, it could potentially have significant impacts on the rest of the design." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:604(para) +msgid "Software selection for a general purpose OpenStack architecture design needs to include these three areas:" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:618(para) -msgid "The exclusion of certain OpenStack components might also limit or constrain the functionality of other components. If the architecture includes Heat but excludes Ceilometer, then the design will not be able to take advantage of Heat's auto scaling functionality (which relies on information from Ceilometer). It is important to research the component interdependencies in conjunction with the technical requirements before deciding what components need to be included and what components can be dropped from the final architecture." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:608(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:523(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:391(para) +msgid "Operating system (OS) and hypervisor" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:630(title) -msgid "Supplemental components" +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:614(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:435(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:529(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:743(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:397(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:562(title) +msgid "Supplemental software" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:631(para) -msgid "While OpenStack is a fairly complete collection of software projects for building a platform for cloud services, there are invariably additional pieces of software that need to be considered in any given OpenStack design." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:619(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:538(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:403(title) +msgid "Operating system and hypervisor" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:637(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:751(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:480(title) -msgid "Networking software" +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:620(para) +msgid "The selection of operating system (OS) and hypervisor has a tremendous impact on the overall design. Selecting a particular operating system and hypervisor can also directly affect server hardware selection. It is recommended to make sure the storage hardware selection and topology support the selected operating system and hypervisor combination. Finally, it is important to ensure that the networking hardware selection and topology will work with the chosen operating system and hypervisor combination. For example, if the design uses Link Aggregation Control Protocol (LACP), the OS and hypervisor both need to support it." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:638(para) -msgid "OpenStack Neutron provides a wide variety of networking services for instances. There are many additional networking software packages that might be useful to manage the OpenStack components themselves. Some examples include software to provide load balancing, network redundancy protocols, and routing daemons. Some of these software packages are described in more detail in the OpenStack HA Guide (refer to Chapter 8 of the OpenStack High Availability Guide)." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:632(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:554(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:413(para) +msgid "Some areas that could be impacted by the selection of OS and hypervisor include:" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:646(para) -msgid "For a general purpose OpenStack cloud, the OpenStack infrastructure components will need to be highly available. If the design does not include hardware load balancing, networking software packages like HAProxy will need to be included." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:639(para) +msgid "Selecting a commercially supported hypervisor, such as Microsoft Hyper-V, will result in a different cost model rather than community-supported open source hypervisors including KVM, Kinstance or Xen. When comparing open source OS solutions, choosing Ubuntu over Red Hat (or vice versa) will have an impact on cost due to support contracts. On the other hand, business or application requirements may dictate a specific or commercially supported hypervisor." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:653(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:775(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:494(title) -msgid "Management software" +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:651(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:431(term) +msgid "Supportability" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:654(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:776(para) -msgid "The selected supplemental software solution impacts and affects the overall OpenStack cloud design. This includes software for providing clustering, logging, monitoring and alerting." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:653(para) +msgid "Depending on the selected hypervisor, the staff should have the appropriate training and knowledge to support the selected OS and hypervisor combination. If they do not, training will need to be provided which could have a cost impact on the design." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:658(para) -msgid "Inclusion of clustering Software, such as Corosync or Pacemaker, is determined primarily by the availability requirements. Therefore, the impact of including (or not including) these software packages is primarily determined by the availability of the cloud infrastructure and the complexity of supporting the configuration after it is deployed. The OpenStack High Availability Guide provides more details on the installation and configuration of Corosync and Pacemaker, should these packages need to be included in the design." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:662(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:448(term) +msgid "Management tools" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:668(para) -msgid "Requirements for logging, monitoring, and alerting are determined by operational considerations. Each of these sub-categories includes a number of various options. For example, in the logging sub-category one might consider Logstash, Splunk, instanceware Log Insight, or some other log aggregation-consolidation tool. Logs should be stored in a centralized location to make it easier to perform analytics against the data. Log data analytics engines can also provide automation and issue notification by providing a mechanism to both alert and automatically attempt to remediate some of the more commonly known issues." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:664(para) +msgid "The management tools used for Ubuntu and Kinstance differ from the management tools for VMware vSphere. Although both OS and hypervisor combinations are supported by OpenStack, there will be very different impacts to the rest of the design as a result of the selection of one combination versus the other." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:679(para) -msgid "If any of these software packages are required, then the design must account for the additional resource consumption (CPU, RAM, storage, and network bandwidth for a log aggregation solution, for example). Some other potential design impacts include:" +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:674(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:460(term) +msgid "Scale and performance" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:686(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:830(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:529(para) -msgid "OS - Hypervisor combination: Ensure that the selected logging, monitoring, or alerting tools support the proposed OS-hypervisor combination." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:676(para) +msgid "Ensure that selected OS and hypervisor combinations meet the appropriate scale and performance requirements. The chosen architecture will need to meet the targeted instance-host ratios with the selected OS-hypervisor combinations." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:691(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:838(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:534(para) -msgid "Network hardware: The network hardware selection needs to be supported by the logging, monitoring, and alerting software." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:686(para) +msgid "Ensure that the design can accommodate the regular periodic installation of application security patches while maintaining the required workloads. The frequency of security patches for the proposed OS-hypervisor combination will have an impact on performance and the patch installation process could affect maintenance windows." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:698(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:847(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:540(title) -msgid "Database software" +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:696(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:483(term) +msgid "Supported features" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:699(para) -msgid "A large majority of the OpenStack components require access to back-end database services to store state and configuration information. Selection of an appropriate back-end database that will satisfy the availability and fault tolerance requirements of the OpenStack services is required. OpenStack services supports connecting to any database that is supported by the sqlalchemy python drivers, however, most common database deployments make use of mySQL or variations of it. It is recommended that the database which provides back-end service within a general purpose cloud be made highly available when using an available technology which can accomplish that goal. Some of the more common software solutions used include Galera, MariaDB and mySQL with multi-master replication." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:698(para) +msgid "Determine which features of OpenStack are required. This will often determine the selection of the OS-hypervisor combination. Certain features are only available with specific OSs or hypervisors. For example, if certain features are not available, the design might need to be modified to meet the user requirements." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:715(title) -msgid "Addressing performance-sensitive workloads" +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:708(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:495(term) +msgid "Interoperability" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:716(para) -msgid "Although one of the key defining factors for a general purpose OpenStack cloud is that performance is not a determining factor, there may still be some performance-sensitive workloads deployed on the general purpose OpenStack cloud. For design guidance on performance-sensitive workloads, it is recommended to refer to the focused scenarios later in this guide. The resource-focused guides can be used as a supplement to this guide to help with decisions regarding performance-sensitive workloads." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:710(para) +msgid "Consideration should be given to the ability of the selected OS-hypervisor combination to interoperate or co-exist with other OS-hypervisors as well as other software solutions in the overall design (if required). Operational troubleshooting tools for one OS-hypervisor combination may differ from the tools used for another OS-hypervisor combination and, as a result, the design will need to address if the two sets of tools need to interoperate." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:728(title) -msgid "Compute-focused workloads" +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:726(para) +msgid "The selection of which OpenStack components are included has a significant impact on the overall design. While there are certain components that will always be present, (Compute and Image Service, for example) there are other services that may not be required. As an example, a certain design might not need Orchestration. Omitting Orchestration would not have a significant impact on the overall design of a cloud; however, if the architecture uses a replacement for OpenStack Swift for its storage component, it could potentially have significant impacts on the rest of the design." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:729(para) -msgid "In an OpenStack cloud that is compute-focused, there are some design choices that can help accommodate those workloads. Compute-focused workloads are generally those that would place a higher demand on CPU and memory resources with lower priority given to storage and network performance, other than what is required to support the intended compute workloads. For guidance on designing for this type of cloud, please refer to the section on Compute Focused clouds." -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:739(title) -msgid "Network-focused workloads" -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:740(para) -msgid "In a network-focused OpenStack cloud some design choices can improve the performance of these types of workloads. Network-focused workloads have extreme demands on network bandwidth and services that require specialized consideration and planning. For guidance on designing for this type of cloud, please refer to the section on Network-Focused clouds." +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:736(para) +msgid "The exclusion of certain OpenStack components might also limit or constrain the functionality of other components. If the architecture includes Orchestration but excludes Telemetry, then the design will not be able to take advantage of Orchestrations' auto scaling functionality (which relies on information from Telemetry). It is important to research the component interdependencies in conjunction with the technical requirements before deciding what components need to be included and what components can be dropped from the final architecture." msgstr "" #: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:748(title) -msgid "Storage-focused workloads" +msgid "Supplemental components" msgstr "" #: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:749(para) -msgid "Storage focused OpenStack clouds need to be designed to accommodate workloads that have extreme demands on either object or block storage services that require specialized consideration and planning. For guidance on designing for this type of cloud, please refer to the section on Storage-Focused clouds." +msgid "While OpenStack is a fairly complete collection of software projects for building a platform for cloud services, there are invariably additional pieces of software that need to be considered in any given OpenStack design." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:755(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:751(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:568(title) +msgid "Networking software" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:756(para) +msgid "OpenStack Networking provides a wide variety of networking services for instances. There are many additional networking software packages that might be useful to manage the OpenStack components themselves. Some examples include software to provide load balancing, network redundancy protocols, and routing daemons. Some of these software packages are described in more detail in the <citetitle>OpenStack High Availability Guide</citetitle> (refer to the <link href=\"http://docs.openstack.org/high-availability-guide/content/ch-network.html\">Network controller cluster stack chapter</link> of the OpenStack High Availability Guide)." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:767(para) +msgid "For a general purpose OpenStack cloud, the OpenStack infrastructure components will need to be highly available. If the design does not include hardware load balancing, networking software packages like HAProxy will need to be included." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:774(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:775(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:585(title) +msgid "Management software" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:775(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:776(para) +msgid "The selected supplemental software solution impacts and affects the overall OpenStack cloud design. This includes software for providing clustering, logging, monitoring and alerting." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:779(para) +msgid "Inclusion of clustering software, such as Corosync or Pacemaker, is determined primarily by the availability requirements. Therefore, the impact of including (or not including) these software packages is primarily determined by the availability of the cloud infrastructure and the complexity of supporting the configuration after it is deployed. The <link href=\"http://docs.openstack.org/high-availability-guide/\"><citetitle>OpenStack High Availability Guide</citetitle></link> provides more details on the installation and configuration of Corosync and Pacemaker, should these packages need to be included in the design." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:790(para) +msgid "Requirements for logging, monitoring, and alerting are determined by operational considerations. Each of these sub-categories includes a number of various options. For example, in the logging sub-category one might consider Logstash, Splunk, instanceware Log Insight, or some other log aggregation-consolidation tool. Logs should be stored in a centralized location to make it easier to perform analytics against the data. Log data analytics engines can also provide automation and issue notification by providing a mechanism to both alert and automatically attempt to remediate some of the more commonly known issues." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:801(para) +msgid "If any of these software packages are required, then the design must account for the additional resource consumption (CPU, RAM, storage, and network bandwidth for a log aggregation solution, for example). Some other potential design impacts include:" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:808(para) +msgid "OS-hypervisor combination: Ensure that the selected logging, monitoring, or alerting tools support the proposed OS-hypervisor combination." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:813(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:838(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:625(para) +msgid "Network hardware: The network hardware selection needs to be supported by the logging, monitoring, and alerting software." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:820(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:847(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:631(title) +msgid "Database software" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:821(para) +msgid "A large majority of the OpenStack components require access to back-end database services to store state and configuration information. Selection of an appropriate back-end database that will satisfy the availability and fault tolerance requirements of the OpenStack services is required. OpenStack services supports connecting to any database that is supported by the SQLAlchemy python drivers, however, most common database deployments make use of MySQL or variations of it. It is recommended that the database which provides back-end service within a general purpose cloud be made highly available when using an available technology which can accomplish that goal. Some of the more common software solutions used include Galera, MariaDB and MySQL with multi-master replication." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:837(title) +msgid "Addressing performance-sensitive workloads" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:838(para) +msgid "Although one of the key defining factors for a general purpose OpenStack cloud is that performance is not a determining factor, there may still be some performance-sensitive workloads deployed on the general purpose OpenStack cloud. For design guidance on performance-sensitive workloads, it is recommended to refer to the focused scenarios later in this guide. The resource-focused guides can be used as a supplement to this guide to help with decisions regarding performance-sensitive workloads." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:850(title) +msgid "Compute-focused workloads" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:851(para) +msgid "In an OpenStack cloud that is compute-focused, there are some design choices that can help accommodate those workloads. Compute-focused workloads are generally those that would place a higher demand on CPU and memory resources with lower priority given to storage and network performance, other than what is required to support the intended compute workloads. For guidance on designing for this type of cloud, please refer to <xref linkend=\"compute_focus\"/>." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:861(title) +msgid "Network-focused workloads" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:862(para) +msgid "In a network-focused OpenStack cloud some design choices can improve the performance of these types of workloads. Network-focused workloads have extreme demands on network bandwidth and services that require specialized consideration and planning. For guidance on designing for this type of cloud, please refer to <xref linkend=\"network_focus\"/>." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:870(title) +msgid "Storage-focused workloads" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:871(para) +msgid "Storage focused OpenStack clouds need to be designed to accommodate workloads that have extreme demands on either object or block storage services that require specialized consideration and planning. For guidance on designing for this type of cloud, please refer to <xref linkend=\"storage_focus\"/>." msgstr "" #: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:9(para) @@ -2213,60 +2313,84 @@ msgstr "" msgid "These user considerations are written from the perspective of the organization that is building the cloud, not from the perspective of the end-users who will consume cloud services provided by this design." msgstr "" -#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:23(para) -msgid "Cost: Financial factors are a primary concern for any organization. Since general purpose clouds are considered the baseline from which all other cloud architecture environments derive, cost will commonly be an important criteria. This type of cloud, however, does not always provide the most cost-effective environment for a specialized application or situation. Unless razor-thin margins and costs have been mandated as a critical factor, cost should not be the sole consideration when choosing or designing a general purpose architecture." +#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:26(para) +msgid "Financial factors are a primary concern for any organization. Since general purpose clouds are considered the baseline from which all other cloud architecture environments derive, cost will commonly be an important criteria. This type of cloud, however, does not always provide the most cost-effective environment for a specialized application or situation. Unless razor-thin margins and costs have been mandated as a critical factor, cost should not be the sole consideration when choosing or designing a general purpose architecture." msgstr "" -#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:36(para) -msgid "Time to market: Another common business factor in building a general purpose cloud is the ability to deliver a service or product more quickly and flexibly. In the modern hyper-fast business world, being able to deliver a product in six months instead of two years is often a major driving force behind the decision to build a general purpose cloud. General purpose clouds allow users to self-provision and gain access to compute, network, and storage resources on-demand thus decreasing time to market. It may potentially make more sense to build a general purpose PoC as opposed to waiting to finalize the ultimate use case for the system. The tradeoff with taking this approach is the risk that the general purpose cloud is not optimized for the actual final workloads. The final decision on which approach to take will be dependent on the specifics of the business objectives and time frame for the project." +#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:40(term) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:31(term) +msgid "Time to market" msgstr "" -#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:56(para) -msgid "Revenue opportunity: The revenue opportunity for a given 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 plenty of other reasons that might make the general purpose cloud the right choice. 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." +#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:42(para) +msgid "Another common business factor in building a general purpose cloud is the ability to deliver a service or product more quickly and flexibly. In the modern hyper-fast business world, being able to deliver a product in six months instead of two years is often a major driving force behind the decision to build a general purpose cloud. General purpose clouds allow users to self-provision and gain access to compute, network, and storage resources on-demand thus decreasing time to market. It may potentially make more sense to build a general purpose PoC as opposed to waiting to finalize the ultimate use case for the system. The tradeoff with taking this approach is the risk that the general purpose cloud is not optimized for the actual final workloads. The final decision on which approach to take will be dependent on the specifics of the business objectives and time frame for the project." msgstr "" -#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:77(title) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:40(title) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:67(title) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:35(title) +#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:63(term) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:40(term) +msgid "Revenue opportunity" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:65(para) +msgid "The revenue opportunity for a given 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 plenty of other reasons that might make the general purpose cloud the right choice. 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:87(title) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:54(title) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:67(title) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:35(title) msgid "Legal requirements" msgstr "" -#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:97(para) +#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:107(para) msgid "Data compliance policies governing certain types of information need to reside in certain locations due to regular issues - and more important cannot reside in other locations for the same reason." msgstr "" -#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:103(para) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:66(para) ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:42(para) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:61(para) -msgid "Examples of such legal frameworks include the data protection framework of the European Union (http://ec.europa.eu/justice/data-protection/ ) and the requirements of the Financial Industry Regulatory Authority (http://www.finra.org/Industry/Regulation/FINRARules/ ) in the United States. Consult a local regulatory body for more information." +#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:113(para) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:80(para) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:61(para) +msgid "Examples of such legal frameworks include the <link href=\"http://ec.europa.eu/justice/data-protection/\">data protection framework</link> of the European Union and the requirements of the <link href=\"http://www.finra.org/Industry/Regulation/FINRARules/\">Financial Industry Regulatory Authority</link> in the United States. Consult a local regulatory body for more information." msgstr "" -#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:111(title) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:69(title) +#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:124(title) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:72(title) msgid "Technical requirements" msgstr "" -#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:112(para) +#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:125(para) msgid "Technical cloud architecture requirements should be weighted against the business requirements." msgstr "" -#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:116(para) -msgid "Performance: 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:124(para) -msgid "No predefined usage model: 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:132(para) -msgid "On-demand and self-service application: 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." +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:144(para) -msgid "Public cloud: For a company interested in building a commercial public cloud offering based on OpenStack, the general purpose architecture model might be the best choice because the designers are not going to know the purposes or workloads for which the end users will use the cloud." +#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:141(term) +msgid "No predefined usage model" msgstr "" -#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:152(para) -msgid "Internal consumption (private) cloud: Organizations need to determine if it makes the most sense to create their own clouds internally. The main advantage of a private cloud is that it allows the organization to maintain complete control over all the architecture and the cloud components. One caution is to think about the possibility that 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. 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." +#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:143(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:152(term) +msgid "On-demand and self-service application" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:154(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:167(term) +msgid "Public cloud" msgstr "" #: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:169(para) -msgid "Security: Security should be implemented according to asset, threat, and vulnerability risk assessment matrices. For cloud domains that require increased computer security, network security, or information security, general purpose cloud is not considered an appropriate choice." +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 because the designers are not 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:178(term) +msgid "Internal consumption (private) cloud" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:180(para) +msgid "Organizations need to determine if it makes the most sense to create their own clouds internally. The main advantage of a private cloud is that it allows the organization to maintain complete control over all the architecture and the cloud components. One caution is to think about the possibility that 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. 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:201(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, general purpose cloud is not considered an appropriate choice." msgstr "" #: ./doc/arch-design/generalpurpose/section_introduction_generalpurpose.xml:8(para) @@ -2390,7 +2514,7 @@ msgid "Insufficient disk capacity could also have a negative effect on overall p msgstr "" #: ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:144(para) -msgid "For a deeper discussion on many of these topics, refer to the OpenStack Operations Guide at http://docs.openstack.org/ops." +msgid "For a deeper discussion on many of these topics, refer to the <link href=\"http://docs.openstack.org/ops\"><citetitle>OpenStack Operations Guide</citetitle></link>." msgstr "" #. When image changes, this message will be marked fuzzy or untranslated for you. @@ -2459,404 +2583,400 @@ msgstr "" msgid "OpenStack Networking can be used to control hardware load balancers through the use of plug-ins and the Networking API. This would allow a user to control hardware load balance pools and instances as members in these pools, but their use in production environments must be carefully weighed against current stability." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:9(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:13(para) msgid "When designing a general purpose cloud, there is an implied requirement to design for all of the base services generally associated with providing Infrastructure-as-a-Service: compute, network and storage. Each of these services have different resource requirements. As a result, it is important to make design decisions relating directly to the service currently under design, while providing a balanced infrastructure that provides for all services." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:17(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:21(para) msgid "When designing an OpenStack cloud as a general purpose cloud, the hardware selection process can be lengthy and involved due to the sheer mass of services which need to be designed and the unique characteristics and requirements of each service within the cloud. Hardware designs need to be generated for each type of resource pool; specifically, compute, network, and storage. In addition to the hardware designs, which affect the resource nodes themselves, there are also a number of additional hardware decisions to be made related 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:30(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:34(title) msgid "Designing compute resources" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:31(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:35(para) msgid "It is recommended to design compute resources as pools of resources which will be addressed on-demand. When designing compute resource pools, a number of factors 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, it is necessary to decide whether compute resources will be provided in a single pool or in multiple pools." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:39(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:43(para) msgid "To design for the best use of available resources by applications running in the cloud, it is recommended to design more than one compute resource pool. Each independent resource pool should be designed to provide service for specific flavors of instances or groupings of flavors. For the purpose of this book, \"instance\" refers to a virtual machines and the operating system running on the virtual machine. Designing multiple resource pools 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 available hardware. This is commonly referred to as bin packing." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:51(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:55(para) msgid "Using a consistent hardware design among the nodes that are placed within a resource pool also helps support bin packing. Hardware nodes selected for being a part of a compute resource pool should share a common processor, memory, and storage layout. By choosing a common hardware design, it becomes easier to deploy, support and maintain those nodes throughout their life cycle in the cloud." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:58(para) -msgid "OpenStack provides the ability to configure overcommit ratio--the ratio of virtual resources available for allocation to physical resources present--for both CPU and memory. The default CPU overcommit ratio is 16:1 and the default memory overcommit ratio is 1.5:1. Determine the tuning of the overcommit ratios for both of these options during the design phase, as this has a direct impact on the hardware layout of your compute nodes." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:62(para) +msgid "OpenStack provides the ability to configure overcommit ratiothe ratio of virtual resources available for allocation to physical resources presentfor both CPU and memory. The default CPU overcommit ratio is 16:1 and the default memory overcommit ratio is 1.5:1. Determine the tuning of the overcommit ratios for both of these options during the design phase, as this has a direct impact on the hardware layout of your compute nodes." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:66(para) -msgid "As an example, consider that a m1.small instance uses 1 vCPU, 20 GB of ephemeral storage and 2,048 MB 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 x 10 x 2 x 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 x 2,048 MB % 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 "As an example, consider that 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 x 10 x 2 x 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 x 2,048 MB % 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:80(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:84(para) msgid "Processor selection is an extremely important consideration in hardware design, especially when comparing the features and performance characteristics of different processors. Some newly released processors include features specific to virtualized compute hosts including hardware assisted virtualization and technology related to memory paging (also known as EPT shadowing). These features have a tremendous positive impact on the performance of virtual machines running in the cloud." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:89(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:93(para) msgid "In addition to the impact on actual compute services, it is also important to consider the compute requirements of resource nodes within the cloud. Resource nodes refers to non-hypervisor nodes providing controller, object storage, block storage, or networking services in the cloud. 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. It is important to ensure sufficient compute capacity and memory is planned on resource nodes." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:98(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:102(para) msgid "Workload profiles are unpredictable in a general purpose cloud, so it may be difficult to design for every specific use case in mind. Additional compute resource pools can be added to the cloud at a later time, so this unpredictability should not be a problem. In some cases, the demand on certain instance types or flavors may not justify an individual hardware design. In either of these cases, start by providing hardware designs which will be capable of servicing the most common instance requests first, looking to add additional hardware designs to the overall architecture in the form of new hardware node designs and resource pools as they become justified at a later time." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:111(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:115(title) msgid "Designing network resources" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:112(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:116(para) msgid "An OpenStack cloud traditionally has multiple network segments, each of which provides access to resources within the cloud to both operators and tenants. In addition, the network services themselves also require network communication paths which should also be separated from the other networks. When designing network services for a general purpose cloud, it is recommended to plan for either a physical or logical separation of network segments which will be used by operators and tenants. It is further suggested to create an additional network segment for access to internal services such as the message bus and database used by the various cloud services. Segregating these services onto separate networks helps to protect sensitive data and also protects against unauthorized access to services." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:126(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:130(para) msgid "Based on the requirements of instances being serviced in the cloud, the next design choice which will affect your design is the choice of network service which will be used to service instances in the cloud. The choice between nova-network, as a part of OpenStack Compute Service, and Neutron, the OpenStack Networking Service, has tremendous implications and will have a huge impact on the architecture and design of the cloud network infrastructure." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:134(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:138(para) msgid "The nova-network service is primarily a layer 2 networking service which has two main modes in which it will function. The difference between the two modes in nova-network pertain to whether or not nova-network uses VLANs. When using nova-network in a flat network mode, all network hardware nodes and devices throughout the cloud are connected to a single layer 2 network segment which provides access to application data." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:142(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:146(para) msgid "When the network devices in the cloud support segmentation using VLANs, nova-network 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, it is especially recommended to use nova-network with VLANs, and not in flat network mode." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:153(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:157(para) msgid "Another consideration regarding network is the fact that nova-network 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:160(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:164(para) msgid "The OpenStack Networking Service 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:169(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:173(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 generally referred to as a public network. In most cases, the controller nodes and swift proxies within the cloud will be the only devices necessary to connect to this network segment. In some cases, this network might also be serviced by hardware load balancers and other network devices." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:177(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:181(para) msgid "The next segment is used by cloud administrators to manage hardware resources and is also used by configuration management tools when deploying software and services onto new hardware. In some cases, this network segment might also be used for internal services, including the message bus and database services, to communicate with each other. Due to the highly secure nature of this network segment, it may be desirable to secure this network from unauthorized access. This network will likely need to communicate with every hardware node within the cloud." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:187(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:191(para) msgid "The last network segment is used by applications and consumers to provide access to the physical network and also for users accessing applications running within the cloud. This network is generally segregated from the one used to access the cloud APIs and is not capable of communicating directly with the hardware resources in the cloud. Compute resource nodes will need to communicate on this network segment, as will any network gateway services which allow application data to access the physical network outside of the cloud." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:198(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:202(title) msgid "Designing storage resources" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:199(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:203(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:206(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:210(title) msgid "Designing OpenStack Object Storage" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:207(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:211(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:216(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:220(para) msgid "It is not recommended to invest 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:222(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:226(para) msgid "A great benefit of OpenStack Object Storage is the ability to mix and match drives by utilizing weighting within the swift ring. When designing your swift storage cluster, it is recommended to make 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 it is recommended to maximize the amount of storage per rack unit at the best cost per terabyte. Furthermore, the use of RAID controllers is not recommended in an object storage node." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:232(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:236(para) msgid "In order to achieve this durability and availability of data stored as objects, it is important to design object storage resource pools in a way that provides the suggested availability that the service can provide. Beyond designing at the hardware node level, it is important to consider rack-level and zone-level designs to accommodate the number of replicas configured to be stored in the Object Storage service (the default number of replicas is three). 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:243(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:247(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:249(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:253(title) msgid "Designing OpenStack Block Storage" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:250(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:254(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. In a general purpose cloud these use patterns are often unknown. It is recommended to design block storage pools so that tenants can choose the appropriate storage solution 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:261(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:265(para) msgid "In addition to directly attached storage populated in servers, block storage can also take 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). While a general purpose cloud would likely use directly attached storage in the majority of block storage nodes, it may also be 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:272(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:276(para) msgid "The determination to use a RAID controller card in block storage nodes is impacted primarily by the redundancy and availability requirements of the application. Applications which have a higher demand on input-output per second (IOPS) will influence both the choice to use a RAID controller and the level of RAID configured on the volume. Where performance is a consideration, it is suggested to make use of higher performing RAID volumes. In contrast, where redundancy of block storage volumes is more important it is recommended to make 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:291(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:295(para) msgid "The software selection process can play a large role in the architecture of a general purpose cloud. Choice of operating system, selection of OpenStack software components, choice of hypervisor and selection of supplemental software will have a large impact on the design of the cloud." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:296(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:300(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 Ubuntu, Red Hat Enterprise Linux (RHEL), CentOS, and SUSE Linux Enterprise Server (SLES). \"Native support\" in this context means that the distribution provides distribution-native packages by which to install OpenStack in their repositories. Note that \"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, the reality is that 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:311(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:315(para) msgid "OS selection also directly influences hypervisor selection. A cloud architect who selects Ubuntu or RHEL has some flexibility in hypervisor; KVM, Xen, and LXC are supported virtualization methods available under OpenStack Compute (Nova) on these Linux distributions. A cloud architect who selects Hyper-V, on the other hand, is limited to Windows Server. 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:320(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:324(para) msgid "The primary factors that play into OS/hypervisor selection include:" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:324(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:328(para) msgid "User requirements: 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:329(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:333(para) msgid "Support: The selected OS/hypervisor combination needs to be supported by OpenStack." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:333(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:337(para) msgid "Interoperability: 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:340(title) ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:30(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:344(title) ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:30(title) msgid "Hypervisor" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:341(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:345(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:346(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:350(para) msgid "KVM (and Qemu)" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:349(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:353(para) msgid "XCP/XenServer" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:352(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:356(para) msgid "vSphere (vCenter and ESXi)" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:355(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:359(para) msgid "Hyper-V" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:358(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:362(para) msgid "LXC" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:361(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:365(para) msgid "Docker" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:364(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:368(para) msgid "Bare-metal" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:367(para) -msgid "A complete list of supported hypervisors and their capabilities can be found at https://wiki.openstack.org/wiki/HypervisorSupportMatrix." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:371(para) +msgid "A complete list of supported hypervisors and their capabilities can be found at <link href=\"https://wiki.openstack.org/wiki/HypervisorSupportMatrix\">https://wiki.openstack.org/wiki/HypervisorSupportMatrix</link>." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:370(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:375(para) msgid "General purpose clouds should make use of hypervisors that support the most general purpose use cases, such as KVM and Xen. More specific hypervisors should then 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:377(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:382(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 might 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:392(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:397(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:400(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:405(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:406(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:366(para) -msgid "OpenStack Compute (Nova)" +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:411(para) +msgid "OpenStack Compute (nova)" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:409(para) -msgid "OpenStack Networking (Neutron)" +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:414(para) +msgid "OpenStack Networking (neutron)" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:412(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:369(para) -msgid "OpenStack Image Service (Glance)" +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:417(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:546(para) +msgid "OpenStack Image Service (glance)" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:415(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:372(para) -msgid "OpenStack Identity Service (Keystone)" +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:420(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:530(para) +msgid "OpenStack Identity (keystone)" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:418(para) -msgid "OpenStack Dashboard (Horizon)" +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:423(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:533(para) +msgid "OpenStack dashboard (horizon)" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:421(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:390(para) -msgid "OpenStack Telemetry (Ceilometer)" +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:426(para) +msgid "Telemetry module (ceilometer)" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:424(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:429(para) msgid "A general purpose cloud may also include OpenStack Object Storage (Swift). OpenStack Block Storage (Cinder) may be selected to provide persistent storage to applications and instances although, depending on the use case, this could be optional." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:431(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:436(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:446(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:451(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. This 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:459(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:464(para) msgid "Memcached is a distributed memory object caching system, and Redis is a key-value store. Both are usually 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:470(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:475(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:476(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:481(title) msgid "Controller infrastructure" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:477(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:482(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 typically 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:492(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:497(para) msgid "Performance of the controller services is not just 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:503(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:508(title) msgid "Network performance" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:504(para) -msgid "In a general purpose OpenStack cloud, the requirements of the network help determine its performance capabilities. For example, small deployments may employ 1 Gibabit Ethernet (GbE) networking, whereas larger installations serving multiple departments or many users would be better architected with 10 GbE 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. 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 10 GbE capability to replicate its data or, in some cases, the design may incorporate link aggregation for greater throughput." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:509(para) +msgid "In a general purpose OpenStack cloud, the requirements of the network help determine its 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. 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:520(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:525(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:528(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:533(title) msgid "Compute host" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:529(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:534(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:543(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:548(title) msgid "Storage performance" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:544(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:549(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, use 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:555(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:560(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 typically 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:564(title) -msgid "Availability" -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:565(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:570(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:574(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:579(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:579(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:584(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:588(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:593(para) msgid "Care must be taken when deciding network functionality. Currently, OpenStack supports both the legacy Nova-network system and the newer, extensible OpenStack Networking. Both have their pros and cons when it comes to providing highly available access. Nova-network, 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 Nova network’s Multi-Host functionality restricts failure domains to the host running that instance." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:599(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:604(para) msgid "On the other hand, when using OpenStack Networking, the OpenStack controller servers or separate OpenStack Networking hosts handle routing. For a deployment that requires features available in only OpenStack 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 OpenStack 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:611(para) -msgid "OpenStack Networking (Neutron) and Nova Network both have their advantages and disadvantages. They are both valid and supported options that fit different use cases as described in the following table." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:616(para) +msgid "OpenStack Networking (neutron) and nova-network both have their advantages and disadvantages. They are both valid and supported options that fit different use cases as described in the following table." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:615(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:620(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:624(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:629(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:636(para) -msgid "For more information on HA in OpenStack, see the OpenStack High Availability Guide found at http://docs.openstack.org/high-availability-guide." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:641(para) +msgid "For more information on HA in OpenStack, see the <link href=\"http://docs.openstack.org/high-availability-guide\"><citetitle>OpenStack High Availability Guide</citetitle></link>." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:641(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:271(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:649(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:272(para) msgid "A security domain comprises users, applications, servers or networks that share common trust requirements and expectations within a system. Typically they have the same authentication and authorization requirements and users." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:645(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:276(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:653(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:277(para) msgid "These security domains are:" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:648(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:279(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:116(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:656(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:280(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:116(para) msgid "Public" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:651(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:282(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:119(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:659(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:283(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:119(para) msgid "Guest" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:657(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:288(para) ./doc/arch-design/hybrid/section_architecture_hybrid.xml:158(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:125(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:665(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:289(para) ./doc/arch-design/hybrid/section_architecture_hybrid.xml:158(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:125(para) msgid "Data" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:660(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:668(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:670(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:678(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:674(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:682(para) msgid "Typically used for compute instance-to-instance traffic, the guest security domain handles compute data generated by instances on the cloud but not services that support the operation of the cloud, such as API calls. Public cloud providers and private cloud providers who do not have stringent controls on instance use or who allow unrestricted internet access to instances should consider this domain to be untrusted. Private cloud providers may want to consider this network as internal and therefore trusted only if they have controls in place to assert that they trust instances and all their tenants." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:685(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:317(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:693(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:318(para) msgid "The management security domain is where services interact. Sometimes referred to as the \"control plane\", the networks in this domain transport confidential data such as configuration parameters, user names, and passwords. In most deployments this domain is considered trusted." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:690(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:698(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:697(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:705(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:711(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:719(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:717(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:725(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:722(para) -msgid "For more information OpenStack Security, see the OpenStack Security Guide, at http://docs.openstack.org/security-guide/." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:730(para) +msgid "For more information OpenStack Security, see the <link href=\"http://docs.openstack.org/security-guide/\"><citetitle>OpenStack Security Guide</citetitle></link>" msgstr "" #: ./doc/arch-design/introduction/section_intended_audience.xml:7(title) @@ -2953,183 +3073,199 @@ msgstr "" #. When image changes, this message will be marked fuzzy or untranslated for you. #. It doesn't matter what you translate it to: it's not used at all. -#: ./doc/arch-design/introduction/section_methodology.xml:17(None) +#: ./doc/arch-design/introduction/section_methodology.xml:21(None) msgid "@@image: '../images/Methodology.png'; md5=6b187c6b7bf846d86f60b062461e7bdf" msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:7(title) +#: ./doc/arch-design/introduction/section_methodology.xml:11(title) msgid "Methodology" msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:8(para) +#: ./doc/arch-design/introduction/section_methodology.xml:12(para) msgid "The magic of the cloud is that it can do anything. It is both robust and flexible, the best of both worlds. Yes, the cloud is highly flexible and it can do almost anything, but to get the most out of a cloud investment, it is important to define how the cloud will be used by creating and testing use cases. This is the chapter that describes the thought process behind how to design a cloud architecture that best suits the intended use." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:20(para) +#: ./doc/arch-design/introduction/section_methodology.xml:24(para) msgid "The diagram shows at a very abstract level the process for capturing requirements and building use cases. Once a set of use cases has been defined, it can then be used to design the cloud architecture." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:23(para) +#: ./doc/arch-design/introduction/section_methodology.xml:27(para) msgid "Use case planning can seem counter-intuitive. After all, it takes about five minutes to sign up for a server with Amazon. Amazon does not know in advance what any given user is planning on doing with it, right? Wrong. Amazon’s product management department spends plenty of time figuring out exactly what would be attractive to their typical customer and honing the service to deliver it. For the enterprise, the planning process is no different, but instead of planning for an external paying customer, for example, the use could be for internal application developers or a web portal. The following is a list of the high level objectives that need to be incorporated into the thinking about creating a use case." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:34(para) +#: ./doc/arch-design/introduction/section_methodology.xml:38(para) msgid "Overall business objectives" msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:37(para) +#: ./doc/arch-design/introduction/section_methodology.xml:41(para) msgid "Develop clear definition of business goals and requirements" msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:41(para) +#: ./doc/arch-design/introduction/section_methodology.xml:45(para) msgid "Increase project support and engagement with business, customers and end users." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:45(para) +#: ./doc/arch-design/introduction/section_methodology.xml:49(para) msgid "Technology" msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:48(para) +#: ./doc/arch-design/introduction/section_methodology.xml:52(para) msgid "Coordinate the OpenStack architecture across the project and leverage OpenStack community efforts more effectively." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:52(para) +#: ./doc/arch-design/introduction/section_methodology.xml:56(para) msgid "Architect for automation as much as possible to speed development and deployment." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:56(para) +#: ./doc/arch-design/introduction/section_methodology.xml:60(para) msgid "Use the appropriate tools for the development effort." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:59(para) +#: ./doc/arch-design/introduction/section_methodology.xml:63(para) msgid "Create better and more test metrics and test harnesses to support continuous and integrated development, test processes and automation." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:64(para) +#: ./doc/arch-design/introduction/section_methodology.xml:68(para) msgid "Organization" msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:67(para) +#: ./doc/arch-design/introduction/section_methodology.xml:71(para) msgid "Better messaging of management support of team efforts" msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:70(para) +#: ./doc/arch-design/introduction/section_methodology.xml:74(para) msgid "Develop better cultural understanding of Open Source, cloud architectures, Agile methodologies, continuous development, test and integration, overall development concepts in general" msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:75(para) +#: ./doc/arch-design/introduction/section_methodology.xml:79(para) msgid "As an example of how this works, consider a business goal of using the cloud for the company’s E-commerce website. This goal means planning for applications that will support thousands of sessions per second, variable workloads, and lots of complex and changing data. By identifying the key metrics, such as number of concurrent transactions per second, size of database, and so on, it is possible to then build a method for testing the assumptions." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:82(para) -msgid "Develop functional user scenarios: Develop functional user scenarios that can be used to develop test cases that can be used to measure overall project trajectory. If the organization is not ready to commit to an application or applications that can be used to develop user requirements, it needs to create requirements to build valid test harnesses and develop usable metrics. Once the metrics are established, as requirements change, it is easier to respond to the changes quickly without having to worry overly much about setting the exact requirements in advance. Think of this as creating ways to configure the system, rather than redesigning it every time there is a requirements change." +#: ./doc/arch-design/introduction/section_methodology.xml:87(title) +msgid "Develop functional user scenarios" msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:92(para) -msgid "Limit cloud feature set: Create requirements that address the pain points, but do not recreate the entire OpenStack tool suite. The requirement to build OpenStack, only better, is self-defeating. It is important to limit scope creep by concentrating on developing a platform that will address tool limitations for the requirements, but not recreating the entire suite of tools. Work with technical product owners to establish critical features that are needed for a successful cloud deployment." +#: ./doc/arch-design/introduction/section_methodology.xml:88(para) +msgid "Develop functional user scenarios that can be used to develop test cases that can be used to measure overall project trajectory. If the organization is not ready to commit to an application or applications that can be used to develop user requirements, it needs to create requirements to build valid test harnesses and develop usable metrics. Once the metrics are established, as requirements change, it is easier to respond to the changes quickly without having to worry overly much about setting the exact requirements in advance. Think of this as creating ways to configure the system, rather than redesigning it every time there is a requirements change." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:101(title) +#: ./doc/arch-design/introduction/section_methodology.xml:104(title) +msgid "Limit cloud feature set" +msgstr "" + +#: ./doc/arch-design/introduction/section_methodology.xml:105(para) +msgid "Create requirements that address the pain points, but do not recreate the entire OpenStack tool suite. The requirement to build OpenStack, only better, is self-defeating. It is important to limit scope creep by concentrating on developing a platform that will address tool limitations for the requirements, but not recreating the entire suite of tools. Work with technical product owners to establish critical features that are needed for a successful cloud deployment." +msgstr "" + +#: ./doc/arch-design/introduction/section_methodology.xml:118(title) msgid "Application cloud readiness" msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:102(para) +#: ./doc/arch-design/introduction/section_methodology.xml:119(para) msgid "Although the cloud is designed to make things easier, it is important to realize that \"using cloud\" is more than just firing up an instance and dropping an application on it. The \"lift and shift\" approach works in certain situations, but there is a fundamental difference between clouds and traditional bare-metal-based environments, or even traditional virtualized environments." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:108(para) +#: ./doc/arch-design/introduction/section_methodology.xml:125(para) msgid "In traditional environments, with traditional enterprise applications, the applications and the servers that run on them are \"pets\". They're lovingly crafted and cared for, the servers have names like Gandalf or Tardis, and if they get sick, someone nurses them back to health. All of this is designed so that the application does not experience an outage." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:114(para) +#: ./doc/arch-design/introduction/section_methodology.xml:131(para) msgid "In cloud environments, on the other hand, servers are more like cattle. There are thousands of them, they get names like NY-1138-Q, and if they get sick, they get put down and a sysadmin installs another one. Traditional applications that are unprepared for this kind of environment, naturally will suffer outages, lost data, or worse." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:120(para) +#: ./doc/arch-design/introduction/section_methodology.xml:137(para) msgid "There are other reasons to design applications with cloud in mind. Some are defensive, such as the fact that applications cannot be certain of exactly where or on what hardware they will be launched, they need to be flexible, or at least adaptable. Others are proactive. For example, one of the advantages of using the cloud is scalability, so applications need to be designed in such a way that they t can take advantage of those and other opportunities." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:129(title) +#: ./doc/arch-design/introduction/section_methodology.xml:146(title) msgid "Determining whether an application is cloud-ready" msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:130(para) +#: ./doc/arch-design/introduction/section_methodology.xml:147(para) msgid "There are several factors to take into consideration when looking at whether an application is a good fit for the cloud." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:132(para) -msgid "Structure: A large, monolithic, single-tiered legacy application typically isn't a good fit for the cloud. Efficiencies are gained when load can be spread over several instances, so that a failure in one part of the system can be mitigated without affecting other parts of the system, or so that scaling can take place where the app needs it." +#: ./doc/arch-design/introduction/section_methodology.xml:151(term) +msgid "Structure" msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:138(para) -msgid "Dependencies: Applications that depend on specific hardware -- such as a particular chip set or an external device such as a fingerprint reader -- might not be a good fit for the cloud, unless those dependencies are specifically addressed. Similarly, if an application depends on an operating system or set of libraries that cannot be used in the cloud, or cannot be virtualized, that is a problem." +#: ./doc/arch-design/introduction/section_methodology.xml:153(para) +msgid "A large, monolithic, single-tiered legacy application typically isn't a good fit for the cloud. Efficiencies are gained when load can be spread over several instances, so that a failure in one part of the system can be mitigated without affecting other parts of the system, or so that scaling can take place where the app needs it." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:145(para) -msgid "Connectivity: Self-contained applications or those that depend on resources that are not reachable by the cloud in question, will not run. In some situations, work around these issues with custom network setup, but how well this works depends on the chosen cloud environment." +#: ./doc/arch-design/introduction/section_methodology.xml:168(para) +msgid "Applications that depend on specific hardwaresuch as a particular chip set or an external device such as a fingerprint readermight not be a good fit for the cloud, unless those dependencies are specifically addressed. Similarly, if an application depends on an operating system or set of libraries that cannot be used in the cloud, or cannot be virtualized, that is a problem." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:150(para) -msgid "Durability and Resilience: Despite the existence of SLAs, the one reality of the cloud is that Things Break. Servers go down, network connections are disrupted, other tenants on a server ramp up the load to make the server unusable. Any number of things can happen, and an application that isn't built to withstand this kind of disruption isn't going to work properly." +#: ./doc/arch-design/introduction/section_methodology.xml:184(para) +msgid "Self-contained applications or those that depend on resources that are not reachable by the cloud in question, will not run. In some situations, work around these issues with custom network setup, but how well this works depends on the chosen cloud environment." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:158(title) +#: ./doc/arch-design/introduction/section_methodology.xml:195(term) +msgid "Durability and resilience" +msgstr "" + +#: ./doc/arch-design/introduction/section_methodology.xml:197(para) +msgid "Despite the existence of SLAs, the one reality of the cloud is that Things Break. Servers go down, network connections are disrupted, other tenants on a server ramp up the load to make the server unusable. Any number of things can happen, and an application that isn't built to withstand this kind of disruption isn't going to work properly." +msgstr "" + +#: ./doc/arch-design/introduction/section_methodology.xml:212(title) msgid "Designing for the cloud" msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:159(para) +#: ./doc/arch-design/introduction/section_methodology.xml:213(para) msgid "Here are some guidelines to keep in mind when designing an application for the cloud:" msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:163(para) +#: ./doc/arch-design/introduction/section_methodology.xml:217(para) msgid "Be a pessimist: Assume everything fails and design backwards. Love your chaos monkey." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:167(para) +#: ./doc/arch-design/introduction/section_methodology.xml:221(para) msgid "Put your eggs in multiple baskets: Leverage multiple providers, geographic regions and availability zones to accommodate for local availability issues. Design for portability." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:173(para) +#: ./doc/arch-design/introduction/section_methodology.xml:227(para) msgid "Think efficiency: Inefficient designs will not scale. Efficient designs become cheaper as they scale. Kill off unneeded components or capacity." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:178(para) +#: ./doc/arch-design/introduction/section_methodology.xml:232(para) msgid "Be paranoid: Design for defense in depth and zero tolerance by building in security at every level and between every component. Trust no one." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:183(para) +#: ./doc/arch-design/introduction/section_methodology.xml:237(para) msgid "But not too paranoid: Not every application needs the platinum solution. Architect for different SLA’s, service tiers and security levels." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:188(para) +#: ./doc/arch-design/introduction/section_methodology.xml:242(para) msgid "Manage the data: Data is usually the most inflexible and complex area of a cloud and cloud integration architecture. Don’t short change the effort in analyzing and addressing data needs." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:194(para) +#: ./doc/arch-design/introduction/section_methodology.xml:248(para) msgid "Hands off: Leverage automation to increase consistency and quality and reduce response times." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:198(para) +#: ./doc/arch-design/introduction/section_methodology.xml:252(para) msgid "Divide and conquer: Pursue partitioning and parallel layering wherever possible. Make components as small and portable as possible. Use load balancing between layers." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:204(para) +#: ./doc/arch-design/introduction/section_methodology.xml:258(para) msgid "Think elasticity: Increasing resources should result in a proportional increase in performance and scalability. Decreasing resources should have the opposite effect." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:210(para) +#: ./doc/arch-design/introduction/section_methodology.xml:264(para) msgid "Be dynamic: Enable dynamic configuration changes such as auto scaling, failure recovery and resource discovery to adapt to changing environments, faults and workload volumes." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:216(para) +#: ./doc/arch-design/introduction/section_methodology.xml:270(para) msgid "Stay close: Reduce latency by moving highly interactive components and data near each other." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:220(para) +#: ./doc/arch-design/introduction/section_methodology.xml:274(para) msgid "Keep it loose: Loose coupling, service interfaces, separation of concerns, abstraction and well defined API’s deliver flexibility." msgstr "" -#: ./doc/arch-design/introduction/section_methodology.xml:225(para) +#: ./doc/arch-design/introduction/section_methodology.xml:279(para) msgid "Be cost aware: Autoscaling, data transmission, virtual software licenses, reserved instances, and so on can rapidly increase monthly usage charges. Monitor usage closely." msgstr "" @@ -3142,66 +3278,66 @@ msgid "This book has been organized into various chapters that help define the u msgstr "" #: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:24(para) -msgid "General purpose: A cloud built with common components that should address 80% of common use cases." +msgid "<link linkend=\"generalpurpose\">General purpose</link>: A cloud built with common components that should address 80% of common use cases." msgstr "" -#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:29(para) -msgid "Compute focused: A cloud designed to address compute intensive workloads such as high performance computing (HPC)." +#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:31(para) +msgid "<link linkend=\"compute_focus\">Compute focused</link>: A cloud designed to address compute intensive workloads such as high performance computing (HPC)." msgstr "" -#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:34(para) -msgid "Storage focused: A cloud focused on storage intensive workloads such as data analytics with parallel file systems." +#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:38(para) +msgid "<link linkend=\"storage_focus\">Storage focused</link>: A cloud focused on storage intensive workloads such as data analytics with parallel file systems." msgstr "" -#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:39(para) -msgid "Network focused: A cloud depending on high performance and reliable networking, such as a content delivery network (CDN)." +#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:45(para) +msgid "<link linkend=\"network_focus\">Network focused</link>: A cloud depending on high performance and reliable networking, such as a content delivery network (CDN)." msgstr "" -#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:44(para) -msgid "Multi-site: A cloud built with multiple sites available for application deployments for geographical, reliability or data locality reasons." +#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:53(para) +msgid "<link linkend=\"multi_site\">Multi-site</link>: A cloud built with multiple sites available for application deployments for geographical, reliability or data locality reasons." msgstr "" -#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:50(para) -msgid "Hybrid cloud: An architecture where multiple disparate clouds are connected either for failover, hybrid cloud bursting, or availability." +#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:61(para) +msgid "<link linkend=\"hybrid\">Hybrid cloud</link>: An architecture where multiple disparate clouds are connected either for failover, hybrid cloud bursting, or availability." msgstr "" -#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:55(para) -msgid "Massively Scalable: An architecture that is intended for cloud service providers or other extremely large installations." +#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:69(para) +msgid "<link linkend=\"massively_scalable\">Massively scalable</link>: An architecture that is intended for cloud service providers or other extremely large installations." msgstr "" -#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:60(para) -msgid "A section titled Specialized Use Cases provides information on architectures that have not previously been covered in the defined use cases." +#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:77(para) +msgid "A chapter titled <link linkend=\"specialized\">Specialized cases</link> provides information on architectures that have not previously been covered in the defined use cases." msgstr "" -#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:63(para) +#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:82(para) msgid "Each chapter in the guide is then further broken down into the following sections:" msgstr "" -#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:67(para) +#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:86(para) msgid "Introduction: Provides an overview of the architectural use case." msgstr "" -#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:71(para) +#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:90(para) msgid "User requirements: Defines the set of user considerations that typically come into play for that use case." msgstr "" -#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:76(para) +#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:95(para) msgid "Technical considerations: Covers the technical issues that must be accounted when dealing with this use case." msgstr "" -#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:81(para) +#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:100(para) msgid "Operational considerations: Covers the ongoing operational tasks associated with this use case and architecture." msgstr "" -#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:86(para) +#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:105(para) msgid "Architecture: Covers the overall architecture associated with the use case." msgstr "" -#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:90(para) +#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:109(para) msgid "Prescriptive examples: Presents one or more scenarios where this architecture could be deployed." msgstr "" -#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:95(para) +#: ./doc/arch-design/introduction/section_how_this_book_is_organized.xml:114(para) msgid "A Glossary covers the terms and phrases used in the book." msgstr "" @@ -3313,51 +3449,59 @@ msgstr "" msgid "Another option is to assess the average workloads and increase the number of instances that can run within the compute environment by adjusting the overcommit ratio. While only appropriate in some environments, it's important to remember that changing the CPU overcommit ratio can have a detrimental effect and cause a potential increase in noisy neighbor. The added risk of increasing the overcommit ratio is more instances will fail when a compute host fails. In a compute-focused OpenStack design architecture, increasing the CPU overcommit ratio increases the potential for noisy neighbor issues and is not recommended." msgstr "" -#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:9(para) +#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:13(para) msgid "Compute intensive workloads are defined by their high utilization of CPU, RAM, or both. User requirements will determine if a cloud must be built to accommodate anticipated performance demands." msgstr "" -#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:15(para) -msgid "Cost: Cost is not generally a primary concern for a compute-focused cloud, however some organizations might be concerned with cost avoidance. Repurposing existing resources to tackle compute-intensive tasks instead of needing to acquire additional resources may offer cost reduction opportunities." +#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:22(para) +msgid "Cost is not generally a primary concern for a compute-focused cloud, however some organizations might be concerned with cost avoidance. Repurposing existing resources to tackle compute-intensive tasks instead of needing to acquire additional resources may offer cost reduction opportunities." msgstr "" -#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:23(para) -msgid "Time to Market: Compute-focused clouds can be used to deliver products more quickly, for example, speeding up a company's software development life cycle (SDLC) for building products and applications." +#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:33(para) +msgid "Compute-focused clouds can be used to deliver products more quickly, for example, speeding up a company's software development life cycle (SDLC) for building products and applications." msgstr "" -#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:29(para) -msgid "Revenue Opportunity: Companies that are interested in building services or products that rely on the power of the compute resources will benefit from a compute-focused cloud. Examples include the analysis of large data sets (via Hadoop or Cassandra) or completing computational intensive tasks such as rendering, scientific computation, or simulations." +#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:42(para) +msgid "Companies that are interested in building services or products that rely on the power of the compute resources will benefit from a compute-focused cloud. Examples include the analysis of large data sets (via Hadoop or Cassandra) or completing computational intensive tasks such as rendering, scientific computation, or simulations." msgstr "" -#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:60(para) -msgid "Data compliance - certain types of information needs to reside in certain locations due to regular issues - and more important cannot reside in other locations for the same reason." +#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:74(para) +msgid "Data compliancecertain types of information needs to reside in certain locations due to regular issuesand more important cannot reside in other locations for the same reason." msgstr "" -#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:75(para) +#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:91(para) msgid "The following are some technical requirements that need to be incorporated into the architecture design." msgstr "" -#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:79(para) -msgid "Performance: If a primary technical concern is for the environment to deliver high performance capability, then a compute-focused design is an obvious choice because it is specifically designed to host compute-intensive workloads." +#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:98(para) +msgid "If a primary technical concern is for the environment to deliver high performance capability, then a compute-focused design is an obvious choice because it is specifically designed to host compute-intensive workloads." msgstr "" -#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:86(para) -msgid "Workload persistence: Workloads can be either short-lived or long running. Short-lived workloads might include continuous integration and continuous deployment (CI-CD) jobs, where large numbers of compute instances are created simultaneously to perform a set of compute-intensive tasks. The results or artifacts are then copied from the instance into long-term storage before the instance is destroyed. Long-running workloads, like a Hadoop or high-performance computing (HPC) cluster, typically ingest large data sets, perform the computational work on those data sets, then push the results into long term storage. Unlike short-lived workloads, when the computational work is completed, they will remain idle until the next job is pushed to them. Long-running workloads are often larger and more complex, so the effort of building them is mitigated by keeping them active between jobs. Another example of long running workloads is legacy applications that typically are persistent over time." +#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:106(term) +msgid "Workload persistence" msgstr "" #: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:108(para) -msgid "Storage: Workloads targeted for a compute-focused OpenStack cloud generally do not require any persistent block storage (although some usages of Hadoop with HDFS may dictate the use of persistent block storage). A shared filesystem or object store will maintain the initial data set(s) and serve as the destination for saving the computational results. By avoiding the input-output (IO) overhead, workload performance is significantly enhanced. Depending on the size of the data set(s), it might be necessary to scale the object store or shared file system to match the storage demand." +msgid "Workloads can be either short-lived or long running. Short-lived workloads might include continuous integration and continuous deployment (CI-CD) jobs, where large numbers of compute instances are created simultaneously to perform a set of compute-intensive tasks. The results or artifacts are then copied from the instance into long-term storage before the instance is destroyed. Long-running workloads, like a Hadoop or high-performance computing (HPC) cluster, typically ingest large data sets, perform the computational work on those data sets, then push the results into long term storage. Unlike short-lived workloads, when the computational work is completed, they will remain idle until the next job is pushed to them. Long-running workloads are often larger and more complex, so the effort of building them is mitigated by keeping them active between jobs. Another example of long running workloads is legacy applications that typically are persistent over time." msgstr "" -#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:122(para) -msgid "User Interface: Like any other cloud architecture, a compute-focused OpenStack cloud requires an on-demand and self-service user interface. End users must be able to provision computing power, storage, networks and software simply and flexibly. This includes scaling the infrastructure up to a substantial level without disrupting host operations." +#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:133(para) +msgid "Workloads targeted for a compute-focused OpenStack cloud generally do not require any persistent block storage (although some usages of Hadoop with HDFS may dictate the use of persistent block storage). A shared filesystem or object store will maintain the initial data set(s) and serve as the destination for saving the computational results. By avoiding the input-output (IO) overhead, workload performance is significantly enhanced. Depending on the size of the data set(s), it might be necessary to scale the object store or shared file system to match the storage demand." msgstr "" -#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:131(para) -msgid "Security: Security is going to be highly dependent on the business requirements. For example, a computationally intense drug discovery application will obviously have much higher security requirements than a cloud that is designed for processing market data for a retailer. As a general start, the security recommendations and guidelines provided in the OpenStack Security Guide are applicable." +#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:148(term) +msgid "User interface" msgstr "" -#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:143(para) +#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:150(para) +msgid "Like any other cloud architecture, a compute-focused OpenStack cloud requires an on-demand and self-service user interface. End users must be able to provision computing power, storage, networks and software simply and flexibly. This includes scaling the infrastructure up to a substantial level without disrupting host operations." +msgstr "" + +#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:162(para) +msgid "Security is going to be highly dependent on the business requirements. For example, a computationally intense drug discovery application will obviously have much higher security requirements than a cloud that is designed for processing market data for a retailer. As a general start, the security recommendations and guidelines provided in the OpenStack Security Guide are applicable." +msgstr "" + +#: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:176(para) msgid "The compute intensive cloud from the operational perspective is similar to the requirements for the general-purpose cloud. More details on operational requirements can be found in the general-purpose design section." msgstr "" @@ -3369,10 +3513,26 @@ msgstr "" msgid "In a compute-focused OpenStack cloud the hardware selection must reflect the workloads being compute intensive. Compute-focused is defined as having extreme demands on processor and memory resources. The hardware selection for a compute-focused OpenStack architecture design must reflect this preference for compute-intensive workloads, as these workloads are not storage intensive, nor are they consistently network intensive. The network and storage may be heavily utilized while loading a data set into the computational cluster, but they are not otherwise intensive." msgstr "" -#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:39(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:130(para) +#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:39(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:156(para) msgid "Compute (server) hardware must be evaluated against four opposing dimensions:" msgstr "" +#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:45(para) +msgid "Server density: A measure of how many servers can fit into a given measure of physical space, such as a rack unit [U]." +msgstr "" + +#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:52(para) +msgid "Resource capacity: The number of CPU cores, how much RAM, or how much storage a given server will deliver." +msgstr "" + +#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:59(para) +msgid "Expandability: The number of additional resources that can be added to a server before it has reached its limit." +msgstr "" + +#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:66(para) +msgid "Cost: The relative purchase price of the hardware weighted against the level of design effort needed to build the system." +msgstr "" + #: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:73(para) msgid "The dimensions need to be weighted against each other to determine the best design for the desired purpose. For example, increasing server density means sacrificing resource capacity or expandability. Increasing resource capacity and expandability can increase cost but decreases server density. Decreasing cost can mean decreasing supportability, server density, resource capacity, and expandability." msgstr "" @@ -3465,7 +3625,7 @@ msgstr "" msgid "Connectivity: Based on the storage solution selected, ensure the connectivity matches the storage solution requirements. If a centralized storage array is selected, it is important to determine how the hypervisors will connect to the storage array. Connectivity could affect latency and thus performance, so check that the network characteristics will minimize latency to boost the overall performance of the design." msgstr "" -#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:370(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:113(para) +#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:370(para) msgid "Latency: Determine if the use case will have consistent or highly variable latency." msgstr "" @@ -3481,10 +3641,22 @@ msgstr "" msgid "Where instances need to be made highly available, or they need to be capable of migration between hosts, use of a shared storage file-system to store instance ephemeral data should be employed to ensure that compute services can run uninterrupted in the event of a node failure." msgstr "" +#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:410(para) +msgid "Port count: The design will require networking hardware that has the requisite port count." +msgstr "" + #: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:416(para) msgid "Port density: The network design will be affected by the physical space that is required to provide the requisite port count. A switch that can provide 48 10 GbE ports in 1U has a much higher port density than a switch that provides 24 10 GbE ports in 2U. A higher port density is preferred, as it leaves more rack space for compute or storage components that might be required by the design. This also leads into concerns about fault domains and power density that must also be considered. Higher density switches are more expensive and should also be considered, as it is important not to over design the network if it is not required." msgstr "" +#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:440(para) +msgid "Port speed: The networking hardware must support the proposed network speed, for example: 1 GbE, 10 GbE, or 40 GbE (or even 100 GbE)." +msgstr "" + +#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:448(para) +msgid "Redundancy: The level of network hardware redundancy required is influenced by the user requirements for high availability and cost considerations. Network redundancy can be achieved by adding redundant power supplies or paired switches. If this is a requirement, the hardware will need to support this configuration. User requirements will determine if a completely redundant network infrastructure is required." +msgstr "" + #: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:464(para) msgid "Power requirements: Ensure that the physical data center provides the necessary power for the selected network hardware. This is not an issue for top of rack (ToR) switches, but may be an issue for spine switches in a leaf and spine fabric, or end of row (EoR) switches." msgstr "" @@ -3513,11 +3685,23 @@ msgstr "" msgid "Cost: Selecting a commercially supported hypervisor such as Microsoft Hyper-V will result in a different cost model rather than chosen a community-supported open source hypervisor like Kinstance or Xen. Even within the ranks of open source solutions, choosing Ubuntu over Red Hat (or vice versa) will have an impact on cost due to support contracts. On the other hand, business or application requirements might dictate a specific or commercially supported hypervisor." msgstr "" +#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:577(para) +msgid "Supportability: Depending on the selected hypervisor, the staff should have the appropriate training and knowledge to support the selected OS and hypervisor combination. If they do not, training will need to be provided which could have a cost impact on the design." +msgstr "" + +#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:590(para) +msgid "Management tools: The management tools used for Ubuntu and Kinstance differ from the management tools for VMware vSphere. Although both OS and hypervisor combinations are supported by OpenStack, there will be very different impacts to the rest of the design as a result of the selection of one combination versus the other." +msgstr "" + #: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:604(para) msgid "Scale and performance: Ensure that selected OS and hypervisor combinations meet the appropriate scale and performance requirements. The chosen architecture will need to meet the targeted instance-host ratios with the selected OS-hypervisor combination." msgstr "" -#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:629(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:402(para) +#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:615(para) +msgid "Security: Ensure that the design can accommodate the regular periodic installation of application security patches while maintaining the required workloads. The frequency of security patches for the proposed OS - hypervisor combination will have an impact on performance and the patch installation process could affect maintenance windows." +msgstr "" + +#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:629(para) msgid "Supported features: Determine what features of OpenStack are required. This will often determine the selection of the OS-hypervisor combination. Certain features are only available with specific OSs or hypervisors. For example, if certain features are not available, the design might need to be modified to meet the user requirements." msgstr "" @@ -3589,283 +3773,299 @@ msgstr "" msgid "Requirements for logging, monitoring, and alerting are determined by operational considerations. Each of these sub-categories includes a number of various options. For example, in the logging sub-category one might consider Logstash, Splunk, Log Insight, or some other log aggregation-consolidation tool. Logs should be stored in a centralized location to make it easier to perform analytics against the data. Log data analytics engines can also provide automation and issue notification by providing a mechanism to both alert and automatically attempt to remediate some of the more commonly known issues." msgstr "" -#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:819(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:522(para) +#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:819(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:613(para) msgid "If any of these software packages are needed, then the design must account for the additional resource consumption (CPU, RAM, storage, and network bandwidth for a log aggregation solution, for example). Some other potential design impacts include:" msgstr "" +#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:830(para) +msgid "OS - Hypervisor combination: Ensure that the selected logging, monitoring, or alerting tools support the proposed OS-hypervisor combination." +msgstr "" + #: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:848(para) msgid "A large majority of the OpenStack components require access to back-end database services to store state and configuration information. Selection of an appropriate back-end database that will satisfy the availability and fault tolerance requirements of the OpenStack services is required. OpenStack services support connecting to any database that is supported by the sqlalchemy Python drivers, however most common database deployments make use of mySQL or some variation of it. It is recommended that the database which provides back-end service within a general purpose cloud be made highly available using an available technology which can accomplish that goal. Some of the more common software solutions used include Galera, MariaDB and mySQL with multi-master replication." msgstr "" #. When image changes, this message will be marked fuzzy or untranslated for you. #. It doesn't matter what you translate it to: it's not used at all. -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:232(None) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:233(None) msgid "@@image: '../images/Compute_Tech_Bin_Packing_General1.png'; md5=34f2f0b656a66124016d2484fb96068b" msgstr "" #. When image changes, this message will be marked fuzzy or untranslated for you. #. It doesn't matter what you translate it to: it's not used at all. -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:241(None) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:242(None) msgid "@@image: '../images/Compute_Tech_Bin_Packing_CPU_optimized1.png'; md5=45084140c29e59a459d6b0af9b47642a" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:9(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:13(para) msgid "In a compute-focused OpenStack cloud, the type of instance workloads being provisioned heavily influences technical decision making. For example, specific use cases that demand multiple short running jobs present different requirements than those that specify long-running jobs, even though both situations are considered \"compute focused.\"" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:15(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:19(para) msgid "Public and private clouds require deterministic capacity planning to support elastic growth in order to meet user SLA expectations. Deterministic capacity planning is the path to predicting the effort and expense of making a given process consistently performant. This process is important because, when a service becomes a critical part of a user's infrastructure, the user's fate becomes wedded to the SLAs of the cloud itself. In cloud computing, a service’s performance will not be measured by its average speed but rather by the consistency of its speed." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:25(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:29(para) msgid "There are two aspects of capacity planning to consider: planning the initial deployment footprint, and planning expansion of it to stay ahead of the demands of cloud users." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:29(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:33(para) msgid "Planning the initial footprint for an OpenStack deployment is typically done based on existing infrastructure workloads and estimates based on expected uptake." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:32(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:36(para) msgid "The starting point is the core count of the cloud. By applying relevant ratios, the user can gather information about:" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:37(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:41(para) msgid "The number of instances expected to be available concurrently: (overcommit fraction × cores) / virtual cores per instance" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:42(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:46(para) msgid "How much storage is required: flavor disk size × number of instances" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:46(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:50(para) msgid "These ratios can be used to determine the amount of additional infrastructure needed to support the cloud. For example, consider a situation in which you require 1600 instances, each with 2 vCPU and 50 GB of storage. Assuming the default overcommit rate of 16:1, working out the math provides an equation of:" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:54(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:58(para) msgid "1600 = (16 x (number of physical cores)) / 2" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:57(para) -msgid "storage required = 50 GB x 1600" +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:61(para) +msgid "storage required = 50GB x 1600" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:60(para) -msgid "On the surface, the equations reveal the need for 200 physical cores and 80 TB of storage for /var/lib/nova/instances/. However, it is also important to look at patterns of usage to estimate the load that the API services, database servers, and queue servers are likely to encounter." +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:64(para) +msgid "On the surface, the equations reveal the need for 200 physical cores and 80TB of storage for /var/lib/nova/instances/. However, it is also important to look at patterns of usage to estimate the load that the API services, database servers, and queue servers are likely to encounter." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:66(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:71(para) msgid "Consider, for example, the differences between a cloud that supports a managed web-hosting platform with one running integration tests for a development project that creates one instance per code commit. In the former, the heavy work of creating an instance happens only every few months, whereas the latter puts constant heavy load on the cloud controller. The average instance lifetime must be considered, as a larger number generally means less load on the cloud controller." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:75(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:80(para) msgid "Aside from the creation and termination of instances, the impact of users must be considered when accessing the service, particularly on nova-api and its associated database. Listing instances garners a great deal of information and, given the frequency with which users run this operation, a cloud with a large number of users can increase the load significantly. This can even occur unintentionally. For example, the OpenStack Dashboard instances tab refreshes the list of instances every 30 seconds, so leaving it open in a browser window can cause unexpected load." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:85(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:90(para) msgid "Consideration of these factors can help determine how many cloud controller cores are required. A server with 8 CPU cores and 8 GB of RAM server would be sufficient for up to a rack of compute nodes, given the above caveats." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:89(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:94(para) msgid "Key hardware specifications are also crucial to the performance of user instances. Be sure to consider budget and performance needs, including storage performance (spindles/core), memory availability (RAM/core), network bandwidth (Gbps/core), and overall CPU performance (CPU/core)." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:95(para) -msgid "The cloud resource calculator is a useful tool in examining the impacts of different hardware and instance load outs. It is available at:" -msgstr "" - #: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:100(para) -msgid "https://github.com/noslzzp/cloud-resource-calculator/blob/master/cloud-resource-calculator.ods" +msgid "The cloud resource calculator is a useful tool in examining the impacts of different hardware and instance load outs. It is available at: <link href=\"https://github.com/noslzzp/cloud-resource-calculator/blob/master/cloud-resource-calculator.ods\">https://github.com/noslzzp/cloud-resource-calculator/blob/master/cloud-resource-calculator.ods</link>" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:104(title) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:105(title) msgid "Expansion planning" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:105(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:106(para) msgid "A key challenge faced when planning the expansion of cloud compute services is the elastic nature of cloud infrastructure demands. Previously, new users or customers would be forced to plan for and request the infrastructure they required ahead of time, allowing time for reactive procurement processes. Cloud computing users have come to expect the agility provided by having instant access to new resources as they are required. Consequently, this means planning should be delivered for typical usage, but also more importantly, for sudden bursts in usage." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:115(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:116(para) msgid "Planning for expansion can be a delicate balancing act. Planning too conservatively can lead to unexpected oversubscription of the cloud and dissatisfied users. Planning for cloud expansion too aggressively can lead to unexpected underutilization of the cloud and funds spent on operating infrastructure that is not being used efficiently." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:121(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:122(para) msgid "The key is to carefully monitor the spikes and valleys in cloud usage over time. The intent is to measure the consistency with which services can be delivered, not the average speed or capacity of the cloud. Using this information to model performance results in capacity enables users to more accurately determine the current and future capacity of the cloud." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:128(title) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:129(title) msgid "CPU and RAM" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:129(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:130(para) msgid "(Adapted from: http://docs.openstack.org/openstack-ops/content/compute_nodes.html#cpu_choice)" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:131(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:132(para) msgid "In current generations, CPUs have up to 12 cores. If an Intel CPU supports Hyper-Threading, those 12 cores are doubled to 24 cores. If a server is purchased that supports multiple CPUs, the number of cores is further multiplied. Hyper-Threading is Intel's proprietary simultaneous multi-threading implementation, used to improve parallelization on their CPUs. Consider enabling Hyper-Threading to improve the performance of multithreaded applications." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:140(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:141(para) msgid "Whether the user should enable Hyper-Threading on a CPU depends upon the use case. For example, disabling Hyper-Threading can be beneficial in intense computing environments. Performance testing conducted by running local workloads with both Hyper-Threading on and off can help determine what is more appropriate in any particular case." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:147(para) -msgid "If the Libvirt/KVM Hypervisor driver are the intended use cases, then the CPUs used in the compute nodes must support virtualization by way of the VT-x extensions for Intel chips and AMD-v extensions for AMD chips to provide full performance." +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:148(para) +msgid "If the Libvirt/KVM hypervisor driver are the intended use cases, then the CPUs used in the compute nodes must support virtualization by way of the VT-x extensions for Intel chips and AMD-v extensions for AMD chips to provide full performance." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:152(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:153(para) msgid "OpenStack enables the user to overcommit CPU and RAM on compute nodes. This allows an increase in the number of instances running on the cloud at the cost of reducing the performance of the instances. OpenStack Compute uses the following ratios by default:" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:159(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:160(para) msgid "CPU allocation ratio: 16:1" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:162(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:163(para) msgid "RAM allocation ratio: 1.5:1" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:165(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:166(para) msgid "The default CPU allocation ratio of 16:1 means that the scheduler allocates up to 16 virtual cores per physical core. For example, if a physical node has 12 cores, the scheduler sees 192 available virtual cores. With typical flavor definitions of 4 virtual cores per instance, this ratio would provide 48 instances on a physical node." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:171(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:172(para) msgid "Similarly, the default RAM allocation ratio of 1.5:1 means that the scheduler allocates instances to a physical node as long as the total amount of RAM associated with the instances is less than 1.5 times the amount of RAM available on the physical node." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:176(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:177(para) msgid "For example, if a physical node has 48 GB of RAM, the scheduler allocates instances to that node until the sum of the RAM associated with the instances reaches 72 GB (such as nine instances, in the case where each instance has 8 GB of RAM)." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:181(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:182(para) msgid "The appropriate CPU and RAM allocation ratio must be selected based on particular use cases." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:184(title) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:185(title) msgid "Additional hardware" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:185(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:186(para) msgid "Certain use cases may benefit from exposure to additional devices on the compute node. Examples might include:" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:189(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:190(para) msgid "High performance computing jobs that benefit from the availability of graphics processing units (GPUs) for general-purpose computing." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:196(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:197(para) msgid "Cryptographic routines that benefit from the availability of hardware random number generators to avoid entropy starvation." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:201(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:202(para) msgid "Database management systems that benefit from the availability of SSDs for ephemeral storage to maximize read/write time when it is required." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:206(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:207(para) msgid "Host aggregates are used to group hosts that share similar characteristics, which can include hardware similarities. The addition of specialized hardware to a cloud deployment is likely to add to the cost of each node, so careful consideration must be given to whether all compute nodes, or just a subset which is targetable using flavors, need the additional customization to support the desired workloads." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:215(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:216(para) msgid "Infrastructure-as-a-Service offerings, including OpenStack, use flavors to provide standardized views of virtual machine resource requirements that simplify the problem of scheduling instances while making the best use of the available physical resources." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:220(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:221(para) msgid "In order to facilitate packing of virtual machines onto physical hosts, the default selection of flavors are constructed so that the second largest flavor is half the size of the largest flavor in every dimension. It has half the vCPUs, half the vRAM, and half the ephemeral disk space. The next largest flavor is half that size again. As a result, packing a server for general purpose computing might look conceptually something like this figure:" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:235(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:236(para) msgid "On the other hand, a CPU optimized packed server might look like the following figure:" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:244(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:245(para) msgid "These default flavors are well suited to typical load outs for commodity server hardware. To maximize utilization, however, it may be necessary to customize the flavors or create new ones, to better align instance sizes to the available hardware." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:249(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:250(para) msgid "Workload characteristics may also influence hardware choices and flavor configuration, particularly where they present different ratios of CPU versus RAM versus HDD requirements." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:253(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:254(para) msgid "For more information on Flavors refer to: http://docs.openstack.org/openstack-ops/content/flavors.html" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:257(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:258(para) msgid "The infrastructure of a cloud should not be shared, so that it is possible for the workloads to consume as many resources as are made available, and accommodations should be made to provide large scale workloads." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:261(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:262(para) msgid "The duration of batch processing differs depending on individual workloads that are launched. Time limits range from seconds, minutes to hours, and as a result it is considered difficult to predict when resources will be used, for how long, and even which resources will be used." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:268(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:269(para) msgid "The security considerations needed for this scenario are similar to those of the other scenarios discussed in this book." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:291(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:292(para) msgid "These security domains can be mapped individually to the installation, or they can also be combined. For example, some deployment topologies combine both guest and data domains onto one physical network, whereas in other cases these networks are physically separated. In each case, the cloud operator should be aware of the appropriate security concerns. Security domains should be mapped out against specific OpenStack deployment topology. The domains and their trust requirements depend upon whether the cloud instance is public, private, or hybrid." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:301(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:302(para) msgid "The public security domain is an entirely untrusted area of the cloud infrastructure. It can refer to the Internet as a whole or simply to networks over which the user has no authority. This domain should always be considered untrusted." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:306(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:307(para) msgid "Typically used for compute instance-to-instance traffic, the guest security domain handles compute data generated by instances on the cloud; not services that support the operation of the cloud, for example API calls. Public cloud providers and private cloud providers who do not have stringent controls on instance use or who allow unrestricted internet access to instances should consider this domain to be untrusted. Private cloud providers may want to consider this network as internal and therefore trusted only if they have controls in place to assert that they trust instances and all their tenants." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:322(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:323(para) msgid "The data security domain is concerned primarily with information pertaining to the storage services within OpenStack. Much of the data that crosses this network has high integrity and confidentiality requirements and depending on the type of deployment there may also be strong availability requirements. The trust level of this network is heavily dependent on deployment decisions and as such we do not assign this any default level of trust." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:330(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:331(para) msgid "When deploying OpenStack in an enterprise as a private cloud it is assumed to be behind a firewall and within the trusted network alongside existing systems. Users of the cloud are typically employees or trusted individuals that are bound by the security requirements set forth by the company. This tends to push most of the security domains towards a more trusted model. However, when deploying OpenStack in a public-facing role, no assumptions can be made and the attack vectors significantly increase. For example, the API endpoints and the software behind it will be vulnerable to potentially hostile entities wanting to gain unauthorized access or prevent access to services. This can result in loss of reputation and must be protected against through auditing and appropriate filtering." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:344(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:345(para) msgid "Consideration must be taken when managing the users of the system, whether it is the operation of public or private clouds. The identity service allows for LDAP to be part of the authentication process, and includes such systems as an OpenStack deployment that may ease user management if integrated into existing systems." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:350(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:351(para) msgid "It is strongly recommended that the API services are placed behind hardware that performs SSL termination. API services transmit user names, passwords, and generated tokens between client machines and API endpoints and therefore must be secured." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:355(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:219(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:356(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:219(para) msgid "More information on OpenStack Security can be found at http://docs.openstack.org/security-guide/" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:360(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:361(para) msgid "Due to the nature of the workloads that will be used in this scenario, a number of components will be highly beneficial in a Compute-focused cloud. This includes the typical OpenStack components:" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:375(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:367(para) +msgid "OpenStack Compute (Nova)" +msgstr "" + +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:370(para) +msgid "OpenStack Image Service (Glance)" +msgstr "" + +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:373(para) +msgid "OpenStack Identity Service (Keystone)" +msgstr "" + +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:376(para) msgid "Also consider several specialized components:" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:378(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:379(para) msgid "OpenStack Orchestration Engine (Heat)" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:381(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:382(para) msgid "It is safe to assume that, given the nature of the applications involved in this scenario, these will be heavily automated deployments. Making use of Heat will be highly beneficial in this case. Deploying a batch of instances and running an automated set of tests can be scripted, however it makes sense to use the OpenStack Orchestration Engine (Heat) to handle all these actions." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:393(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:391(para) +msgid "OpenStack Telemetry (Ceilometer)" +msgstr "" + +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:394(para) msgid "OpenStack Telemetry and the alarms it generates are required to support autoscaling of instances using OpenStack Orchestration. Users that are not using OpenStack Orchestration do not need to deploy OpenStack Telemetry and may choose to use other external solutions to fulfill their metering and monitoring requirements." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:399(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:400(para) msgid "See also: http://docs.openstack.org/openstack-ops/content/logging_monitoring.html" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:403(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:404(para) msgid "OpenStack Block Storage (Cinder)" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:406(para) -msgid "Due to the burst-able nature of the workloads and the applications and instances that will be used for batch processing, this cloud will utilize mainly memory or CPU, so the need for add-on storage to each instance is not a likely requirement. This does not mean the OpenStack Block Storage service (Cinder) will not be used in the infrastructure, but typically it will not be used as a central component." +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:407(para) +msgid "Due to the burst-able nature of the workloads and the applications and instances that will be used for batch processing, this cloud will utilize mainly memory or CPU, so the need for add-on storage to each instance is not a likely requirement. This does not mean the OpenStack Block Storage service (cinder) will not be used in the infrastructure, but typically it will not be used as a central component." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:418(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:419(para) msgid "When choosing a networking platform, ensure that it either works with all desired hypervisor and container technologies and their OpenStack drivers, or includes an implementation of an ML2 mechanism driver. Networking platforms that provide ML2 mechanisms drivers can be mixed." msgstr "" @@ -3886,7 +4086,7 @@ msgid "The Conseil Européen pour la Recherche Nucléaire (CERN), also known as msgstr "" #: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:13(para) -msgid "As of 2011 CERN operated these two compute centers in Europe with plans to add a third:" +msgid "As of 2011 CERN operated these two compute centers in Europe with plans to add a third." msgstr "" #: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:15(para) @@ -4827,6 +5027,10 @@ msgstr "" msgid "More so than other scenarios, defining user requirements for a massively scalable OpenStack design architecture dictates approaching the design from two different, yet sometimes opposing, perspectives: the cloud user, and the cloud operator. The expectations and perceptions of the consumption and management of resources of a massively scalable OpenStack cloud from the user point of view is distinctly different from that of the cloud operator." msgstr "" +#: ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:42(para) +msgid "Examples of such legal frameworks include the data protection framework of the European Union (http://ec.europa.eu/justice/data-protection/ ) and the requirements of the Financial Industry Regulatory Authority (http://www.finra.org/Industry/Regulation/FINRARules/ ) in the United States. Consult a local regulatory body for more information." +msgstr "" + #: ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:51(para) msgid "Massively scalable OpenStack clouds have the following user requirements:" msgstr "" @@ -5427,267 +5631,283 @@ msgstr "" msgid "The SSD cache layer is used to present block devices directly to Hypervisors or instances. The SSD cache systems can also be used as an inline cache for the REST interface." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:8(para) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:12(para) msgid "Storage hardware selection options include three areas:" msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:18(para) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:22(para) msgid "Reliability" msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:21(para) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:25(para) msgid "The selection of hardware for a storage-focused OpenStack cloud must reflect the fact that the workloads are storage intensive. These workloads are not compute intensive, nor are they consistently network intensive. The network may be heavily utilized to transfer storage, but they are not otherwise network intensive. The hardware selection for a storage-focused OpenStack architecture design must reflect this preference for storage-intensive workloads." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:29(para) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:33(para) msgid "For a storage-focused OpenStack design architecture, the selection of storage hardware will determine the overall performance and scalability of the design architecture. A number of different factors must be considered in the design process:" msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:36(para) -msgid "Cost: The overall cost of the solution will play a major role in what storage architecture and the resulting storage hardware that is selected." +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:42(para) +msgid "The overall cost of the solution will play a major role in what storage architecture and the resulting storage hardware that is selected." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:41(para) -msgid "Performance: The performance of the solution, measured by observing the latency of storage I-O requests, also plays a major role. In a compute-focused OpenStack cloud storage latency could potentially be a major consideration, in some compute-intensive workloads, minimizing the delays that the CPU experiences while fetching data from the storage can have a significant impact on the overall performance of the application." +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:50(para) +msgid "The performance of the solution, measured by observing the latency of storage I-O requests, also plays a major role. In a compute-focused OpenStack cloud storage latency could potentially be a major consideration, in some compute-intensive workloads, minimizing the delays that the CPU experiences while fetching data from the storage can have a significant impact on the overall performance of the application." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:54(para) -msgid "Scalability: \"Scalability\" refers to how well the storage solution performs as it is expanded up to its maximum size. A storage solution that performs well in small configurations but has degrading performance as it expands would be considered not scalable. Conversely, a solution that continues to perform well at maximum expansion would be considered scalable. The ability of the storage solution to continue to perform well as it expands is important." +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:64(para) +msgid "\"Scalability\" refers to how well the storage solution performs as it is expanded up to its maximum size. A storage solution that performs well in small configurations but has degrading performance as it expands would be considered not scalable. Conversely, a solution that continues to perform well at maximum expansion would be considered scalable. The ability of the storage solution to continue to perform well as it expands is important." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:65(para) -msgid "Expandability: Here we are referring to the overall ability of the solution to grow. A storage solution that expands to 50 PB is considered more expandable than a solution that only scales to 10 PB. Note that this metric is related to but different from scalability which is a measure of the solution's performance as it expands." +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:78(para) +msgid "Here we are referring to the overall ability of the solution to grow. A storage solution that expands to 50 PB is considered more expandable than a solution that only scales to 10 PB. Note that this metric is related to but different from scalability which is a measure of the solution's performance as it expands." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:74(para) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:88(para) msgid "Latency is one of the key considerations in a storage-focused OpenStack cloud . Using solid-state disks (SSDs) to minimize latency for instance storage and reduce CPU delays caused by waiting for the storage will have a result of increased performance. It is also recommended to evaluate the gains from using RAID controller cards in compute hosts to improve the performance of the underlying disk subsystem." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:82(para) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:96(para) msgid "The selection of storage architecture (and the corresponding storage hardware, if there is an option) is determined by evaluating possible solutions against the key factors above. This will determine if a scale-out solution (such as Ceph, GlusterFS, or similar) should be used or if a single, highly expandable and scalable centralized storage array would be a better choice. If a centralized storage array is the right fit for the requirements then the hardware will be determined by the array vendor. It is possible to build a storage array using commodity hardware with Open Source software, but there needs to be access to people with expertise to build such a system. On the other hand, a scale-out storage solution that uses direct-attached storage (DAS) in the servers may be an appropriate choice. If this is true, then the server hardware needs to be configured to support the storage solution." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:97(para) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:111(para) msgid "Some potential impacts that might affect a particular storage architecture (and corresponding storage hardware) of a Storage-focused OpenStack cloud:" msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:102(para) -msgid "Connectivity: Based on the storage solution selected, ensure the connectivity matches the storage solution requirements. If a centralized storage array is selected it is important to determine how the hypervisors will connect to the storage array. Connectivity can affect latency and thus performance. It is recommended to check that the network characteristics will minimize latency to boost the overall performance of the design." +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:118(para) +msgid "Based on the storage solution selected, ensure the connectivity matches the storage solution requirements. If a centralized storage array is selected it is important to determine how the hypervisors will connect to the storage array. Connectivity can affect latency and thus performance. It is recommended to check that the network characteristics will minimize latency to boost the overall performance of the design." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:117(para) -msgid "Throughput: Ensure that the storage solution throughput is optimized based on application requirements." +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:130(term) +msgid "Latency" msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:122(para) -msgid "Server Hardware: Use of DAS impacts the server hardware choice and affects host density, instance density, power density, OS-hypervisor, and management tools, to name a few." +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:132(para) +msgid "Determine if the use case will have consistent or highly variable latency." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:129(title) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:137(term) +msgid "Throughput" +msgstr "" + +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:139(para) +msgid "Ensure that the storage solution throughput is optimized based on application requirements." +msgstr "" + +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:147(para) +msgid "Use of DAS impacts the server hardware choice and affects host density, instance density, power density, OS-hypervisor, and management tools, to name a few." +msgstr "" + +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:155(title) msgid "Compute (server) hardware selection" msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:149(para) -msgid "Cost: The relative of the hardware weighted against the level of design effort needed to build the system." +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:186(para) +msgid "The relative of the hardware weighted against the level of design effort needed to build the system." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:154(para) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:192(para) msgid "The dimensions need to be weighed against each other to determine the best design for the desired purpose. For example, increasing server density can mean sacrificing resource capacity or expandability. Increasing resource capacity and expandability can increase cost but decrease server density. Decreasing cost often means decreasing supportability, server density, resource capacity, and expandability." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:162(para) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:200(para) msgid "For a storage-focused OpenStack architecture design, a secondary design consideration for selecting server hardware will be the compute capacity (CPU cores and RAM capacity). As a result, the required server hardware must supply adequate CPU sockets, additional CPU cores, and more RAM; network connectivity and storage capacity are not as critical. The hardware will need to provide enough network connectivity and storage capacity to meet the user requirements, however they are not the primary consideration." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:171(para) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:209(para) msgid "Since there is only a need for adequate CPU and RAM capacity, some server hardware form factors will be better suited to this storage-focused design than others:" msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:176(para) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:214(para) msgid "Most blade servers typically support dual-socket multi-core CPUs; to avoid the limit will mean choosing \"full width\" or \"full height\" blades, which means losing server density. The high density blade servers (for example, both HP BladeSystem and Dell PowerEdge M1000e), which support up to 16 servers in only 10 rack units using \"half height\" or \"half width\" blades, suddenly decrease the density by 50% (only 8 servers in 10 U) if a \"full width\" or \"full height\" option is used." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:188(para) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:226(para) msgid "1U rack-mounted servers (servers that occupy only a single rack unit) might be able to offer greater server density than a blade server solution (40 servers in a rack, providing space for the top of rack (ToR) switches, versus 32 \"full width\" or \"full height\" blade servers in a rack), but often are limited to dual-socket, multi-core CPU configurations. Note that as of the Icehouse release, neither HP, IBM, nor Dell offered 1U rack servers with more than 2 CPU sockets. To obtain greater than dual-socket support in a 1U rack-mount form factor, customers need to buy their systems from Original Design Manufacturers (ODMs) or second-tier manufacturers. This may cause issues for organizations that have preferred vendor policies or concerns with support and hardware warranties of non-tier 1 vendors." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:206(para) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:244(para) msgid "2U rack-mounted servers provide quad-socket, multi-core CPU support but with a corresponding decrease in server density (half the density offered by 1U rack-mounted servers)." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:212(para) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:250(para) msgid "Larger rack-mounted servers, such as 4U servers, often provide even greater CPU capacity. Commonly supporting four or even eight CPU sockets. These servers have greater expandability capacity but such servers have much lower server density and usually greater hardware cost." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:220(para) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:258(para) msgid "The so-called \"sled servers\" (rack-mounted servers that support multiple independent servers in a single 2U or 3U enclosure) deliver increased density as compared to a typical 1U-2U rack-mounted servers. For example, many sled servers offer four independent dual-socket nodes in 2U for a total of 8 CPU sockets in 2U. However, the dual-socket limitation on individual nodes may not be sufficient to offset their additional cost and configuration complexity." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:231(para) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:269(para) msgid "Other factors that will strongly influence server hardware selection for a storage-focused OpenStack design architecture:" msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:236(para) -msgid "Instance density: In this architecture, instance density and CPU-RAM oversubscription are lower. More hosts will be required to support the anticipated scale, especially if the design uses dual-socket hardware designs." +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:276(para) +msgid "In this architecture, instance density and CPU-RAM oversubscription are lower. More hosts will be required to support the anticipated scale, especially if the design uses dual-socket hardware designs." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:243(para) -msgid "Host density: Another option to address the higher host count is to use a quad socket platform. Taking this approach will decrease host density which also increases rack count. This configuration affects the number of power connections and also impacts network and cooling requirements." +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:286(para) +msgid "Another option to address the higher host count is to use a quad socket platform. Taking this approach will decrease host density which also increases rack count. This configuration affects the number of power connections and also impacts network and cooling requirements." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:251(para) -msgid "Power and cooling density: The power and cooling density requirements might be lower than with blade, sled, or 1U server designs due to lower host density (by using 2U, 3U or even 4U server designs). For data centers with older infrastructure, this might be a desirable feature." +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:295(term) +msgid "Power and cooling density" msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:259(para) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:297(para) +msgid "The power and cooling density requirements might be lower than with blade, sled, or 1U server designs due to lower host density (by using 2U, 3U or even 4U server designs). For data centers with older infrastructure, this might be a desirable feature." +msgstr "" + +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:306(para) msgid "Storage-focused OpenStack design architecture server hardware selection should focus on a \"scale up\" versus \"scale out\" solution. The determination of which will be the best solution, smaller number of larger hosts or a larger number of smaller hosts, will depend of a combination of factors including cost, power, cooling, physical rack and floor space, support-warranty, and manageability." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:267(title) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:314(title) msgid "Networking hardware selection" msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:272(para) -msgid "Port count: The user will require networking hardware that has the requisite port count." -msgstr "" - -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:276(para) -msgid "Port density: The network design will be affected by the physical space that is required to provide the requisite port count. A switch that can provide 48 10 GbE ports in 1U has a much higher port density than a switch that provides 24 10 GbE ports in 2U. On a general scale, a higher port density leaves more rack space for compute or storage components which is preferred. It is also important to consider fault domains and power density. Finally, higher density switches are more expensive, therefore it is important not to over design the network." -msgstr "" - -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:294(para) -msgid "Redundancy: The level of network hardware redundancy required is influenced by the user requirements for high availability and cost considerations. Network redundancy can be achieved by adding redundant power supplies or paired switches. If this is a requirement the hardware will need to support this configuration. User requirements will determine if a completely redundant network infrastructure is required." -msgstr "" - -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:304(para) -msgid "Power requirements: Make sure that the physical data center provides the necessary power for the selected network hardware. This is not typically an issue for top of rack (ToR) switches, but may be an issue for spine switches in a leaf and spine fabric, or end of row (EoR) switches." -msgstr "" - -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:312(para) -msgid "Protocol support: It is possible to gain even 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:321(para) -msgid "Selecting software to be included in a storage-focused OpenStack architecture design includes three areas:" +msgid "The user will require networking hardware that has the requisite port count." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:334(para) -msgid "Design decisions made in each of these areas impacts the rest of the OpenStack architecture design." +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:328(para) +msgid "The network design will be affected by the physical space that is required to provide the requisite port count. A switch that can provide 48 10GbE ports in 1U has a much higher port density than a switch that provides 24 10GbE ports in 2U. On a general scale, a higher port density leaves more rack space for compute or storage components which is preferred. It is also important to consider fault domains and power density. Finally, higher density switches are more expensive, therefore it is important not to over design the network." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:338(para) -msgid "The selection of OS and hypervisor has a significant impact on the overall design and also affects server hardware selection. Ensure that the storage hardware is supported by the selected operating system and hypervisor combination and that the networking hardware selection and topology will work with the chosen operating system and hypervisor combination. For example, if the design uses Link Aggregation Control Protocol (LACP), the OS and hypervisor are both required to support it." +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:352(para) +msgid "The level of network hardware redundancy required is influenced by the user requirements for high availability and cost considerations. Network redundancy can be achieved by adding redundant power supplies or paired switches. If this is a requirement the hardware will need to support this configuration. User requirements will determine if a completely redundant network infrastructure is required." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:351(para) -msgid "Cost: Selection of a commercially supported hypervisor, such as Microsoft Hyper-V, will result in a different cost model rather than selected a community-supported open source hypervisor like Kinstance or Xen. Similarly, choosing Ubuntu over Red Hat (or vice versa) will have an impact on cost due to support contracts. Conversely, business or application requirements might dictate a specific or commercially supported hypervisor." +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:365(para) +msgid "Make sure that the physical data center provides the necessary power for the selected network hardware. This is not typically an issue for top of rack (ToR) switches, but may be an issue for spine switches in a leaf and spine fabric, or end of row (EoR) switches." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:362(para) -msgid "Supportability: Whichever hypervisor is chosen, the staff needs to have appropriate training and knowledge to support the selected OS and hypervisor combination. If they do not training will need to be provided, which could have a cost impact on the design. Another aspect to consider would be the support for the OS-hypervisor. The support of a commercial product such as Redhat, Suse, or Windows, is the responsibility of the OS vendor. If an Open Source platform is chosen, the support comes from in-house resources. Either decision has a cost that will have an impact on the design." +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:374(term) +msgid "Protocol support" msgstr "" #: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:376(para) -msgid "Management tools: The management tools used for Ubuntu and Kinstance differ from the management tools for VMware vSphere. Although both OS and hypervisor combinations are supported by OpenStack, there will naturally be very different impacts to the rest of the design as a result of the selection of one combination versus the other." +msgid "It is possible to gain even 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:385(para) -msgid "Scale and performance: Make sure that selected OS and hypervisor combination meet the appropriate scale and performance requirements needed for this general purpose OpenStack cloud. The chosen architecture will need to meet the targeted instance-host ratios with the selected OS-hypervisor combination." +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:387(para) +msgid "Selecting software to be included in a storage-focused OpenStack architecture design includes three areas:" msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:393(para) -msgid "Security: Make sure that the design can accommodate the regular periodic installation of application security patches while maintaining the required workloads. The frequency of security patches for the proposed OS-hypervisor combination will have an impact on performance and the patch installation process could affect maintenance windows." +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:400(para) +msgid "Design decisions made in each of these areas impacts the rest of the OpenStack architecture design." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:411(para) -msgid "Interoperability: Consideration should be given to the ability of the selected OS-hypervisor combination to interoperate or co-exist with other OS-hypervisors ,or other software solutions in the overall design, if that is a requirement. Operational and troubleshooting tools for one OS-hypervisor combination may differ from the tools used for another OS-hypervisor combination. As a result, the design will need to address if the two sets of tools need to interoperate." +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:404(para) +msgid "The selection of OS and hypervisor has a significant impact on the overall design and also affects server hardware selection. Ensure that the storage hardware is supported by the selected operating system and hypervisor combination and that the networking hardware selection and topology will work with the chosen operating system and hypervisor combination. For example, if the design uses Link Aggregation Control Protocol (LACP), the OS and hypervisor are both required to support it." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:425(para) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:419(para) +msgid "Selection of a commercially supported hypervisor, such as Microsoft Hyper-V, will result in a different cost model rather than selected a community-supported open source hypervisor like Kinstance or Xen. Similarly, choosing Ubuntu over Red Hat (or vice versa) will have an impact on cost due to support contracts. Conversely, business or application requirements might dictate a specific or commercially supported hypervisor." +msgstr "" + +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:433(para) +msgid "Whichever hypervisor is chosen, the staff needs to have appropriate training and knowledge to support the selected OS and hypervisor combination. If they do not training will need to be provided, which could have a cost impact on the design. Another aspect to consider would be the support for the OS-hypervisor. The support of a commercial product such as Redhat, Suse, or Windows, is the responsibility of the OS vendor. If an Open Source platform is chosen, the support comes from in-house resources. Either decision has a cost that will have an impact on the design." +msgstr "" + +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:450(para) +msgid "The management tools used for Ubuntu and Kinstance differ from the management tools for VMware vSphere. Although both OS and hypervisor combinations are supported by OpenStack, there will naturally be very different impacts to the rest of the design as a result of the selection of one combination versus the other." +msgstr "" + +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:462(para) +msgid "Make sure that selected OS and hypervisor combination meet the appropriate scale and performance requirements needed for this general purpose OpenStack cloud. The chosen architecture will need to meet the targeted instance-host ratios with the selected OS-hypervisor combination." +msgstr "" + +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:473(para) +msgid "Make sure that the design can accommodate the regular periodic installation of application security patches while maintaining the required workloads. The frequency of security patches for the proposed OS-hypervisor combination will have an impact on performance and the patch installation process could affect maintenance windows." +msgstr "" + +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:485(para) +msgid "Determine what features of OpenStack are required. This will often determine the selection of the OS-hypervisor combination. Certain features are only available with specific OSs or hypervisors. For example, if certain features are not available, the design might need to be modified to meet the user requirements." +msgstr "" + +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:497(para) +msgid "Consideration should be given to the ability of the selected OS-hypervisor combination to interoperate or co-exist with other OS-hypervisors ,or other software solutions in the overall design, if that is a requirement. Operational and troubleshooting tools for one OS-hypervisor combination may differ from the tools used for another OS-hypervisor combination. As a result, the design will need to address if the two sets of tools need to interoperate." +msgstr "" + +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:513(para) msgid "The selection of OpenStack components has a significant direct impact on the overall design. While there are certain components that will always be present, (Nova and Glance, for example) there are other services that may not need to be present. As an example, a certain design may not require OpenStack Heat. Omitting Heat would not typically have a significant impact on the overall design however, if the architecture uses a replacement for OpenStack Swift for its storage component, this could potentially have significant impacts on the rest of the design." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:435(para) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:523(para) msgid "A storage-focused design might require the ability to use Heat to launch instances with Cinder volumes to perform storage-intensive processing." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:438(para) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:526(para) msgid "For a storage-focused OpenStack design architecture, the following components would typically be used:" msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:442(para) -msgid "Keystone" +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:536(para) +msgid "OpenStack Compute (nova) (including the use of multiple hypervisor drivers)" msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:445(para) -msgid "Horizon" +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:540(para) +msgid "OpenStack Object Storage (swift) (or another object storage solution)" msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:448(para) -msgid "Nova (including the use of multiple hypervisor drivers)" +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:543(para) +msgid "OpenStack Block Storage (cinder)" msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:452(para) -msgid "Swift (or another object storage solution)" +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:549(para) +msgid "OpenStack Networking (neutron) or nova-network" msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:455(para) -msgid "Cinder" -msgstr "" - -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:458(para) -msgid "Glance" -msgstr "" - -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:461(para) -msgid "Neutron or nova-network" -msgstr "" - -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:464(para) -msgid "The exclusion of certain OpenStack components may limit or constrain the functionality of other components. If a design opts to include Heat but exclude Ceilometer, then the design will not be able to take advantage of Heat's auto scaling functionality (which relies on information from Ceilometer). Due to the fact that you can use Heat to spin up a large number of instances to perform the compute-intensive processing, including Heat in a compute-focused architecture design is strongly recommended." -msgstr "" - -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:475(para) -msgid "While OpenStack is a fairly complete collection of software projects for building a platform for cloud services, there are additional pieces of software that might need to be added to any given OpenStack design." -msgstr "" - -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:481(para) -msgid "OpenStack Neutron provides a wide variety of networking services for instances. There are many additional networking software packages that may be useful to manage the OpenStack components themselves. Some examples include HAProxy, keepalived, and various routing daemons (like Quagga). Some of these software packages, HAProxy in particular, are described in more detail in the OpenStack HA Guide (refer to Chapter 8 of the OpenStack High Availability Guide). For a general purpose OpenStack cloud, it is reasonably likely that the OpenStack infrastructure components will need to be highly available, and therefore networking software packages like HAProxy will need to be included." -msgstr "" - -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:495(para) -msgid "This includes software for providing clustering, logging, monitoring, and alerting. The factors for determining which software packages in this category should be selected is outside the scope of this design guide. This design guide focuses specifically on how the selected supplemental software solution impacts or affects the overall OpenStack cloud design." -msgstr "" - -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:502(para) -msgid "Clustering Software, such as Corosync or Pacemaker, is determined primarily by the availability design requirements. Therefore, the impact of including (or not including) these software packages is determined by the availability of the cloud infrastructure and the complexity of supporting the configuration after it is deployed. The OpenStack High Availability Guide provides more details on the installation and configuration of Corosync and Pacemaker, should these packages need to be included in the design." -msgstr "" - -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:511(para) -msgid "Requirements for logging, monitoring, and alerting are determined by operational considerations. Each of these sub-categories includes a number of various options. For example, in the logging sub-category one might consider Logstash, Splunk, Log Insight, or some other log aggregation-consolidation tool. Logs should be stored in a centralized location to make it easier to perform analytics against the data. Log data analytics engines can also provide automation and issue notification, by providing a mechanism to both alert and automatically attempt to remediate some of the more commonly known issues." -msgstr "" - -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:541(para) -msgid "Virtually all of the OpenStack components require access to back-end database services to store state and configuration information. Choose an appropriate back-end database which will satisfy the availability and fault tolerance requirements of the OpenStack services." -msgstr "" - -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:546(para) -msgid "MySQL is generally considered to be the de facto database for OpenStack, however, other compatible databases are also known to work. Note, however, that Ceilometer uses MongoDB." -msgstr "" - -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:550(para) -msgid "The solution selected to provide high availability for the database will change based on the selected database. If MySQL is selected, then a number of options are available. For active-active clustering a replication technology such as Galera can be used. For active-passive some form of shared storage must be used. Each of these potential solutions has an impact on the design:" -msgstr "" - -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:559(para) -msgid "Solutions that employ Galera/MariaDB will require at least three MySQL nodes." +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:552(para) +msgid "The exclusion of certain OpenStack components may limit or constrain the functionality of other components. If a design opts to include Orchestration but exclude Telemetry, then the design will not be able to take advantage of Orchestration's auto scaling functionality (which relies on information from Telemetry). Due to the fact that you can use Orchestration to spin up a large number of instances to perform the compute-intensive processing, including Orchestration in a compute-focused architecture design is strongly recommended." msgstr "" #: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:563(para) +msgid "While OpenStack is a fairly complete collection of software projects for building a platform for cloud services, there are additional pieces of software that might need to be added to any given OpenStack design." +msgstr "" + +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:569(para) +msgid "OpenStack Networking (neutron) provides a wide variety of networking services for instances. There are many additional networking software packages that may be useful to manage the OpenStack components themselves. Some examples include HAProxy, keepalived, and various routing daemons (like Quagga). Some of these software packages, HAProxy in particular, are described in more detail in the <citetitle>OpenStack High Availability Guide</citetitle> (refer to the <link href=\"http://docs.openstack.org/high-availability-guide/content/ch-network.html\">Network controller cluster stack chapter</link> of the OpenStack High Availability Guide). For a general purpose OpenStack cloud, it is reasonably likely that the OpenStack infrastructure components will need to be highly available, and therefore networking software packages like HAProxy will need to be included." +msgstr "" + +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:586(para) +msgid "This includes software for providing clustering, logging, monitoring, and alerting. The factors for determining which software packages in this category should be selected is outside the scope of this design guide. This design guide focuses specifically on how the selected supplemental software solution impacts or affects the overall OpenStack cloud design." +msgstr "" + +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:593(para) +msgid "Clustering Software, such as Corosync or Pacemaker, is determined primarily by the availability design requirements. Therefore, the impact of including (or not including) these software packages is determined by the availability of the cloud infrastructure and the complexity of supporting the configuration after it is deployed. The <citetitle>OpenStack High Availability Guide</citetitle> provides more details on the installation and configuration of Corosync and Pacemaker, should these packages need to be included in the design." +msgstr "" + +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:602(para) +msgid "Requirements for logging, monitoring, and alerting are determined by operational considerations. Each of these sub-categories includes a number of various options. For example, in the logging sub-category one might consider Logstash, Splunk, Log Insight, or some other log aggregation-consolidation tool. Logs should be stored in a centralized location to make it easier to perform analytics against the data. Log data analytics engines can also provide automation and issue notification, by providing a mechanism to both alert and automatically attempt to remediate some of the more commonly known issues." +msgstr "" + +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:620(para) +msgid "OS-Hypervisor combination: Ensure that the selected logging, monitoring, or alerting tools support the proposed OS-hypervisor combination." +msgstr "" + +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:632(para) +msgid "Virtually all of the OpenStack components require access to back-end database services to store state and configuration information. Choose an appropriate back-end database which will satisfy the availability and fault tolerance requirements of the OpenStack services." +msgstr "" + +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:637(para) +msgid "MySQL is generally considered to be the de facto database for OpenStack, however, other compatible databases are also known to work. Note, however, that Telemetry uses MongoDB." +msgstr "" + +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:641(para) +msgid "The solution selected to provide high availability for the database will change based on the selected database. If MySQL is selected, then a number of options are available. For active-active clustering a replication technology such as Galera can be used. For active-passive some form of shared storage must be used. Each of these potential solutions has an impact on the design:" +msgstr "" + +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:650(para) +msgid "Solutions that employ Galera/MariaDB will require at least three MySQL nodes." +msgstr "" + +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:654(para) msgid "MongoDB will have its own design considerations, with regards to making the database highly available." msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:568(para) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:659(para) msgid "OpenStack design, generally, does not include shared storage but for a high availability design some components might require it depending on the specific implementation." msgstr "" @@ -5719,23 +5939,23 @@ msgstr "" msgid "Data compliance: Policies governing types of information that are required to reside in certain locations due to regular issues and cannot reside in other locations for the same reason." msgstr "" -#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:70(para) +#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:73(para) msgid "The following are some technical requirements that could be incorporated into the architecture design." msgstr "" -#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:74(para) +#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:77(para) msgid "Storage Proximity: In order to provide high performance or large amounts of storage space the design may have to accommodate storage that is each of the hypervisors or served from a central storage device." msgstr "" -#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:81(para) +#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:84(para) msgid "Performance: To boost performance the organization may want to make use of different technologies to cache disk activity." msgstr "" -#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:86(para) +#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:89(para) msgid "Availability: Specific requirements regarding availability will influence the technology used to store and protect data. These requirements will be influence the cost and solution that will be implemented." msgstr "" -#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:93(para) +#: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:96(para) msgid "Security: Data will need to be protected both in transit and at rest." msgstr "" diff --git a/doc/common/locale/common.pot b/doc/common/locale/common.pot index 3e6b6de3f6..7c884d72f0 100644 --- a/doc/common/locale/common.pot +++ b/doc/common/locale/common.pot @@ -1,7 +1,7 @@ msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" -"POT-Creation-Date: 2014-07-27 06:09+0000\n" +"POT-Creation-Date: 2014-07-28 06:07+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" "Language-Team: LANGUAGE <LL@li.org>\n" @@ -974,7 +974,7 @@ msgid "Write any buffered data to disk." msgstr "" #: ./doc/common/section_cli_nova_images.xml:20(para) -msgid "For more information, see the <link href=\"http://docs.openstack.org/openstack-ops/content/snapsnots.html\">Taking Snapshots</link> in the <citetitle>OpenStack Operations Guide</citetitle>." +msgid "For more information, see the <link href=\"http://docs.openstack.org/openstack-ops/content/snapshots.html\">Taking Snapshots</link> in the <citetitle>OpenStack Operations Guide</citetitle>." msgstr "" #: ./doc/common/section_cli_nova_images.xml:27(para) @@ -1754,7 +1754,7 @@ msgid "Common errors and fixes for Compute" msgstr "" #: ./doc/common/section_support-compute.xml:80(para) -msgid "The <link href=\"ask.openstack.org\">ask.openstack.org</link> site offers a place to ask and answer questions, and you can also mark questions as frequently asked questions. This section describes some errors people have posted previously. Bugs are constantly being fixed, so online resources are a great way to get the most up-to-date errors and fixes." +msgid "The <link href=\"http://ask.openstack.org\">ask.openstack.org</link> site offers a place to ask and answer questions, and you can also mark questions as frequently asked questions. This section describes some errors people have posted previously. Bugs are constantly being fixed, so online resources are a great way to get the most up-to-date errors and fixes." msgstr "" #: ./doc/common/section_support-compute.xml:88(title) @@ -8618,7 +8618,7 @@ msgid "Complete these steps to install OpenStack in your XenServer system:" msgstr "" #: ./doc/common/section_xen-install.xml:75(para) -msgid "For resize and migrate functionality, complete the changes described in the <citetitle>Configure resize</citetitle> section in the <link href=\"../config-reference/content/index.html\"><citetitle>OpenStack Configuration Reference</citetitle></link>." +msgid "For resize and migrate functionality, complete the changes described in the <citetitle>Configure resize</citetitle> section in the <link href=\"http://docs.openstack.org/trunk/config-reference/content/\"><citetitle>OpenStack Configuration Reference</citetitle></link>." msgstr "" #: ./doc/common/section_xen-install.xml:83(para) diff --git a/doc/common/locale/fr.po b/doc/common/locale/fr.po index 5bedf4cc00..27719d9e79 100644 --- a/doc/common/locale/fr.po +++ b/doc/common/locale/fr.po @@ -18,8 +18,8 @@ msgid "" msgstr "" "Project-Id-Version: OpenStack Manuals\n" -"POT-Creation-Date: 2014-07-27 05:14+0000\n" -"PO-Revision-Date: 2014-07-26 18:41+0000\n" +"POT-Creation-Date: 2014-07-28 05:37+0000\n" +"PO-Revision-Date: 2014-07-27 19:16+0000\n" "Last-Translator: openstackjenkins <jenkins@openstack.org>\n" "Language-Team: French (http://www.transifex.com/projects/p/openstack-manuals-i18n/language/fr/)\n" "MIME-Version: 1.0\n" @@ -1819,7 +1819,7 @@ msgstr "" #: ./doc/common/section_cli_nova_images.xml20(para) msgid "" "For more information, see the <link href=\"http://docs.openstack.org" -"/openstack-ops/content/snapsnots.html\">Taking Snapshots</link> in the " +"/openstack-ops/content/snapshots.html\">Taking Snapshots</link> in the " "<citetitle>OpenStack Operations Guide</citetitle>." msgstr "" @@ -2938,12 +2938,12 @@ msgstr "Erreurs Fréquentes et Solutions pour Calcul" #: ./doc/common/section_support-compute.xml80(para) msgid "" -"The <link href=\"ask.openstack.org\">ask.openstack.org</link> site offers a " -"place to ask and answer questions, and you can also mark questions as " -"frequently asked questions. This section describes some errors people have " -"posted previously. Bugs are constantly being fixed, so online resources are " -"a great way to get the most up-to-date errors and fixes." -msgstr "Le site <link href=\"ask.openstack.org\">ask.openstack.org</link> offre un endroit où poser et répondre aux questions, et vous pouvez également annoter des questions comme fréquemment posées. Cette section décrit certaines erreurs que des personnes ont postées précédemment. Comme nous corrigeons constamment les bugs, les ressources en ligne sont un excellent moyen pour obtenir le plus de mises à jour sur les erreurs et solutions." +"The <link href=\"http://ask.openstack.org\">ask.openstack.org</link> site " +"offers a place to ask and answer questions, and you can also mark questions " +"as frequently asked questions. This section describes some errors people " +"have posted previously. Bugs are constantly being fixed, so online resources" +" are a great way to get the most up-to-date errors and fixes." +msgstr "" #: ./doc/common/section_support-compute.xml88(title) msgid "Credential errors, 401, and 403 forbidden errors" @@ -12684,9 +12684,10 @@ msgstr "" #: ./doc/common/section_xen-install.xml75(para) msgid "" "For resize and migrate functionality, complete the changes described in the " -"<citetitle>Configure resize</citetitle> section in the <link href" -"=\"../config-reference/content/index.html\"><citetitle>OpenStack " -"Configuration Reference</citetitle></link>." +"<citetitle>Configure resize</citetitle> section in the <link " +"href=\"http://docs.openstack.org/trunk/config-" +"reference/content/\"><citetitle>OpenStack Configuration " +"Reference</citetitle></link>." msgstr "" #: ./doc/common/section_xen-install.xml83(para) diff --git a/doc/common/locale/ja.po b/doc/common/locale/ja.po index b86b8729d6..0a915dabf4 100644 --- a/doc/common/locale/ja.po +++ b/doc/common/locale/ja.po @@ -7,8 +7,8 @@ msgid "" msgstr "" "Project-Id-Version: OpenStack Manuals\n" -"POT-Creation-Date: 2014-07-27 05:14+0000\n" -"PO-Revision-Date: 2014-07-26 18:41+0000\n" +"POT-Creation-Date: 2014-07-28 05:37+0000\n" +"PO-Revision-Date: 2014-07-27 19:16+0000\n" "Last-Translator: openstackjenkins <jenkins@openstack.org>\n" "Language-Team: Japanese (http://www.transifex.com/projects/p/openstack-manuals-i18n/language/ja/)\n" "MIME-Version: 1.0\n" @@ -1808,9 +1808,9 @@ msgstr "バッファーデータをディスクに書き込みます。" #: ./doc/common/section_cli_nova_images.xml20(para) msgid "" "For more information, see the <link href=\"http://docs.openstack.org" -"/openstack-ops/content/snapsnots.html\">Taking Snapshots</link> in the " +"/openstack-ops/content/snapshots.html\">Taking Snapshots</link> in the " "<citetitle>OpenStack Operations Guide</citetitle>." -msgstr "詳細は <citetitle>OpenStack Operations Guide</citetitle> の <link href=\"http://docs.openstack.org/openstack-ops/content/snapsnots.html\">スナップショットの作成方法</link> を参照してください。" +msgstr "" #: ./doc/common/section_cli_nova_images.xml27(para) msgid "To create the image, list instances to get the server ID:" @@ -2927,11 +2927,11 @@ msgstr "" #: ./doc/common/section_support-compute.xml80(para) msgid "" -"The <link href=\"ask.openstack.org\">ask.openstack.org</link> site offers a " -"place to ask and answer questions, and you can also mark questions as " -"frequently asked questions. This section describes some errors people have " -"posted previously. Bugs are constantly being fixed, so online resources are " -"a great way to get the most up-to-date errors and fixes." +"The <link href=\"http://ask.openstack.org\">ask.openstack.org</link> site " +"offers a place to ask and answer questions, and you can also mark questions " +"as frequently asked questions. This section describes some errors people " +"have posted previously. Bugs are constantly being fixed, so online resources" +" are a great way to get the most up-to-date errors and fixes." msgstr "" #: ./doc/common/section_support-compute.xml88(title) @@ -12673,9 +12673,10 @@ msgstr "" #: ./doc/common/section_xen-install.xml75(para) msgid "" "For resize and migrate functionality, complete the changes described in the " -"<citetitle>Configure resize</citetitle> section in the <link href" -"=\"../config-reference/content/index.html\"><citetitle>OpenStack " -"Configuration Reference</citetitle></link>." +"<citetitle>Configure resize</citetitle> section in the <link " +"href=\"http://docs.openstack.org/trunk/config-" +"reference/content/\"><citetitle>OpenStack Configuration " +"Reference</citetitle></link>." msgstr "" #: ./doc/common/section_xen-install.xml83(para) diff --git a/doc/config-reference/locale/config-reference.pot b/doc/config-reference/locale/config-reference.pot index 6a007cbc2e..18cd7abba8 100644 --- a/doc/config-reference/locale/config-reference.pot +++ b/doc/config-reference/locale/config-reference.pot @@ -1,7 +1,7 @@ msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" -"POT-Creation-Date: 2014-07-22 06:10+0000\n" +"POT-Creation-Date: 2014-07-28 06:07+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" "Language-Team: LANGUAGE <LL@li.org>\n" @@ -14,7 +14,7 @@ msgid "Identity service" msgstr "" #: ./doc/config-reference/ch_identityconfigure.xml:8(para) -msgid "This chapter details the OpenStack Identity service configuration options. For installation prerequisites and step-by-step walkthroughs, see the <citetitle>OpenStack Installation Guide</citetitle> for your distribution (<link href=\"docs.openstack.org\">docs.openstack.org</link>) and <citetitle><link href=\"http://docs.openstack.org/admin-guide-cloud/content/\">Cloud Administrator Guide</link></citetitle>." +msgid "This chapter details the OpenStack Identity service configuration options. For installation prerequisites and step-by-step walkthroughs, see the <citetitle>OpenStack Installation Guide</citetitle> for your distribution (<link href=\"http://docs.openstack.org\">docs.openstack.org</link>) and <citetitle><link href=\"http://docs.openstack.org/admin-guide-cloud/content/\">Cloud Administrator Guide</link></citetitle>." msgstr "" #: ./doc/config-reference/ch_identityconfigure.xml:16(title) @@ -78,7 +78,7 @@ msgid "The Telemetry service collects measurements within OpenStack. Its various msgstr "" #: ./doc/config-reference/ch_telemetryconfigure.xml:11(para) -msgid "To install Telemetry, see the <citetitle>OpenStack Installation Guide</citetitle> for your distribution (<link href=\"docs.openstack.org\">docs.openstack.org</link>)." +msgid "To install Telemetry, see the <citetitle>OpenStack Installation Guide</citetitle> for your distribution (<link href=\"http://docs.openstack.org\">docs.openstack.org</link>)." msgstr "" #: ./doc/config-reference/ch_telemetryconfigure.xml:15(para) @@ -218,7 +218,7 @@ msgid "The Orchestration service is designed to manage the lifecycle of infrastr msgstr "" #: ./doc/config-reference/ch_orchestrationconfigure.xml:12(para) -msgid "To install Orchestration, see the <citetitle>OpenStack Installation Guide</citetitle> for your distribution (<link href=\"docs.openstack.org\">docs.openstack.org</link>)." +msgid "To install Orchestration, see the <citetitle>OpenStack Installation Guide</citetitle> for your distribution (<link href=\"http://docs.openstack.org\">docs.openstack.org</link>)." msgstr "" #: ./doc/config-reference/ch_orchestrationconfigure.xml:16(para) @@ -818,7 +818,7 @@ msgid "Networking" msgstr "" #: ./doc/config-reference/ch_networkingconfigure.xml:8(para) -msgid "This chapter explains the OpenStack Networking configuration options. For installation prerequisites, steps, and use cases, see the <citetitle>OpenStack Installation Guide</citetitle> for your distribution (<link href=\"docs.openstack.org\">docs.openstack.org</link>) and <citetitle><link href=\"http://docs.openstack.org/admin-guide-cloud/content/\">Cloud Administrator Guide</link></citetitle>." +msgid "This chapter explains the OpenStack Networking configuration options. For installation prerequisites, steps, and use cases, see the <citetitle>OpenStack Installation Guide</citetitle> for your distribution (<link href=\"http://docs.openstack.org\">docs.openstack.org</link>) and <citetitle><link href=\"http://docs.openstack.org/admin-guide-cloud/content/\">Cloud Administrator Guide</link></citetitle>." msgstr "" #: ./doc/config-reference/ch_dashboardconfigure.xml:7(title) @@ -6883,7 +6883,7 @@ msgid "RAW creates files without any sort of file formatting, effectively creati msgstr "" #: ./doc/config-reference/compute/section_compute-configure-backing-storage.xml:30(para) -msgid "Local <link href=\"http://http//en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux)\">LVM volumes</link> can also be used. Set <literal>images_volume_group = nova_local</literal> where <literal>nova_local</literal> is the name of the LVM group you have created." +msgid "Local <link href=\"http://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux)\">LVM volumes</link> can also be used. Set <literal>images_volume_group = nova_local</literal> where <literal>nova_local</literal> is the name of the LVM group you have created." msgstr "" #: ./doc/config-reference/compute/section_compute-configure-db.xml:6(title) @@ -6947,7 +6947,7 @@ msgid "[cells]" msgstr "" #: ./doc/config-reference/compute/section_nova-conf.xml:44(para) -msgid "Configures cells functionality. For details, see the Cells section (<link href=\"../config-reference/content/section_compute-cells.html\"/>)." +msgid "Configures cells functionality. For details, see the Cells section (<link href=\"http://docs.openstack.org/trunk/config-reference/content/section_compute-cells.html\"/>)." msgstr "" #: ./doc/config-reference/compute/section_nova-conf.xml:52(literal) diff --git a/doc/high-availability-guide/locale/high-availability-guide.pot b/doc/high-availability-guide/locale/high-availability-guide.pot index 0cb6a48d15..66fbaa6a11 100644 --- a/doc/high-availability-guide/locale/high-availability-guide.pot +++ b/doc/high-availability-guide/locale/high-availability-guide.pot @@ -1,7 +1,7 @@ msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" -"POT-Creation-Date: 2014-07-17 06:09+0000\n" +"POT-Creation-Date: 2014-07-28 06:07+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" "Language-Team: LANGUAGE <LL@li.org>\n" @@ -594,7 +594,7 @@ msgid "Manage OpenStack Image API daemon with the Pacemaker cluster manager." msgstr "" #: ./doc/high-availability-guide/api/section_glance_api.xml:29(para) -msgid "Here is the <link href=\"http://docs.openstack.org/trunk/install-guide/install/apt/content/ch_installing-openstack-image.html\">documentation</link> for installing OpenStack Image API service." +msgid "Here is the <link href=\"http://docs.openstack.org/trunk/install-guide/install/apt/content/ch_glance.html\">documentation</link> for installing OpenStack Image API service." msgstr "" #: ./doc/high-availability-guide/api/section_glance_api.xml:33(title) @@ -662,7 +662,7 @@ msgid "managing OpenStack Networking API Server daemon with the Pacemaker cluste msgstr "" #: ./doc/high-availability-guide/api/section_neutron_server.xml:29(para) -msgid "Here is the <link href=\"http://docs.openstack.org/trunk/install-guide/install/apt/content/ch_installing-openstack-networking.html\">documentation</link> for installing OpenStack Networking service." +msgid "Here is the <link href=\"http://docs.openstack.org/trunk/install-guide/install/apt/content/ch_networking.html\">documentation</link> for installing OpenStack Networking service." msgstr "" #: ./doc/high-availability-guide/api/section_neutron_server.xml:33(title) @@ -774,7 +774,7 @@ msgid "managing OpenStack Identity daemon with the Pacemaker cluster manager," msgstr "" #: ./doc/high-availability-guide/api/section_keystone.xml:29(para) -msgid "Here is the <link href=\"http://docs.openstack.org/trunk/install-guide/install/apt/content/ch_installing-openstack-identity-service.html\">documentation</link> for installing OpenStack Identity service." +msgid "Here is the <link href=\"http://docs.openstack.org/trunk/install-guide/install/apt/content/ch_keystone.html\">documentation</link> for installing OpenStack Identity service." msgstr "" #: ./doc/high-availability-guide/api/section_keystone.xml:33(title) @@ -1014,7 +1014,7 @@ msgid "managing all resources, including the MySQL daemon itself, with the Pacem msgstr "" #: ./doc/high-availability-guide/controller/section_mysql.xml:47(para) -msgid "<link href=\"http://codership.com/products/mysql_galera\">MySQL/Galera</link> is an alternative method of Configure MySQL for high availability. It is likely to become the preferred method of achieving MySQL high availability once it has sufficiently matured. At the time of writing, however, the Pacemaker/DRBD based approach remains the recommended one for OpenStack environments." +msgid "<link href=\"http://galeracluster.com/\">MySQL/Galera</link> is an alternative method of Configure MySQL for high availability. It is likely to become the preferred method of achieving MySQL high availability once it has sufficiently matured. At the time of writing, however, the Pacemaker/DRBD based approach remains the recommended one for OpenStack environments." msgstr "" #: ./doc/high-availability-guide/controller/section_mysql.xml:58(para) diff --git a/doc/high-availability-guide/locale/ja.po b/doc/high-availability-guide/locale/ja.po index 8f10333d91..8a8b3fa100 100644 --- a/doc/high-availability-guide/locale/ja.po +++ b/doc/high-availability-guide/locale/ja.po @@ -4,8 +4,8 @@ msgid "" msgstr "" "Project-Id-Version: OpenStack Manuals\n" -"POT-Creation-Date: 2014-07-16 19:09+0000\n" -"PO-Revision-Date: 2014-07-16 23:41+0000\n" +"POT-Creation-Date: 2014-07-28 05:37+0000\n" +"PO-Revision-Date: 2014-07-28 01:00+0000\n" "Last-Translator: Tomoyuki KATO <tomo@dream.daynight.jp>\n" "Language-Team: Japanese (http://www.transifex.com/projects/p/openstack-manuals-i18n/language/ja/)\n" "MIME-Version: 1.0\n" @@ -833,10 +833,9 @@ msgstr "Pacemaker クラスターマネージャーを用いた OpenStack Image #: ./doc/high-availability-guide/api/section_glance_api.xml29(para) msgid "" "Here is the <link href=\"http://docs.openstack.org/trunk/install-" -"guide/install/apt/content/ch_installing-openstack-" -"image.html\">documentation</link> for installing OpenStack Image API " -"service." -msgstr "ここに OpenStack Image API Service をインストールするための<link href=\"http://docs.openstack.org/trunk/install-guide/install/apt/content/ch_installing-openstack-image.html\">ドキュメント</link>があります。" +"guide/install/apt/content/ch_glance.html\">documentation</link> for " +"installing OpenStack Image API service." +msgstr "ここに OpenStack Image API Service をインストールするための<link href=\"http://docs.openstack.org/trunk/install-guide/install/apt/content/ch_glance.html\">ドキュメント</link>があります。" #: ./doc/high-availability-guide/api/section_glance_api.xml33(title) msgid "Add OpenStack Image API resource to Pacemaker" @@ -934,10 +933,9 @@ msgstr "Pacemaker クラスターマネージャーを用いた OpenStack Networ #: ./doc/high-availability-guide/api/section_neutron_server.xml29(para) msgid "" "Here is the <link href=\"http://docs.openstack.org/trunk/install-" -"guide/install/apt/content/ch_installing-openstack-" -"networking.html\">documentation</link> for installing OpenStack Networking " -"service." -msgstr "ここに OpenStack Networking Service をインストールするための<link href=\"http://docs.openstack.org/trunk/install-guide/install/apt/content/ch_installing-openstack-networking.html\">ドキュメント</link>があります。" +"guide/install/apt/content/ch_networking.html\">documentation</link> for " +"installing OpenStack Networking service." +msgstr "ここに OpenStack Networking Service をインストールするための<link href=\"http://docs.openstack.org/trunk/install-guide/install/apt/content/ch_networking.html\">ドキュメント</link>があります。" #: ./doc/high-availability-guide/api/section_neutron_server.xml33(title) msgid "Add OpenStack Networking Server resource to Pacemaker" @@ -1105,10 +1103,9 @@ msgstr "Pacemaker クラスターマネージャーを用いた OpenStack Identi #: ./doc/high-availability-guide/api/section_keystone.xml29(para) msgid "" "Here is the <link href=\"http://docs.openstack.org/trunk/install-" -"guide/install/apt/content/ch_installing-openstack-identity-" -"service.html\">documentation</link> for installing OpenStack Identity " -"service." -msgstr "ここに OpenStack Identity Service をインストールするための<link href=\"http://docs.openstack.org/trunk/install-guide/install/apt/content/ch_installing-openstack-identity-service.html\">ドキュメント</link>があります。" +"guide/install/apt/content/ch_keystone.html\">documentation</link> for " +"installing OpenStack Identity service." +msgstr "ここに OpenStack Identity Service をインストールするための<link href=\"http://docs.openstack.org/trunk/install-guide/install/apt/content/ch_keystone.html\">ドキュメント</link>があります。" #: ./doc/high-availability-guide/api/section_keystone.xml33(title) msgid "Add OpenStack Identity resource to Pacemaker" @@ -1491,14 +1488,13 @@ msgstr "Pacemaker クラスターマネージャーを用いて、MySQL デー #: ./doc/high-availability-guide/controller/section_mysql.xml47(para) msgid "" -"<link " -"href=\"http://codership.com/products/mysql_galera\">MySQL/Galera</link> is " -"an alternative method of Configure MySQL for high availability. It is likely" -" to become the preferred method of achieving MySQL high availability once it" -" has sufficiently matured. At the time of writing, however, the " +"<link href=\"http://galeracluster.com/\">MySQL/Galera</link> is an " +"alternative method of Configure MySQL for high availability. It is likely to" +" become the preferred method of achieving MySQL high availability once it " +"has sufficiently matured. At the time of writing, however, the " "Pacemaker/DRBD based approach remains the recommended one for OpenStack " "environments." -msgstr "<link href=\"http://codership.com/products/mysql_galera\">MySQL/Galera</link> は MySQL を高可用性に設定するもう一つの方法です。十分に成熟すれば、MySQL の高可用性を達成する好ましい方法になるでしょう。しかしながら、執筆時点では、Pacemaker/DRBD による方法が OpenStack 環境に対する推奨のものです。" +msgstr "<link href=\"http://galeracluster.com/\">MySQL/Galera</link> は MySQL を高可用性に設定するもう一つの方法です。十分に成熟すれば、MySQL の高可用性を達成する好ましい方法になるでしょう。しかしながら、執筆時点では、Pacemaker/DRBD による方法が OpenStack 環境に対する推奨のものです。" #: ./doc/high-availability-guide/controller/section_mysql.xml58(para) msgid "" diff --git a/doc/image-guide/locale/image-guide.pot b/doc/image-guide/locale/image-guide.pot index e40c6e097e..bb1b2fe357 100644 --- a/doc/image-guide/locale/image-guide.pot +++ b/doc/image-guide/locale/image-guide.pot @@ -1,7 +1,7 @@ msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" -"POT-Creation-Date: 2014-07-27 06:09+0000\n" +"POT-Creation-Date: 2014-07-28 06:07+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" "Language-Team: LANGUAGE <LL@li.org>\n" @@ -310,7 +310,7 @@ msgid "If the image has multiple partitions, use <placeholder-1/> to expose the msgstr "" #: ./doc/image-guide/ch_modifying_images.xml:295(para) -msgid "If the image has, say three partitions (/boot, /, /swap), there should be one new device created per partition:<placeholder-1/>To mount the second partition, as root:<placeholder-2/>Once you're done, to clean up:<placeholder-3/>" +msgid "If the image has, say three partitions (/boot, /, swap), there should be one new device created per partition:<placeholder-1/>To mount the second partition, as root:<placeholder-2/>Once you're done, to clean up:<placeholder-3/>" msgstr "" #: ./doc/image-guide/ch_modifying_images.xml:310(title) @@ -342,7 +342,7 @@ msgid "Assuming the first block device (<filename>/dev/nbd0</filename>) is not c msgstr "" #: ./doc/image-guide/ch_modifying_images.xml:348(para) -msgid "If the image has, say three partitions (/boot, /, /swap), there should be one new device created for each partition:" +msgid "If the image has, say three partitions (/boot, /, swap), there should be one new device created for each partition:" msgstr "" #: ./doc/image-guide/ch_modifying_images.xml:357(para) @@ -1406,7 +1406,7 @@ msgid "Microsoft Windows images" msgstr "" #: ./doc/image-guide/ch_obtaining_images.xml:102(para) -msgid "Cloudbase Solutions hosts an <link href=\"http://www.cloudbase.it/ws2012/\">OpenStack Windows Server 2012 Standard Evaluation image</link> that runs on Hyper-V, KVM, and XenServer/XCP." +msgid "Cloudbase Solutions hosts an <link href=\"http://www.cloudbase.it/ws2012r2/\">OpenStack Windows Server 2012 Standard Evaluation image</link> that runs on Hyper-V, KVM, and XenServer/XCP." msgstr "" #. When image changes, this message will be marked fuzzy or untranslated for you. @@ -1610,7 +1610,7 @@ msgid "img-uuid" msgstr "" #: ./doc/image-guide/section_glance-image-metadata.xml:23(para) -msgid "Common image properties are also specified in the <filename>/etc/glance/schema-image.json</filename> file. For a complete list of valid property keys and values, refer to the <link href=\"http://docs.openstack.org/cli-reference/content/image-metadata.html\"><citetitle>OpenStack Command-Line Reference</citetitle></link>." +msgid "Common image properties are also specified in the <filename>/etc/glance/schema-image.json</filename> file. For a complete list of valid property keys and values, refer to the <link href=\"http://docs.openstack.org/cli-reference/content/chapter_cli-glance-property.html\"><citetitle>OpenStack Command-Line Reference</citetitle></link>." msgstr "" #: ./doc/image-guide/section_glance-image-metadata.xml:28(para) diff --git a/doc/install-guide/locale/install-guide.pot b/doc/install-guide/locale/install-guide.pot index 1630a995e4..8fa4c8bc13 100644 --- a/doc/install-guide/locale/install-guide.pot +++ b/doc/install-guide/locale/install-guide.pot @@ -1,7 +1,7 @@ msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" -"POT-Creation-Date: 2014-07-27 06:09+0000\n" +"POT-Creation-Date: 2014-07-28 06:07+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" "Language-Team: LANGUAGE <LL@li.org>\n" @@ -3041,7 +3041,7 @@ msgid "Install required packages:" msgstr "" #: ./doc/install-guide/section_trove-install.xml:34(para) -msgid "Respond to the prompts for <link href=\"debconf-dbconfig-common\">database management</link> and <link href=\"debconf-keystone_authtoken\"><literal>[keystone_authtoken]</literal> settings</link>, and <link href=\"debconf-api-endpoints\">API endpoint</link> registration. The <placeholder-1/> command runs automatically." +msgid "Respond to the prompts for <link linkend=\"debconf-dbconfig-common\">database management</link> and <link linkend=\"debconf-keystone_authtoken\"><literal>[keystone_authtoken]</literal> settings</link>, and <link linkend=\"debconf-api-endpoints\">API endpoint</link> registration. The <placeholder-1/> command runs automatically." msgstr "" #: ./doc/install-guide/section_trove-install.xml:40(para) diff --git a/doc/install-guide/locale/ja.po b/doc/install-guide/locale/ja.po index 539a3d494a..7cf81a43f3 100644 --- a/doc/install-guide/locale/ja.po +++ b/doc/install-guide/locale/ja.po @@ -5,8 +5,8 @@ msgid "" msgstr "" "Project-Id-Version: OpenStack Manuals\n" -"POT-Creation-Date: 2014-07-27 05:14+0000\n" -"PO-Revision-Date: 2014-07-25 16:19+0000\n" +"POT-Creation-Date: 2014-07-28 05:37+0000\n" +"PO-Revision-Date: 2014-07-28 05:51+0000\n" "Last-Translator: openstackjenkins <jenkins@openstack.org>\n" "Language-Team: Japanese (http://www.transifex.com/projects/p/openstack-manuals-i18n/language/ja/)\n" "MIME-Version: 1.0\n" @@ -5150,13 +5150,13 @@ msgstr "必要パッケージをインストールします。" #: ./doc/install-guide/section_trove-install.xml34(para) msgid "" -"Respond to the prompts for <link href=\"debconf-dbconfig-common\">database " -"management</link> and <link href=\"debconf-" +"Respond to the prompts for <link linkend=\"debconf-dbconfig-" +"common\">database management</link> and <link linkend=\"debconf-" "keystone_authtoken\"><literal>[keystone_authtoken]</literal> " -"settings</link>, and <link href=\"debconf-api-endpoints\">API " +"settings</link>, and <link linkend=\"debconf-api-endpoints\">API " "endpoint</link> registration. The <placeholder-1/> command runs " "automatically." -msgstr "" +msgstr "<link linkend=\"debconf-dbconfig-common\">データベース管理</link>、<link linkend=\"debconf-keystone_authtoken\"><literal>[keystone_authtoken]</literal> 設定</link>、<link linkend=\"debconf-api-endpoints\">API エンドポイント</link>登録に関するプロンプトに答えます。<placeholder-1/> コマンドが自動的に実行されます。" #: ./doc/install-guide/section_trove-install.xml40(para) msgid "Prepare OpenStack:" diff --git a/doc/user-guide/locale/fr.po b/doc/user-guide/locale/fr.po index 30c50ad5b5..1e771dfcdf 100644 --- a/doc/user-guide/locale/fr.po +++ b/doc/user-guide/locale/fr.po @@ -11,8 +11,8 @@ msgid "" msgstr "" "Project-Id-Version: OpenStack Manuals\n" -"POT-Creation-Date: 2014-07-24 02:16+0000\n" -"PO-Revision-Date: 2014-07-23 15:31+0000\n" +"POT-Creation-Date: 2014-07-28 05:37+0000\n" +"PO-Revision-Date: 2014-07-27 19:30+0000\n" "Last-Translator: openstackjenkins <jenkins@openstack.org>\n" "Language-Team: French (http://www.transifex.com/projects/p/openstack-manuals-i18n/language/fr/)\n" "MIME-Version: 1.0\n" @@ -3499,7 +3499,7 @@ msgstr "" #: ./doc/user-guide/section_cli_trove.xml253(para) msgid "" -"As background, assume that you have <link href=\"create_db\">created a " +"As background, assume that you have <link linkend=\"create_db\">created a " "database instance</link> with the following characteristics:" msgstr "" @@ -3688,9 +3688,9 @@ msgstr "" #: ./doc/user-guide/section_cli_trove.xml444(para) msgid "" -"Assume that you have <link href=\"backup_db\">created a regular " +"Assume that you have <link linkend=\"backup_db\">created a regular " "backup</link> for the following database instance:" -msgstr "" +msgstr "S'assurer que vous avez <link linkend=\"backup_db\">created a regular backup</link> pour l'instance de la base de donnée qui suit:" #: ./doc/user-guide/section_cli_trove.xml449(para) msgid "Instance name: <literal>guest1</literal>" @@ -3795,7 +3795,7 @@ msgstr "" #: ./doc/user-guide/section_cli_trove.xml557(para) msgid "" -"This example assumes you have <link href=\"create_db\">created a MySQL " +"This example assumes you have <link linkend=\"create_db\">created a MySQL " "database</link> and shows you how to use a configuration group to configure " "it. Although this example sets just one option on one database, you can use " "these same procedures to set multiple options on multiple database instances" @@ -4847,7 +4847,7 @@ msgid "" " users to ping and use SSH to connect to the instance. Security groups are " "sets of IP filter rules that define networking access and are applied to all" " instances within a project. To do so, you either <link " -"href=\"#security_groups_add_rule\">add rules to the default security " +"linkend=\"security_groups_add_rule\">add rules to the default security " "group</link> or add a new security group with rules." msgstr "" diff --git a/doc/user-guide/locale/ja.po b/doc/user-guide/locale/ja.po index c22e16b5ca..7aef0d5b7c 100644 --- a/doc/user-guide/locale/ja.po +++ b/doc/user-guide/locale/ja.po @@ -7,9 +7,9 @@ msgid "" msgstr "" "Project-Id-Version: OpenStack Manuals\n" -"POT-Creation-Date: 2014-07-25 00:50+0000\n" -"PO-Revision-Date: 2014-07-24 09:50+0000\n" -"Last-Translator: Tomoyuki KATO <tomo@dream.daynight.jp>\n" +"POT-Creation-Date: 2014-07-28 05:37+0000\n" +"PO-Revision-Date: 2014-07-27 19:30+0000\n" +"Last-Translator: openstackjenkins <jenkins@openstack.org>\n" "Language-Team: Japanese (http://www.transifex.com/projects/p/openstack-manuals-i18n/language/ja/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -3495,9 +3495,9 @@ msgstr "" #: ./doc/user-guide/section_cli_trove.xml253(para) msgid "" -"As background, assume that you have <link href=\"create_db\">created a " +"As background, assume that you have <link linkend=\"create_db\">created a " "database instance</link> with the following characteristics:" -msgstr "" +msgstr "背景として、以下の特性を持つ<link linkend=\"create_db\">データベースインスタンスを作成</link>してあることを仮定しています。" #: ./doc/user-guide/section_cli_trove.xml257(para) msgid "Name of the database instance: <literal>guest1</literal>" @@ -3684,9 +3684,9 @@ msgstr "" #: ./doc/user-guide/section_cli_trove.xml444(para) msgid "" -"Assume that you have <link href=\"backup_db\">created a regular " +"Assume that you have <link linkend=\"backup_db\">created a regular " "backup</link> for the following database instance:" -msgstr "" +msgstr "以下のデータベースインスタンスに対して、<link linkend=\"backup_db\">バックアップが作成されている</link>ことを仮定しています。" #: ./doc/user-guide/section_cli_trove.xml449(para) msgid "Instance name: <literal>guest1</literal>" @@ -3791,7 +3791,7 @@ msgstr "" #: ./doc/user-guide/section_cli_trove.xml557(para) msgid "" -"This example assumes you have <link href=\"create_db\">created a MySQL " +"This example assumes you have <link linkend=\"create_db\">created a MySQL " "database</link> and shows you how to use a configuration group to configure " "it. Although this example sets just one option on one database, you can use " "these same procedures to set multiple options on multiple database instances" @@ -4843,9 +4843,9 @@ msgid "" " users to ping and use SSH to connect to the instance. Security groups are " "sets of IP filter rules that define networking access and are applied to all" " instances within a project. To do so, you either <link " -"href=\"#security_groups_add_rule\">add rules to the default security " +"linkend=\"security_groups_add_rule\">add rules to the default security " "group</link> or add a new security group with rules." -msgstr "インスタンスの起動前に、ユーザーがインスタンスに ping と SSH を実行できるよう、セキュリティグループのルールを追加すべきです。セキュリティグループは、ネットワークアクセスを定義し、プロジェクト内のすべてのインスタンスに適用される、IP フィルタールール群です。そうする場合、<link href=\"#security_groups_add_rule\">default セキュリティグループにルールを追加する</link> か、ルールを持つ新しいセキュリティグループを追加します。" +msgstr "" #: ./doc/user-guide/section_dashboard_access_and_security.xml15(para) msgid "" diff --git a/doc/user-guide/locale/user-guide.pot b/doc/user-guide/locale/user-guide.pot index b34f6e0da7..f33b425040 100644 --- a/doc/user-guide/locale/user-guide.pot +++ b/doc/user-guide/locale/user-guide.pot @@ -1,7 +1,7 @@ msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" -"POT-Creation-Date: 2014-07-24 06:09+0000\n" +"POT-Creation-Date: 2014-07-28 06:08+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" @@ -2642,7 +2642,7 @@ msgid "Backup the database instance" msgstr "" #: ./doc/user-guide/section_cli_trove.xml:253(para) -msgid "As background, assume that you have <link href=\"create_db\">created a database instance</link> with the following characteristics:" +msgid "As background, assume that you have <link linkend=\"create_db\">created a database instance</link> with the following characteristics:" msgstr "" #: ./doc/user-guide/section_cli_trove.xml:257(para) @@ -2770,7 +2770,7 @@ msgid "Assumptions" msgstr "" #: ./doc/user-guide/section_cli_trove.xml:444(para) -msgid "Assume that you have <link href=\"backup_db\">created a regular backup</link> for the following database instance:" +msgid "Assume that you have <link linkend=\"backup_db\">created a regular backup</link> for the following database instance:" msgstr "" #: ./doc/user-guide/section_cli_trove.xml:449(para) @@ -2842,7 +2842,7 @@ msgid "You can manage database configuration tasks by using configuration groups msgstr "" #: ./doc/user-guide/section_cli_trove.xml:557(para) -msgid "This example assumes you have <link href=\"create_db\">created a MySQL database</link> and shows you how to use a configuration group to configure it. Although this example sets just one option on one database, you can use these same procedures to set multiple options on multiple database instances throughout your environment. This can provide significant time savings in managing your cloud." +msgid "This example assumes you have <link linkend=\"create_db\">created a MySQL database</link> and shows you how to use a configuration group to configure it. Although this example sets just one option on one database, you can use these same procedures to set multiple options on multiple database instances throughout your environment. This can provide significant time savings in managing your cloud." msgstr "" #: ./doc/user-guide/section_cli_trove.xml:563(title) @@ -3670,7 +3670,7 @@ msgid "For details about how to install the clients, see <link linkend=\"install msgstr "" #: ./doc/user-guide/section_dashboard_access_and_security.xml:9(para) -msgid "Before you launch an instance, you should add security group rules to enable users to ping and use SSH to connect to the instance. Security groups are sets of IP filter rules that define networking access and are applied to all instances within a project. To do so, you either <link href=\"#security_groups_add_rule\">add rules to the default security group</link> or add a new security group with rules." +msgid "Before you launch an instance, you should add security group rules to enable users to ping and use SSH to connect to the instance. Security groups are sets of IP filter rules that define networking access and are applied to all instances within a project. To do so, you either <link linkend=\"security_groups_add_rule\">add rules to the default security group</link> or add a new security group with rules." msgstr "" #: ./doc/user-guide/section_dashboard_access_and_security.xml:15(para)