Imported Translations from Transifex
For more information about this automatic import see: https://wiki.openstack.org/wiki/Translations/Infrastructure Change-Id: If783878fb3f63e45912e7ffbaf6041382d0c519d
This commit is contained in:
OpenStack Proposal Bot
parent
6b4aa47f9a
commit
b4823abfb6
@ -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 <EMAIL@ADDRESS>\n"
|
||||
"Language-Team: LANGUAGE <LL@li.org>\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, <filename>m1.tiny</filename>, 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 <link href=\"http://docs.openstack.org/juno/config-reference/content/\"><citetitle>OpenStack Configuration Reference</citetitle></link>."
|
||||
#: ./doc/admin-guide-cloud/ch_compute.xml:201(para)
|
||||
msgid "In addition to the ephemeral root volume, all default types of flavors, except <literal>m1.tiny</literal>, 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 <systemitem class=\"service\">cloud-init</systemitem> package included into an Ubuntu's stock cloud image, by default, formats this space as an Ext4 file system and mounts it on <filename>/mnt</filename>. 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 <link href=\"http://docs.openstack.org/juno/config-reference/content/\"><citetitle>OpenStack Configuration Reference</citetitle></link>."
|
||||
#: ./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 <link href=\"http://docs.openstack.org/juno/config-reference/content/\"><citetitle>OpenStack Configuration Reference</citetitle></link>."
|
||||
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 <link href=\"http://docs.openstack.org/juno/config-reference/content/\"><citetitle>OpenStack Configuration Reference</citetitle></link>."
|
||||
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 <link href=\"http://open.eucalyptus.com/wiki/Euca2oolsGuide\">euca2ools site</link>."
|
||||
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 <link href=\"http://code.google.com/p/hybridfox/\"> hybridfox site</link>."
|
||||
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 <link href=\"https://github.com/boto/boto\"> boto project page on GitHub</link>."
|
||||
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 <link href=\"https://rubygems.org/gems/fog\"> fog site</link>."
|
||||
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 <link href=\"http://www.php-opencloud.com\"> php-opencloud site</link>."
|
||||
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: <placeholder-1/>"
|
||||
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 <literal>ACTIVE</literal> 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 <literal>flavors</literal>. 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 <parameter>compute_extension:flavormanage</parameter> in <filename>/etc/nova/policy.json</filename> on the <filename>compute-api</filename> 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 ""
|
||||
|
||||
|
||||
@ -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 <EMAIL@ADDRESS>\n"
|
||||
"Language-Team: LANGUAGE <LL@li.org>\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 <firstterm>overcommit ratio</firstterm> is the ratio of available virtual resources, compared to the available physical resources. OpenStack is able to configure the overcommit ratio for CPU and memory. The default CPU overcommit ratio is 16:1 and the default memory overcommit ratio is 1.5:1. Determining the tuning of the overcommit ratios for both of these options during the design phase is important as it has a direct impact on the hardware layout of your compute nodes."
|
||||
msgstr ""
|
||||
|
||||
#: ./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 <link href=\"https://wiki.openstack.org/wiki/HypervisorSupportMatrix\">https://wiki.openstack.org/wiki/HypervisorSupportMatrix</link>."
|
||||
#: ./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 <glossterm>Compute</glossterm> (<glossterm>nova</glossterm>)"
|
||||
#: ./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 <glossterm>Networking</glossterm> (<glossterm>neutron</glossterm>)"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:429(para)
|
||||
msgid "OpenStack <glossterm>Image Service</glossterm> (<glossterm>glance</glossterm>)"
|
||||
#: ./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 <glossterm>Identity</glossterm> (<glossterm>keystone</glossterm>)"
|
||||
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 <glossterm>dashboard</glossterm> (<glossterm>horizon</glossterm>)"
|
||||
#: ./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 "<glossterm>Telemetry</glossterm> module (<glossterm>ceilometer</glossterm>)"
|
||||
#: ./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 <glossterm>Object Storage</glossterm> (<glossterm>swift</glossterm>). OpenStack <glossterm>Block Storage</glossterm> (<glossterm>cinder</glossterm>) 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 <link href=\"https://wiki.openstack.org/wiki/HypervisorSupportMatrix\">OpenStack Hypervisor Support Matrix</link>."
|
||||
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 <glossterm>Compute</glossterm> (<glossterm>nova</glossterm>)"
|
||||
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 <glossterm>Networking</glossterm> (<glossterm>neutron</glossterm>)"
|
||||
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 <glossterm>Image Service</glossterm> (<glossterm>glance</glossterm>)"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:524(para)
|
||||
msgid "OpenStack <glossterm>Identity</glossterm> (<glossterm>keystone</glossterm>)"
|
||||
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 <glossterm>dashboard</glossterm> (<glossterm>horizon</glossterm>)"
|
||||
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 "<glossterm>Telemetry</glossterm> module (<glossterm>ceilometer</glossterm>)"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:536(para)
|
||||
msgid "A general purpose cloud may also include OpenStack <glossterm>Object Storage</glossterm> (<glossterm>swift</glossterm>). OpenStack <glossterm>Block Storage</glossterm> (<glossterm>cinder</glossterm>). These may be selected to provide storage to applications and instances."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml: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 <citetitle><link href=\"http://docs.openstack.org/openstack-ops/content/network_design.html#network_deployment_options\">OpenStack Operations Guide</link></citetitle>."
|
||||
#: ./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 <citetitle><link href=\"http://docs.openstack.org/openstack-ops/content/network_design.html#network_deployment_options\">OpenStack Operations Guide</link></citetitle>."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml: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 <link href=\"http://docs.openstack.org/high-availability-guide\"><citetitle>OpenStack High Availability Guide</citetitle></link>."
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml: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 <link href=\"http://docs.openstack.org/security-guide/\"><citetitle>OpenStack Security Guide</citetitle></link>"
|
||||
#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:860(para)
|
||||
msgid "For more information OpenStack Security, see the <link href=\"http://docs.openstack.org/security-guide/\"><citetitle>OpenStack Security Guide</citetitle></link>"
|
||||
msgstr ""
|
||||
|
||||
#: ./doc/arch-design/introduction/section_intended_audience.xml:7(title)
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -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 <EMAIL@ADDRESS>\n"
|
||||
"Language-Team: LANGUAGE <LL@li.org>\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 <filename>test-stack.yml</filename> 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 <placeholder-1/> 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 <placeholder-1/> command to verify successful creation of the stack:"
|
||||
msgstr ""
|
||||
|
||||
@ -5185,22 +5185,6 @@ msgstr ""
|
||||
msgid "Copy the <filename>account.ring.gz</filename>, <filename>container.ring.gz</filename>, and <filename>object.ring.gz</filename> files to the <literal>/etc/swift</literal> 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 <literal>swift-init</literal> 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 ""
|
||||
|
||||
@ -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 <jenkins@openstack.org>\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 "以下の内容を持つ <filename>test-stack.yml</filename> ファイルにテストテンプレートを作成します。"
|
||||
|
||||
#: ./doc/install-guide/section_heat-verify.xml56(para)
|
||||
#: ./doc/install-guide/section_heat-verify.xml50(para)
|
||||
msgid "Use the <placeholder-1/> command to create a stack from the template:"
|
||||
msgstr "テンプレートからスタックを作成するために <placeholder-1/> コマンドを使用します。"
|
||||
|
||||
#: ./doc/install-guide/section_heat-verify.xml68(para)
|
||||
#: ./doc/install-guide/section_heat-verify.xml62(para)
|
||||
msgid ""
|
||||
"Use the <placeholder-1/> command to verify successful creation of the stack:"
|
||||
msgstr "スタックが正常に作成されたことを検証するために、<placeholder-1/> コマンドを使用します。"
|
||||
@ -8303,24 +8301,6 @@ msgid ""
|
||||
"additional nodes running the proxy service."
|
||||
msgstr "各ストレージノード、プロキシーサービスを実行している追加ノードにおいて、 <filename>account.ring.gz</filename> ファイル、<filename>container.ring.gz</filename> ファイル、<filename>object.ring.gz</filename> ファイルを <literal>/etc/swift</literal> ディレクトリーにコピーします。"
|
||||
|
||||
#: ./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 <literal>swift-init</literal> command, run:"
|
||||
msgstr "<literal>swift-init</literal> コマンドについて詳しく知りたい場合、以下を実行します。"
|
||||
|
||||
#: ./doc/install-guide/object-storage/section_swift-verify.xml8(para)
|
||||
msgid ""
|
||||
"This section describes how to verify operation of the Object Storage "
|
||||
|
||||
@ -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 <jenkins@openstack.org>\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 <placeholder-1/> 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 <placeholder-1/> 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 <literal>swift-init</literal> command, run:"
|
||||
msgstr "<literal>swift-init</literal> 명령에 대해 더 알아보려면 다음 명령을 실행하십시오:"
|
||||
|
||||
#: ./doc/install-guide/object-storage/section_swift-verify.xml8(para)
|
||||
msgid ""
|
||||
"This section describes how to verify operation of the Object Storage "
|
||||
|
||||
@ -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 <jenkins@openstack.org>\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 <filename>test-stack.yml</filename> com o seguinte conteúdo:"
|
||||
|
||||
#: ./doc/install-guide/section_heat-verify.xml56(para)
|
||||
#: ./doc/install-guide/section_heat-verify.xml50(para)
|
||||
msgid "Use the <placeholder-1/> command to create a stack from the template:"
|
||||
msgstr "Utilize o comando <placeholder-1/> 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 <placeholder-1/> command to verify successful creation of the stack:"
|
||||
msgstr "Utilize o comando <placeholder-1/> para verificar a criação com sucesso da pilha:"
|
||||
@ -8310,24 +8308,6 @@ msgid ""
|
||||
"additional nodes running the proxy service."
|
||||
msgstr "Copie os arquivos <filename>account.ring.gz</filename>, <filename>container.ring.gz</filename>, e <filename>object.ring.gz</filename> para o diretório <literal>/etc/swift</literal> 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 <literal>swift-init</literal> command, run:"
|
||||
msgstr "Para saber mais sobre o comando <literal>swift-init</literal>, execute:"
|
||||
|
||||
#: ./doc/install-guide/object-storage/section_swift-verify.xml8(para)
|
||||
msgid ""
|
||||
"This section describes how to verify operation of the Object Storage "
|
||||
|
||||
Loading…
Reference in New Issue
Block a user