Choosing Application Center to Manage a Web Farm
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
This article is excerpted from Deploying and Managing Microsoft .NET Web Farms (Sams, 2001, ISBN: 0672320576).
Many of the actions and tasks in this book have sorely needed a tool like Application Center 2000. First and foremost, Application Center 2000 solves the application replication problem. Application Center simplifies the process of scaling so that a Web farm can handle its load easily. Application Center centralizes management and monitoring of multiple servers. Finally, Application Center 2000 provides an easy way to stage and deploy new releases.
Replicating Applications with Application Center 2000
Application replication is a serious problem for medium-to-large-scale Web farms. When a Web cluster has more than a few members, the process of application replication must be scripted and automated. If it is not, then the process of manually updating a Web site with a new release could take a very long time. Until Application Center 2000, Content Replication System (CRS, also known as Site Server Publishing) was the only tool available from Microsoft that could be used for application replication. However, CRS only replicates the contents of directories and the supporting directory structure. Figure 1 is an example of the clunky CRS interface. Eight different tabs with archaic and hard-to-use features make CRS difficult to configure. Just managing file exclude and include paths for directory replication is error-prone and poorly designed. CRS cannot replicate other typical application components automatically. Replicating Registry entries, IIS metabase information, Data Source Names for ODBC, and COM+ applications is accomplished by custom scripts. These scripts run before or after a replication job. Clearly, CRS is not good enough to manage a complicated .NET Web farm.
){kind=link}
Figure 1 The CRS user interface, a nightmare.
With Application Center 2000, application replication for Web farms issolved. The clunky interface of CRS has been abandoned for a flashy new explorerinterface. COM+ applications, IIS metabase settings, ODBC connection strings,Registry entries, and file system paths are all part of an Application Centerapplication object. This application object is easily configured from onemanagement console, and no custom scripts are required. When deploying, all thepieces of the application object sync with the configuration of the clustercontroller. Once an application object is defined, it becomes a conceptualscript that Application Center executes on each of the cluster members. Figure 2 shows the flow of an application object through an Application Center 2000cluster.
){kind=link}
Figure 2 An application object in Application Center 2000.
The application object is easily modified to include new objects. Forexample, a change control requires a new COM+ application. In the past, thedeployment team would likely manually install the exported COM+ application oneach machine in the cluster. A manual process is likely to fail at some point.With Application Center 2000, the deployment team manually configures the newCOM+ application exactly as needed on the one cluster controller. They add theCOM+ application to the application object, telling Application Center 2000 tosynchronize the cluster. Within a matter of minutes, the new COM+ application isavailable on the other cluster members, configured exactly like the clustercontroller.
NOTE
A cluster controller is an Application Center 2000 server that has the master copy of the application. All deployments and cluster synchronizations originate from this server.
If an application has pieces that don't fit within the scope of the Application Center 2000 object, it is possible to write custom scripts that will be executed from deployment events on each cluster member. Replication of any application configuration is possible with Application Center 2000 custom scripting.
Scaling with Application Center 2000
Scaling to handle load is a critical success factor for any .NET Web farm. Once an application is able to run across multiple servers, the process of scaling a site is simply adding server capacity to the stressed portion of a site. The challenge then is to replicate the application parts to the new server and add it to the cluster.
Application Center 2000 simplifies adding and removing cluster members for scaling. After installing Application Center 2000 on each new cluster member, a simple two-step process can bring a new server online. In its default configuration, Application Center 2000 uses Network Load Balancing (NLB) as its scaling solution. NLB configuration is done automatically to each server when it is added to the cluster. From the management console, the Add Cluster Member Wizard adds the server to the cluster. During the addition process, the cluster controller configures NLB and readies the new machine to coalesce with the cluster so that it can begin receiving traffic. Figure 3 shows the Add Cluster Member Wizard, the first step to smooth scaling
){kind=link}
Figure 3 The Add Cluster Member Wizard.
At this point, if the cluster controller is set up with the default configuration options, the applications on the cluster controller will automatically synchronize to the new member. Once this synchronization is complete, the new cluster member is ready to be brought online through the management console. Since Application Center 2000 is highly integrated with Network Load Balancing, the server can begin handling Web requests immediately. A two-step process scales any Web farm.
This flexibility in scaling allows for some creative management of resources. In a large Web farm, there could be any number of under-utilized servers at one time. With the dynamic cluster member management and automated synchronization processes, those servers could stop serving the under-utilized content and begin serving the stressed content in a matter of minutes. Scenarios like those in Figure 4 show creative ways to maximize return on hardware investments.
){kind=link}
Figure 4 Using Application Center 2000 to maximize hardware utilization.
Using Application Center 2000 for COM+ Load Balancing
COM+ is a great way to create component-based services. COM+ also greatly simplifies the process of deploying and accessing COM+ application services locally and remotely. Application Center adds to this architecture by allowing COM+ applications to replicate with a Web application. For example, if a Web site uses a COM+ application to handle login or credit card authorization, Application Center can be configured to group these objects with the Web pages and replicate them as one unit. Application Center also introduces the concept of COM+ routing clusters and COM+ application clusters to provide fail-over and redundancy.
Without Application Center, a COM+ application proxy installed on a Web server pointing to a COM+ application server is a single point of failure. If that COM+ application server fails, there is no built-in mechanism for COM+ to begin making remote component requests to a backup machine automatically. While it is possible to use standard load balancing technology like Network Load Balancing to achieve COM+ application server scaling, in reality this only provides high availability. In any case, Application Center solves these problems with COM+ application and routing clusters.
A COM+ application cluster is a group of servers configured with the same COM+ applications. With Application Center 2000, these members are managed and synchronized in the same way as a Web cluster. Once again, a deployment team has only to configure a new COM+ application on the cluster controller. Then, with the same synchronization technology as a Web cluster, Application Center deploys the COM+ application to all members of the cluster. COM+ clusters can use Component Load Balancing or Network Load Balancing to achieve scalability and availability of COM+ clusters.
A COM+ routing cluster is the third type of cluster supported by Application Center 2000. A COM+ routing cluster allows a single client server to address more than one COM+ cluster that uses CLB, a limitation of the current implementation of CLB in Application Center 2000. Figure 5 shows a COM+ routing cluster associated with a COM+ cluster.
){kind=link}
Figure 5 A COM+ routing and application cluster.
Another important aspect of the COM+ Application Center enhancements is the addition of a WMI provider (see the following section for more on WMI) for COM+. With this, it is possible to monitor the health of COM+ applications using Application Center 2000. The provider is also used by Application Center 2000 Component Load Balancing to decide which member of a COM+ application cluster activates a component for any request.
By providing scalable COM+ solutions, Application Center eliminates the single point of failure when accessing a COM+ object remotely. When a COM+ application cluster member fails and is taken offline, requests are not sent to the ailing member until the problem is resolved. Application Center 2000 finally delivers a highly available, highly scalable COM+ solution for the enterprise.
Monitoring a Web Farm Is Centralized
Like application replication, monitoring a Web farm is a complex problem. With large application clusters, the administration of monitoring tasks can become time consuming and error prone. Worse than that, monitoring a Web farm for a specific problem is sometimes the only way to tell if an application is failing. Sometimes a problem has no solution, and alerting an administrator who can address the problem manually is the only way to restore functionality. With no simple way to deploy monitoring configurations, the deployment team will bog down in the day-to-day operations and monitoring tasks of a Web farm.
Currently there are a number of different monitoring tools from Microsoft but nothing centralized and useful. For instance, Performance Monitor can alert at different thresholds in a real-time log. This is useful, but hardly an enterprise solution. There are third-party tools that provide an all-in-one solution, but they are proprietary.
With Windows 2000, Microsoft introduced Windows Management Instrumentation (WMI). WMI is Microsoft's unified monitoring API. WMI is a collection of COM interfaces that provide programmatic monitoring information in real-time. Similar to SNMP, WMI provides makers of server technologies, device drivers, and other system-level devices a way to expose monitoring information to a common, scriptable API. All .NET enterprise servers come with some level of WMI support.
With Application Center 2000, Microsoft delivers its unified application health-monitoring console, aptly named Health Monitor. Health Monitor provides a way to examine the state of a Web farm centrally in real-time. Health Monitor examines each member of a cluster and can report back information to a single management console. This console creates a Web farm command station where deployment status, application health, and availability are measured. Figure 6 shows the Health Monitor console.
){kind=link}
Figure 6 The Health Monitor console.
Health Monitor can alert on the entire standard performance counter list. Administrators can create alerts for low disk space conditions and on high CPU utilization conditions. Health Monitor reacts to user-definable alerts and responds with user-definable actions. Any WMI provider can be used to generate alerts. Actions include sending e-mail, launching scripts, running batch jobs, writing events to a file, and adding entries in the event log.
Managing the Staging of Releases with Application Center 2000
Application Center 2000 makes multiple stage deployment of Web applications easy. Without Application Center 2000, deployment from testing to staging and staging to production is at best a conglomeration of actions such as copying directories, running scripts, and other manual tasks. The staging of releases is as simple as scheduling a task. Application Center can replicate applications across clusters by using the same technology for deploying applications between members of the same cluster.