openstack/openstack-manuals
Code Issues Proposed changes

Fix incorrect RST markups

Browse Source 
also, remove improper internal reference target.

Change-Id: I49c969eab536e3a40c7a7b05481982e5d0cdb75c
This commit is contained in:
KATO Tomoyuki 2016-09-28 18:43:15 +09:00
parent 52d17f2604
commit a972884d16
2 changed files with 15 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
doc/arch-design-draft/source/use-cases/use-case-multisite.rst
View File

@ -81,12 +81,10 @@ The follow figure depicts the solution designed to have both a
centralized set of core data centers for OpenStack services and paired edge
data centers.
**Multi-site architecture example**
**Multi-site architecture example**
.. figure:: ../figures/Multi-Site_Customer_Edge.png
Geo-redundant load balancing example
------------------------------------
@ -166,13 +164,10 @@ An external load balancing service was used and not the LBaaS in
OpenStack because the solution in OpenStack is not redundant and does
not have any awareness of geo location.
.. _ms-geo-redundant:
**Multi-site geo-redundant architecture**
**Multi-site geo-redundant architecture**
.. figure:: ../figures/Multi-site_Geo_Redundant_LB.png
Location-local service example
------------------------------
@ -192,15 +187,13 @@ number of network hops for end users. Despite these differences, the
storage replication configuration has significant overlap with that of a
geo-redundant load balancing use case.
In :ref:`ms-shared-keystone`, the application utilizing this multi-site
In the below architecture, the application utilizing this multi-site
OpenStack install that is location-aware would launch web server or content
serving instances on the compute cluster in each site. Requests from clients
are first sent to a global services load balancer that determines the location
of the client, then routes the request to the closest OpenStack site where the
application completes the request.
.. _ms-shared-keystone:
**Multi-site shared keystone architecture**
.. figure:: ../figures/Multi-Site_shared_keystone1.png
**Multi-site shared keystone architecture**

22
doc/ha-guide/source/shared-database-configure.rst
View File

@ -33,11 +33,11 @@ Galera Cluster requires that you open four ports to network traffic:
This can be achieved through the use of either the ``iptables``
command such as:
.. code-block:: console
.. code-block:: console
# iptables --append INPUT --in-interface eth0 \
--protocol tcp --match tcp --dport ${PORT} \
--source ${NODE-IP-ADDRESS} --jump ACCEPT
# iptables --append INPUT --in-interface eth0 \
--protocol tcp --match tcp --dport ${PORT} \
--source ${NODE-IP-ADDRESS} --jump ACCEPT
Make sure to save the changes once you are done, this will vary
depending on your distribution:
@ -49,10 +49,10 @@ Alternatively you may be able to make modifications using the
``firewall-cmd`` utility for FirewallD that is available on many Linux
distributions:
.. code-block:: console
.. code-block:: console
# firewall-cmd --add-service=mysql --permanent
# firewall-cmd --add-port=3306/tcp --permanent
# firewall-cmd --add-service=mysql --permanent
# firewall-cmd --add-port=3306/tcp --permanent
SELinux
--------
@ -67,17 +67,17 @@ To configure SELinux to permit Galera Cluster to operate, you may need
to use the ``semanage`` utility to open the ports it uses, for
example:
.. code-block:: console
.. code-block:: console
# semanage port -a -t mysqld_port_t -p tcp 3306
# semanage port -a -t mysqld_port_t -p tcp 3306
Older versions of some distributions, which do not have an up-to-date
policy for securing Galera, may also require SELinux to be more
relaxed about database access and actions:
.. code-block:: console
.. code-block:: console
# semanage permissive -a mysqld_t
# semanage permissive -a mysqld_t
.. note:: Bear in mind, leaving SELinux in permissive mode is not a good
security practice. Over the longer term, you need to develop a