Figure 2.4 In a centralized deployment, SNA Server computers support local and remote split-stack SNA clients, server-based applications, and TN3270 emulators.
In a centralized configuration, the SNA Server computers are located near the host systems at central sites. In a typical centralized deployment, as depicted in Figure 2.4, channel-attached or high-speed token-ring-attached SNA Server computers are placed at the data center and connect to the host using SNA protocols. The centralized SNA Server computers provide split-stack 3270 and AS/400 access for local and remote desktops, which connect to the gateways using TCP/IP or another WAN protocol. Additionally, desktop- or server-based LU0 and LU6.2 applications, plus TN3270 emulators, can connect through these gateways from anywhere on the WAN.
There are many advantages to following a centralized SNA gateway deployment strategy. These include using a single protocol on the LAN and the WAN; efficiently sharing host resources; easing administration; improving reliability with load balancing and hot backup; and employing high-speed host connections.
A centralized deployment model not only makes possible but presupposes the existence of an efficient WAN environment. All desktop access to host systems is across routable protocols such as TCP/IP. Of course, a centralized configuration requires higher-capacity WAN links to support the increased traffic. This deployment model will yield less-responsive client-to-server connections, yet offers faster server-to-host connections when compared to a branch-based configuration. With a centralized deployment strategy, organizations can take advantage of SNA Server's high-speed token-ring, Ethernet, or FDDI connections, as well as even-higher-speed channel attachment options.
Deploying groups of SNA Server computers allows the network administrator to use features such as LU pooling, load balancing, and hot backup. These features can make host logical units (LUs) more available and host connections more reliable. This is often one of the key reasons why network managers deploy SNA Server computers centrally...
Up to 15 SNA Server computers can interoperate simultaneously in an SNA Server group, called an SNA Server subdomain. An unlimited number of SNA Server subdomains can be deployed in any one Windows NT domain. Each subdomain can contain one primary SNA Server and up to 14 backup SNA Server computers for a total of 15 SNA Server computers. The primary SNA Server computer stores the master copy of the subdomain-wide configuration file, which containsconnection (PUs/LUs) and user/group access right information. The SNA Server computers communicate with each other in two ways: (1) the primary SNA Server replicates the SNA Server configuration file (COM.CFG) to each backup SNA Server when changes are made to the configuration using the SNA Server Manager program; and (2) all SNA Server computers send multicast messages to each other to notify the other SNA Server computers of major status changes, such as server and host connection activation or deactivation.
When an efficient WAN is implemented and SNA Server computers are centrally deployed, users located anywhere on the WAN can access the same host resources on an as-needed basis. This is accomplished with an SNA Server feature called LU pooling, in which dependent LU sessions and APPC session pairs are grouped together into a pool of common resources. Pools allow groups of intermittent users to share resources efficiently. A user, APPC transaction program, LUA application, or downstream system requesting pooled resources
from SNA Server gets LU access so long as one of the pooled sessions is available. For example, 100 3270 users who need intermittent access to one session each may find that a pool of 50 3270 LUs is adequate for their needs. With proper capacity planning, pooled resources are more efficient, more flexible and easier to administer.
LU pooling reduces the number of host connections required and makes better use of host administration time, which would otherwise be spent reconfiguring host PUs and line definitions as required to meet constantly changing needs. Additionally, centrally located SNA Server computers are easier to secure and manage by the central-site MIS group. This reduces the potential need for SNA expertise at remote sites.
LU pools and APPC session pairs can be configured across multiple central-site SNA Server computers to provide load balancing and fault tolerance. Load balancing ensures greater reliability by reducing the possibility that any single SNA Server will be saturated and performance will degrade. Fault tolerance can be provided through an SNA Server feature called hot backup. Hot backup ensures that if one central-site SNA Server computer should fail, then users can connect via another server automatically.
Centrally deployed SNA Server computers can easily be configured for channel attachment or high-speed LAN links to the host. Channel attachment offers the fastest throughput to a mainframe. ESCON supports up to 17 MBytes/sec over eight channels for a total bandwidth of 135 MBytes/sec, compared to 16Mbps for token ring. In many cases, a channel-attached SNA Server computer can bypass the front-end processor (FEP), minimizing the transaction response time. For AS/400 connections, SNA Server can connect via high-speed token ring or Ethernet. To best take advantage of these high-speed host connections, SNA Server is based on the scalable Windows NT Server platform and can support up to 2,000 users running up to 10,000 concurrent sessions across up to 250 concurrent host connections.
There are disadvantages to centrally deploying SNA gateways. These include slower response times when large numbers of users connect across the WAN from branch-office to centralized SNA Server computers; and greater WAN bandwidth requirements as a result of multiple client-to-server sessions between SNA desktops and SNA Server.
In a centralized model, the network manager will likely turn on at the workstation the Nagle (see the discussion of the Nagle TCP/IP compression algorithm in the following section on the distributed deployment model)TCP/IP compression algorithm, which is the default for SNA Server's client-to-server communications and Windows NT Server's TCP/IP. This improves mission-critical client-to-host traffic. Yet, Nagle will slow down other essential traffic—that flowing between the PC and local LAN servers, such as file and print access. In contrast, a distributed deployment allows the network manager to configure Nagle "on" and achieve maximum benefit for both local LAN server access and PC-to-host connectivity. This is because in a distributed deployment all traffic is considered "local" between the workstation and the LAN file server or SNA Server computer. Therefore, workstations will have similarly good (the best overall) response between both client-to-server and client-to-host connectivity.
Microsoft has recognized the disadvantages of centrally deployed SNA gateways. In order to correct these issues, Microsoft has produced an alternative deployment strategy—the distributed model. Distributed deployment combines the advantages of the branch-based and the centralized deployment models without the disadvantages of either.