Distributed Cloud Architecture

A Distributed Cloud 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 Distributed Cloud 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 Distributed Cloud.

Subclouds

The subclouds are StarlingX instances used to host containerized applications. Any type of StarlingX 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 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 StarlingX.