Networking Implications of S/390 Parallel Sysplex
By Rachel Pickering (rachel_pickering@uk.ibm.com)
The S/390 Parallel Sysplex configuration provides many benefits to the
large mainframe environment, including high availability, workload balancing,
scalable growth, reduced cost of computing and investment protection of
current applications . This article discusses the networking implications
of Parallel Sysplex, especially focusing on applications where high availability
and workload balancing are required. It addresses the requirement for APPN/HPR
and shows that TCP/IP now implements many of the Parallel Sysplex functions
that were initially available only for SNA.
Overview
The S/390 Parallel Sysplex configuration is based on an advanced form of
clustering technology. A S/390 Parallel Sysplex can be built using the
older ES/9000 511 or 711 processors, or the latest S/390 CMOS-based Enterprise
Servers. The maximum number of systems that can be configured in a Parallel
Sysplex today is 32.
The S/390 Parallel Sysplex is different from other clustering implementations
in two important areas:
- MVS Workload Manager (WLM)
- Data sharing architecture, implemented using the Coupling Facility
The Coupling Facility is a new processor for the Parallel Sysplex configuration,
which is used to store system information such as lists and database locks.
It is usually configured on a separate hardware device (IBM 9674), although
it can reside in a logical partition of a CMOS processor.
Workload Manager (WLM)
The WLM is a component of the OS/390 operating system that resides on every
system in the Parallel Sysplex. It manages the resources of the Parallel
Sysplex and replaces the fixed scheduling that was used in earlier MVS
releases. The WLM "self-manages" the Parallel Sysplex by dynamically adjusting
workload priorities. The priorities are based on service levels or goals
that you set.
Data-Sharing Architecture
The data-sharing architecture allows concurrent access to shared system
and user data from all the systems in the Parallel Sysplex. This allows
workload to be balanced between many systems, instead of allocating work
to the server where the data resides. The shared system and user data is
kept in the Coupling Facility, which is a new CMOS-based hardware processor.
Benefits of S/390 Parallel Sysplex
There are many benefits of the S/390 Parallel Sysplex, including:
- High availability, providing a high level of service to users and enabling
24x7 availability
- Workload balancing, providing automatic and dynamic balancing of user and
system workloads among the systems of the Parallel Sysplex
- Data sharing, enabling timely access to corporate data for multiple users
- Sharing of other system resources such as tapes, a RACF database, JES SPOOL,
and so on
- Planned maintenance, ensuring new functions, hardware and software can
be tested with no disruption to user service
- Unplanned maintenance, to enable problem fixes to be applied with no disruption
to service
- Data center backup using the Geoplex¹ concept
- Cost savings on software using the Parallel Sysplex Licensing Charge (PSLC)
option
- Granularity, allowing new systems to be added easily
without major upheaval and with no disruption to service
- Scalability -- you can now support applications that
can run on the smallest 9672 machine or on the very largest Parallel Sysplex
without modification
You can implement different levels of the configuration. For example, it
is possible to implement a single operational image, and get the benefits
of shared tape drives, a single RACF database and single point of control
for problem, change and performance management. Or you may wish to implement
full data sharing and workload balancing and get all the benefits of high
availability and a single system image for the end user.
Networking Functions Supporting the Parallel Sysplex
When the Parallel Sysplex was first implemented, most the networking functions
were provided for SNA applications. This ensured that traditional or "legacy"
applications could participate in workload balancing and high availability.
TCP applications could reside in the Parallel Sysplex, but not make use
of the facilities. Recently, however, support for TCP applications has
been provided, so that TCP applications (such as a S/390-based Web server)
can not only reside in the Parallel Sysplex, but can also benefit from
the technology.
For SNA applications, there are two functions that are unique to the
Parallel Sysplex:
- Generic Resources, which provide load balancing for SNA applications
- Multi-Node Persistent Sessions, which provide high availability for SNA
applications
In addition, there are other functions relevant to SNA applications that
are not unique to the Parallel Sysplex environment, but which are important:
- Use of APPN inside the Parallel Sysplex to reduce system definitions and
enable scalability
- Enterprise Extender, which allows SNA applications to be carried over an
IP backbone network
- TN3270E Server, which provides an alternative solution to supporting SNA
applications over an IP backbone network
For TCP applications, three functions are discussed here:
- Virtual IP Addressing (VIPA) , providing an availability
enhancement for access to TCP/IP on the S/390
- Domain Name Server (DNS), which provides a solution to workload balancing
for traditional business applications
- Network Dispatcher, which provides an alternative solution for workload
balancing for applications such as Web servers
Generic Resources
Generic Resources (GR) is the VTAM function that provides
workload balancing for SNA applications. This function was first shipped
with VTAM V4R2. The IBM subsystems that support generic resources include:
CICS, IMS, TSO, DB2 and APPC/MVS.
Using this function, the end user logs onto a generic subsystem name
and the session is set up with a real subsystem instances on one of the
Parallel Sysplex systems. The end user will have no knowledge of the real
subsystem name. For example, in the CICS environment, the end user could
logon on with a name CICS, and the real terminal owning region could
be CICS2 on VTAM2 today or CICS4 on VTAM4 tomorrow, depending on workload.
The load balancing is done by one of the VTAM network nodes inside with
Parallel Sysplex. VTAM uses the services of the Workload Manager to get
information about the utilization of
resources on each system in the Parallel Sysplex. Additional information
is taken from the Coupling Facility to assist in determining whether a
session has affinity with a specific subsystem name. Using the information
from the WLM and from the Coupling Facility, VTAM then chooses the appropriate
subsystem instance to send the logon request. Then the user session is
set up in the normal way.
From the networking point of view, we need to understand that VTAM is
using APPN protocols inside the Parallel Sysplex to support the Generic
Resources function. Typically this means that one or two of the VTAMs will
be set up as APPN network nodes, and the remaining VTAMs will be set up
as APPN end nodes.
Using Generic Resources does not require APPN to be used in the network,
and in fact no network changes are required at all. However, to get optimum
routing into the Parallel Sysplex, it is recommended that the gateway between
the network and the Parallel Sysplex uses APPN.
It is perfectly possible to run and operate subarea
SNA protocols in the network and use APPN inside the Parallel Sysplex and
on the network gateway. All LU types are supported in this configuration.
For example, the network could continue using subarea SNA protocols with
3174 controllers and 3270 applications, but the VTAM systems inside the
Parallel Sysplex could use the latest APPN releases, in which case most
applications would be supported. If the network² gateway is a 3745/46 under
the control of the NCP, then VTAM performs conversion between the APPN
and subarea SNA protocols. If the network gateway is an APPN network node
such as the 2216 or the 3746-900, then the dependent LU requester (DLUR)
function is used to support the subarea network.
Multi-Node Persistent Sessions (MNPS)
Multi-Node Persistent Sessions (MNPS) provides high availability for SNA
applications. This function was first shipped with VTAM V4R4 and the only
IBM subsystem that supports it today is CICS.
Using MNPS, sessions can be restarted on another system in the Parallel
Sysplex after hardware or software failure. Information about the sessions
is stored inside the Coupling Facility and VTAM uses the information to non-disruptively restart the sessions. This
greatly reduces the network restart time after failure, which can be a
major component of recovery time in non-Sysplex environments.
The figure shows an example where it is assumed that the OS/390/VTAM4
system has failed. The sessions connected to CICS4 can be moved non-disruptively
to OS/390/VTAM2. In the CICS environment, there will be a slightly longer
response time because the user will be returned to the CICS signon screen.
All the sessions are kept active using information stored in the Coupling
Facility.
VTAM uses APPN/HPR inside the Parallel Sysplex to support the MNPS function.
High-Performance Routing (HPR) is an extension to the APPN architecture
and is provided on many platforms today. In the general case, HPR is used
to non-disruptively switch traffic around failed nodes or links in the
network. In the special case of MNPS, the HPR endpoint itself is moved
from one VTAM node to another one inside the same Parallel Sysplex. Although
it is possible to use HPR purely inside the Parallel Sysplex for the MNPS
function, it is strongly recommended that the APPN/HPR function move further out into the network
As a minimum, it is recommended that you make the gateway between the
network and the Parallel Sysplex APPN/HPR-capable. If this is not possible,
then the end user sessions must be routed through one of the VTAM network
nodes inside the Parallel Sysplex, using unnecessary resources and adding
an additional hop to the path of the sessions.
If it is possible to move the HPR function right out to the end user,
then high availability can be achieved end-to-end. This means that if any
component fails, whether it be in the network, or the network gateway,
or hardware or software inside the Parallel Sysplex, the session can be
recovered non-disruptively. This enables you to achieve true 24x7 availability,
if required.
Using APPN Inside the Parallel Sysplex
If Generic Resources or Multi-Node Persistent Sessions are not used, there
is no requirement to use APPN inside the Parallel Sysplex. However, there
are advantages in doing so, and many sites start by implementing APPN first
and then adding the other functions later.
Using APPN inside the Parallel Sysplex brings the following advantages:
- Reduction of SNA system definitions
- Removing the requirement to coordinate definitions with other nodes
- Removing the requirement to update other VTAM and NCP definitions when
adding a new system into the Parallel Sysplex
- Easing change management because there is no impact on other nodes when
adding a new system
There is another system facility that is always recommended inside the
Parallel Sysplex -- the concept of cloning. This
allows a single set of software to be built once and used for each system
inside the Parallel Sysplex. When you add a new system, symbolic substitution
is used to dynamically tailor the standard software to build the specific
resource names for the new system. This greatly reduces the workload required
to manage the operating system software. If the VTAM systems are defined
using APPN rather than the subarea SNA definitions, then cloning will be
much simpler and most of the VTAM definitions can be cloned.
Using APPN/HPR Outside the Parallel Sysplex
One question that is frequently asked is:
"I've heard a lot about APPN in the Parallel Sysplex environment.
Does this mean that I must migrate my network to APPN to exploit the Parallel
Sysplex?"
The answer is definitely no. However,
there can be many advantages in doing so. If you are looking to implement
a high availability configuration for SNA applications, it makes a lot
of sense to use APPN/HPR as far out into the network as possible. This
is true whether or not you are using MNPS. Even if your network is based
on an IP backbone, it is still possible to achieve high availability with
APPN/HPR by using the Enterprise Extender function.
Enterprise Extender
One of the trends in networking today is the requirement to consolidate
multiple networks into a single multi-protocol network, usually based on
the IP protocol. Using IP in the backbone network is attractive because
of the wide range of other protocols it supports.
However, one aspect of using IP is the consideration of SNA support,
because most of the legacy systems used in Parallel Sysplex configurations
continue to be based on SNA. One of the common techniques for carrying
SNA applications over an IP backbone network is Data Link Switching (DLSw),
which is used by many vendors. However, DLSw has disadvantages in the Parallel
Sysplex environment for the following reasons:
- DLSw does not support HPR, so availability is compromised if you are using
MNPS, or APPN/HPR without MNPS. Switching of MNPS sessions can be done
only inside the Parallel Sysplex, thus incurring an additional VTAM hop
on the session path. End-to-end high availability can never be achieved.
- DLSw uses TCP, which is connection-oriented, so the routers at the edge
of the IP network (where the DLSw conversion is performed) are single points
of failure. If either of these routers fails, then the end-user session
is always disrupted
- DLSw cannot handle the SNA Class of Service, so the performance of SNA
interactive traffic can degrade in a congested IP backbone network
Because of these restrictions, the APPN architecture has been enhanced
with a function called Enterprise Extender, which is an alternative to
DLSw when carrying SNA applications over an IP backbone network. The Enterprise
Extender function is placed in an edge router (as is DLSw) but it uses
a very different technique, which removes the three restrictions of DLSw
explained above.
Instead of using TCP to carry the SNA traffic, Enterprise Extender uses
the UDP protocol. The SNA Class of Service is mapped into a UDP port number
and this port number is carried in the packet header. All routers today
can prioritize the UDP port number and so it is possible
to prioritize SNA even inside the IP backbone network. This means that
no new hardware is required in the backbone network to support Enterprise
Extender.
One key benefit of Enterprise Extender is that is uses APPN/HPR. This
is crucial for the Parallel Sysplex environment where high availability
is required. Using APPN/HPR end-to-end provides the support for non-disruptively
rerouting SNA sessions around failures in the network.
Typically the Enterprise Extender function³ would be placed on the channel-attached gateway/router at the central site and on the remote gateway/router at
the branch. This means that APPN/HPR is used between the channel gateway
and the branch. However, in the high-availability environment, MNPS uses
APPN/HPR as a minimum
inside the Parallel Sysplex. Consequently, the combination of MNPS and
Enterprise Extender extends APPN/HPR from the mainframe out to the remote
branch, even with an IP network. To make this work, the network gateway
between the network and the Parallel Sysplex must also fully support APPN/HPR.
If APPN/HPR is moved further out into the branch workstations, then
you can achieve full end-to-end high availability. Many workstation platforms
today support APPN/HPR, both on APPN network nodes and APPN end nodes.
Finally, the use of APPN/HPR means that the gateways/routers that implement
the Enterprise Extender are not single points of failure. If the nodes
behind the Enterprise Extender nodes support APPN/HPR (for example, VTAM
in the Parallel Sysplex or a Comms Server platform on the workstation),
and if alternative Enterprise Extender nodes are available, then APPN/HPR
will non-disruptively switch traffic around failed gateways/routers. Thus
there are no single points of failure.
For these reasons, the Enterprise Extender function is strongly recommended
when high availability is required for transporting SNA applications over
an IP backbone network in the Parallel Sysplex environment.
The figure shows two examples of SNA sessions using the Enterprise Extender
technology.
- The session on the left shows what can be achieved if all the products
involved in the session path provide the full APPN/HPR support. There is
an HPR connection from the S/390 server in the Parallel Sysplex all the
way down to the SNA workstation, even though there is an IP backbone network.
This configuration provides an excellent solution for SNA sessions using
MNPS for high availability. Assuming that backup nodes and paths exist,
it is possible to bypass any hardware failures in the network or the Parallel
Sysplex and non-disruptively move the SNA session to a new path. There
are a number of assumptions here:
- The S/390 servers in the Parallel Sysplex support both HPR RTP and the
MNPS function.
- The remote workstation supports the HPR RTP endpoint function.
- The Enterprise Extender function is required in the remote router and on
the channel-attached gateway (or on the S/390 using a future release of
Communications Server/390).
- Routers in the IP backbone network must provide UDP port prioritization.
- The session on the right shows the minimum configuration for Enterprise
Extender. This configuration can support the transport of SNA applications
over the IP backbone network without providing full end-to-end HPR support
for high availability. Part of the LU session is carried over an HPR connection.
The rest of the session is routed using subarea SNA or APPN routing.
TN3270E
Another common technique for carrying SNA applications over an IP backbone
network is TN3270E. This is applicable when the end user has only a TCP/IP
stack on the workstation. The end user will have a TN3270E client function
in the workstation software and this connects over an IP network to a TN3270E
server function. The TN3270E client provides a 3270 appearance to the end
user. The TN3270E server function takes the TCP connections from the TN3270E
clients and maps them into SNA sessions. Then the SNA sessions are carried
over an SNA backbone network in the normal way.
When using TN3270E as a technique to transport SNA sessions over an
IP backbone network, one key consideration is where to place the TN3270E
server. There are four possible locations:
- On the S/390 with the TN3270E server provided by TCP/IP in OS/390. This
means that the SNA-to-TCP conversion will be done on the S/390. All network
traffic across the channel will be carried as TCP/IP.
- On the channel gateway. The SNA-to-TCP conversion is done on the gateway
box. All network traffic across the channel will be carried as SNA. TCP/IP
is used from the gateway out to the network and the remote client.
- At the local site, on a LAN-attached server device. The SNA-to-TCP conversion
is done on this separate TN3270E server hardware. All network traffic from
this TN3270E server, across the LAN to the channel-attached gateway and
up the channel to the S/390, will be carried as SNA. TCP/IP is used from
the server out to the network and the remote client. One example of a TN3270E
server that provides this function is the recently announced Network Utility
device. Typically, these local TN3270E servers are Token-Ring-attached
to a 3745/3746 controller.
- At a remote site, which is typically the branch concentrator
or router. In this configuration, SNA sessions are used from the S/390
out to the remote TN3270E server, and then TCP/IP is used from the server
across the LAN to the TN370e client.
The figure shows an example of the fourth option, using a remote TN3270E
server. Note that the backbone network uses SNA, and TCP/IP is used only
at the remote site.
Using TN3270E as a technique to carry SNA traffic can be enhanced by
the combination of TN3270E and the Enterprise Extender function. If the
requirement is to have the TN3270E server at the remote branch, and an
IP backbone network, then TN3270E and Enterprise Extender together provide
a unique solution. This solution not only prioritizes the SNA through the
IP backbone, but also supports HPR right out to the TN3270E server. This
will provide the highest availability for the Parallel Sysplex configuration.
The figure shows what can be achieved using this combination of TN3720e
and Enterprise Extender:
- The session on the left uses an HPR connection from the S/390 to the remote
Enterprise Extender node. This session supports MNPS for high availability.
- The session on the right uses HPR between the Enterprise Extender nodes.
In both cases, SNA applications are carried over an IP backbone to a remote
TN3270E server.
Virtual IP Addressing
Virtual IP addressing (VIPA) support, which was originally
shipped in TCP/IP V3R2 can improve availability to the S/390 server. Although
it is not unique to the Parallel Sysplex, it does allow fault-tolerant
connections to the S/390 to be defined for TCP applications. By defining
a virtual IP address that is mapped onto a number of real physical interfaces,
VIPA allows one physical interface to be backed up in case of failure.
Examples of physical interfaces that could use VIPA are the 3746, 2216,
3172 and S/390 OSA-2.
Domain Name Server
With the emergence of more IP-based applications, many networks now have requirements to provide functions similar to those
that are already available for SNA applications in the Parallel Sysplex.
Domain Name Server (DNS) is used in IP networks to convert user-friendly
application names into IP addresses. The DNS implementations in many products
today provide a round-robin technique for workload balancing. This is satisfactory
for clusters of small systems, but does not give any feedback, which is
advisable for workload balancing in a Parallel Sysplex.
The DNS in the latest TCP product (shipped as part of OS/390 V2R5) provides
an additional level of support based on the Workload Manager (WLM).
Just as VTAM Generic Resources takes input from WLM for workload balancing
SNA applications, the DNS can now provide the equivalent function for TCP
applications. This enables TCP connections to be balanced among the different
servers in the Parallel Sysplex based on the usage of system resources. Whenever a S/390 DNS is required, it
is recommended that OS/390 V2R5 be used. Only this version of the DNS can
provide the high level of support required for the Parallel Sysplex.
Network Dispatcher
There is an alternative solution for balancing Web server type application
traffic, based on the Network Dispatcher. This function, which resides
in the network gateway, provides load balancing between the IP hosts in
the Parallel Sysplex. It also takes input from the Workload Manager and
thus can provide balancing based on timely information about the usage
of system resources. This technique is useful if the OS/390 DNS cannot
be used for any reason.
This function is not unique to the Parallel Sysplex but in this environment
additional benefits can be gained because of the input from the WLM. It
is especially recommended for load balancing between Web servers in the
Parallel Sysplex, because of the high connection rate that it supports.
Networking Considerations
From the discussion up to now, it is clear that the choice of gateway depends
very much on the extent to which the customer has decided to implement
the Parallel Sysplex configuration. This section summarizes the networking
considerations and the following section gives an overview of the gateway
products used to connect the network to the Parallel Sysplex.
Network Support for SNA Applications
The main networking consideration for SNA applications is the extent to
which APPN and/or APPN/HPR is used in the network or the network gateway.
This can be summarized as follows:
- A product that does not support the APPN/HPR RTP endpoint function. Examples
include the IBM 3172 running ICP and some OEM routers.
- A product that does support APPN/HPR, but which cannot support HPR's ANR
routing. An example of this is an OEM router that does not provide support
today for ANR routing across its ESCON channel.
- Gateway 2 provides the APPN/HPR support required for MNPS, including
both the RTP endpoint and ANR routing, but the network does not support
APPN/HPR. Session 2 can be switched non-disruptively between the S/390
and the gateway, but recovery from network failures will be disruptive.
There are two main configurations where this is applicable:
- The network is based on subarea SNA and there are no plans to migrate to
APPN/HPR or TCP/IP.
- The network is IP-based with no possibility of using Enterprise Extender.
This could be because the TN3270E server is implemented on the gateway
itself, or because the remote router does not yet support Enterprise Extender,
or because DLSw (or an equivalent) is used to carry the SNA traffic.
- Gateway 3 also provides APPN/HPR support for MNPS and this time,
there is support for APPN/HPR across the network. This can be implemented
using either a native APPN/HPR backbone network or an IP backbone network
using the Enterprise Extender function. Examples of product
implementations are the 3745/46 family of products and the 2216. There are two possible
MNPS configurations here:
- The remote concentrator or router supports APPN/HPR, but the remote workstation
does not. This situation is represented by session 3 in the figure. Nondisruptive
session switching can be done between the S/390 in the Parallel Sysplex
and the remote gateway.
- Both the remote concentrator/router and the remote workstation support
APPN/HPR. Session 4 provides the optimum high availability solution for
the Parallel Sysplex.
Network Support for TCP Applications
The main networking consideration for TCP applications today is the type
of transaction in use:
- If there is a requirement for workload balancing for long-lived connections
such as TSO, TN3270E, CICS, IMS or FTP, then use the DNS in OS/390 R5.
- If there is a requirement for workload balancing for short-lived connections
such as Web servers or Domino, then use the Network Dispatcher function
on the network gateway.
Both of these techniques use information from the WLM while doing workload balancing. Thus using either solution will
ensure the best use of the Parallel Sysplex resources.
Other Considerations
In addition to the functions discussed above, there are many other considerations
when selecting a network gateway, such as:
- Cost of ownership of the hardware and software
- Impact on S/390 resources (in particular VTAM cycles)
- Existing installed equipment
- Network management
- Ease of design and configuration
Product Overview
There are a number of products that can act as gateways to the S/390 server. These include:
- 3745 Communication Controller
- 3746 Nways Multiprotocol Controller
- 2216 Nways Multiaccess Connector
- 3172 Nways Interconnect Controller
- S/390 Open Systems Adapter 2 (OSA-2)
- RS/6000 Server
- 8265 Nways ATM Switch
- 3174 Network Processor
- OEM routers
In this article, we consider only the four main solutions from IBM, although
in some environments the other products may also be appropriate.
3745/3746 Communication Controllers
The 3745/3746 family of communication controllers provides a full range
of networking functions, especially when acting as gateway to the S/390
server. In the Parallel Sysplex environment, the requirements for high
availability and load balancing are met in different ways by the products
in the family, and so each is discussed separately here.
3745 Communication Controller
The NCP running in the 3745 provides support for both SNA and TCP applications.
For SNA applications, both subarea SNA and APPN/HPR are supported. The
3745 supports WAN and some LAN adapters.
Where APPN is required, the 3745 provides support for access to the
Parallel Sysplex using APPN support provided in the NCP and VTAM:
- NCP V6R2 and higher, along with VTAM V4R2, provide support for APPN and
GR.
- NCP V7R2 and VTAM V4R4 provide support for APPN/HPR and MNPS.
Where APPN/HPR is required, noted that NCP provides HPR/ANR routing only,
and not the HPR/RTP endpoint function. This means that, to use NCP in a
MNPS configuration, you must either:
- Provide an RTP endpoint further out in the network (for example, in a remote
router or controller), or
- If this is not possible, use HPR only inside the Parallel Sysplex, which
means that one of the VTAM nodes provides the RTP endpoint.
For TCP applications, the NCP provides an IP router for access to the Parallel
Sysplex. Although the Network Dispatcher function is not supported, workload
balancing can be done by the Domain Name Server provided by OS/390. nodes.
For a high volume of TCP/IP traffic, it is advisable to consider solutions
based on the 3746, because NCP cannot support high IP throughput rates.
3746-900 Nways Multiprotocol Controller
The 3746 supports a wide range of LAN, WAN and ATM adapters. It provides
the complete set of functions required for access to the Parallel Sysplex.
It provides NCP or APPN/HPR support for SNA applications and serves as
a full-function IP router for TCP.
The 3746-900 supports three different APPN configurations:
- APPN network node provided by the NCP and VTAM
- APPN network node provided by the Network Node Processor (NNP)
- APPN network node provided by the Multiaccess Enclosure (MAE)
Providing NCP support is an important consideration for the 3746, because
many customers do still use the NCP and wish to access the Parallel Sysplex
without major network expense (at least initially). The NCP requirements
are the same as for the 3745, that is:
- NCP V6R2 and higher, along with VTAM V4R2, provide support for APPN and
GR.
- NCP V7R2 and VTAM V4R4 provide support for APPN/HPR and MNPS (not RTP endpoint).
However, the alternative APPN solutions provided by the APPN network nodes
in the NNP or the MAE can provide the full set of APPN/HPR functions -- ANR
routing and RTP endpoint. Thus the 3746 can provide optimum exploitation
of the Parallel Sysplex for SNA applications, with full support for both
GR and MNPS.
Where TCP applications are used, there are two main configurations:
- IP router provided by the NCP
- IP router provided by the NNP (This router also supports the MAE adapters
using the latest version of the product.)
As discussed above, the NCP is not a solution for high throughput, whereas
the IP router provided by the NNP offers a solution for high volumes of
traffic. In addition, the NNP IP router also supplies the Network Dispatcher
function (using the MAE). This provides support for load balancing among
TCP hosts in the Parallel Sysplex. This is in addition to the load balancing
done by the DNS in the OS/390 nodes.
Another key function provided by the 3746-900 is the Enterprise Extender
(using the MAE). This provides a superior option for carrying SNA applications
over IP backbone networks. As an alternative, the TN3270E server function
is also possible (again using the MAE).
3746-950 Nways Multiprotocol Controller
The 3746-950 provides the same APPN and IP functions as the 3746-900 NNP,
but does not support the NCP.
So, for SNA applications, there are two APPN configurations:
- APPN network node provided by the NNP
- APPN network node provided by the MAE
This configuration is attractive if you have been satisfied with the front-end
processor technology but want to move away from the NCP. For TCP applications,
the NNP provides the full IP router support of the 3746-900. It also provides
the Network Dispatcher function for load balancing in the TCP environment
and Enterprise Extender or TN3270E server for transport of SNA applications
over an IP backbone network. All these functions require the MAE.
2216 Nways Multiaccess Connector
The 2216 is an APPN and/or IP router that provides a solution for S/390
access using either an ESCON or a parallel channel adapter. It supports
a wide range of LAN, WAN and ATM adapters.
For SNA applications, the 2216 acts as an APPN network node and provides
full APPN/HPR support including ANR routing and the RTP endpoint functions.
So it fully supports both the GR and MNPS applications of the Parallel
Sysplex. In addition, if APPN/HPR is used without MNPS to support high
availability, the 2216 provides full support for the APPN/HPR functions
required.
There is also a SNA solution based on the passthrough configuration,
but this is not recommended in the Parallel Sysplex configuration because
it uses the network node function provided by VTAM. This would therefore
incur an additional network hop in some configurations and use more S/390
resources.
For TCP applications, the 2216 provides the Network Dispatcher function
for load balancing in the TCP environment. This is in addition to the load
balancing done by the DNS in the OS/390 nodes. The 2216 also supports both
the TN3270E server and the Enterprise Extender for transport of SNA applications
over an IP backbone network.
Both the 2216 and the 3745/6 family of products provide a very attractive
solution for access to the Parallel Sysplex. While the 2216 is optimized for high throughput and performance, the 3745/6 offers greater connectivity, support for more SNA sessions, and the option of supporting the NCP for traditional SNA
subarea support.
3172 Interconnect Controller
The 3172 running the Interconnect Control Program (ICP) software provides
a simple passthrough configuration for access to the S/390 server. The
3172 supports LAN access to the S/390 when running the ICP.
Although the 3172 does not provide an outboard APPN or IP router, it
uses the routing functions of Communications Server/390, enabling it to
connect both SNA and IP networks to the S/390. However, the lack of the
outboard router means that additional S/390 cycles are used compared with
the solutions based on the 3745/46 or 2216.
A recent enhancement to both VTAM and the 3172 has enabled VTAM to support
the APPN/HPR ANR routing function when using the 3172 ICP. In a high-availability
configuration, using either MNPS or just APPN/HPR, the 3172 can now act
as a gateway without compromising the overall availability.
For TCP applications, there is no possibility of using the Network Dispatcher
function. However, the load balancing function provided by the DNS in the
OS/390 nodes is available.
For transport of SNA applications over an IP backbone network, the 3172
does not support the Enterprise Extender function. If TN3270E support is
required, then the OS/390 solution or one of the external TN3270E solutions
must be implemented, as the 3172 does not provide the server function.
Consequently, although connectivity to the S/390 servers for both SNA
and TCP/IP applications exists with the 3172, many of the additional high-availability
and workload-balancing features required for the Parallel Sysplex are not
provided.
S/390 Open Systems Adapter 2 (OSA-2)
The OSA-2 is a card that is installed inside the S/390 server. Multiple
cards can be installed, depending on the model of S/390 server, up to a
maximum of 12. The OSA-2 provides excellent LAN and ATM access, but no
serial line interfaces.
The OSA-2 provides a similar level of function to the 3172, although
it does have far superior connectivity and performance. It does not provide
an outboard APPN or IP router, and so it uses the routing functions of
Communications Server/390. It can connect both SNA and IP networks to the
S/390. However, the lack of the outboard router means that additional S/390
cycles are used compared to the solutions based on the 3745/46 or 2216.
The recent VTAM enhancement discussed above also provides the possibility
for VTAM to support the APPN/HPR ANR routing function when using the OSA-2.
This means that, in a high availability configuration, using either MNPS
or just APPN/HPR, the OSA-2 can now act as a gateway without compromising
the overall availability and performance.
For TCP applications, there is no possibility of using the Network Dispatcher
function. However, the load-balancing function provided by the DNS in the
OS/390 nodes is available.
For transport of SNA applications over an IP backbone network, the Enterprise
Extender function is not supported and there is also no TN3270E support
on the card. If TN3270E support is required, then the OS/390 solution or
one of the external TN3270E solutions must be implemented.
So although connectivity to the S/390 servers for both SNA and TCP/IP
applications exists with the OSA-2, including high-performance LAN and
ATM access, many of the additional high-availability and workload-balancing
features required for the Parallel Sysplex are not provided. However,
considering the OSA-2 as an alternative to an external gateway is only
one way of using the card. There are other possibilities for using the
OSA-2, including:
- Using the OSA-2 with high-speed LAN or ATM connectivity to
the external gateway (such as the 3745/46 or 2216), as an alternative to
ESCON
- Using the OSA-2 with LAN connectivity to provide a backup
HPR path to the external gateway. The primary path for HPR traffic will
be across the ESCON channel into the S/390, but the
LAN connection to the OSA-2 can be used in case of channel or ESCON director
failures.
Conclusions
The choice of the network gateway can enhance the benefits of the Parallel
Sysplex environment. The table summarizes the important technologies discussed
in this article.
|
3745/46 |
2216 |
3172 (ICP) |
OSA-2 |
| APPN/HPR router |
Yes |
Yes |
No
(Passthrough) |
No
(Passthrough) |
| HPR/RTP support |
Yes |
Yes |
No |
No |
| HPR/ANR routing |
Yes |
Yes |
Yes |
Yes |
| IP router |
Yes |
Yes |
No
(Passthrough) |
No
(Passthrough) |
| Enterprise Extender |
Yes |
Yes |
No |
No |
| TN3270E Server |
Yes |
Yes |
No |
No |
| Network Dispatcher |
Yes |
Yes |
No |
No |
All of the four products discussed in this article provide connectivity
to the Parallel Sysplex for both SNA and TCP applications. Each provides
different levels of LAN, WAN and ATM adapter support, and this can be an
important consideration. However, for the Parallel Sysplex, connectivity
is not the most important factor.
Selecting a gateway that fully supports features such as APPN/HPR, Enterprise
Extender and Network Dispatcher will ensure that the best use is made of
the Parallel Sysplex resources by providing high availability and workload
balancing. Both the 3745/3746 family of products and the 2216 provide this
functionality and are recommended as premier gateways to connect the network
to the S/390 Parallel Sysplex.
Footnotes:
¹ A Geoplex provides a disaster-recovery solution for Parallel Sysplex. [ back to article ]
² One exception to this statement is if the network uses the older BSC protocols under NCP support. In this case, there must be a subarea route to the VTAM application system. [ back to article ]
³ A future release of Communications Server/390 will also provide the Enterprise Extender function. [ back to article ]
Rachel Pickering is a Network Consultant, based in IBM Bedfont in the UK. She works on a worldwide Enterprise Network marketing team, specializing in S/390 server access. |