Deploy Satellite on-premises or in hyperscaler

The Satellite on-premises or in hyperscaler pattern includes two common solution patterns:

One or more IBM Cloud Satellite locations configured on-premises
One Satellite location is configured on-premises, and another Satellite location is configured in the cloud

Due to privacy, regulatory, or compliance reasons, customers might not send or store data in the public cloud. In such scenarios, the best option is to create one or more Satellite locations on-premises and hosts the data locally to satisfy the data residency requirement.

Architecture diagrams

Figure 1 illustrates the IBM Cloud Satellite architecture where one or more Satellite locations are deployed on-premises.

Satellite location on-premises architecture — Base IBM Cloud Satellite solution architecture with Satellite location on-premises

Satellite link connects on-premises Satellite locations to IBM Cloud. Customers might also choose to use Direct Link. Red Hat OpenShift and Red Hat OpenShift Data Foundation are two of the many other Satellite-enabled services in this image that are deployed in the Satellite location.

Design scope

The base IBM Cloud Satellite solution covers design considerations and architecture decisions for the following aspects and domains:

Compute: Bare Metal, Virtual Servers, Virtualization, Containers
Storage: Primary Storage, Backup Storage
Networking: Enterprise Connectivity, Network Segmentation
Data: Data Storage (highlighting the Data Residency requirement)
Security: Data Security, Identity and Access Management, Infrastructure and Endpoint
Resiliency: Backup and Restore, High Availability
Service Management: Monitoring, Logging, Auditing/Tracking

The Introduction to the architecture framework, provides a consistent approach to design cloud solutions by addressing requirements across a pre-defined set of aspects and domains, which are technology-agnostic architectural areas to consider for any enterprise solution. It can be used as a guide to make the necessary design and component choices. After you have identified the applicable requirements and domains that are in scope, you can evaluate and select the best fit for purpose components for your enterprise cloud solution.

In Figure 2, you can view the domains that are relevant in an IBM Cloud Satellite solution.

Base Satellite architecture framework — Base IBM Cloud Satellite Architecture Framework

Solution components and requirements for Satellite location on-premises

Review the following requirements and components for an on-premises Satellite location.

Requirements

The following table represents a baseline set of requirements, which are applicable to many clients and critical to a successful IBM Cloud Satellite on-premises deployment.

Requirements
Aspect	Requirement
Compute	Customer uses the VMs that are on-premises as the hosts in Satellite location.
	Customer is looking to use Red Hat CoreOS (RHCOS) in the Satellite location host machines
Storage	Provide storage that meets the customer application and database performance requirements.
Network	Provide secure, encrypted connectivity from Satellite location to IBM Cloud. Customer has Direct Link. Use DL to connect IBM Cloud to hosts in Satellite Location. Access customer's existing Red Hat Container Registry.
Data	Data residency requirements require that the customer’s data not leave the region.
Security	Encrypt all application data in transit and at rest to protect it from unauthorized disclosure. Customer would like to use their Hardware Security Module (HSM). Note: The HSM owner is responsible for its connectivity, monitoring, and integration with Key Protect. Encrypt all data by using customer-managed keys to meet regulatory compliance requirements for more security and customer control.
Resiliency	Multi-site capability to support a disaster recovery strategy and solution that uses IBM Cloud infrastructure DR capabilities that are combined with Satellite features. Provide backups for data retention.
Service management	Customer wants a fully managed service. Monitor Satellite location health metrics to detect issues that might impact availability. Monitor audit logs to track changes.
Other	DevOps pipeline to help with deployment of applications to the Satellite location

Satellite shared responsibility

IBM Cloud Satellite is a fully managed offering and there are certain responsibilities that are shared by IBM and the customer. The following table explains the breakdown. For more information about the table and the corresponding task details, see Satellite responsibilities.

Shared Responsibility Matrix
Resource	Incident and operations management	Change management	Identity and access management	Security and regulation compliance	Disaster Recovery
Data	Customer	Customer	Customer	Customer	Customer
Application	Customer	Customer	Customer	Customer	Customer
Satellite Location	Shared	Shared	Shared	Shared	Shared
Satellite Host	Shared	Shared	Shared	Shared	Shared
Satellite Config	Shared	Shared	Shared	Shared	Shared
Satellite Link	Shared	Shared	Shared	Shared	Customer
Satellite Storage	Shared	Shared	Customer	Shared	Shared
Satellite-enabled services	Shared	Shared	Shared	Shared	Shared
Operating System	Customer	Shared	Customer	Shared	Customer
Virtual and bare metal servers	Customer	Customer	Customer	Customer	Customer
Virtual storage	Customer	Customer	Customer	Customer	Customer
Virtual network	Customer	Customer	Customer	Customer	Customer
Hypervisor	Customer	Customer	Customer	Customer	Customer
Physical servers and memory	Customer	Customer	Customer	Customer	Customer
Physical storage	Customer	Customer	Customer	Customer	Customer
Physical network and devices	Customer	Customer	Customer	Customer	Customer
Facilities and data centers	Customer	Customer	Customer	Customer	Customer

Components

Review the following tables for each component.

Cloud components

Cloud components
Aspect	Component	How the component is used
Cloud	IBM Cloud Satellite	Distributed cloud paradigm
	Location infrastructure	On-premises: Client provided infrastructure
	Management plane MZR	Closest region (MZR) to Satellite location

Compute components

