Chapter 2 - Feature Overview

This chapter provides an overview of Microsoft Application Center 2000 (Application Center) and examines the customer requirements that influenced its design. Following this, the product feature set is presented, which will illustrate how Application Center addresses the server farm scalability and management issues that are identified in Chapter 1, "Scaling Business Web Sites with Application Center."

On This Page

Application Center Overview
Application Center Feature Summary
Application Center Cluster Services
Load Balancing
Synchronization and Deployment
Monitoring
Programmatic Support
Local and Remote Administration
High Availability
Online Help
Resources

Application Center Overview

Application Center is a tool for creating, deploying, and managing Web- and component-based applications. Typically, these are line-of-business applications that require a high level of availability and need to provide acceptable response time. The servers hosting these applications are expected to handle traffic that is characterized by high volumes, exponential growth curves, and load fluctuations.

This software-based solution is designed to provide the capital cost advantages of the scale-out model, while at the same time providing reduced operations costs—one of the main advantages espoused by proponents of the scale-up model.

In addition to these cost benefits, Application Center provides:

• Manageability**—**Through a centralized management console that is minimal and familiar. This console is used to organize and manage replication, load balancing, and the monitoring of Web and COM+ applications. 

• Scalability**—**That is both linear and flexible. Additional servers can be added to a cluster as needed to accommodate seasonal peaks and removed (and reallocated within the organization) as the load decreases. 

• Reliability**—**By eliminating the single point of failure associated with scaling up or hardware-based load balancing. It also transparently removes a server from operation in the event of a hardware or software failure. 

Good performance, of course, is desirable in any product. In addition to offering optimal load balancing algorithms for different types of applications, Application Center provides tools for monitoring system performance and allows the system administrator to adjust load on a server-by-server basis. This approach recognizes the realities of heterogeneous server farms and provides far greater flexibility than the one-size-fits-all approach.

Design Goals

In addition to providing the benefits itemized in the preceding section, Application Center had to meet specific design goals. These goals were the result of numerous visits to customer sites, focus groups, and consumer surveys that took place before any product design began.

Customer Suggestions

The customers said:

We need integrated tools for managing deployment on a group of servers.

Users could configure load-balanced Web and COM+ servers, but in order to deploy content they had to manually propagate resources with a series of complex and difficult-to-maintain in-house scripts.

NLB is too detailed and complicated for generic implementations.

This interface exposed far more configuration detail than was needed, such as dedicated IP addresses and port rules.

Monitoring and capacity analysis tools need to be integrated with application tools.

Users had to navigate through different tools and interfaces to gather basic information about a Web site or COM+ application.

There should be some central concept of what constitutes an application—its elements and their relationship to each other.

Beyond the pages that are served, Web sites do not imply any additional elements or settings that are associated with the site. For example, COM+ applications may be required for proper site functionality, but this relationship is never expressed nor discovered through any of the tools.

Design Goals

The following goals are highlights from the vision statement that was prepared in response to customer feedback:

• Provide easy administration of Web and COM+ applications on multiple server groups. 

• Provide a taxonomy and user interface that will be easy to use, browsable, scalable, searchable, and minimal. 

• Increase the discoverability of most-used settings; bury or eliminate advanced settings. 

• Provide easy access to related partner configuration tools (that is, Microsoft Internet Information Services [IIS], COM+, and Microsoft Health Monitor). 

Application Center Feature Summary

Note The features that are summarized in Table 2.1 provide the essential tools needed to let you easily create and manage load-balanced clusters. Different elements of the product feature set are accessible through its Microsoft Management Console (MMC) snap-in or via the Web browser.

Table 2.1 ApplicationCenter Feature Set Summary 

