Regions

Review the IBM Cloud® regions that you can choose from to manage your Satellite location. 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.

Red Hat CoreOS is available in all supported Satellite locations and for Red Hat OpenShift version 4.9 and later. Red Hat CoreOS hosts don't support all services. For more information, see Supported Satellite-enabled IBM Cloud services.

Supported IBM Cloud regions.
Geography	Country	Multizone Metro	Location	Region	Zone
Asia Pacific	Australia	Sydney	`syd`	`au-syd`	`au-syd-1` `au-syd-2` `au-syd-3`
Asia Pacific	Japan	Tokyo	`tok`	`jp-tok`	`jp-tok-1` `jp-tok-2` `jp-tok-3`
Asia Pacific	Japan	Osaka	`osa`	`jp-osa`	`jp-osa-1` `jp-osa-2` `jp-osa-3`
North America	Canada	Toronto	`tor`	`ca-tor`	`tor-1` `tor-4` `tor-5`
North America	United States	Dallas	`dal`	`us-south`	`us-south-1` `us-south-2` `us-south-3`
North America	United States	Washington DC	`wdc`	`us-east`	`us-east-1` `us-east-2` `us-east-3`
Europe	Germany	Frankfurt `†`	`fra`	`eu-de`	`eu-de-1` `eu-de-2` `eu-de-3`
Europe	Spain	Madrid	`mad`	`eu-es`	`eu-es-1` `eu-es-2` `eu-es-3`
Europe	United Kingdom	London	`lon`	`eu-gb`	`eu-gb-1` `eu-gb-2` `eu-gb-3`
South America	Brazil	Sao Paulo	`sao`	`br-sao`	`br-sao-1` `br-sao-2` `br-sao-3`

† EU Cloud Certified Locations are managed from the Frankfurt region. To order these, ensure you choose fra as the value for the --managed-from option.

IBM Cloud regions for Satellite FAQs

Review some frequently asked questions about why and how you choose an IBM Cloud region to manage your Satellite location.

Why is my location managed by an IBM Cloud region?

Running IBM Cloud services on your own infrastructure requires a secure connection to IBM Cloud. The connection is controlled, monitored, and managed by IBM to ensure that security and compliance standards for each of the services are met and to roll out updates to these services.

Every Satellite location is set up with a control plane that establishes the secure connection back to IBM Cloud. The control plane consists of a highly available management plane that runs in the IBM Cloud region that you choose. IBM controls and manages this management plane. The control plane nodes run on your own compute hosts that you attached to your Satellite location.

IBM uses this connection to monitor your Satellite location, automatically detect and resolve capacity issues, monitor malicious activity, and roll out updates to the IBM Cloud services that you run on your infrastructure.

For more information, see the Satellite architecture.

What IBM Cloud multizone metro do I choose for my Satellite location?

You can choose any of the supported IBM Cloud region to manage your Satellite location. The metro determines where the master of your Satellite control plane runs. For more information, see the Satellite architecture. To reduce latency between the IBM Cloud region and your Satellite location, choose the region that is closest to where your physical compute infrastructure is.

Can my hosts reside anywhere?

Because you bring your own compute host infrastructure to your Satellite location, you can choose to host this infrastructure anywhere you need it. Hosts can be in your own on-premises data center, public cloud providers, or edge computing devices if they meet the minimum host requirements for Satellite.

How can I deploy in an EU Cloud Certified Location?

EU Cloud Certified Locations are managed from the Frankfurt region. To order these types of locations, ensure you choose fra as the value for the --managed-from option.

Example command:

ibmcloud sat location create --name LOCATION_NAME --coreos-enabled --managed-from fra

ibmcloud sat location create --name LOCATION_NAME --managed-from fra

What about latency requirements?

As you select your infrastructure provider, consider the following latency requirements. Environments that do not meet the latency requirements experience degraded performance.

Between IBM Cloud and the location: 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.
Between hosts in your 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.