One of the aspects of both availability and scalability of a clustered solution such as Parallel Sysplex cluster is that clients and the IP network should know as little as possible about the internal make-up of the cluster in terms of individual nodes and application instances. z/OS has made continuing improvements in TCP/IP to exploit Parallel Sysplex technology, evolving toward a true cluster IP server and distributed application platform.

Virtual IP Addresses, or VIPAs, are IP addresses that are independent of any particular network interface. To an external router or other TCP/IP stack, a VIPA appears as simply an address (or a subnet) that is reachable via the hosting stack. When a z/OS TCP/IP receives an IP packet whose destination is a VIPA that it supports, the packet is merely routed up the stack to the upper-layer protocol (TCP, UDP, or raw socket) as with any other IP packet to an address of a physical link hosted by the stack. VIPAs are advertised via static routes or dynamic routing protocols just as with any other IP address. The benefit of using a VIPA as an application address on a z/OS TCP/IP with multiple physical links, however, is that a failure of any one link will not disrupt connectivity to the application. As long as there is a network path from a remote client to the TCP/IP hosting the VIPA and the server application, the client and the server application can interact uninterrupted. A VIPA thus provides independence from any particular adapter, but is still for the most part tied to a particular TCP/IP stack.

DNS/WLM: The z/OS Workload Manager (WLM) enabled Domain Name Server, provides standard name resolution services (converting a name into an IP address) for IP applications in the Parallel Sysplex cluster. z/OS TCP/IP stacks register their IP addresses with WLM. Application instances register themselves under a generic application name (similar to SNA Generic Resources). The DNS/WLM associates the IP addresses with application names as appropriate. When a resolution request for an application name arrives, DNS/WLM consults the z/OS WLM to determine which TCP/IP the request should be routed to balance the workload appropriately. If a client resolves the same name again, a different IP address may be returned if relative available capacity among the server instances has changed. As long as clients in the network resolve the name each time, and do not cache the IP address from a previous request, the workload will be balanced among the available server applications according to relative available capacity. Work may thus be spread across the cluster, Parallel Sysplex cluster presents the appearance of a single platform to well-behaved client applications.

Network Dispatcher works with a “cluster IP address”, rather than with name resolution. Network Dispatcher (and the similar function in the Cisco Multi-Node Load Balancer, or MNLB) is an external entity adjacent to the Parallel Sysplex cluster. An agent in the sysplex communicates workload capacities of the nodes hosting the application to the Network Dispatcher node. The Network Dispatcher advertises ownership of the cluster IP address (application IP address) to the routing network. When a new TCP connection request arrives, Network Dispatcher consults the most recent capacity information received from the WLM agents, selects the appropriate TCP/IP for this request, and forwards the request over the direct link to the selected stack. For selected applications such as Web serving, an application advisor function in the Network Dispatcher will periodically query the application to be sure it is available and responding, to ensure that requests are routed only to functioning server applications. Clients thus see a network presence represented by a single IP address, and the servers that make up the processing that backs up the cluster address are hidden from the clients.

Dynamic Virtual IP Addresses 
Since VIPAs are not associated with any physical link, there is no particular reason that a VIPA should be associated with one and only one TCP/IP in the sysplex. If a TCP/IP or its hosting operating system suffers an outage, access via the physical links and their associated IP addresses is lost. However, a VIPA may be moved to another TCP/IP manually or via automation, and dynamic routing protocols may be used to notify the routing network of the new location of the VIPA without additional manual configuration change in the routers.

VIPA Takeover: Dynamic VIPAs can be activated either continuously or on demand from an application. Other TCP/IPs in the sysplex may also be configured as backup for a continuously active Dynamic VIPA, such that the Dynamic VIPA is automatically activated on a backup stack whenever the normally owning TCP/IP suffers an outage. The client can very quickly establish a new connection to the backup stack.

As an added benefit, if the backup stack receives client traffic for a connection to the no longer available stack, the backup stack will immediately notify the client that the connection has been terminated, and the client will not have to wait for normal TCP time-outs to discover the connection outage.

Contact an IBM Sales Specialist

Browse z Systems


Infrastructure matters. Businesses turn to the IBM mainframe for unmatched security, operational efficiency, speed, seamless scale, and lower cost per transaction. The IBM z System, the world’s premier data and transaction engine, is enabled for mobile, integrates transactions and analytics, and delivers efficient and trusted clouds.