Interoperability with IBM Host Systems
Interoperability with IBM Host Systems |
|
Consider the following when deciding how to deploy SNA Server throughout your enterprise:
To accommodate different host connectivity requirements, SNA Server offers three deployment models.
Branch Deployment Model Consists of computers running SNA Server placed away from the host system and near your users.
Centralized Deployment Model Consists of SNA gateways placed close to the host system.
Distributed Deployment Model Consists of SNA gateways placed near the host system and close to your users.
These three models can also be combined to achieve the best configuration for your enterprise. The following sections explore the advantages and disadvantages of each SNA Server deployment model and assist you in making deployment decisions based on your current network model and your interoperability goals.
Traditionally, enterprises deploy SNA gateways using the branch-based deployment model. Clients use LAN protocols, such as TCP/IP, to communicate with a computer running SNA Server located on the LAN in the branch office.
The computer running SNA Server, in turn, communicates with the host using SNA protocols. With the branch approach, computers running SNA Server are connected to a host through 802.2 (using routers), SDLC, or X.25 connections, as shown in Figure 10.2. Each computer running SNA Server can be administered locally or remotely using Windows 2000 Routing and Remote Access service or IBM NetView.
Figure 10.2 Branch-based SNA Server Deployment Model Using SDLC Connections
The branch deployment model offers four primary advantages:
A branch-based deployment model is ideal when a limited amount of bandwidth is available over the SNA Server-to-host connection. In general, network traffic is greater between the client and the computer running SNA Server. If your organization has implemented TCP/IP or another routable WAN protocol, isolating the SNA traffic over specific connections that require host connections—in this case between the SNA Server and the host—prevents unnecessary network traffic from being propagated over non-SNA WAN connections.
The branch model is also ideal for organizations that are migrating toward a single, routable WAN protocol solution because it leverages existing investments in SNA data links. As you migrate toward an SNA-free WAN, you can tunnel SNA protocols (such as 802.2 and SDLC) from the branch office LANs to the central site LAN by deploying routers or Frame Relay Access Devices (FRADs) that support Data Link Switching (DLSw), frame relay, or Asynchronous Transfer Mode (ATM) connections.
For more information about frame relay, see RFC 1490.
Because computers running SNA Server are located physically near the clients that request host access services, local SNA Server administrators can usually manage users for their branch, responding more quickly to their needs. If necessary, however, computers running SNA Server can be configured and managed remotely across your WAN links.
By deploying SNA Server in branch offices, you can take advantage of other applications designed to run on Windows 2000 Server. The branch-based server can assume a number of roles in addition to performing SNA Server functions, such as messaging server, database server, and Web server. Components in the BackOffice suite of server applications can work together to provide integrated groupware solutions for your users.
The branch deployment model has two primary disadvantages:
In a branch-based network, you cannot implement high-speed mainframe connections such as channel attachment, Token Ring, or Ethernet. Local high-speed connections often face physical limitations or difficulty in implementing SNA protocols over a WAN connection. Traditionally, branch-based SNA gateways employ an SDLC-type solution that supports only one physical unit (PU) for each host adapter and only 254 logical units (LUs) over the connection.
If you decide to use routers rather than dedicated SNA links to pass WAN traffic between the branch and SNA host systems, the routers must be sophisticated enough to prioritize interactive communications over the WAN, as multiple protocols in addition to SNA might be operating over the connection.
In a centralized model, computers running SNA Server are deployed physically near the host to which they provide connectivity. The centralized computers running SNA Server provide 3270 and 5250 access for local and remote desktops that connect to the gateways using a routable protocol such as TCP/IP. Other desktop or server-based LU 0, LU 6.2 (APPC), or Telnet applications can connect through these gateways from anywhere on the WAN. Figure 10.3 illustrates the centralized deployment model.
Figure 10.3 Centralized SNA Server Deployment Model Using Routers or Bridges
The centralized model offers three primary advantages:
Using the centralized model, LU pools and APPC session pairs can be configured across multiple computers running SNA Server in a logical organization called a subdomain to provide load balancing and fault tolerance services. Load balancing distributes server loads across all configured servers and prevents one server from being overworked. Fault tolerance or hot backup, ensures that other computers running SNA Server in a subdomain can automatically take over for a failed server. To your users, the switch to a backup computer is transparent. For more information about subdomains, see "Grouping Servers" later in this chapter.
A centralized deployment model is also easier to administer and to secure than a branch-based model because all computers running SNA Server are located close to one another (in the branch-based model, SNA expertise is usually required in each branch office to maintain the servers). Also, changes to mainframe definitions can be coordinated between host and SNA Server administrators more readily if all personnel are located near one another.
When computers running SNA Server are physically close to the SNA host, they can be linked by high-speed connections. The channel attachment method provides the highest throughput between SNA Server and a mainframe. In many cases, a channel-attached computer running SNA Server can bypass the front-end processor (FEP), thereby minimizing transaction response time. For AS/400 hosts, you can implement high-speed Token Ring or Ethernet connections.
The centralized model has two primary disadvantages:
A centralized deployment model presupposes the existence of an efficient WAN environment. If a suitable WAN infrastructure is not in place, you must account for the cost in equipment, installation, and possible downtime while you deploy the required hardware. Because client/server transactions generate more network traffic than server/host transactions, this deployment model might yield less responsive client/server connections than a branch model.
With no computers running SNA Server in the branch offices, you cannot use the Windows 2000 Server–based computers, upon which SNA Server runs, as multipurpose servers. If other server applications need to be implemented at the branch locations, you need to install additional computers and hardware.
The distributed deployment model combines the best elements of the branch and centralized deployment models. As shown in Figure 10.4, computers running SNA Server are deployed both in a central location near the SNA host and in the branch LANs near the clients.
Typically, the computers located near the host are linked by a high-performance connection, such as channel-attachment. These link services are then made available for distribution to the branch computers running SNA Server using Distributed Link Services, a feature that allows an SNA Server–based computer to share configured link services with other SNA Server–based computers. When implemented, the branch-based servers communicate with the SNA host through a virtual link service over a routable WAN protocol, such as TCP/IP.
Figure 10.4 Distributed SNA Server Deployment Model
The distributed model has the advantages of the two previous models while minimizing the disadvantages of each.
The distributed model combines the high-capacity, server-to-host communication benefits of the centralized model with the branch model's ability to contain heavy client/server traffic to a localized WAN segment, such as a branch office LAN.
The distributed model provides even greater flexibility than the branch or centralized plans when fault tolerance and load balancing are implemented. For example, multiple computers running SNA Server at a branch location can be configured to provide hot backup and load balancing for each other. These servers in turn can be connected to the SNA host using distributed link services shared by the centralized computers running SNA Server. If any of the servers fails, the other servers at the same location can take over for the failed unit.
The use of Distributed Link Services can also simplify your routing and network protocol choices. For your branch offices, you can use any of the LAN protocols supported by SNA Server, including IPX/SPX. You can implement a more efficient, routable protocol like TCP/IP between the branch and central SNA Server–based computers. SNA traffic is isolated to the connection between the high-speed SNA Server–based computers and the host system. SNA protocols do not need to be routed or bridged across the WAN, thereby simplifying network management.
The one possible disadvantage of the distributed model is that it might require more servers.
Depending on your requirements, deploying SNA Server–based computers both in the central location and in your branch offices could require that you deploy more servers than you would use in a centralized or branch model. However, the additional reliability and performance offered by this model, combined with the ability to eliminate multiprotocol WAN infrastructures can more than offset any requirements for additional servers.
In general, the distributed deployment model provides the most flexible and robust SNA Server solution. This strategy is recommended for medium to large network environments that require the best performance and reliability. The distributed model is also easily scalable to meet your future needs.
