Systems Network Architecture Server, a member of the Backoffice family and
soon to be renamed Host Integration Server, acts as a gateway for both
Microsoft and non-Microsoft clients requiring IBM AS/400 and Mainframe
connectivity.
SNA Server can provide connectivity using multiple protocols such as TCP/IP,
IPX/SPX, NetBEUI, Banyan VINES IP, and AppleTalk. This allows clients
to connect to the Windows 2000 SNA server with commonly installed protocols
while the SNA server connects to the IBM Host via traditional means
(channel attachment, Synchronous Data Link Control, X.25, etc). You must
configure the Server-to-Host connection method.
Synchronous Data Link Control
SDLC was invented by IBM to replace the older Bisyncronous protocol for
wide area connections between IBM equipment. SDLC is not a peer-to-peer
protocol like HDLC, Frame Relay, or X.25. An SDLC network is made up of
a primary station that controls all communications, and one or more
secondary stations. When multiple secondaries are connected to a single
primary, this is known as a multipoint or multidrop network.
X.25-X.25
X.25 is a packet switched data network protocol that defines an international
recommendation for the exchange of data as well as control information
between a user device (host), called Data Terminal Equipment (DTE),
and a network node, called Data Circuit Terminating Equipment (DCE).
X.25 provides a connection oriented technology for transmissions over
highly error prone facilities, which were more common when it was first
introduced. Error checking is performed at each node, which can slow overall
thoughput and renders X.25 incapable of handling real-time data.
Source-Routed Token Ring
The source-routed bridging (SRB) algorithm was developed by IBM and proposed
to the IEEE 802.5 committee as trhe means to bridge between all local-area
networks (LANs). Source Routing allows you to place a virtual bridge between
two network segments so that traffic between the two segments is considered
local to the same segment. This is often used on Token Ring networks to
bridge SNA dependent segments.
SNA Deployment Models
Reviewing your WAN configuration, the location of your Host Systems, and
the location of your users, the deployment model you choose will be based
on the current and planned network infrastructure, quantity of users, and
the required fault tolerance of your SNA Services.
Branch Deployment Model
This model is where you implement an SNA Server in each location that
contains users who need access to host systems. In this decentralized
model, each region can manage their own SNA Server.
The advantage to the branch deployment method is the limitations of network
traffic. Connectivity between the client and SNA Server requires more
network bandwidth than connectivity between the SNA Server and the Host
System, limiting traffic between the client and the SNA Gateway to the
local network. If your network already has SDLC or X.25 connections to each
location, and a decentralized IT, this model can be advantageous. Reponse
times can be lowered due to slow WAN links to the Host System.
Centralized Deployment Model
This model is the method of deploying SNA Server near the host rather than
the clients. This allow clients from anywhere in the WAN to connect to the
Host System via the Gateway by using standard protocols such as TCP/IP,
IPX/SPX, NetBEUI, etc. The SNA Server can be connected directly or
indirectly (through a Front End Processor) to the Host System.
The advantage to this method is the efficiency of the connectivity (Server
can be directly connected to Host System), as well as the flexibility of
client access. This method also offers the centralized management model,
allowing all SNA Servers to be grouped together for easier management. You
can also add efficiency, load balancing, and fault tolerance by utilizing
a second SNA Server as a secondary access point for clients.
The disadvantages to this model are minimal. If you centralize your SNA
Servers in one location with the Host System, then those machines cannot
be efficiently used for other network services. Some organizations may have
limited budgets, requiring them to use existing servers in each region.
This method also needs an efficient WAN architecture to support the traffic
that will be generated by the clients accessing the SNA Server through the
WAN.
Distributed Deployment Model
This model is a combination of the branch deployment model and the
centralized deployment model. In the model, SNA Servers are placed local
to the Host System and configured in the same way as they would be in a
centralized deployment model. SNA Servers are also added at each branch
office or location and configured to use link services with other SNA
Servers.
The advantage of this model is that it combines the best of both branch and
centralized models, while supporting high fault tolerance and load balancing
across the enterprise. This is the recommended configuration for medium to
large organizations. This model does, however, require the use of more
servers than the other two models.
SNA Server Organization
SNA Servers are logically grouped together into subdomains. A
subdomain allows you to provide primary, backup, and stand-alone or member
servers for your SNA Server deployment. You can include up to 15 SNA Servers
in any given subdomain, 1 primary and up to 14 backup or member SNA Servers.
The primary SNA Server holds the master copy of the configuration for the
SNA Server, while backup SNA Servers contain a backup of the configuration
information in the event of a primary SNA Server failure. The member servers
do not contain a copy of the configuration file, but act as a part of the
subdomain in the same way that the primary and the backup do, reponding to
client requests as needed.
Although the number of SNA Servers within a subdomain is limited to 15, the
number of subdomains in any given Active Directory domain is unlimited.
When configuring large SNA subdomains, try to configure a seperate subdomain
for each site where your users are organized into large groups. You can also
configure additional subdomains for a single location and configure the
client software for large groups of users toward the new subdomain.
Try to implement all SNA Servers that belong to the same subdomain in the
same location, due to the replication that must occur between the servers.
If you must implement two or more SNA Servers in the same subdomain across
slow WAN links, youou can modify the replication of the SNA Servers through
the SNA Server Manager. This configuration is referred to as the "Mean Time
Between Server Broadcasts."
When a client is configured for SNA connectivity through an SNA Server, you
can specify the subdomain, instead of the server itself. The client (if
Windows 2000) will negotiate with the AD to determine the closest SNA Server
in the desired subdomain. This AD Sites and Services integration helps
minimize bandwidth usage.
SNA Server to Host System Connectivity Options
If you are using a branch deployment model, then your connectivity options
are limited due to the distance between the SNA Server and the Host System.
Your options would include X.25 and SDLC, both of which are limited to
19,200 bps and only supports 256 sessions over a single connection. You
could also use (assuming your routers support it) a source routed Token
Ring connection directly to the mainframe or front-end processor. This is
often referred to as bridging, and is typically not recommended due to the
excessive network traffic that is usually caused by bridging two seperate
networks.
If you are using a centralized or distributed model, then connectivity from
your branch office SNA Servers to your central office SNA Servers will be
provided using using whatever WAN protocols you have implemented (TCP/IP,
IPX/SPX, etc). Your only decision is how to connect the SNA Server in the
central office to the Host System. If you are using an Front End Processor
(FEP), you can connect to it using Token Ring, Ethernet, FDDI, SDLC, or
X.25. If you are connecting directly to the Mainframe, you can use a Bus &
Tag or ESCON Channel Attachment, Token Ring, Ethernet, or FDDI to make your
connection.
If your Host System is an AS/400, the connectivity options are slightly
different for direct connections. SNA Servers can connect directly to AS/400
systems using SDLC, 802.2/DLC (Token Ring, Ethernet, FDDI), X.25, Twinax,
or Frame Relay.