This chapter is from the book
This chapter is from the book
This chapter is from the book
Evaluating Existing Servers
It may seem intuitive that your existing servers will need to be evaluated prior to the upgrade to Windows 2000. What may not be obvious is the extent to which this evaluation needs to take place. In this section, we will look at the elements of your server which deserve special consideration: hardware and software.
Server Hardware
There are four main areas on the server which require special attention. These areas are the memory, the drive subsystem, the network interface, and the processor.
Memory
So you subscribe to the old axiom, "The more memory, the better." That may have been ok in the old days. However, in a Windows 2000 environment, you need to pay a little bit more attention to the memory subsystem. With today's servers there are several types of memory to choose from. It is important that the right memory for the particular server is selected. In addition, there are very specific combinations and sequences in which to add memory to the machines. In order to correctly determine the amount of memory the machines will need when upgraded to Windows 2000, it is necessary to look at the services the machines will be running. You can also use some of the load simulator tools, set up a similar machine in a lab, and test using a server monitor (the new name for performance monitor). Remember, the goal of the exercise is to make sure that the server has less memory committed, and that it has physical memory. This is easily identified in task manager (see Figure 2–12). In addition to just adding RAM, it is important to see what the maximum memory used was. In Figure 2–12, the peak memory used on the server was 324 megabytes. So we would probably be safe in upgrading it to 512 megabytes. If we anticipate adding extra users, then we might want to bring it up to a gigabyte.
)
Figure 2-12 If a server has more committed memory than physical, the
memory needs to be upgraded.
Drive Subsystem
In addition to physical space, there are several additional items which must be examined. Perhaps the most important, from a reliability standpoint, is to have a very good hardware RAID controller. How the drives need to be configured depend on what the server will be doing on the network. The types of SCSI transfer modes for available devices are listed below.
Narrow SCSI bus. Denotes 8-bit bus
Wide SCSI bus, 16-bit bus. Doubles transfer rate of the bus. Increases supported devices from 8 to 16
Fast SCSI: Denotes a 10MHz bus. When combined with a narrow SCSI bus, the transfer rate is 10MB/s. When combined with a wide SCSI bus, the transfer rate is 20MB/s.
Ultra SCSI: Denotes a 20MHz bus. When combined with a narrow SCSI bus, the transfer rate is 20MB/s. When combined with a wide SCSI bus, the transfer rate is 40MB/s.
Ultra2 SCSI-3: Denotes a 40MHz bus. When combined with a narrow SCSI bus, the transfer rate is 40MB/s. When combined with a wide SCSI bus, the transfer rate is 80MB/s.
Wide Ultra2 SCSI-3: 80MB/s sometimes referred to as generic Ultra2 because the narrow (8-bit) implementation is very uncommon.
Ultra3 SCSI-3: Expands on Ultra2 SCSI technology. 160MB/s is the latest SCSI implementation.
Now that we have a feel for the types of SCSI devices, take a look at Table 2–1 for a quick reference to the number of drives and the throughput that can be obtained using them. Knowledge of SCSI technology is vitally important in server sizing, as typically the bottleneck in a server is the drive subsystem. Therefore, it is important to get the fastest drives with the best transfer rates you can afford.
Table 2-1 Different combinations of SCSI technology provide different transfer rates for servers
|
Type |
Transfer Rate |
SCSI Standard |
Bus Width |
|
SCSI |
2–4MB/s |
SCSI-1 |
8 |
|
SCSI-2 |
5MB/s |
SCSI-2 |
8 |
|
Wide SCSI-2 |
10MB/s |
SCSI-2 |
16 |
|
Fast SCSI-2 |
10MB/s |
SCSI-2 |
8 |
|
Fast-Wide SCSI2 |
20MB/s |
SCSI-2 |
16 |
|
Ultra SCSI-3 |
20MB/s |
SCSI-3 |
8 |
|
Wide-Ultra SCSI-3 |
40MB/s |
SCSI-3 |
16 |
|
Ultra2 SCSI-3 |
40MB/s |
SCSI-3 |
8 |
|
Wide-Ultra2 SCSI-3 |
80MB/s |
SCSI-3 |
16 |
|
Ultra3 |
160MB/s |
SCSI-3 |
16 |
In real-world configurations, SCSI transfer rates are well below the values presented in the technical data sheets. The following example points to what are perhaps more realistic SCSI transfer rates.
Example:
Head positioning (track to track): 1ms Reading one complete track: 8ms (at 7,200 rpm) Reading 1 track including positioning: 9ms With 150 sectors per track, this yields 150 x 0.5KB or 75KB per rotation. With a 7200 RPM drive, this happens 120 (7200/60) times per second. The maximum transfer rate per drive is therefore: 120 x 75KB = 9MB/s. With a 10K drive, it looks like this: 166.66 x 75KB = 12.5 MB/s. With a 15K drive, it looks like this: 250 x 75KB = 18.75 MB/s.
Network interface
The network interface introduces several special considerations. With certain applications, the interface can become a bottleneck. In these situations, you will need to consider gigabit network cards. The better servers have 64-bit buses, that run at 66 mhz. With this kind of bandwidth on the bus, a gigabit network card can be a very effective solution. One thing to keep in mind, however, is there are two patterns for the network traffic—the user-to-server communication, and there is the server-to-server communication. It is sometimes effective to put two NICS in the servers and separate the server-to-server communication from the rest of the LAN traffic involved in client traffic.
Processor
Depending on what the Windows 2000 server is doing, a multiprocessor machine is not always required. In general, I prefer dual-processor machines. At times, I prefer two dual-processor machines to a single quad processor machine. One thing is certain: Whereas in Windows NT 4.0, the PDC could be a relatively wimpy server, a server that is running AD must be a hefty box. Remember that AD is essentially a database, and has configuration characteristics similar to SQL and to Exchange.
Server Software
Evaluating the server software is a tricky and often unsettling experience. In this section, we will look at some of the things that must be looked at prior to the migration.
Testing compatibility
Testing compatibility of applications, which must be early in the migration, can be a very time-consuming process. In trying to determine compatibility, you will need to develop a list of applications that will be migrated to the new servers. Checking with the application vendors is just the beginning. You will need to find out if software is going to be upgraded, patched, or new releases are on the horizon. One thing which could be done is to set up a lab environment, and to model the existing server configuration as much as possible. In this manner, you will be able to perform the upgrade to Windows 2000, simulate normal user activity, and test for potential problems.
Testing interoperability
Once you determine that the software will actually run on the server, make sure it works with other programs and devices. The interoperability study is quite a bit more complex than the test for compatibility. In a compatibility test, you simply need to make sure it runs in Windows 2000. In the interoperability, you need to make sure it will work and play with others nicely. Don't forget: If you upgrade other applications (for Windows 2000 compatibility), make sure that the program you are testing will work with the new version of the software. This includes stuff like the Microsoft Data Access Components (MDACs). I have found many programs that rely on a particular MDAC. If you upgrade another application that requires a newer MDAC, make sure the older application will work with the new MDAC (probably not). This may very well necessitate separating the two applications. Extensive testing and careful planning are required to find this type of information.