In the early 1990s, the business world went through a period of significant change with many new pressures being applied to the business. The Parallel Sysplex architecture was able to address each of these concerns.
Corporations when through a period of dynamic growth as the economy boomed and companies bought out each other. Many were coming to a point where they needed to move applications to other servers to get space for growth, but the capacity requirements of individual applications were approaching the size of the largest servers. There would come a point where there would be no room to grow.
Parallel Sysplex allows up to 32 LPARs on up to 32 servers to run the same application in data sharing mode, each with direct read/write access to the data. It is now possible for a single production workload to run on these multiple servers with each instance accessing and updating the same database with data integrity and serialization being provided by the database manager working with the Coupling Facility.
As a workload expands to multiple servers, scalability is maintained by the design of the architecture. With 99.5% scalability, a Parallel Sysplex obtains near-linear growth from a two to a 32-way configuration.
With business pressures, especially from the internet, it was no longer acceptable to have a period of planned outages such as on Saturday midnight. This was problematic since planned maintenance for hardware and software was still needed. In addition, it application changes continue to put end-user availability at risk.
Since a Parallel Sysplex can have multiple LPARs on multiple servers, a z/OS image can be always available. With dynamic workload routing, new work requests will flow to the systems that are available, with end-user availability maintained. Dynamic workload routing can be done in a number of ways. At the network level network routers with help from the z/OS Workload Manager (WLM), Virtual IP Addressing (VIPA) takeover capabilities, Sysplex Distributor, or VTAM Generic Resources can be used. At the transaction level, CP/SM, IMS Shared Message Queues, or WebSphere MQ Shared Queues can be used. All this is isolated from the end user. In addition, work will flow to the system with the most capacity, to provide the user with the best response times. With a goal of no single points of failure, a Parallel Sysplex is designed to obtain 99.999% availability.
As the data centers grew to multiple servers, it became necessary to monitor and control each of the operating system images. Going from one to two servers, data centers did not want to double the amount of support staff. There is a need to manage these multiple images as a single image, both at the Operations and Systems level.
Parallel Sysplex accomplishes this by providing techniques for "cloning" subsystems and using system symbolics. These allow a definition change to be made once and get reflected on multiple instances, or an operator to issue a single command that can go to one or multiple LPARs. It is common for sites grow from a single to multiple servers in a Parallel Sysplex without having to grow the operations and support staff.
Total Cost of Ownership
Many consultants were saying that the (air-cooled) Unix servers were cheaper on a price / MIPS basis. IBM countered by pointing out that when not just hardware, but software, people, and data center costs are factored in, the "mainframes" still continue to have significantly better price performance. Still, this issue needed to be addressed. In addition, there was a desire to reduce not just the hardware costs, but also software costs on the mainframe environment.
IBM addressed this concern by creating an air-cooled Complimentary Metal Oxide Semiconductor (CMOS) chip that can run the S/390 architecture. An issue is that this chip ran about 10x slower than the current BiPolar technology chip.
By having multiple CMOS servers running the same application, it is possible to provide more capacity than what was available on the BiPolar servers. With the CMOS servers using significantly less space and power to run than BiPolar, this provided a significant improvement in server cost. This strategy was proven as CMOS chip capacity grew faster than what BiPolar capacity could grow, and quickly surpassed the BiPolar server capacity, even if IBM had continued to invest in it.
IBM followed this up with Parallel Sysplex Licensing Charges (PSLC) for improvements in software fees. Details on PSLC can be found here.
Additional value of Parallel Sysplex can be obtained by using Resource Sharing. This is a technique for using the Parallel Sysplex not just for application data sharing, but to help with performance, system management, or reduction of hardware resources. Some Resource Sharing exploiters can be found here.