Satellite reference architecture for IBM Cloud for Financial Services
With IBM Cloud Satellite, you can create a hybrid environment that brings the scalability and on-demand flexibility of public cloud services to the applications and data that run in your secure private cloud. The Satellite reference architecture for the IBM Cloud for Financial Services is designed to provide a framework for building Satellite-based solutions by using a shared responsibility model to fulfill the best practices and requirements of the IBM Cloud Framework for Financial Services. This document describes the architecture and provides guidance for deploying, configuring, and managing it.
Satellite achieves this distributed cloud architecture by providing an API-based suite of tools that you can use to represent your on-premises data center, a public cloud provider, or an edge network as a Satellite location. You fill the Satellite location with your own host machines that meet the minimum host requirements. Then, these hosts provide the compute power to run IBM Cloud services, such as workloads in managed Red Hat OpenShift clusters.
Solution design
When combined with other IBM Cloud services that run in the cloud and other applications in your on-premises environment, the hybrid architecture of Satellite can be used to build robust solutions that are appropriate for financial and other regulated workloads. This hybrid architecture is shown in the following diagram.
The following table provides an index to the components in the diagram.
| IBM Cloud | Satellite location on-premises | Supporting components on-premises |
|---|---|---|
| 1. Satellite link tunnel server | 5. Storage | 11. Edge plane |
| 2. Monitoring | 6. Satellite hosts | 12. Management plane |
| 3. Satellite Config | 7. Link connector | 13. Other application services |
| 4. IBM Cloud services | 8. Monitoring | |
| 9. Cluster 1 master 9. Cluster 2 master |
||
| 10. Workload cluster 1 10. Workload cluster 2 |
Satellite also supports deployments to other public cloud providers. However, we do not explore that feature in this reference architecture.
Financial Services Validated services
The reference architecture depends upon services that are IBM Cloud for Financial Services Validated. These services are designated to have evidenced compliance to the controls of the IBM Cloud Framework for Financial Services. Financial Services Validated services are designed to help address the requirements of financial institutions for regulatory compliance, security, and resiliency.
When properly configured and managed, services that are Financial Services Validated work together so you can deliver a solution that conforms to the best practices of the IBM Cloud Framework for Financial Services. The following table shows the required services that are included in the Satellite reference architecture and the complementary optional services that are available.
Generally speaking, you should strive to use only services which are Financial Services Validated in your solutions. However, depending on your circumstance there may be exceptions. See the best practice Use only services that are IBM Cloud for Financial Services Validated for more details and potential exceptions.
| Category | Required services | Optional services |
|---|---|---|
| Satellite | ||
| Containers | ||
| Storage | ||
| Security | ||
| Logging and monitoring | ||
| Integration | ||
| Developer tools |
The remainder of the topic goes into more detail about how these services fit into the reference architecture.
Core
IBM Cloud Satellite
Most of the services that are mentioned run entirely in IBM Cloud but two exceptions:
- Satellite, which as described earlier, has some components that run in IBM Cloud and some components that run in your Satellite location.
- Red Hat OpenShift on IBM Cloud, which refers to the Red Hat OpenShift on IBM Cloud-enabled type of the service, runs in your Satellite location.
These exceptions have implications for what it means to be Financial Services Validated and that is represented in the following diagram and details.
- Satellite components that run in IBM Cloud are validated to the same IBM Cloud Framework for Financial Services controls as any other Financial Services Validated product.
- Satellite components and IBM Cloud services that run in your on-premises environment that do not have a dependency on your configuration or underlying internal network and infrastructure components, are also validated to the applicable controls that were validated for these components in IBM Cloud.
- On-premises infrastructure and your on-premises workloads are your responsibility and are not validated by IBM. You are responsible for managing infrastructure and physical controls and controls that are related to deployment, configuration, and management of your workloads.
Several Satellite-enabled services can run in your Satellite location. However, only Red Hat OpenShift on IBM Cloud is Financial Services Validated. So, the others are not yet part of this reference architecture.
Containers
Red Hat OpenShift on IBM Cloud
You use Red Hat OpenShift on IBM Cloud to run your application workloads in your Satellite location. Red Hat OpenShift on IBM Cloud is a managed offering to create your own Red Hat OpenShift on IBM Cloud cluster of compute hosts to deploy and manage containerized apps on IBM Cloud. Red Hat OpenShift on IBM Cloud provides intelligent scheduling, self-healing, horizontal scaling, service discovery and load balancing, automated rollouts and rollbacks, and secret and configuration management for your apps. Combined with an intuitive user experience, built-in security and isolation, and advanced tools to secure, manage, and monitor your cluster workloads, you can rapidly deliver highly available and secure containerized apps in the public cloud.
IBM Cloud Container Registry
Container Registry provides a multi-tenant, highly available, scalable, and encrypted private image registry that is hosted and managed by IBM®. When you push images to Container Registry, you benefit from the built-in Vulnerability Advisor features that scan for potential security issues and vulnerabilities.
Storage
IBM Cloud Object Storage
Object Storage stores encrypted and dispersed data across multiple geographic locations. Object Storage is available with three types of resiliency: Cross Region, Regional, and Single Data Center. Cross Region provides higher durability and availability than using a single region at the cost of slightly higher latency. Regional service reverses those tradeoffs, and distributes objects across multiple availability zones within a single region. If a given region or availability zone is unavailable, the object store continues to function without impediment. Single Data Center distributes objects across multiple machines within the same physical location.
Users of Object Storage refer to their binary data, such as files, images, media, archives, or even entire databases as objects. Objects are stored in a bucket, the container for their unstructured data. Buckets contain both inherent and user-defined metadata. Finally, objects are defined by a globally unique combination of the bucket name and the object key, or name.
Security
IBM Cloud Hyper Protect Crypto Services
Hyper Protect Crypto Services is a dedicated key management service and hardware security module (HSM) based on IBM Cloud. This service allows you to take the ownership of the cloud HSM to fully manage your encryption keys and to perform cryptographic operations using Keep Your Own Key (KYOK). Hyper Protect Crypto Services is also the only service in the cloud industry that is built on FIPS 140-2 Level 4-certified hardware.
IBM Cloud App ID (optional)
App ID helps developers to easily add authentication to their web and mobile apps with few lines of code, and secure their cloud-native applications and services on IBM Cloud.
Logging and monitoring
IBM Cloud Activity Tracker Event Routing
Activity Tracker Event Routing is used to collect auditable platform events that are generated by services in your IBM Cloud account. These events allow you to monitor the activity of your IBM Cloud account so that you can investigate abnormal activity and critical actions.
Activity Tracker Event Routing provides for either event routing or hosted event search. However, only the event routing features of Activity Tracker Event Routing are Financial Services Validated. In regions where it's available, you must configure Activity Tracker Event Routing to send events to Object Storage, where they must be encrypted with KYOK.
Activity Tracker Event Routing is only available in some regions (see Locations for Activity Tracker Event Routing event routing for more details). For regions where it's not available, you must use Activity Tracker Event Routing hosted event search until Activity Tracker Event Routing is available. When event routing becomes available in those regions, you must switch to use event routing. For more information and possible exceptions, see Use only services that are IBM Cloud for Financial Services Validated.
IBM Cloud Security and Compliance Center
With Security and Compliance Center you can embed security checks into your every day workflows to help monitor for security and compliance. By monitoring for risks, you can identify security vulnerabilities and quickly work to mitigate the impact and fix the issue. By using Security and Compliance Center along with external integrations (such as, OpenShift Compliance Operator (OSCO), Tanium, NeuVector, and so on), you can build a robust approach for monitoring for security and compliance issues.
Integration
IBM Event Streams for IBM Cloud (optional)
Event Streams is a high-throughput message bus built with Apache Kafka. It is optimized for event ingestion into IBM Cloud and event stream distribution between your services and applications.
You can use Event Streams to complete the following tasks:
- Offload work to back-end worker applications.
- Connect event streams to streaming analytics to realize powerful insights.
- Publish event data to multiple applications to react in real time.
Satellite components in IBM Cloud
When you provision the Satellite service, the Satellite control plane master is created in your account. The following table describes the main components of the control plane master.
| Master components | Description |
|---|---|
| Satellite Link tunnel | The Satellite Link tunnel server creates a secure TLS connection to the Satellite Link connector that runs on the control plane worker 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 that is 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 more 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 | Based on the Razee open source project, Satellite Config is a continuous delivery tool that you can use to consistently roll out versions of your apps across Red Hat OpenShift on IBM Cloud clusters in Satellite locations. For more information, see Deploying Red Hat OpenShift on IBM Cloud resources across clusters with Satellite configurations. |
Satellite location components
A location is a representation of an environment in your on-premises data center that you want to bring IBM Cloud services to so that you can run workloads in your own environment. You create the location based on at least three separate zones of your backing infrastructure environment, and attach host machines from across these zones in your infrastructure to the location. The Satellite console provides a single pane of glass to manage the workloads that run across the infrastructure in your locations. For more information, see Planning your infrastructure environment for Satellite and Setting up Satellite locations.
Infrastructure
Satellite location-underlying infrastructure
You are responsible for providing the underlying infrastructure components in your on-premises data center that the Satellite location uses. These components include:
- Virtual and bare metal servers
- Virtual storage
- Virtual network
- Hypervisor
- Physical servers and memory
- Physical storage
- Physical network and devices
- Facilities and data centers
Satellite infrastructure components
The following table describes Satellite infrastructure components that run on top of the underlying infrastructure that you provide.
| Infrastructure components | Description |
|---|---|
| Hosts | Hosts are machines that reside in your infrastructure provider, across at least three separate zones, and must meet the minimum host requirements. After attaching the hosts to a Satellite location, you assign the hosts to the Satellite clusters to provide the computing power to run your application workloads. For more information, see Setting up Satellite hosts. |
| Storage | Satellite storage uses Satellite Config to provide a convenient way to install various storage drivers in Red Hat OpenShift on IBM Cloud clusters across your Satellite locations, by using storage templates. The storage templates are provided and tested by the vendors. After you install Satellite storage, your cluster users can use Kubernetes persistent volume claims (PVCs) to order and save their application data in persistent storage. For more information, see Understanding Satellite storage templates. |
Satellite control plane worker nodes
The following table describes the components that run as Satellite control plane worker nodes.
| Worker node component | Description |
|---|---|
| Satellite Link connector | The Satellite link connector 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 connector. The Satellite Link connector 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.
Workload cluster communication that leaves and enters your location is proxied by the Link tunnel server, and network traffic on this connection can be monitored and audited. The host requirements guide details any current exceptions to this policy. |
| 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 more 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 worker nodes to allow communication to IBM Cloud and monitoring through IBM. For more information, see Creating Satellite clusters. |
Workload clusters
You will create Red Hat OpenShift on IBM Cloud clusters in your Satellite location to run your application workloads. You will use the hosts of your own infrastructure that you added to your location as the worker nodes for the cluster. See Creating Red Hat OpenShift clusters in Satellite.
Other supporting components on-premises
In addition to your Satellite locations, you will need other components that run on-premises to complete the reference architecture including an edge plane, management plane, and (optionally) other application services. One of the most important features of the reference architecture is the definition of physical and logical separation between the edge plane, management plane, and Satellite workload clusters. This is used to ensure separation of application workloads from management functions and to isolate security functions from non-security functions.
The following table describes these components in more detail.
| Component | Description |
|---|---|
| Edge plane |
|
| Management plane |
|
| Other application services (optional) |
|