For many organizations, public cloud is the main place applications are deployed to today and for good reason. Utilizing public cloud managed services properly brings flexibility and ease of use that allows companies to focus on what’s important to them. But a public cloud isn’t the hammer for every nail. Established organizations may have applications that need to run in an on-premises data center. The reasons for this are plentiful but common justifications are sensitivity of the workload being in a data center outside of the organization’s control, latency requirements, and general complexities of moving highly integrated workloads.
In response to this, Cloud Services Providers (CSP) have developed ways of deploying their cloud services outside of their cloud datacenters. AWS Outpost, Azure Arc, Google Anthos. In 2021 IBM launched Cloud Satellite as their answer. These services all have their differences, but generally have the same goal of bringing cloud-managed services to where they are needed. From the CSP’s perspective, it keeps the customer using their services even if they cannot bring the workload into the CSP data center. From the customer perspective, they get some of the benefits of using cloud services and can have consistency in how those services are used either in a CSP data center or their own on-premise data center.
Let’s dive deeper into IBM Cloud Satellite concepts and its architecture. The main concept is the “Satellite location”, which represents the location where the IBM Cloud services will be extended to. It could be the on-premise data center, another CSP data center, or even your home. Essentially anywhere that VM or Bare Metal servers can be placed could be a Satellite location. The Satellite location consists of x86 RHEL hosts assigned to either be part of the control plane for the Satellite location or used to run the IBM Cloud services in the location.
A Satellite location would be managed from an IBM Cloud region. These could be any of the IBM Cloud MZR regions, but the important piece is that there is < 200 ms of latency between the Cloud region and the Satellite location control plane. This connectivity between the location and the cloud region is called a Satellite Link. From a network perspective, the Satellite Link communication is initiated from the Satellite location to the cloud region so there is no need to open any incoming ports to the Satellite location. All data flowing over the Satellite Link is encrypted to TLS 1.3 standards.
The process of creating a Satellite location is as simple as going into the IBM Cloud portal and defining the location with a name and which cloud region it is managed from. From there, a bash script is generated which can be run on the hosts in the Satellite location. The script attaches the hosts to the Satellite location and will appear in the cloud portal as unassigned.
The Satellite location control plane requires at least 3 hosts with a minimum of 4 cores and 16 GB of RAM. Other services will have their own host requirements. Hosts that run the cloud service do not need to necessarily be in the same physical location as the control plane but should have < 100 ms of latency to the control plane.
Assign 3 hosts in the cloud portal to be part of the control plane. Satellite has the concept of zones, independent data centers that can be used to spread workloads across. If the infrastructure provider has zones, each host can be assigned to a respective zone in the infrastructure provider. Commonly if deploying in an on-premise data center there will not be multiple zones. In that case just specify that each control plane host is in a different zone, even if they are in the same DC. Once the 3 control plane hosts are assigned in different zones the Satellite location status should show as healthy, meaning it is ready to start deploying cloud services. Before that happens though, additional hosts will need to be attached to the Satellite location. These will be left as “unassigned” until they are used by a service in the Satellite.
For a service to be deployed in a Satellite location, it needs to be “Satellite Enabled”, meaning it can support running on Satellite. Not every service supports it and as of today, this list is still growing. The first service that launched, and where a lot of the interest that I see is the Redhat OpenShift service, also known as ROKS. This would deploy an OpenShift cluster in the Satellite location that is managed by the IBM Cloud SRE team. For customers who may not have the skills to set up and maintain an OpenShift cluster, ROKS on Satellite makes it easy to get started and have a consistently managed OpenShift cluster in any environment.
Deploying a ROKS cluster into a Satellite location isn’t much different from deploying ROKS in IBM Cloud. Satellite shows up as an infrastructure deployment option right next to Classic and VPC. Once you specify the worker node sizes, the appropriate unassigned Satellite hosts will be assigned to the ROKS service for the cluster. When it’s provisioned the cluster shows up in the same list of clusters as those that are running in IBM Cloud.
This is the value of Satellite, extending the cloud capabilities wherever they are needed while maintaining consistent service management, logging & monitoring, and IAM access controls to not increase operational complexity.
See the video below for how to set up ROKS in a Satellite location.
The Cloud Guy 