Feature	Description
Cluster services	Common tasks for administering the cluster configuration (for example, creating a cluster or adding a member) are easy to execute by using wizards or the graphical user interface.
Load balancing	Application Center supports Network Load Balancing (integrated NLB) and Component Load Balancing (CLB).
Synchronization and deployment	System settings, content, and applications are replicated across the cluster, either automatically or on demand. Content can be deployed within a cluster or to another cluster.
Monitoring	Real-time event, performance, and health monitoring are supported, and historical data is accessible.
Programmatic support	Scripting support is available for performing common Application Center management tasks and accessing the event and monitoring data. Selected administrative tasks can be completed with a set of command-line tools.
Local and remote administration	A cluster can be administered locally or through a secure remote connection.
High availability	Requests and transactions are automatically rerouted to another member if a server failure occurs.

Let's examine these features in more detail, beginning with cluster services.

Application Center Cluster Services

The cluster services provided by Application Center support the creation and general administration of the cluster infrastructure—from creating a cluster to adding or removing members.

For detailed information about this feature, see Chapter 4, "Cluster Services." 

Cluster Creation

Application Center makes it very easy for you to create a cluster of servers. The New Cluster Wizard, beginning with the page shown in Figure 2.1, steps you through the creation and configuration process.

The design goal was to enable a user to create a fully functional cluster as easily and as quickly as possible. As you can see by the New Cluster Wizard pages summary in Table 2.2, this objective was reached by minimizing the amount of user input needed and by requiring a minimal number of user decision points in the creation process.

Figure 2.1 Pages in the New Cluster Wizard 

The New Cluster Wizard pages and their descriptions are summarized in the next table.

Table 2.2 New Cluster Wizard Pages 

Wizard page	Description
Welcome to the New Cluster Wizard	Starts the process and explains what the wizard does.
Analyzing Server Configuration	The target server is analyzed to see if its configuration is adequate for serving as a cluster controller.
Cluster Name and Description	Used to name the cluster and provide an optional description of the cluster.
Cluster Type	Used to identify the primary type of content that will be served on the cluster. This determines which load balancing option should be used.
Network Load Balancing (NLB) Setting	This page only appears if a current installation of NLB is bound to a network adapter. The existing NLB settings can be retained or new ones can be configured.
Load Balancing	Used to identify whether the cluster will use NLB load balancing, other load balancing, or no load balancing.
Load Balancing Options	Used to identify the network adaptor that will be used for load balancing.
Cluster Type	Used to identify the types of Web sites that the cluster will service.
Monitoring Notifications	Enables the administrator to set up default and general monitoring services (such as a Simple Mail Transfer Protocol [SMTP] server or an e-mail address for notifications).
Completing the New Cluster Wizard	Triggers completion of the process; notifies the user if cluster creation was successful.

Once the cluster is created successfully and you close the wizard, the console tree of the MMC displays a cluster hierarchy similar to the one shown in Figure 2.2. You now have a cluster that consists of one member—the cluster controller. From this point you can scale out the cluster by adding additional members.

Figure 2.2 MMC console tree for a cluster 

The settings you choose during this process provide the foundation for a load balanced, fully synchronized cluster. Even without any tuning, this base configuration will deliver balanced performance by re-balancing the cluster load as you scale out. (Later sections cover the mechanisms that are available for fine-tuning the cluster or an individual member.)

Cluster Administration

For our purposes, administrative tasks are those that deal with the composition of a cluster and the current state of its members. These tasks include activities such as adding a server to a cluster or taking a member offline. A summary and brief description of each administrative task is provided in Table 2.3.

Table 2.3 Cluster Administrative Tasks 

Wizard/menu name	Description
Add Server to Cluster	The task of adding a server to a cluster is accomplished by using a wizard. See the next section, "The Add Cluster Member Wizard."
Remove Server from Cluster	Removes the specified server from a cluster.
Restart a Server	Restart a server, if required (for example, if you have installed new components).
Change the Cluster Controller	Promote a cluster member to controller (for example, if the current controller has failed so that a new controller is required).
Disband Cluster	Completely disband the cluster and leave the remaining server as a standalone server.

The Add Cluster Member Wizard

