diff --git a/doc/admin-guide-cloud/locale/admin-guide-cloud.pot b/doc/admin-guide-cloud/locale/admin-guide-cloud.pot index f0e9a08385..57b5ea714b 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: 2015-02-09 06:10+0000\n" +"POT-Creation-Date: 2015-02-10 06:20+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" @@ -1219,214 +1219,234 @@ msgid "Block storage" msgstr "" #: ./doc/admin-guide-cloud/ch_compute.xml:185(para) -msgid "OpenStack provides two classes of block storage: ephemeral storage and persistent volumes. Volumes are persistent virtualized block devices independent of any particular instance." +msgid "OpenStack provides two classes of the block storage: ephemeral storage and persistent volume." msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:189(para) -msgid "Ephemeral storage is associated with a single unique instance, and it exists only for the life of that instance. The amount of ephemeral storage is defined by the flavor of the instance. Generally, the root file system for an instance will be stored on ephemeral storage. It persists across reboots of the guest operating system, but when the instance is deleted, the ephemeral storage is also removed." +#: ./doc/admin-guide-cloud/ch_compute.xml:189(title) +msgid "Ephemeral storage" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:197(para) -msgid "In addition to the ephemeral root volume, all flavors except the smallest, m1.tiny, also provide an additional ephemeral block device of between 20 and 160GB. These sizes can be configured to suit your environment. This is presented as a raw block device with no partition table or file system. Cloud-aware operating system images can discover, format, and mount these storage devices. For example, the cloud-init package included in Ubuntu's stock cloud images format this space as an ext3 file system and mount it on /mnt. This is a feature of the guest operating system you are using, and is not an OpenStack mechanism. OpenStack only provisions the raw storage." +#: ./doc/admin-guide-cloud/ch_compute.xml:190(para) +msgid "An ephemeral storage includes a root ephemeral volume and an additional ephemeral volume." msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:212(para) -msgid "Persistent volumes are created by users and their size is limited only by the user's quota and availability limits. Upon initial creation, volumes are raw block devices without a partition table or a file system. To partition or format volumes, you must attach them to an instance. Once they are attached to an instance, you can use persistent volumes in much the same way as you would use external hard disk drive. You can attach volumes to only one instance at a time, although you can detach and reattach volumes to as many different instances as you like." +#: ./doc/admin-guide-cloud/ch_compute.xml:193(para) +msgid "The root disk is associated with an instance, and exists only for the life of this very instance. Generally, it is used to store an instance`s root file system, persists across the guest operating system reboots, and is removed on an instance deletion. The amount of the root ephemeral volume is defined by the flavor of an instance." msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:223(para) -msgid "You can configure persistent volumes as bootable and use them to provide a persistent virtual instance similar to traditional non-cloud-based virtualization systems. It is still possible for the resulting instance to also have ephemeral storage, depending on the flavor selected. In this case, the root file system can be on the persistent volume and its state maintained even if the instance is shut down. For more information about this type of configuration, see the OpenStack Configuration Reference." +#: ./doc/admin-guide-cloud/ch_compute.xml:201(para) +msgid "In addition to the ephemeral root volume, all default types of flavors, except m1.tiny, which is the smallest one, provide an additional ephemeral block device sized between 20 and 160GB (a configurable value to suit an environment). It is represented as a raw block device with no partition table or file system. A cloud-aware operating system can discover, format, and mount such a storage device. OpenStack Compute defines the default file system for different operating systems as Ext4 for Linux distributions, VFAT for non-Linux and non-Windows operating systems, and NTFS for Windows. However, it is possible to specify any other filesystem type by using virt_mkfs or default_ephemeral_format configuration options." msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:236(para) -msgid "Persistent volumes do not provide concurrent access from multiple instances. That type of configuration requires a traditional network file system like NFS or CIFS, or a cluster file system such as GlusterFS. These systems can be built within an OpenStack cluster or provisioned outside of it, but OpenStack software does not provide these features." +#: ./doc/admin-guide-cloud/ch_compute.xml:216(para) +msgid "For example, the cloud-init package included into an Ubuntu's stock cloud image, by default, formats this space as an Ext4 file system and mounts it on /mnt. This is a cloud-init feature, and is not an OpenStack mechanism. OpenStack only provisions the raw storage." msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:246(title) -msgid "EC2 compatibility API" +#: ./doc/admin-guide-cloud/ch_compute.xml:226(title) +msgid "Persistent volume" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:247(para) -msgid "In addition to the native compute API, OpenStack provides an EC2-compatible API. This API allows EC2 legacy workflows built for EC2 to work with OpenStack. For more information and configuration options about this compatibility API, see the OpenStack Configuration Reference." +#: ./doc/admin-guide-cloud/ch_compute.xml:227(para) +msgid "A persistent volume is represented by a persistent virtualized block device independent of any particular instance, and provided by OpenStack Block Storage." +msgstr "" + +#: ./doc/admin-guide-cloud/ch_compute.xml:230(para) +msgid "A persistent volume is created by a user, and its size is limited only by a user's quota and availability limits. Upon initial creation, a volume is a raw block device without a partition table or a file system. To partition or format a volume, you must attach it to an instance. Once it is attached, it can be used the same way as an external hard disk drive. A single volume can be attached to one instance at a time, though you can detach and reattach it to other instances as many times as required." +msgstr "" + +#: ./doc/admin-guide-cloud/ch_compute.xml:241(para) +msgid "You can configure a persistent volume as bootable and use it to provide a persistent virtual instance similar to the traditional non-cloud-based virtualization system. It is still possible for the resulting instance to keep ephemeral storage, depending on the flavor selected. In this case, the root file system can be on the persistent volume, and its state is maintained, even if the instance is shut down. For more information about this type of configuration, see the OpenStack Configuration Reference." msgstr "" #: ./doc/admin-guide-cloud/ch_compute.xml:254(para) +msgid "A persistent volume does not provide concurrent access from multiple instances. That type of configuration requires a traditional network file system like NFS, or CIFS, or a cluster file system such as GlusterFS. These systems can be built within an OpenStack cluster, or provisioned outside of it, but OpenStack software does not provide these features." +msgstr "" + +#: ./doc/admin-guide-cloud/ch_compute.xml:266(title) +msgid "EC2 compatibility API" +msgstr "" + +#: ./doc/admin-guide-cloud/ch_compute.xml:267(para) +msgid "In addition to the native compute API, OpenStack provides an EC2-compatible API. This API allows EC2 legacy workflows built for EC2 to work with OpenStack. For more information and configuration options about this compatibility API, see the OpenStack Configuration Reference." +msgstr "" + +#: ./doc/admin-guide-cloud/ch_compute.xml:274(para) msgid "Numerous third-party tools and language-specific SDKs can be used to interact with OpenStack clouds, using both native and compatibility APIs. Some of the more popular third-party tools are:" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:260(term) +#: ./doc/admin-guide-cloud/ch_compute.xml:280(term) msgid "Euca2ools" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:262(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:282(para) msgid "A popular open source command-line tool for interacting with the EC2 API. This is convenient for multi-cloud environments where EC2 is the common API, or for transitioning from EC2-based clouds to OpenStack. For more information, see the euca2ools site." msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:273(term) +#: ./doc/admin-guide-cloud/ch_compute.xml:293(term) msgid "Hybridfox" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:275(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:295(para) msgid "A Firefox browser add-on that provides a graphical interface to many popular public and private cloud technologies, including OpenStack. For more information, see the hybridfox site." msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:284(term) +#: ./doc/admin-guide-cloud/ch_compute.xml:304(term) msgid "boto" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:286(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:306(para) msgid "A Python library for interacting with Amazon Web Services. It can be used to access OpenStack through the EC2 compatibility API. For more information, see the boto project page on GitHub." msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:295(term) +#: ./doc/admin-guide-cloud/ch_compute.xml:315(term) msgid "fog" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:297(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:317(para) msgid "A Ruby cloud services library. It provides methods for interacting with a large number of cloud and virtualization platforms, including OpenStack. For more information, see the fog site." msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:306(term) +#: ./doc/admin-guide-cloud/ch_compute.xml:326(term) msgid "php-opencloud" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:308(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:328(para) msgid "A PHP SDK designed to work with most OpenStack- based cloud deployments, as well as Rackspace public cloud. For more information, see the php-opencloud site." msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:319(title) +#: ./doc/admin-guide-cloud/ch_compute.xml:339(title) msgid "Building blocks" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:320(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:340(para) msgid "In OpenStack the base operating system is usually copied from an image stored in the OpenStack Image Service. This is the most common case and results in an ephemeral instance that starts from a known template state and loses all accumulated states on virtual machine deletion. It is also possible to put an operating system on a persistent volume in the Cinder volume system. This gives a more traditional persistent system that accumulates states, which are preserved on the Cinder volume across the deletion and re-creation of the virtual machine. To get a list of available images on your system run: " msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:340(para) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:25(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:360(para) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:25(para) msgid "The displayed image attributes are:" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:343(literal) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:28(literal) ./doc/admin-guide-cloud/compute/section_compute-networking-nova.xml:572(replaceable) +#: ./doc/admin-guide-cloud/ch_compute.xml:363(literal) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:28(literal) ./doc/admin-guide-cloud/compute/section_compute-networking-nova.xml:572(replaceable) msgid "ID" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:345(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:365(para) msgid "Automatically generated UUID of the image" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:350(literal) ./doc/admin-guide-cloud/blockstorage/section_ts_eql_volume_size.xml:111(entry) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:34(literal) +#: ./doc/admin-guide-cloud/ch_compute.xml:370(literal) ./doc/admin-guide-cloud/blockstorage/section_ts_eql_volume_size.xml:111(entry) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:34(literal) msgid "Name" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:352(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:372(para) msgid "Free form, human-readable name for image" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:357(literal) ./doc/admin-guide-cloud/blockstorage/section_ts_eql_volume_size.xml:112(entry) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:40(literal) +#: ./doc/admin-guide-cloud/ch_compute.xml:377(literal) ./doc/admin-guide-cloud/blockstorage/section_ts_eql_volume_size.xml:112(entry) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:40(literal) msgid "Status" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:359(para) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:42(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:379(para) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:42(para) msgid "The status of the image. Images marked ACTIVE are available for use." msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:365(literal) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:48(literal) +#: ./doc/admin-guide-cloud/ch_compute.xml:385(literal) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:48(literal) msgid "Server" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:367(para) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:50(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:387(para) ./doc/admin-guide-cloud/compute/section_compute-instance-building-blocks.xml:50(para) msgid "For images that are created as snapshots of running instances, this is the UUID of the instance the snapshot derives from. For uploaded images, this field is blank." msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:374(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:394(para) msgid "Virtual hardware templates are called flavors. The default installation provides five flavors. By default, these are configurable by admin users, however that behavior can be changed by redefining the access controls for compute_extension:flavormanage in /etc/nova/policy.json on the compute-api server." msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:382(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:402(para) msgid "For a list of flavors that are available on your system:" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:396(title) +#: ./doc/admin-guide-cloud/ch_compute.xml:416(title) msgid "Compute service architecture" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:397(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:417(para) msgid "These basic categories describe the service architecture and information about the cloud controller." msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:400(title) +#: ./doc/admin-guide-cloud/ch_compute.xml:420(title) msgid "API server" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:401(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:421(para) msgid "At the heart of the cloud framework is an API server, which makes command and control of the hypervisor, storage, and networking programmatically available to users." msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:404(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:424(para) msgid "The API endpoints are basic HTTP web services which handle authentication, authorization, and basic command and control functions using various API interfaces under the Amazon, Rackspace, and related models. This enables API compatibility with multiple existing tool sets created for interaction with offerings from other vendors. This broad compatibility prevents vendor lock-in." msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:415(title) +#: ./doc/admin-guide-cloud/ch_compute.xml:435(title) msgid "Message queue" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:416(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:436(para) msgid "A messaging queue brokers the interaction between compute nodes (processing), the networking controllers (software which controls network infrastructure), API endpoints, the scheduler (determines which physical hardware to allocate to a virtual resource), and similar components. Communication to and from the cloud controller is handled by HTTP requests through multiple API endpoints." msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:425(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:445(para) msgid "A typical message passing event begins with the API server receiving a request from a user. The API server authenticates the user and ensures that they are permitted to issue the subject command. The availability of objects implicated in the request is evaluated and, if available, the request is routed to the queuing engine for the relevant workers. Workers continually listen to the queue based on their role, and occasionally their type host name. When an applicable work request arrives on the queue, the worker takes assignment of the task and begins executing it. Upon completion, a response is dispatched to the queue which is received by the API server and relayed to the originating user. Database entries are queried, added, or removed as necessary during the process." msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:441(title) +#: ./doc/admin-guide-cloud/ch_compute.xml:461(title) msgid "Compute worker" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:442(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:462(para) msgid "Compute workers manage computing instances on host machines. The API dispatches commands to compute workers to complete these tasks:" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:447(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:467(para) msgid "Run instances" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:450(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:470(para) msgid "Terminate instances" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:453(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:473(para) msgid "Reboot instances" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:456(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:476(para) msgid "Attach volumes" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:459(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:479(para) msgid "Detach volumes" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:462(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:482(para) msgid "Get console output" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:467(title) +#: ./doc/admin-guide-cloud/ch_compute.xml:487(title) msgid "Network Controller" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:468(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:488(para) msgid "The Network Controller manages the networking resources on host machines. The API server dispatches commands through the message queue, which are subsequently processed by Network Controllers. Specific operations include:" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:475(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:495(para) msgid "Allocate fixed IP addresses" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:478(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:498(para) msgid "Configuring VLANs for projects" msgstr "" -#: ./doc/admin-guide-cloud/ch_compute.xml:481(para) +#: ./doc/admin-guide-cloud/ch_compute.xml:501(para) msgid "Configuring networks for compute nodes" msgstr "" diff --git a/doc/arch-design/locale/arch-design.pot b/doc/arch-design/locale/arch-design.pot index c24b3a54d0..9ddcf034de 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: 2015-02-09 06:10+0000\n" +"POT-Creation-Date: 2015-02-10 06:20+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" @@ -751,7 +751,7 @@ msgstr "" msgid "The OpenStack dashboard, OpenStack Identity, and OpenStack Object Storage services are components that can each be deployed centrally in order to serve multiple regions." msgstr "" -#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:53(title) ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:155(para) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:22(para) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:131(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:18(para) +#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:53(title) ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:155(para) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:22(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:27(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:51(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 "" @@ -791,7 +791,7 @@ msgstr "" msgid "Networking decisions include the encapsulation mechanism that will be used for the tenant networks, how large the broadcast domains should be, and the contracted SLAs for the interconnects." msgstr "" -#: ./doc/arch-design/multi_site/section_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/generalpurpose/section_tech_considerations_general_purpose.xml:328(term) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:12(title) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:8(title) ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:8(title) ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:52(title) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:8(title) +#: ./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/generalpurpose/section_tech_considerations_general_purpose.xml:416(term) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:12(title) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:8(title) ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:8(title) ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml:52(title) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:8(title) msgid "User requirements" msgstr "" @@ -907,7 +907,7 @@ msgstr "" msgid "Replication" msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:158(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:685(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:286(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:126(para) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:158(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:792(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:286(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:126(para) msgid "Management" msgstr "" @@ -1161,7 +1161,7 @@ msgstr "" msgid "Depending on the storage model chosen during site design, storage replication and availability will also be a concern for end-users. If an application is capable of understanding regions, then it is possible to keep the object storage system separated by region. In this case, users who want to have an object available to more than one region will need to do the cross-site replication themselves. With a centralized swift proxy, however, the user may need to benchmark the replication timing of the Object Storage back end. Benchmarking allows the operational staff to provide users with an understanding of the amount of time required for a stored or modified object to become available to the entire environment." msgstr "" -#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:114(title) ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:432(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:387(term) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:120(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:493(title) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:96(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:177(term) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:257(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:253(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:19(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:48(term) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:105(term) +#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:114(title) ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:432(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:387(term) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:120(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:590(title) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:96(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:177(term) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:257(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:253(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:19(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:48(term) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:105(term) msgid "Performance" msgstr "" @@ -1177,7 +1177,7 @@ msgstr "" msgid "Storage availability can also be impacted by the architecture of a multi-site deployment. A centralized Object Storage service requires more time for an object to be available to instances locally in regions where the object was not created. Some applications may need to be tuned to account for this effect. Block Storage does not currently have a method for replicating data across multiple regions, so applications that depend on available block storage will need to manually cope with this limitation by creating duplicate block storage entries in each region." msgstr "" -#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:139(title) ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:163(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:630(term) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:191(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:671(title) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:160(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:435(term) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:268(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:107(title) ./doc/arch-design/storage_focus/section_tech_considerations_storage_focus.xml:50(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:471(term) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:123(term) +#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:139(title) ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:163(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:630(term) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:191(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:778(title) ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml:160(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:435(term) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:268(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:107(title) ./doc/arch-design/storage_focus/section_tech_considerations_storage_focus.xml:50(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:471(term) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:123(term) msgid "Security" msgstr "" @@ -1193,7 +1193,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:560(para) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:667(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:414(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:366(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:472(title) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:360(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:394(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:512(title) +#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:169(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:560(para) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:667(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:505(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:366(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:472(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 "" @@ -1457,7 +1457,7 @@ msgstr "" msgid "Selecting the type of networking technology to implement depends on many factors. OpenStack Networking (neutron) and legacy networking (nova-network) both have their advantages and disadvantages. They are both valid and supported options that fit different use cases as described in the following table." msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:344(th) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:344(th) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:176(term) msgid "Legacy networking (nova-network)" msgstr "" @@ -1921,11 +1921,11 @@ msgstr "" msgid "Hardware selection involves three key areas:" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:16(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/generalpurpose/section_tech_considerations_general_purpose.xml:17(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:41(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:19(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/generalpurpose/section_tech_considerations_general_purpose.xml:22(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:46(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:15(para) msgid "Network" msgstr "" @@ -2233,7 +2233,7 @@ msgstr "" msgid "The network design should encompass a physical and logical network design that can be easily expanded upon. Network hardware should offer the appropriate types of interfaces and speeds that are required by the hardware nodes." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:531(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:588(title) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:113(term) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:531(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:696(title) ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml:113(term) msgid "Availability" msgstr "" @@ -2241,7 +2241,7 @@ msgstr "" msgid "To ensure that access to nodes within the cloud is not interrupted, we recommend that the network architecture identify any single points of failure and provide some level of redundancy or fault tolerance. With regard to the network infrastructure itself, this often involves use of networking protocols such as LACP, VRRP or others to achieve a highly available network connection. In addition, it is important to consider the networking implications on API availability. In order to ensure that the APIs, and potentially other services in the cloud are highly available, we recommend you design a load balancing solution within the network architecture to accommodate for these requirements." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:552(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:294(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:358(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:386(title) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:552(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:343(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:358(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:386(title) msgid "Software selection" msgstr "" @@ -2253,7 +2253,7 @@ msgstr "" msgid "Operating system (OS) and hypervisor" msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:563(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:454(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:369(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:524(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:397(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:562(title) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:563(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:549(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:369(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:524(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 "" @@ -2309,7 +2309,7 @@ msgstr "" msgid "Determine which features of OpenStack are required. This will often determine the selection of the OS-hypervisor combination. Some features are only available with specific OSs or hypervisors. For example, if certain features are not available, the design might need to be modified to meet the user requirements." msgstr "" -#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:653(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:343(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:457(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:495(term) +#: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:653(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:431(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:457(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:495(term) msgid "Interoperability" msgstr "" @@ -2716,403 +2716,483 @@ msgid "OpenStack Networking can be used to control hardware load balancers throu msgstr "" #: ./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." +msgid "General purpose clouds are often expected to include these base services:" msgstr "" -#: ./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:34(title) -msgid "Designing compute resources" +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:32(para) +msgid "Each of these services has different resource requirements. As a result, you must make design decisions relating directly to the service, as well as provide a balanced infrastructure for all services." msgstr "" #: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:35(para) -msgid "We recommend you 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." +msgid "Consider the unique aspects of each service that requires design since individual characteristics and service mass can impact the hardware selection process. Hardware designs are generated for each type of the following resource pools:" msgstr "" -#: ./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, we recommend you 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 machine 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." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:56(para) +msgid "Hardware decisions are also made in relation to network architecture and facilities planning. These factors play heavily into the overall architecture of an OpenStack cloud." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml: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." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:61(title) +msgid "Designing compute resources" msgstr "" #: ./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." +msgid "When designing compute resource pools, a number of factors can impact your design decisions. For example, decisions related to processors, memory, and storage within each hypervisor are just one element of designing compute resources. In addition, decide whether to provide compute resources in a single pool or in multiple pools. We recommend the compute design allocates multiple pools of resources to be addressed on-demand." msgstr "" #: ./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 10 2 16) total m1.small instances. By the same reasoning, using the default memory overcommit ratio of 1.5:1 you can determine that the server will need at least 853GB (640 2,048MB / 1.5) of RAM. When sizing nodes for memory, it is also important to consider the additional memory required to service operating system and service needs." +msgid "A compute design that allocates multiple pools of resources makes best use of application resources running in the cloud. Each independent resource pool should be designed to provide service for specific flavors of instances or groupings of flavors. Designing multiple resource pools helps to ensure that, as instances are scheduled onto compute hypervisors, each independent node's resources will be allocated to make the most efficient use of available hardware. This is commonly referred to as bin packing." msgstr "" -#: ./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." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:78(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: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 refer 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." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:85(para) +msgid "An overcommit ratio is the ratio of available virtual resources, compared to the available physical resources. OpenStack is able to configure the overcommit ratio for CPU and memory. The default CPU overcommit ratio is 16:1 and the default memory overcommit ratio is 1.5:1. Determining the tuning of the overcommit ratios for both of these options during the design phase is important as it has a direct impact on the hardware layout of your compute nodes." msgstr "" -#: ./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." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:92(para) +msgid "For example, consider a m1.small instance uses 1 vCPU, 20GB of ephemeral storage and 2,048MB of RAM. When designing a hardware node as a compute resource pool to service instances, take into consideration the number of processor cores available on the node as well as the required disk and memory to service instances running at capacity. For a server with 2 CPUs of 10 cores each, with hyperthreading turned on, the default CPU overcommit ratio of 16:1 would allow for 640 (2 10 2 16) total m1.small instances. By the same reasoning, using the default memory overcommit ratio of 1.5:1 you can determine that the server will need at least 853GB (640 2,048MB / 1.5) of RAM. When sizing nodes for memory, it is also important to consider the additional memory required to service operating system and service needs." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:115(title) -msgid "Designing network resources" +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:106(para) +msgid "Processor selection is an extremely important consideration in hardware design, especially when comparing the features and performance characteristics of different processors. Processors can include features specific to virtualized compute hosts including hardware assisted virtualization and technology related to memory paging (also known as EPT shadowing). These types of features can have a significant impact on the performance of your virtual machine running in the cloud." msgstr "" -#: ./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." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:113(para) +msgid "It is also important to consider the compute requirements of resource nodes within the cloud. Resource nodes refer to non-hypervisor nodes providing the following in the cloud:" msgstr "" -#: ./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 legacy networking (nova-network), as a part of OpenStack Compute, and OpenStack Networking (neutron), has tremendous implications and will have a huge impact on the architecture and design of the cloud network infrastructure." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:118(para) +msgid "Controller" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:123(para) +msgid "Object storage" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:128(para) +msgid "Block storage" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:133(para) +msgid "Networking services" msgstr "" #: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:138(para) +msgid "The number of processor cores and threads has a direct correlation to the number of worker threads which can be run on a resource node. As a result, you must make design decisions relating directly to the service, as well as provide a balanced infrastructure for all services." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:142(para) +msgid "Workload profiles are unpredictable in a general purpose cloud. Additional compute resource pools can be added to the cloud later, reducing the stress of unpredictability. In some cases, the demand on certain instance types or flavors may not justify individual hardware design. In either of these cases, initiate the design by allocating hardware designs that are capable of servicing the most common instances requests. If you are looking to add additional hardware designs to the overall architecture, this can be done at a later time." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:154(title) +msgid "Designing network resources" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:155(para) +msgid "OpenStack clouds traditionally have multiple network segments, each of which provides access to resources within the cloud to both operators and tenants. The network services themselves also require network communication paths which should be separated from the other networks. When designing network services for a general purpose cloud, we recommend planning for a physical or logical separation of network segments that will be used by operators and tenants. We further suggest the creation of an additional network segment for access to internal services such as the message bus and databse used by the various cloud services. Segregating these services onto separate networks helps to protect sensitive data and protects against unauthorized access to services." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:167(para) +msgid "Based on the requirements of instances being serviced in the cloud, the choice of network service will be the next decision that affects your design architecture." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:170(para) +msgid "The choice between legacy networking (nova-network), as a part of OpenStack Compute, and OpenStack Networking (neutron), has a huge impact on the architecture and design of the cloud network infrastructure." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:178(para) msgid "The legacy networking (nova-network) service is primarily a layer-2 networking service that functions in two modes. In legacy networking, the two modes differ in their use of VLANs. When using legacy networking in a flat network mode, all network hardware nodes and devices throughout the cloud are connected to a single layer-2 network segment that provides access to application data." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:146(para) -msgid "When the network devices in the cloud support segmentation using VLANs, legacy networking can operate in the second mode. In this design model, each tenant within the cloud is assigned a network subnet which is mapped to a VLAN on the physical network. It is especially important to remember the maximum number of 4096 VLANs which can be used within a spanning tree domain. These limitations place hard limits on the amount of growth possible within the data center. When designing a general purpose cloud intended to support multiple tenants, it is especially recommended to use legacy networking with VLANs, and not in flat network mode." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:185(para) +msgid "When the network devices in the cloud support segmentation using VLANs, legacy networking can operate in the second mode. In this design model, each tenant within the cloud is assigned a network subnet which is mapped to a VLAN on the physical network. It is especially important to remember the maximum number of 4096 VLANs which can be used within a spanning tree domain. These limitations place hard limits on the amount of growth possible within the data center. When designing a general purpose cloud intended to support multiple tenants, we recommend the use of legacy networking with VLANs, and not in flat network mode." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:157(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:199(para) msgid "Another consideration regarding network is the fact that legacy networking is entirely managed by the cloud operator; tenants do not have control over network resources. If tenants require the ability to manage and create network resources such as network segments and subnets, it will be necessary to install the OpenStack Networking service to provide network access to instances." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:164(para) -msgid "OpenStack Networking 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." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:208(term) +msgid "OpenStack Networking (neutron)" msgstr "" -#: ./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." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:210(para) +msgid "OpenStack Networking (neutron) is a first class networking service that gives full control over creation of virtual network resources to tenants. This is often accomplished in the form of tunneling protocols which will establish encapsulated communication paths over existing network infrastructure in order to segment tenant traffic. These methods vary depending on the specific implementation, but some of the more common methods include tunneling over GRE, encapsulating with VXLAN, and VLAN tags." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:181(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:222(para) +msgid "Initially, it is suggested to design at least three network segments, the first of which will be used for access to the cloud's REST APIs by tenants and operators. This is referred to as a public network. In most cases, the controller nodes and swift proxies within the cloud will be the only devices necessary to connect to this network segment. In some cases, this network might also be serviced by hardware load balancers and other network devices." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:230(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:191(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:240(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:202(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:253(title) msgid "Designing storage resources" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:203(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:254(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:210(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:263(title) msgid "Designing OpenStack Object Storage" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:211(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:264(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: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." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:273(para) +msgid "We do not recommended investing in enterprise class drives for an OpenStack Object Storage cluster. The consistency and partition tolerance characteristics of OpenStack Object Storage will ensure that data stays up to date and survives hardware faults without the use of any specialized data replication devices." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml: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." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:279(para) +msgid "One of the benefits of OpenStack Object Storage is the ability to mix and match drives by making use of weighting within the swift ring. When designing your swift storage cluster, we recommend making use of the most cost effective storage solution available at the time. Many server chassis on the market can hold 60 or more drives in 4U of rack space, therefore we recommend maximizing the amount of storage per rack unit at the best cost per terabyte. Furthermore, we do not recommend the use of RAID controllers in an object storage node." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml: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." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:289(para) +msgid "To achieve durability and availability of data stored as objects it is important to design object storage resource pools to ensure they can provide the suggested availability. Considering rack-level and zone-level designs to accommodate the number of replicas configured to be stored in the Object Storage service (the defult number of replicas is three) is important when designing beyond the hardware node level. Each replica of data should exist in its own availability zone with its own power, cooling, and network resources available to service that specific zone." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:247(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:298(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:253(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:306(title) msgid "Designing OpenStack Block Storage" msgstr "" -#: ./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." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:307(para) +msgid "When designing OpenStack Block Storage resource nodes, it is helpful to understand the workloads and requirements that will drive the use of block storage in the cloud. We recommend designing block storage pools so that tenants can choose appropriate storage solutions for their applications. By creating multiple storage pools of different types, in conjunction with configuring an advanced storage scheduler for the block storage service, it is possible to provide tenants with a large catalog of storage services with a variety of performance levels and redundancy options." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml: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." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:316(para) +msgid "Block storage also takes advantage of a number of enterprise storage solutions. These are addressed via a plug-in driver developed by the hardware vendor. A large number of enterprise storage plug-in drivers ship out-of-the-box with OpenStack Block Storage (and many more available via third party channels). General purpose clouds are more likely to use directly attached storage in the majority of block storage nodes, deeming it necessary to provide additional levels of service to tenants which can only be provided by enterprise class storage solutions." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml: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." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:325(para) +msgid "Redundancy and availability requirements impact the decision to use a RAID controller card in block storage nodes. The input-output per second (IOPS) demand of your application will influence whether or not you should use a RAID controller, and which level of RAID is required. Making use of higher performing RAID volumes is suggested when considering performance. However, where redundancy of block storage volumes is more important we recommend making use of a redundant RAID configuration such as RAID 5 or RAID 6. Some specialized features, such as automated replication of block storage volumes, may require the use of third-party plug-ins and enterprise block storage solutions in order to provide the high demand on storage. Furthermore, where extreme performance is a requirement it may also be necessary to make use of high speed SSD disk drives' high performing flash storage solutions." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml: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." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:344(para) +msgid "The software selection process plays a large role in the architecture of a general purpose cloud. The following have a large impact on the design of the cloud:" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml: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)." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:349(para) +msgid "Choice of operating system" msgstr "" -#: ./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, RHEL, or SLES has some flexibility in hypervisor; KVM, Xen, and LXC are supported virtualization methods available under OpenStack Compute (nova) on these Linux distributions. 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." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:354(para) +msgid "Selection of OpenStack software components" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:324(para) -msgid "The primary factors that play into OS-hypervisor selection include:" +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:359(para) +msgid "Choice of hypervisor" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:330(para) -msgid "The selection of OS-hypervisor combination first and foremost needs to support the user requirements." -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:336(term) -msgid "Support" -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:338(para) -msgid "The selected OS-hypervisor combination needs to be supported by OpenStack." -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:345(para) -msgid "The OS-hypervisor needs to be interoperable with other features and services in the OpenStack design in order to meet the user requirements." -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:354(title) ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:37(title) -msgid "Hypervisor" -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:355(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:360(para) -msgid "KVM (and QEMU)" -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:363(para) -msgid "XCP/XenServer" -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:366(para) -msgid "vSphere (vCenter and ESXi)" +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:364(para) +msgid "Selection of supplemental software" msgstr "" #: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:369(para) -msgid "Hyper-V" +msgid "Operating system (OS) selection plays a large role in the design and architecture of a cloud. There are a number of OSes which have native support for OpenStack including:" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:372(para) -msgid "LXC" +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:374(para) +msgid "Ubuntu" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:375(para) -msgid "Docker" +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:379(para) +msgid "Red Hat Enterprise Linux (RHEL)" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:378(para) -msgid "Bare-metal" +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:384(para) +msgid "CentOS" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:381(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:389(para) +msgid "SUSE Linux Enterprise Server (SLES)" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:385(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." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:395(para) +msgid "Native support is not a constraint on the choice of OS; users are free to choose just about any Linux distribution (or even Microsoft Windows) and install OpenStack directly from source (or compile their own packages). However, many organizations will prefer to install OpenStack from distribution-supplied packages or repositories (although using the distribution vendor's OpenStack packages might be a requirement for support)." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:392(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." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:404(para) +msgid "OS selection also directly influences hypervisor selection. A cloud architect who selects Ubuntu, RHEL, or SLES has some flexibility in hypervisor; KVM, Xen, and LXC are supported virtualization methods available under OpenStack Compute (nova) on these Linux distributions. However, a cloud architect who selects Hyper-V is limited to Windows Servers. Similarly, a cloud architect who selects XenServer is limited to the CentOS-based dom0 operating system provided with XenServer." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:407(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." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:412(para) +msgid "The primary factors that play into OS-hypervisor selection include:" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:415(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:" +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:418(para) +msgid "The selection of OS-hypervisor combination first and foremost needs to support the user requirements." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:421(para) -msgid "OpenStack Compute (nova)" +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:424(term) +msgid "Support" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:425(para) -msgid "OpenStack Networking (neutron)" -msgstr "" - -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:429(para) -msgid "OpenStack Image Service (glance)" +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:426(para) +msgid "The selected OS-hypervisor combination needs to be supported by OpenStack." msgstr "" #: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:433(para) -msgid "OpenStack Identity (keystone)" +msgid "The OS-hypervisor needs to be interoperable with other features and services in the OpenStack design in order to meet the user requirements." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:437(para) -msgid "OpenStack dashboard (horizon)" +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:443(title) ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:37(title) +msgid "Hypervisor" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:441(para) -msgid "Telemetry module (ceilometer)" +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:444(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:445(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." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:449(para) +msgid "KVM (and QEMU)" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:452(para) +msgid "XCP/XenServer" msgstr "" #: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:455(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." +msgid "vSphere (vCenter and ESXi)" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:458(para) +msgid "Hyper-V" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:461(para) +msgid "LXC" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:464(para) +msgid "Docker" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:467(para) +msgid "Bare-metal" msgstr "" #: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:470(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." +msgid "A complete list of supported hypervisors and their capabilities can be found at OpenStack Hypervisor Support Matrix." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:483(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." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:474(para) +msgid "We recommend general purpose clouds use hypervisors that support the most general purpose use cases, such as KVM and Xen. More specific hypervisors should be chosen to account for specific functionality or a supported feature requirement. In some cases, there may also be a mandated requirement to run software on a certified hypervisor including solutions from VMware, Microsoft, and Citrix." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:494(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." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:481(para) +msgid "The features offered through the OpenStack cloud platform determine the best choice of a hypervisor. As an example, for a general purpose cloud that predominantly supports a Microsoft-based migration, or is managed by staff that has a particular skill for managing certain hypervisors and operating systems, Hyper-V would be the best available choice. While the decision to use Hyper-V does not limit the ability to run alternative operating systems, be mindful of those that are deemed supported. Each different hypervisor also has their own hardware requirements which may affect the decisions around designing a general purpose cloud. For example, to utilize the live migration feature of VMware, vMotion, this requires an installation of vCenter/vSphere and the use of the ESXi hypervisor, which increases the infrastructure requirements." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:500(title) -msgid "Controller infrastructure" +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:496(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:501(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." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:506(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:512(para) +msgid "OpenStack Compute (nova)" msgstr "" #: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:516(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." +msgid "OpenStack Networking (neutron)" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:527(title) -msgid "Network performance" +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:520(para) +msgid "OpenStack Image Service (glance)" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:524(para) +msgid "OpenStack Identity (keystone)" msgstr "" #: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:528(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." +msgid "OpenStack dashboard (horizon)" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:544(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:532(para) +msgid "Telemetry module (ceilometer)" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:536(para) +msgid "A general purpose cloud may also include OpenStack Object Storage (swift). OpenStack Block Storage (cinder). These may be selected to provide storage to applications and instances." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:543(para) +msgid "However, depending on the use case, these could be optional." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:550(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:565(para) +msgid "Where many general purpose deployments use hardware load balancers to provide highly available API access and SSL termination, software solutions, for example HAProxy, can also be considered. It is vital to ensure that such software implementations are also made highly available. High availability can be achieved by using software such as Keepalived or Pacemaker with Corosync. Pacemaker and Corosync can provide active-active or active-passive highly available configuration depending on the specific service in the OpenStack environment. Using this software can affect the design as it assumes at least a 2-node controller infrastructure where one of those nodes may be running certain services in standby mode." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:578(para) +msgid "Memcached is a distributed memory object caching system, and Redis is a key-value store. Both are deployed on general purpose clouds to assist in alleviating load to the Identity service. The memcached service caches tokens, and due to its distributed nature it can help alleviate some bottlenecks to the underlying authentication system. Using memcached or Redis does not affect the overall design of your architecture as they tend to be deployed onto the infrastructure nodes providing the OpenStack services." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:591(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:599(title) +msgid "Controller infrastructure" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:600(para) +msgid "The Controller infrastructure nodes provide management services to the end-user as well as providing services internally for the operating of the cloud. The Controllers run message queuing services that carry system messages between each service. Performance issues related to the message bus would lead to delays in sending that message to where it needs to go. The result of this condition would be delays in operation functions such as spinning up and deleting instances, provisioning new storage volumes and managing network resources. Such delays could adversely affect an application’s ability to react to certain conditions, especially when using auto-scaling features. It is important to properly design the hardware used to run the controller infrastructure as outlined above in the Hardware Selection section." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:615(para) +msgid "Performance of the controller services is not limited to processing power, but restrictions may emerge in serving concurrent users. Ensure that the APIs and Horizon services are load tested to ensure that you are able to serve your customers. Particular attention should be made to the OpenStack Identity Service (Keystone), which provides the authentication and authorization for all services, both internally to OpenStack itself and to end-users. This service can lead to a degradation of overall performance if this is not sized appropriately." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:628(title) +msgid "Network performance" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:629(para) +msgid "In a general purpose OpenStack cloud, the requirements of the network help determine performance capabilities. For example, small deployments may employ 1 Gigabit Ethernet (GbE) networking, whereas larger installations serving multiple departments or many users would be better architected with 10GbE networking. The performance of the running instances will be limited by these speeds. It is possible to design OpenStack environments that run a mix of networking capabilities. By utilizing the different interface speeds, the users of the OpenStack environment can choose networks that are fit for their purpose." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:640(para) +msgid "For example, web application instances may run on a public network presented through OpenStack Networking that has 1 GbE capability, whereas the back-end database uses an OpenStack Networking network that has 10GbE capability to replicate its data or, in some cases, the design may incorporate link aggregation for greater throughput." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:646(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:552(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:656(title) msgid "Compute host" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:553(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:657(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:567(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:673(title) msgid "Storage performance" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:568(para) -msgid "When considering the performance of OpenStack Block Storage, hardware and architecture choices are 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." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:674(para) +msgid "When considering performance of OpenStack Block Storage, hardware and architecture choice is important. Block Storage can use enterprise back-end systems such as NetApp or EMC, scale out storage such as GlusterFS and Ceph, or simply use the capabilities of directly attached storage in the nodes themselves. Block Storage may be deployed so that traffic traverses the host network, which could affect, and be adversely affected by, the front-side API traffic performance. As such, consider using a dedicated data storage network with dedicated interfaces on the Controller and Compute hosts." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:579(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." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:685(para) +msgid "When considering performance of OpenStack Object Storage, a number of design choices will affect performance. A user’s access to the Object Storage is through the proxy services, which sit behind hardware load balancers. By the very nature of a highly resilient storage system, replication of the data would affect performance of the overall system. In this case, 10 GbE (or better) networking is recommended throughout the storage network architecture." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:589(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:697(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:598(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:706(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:603(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:711(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:612(para) -msgid "Care must be taken when deciding network functionality. Currently, OpenStack supports both the legacy networking (nova-network) system and the newer, extensible OpenStack Networking. Both have their pros and cons when it comes to providing highly available access. Legacy networking, which provides networking access maintained in the OpenStack Compute code, provides a feature that removes a single point of failure when it comes to routing, and this feature is currently missing in OpenStack Networking. The effect of legacy networking's multi-host functionality restricts failure domains to the host running that instance." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:720(para) +msgid "Care must be taken when deciding network functionality. Currently, OpenStack supports both the legacy networking (nova-network) system and the newer, extensible OpenStack Networking (neutron). Both have their pros and cons when it comes to providing highly available access. Legacy networking, which provides networking access maintained in the OpenStack Compute code, provides a feature that removes a single point of failure when it comes to routing, and this feature is currently missing in OpenStack Networking. The effect of legacy networking’s multi-host functionality restricts failure domains to the host running that instance." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:623(para) -msgid "On the other hand, when using OpenStack Networking, the OpenStack controller servers or separate Networking hosts handle routing. For a deployment that requires features available in only Networking, it is possible to remove this restriction by using third party software that helps maintain highly available L3 routes. Doing so allows for common APIs to control network hardware, or to provide complex multi-tier web applications in a secure manner. It is also possible to completely remove routing from Networking, and instead rely on hardware routing capabilities. In this case, the switching infrastructure must support L3 routing." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:731(para) +msgid "When using OpenStack Networking, the OpenStack controller servers or separate Networking hosts handle routing. For a deployment that requires features available in only Networking, it is possible to remove this restriction by using third party software that helps maintain highly available L3 routes. Doing so allows for common APIs to control network hardware, or to provide complex multi-tier web applications in a secure manner. It is also possible to completely remove routing from Networking, and instead rely on hardware routing capabilities. In this case, the switching infrastructure must support L3 routing." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:635(para) -msgid "OpenStack Networking (neutron) and legacy networking (nova-network) both have their advantages and disadvantages. They are both valid and supported options that fit different network deployment models described in the OpenStack Operations Guide." +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:743(para) +msgid "OpenStack Networking and legacy networking both have their advantages and disadvantages. They are both valid and supported options that fit different network deployment models described in the OpenStack Operations Guide." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:643(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:750(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:652(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:759(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:664(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:771(para) msgid "For more information on high availability in OpenStack, see the OpenStack High Availability Guide." msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:672(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:272(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:779(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:676(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:277(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:783(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:679(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:280(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:120(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:786(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:280(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:120(para) msgid "Public" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:682(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:283(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:123(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:789(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:283(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:123(para) msgid "Guest" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:688(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:289(para) ./doc/arch-design/hybrid/section_architecture_hybrid.xml:166(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:129(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:795(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:289(para) ./doc/arch-design/hybrid/section_architecture_hybrid.xml:166(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:129(para) msgid "Data" msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:691(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:798(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:701(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:808(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:705(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:812(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:716(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:318(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:823(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:721(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:828(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:728(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:835(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:742(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:849(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:748(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:855(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:753(para) -msgid "For more information on OpenStack Security, see the OpenStack Security Guide" +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:860(para) +msgid "For more information OpenStack Security, see the OpenStack Security Guide" msgstr "" #: ./doc/arch-design/introduction/section_intended_audience.xml:7(title) diff --git a/doc/arch-design/locale/zh_CN.po b/doc/arch-design/locale/zh_CN.po index 3677de5829..892197fb8b 100644 --- a/doc/arch-design/locale/zh_CN.po +++ b/doc/arch-design/locale/zh_CN.po @@ -8,9 +8,9 @@ msgid "" msgstr "" "Project-Id-Version: OpenStack Manuals\n" -"POT-Creation-Date: 2015-02-09 04:30+0000\n" -"PO-Revision-Date: 2015-02-09 03:40+0000\n" -"Last-Translator: johnwoo_lee \n" +"POT-Creation-Date: 2015-02-10 01:51+0000\n" +"PO-Revision-Date: 2015-02-10 02:23+0000\n" +"Last-Translator: openstackjenkins \n" "Language-Team: Chinese (China) (http://www.transifex.com/projects/p/openstack-manuals-i18n/language/zh_CN/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -1241,6 +1241,8 @@ msgstr "OpenStack GUI，OpenStack认证，以及OpenStack对象存储等服务 #: ./doc/arch-design/multi_site/section_architecture_multi_site.xml53(title) #: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml155(para) #: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml22(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml27(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml51(para) #: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml131(term) #: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml18(para) msgid "Storage" @@ -1339,7 +1341,7 @@ msgstr "网络决定包括用于租户网络的封装机制，广播域有多大 #: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml8(title) #: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml8(title) #: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml8(title) -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml328(term) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml416(term) #: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml12(title) #: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml8(title) #: ./doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml8(title) @@ -1592,7 +1594,7 @@ msgid "Replication" msgstr "重复" #: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml158(para) -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml685(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml792(para) #: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml286(para) #: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml126(para) msgid "Management" @@ -2122,7 +2124,7 @@ msgstr "取决于在设计站点时的选择的存储模式，存储的复制和 #: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml432(title) #: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml387(term) #: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml120(term) -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml493(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml590(title) #: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml96(term) #: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml177(term) #: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml257(title) @@ -2168,7 +2170,7 @@ msgstr "" #: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml163(title) #: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml630(term) #: ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml191(term) -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml671(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml778(title) #: ./doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml160(term) #: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml435(term) #: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml268(title) @@ -2217,7 +2219,7 @@ msgstr "" #: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml169(title) #: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml560(para) #: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml667(title) -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml414(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml505(title) #: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml366(para) #: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml472(title) #: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml360(title) @@ -2666,6 +2668,7 @@ msgid "" msgstr "对要实施的网络技术类型的选择依赖于很多要素。OpenStack 联网方式(neutron)和传统联网(nova-network)都有其各自的优势和劣势。他们都是有效的方式，各自所支持的用于满足不同使用场景的选项在下表中列出。" #: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml344(th) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml176(term) msgid "Legacy networking (nova-network)" msgstr "传统联网方式(nova-network)" @@ -3629,11 +3632,15 @@ msgid "Hardware selection involves three key areas:" msgstr "硬件选择分为三大块：" #: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml16(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml17(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml41(para) #: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml12(para) msgid "Compute" msgstr "计算" #: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml19(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml22(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml46(para) #: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml15(para) msgid "Network" msgstr "网络" @@ -4216,7 +4223,7 @@ msgid "" msgstr "网络设计须围绕物理网路和逻辑网络能够轻松扩展的设计来开展。网络硬件须提供给服务器节点所需要的合适的接口类型和速度。" #: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml531(term) -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml588(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml696(title) #: ./doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml113(term) msgid "Availability" msgstr "可用性" @@ -4236,7 +4243,7 @@ msgid "" msgstr "为确保云内部访问节点不会被中断，我们建议网络架构不要存在单点故障，应该提供一定级别的冗余和容错。网络基础设施本身就能提供一部分，比如使用网络协议诸如LACP,VRRP或其他的保证网络连接的高可用。另外，考虑网络实现的API可用亦非常重要。为了确保云中的API以及其它服务高可用，我们建议用户设计网络架构的负载均衡解决方案，以满足这些需求。" #: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml552(title) -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml294(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml343(title) #: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml358(title) #: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml386(title) msgid "Software selection" @@ -4255,7 +4262,7 @@ msgid "Operating system (OS) and hypervisor" msgstr "操作系统(OS)和虚拟机管理软件" #: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml563(para) -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml454(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml549(title) #: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml369(para) #: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml524(title) #: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml397(para) @@ -4368,7 +4375,7 @@ msgid "" msgstr "决定那些特性是需要OpenStack提供的。这通常也决定了操作系统-hypervisor组合的选择。一些特性仅在特定的操作系统和hypervisor中是可用的。举例，如果确认某些特性无法实现，设计也许需要修改代码去满足用户的需求。" #: ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml653(term) -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml343(term) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml431(term) #: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml457(term) #: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml495(term) msgid "Interoperability" @@ -5104,58 +5111,57 @@ msgstr "OpenStack网络可以通过使用插件和网络的应用程序接口控 #: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml13(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 "当设计通用型云时，即是实现设计所有的基本服务的需求，这些基本的服务即关联起基础设施即服务：计算、网络和存储。这些服务中的每一个都有不同的资源需求。所以，提供所有服务意味着提供平衡的基础设施，直接关系到最终的服务，依据这些作出设计决定是非常重要的。" +"General purpose clouds are often expected to include these base services:" +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml21(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml32(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 "当设计一个基于OpenStack的云作为通用型云时，硬件的选择过程将是漫长的，还有需要决定多数的服务需要被设计、一些独特的特点、在云中每个服务的需求等复杂的事情。硬件的设计需要根据不同的资源池生成不同的配置，资源池特别是计算，网络和存储。在硬件设计之外，得考虑到资源节点本身的影响，还有许多额外的硬件决策会影响到网络的架构和设施的规划。这些问题在OpenStack云的整个架构中扮演非常重要的角色。" - -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml34(title) -msgid "Designing compute resources" -msgstr "规划计算资源" +"Each of these services has different resource requirements. As a result, you" +" must make design decisions relating directly to the service, as well as " +"provide a balanced infrastructure for all services." +msgstr "" #: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml35(para) msgid "" -"We recommend you 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 "我们建议用户设计将计算资源设计为资源池，实现按需使用。当设计计算资源池时，有很多情形会影响到用户的设计决策。例如，和每种hypervisor相关的处理器、内存和存储仅仅是设计计算资源时考虑的一个因素。另外，将计算资源用户单一的池还是用户多个池也是有必要考虑的。" +"Consider the unique aspects of each service that requires design since " +"individual characteristics and service mass can impact the hardware " +"selection process. Hardware designs are generated for each type of the " +"following resource pools:" +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml43(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml56(para) msgid "" -"To design for the best use of available resources by applications running in" -" the cloud, we recommend you 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 machine 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 "要为运行在云中的应用设计最佳可用资源，我们建议用户设计多个计算资源池，每个独立的资源池须设计为可以提供特定类型的实例或一组类型。在本书中,\"实例“一词的意思是一个虚拟机和在此虚拟机中运行的操作系统。设计多个资源池的好处是实例被调度到合适的计算hypervisor中，每个对立的节点资源被分配最大化的利用硬件资源。这就是常见的打包。" +"Hardware decisions are also made in relation to network architecture and " +"facilities planning. These factors play heavily into the overall " +"architecture of an OpenStack cloud." +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml55(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml61(title) +msgid "Designing compute resources" +msgstr "规划计算资源" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml62(para) +msgid "" +"When designing compute resource pools, a number of factors can impact your " +"design decisions. For example, decisions related to processors, memory, and " +"storage within each hypervisor are just one element of designing compute " +"resources. In addition, decide whether to provide compute resources in a " +"single pool or in multiple pools. We recommend the compute design allocates " +"multiple pools of resources to be addressed on-demand." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml70(para) +msgid "" +"A compute design that allocates multiple pools of resources makes best use " +"of application resources running in the cloud. Each independent resource " +"pool should be designed to provide service for specific flavors of instances" +" or groupings of flavors. Designing multiple resource pools helps to ensure " +"that, as instances are scheduled onto compute hypervisors, each independent " +"node's resources will be allocated to make the most efficient use of " +"available hardware. This is commonly referred to as bin packing." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml78(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 " @@ -5165,99 +5171,120 @@ msgid "" "cycle in the cloud." msgstr "使用一致的硬件来设计资源池中的节点对装箱起到积极作用。选择硬件节点当作计算资源池的一部分最好是拥有一样的处理器、内存以及存储类型。选择一致的硬件设计，将会在云的整个生命周期展现出更加容易部署、支持和维护的好处。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml62(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml85(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 "OpenStack支持配置资源超分配比例，即虚拟资源比实际的物理资源，目前支持CPU和内存。默认的CPU超分配比例是16：1，默认的内存超分配比例是1.5：1。在设计阶段就要想要是否决定调整此超分配比例，因为这会直接影响到用户计算节点的硬件布局。" +"An overcommit ratio is the ratio of available virtual" +" resources, compared to the available physical resources. OpenStack is able " +"to configure the overcommit ratio for CPU and memory. The default CPU " +"overcommit ratio is 16:1 and the default memory overcommit ratio is 1.5:1. " +"Determining the tuning of the overcommit ratios for both of these options " +"during the design phase is important as it has a direct impact on the " +"hardware layout of your compute nodes." +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml70(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml92(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 10 2 16) total m1.small " -"instances. By the same reasoning, using the default memory overcommit ratio " -"of 1.5:1 you can determine that the server will need at least 853GB (640 " -"2,048MB / 1.5) of RAM. When sizing nodes for memory, it is also important to" -" consider the additional memory required to service operating system and " -"service needs." -msgstr "举例说明，想像一下，现在有一个m1.small类型的实例，使用的是1 vCPU,20GB的临时存储，2048MB的内存。当设计为此类实例提供计算资源池的硬件节点时，考虑节点需要多少个处理器、多大的磁盘、内存大小才可以满足容量需求。对于一个有2颗10个核的CPU，并开启超线程的服务器，基于默认的CPU超分配比例16：1来计算的话，它总共能运行640(2x10x2x16)个m1.small类型的实例。同样，基于默认的内存超分配比例1.5：1来计算的话，用户则需要至少853GB(640x2048/1.5x1048)内存。当基于内存来丈量服务器节点时，考虑操作系统本身和其服务所需要使用的内存也是非常重要的。" +"For example, consider a m1.small instance uses 1 vCPU, 20GB of ephemeral " +"storage and 2,048MB of RAM. When designing a hardware node as a compute " +"resource pool to service instances, take into consideration the number of " +"processor cores available on the node as well as the required disk and " +"memory to service instances running at capacity. For a server with 2 CPUs of" +" 10 cores each, with hyperthreading turned on, the default CPU overcommit " +"ratio of 16:1 would allow for 640 (2 10 2 16) total m1.small instances. By " +"the same reasoning, using the default memory overcommit ratio of 1.5:1 you " +"can determine that the server will need at least 853GB (640 2,048MB / 1.5) " +"of RAM. When sizing nodes for memory, it is also important to consider the " +"additional memory required to service operating system and service needs." +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml84(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml106(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 "处理器的选择对于硬件设计来讲实在是太过重要了，尤其是对比不同处理器之间的特性和性能。一些近来发布的处理器，拥有针对虚拟化的特性，如硬件增强虚拟化，或者是内存分页技术(著名的EPT影子页表)。这些特性对于在云中运行的虚拟机来说，有着非常关键的影响。" +"characteristics of different processors. Processors can include features " +"specific to virtualized compute hosts including hardware assisted " +"virtualization and technology related to memory paging (also known as EPT " +"shadowing). These types of features can have a significant impact on the " +"performance of your virtual machine running in the cloud." +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml93(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml113(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 refer 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 "另外实际会影响计算服务的是计算需要的资源节点，考虑这点很重要。资源节点也就是非hypervisor的节点，提供控制器、对象存储，块存储或网络服务的节点。处理器核数和线程数直接决定了资源节点可以运行多少个任务线程。确保在资源节点拥有充足的计算容量和内存规划非常重要。" +"It is also important to consider the compute requirements of resource nodes " +"within the cloud. Resource nodes refer to non-hypervisor nodes providing the" +" following in the cloud:" +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml102(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml118(para) +msgid "Controller" +msgstr "控制器" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml123(para) +msgid "Object storage" +msgstr "对象存储" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml128(para) +msgid "Block storage" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml133(para) +msgid "Networking services" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml138(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 "在通用型云中负载是不可预测的，所以能将每个特别的用例都做到胸有成竹是非常困难的。在未来给云增加计算资源池，这种不可预测是不会带来任何问题的。在某些情况下，在确定了实例类型的需求可能不足以需要单独的硬件设计。综合来看，硬件设计方案是先满足大多数通用的实例来启动的，至于以后，寻求增加额外的硬件设计将贯穿整个多样的硬件节点设计和资源池的架构。" +"The number of processor cores and threads has a direct correlation to the " +"number of worker threads which can be run on a resource node. As a result, " +"you must make design decisions relating directly to the service, as well as " +"provide a balanced infrastructure for all services." +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml115(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml142(para) +msgid "" +"Workload profiles are unpredictable in a general purpose cloud. Additional " +"compute resource pools can be added to the cloud later, reducing the stress " +"of unpredictability. In some cases, the demand on certain instance types or " +"flavors may not justify individual hardware design. In either of these " +"cases, initiate the design by allocating hardware designs that are capable " +"of servicing the most common instances requests. If you are looking to add " +"additional hardware designs to the overall architecture, this can be done at" +" a later time." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml154(title) msgid "Designing network resources" msgstr "规划网络资源" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml116(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml155(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 "传统的OpenStack云是有多个网段的，每个网段都提供在云中访问不仅是操作人员还可以是租户的资源。此外，网络服务本身也需要网络通讯路径以和其他网络隔离。当为通用型云设计网络服务时，强烈建议规划不论是物理的还是逻辑的都要将操作人员和租户隔离为不同的网段。进一步的建议，划分出另外一个网段，专门用于访问内部资源，诸如消息队列、数据库等各种云服务。利用不同网段隔离这些服务对于保护敏感数据以及对付没有认证的访问很有帮助。" +"OpenStack clouds traditionally have multiple network segments, each of which" +" provides access to resources within the cloud to both operators and " +"tenants. The network services themselves also require network communication " +"paths which should be separated from the other networks. When designing " +"network services for a general purpose cloud, we recommend planning for a " +"physical or logical separation of network segments that will be used by " +"operators and tenants. We further suggest the creation of an additional " +"network segment for access to internal services such as the message bus and " +"databse used by the various cloud services. Segregating these services onto " +"separate networks helps to protect sensitive data and protects against " +"unauthorized access to services." +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml130(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml167(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 legacy networking (nova-network), as a part of OpenStack Compute, " -"and OpenStack Networking (neutron), has tremendous implications and will " -"have a huge impact on the architecture and design of the cloud network " -"infrastructure." -msgstr "基于在云中实例被服务的需求，接下来的设计选择将会影响到用户的网络服务选择，而这又用于在云中服务于实例。选择在遗留网络(nova-network)和OpenStack网络(neutron)之间进行，前者隶属于OpenStack计算，不同的选择都会都巨大的影响，且会严重影响到云网络基础设施的架构和设计。" +"Based on the requirements of instances being serviced in the cloud, the " +"choice of network service will be the next decision that affects your design" +" architecture." +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml138(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml170(para) +msgid "" +"The choice between legacy networking (nova-network), as a part of OpenStack " +"Compute, and OpenStack Networking (neutron), has a huge impact on the " +"architecture and design of the cloud network infrastructure." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml178(para) msgid "" "The legacy networking (nova-network) service is primarily a layer-2 " "networking service that functions in two modes. In legacy networking, the " @@ -5267,7 +5294,7 @@ msgid "" " to application data." msgstr "遗留的网络服务(nova-network)主要是一个二层的网络服务，有两种模式的功能实现。在遗留网络中，两种模式的区别是它们使用VLAN的方式不同。当使用遗留网络用于浮动网络模式时，所有的网络硬件节点和设备通过一个二层的网段来连接，提供应用数据的访问。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml146(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml185(para) msgid "" "When the network devices in the cloud support segmentation using VLANs, " "legacy networking can operate in the second mode. In this design model, each" @@ -5276,11 +5303,11 @@ msgid "" "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 legacy " -"networking with VLANs, and not in flat network mode." -msgstr "当云中的网络设备可通过VLANs支持分段时，遗留网络的第二种模式就可操作了。此模式中，云中的每个组户都被分配一个网络子网，其是映射到物理网络的VLAN中的。尤其重要的一点，要记得在一个生成树域里VLANs的最大数量是4096.在数据中心此限制成为了可能成长的一个硬性限制。当设计一个支持多租户的通用型云时，特别要记住使用和VLANs一起使用遗留网络，而且不使用浮动网络模式。" +"support multiple tenants, we recommend the use of legacy networking with " +"VLANs, and not in flat network mode." +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml157(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml199(para) msgid "" "Another consideration regarding network is the fact that legacy networking " "is entirely managed by the cloud operator; tenants do not have control over " @@ -5290,29 +5317,32 @@ msgid "" "instances." msgstr "另外的考虑是关于基于遗留网络的网络的管理是由云运维人员负责的。租户对网络资源没有控制权。如果租户希望有管理和创建网络资源的能力，如创建、管理一个网段或子网，那么就有必要安装OpenStack网络服务，以提供租户访问网络。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml164(para) -msgid "" -"OpenStack Networking 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 "OpenStack网络是第一次实现为租户提供全部的控制权来建立虚拟网络资源的网络服务。为了实现给租户流量分段，通常是基于已有的网络基础设施来封装通信路径，即以隧道协议的方式。这些方法严重依赖与特殊的实现方式，大多数通用的方式包括GRE隧道，VXLAN封装以及VLAN标签。" +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml208(term) +msgid "OpenStack Networking (neutron)" +msgstr "OpenStack 网络 (neutron)" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml173(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml210(para) +msgid "" +"OpenStack Networking (neutron) is a first class networking service that " +"gives full control over creation of virtual network resources to tenants. " +"This is often accomplished in the form of tunneling protocols which will " +"establish encapsulated communication paths over existing network " +"infrastructure in order to segment tenant traffic. These methods vary " +"depending on the specific implementation, but some of the more common " +"methods include tunneling over GRE, encapsulating with VXLAN, and VLAN tags." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml222(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 "首先建议的设计是至少划分三个网段，第一个是给租户和运维人员用于访问云的REST 应用程序接口。这也是通常说的公有网络。在多数的用例中，控制节点和swift代理是唯一的需要连接到此网段的设备。也有一些用例中，此网段也许服务于硬件的负载均衡或其他网络设备。" +"and operators. This is referred to as a public network. In most cases, the " +"controller nodes and swift proxies within the cloud will be the only devices" +" necessary to connect to this network segment. In some cases, this network " +"might also be serviced by hardware load balancers and other network devices." +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml181(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml230(para) msgid "" "The next segment is used by cloud administrators to manage hardware " "resources and is also used by configuration management tools when deploying " @@ -5324,7 +5354,7 @@ msgid "" "every hardware node within the cloud." msgstr "第二个网段用于云管理员管理硬件资源，也用于在新的硬件上部署软件和服务的配置管理工具。在某些情况下，此网段也许用于内部服务间的通信，包括消息总线和数据库服务。介于此网段拥有高度安全的本质，需要将此网络设置为未经授权不得访问。此网段在云中的所有硬件节点需要互联互通。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml191(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml240(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 " @@ -5336,11 +5366,11 @@ msgid "" "cloud." msgstr "第三个网段用于为应用程序和消费者访问物理网络，也为最终用户访问云中运行的应用程序提供网络。此网络是隔离能够访问云API的网络，并不能够直接和云中的硬件资源通信。计算资源节点需要基于此网段通信，以及任何的网络网关服务将允许应用程序的数据可通过物理网络到云的外部。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml202(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml253(title) msgid "Designing storage resources" msgstr "规划存储资源" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml203(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml254(para) msgid "" "OpenStack has two independent storage services to consider, each with its " "own specific design requirements and goals. In addition to services which " @@ -5349,11 +5379,11 @@ msgid "" " the overall cloud architecture." msgstr "OpenStack有两个独立的存储服务需要考虑，且每个都拥有自己特别的设计需求和目标。除了提供存储服务是他们的主要功能之外，在整个云架构中，需要额外考虑的是它们对计算/控制节点的影响。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml210(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml263(title) msgid "Designing OpenStack Object Storage" msgstr "规划OpenStack对象存储" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml211(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml264(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 " @@ -5364,41 +5394,40 @@ msgid "" "main goal is to maximize the storage available in each node." msgstr "当为OpenStack对象存储设计硬件资源时，首要的目标就尽可能的为每个资源节点加上最多的存储，当然也要在每TB的花费上保持最低。这往往涉及到了利用服务器的容纳大量的磁盘。无论是选择使用2U服务器直接挂载磁盘，还是选择外挂大量的磁盘驱动，主要的目标还是为每个节点得到最多的存储。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml220(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml273(para) msgid "" -"It is not recommended to invest in enterprise class drives for an OpenStack " +"We do not recommended investing in enterprise class drives for an OpenStack " "Object Storage cluster. The consistency and partition tolerance " "characteristics of OpenStack Object Storage will ensure that data stays up " "to date and survives hardware faults without the use of any specialized data" " replication devices." -msgstr "并不建议为OpenStack对象存储投资企业级的设备。OpenStack对象存储的一致性和分区容错保证的数据的更新，即使是在硬件损坏的情况下仍能保证数据可用，而这都无须特别的数据复制设备。" +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml226(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml279(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 " +"One of the benefits of OpenStack Object Storage is the ability to mix and " +"match drives by making use of weighting within the swift ring. When " +"designing your swift storage cluster, we recommend making use of the most " +"cost effective storage solution available at the time. Many server chassis " +"on the market can hold 60 or more drives in 4U of rack space, therefore we " +"recommend maximizing the amount of storage per rack unit at the best cost " +"per terabyte. Furthermore, we do not recommend the use of RAID controllers " "in an object storage node." -msgstr "OpenStack对象存储一个亮点就是有混搭设备的能力，基于swift环的加权机制。当用户设计一个swift存储集群时，建议将大部分的成本花在存储上，保证永久可用。市场上多数的服务器使用4U，可容纳60块甚至更多的磁盘驱动器，因此建议在1U空间内置放最多的驱动器，就是最好的每TB花费。进一步的建议，在对象存储节点上没必要使用RAID控制器。" +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml236(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml289(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 "为了实现数据存储和对象一样的持久和可用，设计对象存储资源池显得非常的重要，在硬件节点这层之外的设计，考虑机柜层或区域层是非常重要的，在对象存储服务中配置数据复制多少份保存(默认情况是3份)。每份复制的数据最好独立的可用区域中，有独立的电源、冷却设备以及网络资源。" +"To achieve durability and availability of data stored as objects it is " +"important to design object storage resource pools to ensure they can provide" +" the suggested availability. Considering rack-level and zone-level designs " +"to accommodate the number of replicas configured to be stored in the Object " +"Storage service (the defult number of replicas is three) is important when " +"designing beyond the hardware node level. Each replica of data should exist " +"in its own availability zone with its own power, cooling, and network " +"resources available to service that specific zone." +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml247(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml298(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 " @@ -5406,178 +5435,208 @@ msgid "" "higher core counts will ensure the IO requests do not inundate the server." msgstr "对象存储节点应该被设计为在集群中不至于区区几个请求就拖性能后腿的样子。对象存储服务是一种频繁交互的协议，因此确定使用多个处理器，而且要多核的，这样才可确保不至于因为IO请求将服务器搞垮。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml253(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml306(title) msgid "Designing OpenStack Block Storage" msgstr "规划OpenStack块存储" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml254(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml307(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 " +"storage in the cloud. We recommend designing block storage pools so that " +"tenants can choose appropriate storage solutions for their applications. By " +"creating multiple storage pools of different types, in conjunction with " "configuring an advanced storage scheduler for the block storage service, it " "is possible to provide tenants with a large catalog of storage services with" " a variety of performance levels and redundancy options." -msgstr "当设计OpenStack块存储资源节点时，有助于理解负载和需求，即在云中使用块存储。由于通用型云的使用模式经常是未知的。在此建议设计块存储池做到租户可以根据他们的应用来选择不同的存储。创建多个不同类型的存储池，得与块存储服务配置高级的存储调度相结合，才可能为租户提供基于多种不同性能级别和冗余属性的大型目录存储服务。" +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml265(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml316(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 "除了直接为服务器附加存储，块存储还可以利用一些企业级存储解决方案的优势。由硬件厂商开发的插件驱动得以实现。基于OpenStack块存储有大量的企业存储写了它们带外的插件驱动(也有很大一部分是通过第三方渠道来实现的)。作为通用型云使用的是直接挂载存储到块存储节点，如果未来需要为租户提供额外级别的块存储，只须增加企业级的存储解决方案即可。" +"Block storage also takes advantage of a number of enterprise storage " +"solutions. These are addressed via a plug-in driver developed by the " +"hardware vendor. A large number of enterprise storage plug-in drivers ship " +"out-of-the-box with OpenStack Block Storage (and many more available via " +"third party channels). General purpose clouds are more likely to use " +"directly attached storage in the majority of block storage nodes, deeming it" +" necessary to provide additional levels of service to tenants which can only" +" be provided by enterprise class storage solutions." +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml276(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml325(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 "决定在块存储节点中使用RAID控制卡主要取决于应用程序对冗余和可用性的需求。应用如果对每秒输入输出(IOPS)有很高的要求，不仅得使用RAID控制器，还得配置RAID的级别值，当性能是重要因素时，建议使用高级别的RAID值，相对比的情况是，如果冗余的因素考虑更多谢，那么就使用冗余RAID配置，比如RAID5或RAID6。一些特殊的特性，例如自动复制块存储卷，需要使用第三方插件和企业级的块存储解决方案，以满足此高级需求。进一步讲，如果有对性能有极致的要求，可以考虑使用告诉的SSD磁盘，即高性能的flash存储解决方案。" +"Redundancy and availability requirements impact the decision to use a RAID " +"controller card in block storage nodes. The input-output per second (IOPS) " +"demand of your application will influence whether or not you should use a " +"RAID controller, and which level of RAID is required. Making use of higher " +"performing RAID volumes is suggested when considering performance. However, " +"where redundancy of block storage volumes is more important we recommend " +"making use of a redundant RAID configuration such as RAID 5 or RAID 6. Some " +"specialized features, such as automated replication of block storage " +"volumes, may require the use of third-party plug-ins and enterprise block " +"storage solutions in order to provide the high demand on storage. " +"Furthermore, where extreme performance is a requirement it may also be " +"necessary to make use of high speed SSD disk drives' high performing flash " +"storage solutions." +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml295(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml344(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 "软件筛选的过程在通用型云架构中扮演了重要角色。选择操作系统，选择OpenStack软件组件，选择Hypervisor，以及选择支撑软件，都会在设计云时产生重大的影响。" +"The software selection process plays a large role in the architecture of a " +"general purpose cloud. The following have a large impact on the design of " +"the cloud:" +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml300(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml349(para) +msgid "Choice of operating system" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml354(para) +msgid "Selection of OpenStack software components" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml359(para) +msgid "Choice of hypervisor" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml364(para) +msgid "Selection of supplemental software" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml369(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 " +"support for OpenStack including:" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml374(para) +msgid "Ubuntu" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml379(para) +msgid "Red Hat Enterprise Linux (RHEL)" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml384(para) +msgid "CentOS" +msgstr "CentOS" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml389(para) +msgid "SUSE Linux Enterprise Server (SLES)" +msgstr "SUSE Linux Enterprise Server (SLES)" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml395(para) +msgid "" +"Native support is not a constraint on the choice of OS; users are free to " +"choose just about any Linux distribution (or even Microsoft Windows) and " +"install OpenStack directly from source (or compile their own packages). " +"However, many organizations will prefer to install OpenStack from " "distribution-supplied packages or repositories (although using the " "distribution vendor's OpenStack packages might be a requirement for " "support)." -msgstr "操作系统(OS)的选择在云的设计和架构中扮演着重要的角色。有许多操作系统是原生就支持OpenStack的，它们是：Ubuntu,红帽企业Linux(RHEL)，CentOS,以及SUSE Linux企业服务版(SLES).所谓的原生支持，在这里的意思是这些发行版在发布自己的版本时同时也会在它们的仓库发行OpenStack的软件包。记住原生并非是限制到某些操作系统，用户仍然可以自己选择Linux的任何发行版(甚至是微软的Windows),然后从源码安装OpenStack(或者编译为某个发行版的包)。尽管如此，事实上多数组织还是会从发行版支持的包或仓库去安装OpenStack(使用分发商的OpenStack软件包也许需要他们的支持)。" +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml315(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml404(para) msgid "" "OS selection also directly influences hypervisor selection. A cloud " "architect who selects Ubuntu, RHEL, or SLES has some flexibility in " "hypervisor; KVM, Xen, and LXC are supported virtualization methods available" -" under OpenStack Compute (nova) on these Linux distributions. 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 "操作系统的选择会直接影响到hypervisor的选择。一个云架构会选择Ubuntu,RHEL,或SLES等，它们都拥有灵活的hypervisor可供选择，同时也被OpenStack 计算(nova)所支持，如KVM,Xen,LXC等虚拟化。一个云架构若选择了Hyper-V,那么只能使用Windows服务器版本。同样的，一个云架构若选择了XenServer,也限制到基于CenOS dom0操作系统。" +" under OpenStack Compute (nova) on these Linux distributions. However, a " +"cloud architect who selects Hyper-V is limited to Windows Servers. " +"Similarly, a cloud architect who selects XenServer is limited to the CentOS-" +"based dom0 operating system provided with XenServer." +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml324(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml412(para) msgid "The primary factors that play into OS-hypervisor selection include:" msgstr "影响操作系统-hypervisor选择的主要因素包括：" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml330(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml418(para) msgid "" "The selection of OS-hypervisor combination first and foremost needs to " "support the user requirements." msgstr "选择操作系统-虚拟机管理程序组合，首先且最重要的是支持用户的需求。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml336(term) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml424(term) msgid "Support" msgstr "支持" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml338(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml426(para) msgid "" "The selected OS-hypervisor combination needs to be supported by OpenStack." msgstr "选择操作系统-虚拟机管理程序组合需要OpenStack支持。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml345(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml433(para) msgid "" "The OS-hypervisor needs to be interoperable with other features and services" " in the OpenStack design in order to meet the user requirements." msgstr "在OpenStack的设计中，为满足用户需求，需要操作系统的hypervisor在彼此的特性和服务中要有互操作性。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml354(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml443(title) #: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml37(title) msgid "Hypervisor" msgstr "虚拟机管理程序" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml355(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml444(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 "OpenStack支持多种Hypervisor,在单一的云中可以有一种或多种。这些Hypervisor包括：" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml360(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml449(para) msgid "KVM (and QEMU)" msgstr "KVM (and QEMU)" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml363(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml452(para) msgid "XCP/XenServer" msgstr "XCP/XenServer" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml366(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml455(para) msgid "vSphere (vCenter and ESXi)" msgstr "vSphere (vCenter and ESXi)" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml369(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml458(para) msgid "Hyper-V" msgstr "Hyper-V" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml372(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml461(para) msgid "LXC" msgstr "LXC" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml375(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml464(para) msgid "Docker" msgstr "Docker" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml378(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml467(para) msgid "Bare-metal" msgstr "裸金属" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml381(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml470(para) msgid "" "A complete list of supported hypervisors and their capabilities can be found" " at https://wiki.openstack.org/wiki/HypervisorSupportMatrix." -msgstr "支持hypervisor和它们的兼容性的完整列表可以从https://wiki.openstack.org/wiki/HypervisorSupportMatrix页面找到。" +"href=\"https://wiki.openstack.org/wiki/HypervisorSupportMatrix\">OpenStack " +"Hypervisor Support Matrix." +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml385(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml474(para) msgid "" -"General purpose clouds should make use of hypervisors that support the most " +"We recommend general purpose clouds use 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 " +"should be chosen to account for specific functionality or a supported " "feature requirement. In some cases, there may also be a mandated requirement" " to run software on a certified hypervisor including solutions from VMware, " "Microsoft, and Citrix." -msgstr "通用型云须确保使用的hypervisor可以支持多数通用目的的用例，例如KVM或Xen。更多特定的hypervisor需要根据特定的功能和支持特性需求来做出选择。在一些情况下，也许是授权所需，需要运行的软件必须是在认证的hpervisor中，比如来自VMware，微软和思杰的产品。" +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml392(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml481(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 " +"systems, Hyper-V would be the best available choice. While the decision to " "use Hyper-V does not limit the ability to run alternative operating systems," " be mindful of those that are deemed supported. Each different hypervisor " "also has their own hardware requirements which may affect the decisions " @@ -5585,9 +5644,9 @@ msgid "" "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 "通过OpenStack云平台提供的特性决定了选择最佳的hyperviosr。举个例子，要使通用型云主要支持基于微软的迁移，或工作人员所管理的是需要特定技能的去管理hypervisor或操作系统，Hyper-V也许是最好的选择。即使是决定了使用Hyper-V，这也并不意味着不可以去管理相关的操作系统，要记得OpenStack是支持多种hypervisor的。在设计通用型用时需要考虑到不同的hypervisor有他们特定的硬件需求。例如欲整合VMware的特性：活迁移，那么就需要安装安装vMotion,给ESXi hypervisor所使用的VCenter/vSphere，这即是增加的基础设施需求。" +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml407(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml496(para) msgid "" "In a mixed hypervisor environment, specific aggregates of compute resources," " each with defined capabilities, enable workloads to utilize software and " @@ -5596,53 +5655,56 @@ msgid "" "within a particular flavor of an instance." msgstr "在混合的hypervisor环境中，等于聚合了计算资源，但是各个hypervisor定义了各自的能力，以及它们分别对软、硬件特殊的需求等。这些功能需要明确暴露给最终用户，或者通过为实例类型定义的元数据来访问。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml415(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml506(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 "通用型OpenStack云的设计，使核心的OpenStack服务的互相紧密配合为最终用户提供广泛的服务。在通用型云中建议的OpenStack核心服务有：" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml421(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml512(para) msgid "OpenStack Compute (nova)" msgstr "OpenStack 计算 (nova)" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml425(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml516(para) msgid "" "OpenStack Networking (neutron)" msgstr "OpenStack 网络 (neutron)" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml429(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml520(para) msgid "" "OpenStack Image Service " "(glance)" msgstr "OpenStack 镜像服务 (glance)" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml433(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml524(para) msgid "" "OpenStack Identity (keystone)" msgstr "OpenStack 认证 (keystone)" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml437(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml528(para) msgid "" "OpenStack dashboard (horizon)" msgstr "OpenStack 仪表盘 (horizon)" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml441(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml532(para) msgid "" "Telemetry module (ceilometer)" msgstr "Telemetry module (ceilometer)" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml445(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml536(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 "通用型云还包括OpenStack 对象存储 (swift).。选择OpenStack 块存储 (cinder) 是为应用和实例提供持久性的存储，但是这取决于用例，是可选项。" +"Block Storage (cinder). These " +"may be selected to provide storage to applications and instances." +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml455(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml543(para) +msgid "However, depending on the use case, these could be optional." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml550(para) msgid "" "A general purpose OpenStack deployment consists of more than just OpenStack-" "specific components. A typical deployment involves services that provide " @@ -5658,33 +5720,33 @@ msgid "" "consideration of rack space and switch port density becomes important." msgstr "通用型OpenStack的软件部署不仅仅是OpenStack特定的组件。一个典型的部署，如提供支撑功能的服务，须包含数据库，消息队列，以及为OpenStack环境提供高可用的软件。设计的决定围绕着底层的消息队列会影响到控制器服务的多寡，正如技术上为数据库提供高弹性功能，例如在MariaDB之上使用Galera。在这些场景中，服务的复制依赖于预订的机器数，因此，考虑数据库的\n节点，例如，至少需要3个节点才可满足Galera节点的失效恢复。随着节点数量的增加，以支持软件的特性，考虑机柜的空间和交换机的端口显得非常的重要。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml470(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml565(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 " +"such software implementations are also made highly available. High " "availability can be achieved by using software such as Keepalived or " "Pacemaker with Corosync. Pacemaker and Corosync can provide active-active or" " active-passive highly available configuration depending on the specific " "service in the OpenStack environment. Using this software can affect the " "design as it assumes at least a 2-node controller infrastructure where one " "of those nodes may be running certain services in standby mode." -msgstr "多数的通用型部署使用硬件的负载均衡来提供API访问高可用和SSL终端，但是软件的解决方案也要考虑到，比如HAProxy。至关重要的是软件实现的高可用也很靠谱。这些高可用的软件如Keepalived或基于Corosync的Pacemaker。Pacemaker和Corosync配合起来可以提供双活或者单活的高可用配置，至于是否双活取决于OpenStack环境中特别的服务。使用Pacemaker会影响到设计，假定有至少两台控制器基础设施，其中一个节点可在待机模式下运行的某些服务。" +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml483(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml578(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 " +"value store. Both are deployed on general purpose clouds to assist in " +"alleviating load to the Identity service. The memcached service caches " "tokens, and due to its distributed nature it can help alleviate some " "bottlenecks to the underlying authentication system. Using memcached or " "Redis does not affect the overall design of your architecture as they tend " "to be deployed onto the infrastructure nodes providing the OpenStack " "services." -msgstr "Memcached是一个分布式的内存对象缓存系统，Redia是一个key-value存储系统。在通用型云中使用这两个系统来减轻认证服务的负载。memcached服务缓存令牌，基于它天生的分布式特性可以缓减授权系统的瓶颈。使用memcached或Redis不会影响到用户的架构设计，虽然它们会部署到基础设施节点中为OpenStack提供服务。" +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml494(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml591(para) msgid "" "Performance of an OpenStack deployment is dependent on a number of factors " "related to the infrastructure and controller services. The user requirements" @@ -5692,60 +5754,65 @@ msgid "" "resources, and performance of storage systems." msgstr "OpenStack的性能取决于和基础设施有关的因素的多少以及控制器服务的多少。按照用户需求性能可归类为通用网络性能，计算资源性能，以及存储系统性能。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml500(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml599(title) msgid "Controller infrastructure" msgstr "控制器基础设施" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml501(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml600(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 " +"cloud. The Controllers run message queuing services that carry system " +"messages between each service. Performance issues related to the message bus" +" would lead to delays in sending that message to where it needs to go. The " +"result of this condition would be delays in operation functions such as " +"spinning up and deleting instances, provisioning new storage volumes and " +"managing network resources. Such delays could adversely affect an " +"application’s ability to react to certain conditions, especially when using " "auto-scaling features. It is important to properly design the hardware used " "to run the controller infrastructure as outlined above in the Hardware " "Selection section." -msgstr "控制器基础设施节点为最终用户提供的管理服务，以及在云内部为运维提供服务。控制器较典型的现象，就是运行消息队列服务，在每个服务之间携带传递系统消息。性能问题常和消息总线有关，它会延迟发送的消息到应该去的地方。这种情况的结果就是延迟了实际操作的功能，如启动或删除实例、分配一个新的存储卷、管理网络资源。类似的延迟会严重影响到应用的反应能力，尤其是使用了自动扩展这样的特性。所以运行控制器基础设施的硬件设计是头等重要的，具体参考上述硬件选择一节。" +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml516(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml615(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 " +"Performance of the controller services is not limited to processing power, " +"but restrictions may emerge in serving concurrent users. Ensure that the " +"APIs and Horizon services are load tested to ensure that you are able to " +"serve your customers. Particular attention should be made to the OpenStack " "Identity Service (Keystone), which provides the authentication and " "authorization for all services, both internally to OpenStack itself and to " "end-users. This service can lead to a degradation of overall performance if " "this is not sized appropriately." -msgstr "控制器服务的性能不仅仅限于处理器的强大能力，也受限于所服务的并发用户。确认应用程序接口和Horizon服务的负载测试可以承受来自用户客户的压力。要特别关注OpenStack认证服务(Keystone)的负载，Keystone为所有服务提供认证和授权，无论是最终用户还是OpenStack的内部服务。如果此控制器服务没有正确的被设计，会导致整个环境的性能低下。" +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml527(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml628(title) msgid "Network performance" msgstr "网络性能" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml528(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml629(para) msgid "" "In a general purpose OpenStack cloud, the requirements of the network help " -"determine its performance capabilities. For example, small deployments may " +"determine performance capabilities. For example, small deployments may " "employ 1 Gigabit Ethernet (GbE) networking, whereas larger installations " "serving multiple departments or many users would be better architected with " "10GbE networking. The performance of the running instances will be limited " "by these speeds. It is possible to design OpenStack environments that run a " "mix of networking capabilities. By utilizing the different interface speeds," " the users of the OpenStack environment can choose networks that are fit for" -" their purpose. 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 "通用型OpenStack云，网络的需求其实帮助决定了其本身的性能能力。例如，小的部署环境使用千兆以太网(GbE)，大型的部署环境或者许多用户就要求使用万兆网。运行着的实例性能收到了它们的速度限制。设计OpenStack环境，让它拥有可以运行混合网络的能力是可能的。通过利用不同速度的网卡，OpenStack环境的用户可以选择不同的网络去满足不同的目的。例如，web应用的实例在公网上运行的是OpenStack网络中的千兆，但是其后端的数据库使用的是OpenStack网络的万兆以复制数据，在某些情况下，为了更大的吞吐量使用聚合链接这样的设计。" +" their purpose." +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml544(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml640(para) +msgid "" +"For example, web application instances may run on a public network presented" +" through OpenStack Networking that has 1 GbE capability, whereas the back-" +"end database uses an OpenStack Networking network that has 10GbE capability " +"to replicate its data or, in some cases, the design may incorporate link " +"aggregation for greater throughput." +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml646(para) msgid "" "Network performance can be boosted considerably by implementing hardware " "load balancers to provide front-end service to the cloud APIs. The hardware " @@ -5754,11 +5821,11 @@ msgid "" "understand the SSL offloading capabilities of the devices selected." msgstr "网络的性能可以考虑有硬件的负载均衡来帮助实现，为云抛出的API提供前端的服务。硬件负载均衡通常也提供SSL终端，如果用户的环境有需求的话。当实现SSL减负时，理解SSL减负的能力来选择硬件，这点很重要。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml552(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml656(title) msgid "Compute host" msgstr "计算主机" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml553(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml657(para) msgid "" "The choice of hardware specifications used in compute nodes including CPU, " "memory and disk type directly affects the performance of the instances. " @@ -5772,35 +5839,34 @@ msgid "" " defaults, but make sure to monitor your environment as usage increases." msgstr "为计算节点选择硬件规格包括CPU,内存和磁盘类型，会直接影响到实例的性能。另外直接影响性能的情形是为OpenStack服务优化参数，例如资源的超分配比例。默认情况下OpenStack计算设置16:1为CPU的超分配比例，内存为1.5:1。运行跟高比例的超分配即会导致有些服务无法启动。调整您的计算环境时，为了避免这种情况下必须小心。运行一个通用型的OpenStack环境保持默认配置就可以，但是也要检测用户的环境中使用量的增加。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml567(title) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml673(title) msgid "Storage performance" msgstr "存储性能" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml568(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml674(para) msgid "" -"When considering the performance of OpenStack Block Storage, hardware and " -"architecture choices are 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 "当考虑OpenStack块设备的性能时，硬件和架构的选择就显得非常重要。块存储可以使用企业级后端系统如NetApp或EMC的产品，也可以使用横向扩展存储如GlusterFS和Ceph，更可以是简单的在节点上直接附加的存储。块存储或许是云所关注的贯穿主机网络的部署，又或许是前端应用程序接口所关注的流量性能。无论怎么，都得在控制器和计算主机上考虑使用专用的数据存储网络和专用的接口。" +"When considering performance of OpenStack Block Storage, hardware and " +"architecture choice is important. Block Storage can use enterprise back-end " +"systems such as NetApp or EMC, scale out storage such as GlusterFS and Ceph," +" or simply use the capabilities of directly attached storage in the nodes " +"themselves. Block Storage may be deployed so that traffic traverses the host" +" network, which could affect, and be adversely affected by, the front-side " +"API traffic performance. As such, consider using a dedicated data storage " +"network with dedicated interfaces on the Controller and Compute hosts." +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml579(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml685(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 "当考虑OpenStack对象存储的性能时，有几样设计选择会影响到性能。用户访问对象存储是通过代理服务，它通常是在硬件负载均衡之后。由于高弹性是此存储系统的天生特性，所以复制数据将会影响到整个系统的性能。在此例中，存储网络使用万兆(或更高)网络是我们所建议的。" +" choices will affect performance. A user’s access to the Object Storage is " +"through the proxy services, which sit behind hardware load balancers. By the" +" very nature of a highly resilient storage system, replication of the data " +"would affect performance of the overall system. In this case, 10 GbE (or " +"better) networking is recommended throughout the storage network " +"architecture." +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml589(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml697(para) msgid "" "In OpenStack, the infrastructure is integral to providing services and " "should always be available, especially when operating with SLAs. Ensuring " @@ -5811,7 +5877,7 @@ msgid "" "diverse routes to your highly available switch infrastructure." msgstr "在OpenStack架构下，基础设施是作为一个整体提供服务的，必须保证可用性，尤其是建立了服务水平协议。确保网络的可用性，在完成设计网络架构后不可以有单点故障存在。考虑使用多个交换机、路由器以及冗余的电源是必须考虑的，这是核心基础设施，使用bonding网卡、提供多个路由、交换机高可用等。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml598(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml706(para) msgid "" "The OpenStack services themselves should be deployed across multiple servers" " that do not represent a single point of failure. Ensuring API availability " @@ -5819,7 +5885,7 @@ msgid "" "balancers that have multiple OpenStack servers as members." msgstr "OpenStack自身的那些服务需要在跨多个服务器上部署，不能出现单点故障。确保应用程序接口的可用性，作为多个OpenStack服务的成员放在高可用负载均衡的后面。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml603(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml711(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 " @@ -5831,43 +5897,43 @@ msgid "" "scale out decisions." msgstr "OpenStack其本身的部署是期望高可用的，实现此需要至少两台服务器来完成。他们可以运行所有的服务，由消息队列服务连接起来，消息队列服务如RabbitMQ或QPID，还需要部署一个合适的数据库服务如MySQL或MariaDB。在云中所有的服务都是可横向扩展的，其实后端的服务同样需要扩展。检测和报告在服务器上的使用和采集，以及负载测试，都可以帮助作出横向扩展的决定。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml612(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml720(para) msgid "" "Care must be taken when deciding network functionality. Currently, OpenStack" " supports both the legacy networking (nova-network) system and the newer, " -"extensible OpenStack Networking. Both have their pros and cons when it comes" -" to providing highly available access. Legacy networking, which provides " -"networking access maintained in the OpenStack Compute code, provides a " -"feature that removes a single point of failure when it comes to routing, and" -" this feature is currently missing in OpenStack Networking. The effect of " -"legacy networking's multi-host functionality restricts failure domains to " -"the host running that instance." -msgstr "当决定网络功能的时候务必小心谨慎。当前的OpenStack不仅支持遗留网络(nova-network)系统还支持新的，可扩展的OpenStack网络(neutron)。二者在提供高可用访问时有各自的优缺点。遗留网络提供的网络服务的代码是由OpenStack计算来维护的，它可提供移除来自路由的单点故障特性，但是此特性在当前的Openstack网络中不被支持。遗留网络的多主机功能受限于仅在运行实例的主机，一旦失效，此实例将无法被访问。" +"extensible OpenStack Networking (neutron). Both have their pros and cons " +"when it comes to providing highly available access. Legacy networking, which" +" provides networking access maintained in the OpenStack Compute code, " +"provides a feature that removes a single point of failure when it comes to " +"routing, and this feature is currently missing in OpenStack Networking. The " +"effect of legacy networking’s multi-host functionality restricts failure " +"domains to the host running that instance." +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml623(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml731(para) msgid "" -"On the other hand, when using OpenStack Networking, the OpenStack controller" -" servers or separate Networking hosts handle routing. For a deployment that " -"requires features available in only Networking, it is possible to remove " -"this restriction by using third party software that helps maintain highly " +"When using OpenStack Networking, the OpenStack controller servers or " +"separate Networking hosts handle routing. For a deployment that requires " +"features available in only Networking, it is possible to remove this " +"restriction by using third party software that helps maintain highly " "available L3 routes. Doing so allows for common APIs to control network " "hardware, or to provide complex multi-tier web applications in a secure " "manner. It is also possible to completely remove routing from Networking, " "and instead rely on hardware routing capabilities. In this case, the " "switching infrastructure must support L3 routing." -msgstr "另一方面，当使用OpenStack网络时，OpenStack控制器服务器或者是分离的网络主机掌控路由。对于部署来说，需要在网络中满足此特性，有可能使用第三方软件来协助维护高可用的3层路由。这么做允许通常的应用程序接口来控制网络硬件，或者基于安全的行为提供复杂多层的web应用。从OpenStack网络中完全移除路由是可以的，取而代之的是硬件的路由能力。在此情况下，交换基础设施必须支持3层路由。" +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml635(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml743(para) msgid "" -"OpenStack Networking (neutron) and legacy networking (nova-network) both " -"have their advantages and disadvantages. They are both valid and supported " -"options that fit different network deployment models described in the " -"OpenStack " "Operations Guide." -msgstr "OpenStack网络(neutron)和遗留网络(nova-network)各有各的优点和缺点。它们有效的和支持的属性适合不同的网络部署模式，详细描述见OpenStack 运维指南。" +msgstr "" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml643(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml750(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" @@ -5878,7 +5944,7 @@ msgid "" "availability of controller nodes." msgstr "确保用户的部署有足够的后备能力。举例来说，部署是拥有两台基础设施的控制器节点，此设计须包括控制器可用。一旦丢失单个控制器这种事件发生，云服务将会停止对外服务。当有高可用需求的设计时，解决此需求的办法就是准备冗余的、高可用的控制器节点。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml652(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml759(para) msgid "" "Application design must also be factored into the capabilities of the " "underlying cloud infrastructure. If the compute hosts do not provide a " @@ -5892,14 +5958,14 @@ msgid "" "guarantee to match service features." msgstr "应用程序的设计也必须记入到云基础设施的能力之中。如果计算主机不能提供无缝的活迁移功能，就必须预料到一旦计算节点失效，运行在其上的实例，以及其中的数据，都不可访问。反过来讲，提供给用户的是具有高级别的运行时间保证的实例，基础设施必须被部署为没有任何的单点故障，即使是某计算主机消失，也得马上有其他主机顶上。这需要构建在企业级存储的共享文件系统之上，或者是OpenStack块存储，以满足保证级别和对应的服务匹配。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml664(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml771(para) msgid "" "For more information on high availability in OpenStack, see the OpenStack High Availability Guide." msgstr "关于OpenStack高可用更多信息，请阅读 OpenStack 高可用指南." -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml672(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml779(para) #: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml272(para) msgid "" "A security domain comprises users, applications, servers or networks that " @@ -5907,31 +5973,31 @@ msgid "" "they have the same authentication and authorization requirements and users." msgstr "一个安全域在一个系统下包括让用户、应用、服务器和网络共享通用的信任需求和预期。典型情况是他们有相同的认证和授权的需求和用户。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml676(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml783(para) #: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml277(para) msgid "These security domains are:" msgstr "这些安全域有：" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml679(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml786(para) #: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml280(para) #: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml120(para) msgid "Public" msgstr "公有" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml682(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml789(para) #: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml283(para) #: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml123(para) msgid "Guest" msgstr "客户机" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml688(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml795(para) #: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml289(para) #: ./doc/arch-design/hybrid/section_architecture_hybrid.xml166(title) #: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml129(para) msgid "Data" msgstr "数据" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml691(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml798(para) msgid "" "These security domains can be mapped to an OpenStack deployment " "individually, or combined. For example, some deployment topologies combine " @@ -5943,7 +6009,7 @@ msgid "" "cloud instance is public, private, or hybrid." msgstr "这些安全域可以映射给分开的OpenStack部署，也可以是合并的。例如，一些部署的拓扑合并了客户机和数据域在同一物理网络，其他一些情况的网络是物理分离的。无论那种情况，云运维人员必须意识到适当的安全问题。安全域须制定出针对特定的OpenStack部署拓扑。所谓的域和其信任的需求取决于云的实例是公有的，私有的，还是混合的。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml701(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml808(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 " @@ -5951,7 +6017,7 @@ msgid "" "considered untrusted." msgstr "公有安全域对于云基础设施是完全不可信任的区域。正如将内部暴露给整个互联网，或者是没有认证的简单网络。此域一定不可以被信任。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml705(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml812(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 " @@ -5964,7 +6030,7 @@ msgid "" "instances and all their tenants." msgstr "典型的用户计算服务中的实例对实际的互联互通，客户安全域，在云中掌握着由实例生成的计算机数据，但是不可以通过云来访问，包括应用程序接口调用。公有云或私有云提供商不会严格的控制实例的使用，以及谁受限访问互联网，所以应指定此域是不可信任的。或许私有云提供商可以稍宽松点，因为是内部网络，还有就是它可以控制所有的实例和租户。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml716(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml823(para) #: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml318(para) msgid "" "The management security domain is where services interact. Sometimes " @@ -5973,7 +6039,7 @@ msgid "" "passwords. In most deployments this domain is considered trusted." msgstr "管理安全域即是服务交互的集中地，想一下“控制面板”，在此域中网络传输的都是机密的数据，比如配置参数、用户名称、密码等。多数部署此域为信任的。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml721(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml828(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" @@ -5983,7 +6049,7 @@ msgid "" "decisions." msgstr "数据安全域主要关心的是OpenStack存储服务相关的信息。多数通过此网络的数据具有高度机密的要求，甚至在某些类型的部署中，还有高可用的需求。此网络的信任级别高度依赖于其他部署的决定。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml728(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml835(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 " @@ -5998,7 +6064,7 @@ msgid "" "protected against through auditing and appropriate filtering." msgstr "在一个企业部署OpenStack为私有云，通常是安置在防火墙之后，和原来的系统一并认为是可信任网络。云的用户即是原来的员工，由公司本来的安全需求所约束。这导致推动大部分的安全域趋向信任模式。但是，当部署OpenStack为面向公用的角色时，不要心存侥幸，它被攻击的几率大大增加。例如，应用程序接口端点，以及其背后的软件，很容易成为一些坏人下手的地方，获得未经授权的访问服务或者阻止其他人访问正常的服务，这可能会导致丢失数据、程序失效，乃至名声。这些服务必须被保护，通过审计以及适当的过滤来实现。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml742(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml849(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 " @@ -6006,7 +6072,7 @@ msgid "" "deployment may ease user management if integrating into existing systems." msgstr "无论是公有云还是私有云，管理用户的系统必须认真的考虑。身份认证服务允许LDAP作为认证流程的一部分。Including such systems in an OpenStack deployment may ease user management if integrating into existing systems." -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml748(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml855(para) msgid "" "It's important to understand that user authentication requests include " "sensitive information including user names, passwords and authentication " @@ -6014,12 +6080,12 @@ msgid "" "performs SSL termination is strongly recommended." msgstr "理解用户的认证需要一些敏感信息如用户名、密码和认证令牌是非常重要的。基于这个原因，强烈建议将认证的API服务隐藏在基于硬件的SSL终端之后。" -#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml753(para) +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml860(para) msgid "" -"For more information on OpenStack Security, see the OpenStack " "Security Guide" -msgstr "关于更多OpenStack安全方面的信息，请参考 OpenStack 安全指南" +msgstr "更多关于OpenStack安全的信息，请访问OpenStack 安全指南。" #: ./doc/arch-design/introduction/section_intended_audience.xml7(title) msgid "Intended audience" diff --git a/doc/install-guide/locale/install-guide.pot b/doc/install-guide/locale/install-guide.pot index 48565a2635..028205cdd5 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: 2015-02-08 06:11+0000\n" +"POT-Creation-Date: 2015-02-10 06:21+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" @@ -211,11 +211,11 @@ msgstr "" msgid "Start the Identity service and configure it to start when the system boots:" msgstr "" -#: ./doc/install-guide/section_keystone-install.xml:245(para) ./doc/install-guide/section_basics-database.xml:27(para) ./doc/install-guide/section_basics-database.xml:76(para) ./doc/install-guide/section_ceilometer-swift.xml:63(para) ./doc/install-guide/section_ceilometer-nova.xml:36(para) ./doc/install-guide/section_ceilometer-nova.xml:119(para) ./doc/install-guide/section_sahara-install.xml:97(para) ./doc/install-guide/section_ceilometer-cinder.xml:26(para) ./doc/install-guide/section_ceilometer-cinder.xml:34(para) ./doc/install-guide/section_cinder-storage-node.xml:264(para) ./doc/install-guide/section_cinder-controller-node.xml:255(para) ./doc/install-guide/section_basics-ntp.xml:60(para) ./doc/install-guide/section_basics-ntp.xml:102(para) ./doc/install-guide/section_nova-controller-install.xml:266(para) ./doc/install-guide/section_nova-networking-compute-node.xml:61(para) ./doc/install-guide/section_glance-install.xml:294(para) ./doc/install-guide/section_dashboard-install.xml:133(para) ./doc/install-guide/section_neutron-compute-node.xml:215(para) ./doc/install-guide/section_neutron-compute-node.xml:304(para) ./doc/install-guide/section_neutron-compute-node.xml:315(para) ./doc/install-guide/section_neutron-controller-node.xml:393(para) ./doc/install-guide/section_neutron-controller-node.xml:409(para) ./doc/install-guide/section_neutron-network-node.xml:434(para) ./doc/install-guide/section_neutron-network-node.xml:457(para) ./doc/install-guide/section_neutron-network-node.xml:533(para) ./doc/install-guide/section_trove-install.xml:236(para) ./doc/install-guide/section_nova-networking-controller-node.xml:31(para) ./doc/install-guide/section_nova-compute-install.xml:215(para) ./doc/install-guide/section_heat-install.xml:288(para) ./doc/install-guide/section_ceilometer-glance.xml:33(para) ./doc/install-guide/section_basics-queue.xml:49(para) ./doc/install-guide/section_ceilometer-controller.xml:26(para) ./doc/install-guide/section_ceilometer-controller.xml:78(para) ./doc/install-guide/section_ceilometer-controller.xml:375(para) ./doc/install-guide/object-storage/section_swift-finalize-installation.xml:68(para) ./doc/install-guide/object-storage/section_swift-finalize-installation.xml:106(para) ./doc/install-guide/object-storage/section_swift-storage-node.xml:169(para) ./doc/install-guide/object-storage/section_start-storage-node-services.xml:22(para) +#: ./doc/install-guide/section_keystone-install.xml:245(para) ./doc/install-guide/section_basics-database.xml:27(para) ./doc/install-guide/section_basics-database.xml:76(para) ./doc/install-guide/section_ceilometer-swift.xml:63(para) ./doc/install-guide/section_ceilometer-nova.xml:36(para) ./doc/install-guide/section_ceilometer-nova.xml:119(para) ./doc/install-guide/section_sahara-install.xml:97(para) ./doc/install-guide/section_ceilometer-cinder.xml:26(para) ./doc/install-guide/section_ceilometer-cinder.xml:34(para) ./doc/install-guide/section_cinder-storage-node.xml:264(para) ./doc/install-guide/section_cinder-controller-node.xml:255(para) ./doc/install-guide/section_basics-ntp.xml:60(para) ./doc/install-guide/section_basics-ntp.xml:102(para) ./doc/install-guide/section_nova-controller-install.xml:266(para) ./doc/install-guide/section_nova-networking-compute-node.xml:61(para) ./doc/install-guide/section_glance-install.xml:294(para) ./doc/install-guide/section_dashboard-install.xml:133(para) ./doc/install-guide/section_neutron-compute-node.xml:215(para) ./doc/install-guide/section_neutron-compute-node.xml:304(para) ./doc/install-guide/section_neutron-compute-node.xml:315(para) ./doc/install-guide/section_neutron-controller-node.xml:393(para) ./doc/install-guide/section_neutron-controller-node.xml:409(para) ./doc/install-guide/section_neutron-network-node.xml:434(para) ./doc/install-guide/section_neutron-network-node.xml:457(para) ./doc/install-guide/section_neutron-network-node.xml:533(para) ./doc/install-guide/section_trove-install.xml:236(para) ./doc/install-guide/section_nova-networking-controller-node.xml:31(para) ./doc/install-guide/section_nova-compute-install.xml:215(para) ./doc/install-guide/section_heat-install.xml:288(para) ./doc/install-guide/section_ceilometer-glance.xml:33(para) ./doc/install-guide/section_basics-queue.xml:49(para) ./doc/install-guide/section_ceilometer-controller.xml:26(para) ./doc/install-guide/section_ceilometer-controller.xml:78(para) ./doc/install-guide/section_ceilometer-controller.xml:375(para) ./doc/install-guide/object-storage/section_swift-finalize-installation.xml:68(para) ./doc/install-guide/object-storage/section_swift-finalize-installation.xml:106(para) ./doc/install-guide/object-storage/section_swift-storage-node.xml:169(para) msgid "On SLES:" msgstr "" -#: ./doc/install-guide/section_keystone-install.xml:248(para) ./doc/install-guide/section_basics-database.xml:25(para) ./doc/install-guide/section_basics-database.xml:79(para) ./doc/install-guide/section_ceilometer-swift.xml:65(para) ./doc/install-guide/section_ceilometer-nova.xml:38(para) ./doc/install-guide/section_ceilometer-nova.xml:122(para) ./doc/install-guide/section_sahara-install.xml:99(para) ./doc/install-guide/section_ceilometer-cinder.xml:29(para) ./doc/install-guide/section_ceilometer-cinder.xml:36(para) ./doc/install-guide/section_cinder-storage-node.xml:269(para) ./doc/install-guide/section_cinder-controller-node.xml:260(para) ./doc/install-guide/section_basics-ntp.xml:63(para) ./doc/install-guide/section_basics-ntp.xml:105(para) ./doc/install-guide/section_nova-controller-install.xml:279(para) ./doc/install-guide/section_nova-networking-compute-node.xml:66(para) ./doc/install-guide/section_glance-install.xml:299(para) ./doc/install-guide/section_dashboard-install.xml:138(para) ./doc/install-guide/section_neutron-compute-node.xml:218(para) ./doc/install-guide/section_neutron-compute-node.xml:306(para) ./doc/install-guide/section_neutron-compute-node.xml:318(para) ./doc/install-guide/section_neutron-controller-node.xml:397(para) ./doc/install-guide/section_neutron-controller-node.xml:412(para) ./doc/install-guide/section_neutron-network-node.xml:436(para) ./doc/install-guide/section_neutron-network-node.xml:460(para) ./doc/install-guide/section_neutron-network-node.xml:543(para) ./doc/install-guide/section_trove-install.xml:243(para) ./doc/install-guide/section_nova-networking-controller-node.xml:35(para) ./doc/install-guide/section_nova-compute-install.xml:220(para) ./doc/install-guide/section_heat-install.xml:295(para) ./doc/install-guide/section_ceilometer-glance.xml:36(para) ./doc/install-guide/section_basics-queue.xml:52(para) ./doc/install-guide/section_ceilometer-controller.xml:24(para) ./doc/install-guide/section_ceilometer-controller.xml:81(para) ./doc/install-guide/section_ceilometer-controller.xml:388(para) ./doc/install-guide/object-storage/section_swift-finalize-installation.xml:73(para) ./doc/install-guide/object-storage/section_swift-finalize-installation.xml:119(para) ./doc/install-guide/object-storage/section_swift-storage-node.xml:172(para) ./doc/install-guide/object-storage/section_start-storage-node-services.xml:28(para) +#: ./doc/install-guide/section_keystone-install.xml:248(para) ./doc/install-guide/section_basics-database.xml:25(para) ./doc/install-guide/section_basics-database.xml:79(para) ./doc/install-guide/section_ceilometer-swift.xml:65(para) ./doc/install-guide/section_ceilometer-nova.xml:38(para) ./doc/install-guide/section_ceilometer-nova.xml:122(para) ./doc/install-guide/section_sahara-install.xml:99(para) ./doc/install-guide/section_ceilometer-cinder.xml:29(para) ./doc/install-guide/section_ceilometer-cinder.xml:36(para) ./doc/install-guide/section_cinder-storage-node.xml:269(para) ./doc/install-guide/section_cinder-controller-node.xml:260(para) ./doc/install-guide/section_basics-ntp.xml:63(para) ./doc/install-guide/section_basics-ntp.xml:105(para) ./doc/install-guide/section_nova-controller-install.xml:279(para) ./doc/install-guide/section_nova-networking-compute-node.xml:66(para) ./doc/install-guide/section_glance-install.xml:299(para) ./doc/install-guide/section_dashboard-install.xml:138(para) ./doc/install-guide/section_neutron-compute-node.xml:218(para) ./doc/install-guide/section_neutron-compute-node.xml:306(para) ./doc/install-guide/section_neutron-compute-node.xml:318(para) ./doc/install-guide/section_neutron-controller-node.xml:397(para) ./doc/install-guide/section_neutron-controller-node.xml:412(para) ./doc/install-guide/section_neutron-network-node.xml:436(para) ./doc/install-guide/section_neutron-network-node.xml:460(para) ./doc/install-guide/section_neutron-network-node.xml:543(para) ./doc/install-guide/section_trove-install.xml:243(para) ./doc/install-guide/section_nova-networking-controller-node.xml:35(para) ./doc/install-guide/section_nova-compute-install.xml:220(para) ./doc/install-guide/section_heat-install.xml:295(para) ./doc/install-guide/section_ceilometer-glance.xml:36(para) ./doc/install-guide/section_basics-queue.xml:52(para) ./doc/install-guide/section_ceilometer-controller.xml:24(para) ./doc/install-guide/section_ceilometer-controller.xml:81(para) ./doc/install-guide/section_ceilometer-controller.xml:388(para) ./doc/install-guide/object-storage/section_swift-finalize-installation.xml:73(para) ./doc/install-guide/object-storage/section_swift-finalize-installation.xml:119(para) ./doc/install-guide/object-storage/section_swift-storage-node.xml:172(para) msgid "On openSUSE:" msgstr "" @@ -1609,11 +1609,11 @@ msgstr "" msgid "Create a test template in the test-stack.yml file with the following content:" msgstr "" -#: ./doc/install-guide/section_heat-verify.xml:56(para) +#: ./doc/install-guide/section_heat-verify.xml:50(para) msgid "Use the command to create a stack from the template:" msgstr "" -#: ./doc/install-guide/section_heat-verify.xml:68(para) +#: ./doc/install-guide/section_heat-verify.xml:62(para) msgid "Use the command to verify successful creation of the stack:" msgstr "" @@ -5185,22 +5185,6 @@ msgstr "" msgid "Copy the account.ring.gz, container.ring.gz, and object.ring.gz files to the /etc/swift directory on each storage node and any additional nodes running the proxy service." msgstr "" -#: ./doc/install-guide/object-storage/section_start-storage-node-services.xml:8(title) -msgid "Start services on the storage nodes" -msgstr "" - -#: ./doc/install-guide/object-storage/section_start-storage-node-services.xml:9(para) -msgid "Now that the ring files are on each storage node, you can start the services. On each storage node, run the following command:" -msgstr "" - -#: ./doc/install-guide/object-storage/section_start-storage-node-services.xml:35(para) -msgid "To start all swift services at once, run the command:" -msgstr "" - -#: ./doc/install-guide/object-storage/section_start-storage-node-services.xml:37(para) -msgid "To know more about swift-init command, run:" -msgstr "" - #: ./doc/install-guide/object-storage/section_swift-verify.xml:8(para) msgid "This section describes how to verify operation of the Object Storage service." msgstr "" diff --git a/doc/install-guide/locale/ja.po b/doc/install-guide/locale/ja.po index 3a5fffb27a..73c6488292 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: 2015-02-08 04:30+0000\n" -"PO-Revision-Date: 2015-02-07 18:13+0000\n" +"POT-Creation-Date: 2015-02-10 01:52+0000\n" +"PO-Revision-Date: 2015-02-10 02:23+0000\n" "Last-Translator: openstackjenkins \n" "Language-Team: Japanese (http://www.transifex.com/projects/p/openstack-manuals-i18n/language/ja/)\n" "MIME-Version: 1.0\n" @@ -534,7 +534,6 @@ msgstr "Identity のサービスを起動し、システム起動時に起動す #: ./doc/install-guide/object-storage/section_swift-finalize-installation.xml68(para) #: ./doc/install-guide/object-storage/section_swift-finalize-installation.xml106(para) #: ./doc/install-guide/object-storage/section_swift-storage-node.xml169(para) -#: ./doc/install-guide/object-storage/section_start-storage-node-services.xml22(para) msgid "On SLES:" msgstr "SLES の場合:" @@ -575,7 +574,6 @@ msgstr "SLES の場合:" #: ./doc/install-guide/object-storage/section_swift-finalize-installation.xml73(para) #: ./doc/install-guide/object-storage/section_swift-finalize-installation.xml119(para) #: ./doc/install-guide/object-storage/section_swift-storage-node.xml172(para) -#: ./doc/install-guide/object-storage/section_start-storage-node-services.xml28(para) msgid "On openSUSE:" msgstr "openSUSE の場合:" @@ -2965,11 +2963,11 @@ msgid "" "the following content:" msgstr "以下の内容を持つ test-stack.yml ファイルにテストテンプレートを作成します。" -#: ./doc/install-guide/section_heat-verify.xml56(para) +#: ./doc/install-guide/section_heat-verify.xml50(para) msgid "Use the command to create a stack from the template:" msgstr "テンプレートからスタックを作成するために コマンドを使用します。" -#: ./doc/install-guide/section_heat-verify.xml68(para) +#: ./doc/install-guide/section_heat-verify.xml62(para) msgid "" "Use the command to verify successful creation of the stack:" msgstr "スタックが正常に作成されたことを検証するために、 コマンドを使用します。" @@ -8303,24 +8301,6 @@ msgid "" "additional nodes running the proxy service." msgstr "各ストレージノード、プロキシーサービスを実行している追加ノードにおいて、 account.ring.gz ファイル、container.ring.gz ファイル、object.ring.gz ファイルを /etc/swift ディレクトリーにコピーします。" -#: ./doc/install-guide/object-storage/section_start-storage-node-services.xml8(title) -msgid "Start services on the storage nodes" -msgstr "ストレージノードでのサービスの起動" - -#: ./doc/install-guide/object-storage/section_start-storage-node-services.xml9(para) -msgid "" -"Now that the ring files are on each storage node, you can start the " -"services. On each storage node, run the following command:" -msgstr "これで、リングファイルが各ストレージノードに存在するので、サービスを起動できます。各ストレージノードで以下のコマンドを実行します。" - -#: ./doc/install-guide/object-storage/section_start-storage-node-services.xml35(para) -msgid "To start all swift services at once, run the command:" -msgstr "すべての Swift サービスを起動するために、次のコマンドを実行します。" - -#: ./doc/install-guide/object-storage/section_start-storage-node-services.xml37(para) -msgid "To know more about swift-init command, run:" -msgstr "swift-init コマンドについて詳しく知りたい場合、以下を実行します。" - #: ./doc/install-guide/object-storage/section_swift-verify.xml8(para) msgid "" "This section describes how to verify operation of the Object Storage " diff --git a/doc/install-guide/locale/ko_KR.po b/doc/install-guide/locale/ko_KR.po index 8ebd316e2d..9fe70e221d 100644 --- a/doc/install-guide/locale/ko_KR.po +++ b/doc/install-guide/locale/ko_KR.po @@ -17,8 +17,8 @@ msgid "" msgstr "" "Project-Id-Version: OpenStack Manuals\n" -"POT-Creation-Date: 2015-02-08 04:30+0000\n" -"PO-Revision-Date: 2015-02-07 18:13+0000\n" +"POT-Creation-Date: 2015-02-10 01:52+0000\n" +"PO-Revision-Date: 2015-02-10 02:23+0000\n" "Last-Translator: openstackjenkins \n" "Language-Team: Korean (Korea) (http://www.transifex.com/projects/p/openstack-manuals-i18n/language/ko_KR/)\n" "MIME-Version: 1.0\n" @@ -546,7 +546,6 @@ msgstr "Identity 서비스를 시작하고 시스템 부팅시 시작하도록 #: ./doc/install-guide/object-storage/section_swift-finalize-installation.xml68(para) #: ./doc/install-guide/object-storage/section_swift-finalize-installation.xml106(para) #: ./doc/install-guide/object-storage/section_swift-storage-node.xml169(para) -#: ./doc/install-guide/object-storage/section_start-storage-node-services.xml22(para) msgid "On SLES:" msgstr "SLES 상에서:" @@ -587,7 +586,6 @@ msgstr "SLES 상에서:" #: ./doc/install-guide/object-storage/section_swift-finalize-installation.xml73(para) #: ./doc/install-guide/object-storage/section_swift-finalize-installation.xml119(para) #: ./doc/install-guide/object-storage/section_swift-storage-node.xml172(para) -#: ./doc/install-guide/object-storage/section_start-storage-node-services.xml28(para) msgid "On openSUSE:" msgstr "openSUSE 상에서:" @@ -2977,11 +2975,11 @@ msgid "" "the following content:" msgstr "" -#: ./doc/install-guide/section_heat-verify.xml56(para) +#: ./doc/install-guide/section_heat-verify.xml50(para) msgid "Use the command to create a stack from the template:" msgstr "" -#: ./doc/install-guide/section_heat-verify.xml68(para) +#: ./doc/install-guide/section_heat-verify.xml62(para) msgid "" "Use the command to verify successful creation of the stack:" msgstr "" @@ -8315,24 +8313,6 @@ msgid "" "additional nodes running the proxy service." msgstr "" -#: ./doc/install-guide/object-storage/section_start-storage-node-services.xml8(title) -msgid "Start services on the storage nodes" -msgstr "저장소 노드에서 서비스 시작" - -#: ./doc/install-guide/object-storage/section_start-storage-node-services.xml9(para) -msgid "" -"Now that the ring files are on each storage node, you can start the " -"services. On each storage node, run the following command:" -msgstr "이제 링 파일을 각각의 저장소 노드에 놓았으므로 서비스를 시작할 수 있습니다. 각각의 저장소 노드에서 다음 명령을 실행하십시오:" - -#: ./doc/install-guide/object-storage/section_start-storage-node-services.xml35(para) -msgid "To start all swift services at once, run the command:" -msgstr "스위프트 서비스를 한번에 시작하려면 다음 명령을 실행하십시오:" - -#: ./doc/install-guide/object-storage/section_start-storage-node-services.xml37(para) -msgid "To know more about swift-init command, run:" -msgstr "swift-init 명령에 대해 더 알아보려면 다음 명령을 실행하십시오:" - #: ./doc/install-guide/object-storage/section_swift-verify.xml8(para) msgid "" "This section describes how to verify operation of the Object Storage " diff --git a/doc/install-guide/locale/pt_BR.po b/doc/install-guide/locale/pt_BR.po index 221b029f68..d12646e78b 100644 --- a/doc/install-guide/locale/pt_BR.po +++ b/doc/install-guide/locale/pt_BR.po @@ -12,8 +12,8 @@ msgid "" msgstr "" "Project-Id-Version: OpenStack Manuals\n" -"POT-Creation-Date: 2015-02-08 04:30+0000\n" -"PO-Revision-Date: 2015-02-07 18:13+0000\n" +"POT-Creation-Date: 2015-02-10 01:52+0000\n" +"PO-Revision-Date: 2015-02-10 02:23+0000\n" "Last-Translator: openstackjenkins \n" "Language-Team: Portuguese (Brazil) (http://www.transifex.com/projects/p/openstack-manuals-i18n/language/pt_BR/)\n" "MIME-Version: 1.0\n" @@ -541,7 +541,6 @@ msgstr "Inicie o serviço de Identidade e configure-o para iniciar quando o sist #: ./doc/install-guide/object-storage/section_swift-finalize-installation.xml68(para) #: ./doc/install-guide/object-storage/section_swift-finalize-installation.xml106(para) #: ./doc/install-guide/object-storage/section_swift-storage-node.xml169(para) -#: ./doc/install-guide/object-storage/section_start-storage-node-services.xml22(para) msgid "On SLES:" msgstr "No SLES:" @@ -582,7 +581,6 @@ msgstr "No SLES:" #: ./doc/install-guide/object-storage/section_swift-finalize-installation.xml73(para) #: ./doc/install-guide/object-storage/section_swift-finalize-installation.xml119(para) #: ./doc/install-guide/object-storage/section_swift-storage-node.xml172(para) -#: ./doc/install-guide/object-storage/section_start-storage-node-services.xml28(para) msgid "On openSUSE:" msgstr "No OpenSUSE:" @@ -2972,11 +2970,11 @@ msgid "" "the following content:" msgstr "Crie um modelo de teste no arquivo test-stack.yml com o seguinte conteúdo:" -#: ./doc/install-guide/section_heat-verify.xml56(para) +#: ./doc/install-guide/section_heat-verify.xml50(para) msgid "Use the command to create a stack from the template:" msgstr "Utilize o comando para criar a pilha através do modelo:" -#: ./doc/install-guide/section_heat-verify.xml68(para) +#: ./doc/install-guide/section_heat-verify.xml62(para) msgid "" "Use the command to verify successful creation of the stack:" msgstr "Utilize o comando para verificar a criação com sucesso da pilha:" @@ -8310,24 +8308,6 @@ msgid "" "additional nodes running the proxy service." msgstr "Copie os arquivos account.ring.gz, container.ring.gz, e object.ring.gz para o diretório /etc/swift em cada nodo de armazenamento e em quaisquer nodos adicionais que estejam executando o serviço de proxy." -#: ./doc/install-guide/object-storage/section_start-storage-node-services.xml8(title) -msgid "Start services on the storage nodes" -msgstr "Iniciar serviços nos nodos de armazenamento" - -#: ./doc/install-guide/object-storage/section_start-storage-node-services.xml9(para) -msgid "" -"Now that the ring files are on each storage node, you can start the " -"services. On each storage node, run the following command:" -msgstr "Agora que os arquivos do anel estão em cada nodo de armazenamento, você pode iniciar os serviços. Em cada nodo de armazenamento execute o seguinte comando:" - -#: ./doc/install-guide/object-storage/section_start-storage-node-services.xml35(para) -msgid "To start all swift services at once, run the command:" -msgstr "Para iniciar todos os serviços swift de uma vez, execute o comando:" - -#: ./doc/install-guide/object-storage/section_start-storage-node-services.xml37(para) -msgid "To know more about swift-init command, run:" -msgstr "Para saber mais sobre o comando swift-init, execute:" - #: ./doc/install-guide/object-storage/section_swift-verify.xml8(para) msgid "" "This section describes how to verify operation of the Object Storage "