ISV Ecosystem

zCX containers exploitation

  • 1.  zCX containers exploitation

    Posted Tue December 14, 2021 04:25 AM

    zCX containers exploitation 

    In one of the previous articles "The new generation of IBM Z confirms the longevity of mainframe", we started talking about the experiment concerning the exploitation of zCX containers on our products line: Primeur DATAONE.  


    Why IBM zCX? 

    IBM zCX expands and modernizes the z/OS software ecosystem.  

    It allows to integrate Linux on Z applications with z/OS enabling the operations of popular open source (applications and sw) with z/OS applications and data. 

    As the continuous development and delivery of applications have become crucial, containers seem to be the right choice for developing new microservices and applications. 


    zCX on Primeur's technology 

    Thanks to the possibility offered by IBM to run docker we recently succesfully dokerized some of our DATAONE components like s390x architecture zLinux docker images and we are now able to run the relevant containers into one or more instances of zCX on zOS 2.4. 

    Our containerized DATAONE components are JEE applications, aimed at Managed File Transfer, running on IBM open liberty application servers; these components heavily access to: 

    - TCP/IP related network resource 

    - DBRM tables 

    - hierarchical File System 

    In zOS systems we can take advantage of zCX to co-locate our run-time components with the native ZOS services: 

    - zOS TCPIP stack 

    - DB2 for zOS 

    - zFS  

    By co-locating applications and data on zOS platform we are able to consolidate the specific zOS workload in a high secure and scalable system in a very efficient way without the need to keep multiple environments. 

    In a typical zOS platform centric workload, the use of DB2 for zOS is almost mandatory compared to a departmental DBRM solution and co-locating the DB2 with DATAONE component is a very efficient way to speed-up the DB access.  

    Specifically, we can access the native local zFS in a shared manner via NFS so multiple containers in multiple zCX instances can share the same information and set-up a High Availability ACTIVE/ACTIVE application 

    With zCX, the code execution is delegated to zIIP type processors instead of general purpose ones generating cost savings and a great impact on mainframe costs 

    When all the components reside in the same zOS image than all the TCP/IP traffic is optimized via "cross memory virtual network":  

    in zOS, zCX uses cross memory functionality so that the data exchanged in TCP/IP connections between regular zOS address space and Docker containers flows through the copy of data in memory. 

    When the components are spreads between multiple zOS images the "Inbound Workload Queuing (IWQ) on OSA-Express in QDIO mode" feature keeps providing a fast connection on TCP/IP:   

    QDIO inbound workload queueing (IWQ) is a sophisticated OSA-Express feature to place inbound packets for differing workload types on separate processing queues; it is possible to enable the IWQ support for zCX so that the specific zCX queue can be used by the z/OS Communications Server to process inbound zCX traffic in parallel with inbound traffic on the other queues. 

    We are now experimenting: 

    • another DATAONE component on zCX containers that access on MongoDB 
    • how to implement integrated Disaster Recovery & Planned Outage Coordination of zCX instances 
    • how to implement the clustering and orchestration of zCX and container for higher availability and load balancing. 

    We will also do comparative throughput performance tests against the current traditional solution to validate the new approach based on zCX containers exploitation. 

    With The z/OS Container Extensions we can benefit of containerized applications that have been built to run on Linux on IBM Z, leveraging z/OS quality of service for optimized business continuity.  

    Angelo Pierotti