f125a8b892
This change addresses a long-standing issue in rST documentation imported from XML.
That import process added backslash escapes in front of various characters. The three
most common being '(', ')', and '_'.
These instances are removed.
Signed-off-by: Ron Stone <ronald.stone@windriver.com>
Change-Id: Id43a9337ffcd505ccbdf072d7b29afdb5d2c997e
104 lines
4.6 KiB
ReStructuredText
104 lines
4.6 KiB
ReStructuredText
.. bwx1558617101415
|
|
.. _distributed-cloud-architecture:
|
|
|
|
==============================
|
|
Distributed Cloud Architecture
|
|
==============================
|
|
|
|
A |prod-dc| system consists of a Central Cloud and one or more subclouds
|
|
connected to the Central Cloud over L3 networks.
|
|
|
|
The Central Cloud has two regions: RegionOne, used to manage the nodes in the
|
|
Central Cloud, and System Controller, used to manage the subclouds in the
|
|
|prod-dc| system. You can select RegionOne or System Controller regions from the
|
|
Horizon Web interface or by setting the <OS_REGION_NAME> environment variable
|
|
if using the CLI.
|
|
|
|
**Central Cloud**
|
|
The Central Cloud provides a RegionOne region for managing the physical
|
|
platform of the Central Cloud and the System Controller region for managing
|
|
and orchestrating over the subclouds.
|
|
|
|
The Central Cloud does not support worker hosts. All worker functions are
|
|
performed at the subcloud level.
|
|
|
|
**RegionOne**
|
|
RegionOne is the name of the access mode, or region, for managing the
|
|
Central Cloud's physical platform.
|
|
|
|
**System Controller**
|
|
The System Controller access mode, or region, for managing subclouds is
|
|
System Controller.
|
|
|
|
You can use the System Controller to add subclouds, synchronize select
|
|
configuration data across all subclouds and monitor subcloud operations and
|
|
alarms. You can also access the individual subclouds through the single
|
|
central Horizon interface at the Central Cloud to perform subcloud-specific
|
|
operations such as configuring and managing the subclouds' host nodes and
|
|
containers. System software updates for the subclouds are also centrally
|
|
managed and applied from the System Controller.
|
|
|
|
DNS and other select configuration settings are centrally managed at the
|
|
System Controller and pushed to the subclouds in parallel to maintain
|
|
synchronization across the |prod-dc|.
|
|
|
|
**Subclouds**
|
|
The subclouds are |prod| instances used to host containerized applications.
|
|
Any type of |prod| deployment configuration, i.e. simplex, duplex or
|
|
standard with or without storage nodes, can be used for a subcloud.
|
|
|
|
Alarms raised at the subclouds are sent to the System Controller for
|
|
central reporting.
|
|
|
|
.. note::
|
|
|
|
Services in a Subcloud authenticate against their local Identity
|
|
Provider only (i.e. Keystone for StarlingX and Kubernetes Service
|
|
Accounts for Kubernetes). This allows the subcloud to not only be
|
|
autonomous in the face of disruptions with the Central Region, but also
|
|
allows the subcloud to improve service performance since authentication
|
|
is localized within the subcloud.
|
|
|
|
|
|
|
|
Each subcloud can be in a Managed or Unmanaged state.
|
|
|
|
**Managed**
|
|
When a subcloud is in the Managed state, it is updated (synchronized)
|
|
immediately with configuration changes made at the System Controller.
|
|
This is the normal operating state. Updates may be delayed slightly
|
|
depending on network conditions.
|
|
|
|
**Unmanaged**
|
|
When the subcloud is in an Unmanaged state, configuration changes are
|
|
queued at the System Controller. They are sent to the subcloud when the
|
|
subcloud is returned to a Managed state. The Unmanaged state is used to
|
|
disconnect the subcloud from synchronization operations for local
|
|
maintenance. Alarms generated by the subcloud are still sent to the
|
|
System Controller.
|
|
|
|
**Networks**
|
|
Subclouds are connected to the System Controller over L3 networks. Because
|
|
each subcloud is on a separate L3 subnet, the management and PXE boot L2
|
|
networks are local to the subclouds and not connected via L2 to the Central
|
|
Cloud; they are only connected via L3 routing.
|
|
|
|
The settings required to connect a subcloud to the System Controller are
|
|
specified when a subcloud is defined. For more information, see
|
|
:ref:`Installing a Subcloud Without Redfish Platform Management Service
|
|
<installing-a-subcloud-without-redfish-platform-management-service>`.
|
|
|
|
No additional platform configuration is required to establish network
|
|
communications. However, third-party routers are required to complete the
|
|
L3 connections. The routers must be configured independently according to
|
|
OEM instructions.
|
|
|
|
All messaging between System Controllers and Subclouds uses the **admin**
|
|
REST API service endpoints which, in this distributed cloud environment,
|
|
are all configured for secure HTTPS. Certificates for these HTTPS
|
|
connections are managed internally by |prod|.
|
|
|
|
.. xbooklink For more information, see :ref:`Certificate Management for Admin
|
|
REST API Endpoints <certificate-management-for-admin-rest-endpoints>`.
|
|
|