One of the early administrative tasks is adding a server to a cluster after the cluster has been created. Once again—in keeping with the ease-of-use design goal—a wizard is available for this task. The Add Cluster Member Wizard (Figure 2.3) is launched from the cluster pop-up menu in the MMC console.

Figure 2.3 Pages for the Add Cluster Member Wizard 

Table 2.4 describes the Add Cluster Member Wizard pages.

Table 2.4 Add Cluster Member Wizard Pages 

Wizard page	Description
Welcome to the Add Cluster Member Wizard	Starts the process, explains what the wizard does, and provides these warnings: · Server content will be overwritten when the member is synchronized with the controller. · Two network adapters are required for Network Load Balancing.
Name and Credentials	Used to specify the server to add, either by browsing or by entering the server name or IP address. The current user must have, or be able to provide credentials for, a user account with administrative privileges in order to continue.
Controller Name(1)	Used to identify the controller for the cluster to which the server will be added. This is done either by browsing or by entering the controller name/IP address. In order to continue, the current user must have, or be able to, provide credentials for an account with administrative privileges.
Analyzing Server Configuration	The specified server configuration is analyzed to ensure that it is configured adequately and is eligible to be added.
Cluster Member Options	Used to specify a network adapter to use in an NLB cluster.
Completing the Add Cluster Member Wizard	Triggers completion of the process; notifies the user whether the server was added to the cluster successfully.

1 This page is not shown when running the wizard from a cluster where the controller is assumed to be the current controller.

Load Balancing

Application Center provides several alternatives for implementing load balancing on a cluster. (See "Cluster Type" in "Table 2.2, New Cluster Wizard Pages.") In addition to the controller configuration, the type of application that will be hosted on the cluster will determine which of the following load balancing options you should select:

• Integrated NLB 

• CLB 

• No load balancing 

For detailed information about this feature, see Chapter 5, "Load Balancing." 

Let's start by examining integrated NLB.

Integrated NLB

With this option, load balancing is actually carried out by the NLB that's part of Microsoft Windows 2000 Advanced Server. Application Center only provides an interface that's integrated with NLB.

Note NLB is a distributed IP-level load-balancing solution that works by having cluster members see the packets sent to the virtual IP (VIP) addresses associated with a cluster. Which member actually processes a particular packet depends on the load-balancing rules that are in effect.

The Application Center user interface serves to make load balancing configuration for a cluster easier by removing much of the configuration detail and, through the use of a wizard, by reducing the number of user decision points. The wizard also conducts hardware and software diagnostics to ensure that a minimal workable platform is available to support load balancing (for example, it checks for the correct number of network adapters and IP addresses).

The main element of the NLB configuration for your cluster is selecting an appropriate load-balancing algorithm for the cluster. This algorithm, or affinity, is based on the source of the bulk of the incoming client requests. Application Center integrated NLB uses three types of affinity (described in Table 2.5) settings to identify the algorithm that will be used.

Table 2.5 Load Balancing Affinity Settings 

Affinity	Description
None	Multiple requests from the same client can access any cluster member. The IP address and port number identifies the client.
Single	Multiple requests from the same client must access the same cluster member. This is the default setting for intranet clients. The IP address identifies the client.
Class C	Multiple requests from the same TCP/IP Class C address range must access the same cluster member. This is the default setting for Internet clients because it provides optimum support for "sticky sessions". (1)

1 "Sticky sessions" are sessions in which a client request establishes a server-side state that is used in subsequent requests during the same session. Sticky sessions, or session coherency, are covered in detail in Chapter 5, "Load Balancing."

After you've created a cluster, you can use the MMC console to change the affinity setting for a cluster that's using integrated NLB.

Another load balancing configuration option that's provided by Application Center is the ability to adjust individual server weights in response to performance data or to accommodate different classes of members. You can do this by opening a dialog box, shown in Figure 2.4, from the pop-up menu for a cluster member.

Figure 2.4 Dialog box for adjusting server load balancing 

