Sterling Data Exchange Container Deployment Patterns - IBM Cloud
Table of Contents
Introductory Notes
The following blog is to be used as a reference guide for deploying Sterling Solutions with IBM Cloud. They are reference patterns only. Factors such as internal network/security requirements, the ability and size of the operations team, and others should be considered when choosing an exact deployment.
These examples refer to Openshift Container Platform (OCP) as that is the preferred Kubernetes deployment from IBM. However, these reference patterns also work with Kubernetes.
Where available, IBM Cloud documentation is linked and referenced. It should also be noted that the goal of this blog is not to recommend one vendor or solution over another. If there are solutions favored by you such as specific firewalls, they should work fine. However, you should use officially supported databases.
Acronyms
Below are some acronyms you may find throughout this blog.
-
- B2Bi/SFG: IBM Sterling Business-to-Business Integrator / IBM Sterling File Gateway
- AC: IBM B2Bi/SFG Adapter Container
- ASI: IBM B2Bi/SFG Application Server-Independent
- REST: IBM B2Bi/SFG REST API Server
- C:D: IBM Sterling Connect Direct
- SSP: IBM Sterling Secure Proxy
- SSP PS: SSP Perimeter Server
- B2Bi PS: B2Bi Perimeter Server
- CM: SSP Configuration Manager
- SEAS: IBM Sterling External Authentication Server
- IDP: Identity Provider (e.g. LDAP, SAML, etc.)
- MQ: IBM MQ Cluster
- DB: Database Cluster
- DMZ: Demilitarized Zone
- OCP: Red Hat Openshift Container Platform
- K8s: Kubernetes
General Deployment Considerations
Regardless of whether cloud is being used, there are some deployment considerations to keep in mind. Some of these considerations are as follows:
-
- Make sure to check the latest support information in the IBM Software Product Compatibility Report (SPCR) as we continue to improve our support statement
-
For production environments you should provision enough worker nodes to allow one node or Availability Zone (AZ) to be down and still have enough capacity to run the environment. This allows for node updates or outages without affecting production.
-
In a production deployment, a minimum of 3 AZs is recommended. Additionally, the maximum latency must be below 10 milliseconds to span AZs in a single cluster.
-
Though it is possible to put both production and non-production environments in the same cluster separated by namespaces, it is not recommended as a best practice. This is because you cannot test cluster-level changes without affecting production as well.
-
Development and non-production environments can be less highly available for cost savings.
-
SSD Storage should be used for production workloads
-
It is important to note that some storage types cannot fail over between AZs. If this is the case for your storage type, you should plan to have enough nodes to handle outages or use different storage.
-
Node sizes will vary depending on workload. You typically want to avoid the cases of either many small nodes or only a few large nodes.
-
Some cloud providers limit network bandwidths on some node types so it is important to pay attention to the node types being used.
Traditional Pre-Container On-Premises Deployment
Below is a sample diagram of a pre-container on-premises deployment.
In this deployment, there is a DMZ, Secure Zone, and Infrastructure Layer, each of which is separated by a firewall and has its application components running in separate VMs.
Generic OCP or K8s Deployment & Details
Below is a sample diagram of a generic OCP/K8s deployment showing a Demilitarized Zone (DMZ) and Internal Zone.
Here, there are separate clusters in the DMZ and Internal Zones to further isolate environments (not required but provides more separation if desired). Each component uses a Kubernetes service to allow for load balancing and to surface a single IP Address. These IPs can be internal to the cluster or external. Each individual component in the deployment can scale vertically via K8s CPU and Memory limits. Most components (with the exceptions being SSP although it's planned for a future release) can also scale horizontally.
Rolling upgrades and "self-healing" are supported by components where K8s will spin up another pod if one crashes. Databases, MQ, and LDAP can be running within the cluster or externally. File (Network File System) or Block Storage is external to clusters and should have High Availability (HA). Additionally, there should be enough capacity such that the environment will function with one node offline. Finally, unlike most components, SSP has a service name and separate IP for each instance as it cannot scale horizontally at this time.
IBM Cloud MZR Deployment Model with Separate DMZ, Cluster, and VPC
Below is a sample OCP Deployment showing a DMZ and Internal Zone spanning a 3-zone MZR with the DMZ and application clusters in separate VPC instances.
This deployment configuration provides the maximum separation between the DMZ and Application clusters, but also maximum management overhead. If you wish to avoid the VPC-to-VPC connection going over the public internet, you may want to consider a Transit Gateway.
Each component has both load balancing and a service name to present a consistent IP. Also in this deployment, Database, MQ, and LDAP are High Availability (HA) and can fail over between data centers. The identity provider (IDP), Database, and MQ could be either within the cluster or external deployments/services. File or Block storage is still external to the cluster and Highly Available. In this case, there should be enough spare capacity such that the environment functions with one Availability Zone (AZ) offline.
Finally, all components are active, active meaning calls are load balanced between components. Note that this deployment should have at least one node per data center to allow for intra-data center failover as well.
This deployment pattern would be a good choice if you wish to have very high isolation as it has the DMZ and VPC in separate clusters. Though you must consider that having two clusters and two VPCs results in a higher management overhead and more infrastructure costs. The choice between Transit Gateway or communicating over the public gateway may also mean additional overhead.
IBM Cloud MZR Deployment Model with Separate DMZ and a Single VPC
Below is a sample OCP Deployment showing a DMZ and Internal Zone spanning a 3-zone MZR in a single IBM Virtual Private Cloud (VPC).
This is similar to the previous pattern, except in this deployment, only a single VPC is used. The DMZ and Internal Zone clusters are still separate to isolate environments for those not comfortable with a flat K8s/OCP model. The DMZ cluster is in a private subnet, preventing exposing node/internal IPs to the public internet. Though, Sterling SSP servers are exposed externally via Load Balancers. Inbound connections are possible via NAT servers in a Public Subnet.
This deployment pattern would provide relatively high isolation since the DMZ is a separate cluster to the internal zone. The single VPC is used to minimize network traffic between it and the possible traffic over the public internet. However, some things to keep in mind if going this route include the fact that having two clusters result in management overhead and more infrastructure costs. Additionally, sharing a VPC may not be enough isolation for some.
IBM Cloud MZR Deployment Model with a Single Cluster and Separate Namespaces
Below is a sample OCP Deployment showing an Internal Zone spanning a 3-zone MZR in a single IBM Virtual Private Cloud (VPC). The DMZ and Application pods are separated by namespaces with an OCP Cluster.
This this model, there is a single cluster and a single Private Subnet per data center. Physical nodes span environments and namespaces with the DMZ and Application pods separates with a single OCP Cluster via K8s Namespaces / OCP Projects.
If you wish to have lower management overhead this deployment may be a good choice. The low overhead comes from the fact that the DMZ and Applications share a single cluster and nodes. There is some level of network and management isolation with there being separate namespaces. OpenShift SDN is available by default to provide namespace isolation (Calico if using ROKS as ROKS does not support SDN).
Keep in mind that this deployment requires Calico or another CNI to be deployed in K8s. There is low isolation as environments share clusters and nodes, so care must be taken with networking rules to ensure proper isolation.
This is a common pattern in companies with a separate team that provides infrastructure to application teams. In these cases it is likely that the application team will be given their own namespace(s).
IBM Cloud OCP and K8s Options
There are two Cloud options in IBM Cloud: IBM Cloud Classic and IBM Cloud VPC. IBM Cloud VPC is the latest generation of IBM Cloud and is suggested for all new deployments (a comparison is available here).
-
- Redhat OpenShift on IBM Cloud Kubernetes Service (ROKS): Fully automated as-a-service OCP deployment
- IBM Cloud Kubernetes Service (IKS): Fully automated as-a-service Kubernetes Deployment
- Manual Install of OCP on IBM Virtual Private Cloud.
- Verify via the IBM Support Matrix that the release you want to install is supported on the version of OCP or K8s you plans to use
- Search for "Sterling" to find most components or "Transformation" to find ITX and/or ITXA
- IKS Kubernetes Lifecycle is generally a few months offset from the community. Ensure that the version of K8s you want to use is supported by both IKS and Sterling.
- Best practice for new environments is to start with the newest support version to get the latest capability/patches and maximize time before an upgrade is required.
Compute Infrastructure and Network Bandwidth
-
- IBM Cloud VPC is available in the following MultiZone Regions
- Various VPC Gen 2 node types are available
- For Transformation heavy use cases, likely want to use higher CPU nodes to minimize number of cores required
- For SFG/C:D heavy cases, you don't need to worry about storage on the nodes as you shouldn't use local storage with containers anyway.
- Focus on shared storage speed and network I/O
Understanding Network Bandwidth is very important:
IBM Cloud Storage
Active File System Storage
IBM Cloud has storage options for Single Zone and MultiZone deployments as well as Classic and VPC clusters
Storage Options for Single Zone Clusters
-
-
-
- VPC File Storage is supported in VPC clusters
- Can be used in MZR Clusters, but not ideal as storage volumes cannot move outside the data center. This means that PODs cannot move from one zone to another in the event of a failure so the remaining zones would have to be able to handle the load
- Default performance is 10 IOPS/GB which is the minimum suggested for production workloads
- Supports ReadWriteMany, ReadWriteOnce, and ReadOnlyMany
-
-
-
- VPC Block Storage is supported in VPC Clusters
- Can be used in MZR Clusters, but not ideal as storage volumes cannot move outside the data center. This means that PODs cannot move from one zone to another in the event of a failure so the remaining zones would have to be able to handle the load
- Default performance is 10 IOPS/GB which is the minimum suggested for production workloads
- Supports ReadWriteOnce only
- A full comparison Single Zone Storage is available here
Storage Options for MultiZone Clusters
Software Defined Storage (PortWorx)
-
-
-
- Supported in both VPC and Classic Clusters
- Can span data centers so Apps can fail over between zones in an MZR environment
- Provides close to bare metal performance when using SDS Machines
- Supports ReadWriteMany, ReadWriteOnce, and ReadOnlyMany
- See about PortWorx for details on how PortWorx and Software Defined Storage works and how to enable it in your environment
Software Defined Storage (OpenShift Data Foundation)
-
-
-
- Supported in ROKS for both VPC and Classic Clusters
- Hybrid cloud data platform offering simplified deployment and data management for K8s applications on RHOCP
- Multiple benefits including AI workload modernization, resource organization/optimization, and hybrid cloud integration
- A full description of MultiZone capable storage is available here
- Note: Object Storage is not applicable for active file system storage and is defined below
IBM Cloud Object Storage
-
- A full description of IBM Cloud Object Storage can be found here
- Sterling B2Bi supports Object Storage as an option for document payloads using Document Service
- Available with Sterling B2Bi certified container deployments
- Object storage is meant to store bulk data that is read infrequently. IT IS NOT MEANT TO BE USED AS ACTIVE FILE SYSTEM STORAGE
- Various Storage Classes of Object Storage are available
- Storage class depends on use cases but should probably start with Standard
- Two main use cases in B2Bi/SFG:
- Document Storage: Ability to store BPs and other large documents in S3 Storage vs the DB to reduce size/load on the DB
- Adapter Storage: Ability for SFG to send/receive files to/from S3 as a transfer mechanism
Networking/Firewall Options
Load Balancer Options in IBM Cloud
The IBM Sterling Helm charts will create load balancers as appropriate to expose the necessary containers externally. The exact Load Balancer type that gets provisioned depends on whether you are in a Classic or VPC Cluster:
Firewall Options
-
- We strongly recommend Sterling Secure Proxy (SSP) as it is specifically designed and proven to secure Sterling Environments
- While SSP is preferred, you are free to use whatever firewall you prefer
Network Security options with IBM Virtual Private Cloud (VPC)
Network Security Configuration when using IBM Kubernetes Service (IKS) or Redhat OpenShift on IBM Cloud Kubernetes Service (ROKS)
Since IKS can run in either IBM Cloud Classic or IBM VPC, the network options vary depending on which infrastructure you choose.
Controlling Network Traffic in IKS or ROKS Running on IBM VPC
Controlling Network Traffic in IKS or ROKS running on IBM Cloud Classic
Additional Firewall Options
-
-
- IBM Cloud Transit Gateway provides a private connection between multiple IBM Cloud VPC instances. IBM also provides an overview of the various connectivity options
- ROKS does not support OpenShift SDN, you would need to use Calico instead
- The best practice for controlling network policies is to use VPC controls or use Calico for use cases VPC does not cover
- For instance, Calico should be used in the case of separating two clusters in the same VPC
Database Support
You can either leverage a cloud Database Service or deploy a Database directly in the cluster
Note: it is not recommended to setup your own database in containers as this requires expertise in Kubernetes, the database, and how the database works in containers.
It is recommended that you use VMs/Baremetal or a cloud service.
IBM DB2
Self-Managed Databases
-
- Databases listed at the IBM Software Support Link can be deployed in a VM running a supported OS or via containers
- Search for "Sterling" and choose "IBM Sterling B2B Integrator"
Notes On Oracle DB
-
- As per the licensing policy of Oracle DB, you may not run Oracle DB on IBM Cloud VMs or containers
- There is no VSI support
- For IBM Cloud, you can only run Oracle DB on IBM Cloud Classic Baremetal servers, PowerVS, or a VMware stack
- Refer to the licensing terms from Oracle in conjunction with your supported hardware list when choosing to use Oracle
K8s / OCP Configuration Best Practices
Sterling B2Bi/SFG
A properly configured termination grace period (terminationGracePeriodSeconds) allows for a container's PreStop hooks to finish and then the subsequent stopping of the container.
As of release 6.1.2, IBM Sterling B2Bi/SFG supports a user-configurable termination grade period in contain deployments. With a properly configured termination grace period, processes, BP cleanup, and other currently running workloads will be given a long enough period to stop gracefully before the pod is killed.
A Note on MQ and B2Bi
As of the writing of this blog, MQ hosted on IBM Cloud does not work with Sterling B2Bi.
#Highlights#Highlights-home#sustainability-highlights-home