Compute components
Aspect	Component	How the component is used
Compute	Satellite location hosts	Virtual machine (VM) or Bare Metal Server
	Host OS	RHEL 8.x or RHCOS
	Control plane hosts	4 vCPU and 16 GB RAM
	Satellite services worker nodes hosts: Red Hat OpenShift (Customer Workload Cluster)	16 vCPU and 64 GB RAM (minimum of 3 spares) for Red Hat OpenShift Data Foundation persistent storage. Regular nodes that are tailored to workload but can be as low as 4x16
	Satellite services worker nodes hosts : Other Satellite-enabled services	Based on Satellite-enabled service. This reference solution does not include any other services.
	Containers	Managed Red Hat OpenShift on Satellite
	Red Hat OpenShift cluster connectivity	Private Service cluster URL Public Domain Name System (DNS) pointing to control plane node IPs by default Private Satellite link endpoint for Red Hat OpenShift cluster accessible within IBM Cloud private network
	Workloads Access	Red Hat OpenShift Routes Node Ports There is the ability to integrate external load balancers, just point load balancer to the Red Hat OpenShift router node port.
	Workload isolation	Single cluster for all workloads
	Container Images Registry	IBM Cloud Container Registry on IBM Cloud

Storage components

Storage components
Aspect	Component	How the component is used
Storage: Primary	Satellite Hosts: Control plane and worker nodes host node local storage
	Satellite Services storage: Red Hat OpenShift (Customer Workloads)	Software Defined Storage (SDS)
	Software Defined Storage	Red Hat OpenShift Data Foundation
Storage: Backup	Satellite Control Plane Data	IBM Cloud Object Storage (IBM-managed backups)
	Red Hat OpenShift workload data	Customer might choose to use Cloud Object Storage on IBM Cloud

Networking components

Networking components
Aspect	Component	How the component is used
Networking	Enterprise Connectivity
	Satellite location and IBM Cloud Direct Link 2.0 connect or internet
	Satellite location private Network	VPN or Use Satellite link for Transmission Control Protocol (TCP) and HTTPS connections (no User Datagram Protocol)
	Cloud Connectivity
	Satellite location connectivity	Satellite link over public network
	Satellite Services Connectivity	Satellite link location endpoint for Red Hat OpenShift cluster
	IBM Cloud services connectivity	Satellite link cloud endpoints
	Load balancers
	Red Hat OpenShift application load balancer	3rd party load balancer –Ingress Controller
	Segmentation
	Red Hat OpenShift cluster	Container network policies
	DNS	Client DNS at Satellite location

Security components

Security components
Aspect	Component	How the component is used
Data
Data encryption at rest	Satellite control plane backup storage	Cloud Object Storage encrypted with provider keys
	Satellite worker nodes data	Worker nodes storage encryption: Customer
	Red Hat OpenShift cluster persistent storage	Cluster volume encryption with Kubernetes Secret
Data encyption in transit	Satellite Link	Encryption that uses TLS
	Red Hat OpenShift cluster workloads	App-level encryption that uses TLS
	Certificate Lifecycle Management	Customer on-premises certificate manager
Identity and Access Management (IAM)
IAM: Access & Role Management	Satellite Location	IBM Cloud account set up Account and Resource Organization IBM Cloud IAM roles and access groups
	Satellite location hosts	IBM Cloud IAM
	Satellite services: Red Hat OpenShift (Customer Workloads Cluster)	IBM Cloud IAM Roles Kubernetes role-based access control (RBAC) Roles
IAM: Application	Runtime security (WAF and DDoS)	Bring your own Edge Security
IAM: Infrastructure & endpoint	Core Network Protection	Subnets and firewall rules
IAM: Threat detection and response	Threat detection	Customer SIEM tool, for example, Splunk

Resiliency components

Resiliency components
Aspect	Component	How the component is used
High availability	Satellite Host Nodes (control and worker nodes)	Multi-node deployment
	Red Hat OpenShift workloads	Multi-node Red Hat OpenShift cluster
Backup	Red Hat OpenShift clusters	Portworx PX Backup for Kubernetes

Service management components

Service management components
Aspect	Component	How the component is used
Monitoring	Satellite location and hosts	IBM Satellite Monitoring Tool IBM Cloud Monitoring
	Red Hat OpenShift clusters	IBM Cloud Monitoring
Logging	Satellite location and hosts	IBM Satellite IBM Cloud Logs tool IBM Cloud Logs
	Red Hat OpenShift clusters	IBM Cloud Logs
Auditing	Satellite location events	IBM Cloud Logs
	Red Hat OpenShift clusters	IBM Cloud Logs

Solution components for Satellite location in a hyperscaler

In addition to the components listed in the Satellite location on-premises pattern, there are hyperscaler-related components:

Hyperscaler infrastructure
Hyperscaler specific Container Registry
Direct network connection between Satellite location and IBM Cloud
Hyperscaler specific activity tracker

The table has links that provide additional information about configuring Satellite location in a hyperscaler or VMware.

Satellite location in a Hyperscaler or VMware
Hyperscaler	Link
AWS	Automating your AWS location setup with a Schematics template
Azure	Automating your Azure location setup with a Schematics template
GCP	Automating your GCP location setup with a Schematics template
VMware	Automating your VMware location setup with a Schematics template

The architecture framework is used to guide and determine the applicable aspects and domains for which architecture decisions need to be made. Review the design considerations and architecture decisions for the aspects and domains that are in play in this solution pattern.