Remote physical locations

Services that support remote physical locations

Supported project (namespace) configurations for remote physical locations

To use a cluster as a remote physical location, you must create the following projects:

Projects for shared cluster components

The shared cluster components are installed exactly once on the cluster and are shared by all remote physical locations on the cluster. Each component is installed in its own project, and no other software should be installed in the project.

The following table provides the default project name and the environment variable that is used to identify the project in commands throughout the documentation. You are not required to use the default project names. The default names are used only if you don't specify a project name when you install the components.

Component	Default project name	Environment variable
IBM Certificate manager	ibm-cert-manager	${REMOTE_PROJECT_CERT_MANAGER}
License Service	ibm-licensing	${REMOTE_PROJECT_LICENSE_SERVICE}
Scheduling service	No default.	${REMOTE_PROJECT_SCHEDULING_SERVICE}

For more information about these components, see Shared components.

Projects for the remote physical location

A remote physical location is comprised of two Red Hat OpenShift Container Platform projects:

Management project

The project on the remote cluster where you want to install the required agents, operators, and custom resources.

After you create the remote physical location, any service instances that are created on the physical location are created in the management project.

In the remote physical location setup commands, the ${REMOTE_PROJECT_MANAGEMENT} environment variable refers to the management project.

Each remote physical location has its own management project.

Workload project

The project on the remote cluster where you want to run workloads.

In the remote physical location setup commands, the ${REMOTE_PROJECT_WORKLOAD} environment variable refers to the workload project.

Each remote physical location has its own workload project.

Architecture of remote physical locations

You can have multiple remote physical locations on a remote cluster.

Each remote physical location can communicate with exactly one instance of IBM Software Hub. However, an instance of IBM Software Hub can connect to multiple remote physical locations, as shown in the following diagram:

If you have multiple remote physical locations on a remote cluster, each remote physical location can communicate with different instances of IBM Software Hub.

Organizing remote physical locations with data planes

After you register a physical location with an instance of IBM Software Hub, you can add the remote physical location to a data plane.

A data plane is a logical grouping of one or more physical locations. Users can create services instances on a data plane, and the instance is created on one of the physical locations associated with the data plane.

The following diagram shows examples of how you can use data planes to organize remote physical locations into logical groups.

In this example, the primary instance of IBM Software Hub (the hub) has three data planes.

Data plane 1

This data plane is for workloads that require GPUs.

The data plane contains four remote physical locations. Each remote physical location has between 2 and 4 GPUs. Each remote physical location is located in a different country.

Data plane 2

This data plane is for workloads that must be processed in the European Union.

The data plane contains two remote physical locations. Both physical locations are in countries that are part of the European Union.

Data plane 3

This data plane is for workloads that exceed the available vCPU and memory on the hub.

The data plane contains two remote physical locations. One of the remote physical locations has lower priority, so the scheduling service will schedule workloads on that remote physical location only if it cannot schedule the workload on the remote physical location with higher priority.