twitter
facebook 
| Application Center Aims to Simplify Web Clusters |
| Mar. 12, 2001 |
Application Center enables companies to increase the performance and availability of multitier Web applications by running them on farms of identical machines. With Application Center’s enhancements to Microsoft's core clustering technologies, administrators can manage a farm as a single unit. It's a promising expansion of Microsoft's platform that could give other application server vendors a run for their money. However, companies evaluating this release should carefully note its limitations, and schedule their deployments with an eye toward major additions to Microsoft's platform that are coming this year. Why Application Center Exists Companies such as barnesandnoble.com and Data Return have been using Windows to host large-scale, multitier Web applications. These applications frequently consist of a presentation tier of dynamic Web pages (Active Server Pages) that present data to the user and process the user's responses; a business logic tier of COM components that implement the core functions of the application; and a data tier that manages access to databases and other data sources. Companies sometimes run these multitier applications on clusters of servers to scale performance (by adding servers to a cluster to increase overall throughput) and to improve availability (by rerouting work from failed servers in a cluster to servers that are still working). Although Microsoft provides a variety of clustering technologies (see "Application Center and Microsoft's Clustering Technologies"), certain setup and management tasks, such as keeping a consistent image of the application components across all servers and detecting and correcting problems, have required a combination of third-party tools and homegrown scripts. Microsoft also lacked a clustering technology appropriate for business logic components. Application Center addresses these problems by providing a software console that enables an administrator to centrally set up and manage clusters, deploy applications, and monitor application status and performance. It enhances Microsoft's clustering technology for the presentation tier, Network Load Balancing (NLB), and introduces a new clustering technology called Component Load Balancing (CLB) for business logic components running under Windows 2000's extended COM, COM+. Application Center can't manage every kind of cluster or application. For example, it doesn't provide any tools for managing database clusters, nor does it provide tools for packaging and deploying conventional Windows applications or system services like those provided by Windows 2000 Server or Microsoft Systems Management Server (SMS). However, it gives the Windows 2000 platform application hosting features similar to those of established application server products (see the chart "Microsoft's Windows 2000 Application Server"), which in turn makes that platform more credible for critical enterprise applications. Managing Clusters The Application Center console (based on the Microsoft Management Console) enables administrators to centrally set up clusters of up to a dozen servers and automatically apply a single server configuration to every server in the cluster, including applications and network settings. Once a cluster is up and running, the console provides a variety of monitoring tools to spot problems and evaluate performance, both for individual servers and the cluster as a whole. Cluster Creation and Synchronization To create a cluster, an administrator installs Application Center on one server and runs the Application Center New Cluster Wizard, which verifies that the server has the required hardware and operating system components, and records its configuration. The first server becomes the "controller" of the new cluster. Application Center will automatically replicate the controller's configuration to all other servers in the cluster—a process called synchronization. Synchronization is what allows administrators to manage the cluster as a single unit; administrators make changes on the controller, which then propagates the changes to the other servers in the cluster. Administrators can move the controller role from one machine to another at any time. Synchronization occurs automatically as each new server is added to the cluster. In addition, the controller synchronizes with all servers at regular intervals, and also whenever its applications or network settings change. Administrators can define policies for controlling automatic synchronization and can manually trigger synchronizations with individual servers. Application Deployment and Packaging Application Center provides tools to prepare an application for deployment by creating an "application image," which contains all the parts of the application. This image can include the following:
Developers can use Application Center tools to add and remove application elements in an image. Application Center will also automatically crawl IIS Web sites installed on a server and create initial application images for those sites, which developers can then extend with elements (such as COM+ components) that the crawling process doesn’t pick up. Once an application image has been built, administrators can deploy the image from a staging machine either directly to a subset of the servers in the cluster or to the controller of the cluster, which then replicates the image to the other servers by synchronization. Note that some application elements (specifically, COM+ components and global ISAPI filters) require restarts of services on servers where they are installed. Deploying these elements to a live cluster through synchronization would likely interrupt service to clients while all servers in the cluster except the controller restarted services during installation. Application Center enables administrators to get around this problem by deploying these elements to a subset of the servers in the cluster. Application Center's deployment tool will "drain" clients from target servers by preventing new connections. After all clients have been directed to other servers, it will perform a shutdown and restart of the affected services. Monitoring Application Center provides two distinct systems for monitoring the health and performance of a cluster: an Application Center logging system and a specially configured version of Microsoft's HealthMonitor. Though they share the Application Center console (see the screen shot "Application Center Console"), the two systems are separate and complementary. The Application Center logging system provides integrated performance and status monitoring for clusters and individual servers, and it can show how a cluster's behavior has changed over time. HealthMonitor provides a current snapshot of server status and enables administrators to script automated responses to typical problems. The Application Center logging system provides three basic monitoring displays:
The logging system runs on each server, collecting data through the Windows Management Instrumentation (WMI) API and storing it in a local database managed by the Microsoft Data Engine (MSDE). The cluster controller queries each server's log databases and builds monitoring displays when requested by the Application Center console. Because the logging components require memory and disk space on each server, sites can elect to leave these components out of an Application Center install. HealthMonitor enables administrators to install software components (called monitors) that track specific aspects of a server's behavior and detect when that behavior goes outside of a normal range. For example, a monitor could track processor utilization on a server, sending a message to the Application Center console (called an alert) if utilization reaches more than 70% for more than an hour and sending an e-mail to an administrator if utilization remains above that level for more than four hours. Another monitor might track the status of IIS on a server, detecting IIS shutdown and running a script that e-mails the administrator and also takes the server offline (removing it from load balancing). Like the Application Center logging components, the monitors run on each server and collect data through WMI, although they do so independently of the logging components. A HealthMonitor snap-in in the Application Center console enables administrators to enable, disable, and create or customize monitors. This snap-in can also display the states of individual monitors (showing whether a monitor has detected a problem) and lists all alerts sent to the console by monitors. HealthMonitor isn't specific to Application Center—the same tool (version 2.1) ships in SMS 2.0, BackOffice 2000, and Small Business Server 2000. (See "Business Server Suites Ship".) However, the specially configured version of Health Monitor used in Application Center adds a number of enhancements:
Scripts and Web Interfaces All of Application Center’s features are available from its console. However, most management features are also available as command-line utilities, which allow them to be executed from within scripts. The script interface will likely be heavily used by companies that need to perform cluster setup and application deployment as part of larger operations; for example, application service providers will likely integrate Application Center commands into their scripts for provisioning new customers. Administrators can also view all monitoring data and configure monitoring for a cluster with a browser by visiting a virtual Web site hosted by the cluster controller. Note that this interface, unlike the Application Center console and the command-line interface, does not allow any management commands other than configuration of monitoring. Supporting Load Balancing Application Center delivers enhancements to the NLB service and delivers the CLB service for clusters running COM+ components. Note that Application Center can be used for cluster management without either of these technologies, and NLB can also be used without Application Center (it's a standard service on Windows 2000 Advanced Server and Datacenter Server). Nevertheless, Application Center can make these load-balancing technologies substantially easier to set up and manage. Network Load Balancing NLB is a service that shares the load of incoming network connections among servers in a cluster, based on administrator-defined load-balancing policy. Application Center is intended to make NLB easier to use in clusters of Web servers sharing the load of incoming browser connections. The Application Center wizards provide a simpler user interface for setting up NLB than that provided by Windows 2000, and Application Center synchronization maintains uniform NLB settings across all servers in a cluster. After a cluster is up and running, administrators can adjust the most important settings (e.g., the percentage of connections that should be handled by a given server) from the Application Center console. The console also enables administrators to take a server offline (out of the NLB load-balancing process), bring it back online, and check whether a server is on- or offline. The command to take a server offline will prevent new connections, thus draining clients from the server for an administrator-specified period of time. In addition to NLB management and monitoring support, Application Center delivers an IIS component for handling sessions, which might be required to make some applications work reliably with NLB. (See the sidebar "Supporting Session State with NLB".) Some companies will pass on NLB and use dedicated load-balancing network devices (e.g., Cisco LocalDirector) to balance load among their Web servers, because those devices might provide higher throughput, more efficient sessions, or simpler server configuration. The Application Center Resource Kit includes a tool that enables administrators to control several brands of these devices from the Application Center console. Component Load Balancing Application Center is the first (and only) product to deliver CLB, which, like NLB, was originally intended to be a built-in feature of Advanced Server and Datacenter Server but was pulled from those products until Microsoft could create the necessary configuration and monitoring tools (which then became Application Center). CLB provides load balancing for collections of COM+ components, spreading requests to start up components across all servers in a cluster. (See the illustration "How Component Load Balancing Works".) CLB is mainly designed to enhance availability of an application's business logic components when those components are deployed on a separate cluster of component servers, rather than on a cluster of Web servers within the application's presentation tier. A company might physically separate the presentation and business logic tiers into two clusters for a couple of reasons:
Note that putting a Web application's presentation and business logic tiers in separate clusters normally reduces overall application performance because it introduces network communication overhead between the two tiers. Thus, CLB generally isn't a solution for enhancing the performance of an application as a whole, even though it can enhance the performance of that application's business logic tier. Application Center's cluster management tools help administrators set up component server clusters that host COM+ components and the Web server clusters that activate these components. Application Center can automatically install COM+ components to subsets of the servers in a live cluster, draining connections to the target servers and stopping and restarting the necessary services, so that users will not notice when new components are installed. Ready for Prime Time? Application Center is already in production use at several companies, including the Lycos.com portal and the application hosting companies Data Return and Digex. All of these companies use it to host custom Web applications, but some customers have also tested Application Center with applications based on Microsoft's Commerce Server 2000 and BizTalk Server 2000. While the product has some field experience, Application Center customers should be aware of some potential problems and impending changes to the product. Potential Problems to Watch For Installation. Application Center requires Windows 2000 Service Pack 1 and 14 additional hotfixes to run. The product can't deploy operating system service packs or hotfixes; they must be installed individually on every server prior to installing Application Center. This makes it somewhat time-consuming to get from bare metal to a functioning Application Center server, although a supplied installation script automates the main steps. More importantly, the hotfixes need to be reapplied after installing any optional operating system components, and some components (e.g., the ADMINPAK.MSI administrative tools package) refuse to install at all on machines where the hotfixes have been applied. These issues should be resolved when Windows 2000 Service Pack 2 ships in the first half of 2001, as this service pack incorporates the hotfixes. Companies should investigate the possibility of using system imaging tools (such as Symantec Ghost) to create server images that include Application Center, hotfixes and service packs, and the operating system. Cluster size. Microsoft doesn't recommend cluster sizes over a dozen servers, as such clusters will likely overtax the controller during synchronization. Companies that need to manage many servers can break them up into smaller clusters. They can still manage these clusters and deploy applications to them from a single Application Center console, and use scripts to automate deployment and synchronization across multiple clusters. Monitoring and synchronization robustness. The cluster controller performs all synchronization and generates all the Application Center logging displays, and the controller role does not automatically fail over from one server to the next. As a result, failure of a controller will cause synchronization to cease and most Application Center monitoring displays to disappear. Administrators can change the controller in these situations and resort to the command-line interface and HealthMonitor snap-in for monitoring, if necessary. Administrators could also implement a form of automatic failover by creating a monitor that detects failure of the current controller and promotes another server to controller automatically. WAN deployment. Microsoft doesn't recommend Application Center for deployment of applications to clusters over a WAN because it lacks some features needed for WAN links, such as the ability to restart deployment from the point where a connection was lost and the ability to control the bandwidth it uses. These limitations could prevent Application Center's use in large, geographically dispersed sites, or in companies that have outsourced application hosting to an external provider. The Application Center CD-ROM does include a separate deployment tool called the Content Deployment System (also called the Content Replication Service and originally shipped in Site Server 3.0 Commerce Edition) which handles some of these issues, but which can't deploy some application elements (e.g., COM+ components). Moving applications to Application Center. Application Center is designed to run unmodified Windows 2000 multitier applications. Moving Windows NT 4.0 applications into this environment could require some extra work. The presentation tier of an application probably won't require changes, unless it uses nonstandard mechanisms to store session data. COM business logic components can be more problematic. Many such components can be simply repackaged into COM+ applications using the Windows 2000 Component Services tools. However, in some cases, differences between component behavior on NT 4.0 and Windows 2000 will require source code changes to these components. Documentation. The Application Center product documentation describes its major features and user interface, but doesn't provide advice on good administrative practices. Companies evaluating Application Center should supplement its documentation with the Application Center Resource Kit (available from Microsoft Press; see "Resources" below). Impending Changes Application Center will require some significant changes to support several products slated for release in 2001. Companies should coordinate their deployment plans for the following technologies with their plans for Application Center: Whistler. Application Center does not support installation on Whistler server, the successor to Windows 2000, because Whistler makes changes to many operating system and IIS settings that Application Center manipulates. The desktop versions of Whistler are planned for the first half of 2001, with server versions coming later in the same year. Microsoft Operations Manager (MOM). Application Center doesn't work with this systems management product, which Microsoft is building based on technology licensed from NetIQ. (See "Microsoft Launches .NET Management Services Initiative" on page 12 of the Dec. 2000 Update.) Microsoft has said that MOM will eventually replace HealthMonitor in all of its products, and MOM might also supplant the Application Center logging functions. It's currently scheduled to ship in the second half of 2001. .NET Framework. Application Center doesn't support Microsoft's .NET Framework development platform, which introduces a new version of Active Server Pages (ASP.NET) and new APIs that layer on top of and essentially replace COM+ and the native Windows APIs. (See "Developers Get First Look at .NET Framework" on page 21 of the Aug. 2000 Update.) Web applications written on this platform use a different executable format and installation technology than those supported by Application Center. The .NET Framework is due to ship in 2001, and Microsoft has already enlisted several companies to build applications on the new platform. In the long term, these three technologies will benefit Application Center because they make life easier for its product team. For example, Whistler's version of IIS will support XML configuration files that will be much easier to replicate and install than IIS’s current binary "metabase" file. MOM should provide a much more extensive monitoring functionality than Application Center. (Microsoft already recommends NetIQ to customers who want to supplement Application Center's monitoring tools.) The .NET Framework provides numerous features to make application deployment simpler and more reliable. However, some companies might choose to wait for versions of Application Center that support these new technologies. Requirements, Pricing, and Licensing The Application Center server components require Windows 2000 Server and Advanced Server; they aren't supported on Datacenter Server, despite some information to the contrary in the product's help files and the Microsoft Web site. On Windows 2000 Server, Application Center will install NLB, which doesn't come bundled on that operating system. The Application Center console can run on a Windows 2000 Professional desktop computer or on a server. As discussed above, the currently shipping version of Application Center won't support Whistler, the follow-on to Windows 2000. On both server and client platforms, Application Center requires at least 256MB of memory. Application Center is licensed exclusively on a per-processor basis, with an estimated retail price of US$2,999 per processor. Licenses are required for all machines that have the Application Center server components installed, including staging machines that aren't serving customers. Machines that have only the console components do not require an Application Center license. A free 120-day evaluation edition of the product is available at the Application Center Web site. Resources Product information and evaluation code for Application Center is at www.microsoft.com/applicationcenter. Technical information and Application Center's online documentation is at www.microsoft.com/technet/acs and www.microsoft.com/applicationcenter/techinfo. The TechNet site also includes useful sample chapters from the Application Center Resource Kit. For information on the Application Center Resource Kit, see mspress.microsoft.com/prod/books/4363.htm. For a thorough analysis of alternative Web application architectures with Application Center, see msdn.microsoft.com/library/techart/docu2kbench.htm. Deployment of Commerce Server applications with Application Center and several other tools is discussed at msdn.microsoft.com/library/techart/DeployContent.htm. Useful developer information on application servers is at www.appserver-zone.com. |
