Glossary

IBM GDPS:

• IBM Geographically Dispersed Parallel Sysplex

• Collection of system recovery offerings on the IBM Z platform

• Overall concept including hardware and software architecture.

• Benefits:

  • Automation of operational tasks for availability and recovery with scripts.

  • Flexibility to gain data consistency across both z/OS, z/VM and guests, plus open system data. GDPS also uses open architecture and is application independent.

  • Monitoring of your environment from a single point and in real time to detect any deviation that could impact resiliency.

  • Resiliency to support multiple disk replication architectures, high availability, and disaster recovery at any distance from a single point of control – in seconds.

• IBM GDPS: An Introduction to Concepts and Capabilities (IBM Redbooks)

GDPS Suite of Offerings:

• GDPS Continuous Availability (GDPS AA)

  • Continuous Availability and Disaster recovery solution for Db2, IMS, and VSAM data

  • Application level granularity

  • Site switch in seconds (once the event is detected)

  • RPO in seconds (with the ability to issue reports that can be generated showing orphaned data)

  • Protects against metro and regional disasters (distance between sites is unlimited)

  • Minimal response time impact

  • Multiple levels of D/R:

    • GDPS Metro = local

    • GDPS Global = global

    • GDPS Metro Global = local and global combined

• GDPS Global – GM (GDPS GM)

  • End-end automated disaster recovery solution

  • Disaster recovery solution for IBM Z and non-IBM Z data

  • RTO between an hour to two hours

  • RPO less than one minute

  • Protects against regional disasters (distance between sites is unlimited)

  • Minimal remote copy performance impact

• GDPS Global – XRC (GDPS XR)

  • End-end automated disaster recovery solution.

  • Support for z/OS, z/VM, and z/VM guests, including Linux on Z.

  • RTO between one and two hours.

  • RPO of seconds.

  • Protects against localized as well as regional disasters (distance between sites is unlimited).

  • Minimal remote copy performance impact

• GDPS Metro HyperSwap Manager (GDPS HM)

  • Cost-effective disaster recovery (D/R) solution.

  • Provides the ability to dynamically switch to secondary volumes without requiring applications to be quiesced.

• GDPS Metro

  • Advanced version of GDPS HM

    • GDPS HM + fully automate the recovery at the remote site.

  • Near continuous disk availability.

  • Near transparent D/R solution.

  • Recovery Time Objective (RTO) less than an hour.

  • Recovery Point Objective (RPO) of zero.

  • Protection against localized area disasters (distance between sites limited to 200 km fiber).

  • Protection against multiple failures with three synchronous copies of the data.

  • End-End automation of Linux on Z environment.

  • Management of non-Z data.

  • Management of foreign system disk.

• GDPS Metro Global (GDPS MGM and GDPS MzGM)

  • GDPS Metro or GDPS HM combined with GDPS XRC is called GDPS Metro Global – XRC (or GDPS MzGM)

  • GDPS PPRC or GDPS HM combined with GDPS GM is called GDPS Metro Global – GM (or GDPS MGM). GDPS MGM is a solution that also provides a solution for both IBM Z and non-Z data.

    • Down to zero data loss

    • HyperSwap for disk availability

    • Protection from regional events

    • No impact to end user response time

    • Disaster recovery solution for IBM Z and non-IBM Z data (with GDPS MGM)

GFS2:

• Red Hat Global File System 2

• Shared-disk file system for Linux clusters

• Allows all members of a cluster to have direct concurrent access to the same shared block storage.

• Distributed Lock Manager (DLM) can be used.

GPFS:

• General Parallel File System

• It's also known as IBM Spectrum Scale. (This is the brand name of GPFS)

• since 2001 available for Linux

• does not ship by default with Redhat Distributions

• is a third-party software

• looks like any other file system in Linux:

   $ grep -w gpfs proc/mounts 
   /dev/abcd /efg gpfs rw,relatime 0 0

• GPFS on IBM ESS storage hardware

Floating IP:

An IP address that is loosely attached to a NIC. A high availability service such as Redhat HA or Keepalive can move that IP address to another host system when required. For example when the node becomes unhealthy.

Live Guest Relocation (LGR):

Live Guest Relocation allows you to move a powered-on virtual machine to another host while the virtual machine is running. This feature is useful when you need to perform maintenance on a host or evacuate a host in case of failure.

High availability:

High availability is a concept for system development and the associated implementation of services that ensure that a system maintains a certain level of operation and remains accessible and functional during periods of peak demand or component failure.

Red Hat Enterprise Linux High Availability Add-On (RHEL HA):

This is the official product name for the supported high availability software suite, which includes pacemaker, corosync and more. Red Hat HA is used as an abbreviation. The solution provides failover capabilities for applications and services running on Red Hat Enterprise Linux. It is designed to provide a high level of availability and redundancy for mission-critical applications, and to minimize downtime in the event of a system or component failure. To learn more check out the RedHat HA documentation.

STONITH (Shoot the Other Node in the Head):

