Microsoft® Windows Server™ 2003 White Paper
With NLB, organizations can build groups of clustered computers to support load balancing of TCP, UDP, and GRE requests. Web-tier and front-end services, such as Web servers, streaming media servers, and Terminal Services, are ideal candidates for NLB.
A Server Cluster takes two or more computers and organizes them to work together to provide higher availability, reliability, and scalability than can be obtained by using a single system. When failure occurs in a cluster, resources can be redirected and the workload can be redistributed. Typically the end user experiences a limited failure, and may only have to refresh the browser or reconnect to an application to begin working again.
Together, these two technologies combine to insulate your IT infrastructure from application and service failure (software crashes), system and hardware failure (disk crashes), and even site failure (natural disasters, power outages, network interruptions, and so on). Microsoft cluster technologies increase overall availability, while minimizing single points of failure.
Network Load Balancing (NLB) is available in all versions of the Windows Server 2003 family. Cluster Server is available only in Windows Server 2003, Enterprise Edition and Datacenter Edition.
For more information, see the Windows Server 2003 Help and Support Center – NLB and Cluster Server topics
Choosing Scalable Applications
As discussed earlier, some applications are inherently scalable whereas others are not. Sometimes, however, an application that is scalable in theory is not in practice due to poor implementation. Any application can be slowed by gated access to a restricted resource. For example, a file or record lock will quickly turn into a bottleneck. Therefore, you might want to ensure that files and records remain unlocked by opening them in read-only mode when write access is not needed. Similarly, locking an entire file during peak demand to allow, say, someone to sort the database, will obviously lead to availability problems. Likewise, avoid writing to the same data space from multiple different threads that run on multiple different CPUs in order to avoid having to synchronize caches (which are a very expensive operation because it requires writing to memory and reading back from memory, with the attendant overhead).
Furthermore, you must identify the solutions to potential bottlenecks (or recognize where certain features will not enhance scalability due to the nature of the application). Almost any database scalability issue can be solved, but at what cost? Therefore, you must examine price performance (i.e., the cost per transaction) of a given solution.
IT Professionals have to install complete solutions, such as Enterprise Resource Planning (ERP) or Customer Relationship Management (CRM) applications, not just a database in isolation. So how do you identify applications that are scalable and avoid common bottleneck to ensure that they remain scalable? And how do you evaluate various solutions to ensure they will meet your scalability requirements without going to the time and expense of installing and testing each configuration yourself?
Fortunately, there are industry-standard benchmarks to assist in selecting well-scaling applications for various applications available at . The benchmarks from TPC-C include transaction throughput rating for both clustered and non-clustered configurations.
Implementing a Scalable Architecture12