IBM Cloud Docs
Learning about Satellite architecture, workload isolation, and dependencies

Learning about Satellite architecture, workload isolation, and dependencies

Learn about the IBM Cloud Satellite service architecture, its components, how your workloads are isolated from other tenants, and what other IBM Cloud and third-party services Satellite depends on.

Satellite architecture

The following image shows the main components in IBM Cloud Satellite and how they interact with each other.

Satellite for IBM Cloud service architecture
Figure 1. Satellite service architecture

While communication from your location to some Satellite services is routed fully through the Link tunnel server, other services might require outbound connectivity from your hosts. For more information, see the host network requirements and host outbound connectivity requirements.

Master and worker node components

Review a description of the main components of the Satellite location control plane, including the IBM-managed master from the IBM Cloud region and the worker nodes that you set up in your location.

Overview of Satellite management plane components.
Overview of the Satellite management plane components
Master components Description
Satellite Link tunnel The Satellite Link tunnel server creates a secure TLS connection to the Satellite Link tunnel client that runs on the control plane nodes in your Satellite location. Three tunnels are created between the tunnel server and the connector to support redundancy across the three availability zones of your location. All communication that leaves and enters your location is proxied by the Link tunnel server, and the connection metadata captured and monitored by IBM to detect malicious activity. To control the network connections between the workloads that run in your location and the IBM Cloud multizone metro that manages your location, you can set up Satellite Link endpoints. For more information, see Connecting your Satellite location and IBM Cloud with endpoints.
IBM Cloud Monitoring The IBM Cloud Monitoring component monitors the compute capacity in your Satellite location and the components that run in your Satellite control plane to detect issues and automatically resolve them if possible. These actions can include assigning additional hosts to the control plane or restart components that keep on failing. For issues that cannot be resolved, IBM Site Reliability Engineers are automatically informed for further investigation.
Satellite Config With Satellite Config, you can consistently deploy Kubernetes resource configurations across Red Hat® OpenShift® on IBM Cloud® clusters that run on the infrastructure of your Satellite location or in IBM Cloud. You can monitor the health of these resources by using the location dashboard. For more information, see Deploying Kubernetes resources across Satellite clusters.
IBM Cloud Secrets Manager With IBM Cloud Secrets Manager, you can create secrets dynamically and lease them to applications while you control access from a single location. Built on open source HashiCorp Vault, IBM Cloud Secrets Manager helps you get the data isolation of a dedicated environment with the benefits of a public cloud. For more information, see Getting started with IBM Cloud Secrets Manager.
Overview of Satellite control plane node components.
Overview of the Satellite control plane node components
Worker node components Description
Satellite Link tunnel client The Satellite Link tunnel client component is the main gateway for any communication between your Satellite location and IBM Cloud. All workloads that run in your location and that must connect to an app, service or server that runs in IBM Cloud must send their requests to the Satellite Link tunnel client. The Satellite Link tunnel client securely forwards your request to the Satellite Link tunnel server where the request is proxied and forwarded to the destination target. To enable DNS resolution between your Satellite location and IBM Cloud, you must create a Satellite Link endpoint. For more information, see Connecting your Satellite location and IBM Cloud with endpoints. By default, all network traffic that enters and leaves your location is automatically captured to allow network monitoring and auditing.
IBM Cloud Monitoring The IBM Cloud Monitoring component monitors the compute capacity in your Satellite location and the components that run in your Satellite control plane to detect issues and automatically resolve them if possible. These actions can include assigning additional hosts to the control plane or restart components that keep on failing. For issues that cannot be resolved, IBM Site Reliability Engineers are automatically informed for further investigation.
Cluster master When you create a Satellite cluster in your location, the master of this cluster is deployed onto your Satellite control plane nodes to allow communication to IBM Cloud and monitoring through IBM. For more information, see Creating Satellite clusters.

Latency requirements

Review the network latency requirements for the hosts that you add to your IBM Cloud Satellite location.

IBM-managed master to customer-provided worker nodes for the Satellite location control plane

The hosts that you want to attach to the Satellite location control plane must have a low latency connection of less than or equal to 200 milliseconds (<= 200ms) round trip time (RTT) to the IBM Cloud region that your Satellite location is managed from. As latency increases, you might see impacts to performance, including Satellite Link throughput, Satellite-enabled IBM Cloud service provisioning time, host failure recovery time, and in extreme cases, the availability of resources that run in the Satellite location control plane, such as Red Hat OpenShift cluster masters. For more information, see Testing the latency between IBM Cloud and the Satellite location control plane hosts.

Customer-provided worker nodes in the Satellite location control plane to worker nodes that run Satellite-enabled IBM Cloud services like Red Hat OpenShift clusters in the same location

Your host infrastructure setup must have a low latency connection of less than or equal to 100 milliseconds (<= 100ms) round trip time (RTT) between the hosts that are used for the Satellite location control plane worker nodes and the hosts that are used for other resources in the location, like clusters or Satellite-enabled IBM Cloud service. For example, in cloud providers such as AWS, this setup typically means that all the hosts in the Satellite location are from the same cloud region, like us-east-1. As latency increases, you might see impacts to performance, including provisioning and recovery times, reduced worker nodes in the cluster, Satellite-enabled IBM Cloud service degradation, and in extreme cases, failures in your cluster applications.

Customer-provided worker nodes that are assigned to the same Satellite resource, like the Satellite location control plane or a cluster

Your host infrastructure setup must have a low latency connection of less than or equal to 10 milliseconds (<= 10ms) round trip time (RTT) among all the hosts that are assigned to the same Satellite resource, such as the Satellite location control plane, a Satellite-enabled IBM Cloud service, or cluster. As latency increases, you might see impacts to performance, including Satellite-enabled IBM Cloud services like databases or cluster application failures.

Workload isolation in IBM Cloud Satellite

Learn how your workloads are isolated from other IBM customers in Satellite.

Workload isolation in the IBM Cloud multizone metro that manages your location

When you create a Satellite location, a Satellite management plane is automatically created in the IBM Cloud multizone metro that manages your location. The master and all the components that run inside the master are dedicated to your Satellite location only and are managed by IBM in an IBM-owned IBM Cloud account.

One of the components that is set up in the Satellite management plane is an etcd database where IBM stores personal and sensitive data of the customer account that created the location. The etcd database is not shared across locations or with other IBM customers. For more information, see What information is stored with IBM when using Satellite? and How is my information stored and encrypted?.

Workload isolation in your Satellite location

Because you manage the host infrastructure that you bring to your Satellite location, you are responsible to isolate app workloads that run on your infrastructure. If you host and run IBM Cloud services in your location, such as Red Hat OpenShift on IBM Cloud, you can leverage the tools and features that this service provides to isolate your workloads. For more information about available options, see the service documentation.