This is the fencing implementation of Pacemaker and provides fault tolerance in clusters. It allows nodes to independently check the health of other nodes or resources in the cluster and take action to recover. It also ensures data integrity by forcefully shutting down nodes and removing them from the cluster.

To get an overview of the available hardware, have a look at the following list of hardware. This is not an exhaustive list.

IBM LinuxONE (arch: s390x):

• IBM LinuxONE Emperor 4

• IBM LinuxONE III LT1

• IBM LinuxONE III LT2

• IBM LinuxONE Emperor (named after a penguin species)

• IBM LinuxONE Emperor II

• IBM LinuxONE Rockhopper (named after a penguin species)

• IBM LinuxONE Rockhopper II

IBM Power (arch: ppc64, ppc64le):

• IBM Power9, examples:

  • IBM Power Systems IC922

    • 2U with Processor, flexible PCIe Slots: GPU, HBA, RAID controller, a lot of memory slots

  • IBM Power Systems AC922 (alternatives: LC921, LC922)

    • 2U half rack, 2 x Power 9 processors, up to 6 NVIDIA V100, some flexible PCIe slots, ...

IBM Z (arch: s390x):

• IBM z16

• IBM z15 T01 (Alternative: T02)

• IBM z14 (Air Cooled) (Alternative: Water Cooled, Model ZR1)

IFL:

• IBM Integrated Facility for Linux is a processor specifically designed for Linux-Workloads.

