Hardware planning as it relates to Microsoft BackOffice is primarily concerned with the following critical system resources.
System Processor(s)—CPU
Memory—RAM
Disk Subsystem—Disk I/O
Network Interface—Network I/O
These resources make up the bulk of all relevant hardware platforms on which the Microsoft BackOffice components operate. Hence, this paper will address planning considerations that are generic to all platforms and useful for scaling and implementing optimal Microsoft BackOffice solutions.
As stated earlier in this paper, the level of CPU- or processor-bound work is the key to determining the best CPU architecture. Hence, we have seen that all of the Microsoft BackOffice components require CPU resources to some extent and all will take advantage of SMP architectures. So, is there any set of factors or a particular application that points the way to this resource decision? Unfortunately not. Therefore, it is recommended that you acquire the best CPU architecture you can justify for your Microsoft BackOffice project. In fact, from a scalability point of view, when you look at all the potential combinations of Microsoft BackOffice components, it is best to go with a system that supports SMP, even if you only start with a single processor. Moreover, if your Microsoft BackOffice solution includes more than one of the Microsoft BackOffice components on a single platform, then obtain an SMP system with at least two processors scalable to at least four processors if you think growth of the system justifies the expandability.
All Microsoft BackOffice components require minimum memory configurations. This memory is managed by the Windows NT Virtual Memory Manager (VMM) and is used extensively by the Microsoft BackOffice components. (Mostly for caching data and code pages in order to avoid system page faults and subsequent disk I/O.) Therefore, it is recommended that the amount of memory be proportional to the Microsoft BackOffice components running on the selected hardware platform. Hence, if the platform includes Windows NT Server + Microsoft SQL Server + Systems Management Server, then at minimum add the required memory for each component to arrive at 16 MB (Windows NT Server) + 16 MB (SQL Server) + 16 MB (Systems Management Server) = 48 MB. This is your starting point for building an optimal Microsoft BackOffice system. You must now tune the memory under actual operating conditions in order to get the absolute best configuration.
The goal here is to achieve the fastest, most efficient disk I/O operations possible. All Microsoft BackOffice components except SNA Server are "disk bound." Thus, it is imperative that you configure the Microsoft BackOffice platform with the best disk subsystem you can justify. At minimum this equates to an intelligent SCSI controller and fast SCSI drives with read-ahead (at least 1 track) caching. Optimally for Microsoft BackOffice systems consisting of several components, the configuration will be:
One or more Intelligent SCSI-II array controllers.
Supports hardware-level RAID.
Supports on board caching.
An appropriate number of fast SCSI drives, the size and quantity based on projections of application I/O/sec and space requirements.
Having procured a high-performance disk subsystem, the task is then to appropriately map the Microsoft BackOffice application environments to the disk subsystem based on seek efficiencies.
Without exception, all the Microsoft BackOffice applications initiate some level of network activity. This in turn results in network interrupts being generated. These interrupts may then need to be serviced by the system processor, thus depriving some other Microsoft BackOffice process of the CPU resource. Thus, it is to your benefit to obtain one or more intelligent network interface cards in order to offset this occurrence. Such a NIC will match the bus configuration of your system and should possess an on-board controller (bus master) and possibly on-board cache. This NIC configuration will reduce the level of interrupts and help to increase network throughput, thereby reducing latency.