Microsoft’s Host Integration Server (HIS) enables broad client-side access to data stored on AS/400, UNIX, and other host systems. It provides access to relational databases, flat files, printers, folders, and other resources available on the host systems from terminal emulation applications, Web-based applications, and other means. HIS eliminates the need for an expensive migration away from host servers and applications by integrating host systems with workstations and servers running a variety of operating systems, including Windows, UNIX, and Macintosh.

As you can see, deploying anything as powerful as HIS requires plenty of forethought. One of the most important things is to plan your physical network infrastructure. In this Daily Drill Down, I’ll show you the infrastructure issues you need to consider when planning to deploy HIS.

What else do I need to know?

You must do more than just prepare your network infrastructure to support HIS. You must also identify the host resources you want to share and prepare your server to handle HIS. To find out what other preparations you must make, see the Daily Drill Downs “Host Integration Server bridges the gap between Windows servers and large systems” and “Plan resource access for Host Integration Server deployment.”

Physical network planning
It’s likely that your client systems are either already connected to the HIS servers or can be connected relatively easily through common protocols such as TCP/IP and the networking clients included with the client operating system. However, you might not have the host-to-server connections in place.

HIS builds on Microsoft’s SNA Server to provide SNA connectivity between HIS and your host servers. HIS acts as an SNA gateway, performing protocol translation between the clients and the host servers. This eliminates the need to install and manage SNA protocol stacks on the clients. For that reason, you don’t really need to concern yourself with client-to-host connectivity. Therefore, one of the first issues you need to address is how the HIS servers will connect to the host servers.

Choosing the physical connection between the host servers and HIS servers really depends in large part on the physical media you use to network your host servers. HIS supports direct channel attachment, DLC 802.2, SDLC, and X.25 for HIS-to-host connections, and a range of LAN connection media, including Ethernet, Token Ring, Fiber Distributed Data, and coax connections. Although you could conceivably combine your LAN clients on the same network as your host servers, you’ll get better performance and reliability by separating the two and allowing HIS to act as the gateway between them.

Separating the networks also provides an additional measure of security for the host servers. To determine your network’s requirements for connecting the host servers to the HIS servers, explore the options available from your host system vendor for networking, and choose a solution for the HIS servers that enables easy integration with your existing host network infrastructure.

You also need to consider connectivity between the HIS servers in deployments where you’ll have more than one server. HIS supports TCP/IP and IPX/SPX for intercommunication between HIS servers. Unless you have NetWare servers on the LAN, TCP/IP is the best option for HIS-to-HIS connectivity. Decide where you’ll locate the HIS servers within your LAN, and then determine addressing and any other TCP/IP requirements to integrate the HIS servers into the LAN. With that done, check your clients to determine what protocols you’ll need to install on the HIS servers to support those clients. HIS supports TCP/IP, IPX/SPX, Microsoft Networking (named pipes), and AppleTalk for communication between HIS clients and HIS servers.

Server locations
With the media and protocol issues behind you, you should give some thought to how you’ll position the HIS servers in relation to the host servers. You have three primary deployment models from which to choose: centralized, branch, and distributed.

Centralized deployment
In a centralized deployment, the HIS servers are located near the host servers. For example, if your host servers are located in a central office, and several branch locations need to access those servers, you’d locate the HIS servers in the central office. One advantage to a centralized deployment is the ability to provide high-speed network connections between HIS servers and the host servers using direct channel attachment, Ethernet, or Token Ring.

Locating the HIS servers at the central office can also simplify load balancing and fault tolerance. As I explained in the Daily Drill Down “Plan resource access for Host Integration Server deployment,” you can configure logical unit (LU) pools across multiple HIS servers to balance the load across the group and provide failover capability in the event that one of the servers goes offline. A single high-speed connection can handle client traffic between the branch and central offices.

