kolla-ansible/doc/source/user/multi-regions.rst
confi-surya dbf754655f Following the new PTI for document build
For compliance with the Project Testing Interface [1]
as described in [2]

[1]
https://governance.openstack.org/tc/reference/project-testing-interface.html
[2]
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125710.html

doc8 command is dropped from docs tox envs.
So this affect nothing and run in PEP8.

Related-Bug: #1765348

Depends-On: Icc7fe3a8f9716281de88825e9d5b2fd84de3d00a
Change-Id: Idf9a16111479ccc64004eac9508da575822a3df5
2018-05-21 10:51:59 +01:00

170 lines
5.2 KiB
ReStructuredText

.. _multi-regions:
======================================
Multiple Regions Deployment with Kolla
======================================
This section describes how to perform a basic multiple regions deployment
with Kolla. A basic multiple regions deployment consists of separate
OpenStack installation in two or more regions (RegionOne, RegionTwo, ...)
with a shared Keystone and Horizon. The rest of this documentation assumes
Keystone and Horizon are deployed in RegionOne, and other regions have
access to the admin endpoint (for example, ``kolla_internal_fqdn``) of
RegionOne.
It also assumes that the operator knows the name of all OpenStack regions
in advance, and considers as many Kolla deployments as there are regions.
There is specifications of multiple regions deployment at
`Multi Region Support for Heat
<https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat>`__.
Deployment of the first region with Keystone and Horizon
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Deployment of the first region results in a typical Kolla deployment
whenever, it is an *all-in-one* or *multinode* deployment (see
:doc:`quickstart`). It only requires slight modifications in the
``/etc/kolla/globals.yml`` configuration file. First of all, ensure that
Keystone and Horizon are enabled:
.. code-block:: console
enable_keystone: "yes"
enable_horizon: "yes"
.. end
Then, change the value of ``multiple_regions_names`` to add names of other
regions. In this example, we consider two regions. The current one,
formerly knows as RegionOne, that is hided behind
``openstack_region_name`` variable, and the RegionTwo:
.. code-block:: yaml
openstack_region_name: "RegionOne"
multiple_regions_names:
- "{{ openstack_region_name }}"
- "RegionTwo"
.. end
.. note::
Kolla uses these variables to create necessary endpoints into
Keystone so that services of other regions can access it. Kolla
also updates the Horizon ``local_settings`` to support multiple
regions.
Finally, note the value of ``kolla_internal_fqdn`` and run
``kolla-ansible``. The ``kolla_internal_fqdn`` value will be used by other
regions to contact Keystone. For the sake of this example, we assume the
value of ``kolla_internal_fqdn`` is ``10.10.10.254``.
Deployment of other regions
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Deployment of other regions follows an usual Kolla deployment except that
OpenStack services connect to the RegionOne's Keystone. This implies to
update the ``/etc/kolla/globals.yml`` configuration file to tell Kolla how
to reach Keystone. In the following, ``kolla_internal_fqdn_r1`` refers to
the value of ``kolla_internal_fqdn`` in RegionOne:
.. code-block:: yaml
kolla_internal_fqdn_r1: 10.10.10.254
keystone_admin_url: "{{ admin_protocol }}://{{ kolla_internal_fqdn_r1 }}:{{ keystone_admin_port }}"
keystone_internal_url: "{{ internal_protocol }}://{{ kolla_internal_fqdn_r1 }}:{{ keystone_public_port }}"
openstack_auth:
auth_url: "{{ admin_protocol }}://{{ kolla_internal_fqdn_r1 }}:{{ keystone_admin_port }}"
username: "admin"
password: "{{ keystone_admin_password }}"
project_name: "admin"
domain_name: "default"
.. end
Configuration files of cinder,nova,neutron,glance... have to be updated to
contact RegionOne's Keystone. Fortunately, Kolla offers to override all
configuration files at the same time thanks to the
``node_custom_config`` variable (see :ref:`service-config`). This
implies to create a ``global.conf`` file with the following content:
.. code-block:: ini
[keystone_authtoken]
www_authenticate_uri = {{ keystone_internal_url }}
auth_url = {{ keystone_admin_url }}
.. end
The Placement API section inside the nova configuration file also has
to be updated to contact RegionOne's Keystone. So create, in the same
directory, a ``nova.conf`` file with below content:
.. code-block:: ini
[placement]
auth_url = {{ keystone_admin_url }}
.. end
The Heat section inside the configuration file also
has to be updated to contact RegionOne's Keystone. So create, in the same
directory, a ``heat.conf`` file with below content:
.. code-block:: ini
[trustee]
www_authenticate_uri = {{ keystone_internal_url }}
auth_url = {{ keystone_internal_url }}
[ec2authtoken]
www_authenticate_uri = {{ keystone_internal_url }}
[clients_keystone]
www_authenticate_uri = {{ keystone_internal_url }}
.. end
The Ceilometer section inside the configuration file also
has to be updated to contact RegionOne's Keystone. So create, in the same
directory, a ``ceilometer.conf`` file with below content:
.. code-block:: ini
[service_credentials]
auth_url = {{ keystone_internal_url }}
.. end
And link the directory that contains these files into the
``/etc/kolla/globals.yml``:
.. code-block:: yaml
node_custom_config: path/to/the/directory/of/global&nova_conf/
.. end
Also, change the name of the current region. For instance, RegionTwo:
.. code-block:: yaml
openstack_region_name: "RegionTwo"
.. end
Finally, disable the deployment of Keystone and Horizon that are
unnecessary in this region and run ``kolla-ansible``:
.. code-block:: yaml
enable_keystone: "no"
enable_horizon: "no"
.. end
The configuration is the same for any other region.