Finally, you can take any server offline. The Set Offline option removes a server from the load-balancing loop. This is usually done in situations where you've deployed a new application and you want to test it before adding it to the cluster. After testing is finished you can push the content to the controller for replication, and then put the server back online. The Set Offline option is also used for a removing server that is experiencing problems.

Component Load Balancing

CLB is an Application Center service. The decision to use CLB should be based on a thorough analysis of your application requirements before hosting components on back-end servers. There is an inherent system overhead associated with client requests that traverse the network as well as in the process of selecting a server to satisfy the client request. Some scenarios where CLB should be considered are as follows:

• Security is a major concern and you want to segregate COM objects behind an additional firewall. 

• COM objects are relatively "heavy weight" and the fastest server has to be found on which to run them. 

• Applications are partitioned into n-tiers, either for development or design reasons. 

  Information If you're using NLB for your front-end servers and want to route component requests to a back-end COM+ server, the Application Center user interface easily lets you specify a target. 

• Scaling is important—a single cluster can use multiple COM+ clusters to service component requests. 

  Note For applications that use a limited number of, or "light weight," components, instantiating COM objects locally on a front-end Web server may provide the best performance. 

No Load Balancing

There may be situations in which you do not need, or do not want to have, load balancing enabled; for example, it is not necessary for application testing and staging or controller redundancy.

Application Testing and Staging

You can create a cluster for testing and staging that consists of a single server or a small number of members. In this scenario, load balancing isn't really necessary.

Controller Redundancy

In environments where a cluster is quite small, say two or three servers, you may want to have a completely redundant member on standby to serve as a backup controller. You would keep its content synchronized to the active controller, but you wouldn't have it responding to client requests.

Synchronization and Deployment

When talking about replication, it's very easy to think only in terms of Web pages and applications. However, this line of thought deals with only one-half of the issue. What about the servers that actually host and deliver the content? Every aspect of a cluster's composition and configuration needs to be synchronized to the cluster controller.

Application Center deals with both aspects of the synchronization issue by replicating both controller settings and application settings. Partial or full synchronization of a cluster is achieved by replicating configuration and application settings. A replication engine that uses custom drivers makes the links to the various configuration stores and copies their settings to the target servers.

This holistic approach has an added benefit; in the event of a controller failure, you can make any member the new cluster controller. You can do this on the fly, with minor configuration changes to the member.

For detailed information about this feature, see Chapter 6, "Synchronization and Deployment." 

Controller Configuration Settings

The controller configuration settings are vital to the existence and ongoing operation of a cluster. The controller is the one that's deemed to have the correct configuration and content at all times. Its role is analogous to the domain controller in the Microsoft Windows NT domain model. All other cluster members are synchronized to the controller, and all administrative actions are invoked on the controller. (We'll discuss controller operation in more detail in Chapter 4, "Cluster Services," examining its role, election, and change/failover.)

Cluster-related information, such as the cluster name, cluster-wide user accounts and passwords, IP addresses, and various flags (for example, whether or not NLB is in use), are stored. If integrated NLB is implemented, all the required settings—port rules and client affinity, for example—must also be saved and replicated. Finally, several network settings—such as load-balanced IP addresses bound to the NLB network adapter and default gateway settings—must be saved and replicated as well.

Note Only network settings on the NLB-bound network adapter are replicated.

The replication of configuration settings is transparent to the user and done automatically. Most of these settings are copied to all the members, whether they're in the load-balancing loop (online) or not (offline). However, there are some settings that are copied to members that are online only.

Content Publishing and Application Deployment

During the many focus groups that preceded product development, content and application deployment was always identified as one of the top three Web site management issues.

System administrators are in a difficult position; they need to be able to ensure the integrity of operational systems, while at the same time accommodating developer needs. It's not uncommon for some sites to publish new or revised content several times during a day. (Fortunately, application deployment doesn't happen as frequently.) The easiest solution is to let developers put content and applications on the servers. However, this approach usually means that the developers need to be given some administrative privileges—something that most system administrators are reluctant to do.