Branch deployment
In a branch deployment, each branch office receives one or more local HIS servers. These servers connect to the central office host servers over routed 802.2, SDLC, or X.25, and the clients connect to the HIS servers across their local LAN. A branch deployment is a good option if you have a relatively slow connection between the branch offices and the central office because you’ll generally have more traffic between the clients and HIS than between HIS and the host servers. And assuming that you have other connections, such as an Internet connection from the LAN, placing the HIS servers at the branch offices gives you a little more control over which connection the server-to-host traffic will use, further improving overall performance.

Distributed deployment
Your third choice is a distributed deployment, which combines the centralized and branch models. In a distributed deployment, you place HIS servers at the central office and at the branch offices. As you might expect, this model lets you take advantage of the benefits offered by the other two models. For example, HIS servers at the central office can network to the host servers with high-speed connections. The central office servers also provide for load balancing and failover capability, although these two features aren’t limited to just the central office. Where appropriate, each branch office can host multiple HIS servers to provide their own level of redundancy and load balancing.

In a distributed deployment, the HIS servers at the branch and central offices communicate with one another using the Distributed Link Service, which enables the central HIS servers to share their configured link services with the branch office servers. The traffic between the branch and central office servers is handled by a virtual link service that is routed using (typically) TCP/IP, which simplifies the branch-to-central office connection—you don’t need to route or bridge the SNA traffic across the WAN as you would with a straight branch deployment. This can be a plus with many companies moving away from dedicated frame and other types of WAN connections to the less expensive DSL.

The only real downside to a distributed deployment is the need for additional HIS servers, so unless you have a relatively small deployment in mind, I recommend a distributed model over the other two. If you don’t have the administrative staff at the branch offices to manage the servers, you can implement remote access to enable your central office staff to administer the servers.

As you consider your options, you should also think about what the servers will be doing in addition to serving as HIS gateways. With a branch or distributed deployment, you could use the HIS servers in other functions, such as file or print servers. In addition, you might be able to use existing servers at the branch sites and cut your deployment costs. For example, rather than deploying a new server at each branch, you might only need to beef up memory and add another network adapter to use existing servers.

You should also consider administration when deciding on a deployment model. A centralized deployment puts the HIS servers where your host administrative staff is more likely to be—at the central office. Although staff can administer HIS remotely, it’s usually more convenient to have them close at hand. A centralized deployment also eliminates the need to deploy remote access solutions to support remote management. If you need to support a large number of clients, however, it can be more practical to delegate HIS server management to someone at each branch office. This means either a branch deployment or the provision of remote access for HIS management across the WAN. Take a look at how many clients you need to serve, how much administrative time will be needed to adequately serve them, and whether your branch office IT staff (if any) has the necessary skills to manage its server(s). Then factor those answers into your evaluation of deployment models.

Planning logical server infrastructure
As I’ve already mentioned, providing load balancing and fault tolerance for the HIS servers is an important step toward ensuring highly reliable host access for clients and applications. With load balancing and failover capability properly implemented, clients need never know that a particular server is down. They’ll also enjoy better response from the host servers and host-dependent applications.

HIS domains
Each HIS server must be a domain member in an NT, Windows 2000, or .NET domain. Depending on your authentication needs, you can either create a separate domain for the HIS servers or add them to an existing domain. If you create a separate domain, examine the network and domain membership of users who need to access the HIS server domain to determine whether you need to establish a trust relationship between the HIS domain and the users’ domain, or if an existing transitive trust relationship is already in place. All HIS servers in the same HIS subdomain must reside in the same Windows domain.

As you work toward determining the domain structure to support HIS, keep in mind the physical location of the domain controllers (DCs) in relation to the HIS servers and clients. If the HIS server needs to rely on another domain to authenticate users, you should provide a local DC close to the HIS server to reduce network traffic and provide authentication redundancy. For example, you shouldn’t rely solely on DCs at the central site to provide authentication for HIS servers at a branch site. Instead, place DCs at the branch sites to service client authentication requests.