Mainframe-attached storage (e.g. IBM's System Storage DS8000):

• DASD (Direct Access Storage Devices).

  • ECKD (Extended Count Key Data) type DASD.

  • FBA type DASD.

• zFCP SCSI Lun (FCP attached LUN).

Network cards:

• RoCE Express (RDMA over Converged Ethernet)

  • RoCE = RDMA over Converged Ethernet.

  • RDMA = Remote Direct Memory Access.

  • Shared RoCE environment: RoCE express features can be used concurrently/shared.

  • RNIC: RDMA network interface card.

• OSA (Open Systems Adapter)

  • Network controller for IBM z/Architecture.

  • Maximum speed is 10 Gbps.

vCPU at KVM:

• Virtual central processing unit.

• How to calculate: 1 IFL equals roughly 4 vCPUs (in KVM terms). 12 IFLs show up in Linux as 24 CPUs because of SMT2 (lscpu). With vcpu the KVM vcpu number is meant <vcpu></vcpu>.

Linux on IBM zSystems (LoZ) means you run Linux on either:

• IBM LinuxONE or IBM Z

• on a LPAR (pr/sm OR pr/sm in DPM mode), as KVM Guest or as z/VM Guest.

• s390x architecture

Bootstrap:

• Required during the installation to set up the compute and control planes.

• After installation, it is no longer needed.

Compute plane (compute):

• Formerly known as "Worker node".

• Run the applications that are deployed to the cluster

• Managed by the Control plane.

Control plane (control):

• Former known as "Master node".

• Central point of coordination and management for the cluster.

• Provides the overall system architecture and APIs that allow users to deploy and manage applications on the platform.

• Managing the underlying infrastructure and ensuring that all components are functioning correctly.

• Manage workloads on the compute plane.

etcd:

• Consistent distributed key-value store, which persists the state of all resource objects.

• Designed for small amounts of data that fit entirely in memory.

• Open source.

• More information.

Installer-Provisioned Infrastructure (IPI):

Depending on how you want to install OpenShift, you can choose between user-provisioned infrastructure and installer-provisioned infrastructure. In Supported installation methods is a list which platforms are supported. Check the previous link to see if IPI is currently supported by IBM zSystems.

By default, the installation program acts like an installation wizard, prompting you for values, as well as populating the values that it cannot determine itself with reasonable default parameters. The installation process can also be customized to cover advanced infrastructure scenarios.

There are two different installation types, the standard cluster installation and the custom cluster installation. The standard installation requires the least amount of information for the installation of the cluster. Whereas with a user-defined cluster, further details about the platform can be specified. For example, the number of control/compute planes can be specified here, or the CIDR range for the kubernetes service network.

With installer-provisioned infrastructure, OpenShift manages all aspects of the cluster, including the operating system itself. Each machine starts pre-configured with everything it needs for the underlying infrastructure. This configuration allows the cluster to manage itself and perform updates on its own.

OpenShift command-line interface (CLI):

• Terminal command: oc (OpenShift command).

• Works directly with the source code.

• Scripts for OpenShift.

• Manage OpenShift when the web console is not available.

Red Hat Enterprise Linux CoreOS (RHCOS):

• It is a variant of Red Hat Enterprise Linux (RHEL) optimized for running containerized workloads.

• Provides a minimal, immutable operating system that can be deployed in bare-metal or virtualized environments.

• Includes all the necessary components for running containerized applications, such as a container runtime environment, an image builder, and a command-line interface.

Red Hat OpenShift Container Platform (OpenShift):

• OpenShift is a platform for container-based applications.

• It includes an integrated container runtime, container orchestration, and infrastructure management.

• It enables developers to quickly create and deploy applications in a self-contained environment.

• OpenShift is based on CRI-O and Kubernetes and is compatible with other container technologies.

• It is available in both on-premise and cloud-based versions.

Red Hat OpenShift resource types

Most components in OpenShift are defined as resource. A resource is described in yaml. There are a lot of basic resource types like e.g. NS (Nameserver), S (Service), P (Pod), R (Routes), C (Container). They can be combined to create scalable and reliable workload to your liking. Those yaml configurations are stored in an etcd database which reacts to configurations changes.

The following is a selection of resource types:

• ConfigMap (CM): ConfigMaps allows you to define configuration data for your applications. This data can be used by your applications to load configuration information at runtime.

• Container (C): A container is the basic unit for a deployment in OpenShift. It is a runnable instance of an application that can be created from a Docker image or a source code repository. A container is always deployed on a pod, which is a group of one or more containers.

• Deployments (D): A deployment in OpenShift is a process of creating or updating a group of identical pods. This process is also known as a rollout.

• DeploymentConfigs (DC): A DeploymentConfig resource defines the desired deployment state for a pod or group of pods and is also used to manage them. The resource contains configurations for how to perform the deployment, such as the number of replicas to use, the pod template to use for the deployment, and other options.

• Namespace (NS): A namespace is a logical grouping of OpenShift resources. All resources within a namespace share a common set of labels (key-value pairs). Typically synonymous with "Project" in OpenShift parlance, which is preferred.

• PersistentVolumeClaims (PVC): A PVC is a request for storage by a user, similar to how a Pod requests node resources.

• PersistentVolume (PV): A PV is a cluster resource that represents a piece of storage provisioned by an administrator or dynamically provisioned using Storage Classes.

• Pod (P): A pod is a group of one or more containers with shared storage/network and a specification of how the containers should be executed. A pod's contents are always co-located and co-scheduled, and run in a shared context.

• Projects (PR): A project in OpenShift is a logical separation of resources within the OpenShift environment. With projects, administrators can control who has access to which resources and set up role-based access control for users.

• Routes (RT): Routes define how external clients can access services running in an OpenShift cluster. They also make a service available under a specific hostname and path and can be used for load balancing, SSL termination, and name-based virtual hosting.

• Secrets (S): Secrets are used to store sensitive information, such as passwords, API keys, and certificates. Secrets are encrypted and can be used by pods to access sensitive information.

• Service (S): A Kubernetes service is an internal load balancer that allows pods to communicate with each other. Services are assigned an IP address and port pair that points to a corresponding backing pod when accessed.

User-Provisioned Infrastructure (UPI):

Depending on how you want to install OpenShift, you can choose between user-provisioned infrastructure and installer-provisioned infrastructure. In a nutshell, you must do everything by yourself, manually. This means you must manage the complete infrastructure yourself. This includes load balancers, network configuration, DNS, DHCP and storage for the cluster infrastructure. In addition, you must manage the the update process.

The advantage of this approach is that you understand the underlying infrastructure and most errors are easier to find. It also makes the cluster installable in special infrastructure environments.The disadvantage is that you require greater technical knowledge, the installation usually takes longer, and more training time is needed.

It is also possible to partially automate these steps. This is called automated user-provisioned infrastructure (Auto UPI) and is usually implemented using ansible scripts. Automation can make the user-provisioned infrastructure setup and configuration more convenient but you still need to maintain the infrastructure manually after installation. How Red Hat supports customer automated OpenShift UPI deployments.

Hardware RAID:

Often the Host Bus Adapter already provides RAID capabilities to offload the RAID computations to the adapter.

HBA/Raid Controller:

Let's start with a HBA (Host Bus Adapter). As the name already suggests it is an adapter to connect a drive to a Host System. In consumer systems this can look like this: Drive -> HBA (PCIe extension card OR mainboard-integrated) -> OS visibility. In enterprise environments it looks similar.

• Example (low-end consumer):

  • 4 x 3.5'' drive with a SATA III (SATA revision 3.x) (marketing term: SATA 6 Gb/s) interface

  • Cable: Sideband connector - 1 x SFF-8087 (Internal mini-SAS) with internal fan-out for 4 x SATA III

  • PCIe x4 Gen 2 HBA with two SFF-8087 ports (just one used in this case)

• Example 2 (high-end consumer):

  • 3.5'' drive with a SAS3 interface (allows full-duplex)

  • Cable: Sideband connector - 1 x SFF-8643 (mini-SAS HD) to 1 x SFF-8643 (mini-SAS HD)

  • PCIe x8 Gen 3 HBA with two SFF-8643 ports (just one used in this case)

• Example 3 (business):

  • See: https://www.ibm.com/docs/en/ds8800

JBOD/JBOF:

"Just a bunch of drives"/"Just a bunch of flash" means that we connect drives with a HBA to the host system and make them available as individual drives. You can keep them individual or combine them via software solutions.

Software RAID:

As soon as disks are visible by the operating system as independent disks you can combine disks with different software solutions such as LVM, mdadm or sepcial filesystems such as zfs or btrfs.