Planning your environment for Satellite locations

Plan how to set up your infrastructure environment to use with IBM Cloud Satellite®. Your infrastructure environment can be an on-premises data center, in a public cloud provider, or on compatible edge devices anywhere.

Planning your infrastructure

Before you create your location, choose your infrastructure provider, infrastructure zones, and your infrastructure hosts.

Your Satellite location starts with your infrastructure, such as a public cloud provider or on-prem. Your infrastructure provides the basis for the hosts and zones that you use to build out your Satellite location. For more information about the different responsibilities for your infrastructure and Satellite resources, see Your responsibilities.

Concept overview of planning your infrastructure — Figure 1. Your Satellite location is built atop the zones and hosts in your infrastructure provider.

Plan your infrastructure provider

Choose the infrastructure provider that you want to use to create a Satellite location.

On-premises: You can use a data center with existing infrastructure. You might not even have a data center, but rather an edge location that meets the minimum hardware requirements, such as three racks at one of your company's local sites.
Supported bare metal servers: You can use a supported bare metal server as a host attached to your Satellite location, including IBM Cloud® Bare Metal Servers for Classic. For more information, see Bare Metal Server requirements.
Non-IBM cloud provider: You can use a cloud provider of your choice, such as Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, or Alibaba Cloud.
IBM Cloud: You can use IBM Cloud for testing purposes. While you can use other IBM Cloud virtual servers, such as Virtual Servers for VPC for test environments, the only supported IBM Cloud infrastructure to use in Satellite for production environments is IBM Cloud® Bare Metal Servers for Classic that is running Red Hat CoreOS.

Plan for a multizone location

In your infrastructure provider, identify a multizone location that meets the latency requirements.

Multizone: Your location must have at least three zones that are physically separate so that you can spread out hosts evenly across the zones to increase high availability. For example, your cloud provider might have three different zones within the same region, or you might use three racks with three separate networking and power supply systems in an on-prem environment.
Latency 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.
Latency 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.

Plan your host systems

In each of the three zones in your infrastructure provider, plan to create compatible hosts to add to Satellite. The host instances in your infrastructure provider become the compute hosts to create your location control plane or to run the services in your Satellite location, similar to the worker nodes in a Red Hat OpenShift cluster.

Each host must meet the minimum host requirements for Satellite.
Your hosts must be running on official Red Hat certified hardware.

To calculate how many hosts you need, see Sizing your Satellite location.

To check your host set up, you can use the satellite-host-check script. For more information, see Checking your host set up.

Planning your operating system

Choose your operating system for your hosts. You can choose Red Hat Enterprise Linux or Red Hat CoreOS. If you want to use Red Hat CoreOS for your managed services, you must create and enable a location to use RHCOS hosts. See Creating a Satellite location.

The type of location that you create dictates the type of operating systems that can run on your hosts. If your location is RHCOS enabled, then you can attach hosts that are running either RHEL and RHCOS. If your location isn't RHCOS enabled, then you can attach only hosts that are running RHEL. You can check whether your location is RHCOS enabled.

Red Hat Enterprise Linux 8 (RHEL 8): RHEL 8 is default operating system that is supported for Satellite hosts running Red Hat OpenShift version 4.9 or later and on infrastructure hosts.
Red Hat Enterprise Linux 7 (RHEL 7): RHEL 7 is the operating system that is supported for Satellite hosts running Red Hat OpenShift version 4.9 or earlier. Note that support for RHEL 7 hosts in your control plane ends on March 2nd, 2023. Follow the steps to migrate your hosts to RHEL 8.
Red Hat CoreOS (RHCOS): RHCOS is a minimal operating system for running containerized workloads securely and at scale. It is based on RHEL and includes automated, remote upgrade features. For more information about the key benefits of RHCOS, see Red Hat Enterprise Linux CoreOS (RHCOS). RHCOS is supported for Satellite hosts on Red Hat OpenShift version 4.9 or later. Red Hat CoreOS hosts don't support all services. For more information, see Supported Satellite-enabled IBM Cloud services. To attach RHCOS hosts, your location must be enabled for RHCOS.

Deciding whether to enable Red Hat CoreOS support for your location

