Difference between sysplex and lpar?

[Neeraj Gugnani]

Hi,

What is the difference between sysplex and lpar?

I did google it but it's confusing:

A sysplex can be either basic or parallel. A basic sysplex can communicate using channel to channel (CTC) connections between LPARs. Parallel Sysplex uses something called a Coupling Facility (CF). Note: The Parallel Sysplex Coupling Facility can run either as a separate LPAR or within a dedicated hardware device.

What does that mean? Can I say LPAR and sysplex be same if one sysplex has one lpar?

[zum13]

Hello.

LPARs are basically to do with partitioning a machine. It allows you to run multiple operating systems on the same physical box. It is essentially z/VM in microcode. You can partition up the machine for the operating systems you are running and specify which resources you want to dedicate to it (i.e. I/O devices, memory, processors). Each partition then appears as an IPL-able machine.

Every machine has at least one LPAR. Older machines did not have partitioning, and it only really appeared in the 1980s as an option called PR/SM (commonly referred to as "prism"). Now it is the default, so there has to be an LPAR even if you are only running one OS on the system.

Sysplexes are about running multiple interconnected z/OS systems together to co-operate in the running of workloads. If you submit a job, it can run on any system in the sysplex that has the available capacity to handle it. Should one of the systems fail then the others can take over. The cross-system Coupling Facility (XCF) handles co-ordindation between the systems so that events on the different images can be properly synchronised.

You can have a sysplex between partitions on a single physical machine but if the machine, say, loses power then everything stops. Where it comes into its own is the ability to use multiple machines at which point they need to be linked together which is where the CTCs come in. The machines don't have to be located at a single installation. For the purposes of disaster recovery, the machines can be linked over a considerable distance as can the DASD and communications. If something befalls one site, the others can take over the load without causing disruption to the service.

A single isolated z/OS system is a monoplex. It has the configuration and the management datasets for a sysplex set up, it just has nothing outside its own LPAR to collaborate with. There's a set of messages that appear in the IPL log that tells you what the sysplex setup for the system is.

Unfortunately, my knowledge of the inner workings of sysplexes is a little limited as most of my sysprogging went on under VM so I've not really had the chance to tinker with it even though VM/ESA and z/VM have a feature to allow the creation of a virtual sysplex between z/OS virtual machines. There's a lot of IBM documentation on the subject including a number of Redbooks, so plenty of stuff to dig around in for more information.

[Versatyre]

Sysplex and LPAR (Logical Partition) are both terms used in the context of IBM mainframe systems, but they refer to different aspects of mainframe technology:
he key difference is that Sysplex refers to the clustering of multiple mainframe computers to provide high availability and load balancing at the system level, while LPAR refers to the virtualization of a single mainframe into multiple logical partitions to run separate workloads with isolation at the hardware level. Sysplex is about system-level coordination, while LPAR is about hardware-level virtualization and resource partitioning.

[Neeraj Gugnani]

Hello.

LPARs are basically to do with partitioning a machine. It allows you to run multiple operating systems on the same physical box. It is essentially z/VM in microcode. You can partition up the machine for the operating systems you are running and specify which resources you want to dedicate to it (i.e. I/O devices, memory, processors). Each partition then appears as an IPL-able machine.

Every machine has at least one LPAR. Older machines did not have partitioning, and it only really appeared in the 1980s as an option called PR/SM (commonly referred to as "prism"). Now it is the default, so there has to be an LPAR even if you are only running one OS on the system.

Sysplexes are about running multiple interconnected z/OS systems together to co-operate in the running of workloads. If you submit a job, it can run on any system in the sysplex that has the available capacity to handle it. Should one of the systems fail then the others can take over. The cross-system Coupling Facility (XCF) handles co-ordindation between the systems so that events on the different images can be properly synchronised.

You can have a sysplex between partitions on a single physical machine but if the machine, say, loses power then everything stops. Where it comes into its own is the ability to use multiple machines at which point they need to be linked together which is where the CTCs come in. The machines don't have to be located at a single installation. For the purposes of disaster recovery, the machines can be linked over a considerable distance as can the DASD and communications. If something befalls one site, the others can take over the load without causing disruption to the service.

A single isolated z/OS system is a monoplex. It has the configuration and the management datasets for a sysplex set up, it just has nothing outside its own LPAR to collaborate with. There's a set of messages that appear in the IPL log that tells you what the sysplex setup for the system is.

Unfortunately, my knowledge of the inner workings of sysplexes is a little limited as most of my sysprogging went on under VM so I've not really had the chance to tinker with it even though VM/ESA and z/VM have a feature to allow the creation of a virtual sysplex between z/OS virtual machines. There's a lot of IBM documentation on the subject including a number of Redbooks, so plenty of stuff to dig around in for more information.

