[ops-guide] Cleanup arch examples chapter
Change-Id: I5d229acce9a316fc22c9c82f7338dfae7f0a9004 Implements: blueprint ops-guide-rst
This commit is contained in:
KATO Tomoyuki
parent
901d1a8327
commit
552fbcbd32
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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 <Block Storage service>`:
|
||||
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 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 <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 <Object Storage service>`: 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
|
||||
<http://docs.openstack.org/havana/config-reference/content/ch_configuring-openstack-identity.html#configuring-keystone-for-ldap-backend>`_.
|
||||
<http://docs.openstack.org/mitaka/config-reference/identity/options.html#keystone-ldap>`_.
|
||||
|
||||
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 <http://docs.openstack.org/havana/install-guide/install/apt/content/nova-network.html>`_
|
||||
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 <http://docs.openstack.org/havana/install-guide/install/apt/content/nova-network.html>`_
|
||||
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
|
||||
<http://docs.openstack.org/#install-guides>`_ for your distribution).
|
||||
|
||||
- Add additional OpenStack Block Storage hosts (see
|
||||
:doc:`ops_maintenance`).
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
Loading…
Reference in New Issue