Lesson 1: Introduction to Application Center

Application Center 2000 maintains a high level of availability by allowing Web site administrators to group Windows 2000 Server computers into clusters and manage Web site content and applications easily. Administrators can manage content and configuration settings on a single server, reducing the time required to update a Web site. Application Center 2000 divides Web site content and code into applications that can be updated independently. These applications can consist of any combination of Hypertext Markup Language (HTML) and Active Server Pages (ASP) files, COM+ components, Windows registry settings, and Internet Information Services (IIS) settings. Each server in the cluster hosts a copy of the application, which Application Center keeps synchronized. Application Center NLB and CLB technologies support clusters made of Windows 2000 Server computers. Web browsers, such as Microsoft Internet Explorer, see each cluster as a very large and very reliable Web server. This lesson gives you an overview of Application Center and the features that allow you to create NLB and CLB clusters.

After this lesson, you will be able to

• Describe Application Center and how it’s used
• Identify and describe the features that are supported by Application Center
• Provide an overview of the Application Center architecture

Estimated lesson time: 25 minutes

Platform Components of a Web Site

The key tenet of distributed Web-based applications is the logical partitioning of an application into three tiers:

• Presentation
• Business logic
• Data access and storage

By using component-based programming techniques to partition applications along these lines and by using the services provided by the Windows operating system, developers can build highly scalable and flexible applications.

A simple application model consists of a client that communicates with the middle tier, which itself consists of the application server and an application containing the business logic. The application, in turn, communicates with a back-end database that’s used to supply and store data.

Presentation Services

The Presentation layer consists of either a rich or thin client interface to an application. The rich client, which uses the Microsoft Win32 application programming interface (API), provides a full programming interface to the operating system’s capabilities and uses components extensively. Arguably not as robust or as capable of offering the performance levels of a rich client, the thin client (Web browser) is rapidly becoming the interface of choice for many developers. A developer is able to take advantage of several simple-yet-robust scripting languages to build business logic that can be executed on any of the three application tiers. With full support for HTML, dynamic HTML (DHTML), and Extensible Markup Language (XML) object models, the thin client is able to provide a visually rich, flexible, and interactive user interface to applications. Thin clients have the added advantage of providing a greater degree of portability across platforms.

Business Logic/Application Services

This layer is divided into application servers (IIS, Site Server, Commerce Server 2000, and Systems Network Architecture [SNA] Server) and services, which are available to support clients. Web application logic, typically consisting of ASP written in Virtual Basic Scripting Edition (VBScript), is processed in the IIS server space. You can write ASP-based or Component Object Model (COM)–based applications to take advantage of Microsoft Transaction Server (MTS), Microsoft Message Queue Server (MSMQ), directory services, and security services. Application services, in turn, can interact with several data services on the back end.

Data Access and Storage

The following data services support data access and storage:

• Microsoft ActiveX Data Objects (ADO), which provides simplified programmatic access to data by using either scripting or programming languages
• Object linking and embedding (OLE) database, which is an established universal data provider developed by Microsoft
• XML, which is a markup standard for specifying data structures

XML is a recent standard put forward by the Internet community. Whereas HTML focuses on how information is rendered by the browser and displayed on the screen, XML’s goal is to handle a data structure and its representation.

Overview of Application Center

Application Center is a tool for creating, deploying, and managing Web- and component-based applications, which are typically 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’s characterized by high volumes, exponential growth curves, and load fluctuations.

Application Center is designed to provide the capital cost advantages of the scale-out model, while at the same time reducing operations costs—one of the main advantages espoused by proponents of the scale-up model. In addition to these cost advantages, Application Center provides the following benefits:

• Manageability You can manage Application Center through a centralized management console that’s minimal and familiar. You use this console to organize and manage replication, load balancing, and the monitoring of Web and COM+ applications.
• Scalability Application Center is both linear and flexible. You can add servers to a cluster as needed to accommodate seasonal peaks and remove them (and reallocate them within the organization) as the load decreases.
• Reliability Application Center eliminates 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.

Application Center Features

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

Table 6.1 Application Center Features

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 integrated NLB and 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. You can complete selected administrative tasks with a set of command-line tools.
Local and remote administration	You can administer a cluster locally or through a secure remote connection.
High availability	Requests and transactions are automatically rerouted to another member if a server failure occurs.

Load Balancing

