Operating Systems

Many of the familiar guests in the IBM-supplied directory are now multiconfiguration virtual machines, such as MAINT, OPERATOR, and OPERATNS. These are for member-specific maintenance tasks. There are also some guests that are single-configuration virtual machines, such as PMAINT and MAINT620, which are for clusterwide maintenance. The old duties of MAINT, for example, have been split among MAINT, PMAINT, and MAINT620. PMAINT now owns the CF0 parm disk, where the SYSTEM CONFIG resides, as well as the 2CC disk that holds the USER DIRECT and a new disk, 551, that holds clusterwide utilities such as CPFMTXA and
DIRECTXA. MAINT620 owns all the Release 6.2.0 service disks. MAINT still has disks such as the 190 disk for CMS and the CF1 parm disk for CPLOAD so CMS and CP service can be put into production independently on each member.

Guest Administration and Automation

Administrators can have a view of cluster operations and monitor users on all four members at once. The new AT command allows privileged commands to be issued on any cluster member (e.g., AT MEMBERA CMD XAUTOLOG LINUX01), making writing automation easy. Commands such as MESSAGE, WARNING, and SMSG as well as Inter-User Communication Vehicle (IUCV) connections can transparently reach a target single-configuration virtual machine anywhere in the cluster. These interfaces also support an AT member operand or equivalent to target a specific instance of a multiconfiguration virtual machine explicitly. Some commands also accept an AT ALL operand, allowing them to broadcast or collect information across the cluster. QUERY NAMES, in particular, can now show various views of the guests across the cluster. A simple QUERY NAMES command shows all guests on the member on which it’s issued and the single-configuration virtual machines clusterwide.

Figure 7 shows sample QUERY NAMES output. In contrast, QUERY NAMES AT ALL (Figure 8) shows all guests on all members, with each line prefaced by the member name.

Cross-system use of the Single Console Image Facility (SCIF) is also supported in an SSI cluster. Single-configuration virtual machines may use the SET SECUSER, SET OBSERVER, and SEND commands to communicate with other single-configuration virtual machines no matter where they are. Multiconfiguration virtual machines may only “see” other users on the same member through SCIF. There’s a new AT operand on the SEND command to let you send commands and console input to multiconfiguration virtual machines on other members. SCIF assignments also persist across relocations, so if a Linux server has OPERATOR as its observer, the Linux guest's console will automatically be transferred to the instance of OPERATOR on the destination member after relocation. This cross-system SCIF capability can be useful for automation and console
consolidation.

Guest Relocation

The infrastructure of comprehensive sharing that SSI provides makes moving workload around the cluster a snap. The industry uses the term “virtual server mobility” for this feature, and distinguishes two kinds: static and dynamic. These capabilities can be used to rebalance workload across the cluster, or to evacuate work from a member that must be shut down for service.

Static mobility means shutting down a guest on one hypervisor and bringing it up on another. In z/VM terms, this is simply a logoff and logon. (For Linux guests, the SIGNAL SHUTDOWN or FORCE command can be used rather than LOGOFF to trigger Linux to quiesce and checkpoint its filesystems.) Since both virtual machine definitions and the virtual machine's devices and data are accessible throughout the SSI cluster, moving the guest in this way is a trivial matter.

Dynamic mobility, or LGR, provides a greater technical challenge, but again, SSI is up to the task. The LGR support in z/VM 6.2 allows a running Linux guest to be moved from one SSI member to another. z/VM delivers relocation functionality with the same high level of quality expected from System z. CP does extensive checking to ensure that all the guest's resources are available on the target member and these checks are repeated several times throughout the process to ensure no loss of function, post relocation.

Additionally, z/VM has introduced the new concept of domains, a group of member systems among which a guest may relocate freely without fear of losing facilities or features. This capability lets SSI clusters stretch across different levels of hardware or software and even allows for non-disruptive upgrades of guests.

Further discussion of LGR and relocation domains will appear in a future issue of z/Journal.

Conclusion

For 40 years, customers have turned to mainframe virtualization to handle ever larger and more diverse workloads flexibly and efficiently. The z/VM SSI feature continues this tradition, bringing to bear a host of capabilities to spread work across multiple z/VM member systems. Building on
System z's "share everything" model, SSI allows uniform access to virtual server resources throughout the cluster, under controls that ensure the data integrity System z customers expect. Multi-system installation, a shared service repository, and tools for single point of control and au-tomation can substantially reduce the administrator's burden in maintaining the cluster. Static and dynamic guest mobility let you move work at will to optimize performance or to preserve
application availability through planned system outages. With SSI, horizontal growth becomes a simpler, easier option for z/VM customers.

 

 

 

4 Pages