Kubernetes on Z with PowerMax: Modern Software Running on Mainframe
Mon, 02 Oct 2023 13:21:45 -0000
|Read Time: 0 minutes
Benefits of Kubernetes on System Z and LinuxOne
When I was a customer, I consistently evaluated how to grow the technical influence of the mainframe platform. If I were talking about the financials of the platform, I would evaluate the total cost of ownership (TCO) alongside various IT solutions and the value deduced thereof. If discussing existing technical pain points, I would evaluate technical solutions that may alleviate the issue.
For example, when challenged with finding a solution for a client organization aiming to refresh various x86 servers, I searched online presentations, YouTube videos, and technical websites for a spark. The client organization had already identified the pain point. The hard part was how.
Over time, I found the ability to run Linux on a mainframe (called Linux on Z), using an Integrated Facility for Linux (IFL) engine. Once the idea was formed, I started baking the cake. I created a proof-of-concept environment installing Linux and a couple of applications and began testing.
The light-bulb moment came not in resolving the original pain point, but in discovering new opportunities I had not originally thought of. More specifically:
- Physical server consolidation – I’ll create a plethora of virtual servers when needed
- License Consolidation – Certain applications with x86 were licensed on a per engine basis. A quad core x86 server may need four application licenses to function. I needed one license for my Linux on Z environment (at the time of testing)
- Scalability – I could scale horizontally by adding more virtual machines and vertically by increasing the network ports accessible to the server and adding more memory/storage
- Reliability – Mainframe technology has been known to be reliable, utilizing fault tolerant mechanisms within the software and hardware to continue business operations
With the 2023 addition of Kubernetes on LinuxOne (mainframe that only runs Linux), you can scale, reduce TCO, and build that hybrid cloud your IT management requires. With Kubernetes providing container orchestration irrelevant of the underlying hardware and architecture, you can leverage the benefits of LinuxOne to deploy your applications in a structured fashion.
Benefits when deploying Kubernetes to Linux on Z may include:
- Enablement of DevOps processes
- Container Scalability – using one LinuxOne box with hundreds (if not thousands) of containers
- Hybrid Cloud Strategy – where LinuxOne is servicing various internal business organizations with their compute and storage needs
With Dell providing storage to mainframe environments with PowerMax 8500/2500, a Container Storage Interface (CSI) was created to simplify your experience with allocating storage to Kubernetes environments when using Linux on Z with Kubernetes.
The remaining content will focus on the CSI for PowerMax. Continue reading to explore what’s possible.
Deploy Kubernetes
Linux on IBM Z runs on s390x architecture. This means that all the software we use needs to be compiled with that architecture in mind.
Luckily, Kubernetes, CSI sidecars, and Dell CSI drivers are built in Golang. Since the early days of Go, the portability and support of different OS and architectures has been one of the goals of the project. You can get the list of compatible OS and architecture with your go version using the command:
go tool dist list
The easiest and most straightforward way of trying Kubernetes on LinuxOne is by using the k3s distro. It installs with the following one-liner:
curl -sfL https://get.k3s.io | sh -
Build Dell CSI driver
The Dell CSI Driver for PowerMax is composed of a container to run all actions against Unisphere and mount a LUN to a pod, with a set of official CSI sidecars to interact with Kubernetes calls.
The Kubernetes official sidecars are published for multiple architectures including s390x while Dell publishes only images for x86_64.
To build the driver, we will first build the binary and then the image.
Binary
First, let’s clone the driver from https://github.com/dell/csi-powermax in your GOPATH. To build the driver, go in the directory and just execute:
CGO_ENABLED=0 GOOS=linux GOARCH=s390x GO111MODULE=on go build
At the end of the build, you must have a single binary with static libs compiled for the s390x:
file csi-powermax
csi-powermax: ELF 64-bit MSB executable, IBM S/390, version 1 (SYSV), statically linked, Go BuildID=…, with debug_info, not stripped
Container
The distributed driver uses minimal Red Hat Universal Base Image. There is no s390x compatible UBI image. Therefore, we need to rebuild the container image from a Fedora base-image.
The following is the Dockerfile:
# Dockerfile to build PowerMax CSI Driver
FROM docker.io/fedora:37
# dependencies, following by cleaning the cache
RUN yum install -y \
util-linux \
e2fsprogs \
which \
xfsprogs \
device-mapper-multipath \
&& \
yum clean all \
&& \
rm -rf /var/cache/run
# validate some cli utilities are found
RUN which mkfs.ext4
RUN which mkfs.xfs
COPY "csi-powermax" .
COPY "csi-powermax.sh" .
ENTRYPOINT ["/csi-powermax.sh"]
We can now build our container image with the help of docker buildx, which makes building cross-architecture a breeze:
docker buildx build -o type=registry -t coulof/csi-powermax:v2.8.0 --platform=linux/s390x -f Dockerfile.s390x .
The last step is to change the image in the helm chart to point to the new one: https://github.com/dell/helm-charts/blob/main/charts/csi-powermax/values.yaml
Et voilà! Everything else is the same as with a regular CSI driver.
Wrap-up, limitations, and disclaimer
Thanks to the open-source model of Kubernetes and Dell CSM, it’s easy to build and utilize them for many different architectures.
The CSI driver for PowerMax supports FBA devices via Fiber Channel and iSCSI. There is no support for CKD devices which require code changes.
The CSI driver for PowerMax allows CSI-compliant calls.
Note: Dell officially supports (through Github tickets, Service Requests, and Slack) the image and binary, but not the custom build.
Useful links
Stay informed of the latest updates of the Dell CSM eco-system by subscribing to:
Authors: Justin Bastin & Florian Coulombel
Related Blog Posts
CSM 1.8 Release is Here!
Fri, 22 Sep 2023 21:29:12 -0000
|Read Time: 0 minutes
Introduction
This is already the third release of Dell Container Storage Modules (CSM)!
The official changelog is available in the CHANGELOG directory of the CSM repository.
CSI Features
Supported Kubernetes distributions
The newly supported Kubernetes distributions are :
- Kubernetes 1.28
- OpenShift 4.13
SD-NAS support for PowerMax and PowerFlex
Historically, PowerMax and PowerFlex are Dell’s high-end and SDS for block storage. Both of these backends recently introduced support for software defined NAS.
This means that the respective CSI drivers can now provision PVC with the ReadWriteMany access mode for the volume type file. In other words, thanks to the NFS protocol different nodes from the Kubernetes cluster can access the same volume concurrently. This feature is particularly useful for applications, such as log management tools like Splunk or Elastic Search, that need to process logs coming from multiple Pods.
CSI Specification compliance
Storage capacity tracking
Like PowerScale in v1.7.0, PowerMax and Dell Unity allow you to check the storage capacity on a node before deploying storage to that node. This isn't that relevant in the case of shared storage, because shared storage generally will always show the same capacity to each node in the cluster. However, it could prove useful if the array lacks available storage.
Using this feature, an object from the CSIStorageCapacity type is created by the CSI driver in the same namespace as the CSI driver, one for each storageClass.
An example:
kubectl get csistoragecapacities -n unity # This shows one object per storageClass.
Volume Limits
The Volume Limits feature is added to both PowerStore and PowerFlex. All Dell storage platforms now implement this feature.
This option limits the maximum number of volumes to which a Kubernetes worker node can connect. This can be configured on a per-node basis, or cluster-wide. Setting this variable to zero disables the limit.
Here are some PowerStore examples.
Per node:
kubectl label node <node name> max-powerstore-volumes-per-node=<volume_limit>
For the entire cluster (all worker nodes):
Specify maxPowerstoreVolumesPerNode or maxVxflexVolumesPerNode in the values.yaml file upon Helm installation.
If you opted-in for the CSP Operator deployment, you can control it by specifying X_CSI_MAX_VOLUMES_PER_NODES in the CRD.
Useful links
Stay informed of the latest updates of the Dell CSM eco-system by subscribing to:
- The Dell CSM Github repository
- Our DevOps & Automation Youtube playlist
- Slack (under the Dell Infrastructure namespace)
- Live streaming on Twitch
Author: Florian Coulombel
CSM 1.7 Release is Here!
Fri, 30 Jun 2023 13:42:36 -0000
|Read Time: 0 minutes
Introduction
The second release of 2023 for Kubernetes CSI Driver & Dell Container Storage Modules (CSM) is here!
The official changelog is available in the CHANGELOG directory of the CSM repository.
As you may know, Dell Container Storage Modules (CSM) bring powerful enterprise storage features and functionality to your Kubernetes workloads running on Dell primary storage arrays, and provide easier adoption of cloud native workloads, improved productivity, and scalable operations. Read on to learn more about what’s in this latest release.
CSI features
Supported Kubernetes distributions
The newly supported Kubernetes distributions are:
- Kubernetes 1.27
- OpenShift 4.12
- Amazon EKS Anywhere
- k3s on Debian
CSI PowerMax
For the last couple of versions, the CSI PowerMax reverseproxy is enabled by default. The TLS certificate secret creation is now pre-packaged using cert-manager, to avoid manual steps for the administrator.
A volume can be mounted to a Pod as `readOnly`. This is the default behavior for a `configMap` or `secret`. That option is now also supported for RawBlock devices.
apiVersion: v1 kind: Pod metadata: name: task-pv-pod spec: volumes: - name: task-pv-storage persistentVolumeClaim: claimName: task-pv-claim # What ever is the accessMode it will be read-only for the Pod readOnly: true ...
CSM v1.5 introduced the capacity to provision Fibre Channel LUNs to Kubernetes worker nodes through VMware Raw Device Mapping. One limitation of the RDM/LUN was that it was sticky to a single ESXi host, meaning that the Pod could not move to another worker node.
The auto-RDM feature works at the HostGroup level in PowerMax and therefore supports clusters with multiple ESXi hosts.
We are exposing the host I/O limits on the storage groups parameter using the StorageClass. The Host I/O limit is here to implement QoS at the worker node level and to prevent any noisy neighbor behavior.
CSI PowerScale
Storage Capacity Tracking is used by the Kubernetes scheduler to make sure that the node and backend storage have enough capacity for Pod/PVC.
The user can now set Quota limit parameters from the PVC and StorageClass requests. This allows the user to have better control of the quota parameters (including Soft Limit, AdvisoryLimit, Softgrace period) attached to each PVC
The PVC settings take precedence if quota limit values are specified in both StorageClass and PVC.
CSM features
CSM Operator
One can now use the CSM Operator to install Dell Unity and PowerMax CSI drivers and affiliated modules.
The CSM Operator now provides CSM resiliency and CSM-Replication for CSI-PowerFlex.
A detailed matrix of supported CSM components is available here.
CSM Installation Wizard
The CSM Installation Wizard is the easiest and most straight forward way to install the Dell CSI drivers and Container Storage Modules.
In this release, we are adding support for Dell Unity, PowerScale, and PowerFlex.
To keep it simple, we removed the option to install the driver and modules in separate namespaces.
CSM Authorization
In this release of CSM, Secrets Encryption is enabled by default.
- All secrets are encrypted by default, using the AES-CBC key type.
- After installation/upgrade, all secrets will be encrypted.
- AES-CBC is the default key type.
- AES-CBC is the only supported key type.
CSM Replication
When you use CSM replication, two volumes are created: the active volume and the replica. Prior to CSM v1.7, if you removed the two PVs, the physical replica wasn't deleted.
Now on PV deletion, we cascade the removal to all objects, including the replica block volumes in PowerStore, PowerMax, and PowerFlex, so that there are no more orphan volumes.
Useful links
Stay informed of the latest updates of the Dell CSM eco-system by subscribing to:
- The Dell CSM Github repository
- Our DevOps & Automation Youtube playlist
- Slack (under the Dell Infrastructure namespace)
Author: Florian Coulombel