Microsoft Application Center 2000 - 23 Oct 2000

Application Center leads the way to application scaling, management, and availability

If you've ever tried to set up, configure, or manage Microsoft Cluster Server (MSCS) or Network Load Balancing (NLB), you know how daunting the task can be. And Windows 2000, even with its heightened user-friendliness, hasn't made the task any easier. Vendors have taken MSCS configuration problems to heart and offer a multitude of solutions that don't require an administrator to start from scratch to get a cluster up and running. But few solutions address the complexities of configuring application load balancing through NLB and Component Load Balancing (CLB).

The idea behind NLB and CLB is simple: If you want to expand your network applications' capacity, then configure a server to run a network application and add the server to your network. The ability to leverage this kind of application enhancement is an important component of Microsoft's scale-out expansion and .NET strategies. (For information about scaling out, see "Scaling Out," September 2000. For information about Microsoft .NET, see Mark Smith, Editorial, "Microsoft. NET," October 2000.) Central to Microsoft's .NET strategy is Microsoft Application Center 2000. Application Center's purpose is to integrate and simplify application scaling, management, and availability.

Application Center clustering isn't MSCS clustering but rather network load balancing and COM+ application clustering. And although Application Center's clustering doesn't provide the same level of fault tolerance that MSCS does, it improves performance and doesn't require specialized hardware, as MSCS does. Application Center doesn't even require that its cluster servers be similar in configuration or capacity, only that they run Application Center. Application Center also doesn't offer 2-way or 4-way failover clustering; it offers the up-to-32-way clustering that NLB supports. COM+ load balancing is limited to 8-way, and the complexity of the applications that Application Center is running might limit the number of nodes in the cluster in other ways.

Installing and Setting Up Application Center
I sat down with the Application Center beta 2 to see how well Microsoft is living up to its promises. You install Application Center on the servers that run the applications you want to manage or scale; you can install the Application Center Microsoft Management Console (MMC) management snap-in on any Win2K machine that can see all your servers. You configure and manage Application Center from the snap-in console. A scriptable command-line interface is available for systems administrators who prefer to script their management tasks. A browser console is available, but this console only monitors the performance and health of an Application Center cluster. You can perform almost no administration with the Web interface, a design decision Microsoft made to limit security exposure through the Web.

After you install Application Center and have it running on a couple of machines, the next step is to set up a cluster. All you need to do is launch the New Cluster Wizard and choose which of the three supported cluster types you want to set up. You choose Web Clusters to run Web server applications, as well as local COM+ applications. You choose COM+ Application Clusters to simplify using CLB. You choose COM+ Routing when the COM+ requests that the cluster will handle don't come from within the Application Center cluster. After you've chosen the cluster type, the wizard walks you through creating and organizing the cluster.

An important point is that you must have an application to cluster. The New Cluster Wizard generates code that Application Center uses to glue the cluster together, but no way exists to build applications. You must still create Web applications as you have in the past—Application Center takes care of the problems inherent in load-balancing the application. If you understand the application you're running, Application Center makes getting your new cluster up and running a simple and straightforward process.

Adding Servers
Because one of Application Center's primary goals is to scale out applications through server addition, I tested Application Center by adding another server to my admittedly minimal two-machine cluster. To do so, I launched the Add Server Wizard from the Application Center MMC snap-in console. I used the Add Cluster Member task to identify the new server, then I used the Deploy Applications option to copy the existing cluster application. This option copies the entire application to the selected server.

Deploy Applications is an interesting feature because it doesn't require the add-on server to be part of the cluster, nor does the add-on server hardware need to be the same as or even similar to that of the cluster servers. Thus, you can use Deploy Applications to install an application on a server to duplicate the cluster servers' setup, a task usually reserved for a Systems Management Server (SMS)-type application, which often imposes the limitation that the add-on server's hardware must be identical or similar to the source servers' hardware. Although Microsoft doesn't position Application Center as a deployment tool, the possibility of using Application Center for that purpose exists.

Commanding Features
The ability to manage what you've set up is the necessary corollary to Application Center's simplified configuration and deployment. Application Center's goal is to collect the bits and pieces that make up a complex Web application and unify them in what Microsoft calls a Single Application Image—a logical construct that includes everything necessary to run the target application. Any tools that can make this task easier are welcome. Although my exposure to the Application Center beta didn't allow me time to work with a seriously complex Web application, Application Center's management tools easily handled the simple application I played with.

Among Application Center's most compelling features are the product's unified and enhanced performance and health monitoring tools. Application Center uses Windows Management Instrumentation (WMI) to provide information to the data analysis tools that Application Center includes. Every server in the cluster stores its performance and health data in a local version of the Microsoft SQL Server database engine. Because the data is stored locally, minimal additional network traffic is generated, and a dedicated management server isn't necessary. And because the local database is a SQL Server format database, you can use in Application Center all the tools that you might already be using to extract and analyze data in SQL Server. Microsoft provides documentation for the database schema, which is fully exportable to other tools as necessary. And because Application Center is a WMI provider as well as a WMI user, you can integrate with Application Center any third-party tools that use WMI. When Microsoft releases the final product, the company will announce which OEMs it has been working with to provide the first third-party integration and enhancement tools.

I hope I've given you a sense of Application Center's core functionality. Windows 2000 Magazine will review .NET applications in detail as the final code becomes available. If the final Application Center product holds to the promise of the beta I've been using, I might have to reconsider my traditional dislike of tools that mask their complexity to make life easier for users.