The main elements of the operating system that the User Interface and Feature Set layers interact with are: the MMC, Microsoft Internet Information Services (IIS) version 5.0, the metabase, COM+, Network Load Balancing (NLB), and Microsoft Windows Management Instrumentation (WMI). Microsoft SQL Server 2000 (SQL Server) is outside this layer; however, it is integrated with the operating system and used solely for handling cluster-related data storage and retrieval.
The primary view of the cluster administration tool is an MMC snap-in. The snap-in requires WMI and will run on any version of Windows 2000 if the Application Center Administrative client is installed. The MMC itself doesn't provide any management behavior but acts as a host for management applications. It provides a multi-document interface in which each window is a console. Each console can contain one or more administrative components (snap-ins) that supply the management behavior.
The snap-in consists of a user interface that you can use to configure the majority of Application Center's settings. However, there are some properties that are configurable only through scripts or the command line.
NOTE
Because the goal of Application Center is Web server independence between the different versions of IIS, the Administrative client cannot be completely integrated with the IIS snap-in code base. It's recognized that configuring the settings on the Web server is an integral part of an administrator's daily job. To facilitate these activities and still achieve the design goal of Web server independence, Application Center allows the launching of external tools from within its own space.
The Application Center MMC provides several key elements:
The console tree is hierarchical and displays nodes that represent a cluster, cluster members, applications, events, and monitors. Derived by using Microsoft Win32 API code, these nodes support right-click pop-up menus and scoping. In the Web-based Administrative client, the console tree is presented, but it does not support pop-up menus or scoping.
The details pane provides a Web-based (HTML, Active Server Pages [ASP page], XML, DHTML, Vector Markup Language [VML]) view of information. These pages are used in both the Web-based Administrative client and the MMC-based Administrative client, and adjust according to the view that is in use. For example, the status pages in the Web-based Administrative client do not allow launching of external snap-ins such as Health Monitor or IIS. The details pane displays performance graphs and statistics, provides current status reports for the cluster and its members, and displays a list of certain tasks for a selected object, such as member synchronization.
NOTE
The Web-based Administrative client does not provide access to property dialog box-based configuration.
Application Center depends on several other tools for complete configuration and management of its services. These tools enable you to administer IIS, use COM+ services, and customize Health Monitor settings.
Of the numerous elements that constitute Application Center, WMI is perhaps the heart and soul of the product. WMI is a set of extensions to the Windows Driver Model (WDM) that provide an operating system interface through which components can provide information and notification. Using a bi-directional access mechanism, WMI brings together the management data from the hardware platform, drivers, and applications and passes consolidated data to a management information store. This store uses the Common Information Model (CIM) as the basis for exposing and interacting with the data it holds. In combination, WMI and CIM provide a mechanism that enables management applications, platforms, and consoles to perform the following types of tasks:
The architecture of the WMI technology consists of the following elements:
Figure 3.2 shows a simple model of the WMI architecture, including its relationship to MMC snap-ins.
Figure 3.2 The WMI technology architecture
As Figure 3.2 illustrates, MMC snap-ins such as Application Center can be used to display any information that is stored in WMI. The snap-in can also receive WMI event notification when information changes in the CIM Repository. Subsequent chapters deal with accessing WMI data in more detail, as well as placing information in the CIM Repository by using the Managed Object Format (MOF) language and its compiler.
The primary role of IIS is serving Web content in response to client requests. This service includes the provision of server-side processing for ASP pages. Additionally, IIS supports Application Center administration by providing content for the MMC details pane as well as Web-based administration by providing pages served from port 4242 of any cluster member. Application Center uses port 4242 by default, but you can reassign this port number. Another thing to be aware of is that although this site is installed on each cluster member, all requests should be forwarded to the cluster controller, so the site is "served" by the controller alone.
There are substantial differences between Microsoft Internet Information Server version 4.0 and IIS 5.0, both in terms of feature changes and added features. Since IIS 5.0 is a core requirement for Application Center-managed clusters, these distinctions are very important, particularly when it comes to server performance tuning and application design.
The differences between the two versions are summarized in Table 3.2 and Table 3.3. Additionally, you can obtain detailed information about individual features in the IIS 5.0 Help.
Table 3.2 Changed Features in IIS
Category | Description |
---|---|
Administration |
|
Programmatic administration |
|
ASP |
|
Registry |
|
Security |
|
Performance |
|
Table 3.3 New Features in IIS
Category | Description |
---|---|
Administration |
|
Programmability |
|
Security |
|
Internet |
|
Application Center uses the IIS metabase to store server and cluster configuration settings.
If you haven't used IIS 5.0 extensively, you should refer to the IIS documentation to see how this information store operates, how it is structured, and how you can access it programmatically. The key aspects of the metabase are summarized next.
Organization
The metabase is organized in a hierarchical structure that mirrors the structure of the IIS installation. Figure 3.3 shows a portion of the IIS structure, which is arranged by key types. The metabase structure of your IIS and Application Center installation can consist of a varied number of elements, depending on your installation choices.
Figure 3.3 The IIS metabase hierarchy
Metabase Properties and the Namespace
Each node in the metabase structure is called a key, and each key can contain one or more configuration values (Figure 3.4), called metabase properties. The Application Center metabase keys correspond to the elements of Application Center, and each key contains properties that affect the configuration of its associated element.
Figure 3.4 Using the IIS metabase to store property values
Metabase keys that are associated with specific elements are referenced by their paths, which are analogous to a directory in a file system, within the metabase. The metabase path, or namespace, specifies the location of metabase properties. It is organized as follows:
LM/Service/Website/Root/virtual_directory/dir/file
Where:
For example, if the namespace of the metabase path LM/W3SVC/Website1/Root is associated with the path C:\Inetpub\WWWrooot, the URL http://domain.com/default.htm can be mapped to the physical file path C:\Inetpub\WWWroot\Default.htm.
NOTE
Key names in the metabase are not unique unless qualified by their metabase paths, just as different files with the same name can exist in different directories.
Figure 3.5, which provides a view of the metabase on an Application Center server, shows a highlighted metabase path.
Figure 3.5 A view of the Application Center metabase
Property Inheritance
You can use the property inheritance feature of the metabase to configure your installation with few settings and to minimize the amount of memory required for the metabase. Most metabase properties are inheritable, meaning that they are not explicitly set at a specific key and will inherit values assigned at higher-level keys. For example, you can set file and directory permissions such as AccessScript, AccessExecute, and AccessWrite at the W3SVC level to apply to all files and directories in all server instances, or you can set them at the W3SVC/2/ROOT level to apply to all files and directories for the second Web server only. Then, you can set different permissions for individual subdirectories and files by explicitly setting them at lower levels. For example, you might set the AccessExecute permission property to TRUE for specific directories, virtual directories, or files, such as ...W3SVC/1/ROOT/VDir1/VDir1a, ...W3SVC/1/ROOT/VDir2/Dir2d, and ...W3SVC/1/ROOT/VDir2/Dir3/File1, and so on.
Most metabase properties are inheritable, except for a few that are used only at specific keys. Some properties in the metabase are lists of values, such as the ServerBindings property.
Flag properties, such as file access permissions, are often combined into one DWORD by use of bitmasking. The entire set of flags is stored together and inherits together. For example, if you change one of the file access permissions, such as AccessExecute, for a directory, the entire set of file access permissions is stored at the metabase key for that directory.
Metabase Access Control
The metabase key values are stored in a disk file, which is named Metabase.bin by default. The metabase is loaded from disk when IIS starts, stored to disk when IIS shuts down, and saved periodically while IIS is running. It is important to protect this file from unauthorized use. Additionally, it is recommended that you store this file on an NTFS partition protected by Windows security mechanisms.
WARNING
You can edit the metabase directly—a metabase editor (MetaEdit 2.0) ships with the Microsoft Windows 2000 Server Software Development Kit—but exercise extreme caution if you choose to do this. An incorrect value or deleted key could totally destroy your cluster configuration.
Network Load Balancing (NLB) is available with Microsoft Windows 2000 Advanced Server and supports clusters of up to 32 servers. NLB makes it possible to evenly distribute incoming traffic while also monitoring server and network adapter health across a server group. The NLB scaling out model, sometimes called software scaling, provides the dual benefits of simple, incremental scalability and high availability. For more information about NLB scalability and performance, see Network Load Balancing Technology Overview in the Appendix.
Note the following points regarding Windows NLB:
Because of its level of integration with Windows NLB, the Application Center interface provides a single point for configuring and managing NLB on a cluster. This level of integration ensures that all cluster services, such as replication, are fully aware of each other.
In addition to providing full support for COM+, Application Center provides Component Load Balancing (CLB) as one of its core services. Application Center uses a common interface for configuring and managing load-balanced component servers in the same manner as NLB. This unified view of cluster load balancing makes it very easy to manage cluster subsets that need to use either type of load balancing.