Another issue is getting content replicated across the appropriate servers in a Web farm. This is perhaps one of the most labor-intensive activities for development and support staff, as well as one of the most error-prone. (Cluster synchronization and content replication is touched on later in this section, but is covered in detail later in the chapter.) It's clear that a robust tool is needed to automate the publishing (deployment) process as well as to manage content and applications after they are in production.

In order to create this tool, the product team first had to define an application. Once the application was defined, they could develop the code that would function in the context of this definition.

The result is support for user-defined, custom applications, a concept that is fundamental to Application Center's publishing and deployment features.

Applications

An application is defined as a collection of all the required software resources for a Web site or COM+ application. For example, an application can consist of Web site content, COM+ applications, certificates, and registry keys. This approach allows the administrator to think of sites as logical groupings. An application may contain more than one Web site, or no Web sites at all, and still be replicated across a cluster.

Important Because an Application Center application is a logical framework for handling anything hosted on a server, Web content is treated as an application.

By using the Applications view (Figure 2.5), you can create an application and identify all the resources that are associated with it. The result is an application definition, which provides the basis for deploying and replicating applications to a member or over the entire cluster.

NoteApplication Center defines four applications by default: Administration Web Site, AllSites, Application Center 2000 Administrative Site, and Default Web Site. The required settings for any published Web site are automatically stored in AllSites, so a custom application definition is not mandatory for Web sites.

Figure 2.5 shows an application definition (ACPFApp), which was created by clicking the New icon on the toolbar. After naming the application, I chose File System Paths from the Resource Type list, and then clicked the Add button. The resulting dialog box (Add Resource – Web Page Dialog) allowed me to browse the registry and select the key to add. You can use the same technique for adding this and other resources in the Resource Type list.

Figure 2.5 The Applications view in the MMC details pane 

The Resource Type list is used either to display existing resources for an application or to add resources. The following resource categories are available from this list:

• COM+ applications 

• Data source names (DSN) 

• File system paths 

• Registry keys 

• Web sites and virtual directories 

After all the resources for an application are identified, you can deploy the application and its contents to a target server, and in this fashion easily set up a staging environment for deploying applications.

Application Deployment

Application deployment is handled by the New Deployment Wizard, which enables you to identify target servers—inside or outside the application source cluster—and applications to deploy. Figure 2.6 shows the start page for the New Deployment Wizard.

Figure 2.6 Pages in the New Deployment Wizard 

Table 2.6 describes the steps used by the New Deployment Wizard when you use it to deploy an application to a target server.

Table 2.6 New Deployment Wizard Pages 

Wizard page	Description
Welcome to the New Deployment Wizard	Starts the process, explains what the wizard does, and warns that resources on the target(s) may be overwritten.
Deployment Target Options	Used to determine if the target is within the same cluster or outside the cluster.
Deployment Target Authentication	Used to submit valid credentials for the target.
Deployment Targets	Used to identify deployment targets.
Deployment Content	Used to select either the entire server image or specific applications for deployment.
Deployment Options	Used to select deployment options, such as whether or not to replicate all file and directory permissions.
Draining Options	Used to specify whether or not to allow default draining time on target or reset target immediately.
Completing the New Deployment Wizard	Triggers completion of the process.

Additional Application Features

You can use icons on the toolbar in the Applications view to launch additional application-related tasks, summarized in Table 2.7.

Table 2.7 Application Tasks 

Icon	Description
Delete	Deletes the selected application.
Rename	Renames the selected application.
Synchronize	Replicates and then synchronizes the selected application across the cluster.

Because synchronization through replication is a major aspect of deployment, we'll examine the synchronization feature next.

Cluster Synchronization

As explained in the preceding section on application manifest deployment, you can replicate a single application to cluster members, or replicate all the applications that are currently hosted on the controller. Site information contained in the AllSites category, or in custom definitions, may include any of the following information, which is replicated when you synchronize a cluster:

• Web Content and Active Server Pages (ASP) applications 

