Server Farms: Application Center 2000 Offers World-Class Scalability

s the traffic on your Web site increases, you need to find a way to handle the load. It is rarely feasible to upgrade to the latest computer model or even to predict the load in advance. Therefore, you need a scalable solution to manage the load, one that starts with one or two computers and scales to multiple computers as the load increases. Most of the high-volume Web sites handle their load through a Web server farm, a set of autonomous computers that work together to provide the illusion of a single, very powerful server. This configuration also provides high availability; if one of the computers goes down for maintenance or hardware failure, users will not notice.
      If you've been deploying Web server farms on Windows®, Microsoft® Application Center 2000 is the product you wish you had yesterday. Application Center 2000 simplifies the deployment and management of a Windows-based application to a set of computers. In addition, it provides a load balancing solution for COM+ components. The Component Load Balancing (CLB) Service is ideal for computationally intensive services that require the middle tier to be deployed in a different physical layer.
      After explaining Application Center 2000 clusters, its applications and architecture, I'll explain how Application Center 2000 handles load balancing for applications and COM+ components. Although this article's primary purpose is to cover application deployment with Application Center 2000, I'll briefly cover the monitoring features and the options for scripting common administration tasks.
      This article is based on the Beta 2 release of Application Center 2000. Some details might have changed by the time you read this article.

Application Center 2000 Clusters

      Windows DNA originally supported one kind of cluster, a Microsoft Clustering Service (MSCS) cluster. An MSCS cluster is a set of computers which provide failover of server application resources like database or message queues. At any time, an instance of a service is provided by only one of the computers in the cluster. If the computer that provides the service fails, another computer in the cluster picks up the resources of the service and starts providing the service. A distributed system service running on the cluster notifies applications about these events and ensures that only one computer owns the resources at a time. MSCS also required a shared disk resource.
      The .NET Enterprise Servers introduce (or more accurately, formalize) a second kind of cluster, the Application Center 2000 cluster. An Application Center 2000 cluster is a set of shared-nothing, loosely coupled computers that appear as one virtual computer. Unlike MSCS clusters, all the computers in Application Center 2000 clusters provide the same service (Web application) at the same time. As requests arrive, they are delivered to any computer in the cluster. When a computer fails, future requests will be sent to other computers in the cluster. This lets Application Center 2000 clusters provide for both scalability and high availability of services.
      Any application written from scratch could be written for either model. However, if you want to port an existing application to take advantage of multiple computers, the picture is different. Application Center clusters are ideal for applications that either do not share any state or share read-only state. For instance, a Web server serving static or dynamic content is an ideal candidate for an Application Center 2000 cluster. On the other hand, MSCS clusters are better suited for services that share a lot of read/write data. Microsoft SQL Serverâ„¢ and Exchange Server are good examples of such applications. Future versions of MSCS are expected to provide support for load balancing and for a greater number of computers in a cluster, blurring the distinction between the two types of clusters. (Note that throughout the rest of this article I will refer to Application Center 2000 clusters simply as clusters.)


Figure 1Clustering Architecture

      An end-to-end system designed for the Microsoft platform will most likely contain both of these technologies. As you can see in Figure 1, Microsoft Clustering Service is used for the data servers while Application Center 2000 clustering is used for the Web and COM+ load balancing. (Firewalls and other networking devices are omitted for clarity.)


Figure 2Application Center Versatility

      There are three types of clusters that can use the Application Center technology: Web clusters, COM+ application clusters, and COM+ routing clusters (see Figure 2). Depending on the load and the way your application is used, you might use Application Center in one or more of these scenarios. Using the Network Load Balancing (NLB) Service or other hardware-based load-balancing products, the Web cluster distributes HTTP requests to a set of Web servers. Note that Windows 2000 Advanced Server is not required to run NLB. Application Center 2000 enables NLB to run on Windows 2000 Server as well. COM+ application clusters handle DCOM traffic. In most cases COM+ routing clusters are not required.

Application Center 2000 Applications

      In the early days, an application was synonymous with a monolithic executable program. In the new component world introduced with Microsoft Transaction Services (MTS) and improved with COM+, an application is a set of configured components. Application Center 2000 takes an even more liberal view of what an application is. In Application Center 2000 an application is a collection of the following resources:

• Web sites and their related configurations (such as certificates).
  
  • File system hierarchies (and related permissions Centers).
    
    • COM+ applications.
      
      • Registry hierarchies.
        
        • ODBC data sources (DSNs).
          

      If you have ever packaged an application for deployment to a data center, these pieces should be familiar to you. In the rest of the article when I refer to an application I'm referring to an Application Center 2000 application.

