Most applications perform all three functions—for example, Microsoft Word. However, to be scalable, an application needs to perform more work than one computer can manage.
In the client/server model, for example, components of an application cooperate while running from two or more computers. One part of the application handles user interaction and local processing while another part performs back-end processing. An example of the client/server model is the interaction of Microsoft Office and Microsoft Exchange Server, which work together to provide group collaboration. Multi-tiered (i.e., n-tiered) applications spread tasks around to different computers to increase efficiency.
Microsoft has provided a standard—COM—for creating distributable parts (i.e., components) of an application. Developers use COM to create reusable application components that can cooperate in a distributed computing environment. Microsoft's .NET Server architecture defines n-tier applications as applications that you can divide into specific functions that you can implement as components. The first tier, on which user interaction occurs, is called User Services or Presentation Services. The middle tier—called Business Logic—takes input from User Services and queries the back-end tier, which is called Data Store.
N-tiered applications leverage Microsoft's development, scalability, and high-availability technologies. For now, SQL Server 2000 is the only application to take full advantage of Datacenter's large memory space and 4-node clustering. Soon, however, you might be able to add Oracle and Microsoft Exchange 2000 Server (postService Pack 1—SP1) to the Datacenter list of one. Further testing will determine whether Oracle and Exchange 2000 will be good applications for Datacenter.
Microsoft provides clustering technologies that are appropriate for each of the three application tiers. (For more information about Microsoft clustering technologies, see Greg Todd, "Microsoft Clustering Solutions," November 2000.) For an application's Presentation Services tier, use IIS 5.0 on an NLB cluster. (Be sure to implement IIS's reliable restart enhancement, which lets the Web service automatically attempt a restart after failure.) NLB, which Microsoft introduced in Win2K AS, supports as many as 32 nodes per cluster. NLB provides stateless clustering with stateful connections to client browsers.
Alternatively, you can use Cisco Systems' LocalDirector (CLD) hardware solution to load-balance IP traffic. You might prefer CLD because of its support for network switches. (NLB requires hubs in conjunction with switches because of NLB-induced switch flooding.) Although many claim that using IIS on Datacenter with Cluster service is a reasonable first-tier solution, I recommend Win2K AS running IIS and NLB clusters—a solution that provides scalability, availability, and control at a relatively low cost.
Using a CLB cluster on any Win2K server supports the Business Logic tier. CLB lets you load-balance COM components across multiple computers and requires Microsoft Application Center 2000, which provides management tools for CLB and NLB clusters in a highly distributed environment. CLB also dynamically load-balances COM+ components, which are an enhancement to COM components. CLB clustering is good for stateless components and supports as many as 16 nodes. Although CLB runs on Win2K Server, Win2K AS, and Datacenter, your OS decision will depend largely on the nature and scaling requirements of your components.
If your application is stateful, you need the Datacenter implementation of Cluster service to scale out beyond two nodes. (Cluster service is the clustering technology of choice for stateful applications, whereas NLB and CLB are clustering technologies best suited for stateless applications such as IIS and Win2K Terminal Services for NLB and COM+ for CLB.) You need Datacenter to scale up above the eight-processor SMP and 8GB limit of Win2K AS.
Even for an application that doesn't take advantage of Datacenter's large memory space, you might see substantial benefits if you run the application on a Datacenter system with lots of memory. The large system cache and reduced physical paging could have major performance benefits.
Finally, you might experience performance benefits if you use Datacenter's WSD for communications with the Data Store tier. (WSD lets two computers communicate over an extremely high-speed network link.)
For the final tier of a standard n-tier architecture—the Data Store tier—I recommend Datacenter. The large memory requirements of terabyte databases and SQL Server 2000's Physical Address Extension (PAE) support benefit from the scale-up that Datacenter's 64GB of RAM permits. Exchange Server SP1 will likely find support on Datacenter, but it doesn't yet take advantage of the large memory space.
Applications that don't use COM components can still benefit from Datacenter. To take best advantage of 4-node clustering, you should modify these applications to use the Cluster service Cluster API. (The Cluster API features several functions that let applications respond to cluster messages and report their status back to Cluster service.) Best use of Datacenter's large amount of memory requires that you add AWE to your applications. (AWE is a Microsoft API that lets developers take full advantage of the 64GB of RAM that Datacenter supports.) Unmodified applications can still benefit from Cluster service and PAE, just not as much.
For all applications that use Cluster service, you need to enable the use of checkpoint files so that application data recovery occurs. As I mentioned earlier, checkpoint files are important for recovering the transactions that are in memory when a cluster node fails.
The decision to modify a large database application to use AWE or to be cluster-aware (i.e., incorporate the Cluster API) might need substantial justification. You should initiate any change to a mission-critical application with a Request for Change (RFC) and go through the same justification process you would with any other RFC.
For applications that use COM+, development might be easier: COM+ components are typically small and easy to modify. Stateful COM+ components don't perform nearly as well as their stateless counterparts. Storing and recovering component-state information limits the reusability of COM+ components. You can modify stateful COM+ components to become stateless or to store state information in the Data Store tier. For example, in Visual Basic (VB) applications, a Property Bag object holds state information. You can rewrite the VB code to avoid the use of the property bag and instead use Active Data Objects (ADO) to store state information in a different machine's database table.
Prev. page
1
2
[3]
4
next page 
