LEARN HOW TO ADD NETWORK THROUGHPUT TO YOUR RESOURCE AND APPLICATION SERVERS
In the October 1996 Lab Guys column, "Overloading Your Server with
Multi-Homing," John Enck and I raised the issue of putting multiple IP
addresses or multiple NICs in your Windows NT server: Does multi-homing work? We
invited readers to submit ideas about how to make multi-homing work, because the
Windows NT Magazine Lab ran into serious operational difficulties.
Thanks to everyone who suggested ideas or echoed the Lab's concerns. We're happy
to report that we have a solution--not the solution, mind you--but one
possible solution. Let's look at some issues the Lab faced and how we resolved
them.
The Problem
One problem is how to increase network bandwidth for application servers. We
test servers of all sizes in an enterprise environment designed to mimic
corporate networks. We need to know two things: 1) that we can build fat data
pipes into our test servers for thousands of users on one network, and 2) that
network I/O is not a bottleneck in our test environment.
You can take two approaches to network administration: Spend a lot of money
and buy the biggest, fastest hardware; multiple Class-C IP licenses; and so
forth, or make do with what you have and hope your users are patient. The Lab
aimed somewhere in the middle: We limited IP addresses, servers, and network
cards, but we used some expensive equipment.
Our setup is not unique. We need to run one NT domain, using TCP/IP,
Dynamic Host Configuration Protocol (DHCP), and Windows Internet Name Service
(WINS) for up to 50 workstations (simulating 500 to 2000 users) and 10 servers
on 4 independent subnets, while maintaining trusts with other domains and access
to our 10Mbps corporate network and the Internet. We need to operate on
100Base-TX so that our virtual users don't get bogged down by thin network pipes
and we get a clear picture of server performance. Compared with a corporate
organization that has 2000 client workstations, 100+ servers, and who knows how
many separate networks, the Lab's setup is like a walk in the park.
The Solution
I won't describe all the things the Lab tried, but I will mention two things
we learned not to do:
* Don't assign IP addresses to two cards in the same server on the same
subnet (e.g., 205.200.45.50 and 205.200.45.51) without subnet masking. Such an
arrangement hopelessly confuses NT, even if you run Multi-Protocol Routing
(MPR), because the OS doesn't know which card to use for which packets.
* Don't cascade hubs. You can chain only a limited number of 10Base-T hubs,
you cannot chain Class-1 100Base-TX repeaters at all, and you can cascade only
two Class-2 hubs. If you cascade hubs, you end up with contention between ports;
that is, systems (IP packets) earlier in the chain get priority over later ones.
Instead, use switches, which boost network performance in other ways (e.g., add
full-duplex capabilities and high-speed backbones).
What should you do? Your solution depends on your situation. Our
limitations dictated our course of action. Figure 1 depicts our logical network
layout, and "Windows NT Magazine Lab's Enterprise Testing
Environment" details our resource and testing requirements. Working closely
with engineers from Adaptec and Cisco Systems, who each supplied a piece to our
puzzle, we set up our network solution as follows:
* We had only one Class-C license, so without setting up a proxy server
(also an option), we divided our 256 available addresses among four IP subnets
(one resource and three client virtual LANS--VLANS, same physical network,
different collision domains).
* To accommodate four separate networks talking to the same resource server,
we needed a router. We used a server running Microsoft's NT MPR software (built
into NT 4.0; available for NT 3.51 from Microsoft's Web site at
http://www.microsoft.com). Using an NCR Globalyst S40 with two 133MHz Pentiums,
128MB of RAM, three 2.1GB Fast and Wide SCSI-2 drives, and an Adaptec Quartet
4-port 100Base-TX full-duplex NIC, we installed MPR and DHCP services to route
among our four networks and assign IP addresses to all clients and resource
servers.
* Because our setup was a domain, we needed a Primary Domain Controller
(PDC). We used a Digital Equipment Prioris HX 5133DP, with two 133MHz Pentiums,
64MB of RAM, two 2.1GB SCSI-2 drives, and a single Adaptec 100Base-TX NIC. This
system also functioned as the WINS server for NetBIOS name resolution (our
testing software referenced machines by name).
* We set up five 100Base-TX hubs for our network: one 8-port Netelligent
from Compaq and four 12-port hubs from Adaptec. We also needed a fast Ethernet
switch--we started with a 6-port Netelligent 100-TX switch from Compaq, but we
outgrew it. So we acquired a Cisco Catalyst 5000--an expensive piece of
networking hardware (with a base price of $11,000), but worth the price if you
want the power. For our test environment, we needed expandability, flexibility,
and performance. The Catalyst 5000 came with one supervisor card (with two
100Base-TX ports) and three line cards (12 ports each), giving us a total of 38
configurable full-duplex switch ports. We separated 32 of these ports into 4
VLANs, giving us 4 essentially independent 8-port switches. (We could have used
4 separate, smaller boxes, but the Cisco gave us more flexibility).
Previous