• COM+ applications 

• Virtual sites (and their associated ISAPI filters) and content 

• Global ISAPI filters 

• File system directories and files 

• Metabase configuration settings 

• Exportable CryptoAPI (CAPI) server certificates 

• Registry keys 

• System DSNs 

• Microsoft Windows Management Instrumentation (WMI) settings that Application Center uses 

By default, the cluster is synchronized whenever new content is added (only the new content is replicated) or fully synchronized every 60 minutes. The user interface lets you disable this feature completely or change the time frequency for the synchronization schedule.

Note You can exclude specific members from being part of cluster synchronization.

As with application deployment, you can explicitly replicate a single application or all of the applications on the controller. This gives you flexibility in staging and deploying new applications, which you may want to test on part of a cluster before deploying the application to all of the members.

Monitoring

In order to successfully maintain a production environment, you must be able to monitor the behavior and performance of its key components: the network, servers, and applications. A robust monitoring environment—one that provides real time and historical data—enables you to keep an eye on the overall health and performance of any given system. (Historical performance data is particularly useful when it comes to capacity planning.)

Application Center provides a central viewing point for obtaining this kind of information, which is encapsulated by the monitoring and logging of event, performance, and health data.

For detailed information about this feature, see Chapter 7, "Monitoring," Chapter 9, "Working with Monitors and Events," and Chapter 10, "Resolving Performance and Capacity Issues." 

Events

Numerous objects and applications running on a server or cluster generate events—actions that take place on your server or cluster.

Note All of the Windows 2000 events and some of the Application Center events are also logged in the Windows event log.

The more than 300 events relating to cluster functionality come from the 3 main sources summarized in Table 2.8. All the events that you can view are ranked by their severity (Table 2.9).

Table 2.8 ApplicationCenter Event Sources 

Source	Description
Windows 2000	All the events logged by Windows 2000 in its event log. Application Center allows you to view these events by severity, source, time frame, and date generated.
Health Monitor	Health Monitor logs these events whenever established thresholds are exceeded.
Application Center	Various Application Center services, such as load balancing, generate and log events. Some error-related events are also logged in the Windows 2000 event log.

Table 2.9 Event Severities 

Severity	Description
Informational	Describes the successful operation of an application, driver, or service. For example, it informs you when a network driver has loaded successfully.
Warning	The event is not of major significance, but may indicate a possible future problem. For example, you will receive a warning when disk space is low.
Error	Indicates that a significant problem has occurred, such as loss of data or loss of functionality. For example, an error will occur if a service has failed to load during startup.

By activating the Event view in the console tree, you can view all the cluster and server events that are captured together or by specific category.

Figure 2.7 illustrates the Events report for our cluster member. Using the provided lists, you can specify an events category (All, Application Center, HealthMon, and Windows) and an events type (All, Errors, and Errors and Warnings). You can also apply specific filters to the Events report. In the example shown, only Application Center–specific events are displayed.

In addition to the summary event information listed at the top of the details pane in Figure 2.7, detailed information for a selected event is displayed at the bottom of the details pane. In addition to the online Help (MMC toolbar) and context-sensitive Help, you'll notice that the lower portion of the details pane provides additional information about an event. First, it provides a link to expanded information about the event itself. Second, it provides a link to the Microsoft Support Online site, where you can obtain related information, from sources such as Knowledge Base articles.

Figure 2.7 Cluster member events report 

Performance

Performance is indicated by a collection of performance counters that indicate the amount of resource consumption. The counters may indicate, for example, that 70 percent of the total hard disk is space is in use, or that there have been 1,897 requests per second for the WWW Service.

Application Center uses a set of default counters to give you an overview of both server and cluster performance. These counters cover a broad range of system-related information, from the amount of available memory to the number of ASP page requests serviced per second. You can view these counters either in real time or for a selected time frame. Detailed information about these counters is provided in Chapter 7, "Monitoring," as well as Chapter 10, "Resolving Performance and Capacity Issues," which covers cluster performance metrics and tuning.