Thank you for the details. I am still trying to understand it.

What does this mean:

It is essentially z/VM in microcode.

[zum13]

z/VM is IBM's virtualisation product. When you sign on z/VM your userid is running a virtual machine into which you can IPL an operating system. That operating system will see itself as running on bare metal. It's basically like VMWare or VirtualBox for a mainframe. Most users will run a system called CMS, but you can also run z/OS, VSE, zTPF, zLinux, or even a version of z/VM itself on a z/VM userid.

The LPAR functionality is fundamentally z/VM but it's been implemented within the machine's low-level software (the microcode), albeit with some limitations/differences in how it is operated and configured. Each individual LPAR appears to the operating system running in it to be a real machine, but in reality, there could be upto 30 systems running on the same physical box.

[Neeraj Gugnani]

What's the benefit of doing this? is not it that Mainframes were built for reliability and speed and if that is what z/VM takes away then what's the benefit of doing it? I mean when it's all virtualized and not works on real hardware, then how stability is maintained?

[Neeraj Gugnani]

Second question, is not MVS is what works for zOS and z/VM is separate?

[zum13]

What's the benefit of doing this? is not it that Mainframes were built for reliability and speed and if that is what z/VM takes away then what's the benefit of doing it? I mean when it's all virtualized and not works on real hardware, then how stability is maintained?

Mainframes are big, expensive bits of equipment. The older machines were even more expensive than they are now. If you need to run multiple operating systems running different types of workloads then PR/SM allows you to run them on one box rather than suffer the expense of multiple boxes. LPARs came about as a result of the need to split processing resources to keep workloads separate whereas the sysplex is about joining resources together in order to spread the workload across multiple LPARs/machines to improve resilience and scale capacity.

z/VM began life on System/360 as CP/40. It has served many roles over the years. Some sites used it solely with CMS to provide a platform for general users. It was commonly found in combination with DOS/VSE as a means of overcoming some of that operating systems limitation's, but there were also sites that had MVS running on it. VM/XA came along as a means of allowing sites running MVS on System/370 machines to transition to MVS/XA. Until PR/SM, it was the only way to split a machine to handle multiple systems. Today, IBM is mainly marketing it as a means of running large numbers of zLinux instances.

The overheads to running z/VM are relatively minor for the benefits it brings, but is not an emulator. The bulk of the instructions run as they would if they were on bare metal and in that respect it operates in much the same way as traditional time sharing systems do. However, there are some instructions that are flagged as invalid causing an exception to be generated. z/VM intercepts these exceptions and handles them in a manner which allows the instruction to appear to complete so that the guest OS does not see through the illusion. For example, z/VM has the concept of "minidisks". These are simply regions on larger disks, so you could have a minidisk defined at virtual address 200 which actually starts at cylinder 1000 on the real disk. The I/O requests from the guest OS cause exceptions which z/VM intercepts and translates (e.g. a read from cylinder 2 on the minidisk becomes 1002 on the real disk). From the point of view of the guest OS, the instruction completes and it has read from cylinder 2.

There's a project around that emulates a System/360 era mainframe on an FPGA device. Rather than attempting to implement the 360 instruction set, it runs the original microcode. The reality is that the microcode layer has always been there in IBM's mainframe systems so we've never really been running on what is the true bare metal. PR/SM just adds another bit of functionality to the microcode to allow the hardware to do what VM had been doing for many years, only it can do it even faster. It has been available since 1988 and its VM heritage dates back to the 1960's. The stability comes from decades of development, testing and use.

[zum13]

Second question, is not MVS is what works for zOS and z/VM is separate?

z/OS (and OS/390 before it) is a bundling of MVS with various other bits of software which were originally ordered and charged separately. The MVS bit is the core control program onto which everything else is built. z/VM is a separate product and a very different operating system to z/OS with its own control program. While z/VM can host z/OS guests, read its disks, and even run some of its programs, the reverse is not true.

[Sanjay Mainframe]

I think I'm also confused with the use of z/VM. Sysplex is multiple LPARs, right? And a LPAR is just a single LPAR. Is not that enough definition?

[zum13]

Yes, Sysplex is multiple LPARs working together. When they're not working together, then an LPAR is just an LPAR running an independent system.

z/VM is a separate operating system that will run in its own independent LPAR. It essentially does what PR/SM does without the need to meddle with the machine's hardware configuration (which tends to be disruptive). It gives you the ability to create new virtual machines in a few minutes with some simple commands, plus you can have literally thousands of them configured. IBM is currently marketing it for zLinux as it gives you the ability to fire up new instances at very short notice as and when they are required.