HIS subdomains
Another important concept when planning the location of the HIS servers for your deployment is that the HIS servers reside in a HIS subdomain. HIS subdomains have no direct relationship to Windows domains. HIS subdomains serve as logical grouping entities for HIS servers. HIS subdomains play no role at all in client authentication. All HIS servers in a given subdomain must be members of the same Windows domain. However, a single Windows domain can support any number of HIS subdomains.

HIS subdomains enable HIS servers to share common configuration information. To clients, the servers in the subdomain appear and function as a single entity. Resources are configured across the subdomain, so when one server goes offline for some reason, the remaining servers can continue to give clients access to those resources. In addition, the servers in the subdomain balance the load across the subdomain.

HIS subdomains can each contain a maximum of 15 HIS servers. Where you place the subdomains and how many you create depend on the number of HIS servers you need and the deployment model you select. In a centralized deployment with fewer than 15 HIS servers, you’ll probably create only one subdomain. In branch deployments in which each branch has fewer than 15 HIS servers, you’ll likely create a single, separate subdomain at each branch.

In a distributed deployment, you could conceivably create a subdomain spanning the central and branch sites, but that will cause configuration data to pass across the WAN link, creating additional network traffic. Instead, you should create separate subdomains at each branch site and a separate subdomain at the central site so that subdomain boundaries don’t cross the WAN link.

The number of subdomains you create at each site depends on the number of HIS servers required and how you want to structure resource access and failover. First consider network layout when designing the subdomains, and then look at how you want to pool resources. In situations where you have a relatively small number of HIS servers at a site, a single subdomain will suffice.

In other situations, however, you might decide to use multiple subdomains at a site to give yourself additional flexibility when designing load balancing and failover behavior. The key is to first understand what resources the clients need to access, and then decide how you need to configure balancing and failover to provide the best performance and most reliable resource availability.

Your next consideration is the role each HIS server fills in a given subdomain. HIS servers can function as primary, backup, or member servers (not to be confused with primary and backup domain controllers). A primary server maintains the master copy of the configuration data for the subdomain, and it’s the first server you add to the subdomain. The backup servers maintain read-only copies of the configuration data. A member server doesn’t maintain a copy of the configuration data.

All servers in the subdomain can process client requests, regardless of their status in the subdomain. Given the maximum of 15 servers per subdomain, a subdomain can contain one (and only one) primary server with a mix of up to 14 secondary or member servers.

As with authentication, the HIS server’s status has no direct relationship to domain controller status for the domain in which it resides. There’s no requirement for HIS servers to be DCs, although they can be. That decision depends in large part on performance—whether the server can adequately function as a DC and HIS server—and how you’ve structured your domains.

As you do when you install a domain and add DCs, you should plan for at least one backup HIS server in each subdomain. If a primary server fails, you can promote a backup server to primary server. You can also demote a running primary server to backup server, making way for a backup server to become the primary. Also keep in mind that a server’s status as a primary, backup, or member server has no bearing on failover capability or load balancing. The structure of HIS enables servers to share the load and provide failover capability, regardless of their role in the subdomain. Also remember that you can manage a subdomain from a primary or backup server, but not from a member server.

Moving toward installation
You can see that there are several steps to planning an HIS deployment. As with any project, you should start with a good understanding of your existing applications, servers, and services. With that understanding, you can turn your attention to which host resources your clients need to access and what applications or other mechanisms they’ll use to reach them. After you’ve clearly defined those needs, you can begin planning the physical and logical structure of the network, deciding on connection hardware and protocols, authentication requirements and domains, and the type of deployment model that best fits all of the parameters. Then you can decide how to structure your HIS subdomains.

As with any big project, you’ll reduce planning and deployment woes with good documentation, careful planning, and adequate testing. While it’s generally not feasible to deploy test host servers in a lab along with HIS servers for evaluation and testing, you can create a test lab that connects into your existing host server network. You can then work out the bugs and develop the resource pools and other configuration issues prior to deploying HIS on a wider basis.