For example, the current server performance (Figure 2.8) for ACDW822AS is summarized as a chart in the details pane. The available graphs cover several time periods relative to the present time and are available in time segments of 15 minutes, 1 hour, 1 day, 1 week, and 3 months. Figure 2.8 plots the available memory in bytes and the processor utilization (as a percentage).

Figure 2.8 Server performance summary 

By presenting these different views, Application Center enables you to assess the current level of performance in the context of past behavior. You have access to enough data to determine whether or not the present performance picture is an anomaly, represents a trend, or is part of a cycle.

Health

Application Center creates several default data collectors—with pre-defined thresholds—for use in monitoring server and cluster health. Some of the default collectors are toggled as active, while others are inactive and can be activated at any time.

Note Data collectors are used to collect, receive, and retain specific WMI data.

You can also use the Health Monitor console to create and configure custom data collectors to expand the scope of the health monitoring features provided by Application Center. The product also supports the use of local monitors and thresholds, in addition to its global monitors.

Local and Global Monitors

By default, Application Center creates only global monitors. However, you might want to create local monitor thresholds to meet specific needs. For example, one of your cluster members might have a smaller hard disk than the rest, and the global threshold for disk usage (let's say, 80 percent) might be too high for this member. You can set the local threshold at 70 percent to give yourself more leeway for responding to a disk full situation.

The ability to set local monitors gives you greater flexibility, but keep in mind that it can also increase monitoring complexity.

There are three ways to create local monitors:

• From scratch by using the Health Monitor snap-in. 

• By copying and modifying existing monitors in the Health Monitor snap-in. 

• By developing classes with Managed Object Format (.mof) files, and then compiling them for use by WMI. 

Warning Changing monitors for a specific cluster member will cause that member to be out-of-synch with the rest of the cluster from a monitoring perspective. Unless this change is made correctly, Application Center will overwrite your changes and restore the default settings during the next synchronization cycle.

Figure 2.9 shows the Monitors view for ACDW822AS, the cluster controller for the staging cluster.

Figure 2.9 Server Monitors view 

Programmatic Support

Application Center supports the use of programming to access various objects and interfaces in order to query, manage, and configure common administrative and reporting tasks.

For detailed information about this feature, see Chapter 11, "Cluster Administration Using the Command Line and Scripts." 

Monitoring

Through the use of custom scripts, you can create tools for automatically monitoring the Application Center database in both the Monitors and Performance views. The samples provided on the installation CD, for example, can be used to

• Determine whether your database is connected and functioning. 

• Run stored procedures against your database server. 

• Validate a DSN. 

Performance Counters

You can also use programming to install additional performance counters—either by modifying the samples that ship with the product or by creating your own definition in a MOF and compiling the source. Some examples of typical counters are provided in Table 2.10. This list is by no means exhaustive, and you can get information about the entire set of sample definitions in the Appendix or the online documentation (See: Application Center>Programmatic Information>Monitoring>Samples).

Table 2.10 Examples of Performance Counters 

Category	Counter examples
Web Service	Request Execution Time, Request Wait Time, File Cache Hits %, Thread Count
System	Page reads/sec, Interrupts/sec, % DPC time, Processor Queue Length
SQL Server	Buffer Cache Hit Ratio, Number of Deadlocks/sec, Total Server Memory, % Disk Time
COM	Total Committed Transactions, Object Creations/sec, Timeout Shutdowns
Miscellaneous	NIC: Bytes Received/sec, Bytes Sent/sec, Process: Thread Count

Command-Line Administration

Application Center provides the commands summarized in Table 2.11 for command-line administration and automation through scripting. Each command has several parameters that can be used to control the behavior of the command-line tool.

Table 2.11 Command-Line Administration 

Command	Description
HELP	Provides a description of the available Application Center commands, their syntax, and their usage.
LOADBALANCE	Allows the user to take a member offline, put a member online, or enable/disable load balancing. This command can also be used to set NLB weights for cluster members and obtain NLB status information.
DEPLOY	Enables the user to deploy applications (defined by Application Center) from the cluster controller.
CLUSTER	Provides the ability to change the cluster controller.
CLB	Allows the user to update the CLB routing list on the controller of an NLB (DCOM routing) cluster.

COM+ Provider

The COM+ provider enables the monitoring of COM+ data by using WMI to provide statistics about the status of COM+ applications that are running. If you are familiar with WMI and the COM+ programming framework and have access to their software development kits (SDKs), you can create your programs for interacting with the provider. This will let you build your own application monitoring and remote administration tools for a COM+ environment.

Local and Remote Administration

By using the MMC, you can connect to any cluster member and perform administrative tasks that are within the scope of the server's role. Although certain tasks, such as full synchronization on demand, can only be done from the controller, Application Center provides robust connection capability.

The dialog box in Figure 2.10 shows how you can connect to any server on a cluster, including the controller, which gives you powerful administrative capabilities.

You'll find that remote administration is just as easy as local administration. By using a Windows 2000 Terminal Client, you can log on to any member that has Terminal Server installed. Figure 2.11 shows an open session window for a Terminal Services Client connection. In this example, I installed Application Center over a remote connection and created a new cluster.

Note For security reasons, you should run a Terminal Services Client session over a VPN connection.

Figure 2.10 Server connection dialog box 

Figure 2.11 Using a client connection over a network to create a cluster 

Another cluster administrative option is using the Application Center Administrative client, which must be installed on a system running Microsoft Windows 2000 Professional. Provided that you can supply the necessary authentication information, you can connect to any cluster and any cluster member. If this is done remotely, a secure connection is recommended.

In addition to these administrative options, Application Center supports programmatic access to several features, as well as command-line tools for automating common administrative processes (summarized in "Command-Line Administration" earlier in this chapter).

High Availability

Through its implementation of the shared nothing model, Application Center provides a high level of availability for all cluster members, including the controller. Remember that every member is, in essence, a mirror image of the cluster controller.

With integrated NLB installed, each member "hears" incoming client requests, so if one member fails, the other members can continue servicing these requests. Because a failed member is taken offline in the background and load balancing is automatically reconfigured to distribute client requests, Application Center provides an effective environment for providing computing availability. In addition, its transparent isolation mechanism shields users from the effects of server failure.

If a controller fails, cluster administrative activities such as synchronization cannot take place until a new controller is designated; however, load-balanced request handling continues to function.

When coupled with its automated e-mail notification and flexible administration features, the shared nothing implementation provided by Application Center ensures a highly available environment for clusters.

Note Although Application Center clusters provide high levels of server availability, fault tolerance, as it is defined, and the fault tolerant state are not supported. If a member crashes or is intentionally taken out of the cluster, all clients that rely on the state stored on that particular member will lose their state.

In the next chapter, the product's architecture and the underlying technologies that support Application Center are presented. You'll also get a behind-the-scenes look at each feature, explaining the sequence of events and processes that take place when it's used.

Online Help

In addition to the conventional online Help that you can access from the MMC menu and dialog boxes, Application Center also provides user-friendly error messages and context-sensitive Help. Figure 2.12 shows the context-sensitive Help for the Applications view in the details pane of the snap-in.

Figure 2.12 Context-sensitive Help for ApplicationCenter features 

Resources

The following books and Web sites provide additional information about Windows 2000 Advanced Server and Application Center.

Books

Internet Information Services Resource Guide (Microsoft Press, 2000).

This guide is one of the volumes that make up the Microsoft Windows 2000 Resource Kit. The guide provides information not found in the core documentation as well as software tools on a CD.

Web Links

https://www.microsoft.com/windows2000/default.asp 

The Windows 2000 Web site provides the most up-to-date information about Windows 2000 and other server products, such as Application Center.

https://www.microsoft.com/applicationcenter/ 

The Application Center Web site.