.. 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>`.