Application Center provides several options for implementing load balancing on a cluster, including integrated NLB, CLB, or no load balancing.

Integrated NLB

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

Although it isn’t included with Windows 2000 Server, NLB is automatically installed on a system running Windows 2000 Server when Application Center is installed on that system.

The Application Center user interface makes configuring an NLB cluster easier by removing much of the configuration detail and, through the use of a wizard, by reducing the number of decisions that a user must make. 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 Internet Protocol (IP) addresses.

When configuring NLB for your cluster, you must select 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. Integrated NLB uses three types of affinity settings, as described in Table 6.2, to identify the algorithm that’s used.

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.

Table 6.2 NLB affinity settings

Affinity	Description
None	Multiple requests from the same client can access any cluster member. The IP address and port number identify 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 Transmission Control Protocol/Internet Protocol (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, in which a client request establishes a server-side state that’s used in subsequent requests during the same session.

Another load balancing configuration option that Application Center provides is the ability to adjust individual server weights in response to performance data or to accommodate different classes of members.

CLB

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. An inherent system overhead is associated with client requests that traverse the network and with selecting a server to satisfy the client request. You should consider CLB in these situations:

• Security is a major concern and you want to segregate COM objects behind an additional firewall.
• COM objects are relatively large and you want to run them on the fastest servers available.
• Applications are partitioned into n-tiers, either for development or design reasons. 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.

For applications that are relatively small or that use a limited number of 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 don’t need or want to have load balancing enabled; for example, it’s not necessary for application testing and staging or for controller redundancy. You might want to use the no load balancing option in the following situations:

• 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 very small, such as two or three servers, you may want to have a completely redundant member on standby to serve as a backup controller. You’d keep its content synchronized to the active controller, but you wouldn’t have it responding to client requests.

Synchronization and Deployment

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. You achieve partial or full synchronization of a cluster 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 demand with minor configuration changes to the member.

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 ASP applications
• COM+ applications
• Virtual sites (and their associated Internet Server Application Programming Interface [ISAPI] filters) and content
• Global ISAPI filters
• File system directories and files
• Metabase configuration settings
• Exportable CryptoAPI (CAPI) server certificates
• Registry keys
• System data source names (DSNs)
• Windows Management Instrumentation (WMI) settings used by Application Center

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

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.

In Application Center, 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.

Monitoring

In order to maintain a production environment successfully, 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, as described in Table 6.3.

Table 6.3 Monitoring and Logging Data

Monitored Objects	Description
Events	Numerous objects and applications running on a server or cluster generate events (actions that take place on your server or cluster). All Windows 2000 events and some Application Center events are logged in the Windows event log.
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 space is in use or that there have been 1,897 requests per second for the Web 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.
Health	Application Center creates several default data collectors—with predefined 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 that data collectors are used to collect, receive, and retain specific WMI data.

Application Center Architecture

Through its implementation of the shared nothing model, Application Center provides a high level of availability for all cluster members, including the controller. 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 can’t 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.

Although Application Center clusters provide high levels of server availability, fault tolerance (as it’s defined) and the fault-tolerant state aren’t 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.

Architectural Layers

The architecture for Application Center, illustrated in Figure 6.1, consists of three major layers:

• User Interface
• Feature Set
• Operating System

Figure 6.1 - The Application Center architecture

User Interface

The Application Center user interface provides access to the product feature set through an MMC snap-in, the Web browser, and the Microsoft Windows command prompt. The MMC provides full access to the product feature set, but access to cluster administration and monitoring tasks is also possible—although to a lesser extent—by using Internet Explorer or the Application Center command-line tool at the Windows command prompt.

Feature Set

This layer is divided into the following broad categories:

• Cluster services
• Load balancing
• Synchronization and deployment
• Monitoring and logging
• Health services

Operating System

The main elements of the operating system that the user interface and feature set layers interact with are the MMC (IIS version 5.0), the metabase, COM+, NLB, and WMI. The Microsoft SQL Server engine is outside this layer, but it’s integrated with the operating system and used solely for handling cluster-related data storage and retrieval.

Clustering Scenarios

Application Center 2000 supports three primary clustering scenarios:

• Single-node clusters
• Standard Web clusters
• COM+ application clusters

Single-Node Cluster

It can be useful to operate Application Center on a single server without the context of a multimember cluster. Application Center treats a single-node cluster, or stand-alone server, as a cluster of one member. Typically, the most common single-node cluster is a stager. A stager is a server on which content is placed prior to being placed on a production server. On this stager, you can experiment with and fully test the quality and functionality of content from development and test environments before deploying the content to production environments.

In addition to stagers, other single-node clusters can benefit from Application Center without operating in a clustered environment. These servers can use Application Center for the following tasks:

• Deploying applications to or from other members or clusters
• Viewing health and status alongside other clusters
• Viewing performance data and event logs alongside other clusters

Standard Web Cluster

The most typical Application Center clustering scenario is a Web cluster serving Web sites and local COM+ components. You can distinguish such clusters by their load balancing implementation, whether they use NLB or other load-balancing devices. Clustering multiple servers together has the following advantages:

• Failover protection Each member is essentially a backup of the cluster controller.
• Increased application availability With multiple members serving sites and applications, clients can experience uninterrupted service even through failures or problems on individual members.
• Increased scalability You can add and remove members without affecting client availability.
• Increased performance Client workload is distributed throughout the cluster, so that each individual member receives less load, which enhances performance.

NLB Web Clusters

With NLB, Application Center provides seamless integration so that NLB cluster creation and member addition is simplified and you can handle common administrative tasks, such as setting members online and offline, through the Application Center user interface. NLB dynamically distributes client workload as members are set online and offline. Figure 6.2 shows a typical one-tier Web cluster that’s running NLB.

Figure 6.2 - NLB Web cluster

Non-NLB Web Clusters

For typical non-NLB clusters, an external load-balancing device is used to distribute incoming client requests. Figure 6.3 shows a typical one-tier, non-NLB Web cluster.

Figure 6.3 - Non-NLB Web cluster

COM+ Application Cluster

A COM+ application cluster processes COM+ application requests for clients. These clients can include Windows-based clients and Web clusters. A COM+ application cluster relieves Web clusters and Windows-based clients from processing COM+ components. To support Windows-based clients, the cluster can use NLB or other load balancers to distribute incoming client requests. Figure 6.4 shows a COM+ application cluster that’s running NLB.

Figure 6.4 - COM+ application cluster that uses NLB

You can create Web clusters that use CLB to load balance the activation requests for COM+ components and forward these requests from the Web cluster to the COM+ application cluster for processing. In a two-tier Application Center clustering environment, one tier handles requests for Web sites and the second tier handles requests for COM+ components. The performance in this environment might not match the performance of a single Web cluster because data must be transmitted between the Web cluster and the COM+ application cluster.

Although you get the best performance by activating COM+ applications locally, creating a separate cluster to process COM+ components has the following advantages:

• Security is increased because you can place firewalls between Web clusters and COM+ application clusters so that clients accessing the Web cluster are restricted from accessing the COM+ application cluster.
• If the COM+ applications consume extensive processing resources, Web servers might become unresponsive. You can create a separate COM+ application cluster to relieve the Web cluster of processing these COM+ applications. Since the Web cluster doesn’t process the COM+ applications, it can achieve better performance in serving Web sites.
• Manageability of server applications is increased because COM+ applications are isolated on a separate cluster from Web clusters. The two separate clusters allow you to have different developers and administrators maintaining each cluster independently.
• Clients of mixed environments can be supported. COM+ application clusters can accept requests from both clients accessing the Web cluster and clients running Windows-based applications.

COM+ applications clusters are discussed in more detail in Lesson 3, "Designing CLB Clusters."

Lesson Summary

Application Center is a tool for creating, deploying, and managing Web- and component-based applications. Application Center allows administrators to group Windows 2000 Server computers into clusters and easily manage Web site content and applications. The key tenet of distributed Web-based applications is the logical partitioning of an application into three tiers: presentation, business logic, and data access and storage. Application Center includes the following features: cluster services, load balancing, synchronization and deployment, monitoring, programmatic support, local and remote administration, and high availability. Application Center provides several alternatives for implementing load balancing on a cluster. Application Center supports three load balancing options: Integrated NLB, CLB, or no load balancing. Application Center synchronizes every aspect of a cluster’s composition and configuration and provides a central viewing point for obtaining monitoring-related information. The architecture for Application Center consists of three major layers: User Interface, Feature Set, and Operating System. Application Center 2000 supports three primary clustering scenarios: single-node clusters, standard Web clusters, and COM+ application clusters.