The Application Center Architecture

      The Application Center architecture consists of three layers: the user interface, the feature set, and the operating system (see Figure 3).


Figure 3Application Center 2000 Architecture

The top layer is the user interface. There are three user interfaces: the Microsoft Management Console (MMC) snap-in (see Figure 4), a Web browser interface (primarily read- only for viewing status), and a command-line interface. In the middle layer the feature set is responsible for most of the functionality of the product. The Application Center Cluster Service is responsible for maintaining cluster membership and state information. The synchronization and deployment service is responsible for maintaining the cluster members in synchronization with the cluster controller, both in terms of configuration (network settings) and content (Application Center applications). In addition, the deployment module provides services for staging and deploying both intra- and inter-cluster applications. The load balancing subsystem synchronizes the settings of NLB (and other network settings) on every computer in the cluster.


Figure 4Managing Application Center with MMC

      Application Center also offers a request-forwarding service in the form of an ISAPI filter and extension. This mechanism aids in maintaining session state across the cluster to alleviate the mega-proxy problem, as well as to transparently route Microsoft FrontPage® and WebDAV publishing requests to the cluster controller. The monitoring, logging, and health services subsystems aggregate information from all the members of the cluster.
      At the bottom layer is the operating system and its services. The Microsoft Management Console 1.2 and Microsoft Internet Explorer technologies (DHTML, VML, XML) are used extensively for the UI service. Windows Management Instrumentation (WMI) is used to collect management information. The metabase in Microsoft Internet Information Services (IIS) 5.0 is used to store cluster and server configuration settings. Network Load Balancing is integrated with the product, but is not a requirement. Finally, the Microsoft SQL Server 2000 Desktop Engine is used extensively to store logging and monitoring information.

The Cluster Controller

      Every cluster needs a machine that is designated as the cluster controller. The cluster controller is usually the first machine to join the cluster. This can be changed at any point to add increased reliability (that is, if the controller dies for any reason, the user can immediately elect another cluster member to take over the role of controller).
      The concept is that you install your applications on the cluster controller and the cluster controller coordinates with the other computers of the cluster to synch the applications and future changes.
      Every machine in the cluster needs to have Application Center 2000 installed. Application Center 2000 requires Windows 2000 Server or Advanced Server with Service Pack 1. The computer should have at least 256MB RAM and about 130MB free disk space. In addition, if you plan to use NLB you will need two network adapters.


Figure 5Application Center MMC Snap-in

      An administrator manages the cluster through the MMC shown in Figure 4. You can control the membership in the cluster and define applications through the snap-in (see Figure 5). For instance, as you can see in Figure 5, my example contains a Web application called library. The application has its files stored under the path c:\program files\HealtheonWebMD. It has a Web site called Library and is configured using the IIS component. All the COM+ components have been configured through the Component Services Snap-in into a COM+ application called library. Finally, the registry entry under HKEY_ LOCAL_MACHINE/Software/Healtheon is part of the library application because it contains settings such as the connection string to a data source. Next time I synchronize the cluster, all the computers in the cluster will have the same keys and values. The same goes for the COM+ application, the Web site settings, and the file path. If you've ever had a cluster of 10 computers and you needed to change a registry entry, you will really appreciate this feature.

IP Load Balancing

      So let's say you set up your cluster and replicated your content and applications to all the machines. You're ready to serve your customers, but wait a minute. Which IP address are you going to give them? If you provide the IP address of any of the computers in the cluster, then this computer will get overloaded. You really want to provide one address and have the requests distributed to the members of the cluster dynamically. The traditional DNS round-robin solution maps one DNS domain name to multiple IP addresses. Although this solution has served a number of Web sites well, it has problems in case of failures because the mappings from DNS names to DNS addresses are cached.
      Better solutions are based on a virtual IP address that is dynamically mapped to one of the real IP addresses. For instance, let's say that you have three servers with addresses 10.4.0.10, 10.4.0.11, and 10.4.0.12. Using a virtual IP address, such as 10.4.0.15, all your requests will be coming to the virtual IP address and then routed to one of the servers. The virtual IP may be set up through software such as NLB or hardware. If hardware is used in a production environment you should probably use two such devices to avoid a single point of failure.
      With Windows NT® 4.0 and Windows 2000 there is a software solution to address the mapping problem. Network Load Balancing comes as part of Windows 2000 Advanced Server and Windows 2000 Datacenter Server (also available in Windows 2000 Server with Application Center 2000). When you deploy NLB with Application Center you will need two Network Interface Cards (NICs) on every machine. NLB is then bound to one of the NICs. When a request is sent to the virtual address, the request is delivered to the networking subsystem of all the computers in the cluster. Yet only one computer processes the request. The computers communicate at regular intervals to decide which one will pick up which packets. When a machine in the cluster fails, the load is automatically redistributed among those remaining.
      NLB supports up to 32 servers per cluster. On clusters of up to 12 nodes, the maximum cluster supported by Application Center, measurements have shown that the CPU overhead is pretty low. For instance, on a four-server cluster that handles traffic of 100MB/sec, Microsoft measured the overhead from filtering and data transfer to be only about 4 to 7 percent on one processor on each server. In addition, since only a small portion of NLB CPU overhead contributes to latency, throughput and response time scale almost linearly as the number of the servers in the cluster increases. For more details on the performance of NLB, please check https://www.microsoft.com/windows2000/techinfo/howitworks/cluster/nlb.asp.

