10.1 Communication methods under z/VM
One advantage of consolidating servers on the mainframe is the elimination of physical network interconnections between virtual servers. Replacing the physical cabling with memory buses inside the machine also improves the data rate and lowers the latency. In zSeries servers, a high-speed interconnection for TCP/IP communication (HiperSockets) enables TCP/IP traffic to flow directly between partitions. HiperSockets exploit the "network in a box" concept that transmits LAN-type data at near memory speeds.
The z/VM computing model, with multiple operating systems each running applications as separate guests, yet with a need to communicate among themselves, naturally led to thinking of a mainframe system as an extensive network of cooperating virtual nodes. This was the springboard to the early development of mechanisms for communicating between virtual machines, managing such communications, and ensuring the integrity of the system's data in such an environment. In fact, because this computing model required an architecture where one virtual machine requested some system service of another virtual machine, VM could be considered the first implementation of a client/server architecture. This natural affinity between the virtual machine computing model and today's network computing model makes z/VM an ideal infrastructure for network-connected Linux systems.
z/VM offers options for communication among virtual servers that greatly reduce complexity. A "virtual network cable" is nothing more than a Control Program service that transfers data from one memory location to another, making the communicating virtual server images believe that they are sending and receiving data over a real network connection. Memory-to-memory data transfers are fast, and they get faster as processor speeds increase. Upgrade to a faster real processor, and the data transfer rate of your virtual network automatically increases in speed.
z/VM provides several types of communication. However, the ones you will probably use in a Linux-on-the-mainframe environment, besides the real connection to the Internet or intranet, are virtual channel-to-channel adapter (CTCA), virtual Network Interface Cards (NICs), and Guest LANs.
10.1.1 Virtual CTCA
Channel-to-channel (CTC) communication was developed before today's high-speed networks. Originally, CTC simply enabled two S/360 or S/370 processors to communicate using a special protocol called CTCA. The processors used channel paths for the connection to replace, for example, communication over a telephone line. In other words, CTC is a point-to-point connection. A CTC connection is considered a secure communication path, because it involves only two parties directly connected only to each other through a channel path that is entirely on the secure raised floor.
Today, a real channel-to-channel adapter is a common method used to interconnect pairs of mainframe systems. z/VM has virtualized this connection. z/VM provides the ability to define virtual channel-to-channel adapters, which can be useful in connecting virtual machines running the CTCA protocol without requiring real CTCA hardware. The virtualization makes a CTC faster. In a Linux-on-the-mainframe environment, this is useful in connecting Linux guests to other guests, such as VSE/ESA, or z/OS. Virtual CTCAs can also be used to connect Linux guests to each other.
Although virtual CTC lets you establish point-to-point connections between pairs of images, it might be more practical to use Guest LANs when many images need to communicate.
10.1.2 Network in a box: NIC and Guest LANs
z/VM Version 4 includes support for virtual NICs. NICs are used to connect to a local area network (LAN). Specific NIC protocols supported by z/VM include HiperSockets and OSA-Express QDIO mode. Real HiperSockets are used to connect server images in separate LPARs on a HiperSockets LAN. z/OS, VSE/ESA, Linux on zSeries, and z/VM all support the HiperSockets protocol. Like a real HiperSockets connection, virtual HiperSockets are used to connect server images in virtual machines, but data are transferred at near memory speeds. The same is true for virtual QDIO connections. Virtual HiperSockets and virtual QDIO NICs are used to connect a guest to a "virtual LAN" a LAN totally inside z/VM.
In z/VM Version 4, these virtual LANs are referred to as Guest LANs. A server image running on z/VM can connect to a Guest LAN using virtual HiperSockets or queued direct I/O (QDIO) NIC. Virtual HiperSockets and QDIO connections look just like the "real thing" to a Linux server or to any other software that supports the real connections. Unlike the real thing, however, there is no limit on the number of virtual HiperSockets or QDIO connections that can be defined in a z/VM environment. And there is no predefined limit on the number of Guest LANs that can be created.
Guest LAN support eliminates some of the point-to-point network management challenges that exist when using virtual CTCA while providing almost all the value. A Linux server connected to a Guest LAN can communicate with other virtual machines connected to that LAN (see Figure 10-1). Unicast, multicast, and broadcast communications are possible with a Guest LAN. (OSA Express Guest LANs support unicast, multicast, and broadcast. HiperSockets Guest LANs support unicast and multicast.)
Figure 10-1. A Guest LAN connects z/VM guests
z/VM is designed to enable virtual NICs and Guest LANs on mainframes that do not support real HiperSockets, such as the IBM 9672 G5/G6 models and the Multiprise 3000. This enhances the virtual networking environment on those machines, while letting companies prepare for a real HiperSockets environment before moving to a zSeries server.
There can be "system" Guest LANs and Guest LANs that are associated with a specific z/VM guest (for example, a Linux image). System Guest LANs exist independently of any active, logged-on guest, while Guest LANs associated with a guest exist only as long as the guest is active.
For example, assume ISPCompany (as an ISP and outsourcing provider) has a client that has six servers. ISPCompany can host these six servers on a mainframe and map the real LAN that connected the servers to a Guest LAN on the mainframe (see Figure 10-1).
While connected to a Guest LAN, a Linux server can also connect to a real HiperSocket connection and communicate with other servers in a different LPAR on the same mainframe. This offers companies a way to route Guest LAN traffic to another LPAR without requiring each Linux image on the Guest LAN to access a real HiperSockets connection. For example, in order to let one Linux server communicate with the back-end z/OS, StoreCompany uses a real HiperSockets connection (Figure 10-2).
Figure 10-2. HiperSockets connect a Linux server to an image on another LPAR
10.1.3 The value of HiperSockets for Linux
Many data-center environments today have multitiered server applications that include middle-tier servers surrounding a zSeries data and transaction server. Connecting this multitude of servers requires the complexity and cost of many networking components. Furthermore, the performance and availability of interserver communication depend on the performance and stability of this set of connections.
Consolidating this middle-tier workload as multiple Linux virtual servers on a zSeries machine requires a very reliable, high-speed network over which these servers can communicate. zSeries HiperSockets provide this. In addition, these consolidated servers also have direct high-speed access to database or transaction servers running under z/OS on the same zSeries machine.
The left side of Figure 10-3 shows a server farm surrounding a zSeries machine with its corporate data and transaction servers on z/OS.
Figure 10-3. An overview of server consolidation based on Linux
The right side of Figure 10-3 shows a Linux-based server consolidation on a zSeries machine. Servers can communicate on the zSeries machine via HiperSockets. In addition, the network connection for all servers is concentrated over a few high-speed OSA-Express interfaces.