When you create a location, you can select whether to enable Red Hat CoreOS support. Enabling Red Hat CoreOS support comes with both pros and cons. A Red Hat CoreOS enabled location unlocks more features, but it has a higher infrastructure requirement. On the other hand, a non Red Hat CoreOS enabled location supports a smaller feature set but can run at a smaller footprint, allowing more clusters per same capacity. For more information, see Sizing your Satellite location. The following table shows the features that are available only in Red Hat CoreOS-enabled locations. The table also shows the supported host types that can be used when setting up these features in your Red Hat CoreOS-enabled location.

Supported host types for CoreOS location features
Feature	Supported host types
HTTP proxy for outbound traffic	RHEL or RHCOS hosts
Bring your own key (BYOK) or keep your own key (KYOK)	RHEL or RHCOS hosts
Single node cluster topology	RHEL or RHCOS hosts
Direct link	RHCOS hosts only
OpenShift virtualization	RHCOS hosts only

To verify if you location is enabled for Red Hat CoreOS, see Is my location enabled for Red Hat CoreOS.

The bring your own key (BYOK) or keep your own key (KYOK) feature is supported in RHCOS enabled locations on Red Hat OpenShift on IBM Cloud 4.13 and later. It is supported on both RHEL and RHCOS hosts. You can encrypt only cluster secrets. This feature is not available during cluster or worker pool creation. You must run the ibmcloud oc kms enable command to enable it after the cluster or worker pool has been created. Note that this feature cannot be disabled after it is enabled.

Infrastructure credentials

For IBM Cloud Satellite to perform actions on your behalf in a cloud provider, you must provide credentials to the cloud provider.

AWS credentials

Retrieve the Amazon Web Services (AWS) credentials that Satellite can use to create Satellite resources in your AWS cloud on your behalf.

Verify that you have the required permissions in your AWS account to create a Satellite location from a template.
Create a separate IAM user that is scoped to EC2 access.
Retrieve the access key ID and secret access key credentials for the IAM user.
Optional: To provide the credentials during the creation of a Satellite location, format the credentials in a JSON file. The client_id is the ID of the access key and the client_secret is the secret access key that you created for the IAM user in AWS.
```
{
    "client_id":"string",
    "client_secret": "string"
}
```

Azure credentials

Retrieve the Microsoft Azure credentials that Satellite can use to create Satellite resources in your Azure cloud on your behalf.

Verify that you have the required permissions in your Azure account to create a Satellite location from a template.
Sign in to your Azure account from the command line.
```
az login
```
List the available subscriptions in your account.
```
az account list
```
Set the subscription to create your Azure resources in.
```
az account set --subscription="<subscription_ID>"
```
Create a service principal identity with the Contributor role, scoped to your subscription. These credentials are used by IBM Cloud Satellite to provision resources in your Azure account. For more information, see the Azure documentation.
```
az ad sp create-for-rbac --role="Contributor" --scopes="/subscriptions/<subscription_ID>" -n"<service_principal_name>"
```

In the output, note the values of the appID, password, and tenant fields.

{
"appId": "<azure-client-id>",
"displayName": "<service_principal_name>",
"name": "http://<service_principal_name>",
"password": "<azure-secret-key>",
"tenant": "<tenant-id>"
}

Optional: To provide the credentials during the creation of a Satellite location, format the credentials in a JSON file.
```
{
    "app_id":"string",
    "tenant_id":"string",
    "password": "string"
}
```

GCP credentials

Retrieve the Google Cloud Platform (GCP) credentials that Satellite can use to create Satellite resources in your GCP cloud on your behalf.

Create a service account and service account key with at least the required GCP permissions. As part of creating the service account, a JSON key file is downloaded to your local machine.

Open the JSON key file on your local machine, and verify that the format matches the following example. You can provide this JSON key file as your GCP credentials for actions such as creating a Satellite location.

{
    "type":"string",
    "project_id":"string",
    "private_key_id": "string",
    "private_key": "string",
    "client_email": "string",
    "client_id": "string",
    "auth_uri": "string",
    "token_uri": "string",
    "auth_provider_x509_cert_url": "string",
    "client_x509_cert_url": "string"
}

VMWare credentials

Retrieve the VMWare credentials that Satellite can use to create Satellite resources in your VMWare cloud on your behalf.

Verify that you have the required permissions in your VMWare account to create a Satellite location from a template.
Identify or create a user with Administrator role.
Find your network information.
Provide this information on the VMware Cloud Director template.