Component Load Balancing

      In a multitier application using Windows 2000 you could decide to deploy different logical tiers to different physical clusters. This makes a lot of sense when one application is very demanding on computation resources. For instance, the core function of search is a good example of an application tier that you would like to put in its own cluster. Now assuming that your search function is written as a COM+ application, you are again faced with the problem of load balancing requests. In the Web server case, the requests were HTTP requests from Web browsers to Web servers. In this case, the requests come from COM/COM+ clients (an ASP page which activates a COM+ application) to COM+ servers. Several articles in MSDN® and elsewhere have discussed this issue, including Don Box's ActiveX®/COM Q&A in the July 1997 issue of MSJ. All of these articles require a certain degree of custom programming.
      CLB ships as part of Application Center 2000 and allows COM+ load balancing without any custom programming. To use CLB you need to install Application Center 2000 and your COM+ application on both the calling tier (usually the Web server cluster) and the callee tier. In the calling tier, you mark your components for load balancing from the Components Services Snap-in (see Figure 6). Check the option "Component supports dynamic load balancing" to cause calls to this component to be load balanced among the servers in the CLB routing list. You'll also see that load balancing is not supported for components that support events.
      In addition, you need to create a list of the computers where requests will be routed. You do this from the Application Center 2000 snap-in MMC or from the command-line tool.


Figure 6Component Services Snap-in

      Putting your COM+ applications in a different cluster from the Web servers might not always be the best approach. On the upside, multiple Web clusters can share a single COM+ cluster and you can separate the Web applications from COM+ applications. On the downside, you'll experience greater latency, the solution will be more complex to administer, and you will have to decide up front how to partition your hardware between the two layers. Take a careful look at your application and your experience on running multiple clusters before you make the decision.

Monitoring Your Cluster

      This article focuses on the features offered by Application Center to deploy applications, but I will quickly mention its powerful monitoring capabilities. My favorite is the ability to monitor events from all the machines in one display, as shown in Figure 7. The operator can filter events based on the machine they are coming from, their severity, or the application that generated them. In addition, the operator can monitor a number of counters (see Figure 4).


Figure 7Monitoring All Machines at Once

      Finally, the system administrator can associate performance counters with certain thresholds. The thresholds can be set on a global (whole cluster) or local (certain machine) basis. When a threshold is exceeded, an action is taken. Figure 8 shows a number of possible actions. Note that Application Center offers the ability to replicate your monitors, threshold, and actions across a clusterâ€"which means you can define such concepts on the controller and automatically have them applied to all members.

Scripting Application Center 2000

      I love graphical user interfaces because they allow you to quickly explore the features of a product. On the other hand, I hate doing the same thing again and again from the development cluster, the staging cluster, and the production cluster. Fortunately, most products coming out of Redmond in the past few years, including Application Center, provide both graphical interfaces and programmatic administrative interfaces.
      When I first tried the product, I expected to find an Automation-based API that I could script from my favorite scripting language. It turns out that this is not the case. Instead, Microsoft ships a command-line program, called Application Center that can be used either directly from an MS-DOS®-based batch file or indirectly from JScript® or VBScript through the Windows Script Host (WSH) objects.
      The command line allows you to perform most of the functions that are also available from the GUI. For instance, the code in Figure 9 shows how to create a new cluster, add a few machines, create an application, and then deploy it.

Conclusion

      Building highly available and scalable computing facilities using ordinary hardware has been a dream for quite some time. The hardware to make it possible has been there, but the cost of managing such a cluster has been pretty high, contributing to the overall total cost of ownership. Now, Application Center 2000 provides the software layer that will ease the management of such a cluster.