Microsoft Windows 2000

Microsoft Windows is a dominant operating system in the PC marketplace. It is based on the Windows NT architecture and it is a stable, multitasking, priority-based pre-emptive scheduling, and multi-threaded 32-bit operating system.

Some of the features of W2K are listed below:

• Supports multiple CPU’s and provides multi-tasking using SMP.

• Supports different CPU’s using the HAL (NT previously supported Intel x86, DEC Alpha, MIPS and it is understood this is set to continue) and multiprocessor machines using POSIX threads.

• Uses an object-based security model and its own file system (NTFS) that allows permissions to be set on a file and directory basis.

• Built-in Networking protocols such as IPX/SPX, TCP/IP, and NetBEUI.

Figure 3-7 below illustrates the overall structure of W2K.

Figure 3-7 – Windows 2000 Architecture

As with the majority of operating systems, W2K separates application-oriented software from operating systems software. The latter, which includes the Executive, the micro-kernel device drivers, and the HAL, runs in kernel mode. Kernel mode software has access to system data and to the hardware. The remaining software, running in user mode, has limited access to system data.

W2K has what is referred to as a modified micro-kernel architecture, which is highly modular.

Each system function is managed by just one component of the operating system and all applications access that function through the responsible component using a standard interface.

In principle any module can be removed, upgraded, or replaced without rewriting the OS or any of its standard API’s.

However, unlike a pure micro-kernel system, W2K is configured so that many of the system functions out-side the micro-kernel run in kernel mode. The reason is to boost the

The most important sub-system is the Win32 API. The Win32 API allows the applications programmer access to the many functions of the Windows platform and is the point of interface for the cluster middleware layer of software. [31] [32]

One of the drawbacks of using the Windows 2000 platform (standard and clustering versions) for clustering is cost. A cluster is designed to function as a single machine, however in most cases we use a local operating system on each node of the system and with the W2K licensing model this would mean we would need to pay a licence cost per node. One possible way around this is to use diskless nodes. However, with operating systems such as Linux that are freely available under the GNU General Public License model [39] this is not required.

Windows 2000 Cluster Server

Windows 2000 (W2K) Cluster Server (formerly codenamed Wolfpack) is a shared-nothing cluster, in which each disk volume and other resources are owned by a single system at a time.

A typical set-up for a W2K cluster is shown in Figure 3-8 below.

Figure 3-8 – Windows 2000 Cluster Server Topological Diagram

W2K is the next generation from Windows NT 4.0 and is the second generation of cluster operating systems from Microsoft.

W2K Cluster Server is based on the following concepts: [32]

• Cluster Service – The collection of software on each node that manages all cluster-specific activity.

• Resource – An item managed by the cluster service. All resources are objects representing actual resources in the system, including physical hardware devices such as disk drives, network cards and logical items such as logical disk volumes, TCP/IP addresses, entire applications, and databases.

• Online – A resource is said to be online at a node when it is providing service on that specific node.

Architectural Overview

Figure 3-9 – Windows 2000 Cluster Server Block Diagram

The Database Manager is the component of the Cluster Service that implements the cluster database. This database contains information about all of the entities in the cluster, such as the cluster itself, resource types, groups, and resources. The cluster database is stored in the registry on each node of the cluster.

The Database Managers, one on each node in the cluster, cooperate with each other to maintain consistent cluster configuration information.

In addition, the Database Manager also provides an interface to the configuration database that is used by the other components of the Cluster Service. Cluster services coordinate updates to the registry to maintain consistency and provide atomic updates across the nodes in the cluster.

The Node Manager on one node in the cluster communicates with the Node Manager on the other node in order to detect node failures in the cluster. This is accomplished by sending

"heartbeat" messages between the nodes.

If the Node Manager on a node does not respond, the active resources must be failed over to the node that is still running. The Resource/Failover Manager does the failover portion of this process. If the Cluster Service fails on a node, all of the resources on the node will failover even if the resources are still all online and functioning. This happens as a result of the Node Manager initiating failover of the resources since it is unable to communicate with the Node Manager on the other node.

Quorum Resource Interaction – If the communication link between the nodes becomes unavailable but both nodes are still functioning, the Node Manager on each node would try to fail the resources over to the node on which the Node Manager was running. This would result in each node thinking it is the surviving node of the cluster and would try to bring all the resources online. To prevent this situation, the Cluster Server relies on the quorum resource to ensure that only one node has a resource online. If communication between nodes fails, the

cannot access the quorum resource and is out of communication will take any resources it had offline.

The Event Processor is the communications centre of the Cluster Service. It is responsible for connecting events to applications and other components of the Cluster Service. This includes:

• Maintenance of cluster objects.

• Application requests to open, close, or enumerate cluster objects.

• Delivery of signal events to cluster-aware applications and other components of the Cluster Service.

The Event Processor is also responsible for starting the Cluster Service and bringing the node to the "offline" state. The Event Processor then calls the Node Manager to begin the process of joining or forming a cluster.

Communication Manager – The components of the Cluster Service communicate with the Cluster Service on other nodes through the Communication Manager. Communication Manager is responsible for the following:

• KeepAlive protocol. Checks for failure of the Cluster Service on other nodes.

• Resource group push. Initiates failover of resources from one node to another node.

• Resource ownership negotiation. Determines the new owner of resources from a failed node.

• Resource state transitions. Nodes notify the rest of the cluster when a resource goes offline or comes online. This is used to help track the owner of a resource.

• Enlist in a cluster. Initial contact with a cluster.

• Join a cluster. Synchronization with the other node in the cluster after going offline and coming back online.

• Database updates. Two-phase commit of cluster database updates.

The Global Update Manager provides an interface for other components of the Cluster Service to initiate and manage updates. The Global Update Manager allows for changes in the online/offline state of resources to be easily propagated throughout the nodes in a cluster. In addition, notifications of cluster state changes are also sent to all active nodes in the cluster.

Centralizing the global update code in a single component allows the other components of the Cluster Service to use a single, reliable mechanism.

The Resource/Failover Manager is responsible for:

• Managing resource dependencies.

• Starting and stopping resources, by directing the Resource Monitors to bring resources online and offline.

• Initiating failover and failback.

In order to perform the preceding tasks, the Resource/Failover Manager receives resource and