Paving the Way for Application Center 2000

Design considerations for an Application Center—managed environment

[Author's Note: Each month, this column discusses various aspects of the advanced administration of e-business sites. This month, I introduce you to the major features of Application Center and provide design considerations for deploying this server in your environment.]

Historically, deploying and managing multi-tier applications in Web farms or clustered environments has been complex—in some cases, even impossible. This month, I explain the design, configuration, and implementation of Microsoft Application Center 2000 and show you how to use this server to deploy and manage even the most complex Web applications in Web farms and clustered environments. I introduce you to the six major Application Center features, delve into some of the more important design considerations, then discuss Application Center implementation. "Application Center Resources," page 2, lists additional articles and a white paper that will help as you consider using Application Center.

The Application Center Feature Set
Application Center has six major feature areas. Of course, you don't have to use all the features of the product. Nevertheless, this complete and concise list will help get you started thinking about which features you'll deploy in your shop.

Application Center applications. Application Center uses the concept of an application, which is a collection of resources (e.g., IIS Web sites, HTML and image files, Active Server Pages—ASP—applications, COM+ components and applications, database connections, security settings, registry settings) synchronized as a whole. You define which resources make up an Application Center application. An Application Center application lets you manage these resources as a logical grouping or, put another way, as one application image.

Application Center provides a Microsoft Management Console (MMC) snap-in to manage Application Center applications. You update and change an Application Center application from one console, which Figure 1, page 2, shows, then automatically synchronize those changes across large server arrays. Like most Microsoft products, Application Center is an open technology. All the server's APIs are exposed, which means that your developers can write Web-based management applications based on Application Center that perform well beyond the functionality of the MMC snap-in.

Realtime performance and health monitoring. Application Center provides an integrated view of Web application and server performance and health. What makes this monitoring special (and powerful) is that Application Center combines into one view all performance, event, and log data from all the servers in an Application Center cluster. Application Center has default monitors that handle such components as Web services, Application Center services, and system events. You can easily add thresholds (i.e., monitoring rules) to existing performance-data collectors to create additional monitors. For example, many performance-data collectors ship with Microsoft Commerce Server 2000. Application Center can integrate the Commerce Server performance collectors into its integrated monitoring.

When a data collector meets its threshold rules, the state of the data collector changes (e.g., from normal to critical). For example, you can define a CPU threshold so that a collector enters a critical state if processor utilization is greater than 90 percent for 1 minute. Using thresholds, you can define the areas of the system that you want to monitor. In addition, you can define conditions that warrant an alert. Some administrators want to receive 300 system-monitoring email messages (or pages) a day from Application Center; others want to be notified only in times of crisis.

Simplified load balancing. Load balancing distributes Web-application-processing loads evenly across multiple servers. Network Load Balancing (NLB) is a clustering technology that balances incoming IP traffic among the nodes in a multinode cluster, such as an IIS server farm, as Figure 2 shows. NLB decides on a packet-by-packet basis which packets a given server should process. The essence of NLB is a mapping of shared virtual IP (VIP) addresses to the real IP addresses of the servers that are part of the load-balancing scheme. Load-balanced servers (frequently called hosts) in an NLB cluster provide two important benefits:

Fault tolerance. One big challenge that Web-application developers face is maintaining session state (sometimes called coherency) for a user as he or she moves among Web pages. The Application Center Request Forwarder preserves session state in a clustered Web server environment. In the event of a catastrophic failure on a server in an Application Center cluster (such as a NIC failure on the public Internet segment of the LAN), Request Forwarder automatically routes the session and all additional traffic to the next available server.

Application Center can also proactively repair software faults. Application Center enables high availability because no single point of failure exists within the cluster. Even if the Application Center cluster controller is unavailable, the cluster's other servers can handle requests, and the user is unaffected.

Application staging and deployment. Application Center simplifies the process of deploying Web content, Internet Server API (ISAPI) filters, and COM+ applications through the development, testing, and production life cycle. The server also allows seamless, incremental, scheduled application updates and upgrades without requiring system downtime. One of Application Center's primary functions is to coordinate the deployment of one or more single-application images to one or more servers. You can use a simple wizard to immediately deploy selected applications to selected servers. Or you can schedule applications for deployment in nonpeak hours.

Application replication. Application Center provides a core replication engine and drivers to move applications between cluster nodes. Application Center's replication technology is based on Microsoft Site Server 3.0's Content Replication System (CRS), and the engine keeps Web applications synchronized across arrays of multiple servers.

Application Center Project Design Considerations
Before I dive into project design considerations, let me dispel a couple of myths. Myth number one is that you won't benefit from Application Center if you have only one Web server. A single-server shop can benefit from Application Center's help in managing Web site content and components as they move from development to staging to production Web sites on the same server. In addition, you can benefit from realtime performance and health monitoring. Most important, however, Application Center in a single-server scenario provides a quick, easy, and inexpensive road map to multiple servers in a Web farm.

Myth number two is that Application Center requires two NICs in each server in the cluster. If you decide to employ Application Center's NLB feature to create Application Center clusters for content synchronization and health monitoring, you must use dual NICs in your machines. But no other Application Center feature requires a second NIC in each server.

Using two NICs in a Windows NT server is a potential security risk because one NIC can see the other NIC's traffic. However, Microsoft added superior networking drivers to eliminate that potential risk in Windows 2000.

NLB emits periodic "heartbeat" messages so that it can monitor all members of a cluster. These heartbeat messages impose very low overhead on network traffic, but for optimum cluster performance, you might want to install a second NIC on each NLB host to handle them. In this configuration, a front-end NIC carries the load-balancing traffic resulting from client (user) requests and a back-end NIC handles the management traffic addressed to the server (i.e., the heartbeat messages).

If you need or want two NICs, configure them on separate, nonroutable IP subnets to ensure security and efficient messaging. In addition, assign a static IP address to each back-end NIC. Although Application Center supports DHCP-assigned addresses, using static IP addresses can increase the reliability of intracluster communications.

Next, you need to update the HOSTS file for the back-end IP address of each member of the cluster. The HOSTS file resides in the %winnt%system32 driversetchosts folder and must have entries for each server that you add to the cluster. Finally, to ensure that you apply all appropriate settings, you need to restart each server before proceeding with the cluster-creation or member-addition process.

If you want to use Application Center for content and component synchronization, you need to be in a "version release" mentality. In other words, collect updates and implement them together rather than one by one. Application Center doesn't deploy single files into production very well.

In addition, remember that Application Center's purpose is to synchronize content and guarantee that Web sites match. If a developer is working on an application feature on your development Web site, make sure that the developer completes his or her work before you move that feature to the staging environment. When content is in the staging environment, Application Center will move it to production, whether it's ready or not.

Also, if you're planning to implement Application Center and your development, staging, and production servers are out of sync, you should clean up the mess before employing this set of technologies.

Managing with Application Center
Using Application Center to manage a cluster is no more difficult than using it to manage one Web server because you administer clusterwide configuration from one MMC console. Each cluster has one server designated as the cluster controller. This server, which can serve requests in addition to performing its controller duties, is the source (master) of all cluster synchronization, including content, component, and configuration details. If the cluster controller is unavailable, the member servers continue handling HTTP requests from users. You can dynamically designate any node in the cluster to be the controller. After you've defined an Application Center cluster controller, you can automatically deploy new content to the cluster group as a whole, configure load balancing, and monitor cluster performance. As you'd expect, numerous command-line tools and exposed APIs are available to make all of MMC's functionality available through scripting.

Next Month
You deal with complicated tasks every day—tasks such as rebuilding software configurations on Web servers, moving applications from test servers to staging servers, changing software configurations on multiple production Web servers, creating clusters, and rolling application versions into production. Application Center has a powerful set of features that can help you complete these complicated tasks swiftly, automatically, and easily.

Now that I've got you excited about Application Center's features, here are some tips for selling it to your management. You can measure Application Center's Return on Investment (ROI) in several ways: faster Web server deployment, shortened application- development cycles, higher application availability, improved site performance and scalability, and reduced management complexity. Software and hardware costs are, in most cases, the smallest costs involved in deploying software solutions. The most substantial costs come from the personnel costs required to manage the solution after it's in place (often called production support). This production support arena is the area in which Application Center is most effective. Next month, I'll show you how to install and configure Win2K Server Terminal Services to manage IIS.