David Crayford Wrote:
If you intend to set up zCX for high availability, it would involve running zCX instances on different LPARs. To achieve this, you'll likely need Docker Swarm for creating a cluster that operates across multiple nodes. While OpenShift (Kubernetes) is a more advanced option, it comes with much higher operational costs in terms of resource usage. OpenShift 4.13 offers incremental improvements, we've been told it's expected that further enhancements will be introduced over time. Thanks David. I am actually working with one of your associates at Rocket on this. I get the impression that while Rocket has tested RTE in docker (and documented as such), clustering never was. They are going to work on that, and provide some example/samples. Timothy Sipples wrote: It provides an example using nginx, a popular HTTP(S) server. The example uses this startup command: docker run -p 8080:80 -d nginx The -p parameter is crucial. In this example it means, “Expose port 8080 to the outside world, and any traffic to/from port 8080 should be directed to/from port 80 within this nginx container image.” So if you’re trying to get two container images (on two different z/OS LPARs, as Dave Crayford suggested) to talk to each other you’d start them up with the -p option and then tell them to talk to each other on the respective external ports you’ve chosen. Hopefully obviously you should pick external ports that aren’t already occupied or reserved for other z/OS uses in that LPAR. Thanks Timothy. Yep found all that, have the instance up and working just fine it’s the peer to peer networking that is not working. The fine folks at Rocket indicate that their software is picking up the internal container IP, and not using the Host IP causing the problem. They are working up their own testing, and believe that docker overlay networking can resolve this. Yes indeed, the reason for zCX vs straight z/OS Unix is the fact that it all runs on ZIIPS. Plus its cool technology to learn and play with. It’s all a part of changing perceptions here that mainframe is just a COBOL machine. Separately, we are doing a zCX Openshift POC, mainly because there wasn’t any additional infrastructure to provision. If we were to do Openshift in any larger capacity, it would likely be on a LinuxOne box(es). Our next move for DB2 IDAA has to be LinuxOne boxes as well. I mention all of this as is to leverage our investment in GDPS and being able to Hiperswap/Region swap everything on Z or LinuxOne boxes in a coordinated fashion for Disaster recovery or facilities maintenance. This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
