diff --git a/doc/ops-guide/source/arch_example_neutron.rst b/doc/ops-guide/source/arch_example_neutron.rst index b134a98d6d..59e881f598 100644 --- a/doc/ops-guide/source/arch_example_neutron.rst +++ b/doc/ops-guide/source/arch_example_neutron.rst @@ -110,11 +110,13 @@ Node types This section gives you a breakdown of the different nodes that make up the OpenStack environment. A node is a physical machine that is provisioned with an operating system, and running a defined software -stack on top of it. The table below provides node descriptions and +stack on top of it. :ref:`table_node_types` provides node descriptions and specifications. -.. list-table:: Node types - :widths: 33 33 33 +.. _table_node_types: + +.. list-table:: Table. Node types + :widths: 20 50 30 :header-rows: 1 * - Type @@ -297,40 +299,45 @@ Initial deployment Initially, the connection setup should revolve around keeping the connectivity simple and straightforward in order to minimize deployment -complexity and time to deploy. The deployment shown below aims to have 1 × 10G -connectivity available to all compute nodes, while still leveraging bonding on -appropriate nodes for maximum performance. +complexity and time to deploy. +The deployment shown in :ref:`figure_basic_node_deployment` aims to +have 1 × 10G connectivity available to all compute nodes, while still +leveraging bonding on appropriate nodes for maximum performance. + +.. _figure_basic_node_deployment: .. figure:: figures/osog_0101.png :alt: Basic node deployment :width: 100% - Basic node deployment + Figure. Basic node deployment Connectivity for maximum performance ------------------------------------ If the networking performance of the basic layout is not enough, you can -move to the design below, which provides 2 × 10G network -links to all instances in the environment as well as providing more +move to :ref:`figure_performance_node_deployment`, which provides 2 × 10G +network links to all instances in the environment as well as providing more network bandwidth to the storage layer. +.. _figure_performance_node_deployment: + .. figure:: figures/osog_0102.png :alt: Performance node deployment :width: 100% - Performance node deployment + Figure. Performance node deployment Node diagrams ~~~~~~~~~~~~~ -The following diagrams include logical -information about the different types of nodes, indicating what services -will be running on top of them and how they interact with each other. -The diagrams also illustrate how the availability and scalability of -services are achieved. +The following diagrams, :ref:`controller_node` through :ref:`storage_node`, +include logical information about the different types of nodes, indicating +what services will be running on top of them and how they interact with +each other. The diagrams also illustrate how the availability and +scalability of services are achieved. .. _controller_node: @@ -338,7 +345,7 @@ services are achieved. :alt: Controller node :width: 100% - Controller node + Figure. Controller node .. _compute_node: @@ -346,7 +353,7 @@ services are achieved. :alt: Compute node :width: 100% - Compute node + Figure. Compute node .. _network_node: @@ -354,7 +361,7 @@ services are achieved. :alt: Network node :width: 100% - Network node + Figure. Network node .. _storage_node: @@ -362,17 +369,20 @@ services are achieved. :alt: Storage node :width: 100% - Storage node + Figure. Storage node Example Component Configuration ------------------------------- -The following tables include example configuration +:ref:`third_party_component_configuration` and +:ref:`openstack_component_configuration` include example configuration and considerations for both third-party and OpenStack components: -.. list-table:: Table: Third-party component configuration - :widths: 25 25 25 25 +.. _third_party_component_configuration: + +.. list-table:: Table. Third-party component configuration + :widths: 10 30 30 30 :header-rows: 1 * - Component @@ -454,8 +464,10 @@ and considerations for both third-party and OpenStack components: | -.. list-table:: Table: OpenStack component configuration - :widths: 20 20 20 20 20 +.. _openstack_component_configuration: + +.. list-table:: Table. OpenStack component configuration + :widths: 10 10 20 30 30 :header-rows: 1 * - Component @@ -523,7 +535,7 @@ and considerations for both third-party and OpenStack components: achieved linearly by adding in more compute nodes. * - Block Storage (cinder) - Controller - - Configured to use Qpid, ``qpid_heartbeat = ``\ ``10``,configured to + - Configured to use Qpid, ``qpid_heartbeat = ``10``,configured to use a Gluster volume from the storage layer as the back end for Block Storage, using the Gluster native client. - Block Storage API, scheduler, and volume services are run on all diff --git a/doc/ops-guide/source/arch_example_nova_network.rst b/doc/ops-guide/source/arch_example_nova_network.rst index a2517b3f51..a3a7f9fbe6 100644 --- a/doc/ops-guide/source/arch_example_nova_network.rst +++ b/doc/ops-guide/source/arch_example_nova_network.rst @@ -75,27 +75,27 @@ those deviations next. - :term:`Dashboard`: You probably want to offer a dashboard, but your users may be more interested in API access only. - - Block storage: You don't have to offer users block storage if - their use case only needs ephemeral storage on compute nodes, for - example. + - :term:`Block storage `: + You don't have to offer users block storage if their use case only + needs ephemeral storage on compute nodes, for example. - - Floating IP address: Floating IP addresses are public IP - addresses that you allocate from a predefined pool to assign to - virtual machines at launch. Floating IP address ensure that the - public IP address is available whenever an instance is booted. - Not every organization can offer thousands of public floating IP - addresses for thousands of instances, so this feature is - considered optional. + - :term:`Floating IP address `: + Floating IP addresses are public IP addresses that you allocate + from a predefined pool to assign to virtual machines at launch. + Floating IP address ensure that the public IP address is available + whenever an instance is booted. Not every organization can offer + thousands of public floating IP addresses for thousands of + instances, so this feature is considered optional. - - Live migration: If you need to move running virtual machine - instances from one host to another with little or no service - interruption, you would enable live migration, but it is - considered optional. + - :term:`Live migration `: If you need to move + running virtual machine instances from one host to another with + little or no service interruption, you would enable live migration, + but it is considered optional. - - Object storage: You may choose to store machine images on a file - system rather than in object storage if you do not have the extra - hardware for the required replication and redundancy that - OpenStack Object Storage offers. + - :term:`Object storage `: You may choose to + store machine images on a file system rather than in object storage + if you do not have the extra hardware for the required replication + and redundancy that OpenStack Object Storage offers. Rationale ~~~~~~~~~ @@ -157,7 +157,7 @@ We chose the *SQL back end for Identity* over others, such as LDAP. This back end is simple to install and is robust. The authors acknowledge that many installations want to bind with existing directory services and caution careful understanding of the `array of options available -`_. +`_. Block Storage (cinder) is installed natively on external storage nodes and uses the *LVM/iSCSI plug-in*. Most Block Storage plug-ins are tied @@ -191,12 +191,12 @@ and the instances cannot access the Internet. The single node that runs the ``nova-network`` service can become a bottleneck if excessive network traffic comes in and goes out of the cloud. -.. note:: +.. tip:: - `Multi-host `_ - is a high-availability option for the network configuration, where - the ``nova-network`` service is run on every compute node instead of - running on only a single node. + `Multi-host `_ + is a high-availability option for the network configuration, where + the ``nova-network`` service is run on every compute node instead of + running on only a single node. Detailed Description -------------------- @@ -253,7 +253,8 @@ optional extensions follows: - Add additional cloud controllers (see :doc:`ops_maintenance`). - Add an OpenStack Storage service (see the Object Storage chapter in - the *OpenStack Installation Guide* for your distribution). + the `OpenStack Installation Guide + `_ for your distribution). - Add additional OpenStack Block Storage hosts (see :doc:`ops_maintenance`). diff --git a/doc/ops-guide/source/arch_examples.rst b/doc/ops-guide/source/arch_examples.rst index f91bcb5fb7..e9686c9fd1 100644 --- a/doc/ops-guide/source/arch_examples.rst +++ b/doc/ops-guide/source/arch_examples.rst @@ -17,7 +17,7 @@ documenting, as well as to provide the scope for this guide. Both of the offered architecture examples are currently running in production and serving users. -.. note:: +.. tip:: As always, refer to the :doc:`common/glossary` if you are unclear about any of the terminology mentioned in architecture examples.