Overview of Cluster : Final

Implementation Considerations
Describing steps you must take before you deploy a cluster. These include:

Selecting an implementation model
Selecting a configuration model
Determining hardware and network requirements


Virtual Servers
Each resource group in a cluster is associated with a unique IP address and a unique network name. These are considered virtual servers that clients can use to access the resources within the group. As a result, if a resource group fails over to another node in the cluster, the client access to the resource does not change. For example, if the client is accessing a virtual server using a UNC of \\MyServer\TheShare, the client will use the same UNC even if the resource has failed over to another node. This also means that the client does not know which physical node is responding to its request.

Implementation Models
The two models for implementing Cluster Service are Shared Device and Shared Nothing. These models are based on industry standards that define how the applications deployed on the cluster access the available hardware.

Shared Device
In this model, the software applications running on any node in the cluster can gain access to any hardware in the cluster. If two of the applications require the same processor, the data must be synchronized. In order to accomplish this, each application must include a component called a Distributed Lock Manager (DLM) that manages the synchronization.

DLMs keep track of references to hardware resources in the cluster and recognize and resolve conflicts. However, they introduce overhead into the system because of additional message traffic. In addition, there is a potential performance loss because multiple nodes will have access to all hardware resources in the cluster.

Shared Nothing
In this model, each node owns and manages its local disks. Common devices in the cluster are selectively owned and managed by a single node at any time. This makes it easier to manage disk devices and standard applications. In addition, the Shared Nothing model does not require special cabling and is designed to avoid overhead from DLMs. However, under this model, only one node can access a hardware resource at a time. During a failure, another node must assume ownership of the hardware resource to allow it to be accessed. When an application needs to access a resource, its request is sent to the node that currently owns the resource. This allows the creation of applications that are distributed across nodes in the cluster.

Cluster Service implements the Shared Nothing model by default. Because Cluster Service does not include a DLM, it relies on any application that needs access to shared hardware to provide its own DLM. As a result, if you deploy an application that comes with its own DLM, Cluster Service will automatically use the Shared Device model for this application.

Configuration Models
When you implement a cluster, you can select from among five configuration models, depending on your needs for the cluster. The configuration model you select will affect the overall performance of the cluster, the level of availability provided in the event of a failure, and the cost of implementing the solution.

Model A: High Availability with Static Load Balancing

Figure 1.4 Model A
In Model A (shown in Figure 1.4), each node in the cluster is responsible for specific resources. Further, each node must have the capacity to support the other node's resources in the event of a failover. Therefore, each node is typically configured to run at 50 percent of full load. This model provides optimum performance balance because both nodes support cluster resources. However, performance can be reduced in the event of a failover because one node will support all of the cluster's resources until the failed node becomes available.

Model B: Hot Spare with Maximum Availability

Figure 1.5 Model B
In Model B (shown in Figure 1.5), one node is completely responsible for managing the cluster's resources. The second node acts as a live backup that remains idle when both nodes are available. In the event of a failure, the idle node takes control of all the cluster's resources until the failed node becomes available. Unlike in Model A, the nodes are never fully utilized at the same time. Further, because one node remains idle during normal operations, the overall cost of this solution is higher than the other models. Performance is affected only if the nodes do not have the same hardware configurations. For example, if the "hot spare" node has less memory or CPU speed, the cluster's performance is reduced in the event of a failover.

Model C: Partial Cluster Service
In Model C (shown in Figure 1.6), the configuration is based on the Model B configuration in that one node provides complete support for all cluster resources at a time. However, unlike in Model B, the applications supported on the node include cluster-unaware applications that have some of their data stored on the local disks of one of the nodes. As a result, in the event of a failure, these applications are not failed over and remain offline until the original node is made available.


Figure 1.6 Model C
Model D: Virtual Server–Only (No Failover)

Figure 1.7 Model D
In Model D (shown in Figure 1.7), only one node is implemented in the cluster. As a result, there is no support for failover. Instead, the node is configured to support Cluster Service and allows for implementation of virtual servers to respond to client requests. Therefore, this configuration is not considered a cluster because only one node exists. This configuration is ideal if nodes will be added to the cluster in the future. It also allows resources to be grouped into virtual servers. When the cluster is fully implemented, clients do not have to be reconfigured based on any changes because the virtual servers used initially will still be valid.

Model E: Hybrid

Figure 1.8 Model E
The Model E configuration (shown in Figure 1.8) is a combination of any of the other configurations. Under this model, each node manages its own resources and provides support for failover. However, some nodes might support cluster-unaware applications while other nodes might not have the physical capacity to allow specific resources or applications to be failed over. In addition, some nodes might support resources that are not configured for failover and might remain offline until the node is made available.

Configuration Model Comparison
Table 1.1 compares the configuration models based on performance, level of availability, and cost for a cluster with two nodes.

Table 1.1 Configuration Model Comparison

Model Availability Performance Cost
A
High—availability is maintained during failover.
High—performance is reduced during failover.
High—both nodes must be able to support all resources.

B
Very High—availability is maintained during failover.
Very High—performance is maintained during failover.
Very High—half of the hardware investment sits idle until a failover occurs.

C
High—for resources that can be failed over.

Unchanged—for other resources.
Normal—performance can be dramatically reduced.
Average—depends on the number of applications during failover.

D
Unchanged— failover is not supported.
Unchanged—performance is not enhanced by Cluster Service.
Low—requires only one node.

E
High—availability is maintained as needed during failover.
High—performance is reduced during failover.
High—depends on number of resources supported by the cluster.


Hardware and Networking Considerations
Before you implement a cluster, you must consider what hardware will be required based on your needs. This includes the appropriate network configuration, such as network interface cards and cabling, to provide for the communication requirements between nodes.

Drive Technology Overview
You can use two categories of drive technology for the shared devices in a cluster: Small Computer System Interface (SCSI) and Fibre Channel. You cannot implement an IDE hard drive as a shared device in a cluster because IDE does not support sharing of its drives among multiple servers.

SCSI
SCSI is a popular drive technology among enterprises. It supports up to 15 devices per adapter and multiple adapters per server. When you use SCSI, you can connect devices internally to a server or connect them externally, creating a chain of devices. The devices can thus be potentially shared among servers, allowing Cluster Service to use SCSI. The primary benefits of SCSI include increased performance (compared to IDE) and lower cost (compared to Fibre Channel). A limitation of SCSI, when used in a cluster, is that it can support only a two-node cluster. If your cluster will include four nodes (using Windows 2000 Datacenter Server), you must use Fibre Channel.

SCSI will be the primary drive technology discussed and used in this training kit.

Fibre Channel
Fibre Channel is an industry standard that was developed in 1988 to provide support for high-speed standardized connections to storage devices. It is supported on all of the Windows 2000 operating systems. However, only Windows 2000 Datacenter Server supports a four-node cluster using Fibre Channel.

Fibre Channel was designed to be superior to SCSI technology in three areas:

A better connection for serial hard disk interfaces
A faster connection for communication between servers
A alternative networking medium to high-speed Ethernet
Disadvantages of Fibre Channel include higher cost, complex implementation, and increased maintenance compared to other drive technologies. Although Fibre Channel is not suitable for all storage solutions, it is rapidly gaining acceptance in large enterprise environments. Unlike Fiber Distributed Data Interface (FDDI), Fibre Channel was developed to support a greater number of protocols, including SCSI, IEEE 802.2, Internet Protocol (IP), and Asynchronous Transfer Mode (ATM), over a faster physical connection. Thus, Fibre Channel provides a single standard interface where other technologies require multiple interfaces.

Advantages of Fibre Channel include

A fast transmission rate of 100 MBps in both directions.
Increased transmission distance over other technologies, such as SCSI. Transmission distance is limited to about 20 meters for SCSI or up to10 kilometers for Fibre Channel.
Support for real-time hot swapping between drives. You can add or remove several drives from an active channel without interfering with data communication.
Support for arrays of up to 256 disk drives and drive sizes of up to 9 terabytes.
Compatibility with the standard SCSI commands, which Cluster Service relies on.
Cluster Service Hardware Requirements
As mentioned earlier, both Windows 2000 Advanced Server and Windows 2000 Datacenter Server support Cluster Service. You should verify that the hardware you're using is on the hardware compatibility lists (HCLs) for both the operating system and Cluster Service.

The Windows 2000 HCL and the Cluster Service HCL are at http://www.microsoft.com/hcl/default.asp.

NOTE
--------------------------------------------------------------------------------
The online HCL allows you to search on specific hardware components. However, clusters are certified only as a complete system, so you must use the Cluster HCL category to determine whether your hardware is supported.
General Hardware Requirements
Here is a general overview of the hardware required to implement Cluster Service:

Windows 2000 Advanced Server or Windows 2000 Datacenter Server installed on the boot partition of each server. The boot partitions cannot be shared between the servers.
A separate storage host adapter (PCI card) that supports SCSI or Fibre Channel. This must be separate from the adapter used for the boot device.
Two PCI network interface cards (NICs) in each server.
One or more external drives that can be connected to all the servers. Each of these external drives will be shared between the nodes in the cluster and is typically a SCSI drive. Ideally, each external drive should include multiple drives implemented in one or more RAID configurations.
The appropriate cabling to connect each external drive to the servers. If you're using a SCSI drive and the host adapters self-terminate, you do not need to use a Y-cable. Otherwise, you need the required terminators for the Y-cables when you use a SCSI solution.
You should also consider implementing the same RAM, processor, and local drive configurations in each server. If a node does not have the necessary hardware to support an application, it will not fail over. For example, an application might require a certain amount of RAM or hard drive space. Each node in the cluster should meet the minimum configuration requirements to support all the resources in the cluster.

NOTE
--------------------------------------------------------------------------------
All hardware between the servers should be identical. This includes the slot placement of the adapter cards, the brand of the cards (including the network interface cards, or NICs), and the cabling between the nodes and the external drives.
Cluster Service Shared Disk Requirements
In addition to the general hardware requirements, you should consider the following requirements when selecting a shared drive for your cluster:

All the shared drives that will be used by the cluster, including the drive used for the quorum resource, must be physically attached to all nodes in the cluster.
Be sure to first verify that the shared drives can be accessed from each node before you put the cluster into production.
When you use SCSI drives, each drive and each SCSI adapter must have a unique SCSI ID.
Each disk that is shared must be configured as a Basic disk, not a Dynamic disk.
Every partition on the shared disks must be formatted using the NTFS file system.
Cluster Service Network Requirements
You also need to consider the following network requirements for your cluster:

You must select a unique NetBIOS name for the cluster. This name will be used by clients for accessing resources in the cluster.
When you implement a two-node solution, the cluster will require at least five unique IP addresses. Two of these addresses can be private and will be used for cluster communication between the nodes. Two must be public addresses from your network and will be used by the NICs that are connected to your LAN. The fifth address must also be from your public network and will be used by the cluster itself.
Each node in the cluster must be configured as part of the same domain. One node can be a domain controller, while the other can be a member of the domain. If you decide to implement a domain controller, you can optionally make this the domain controller of a domainlet to reduce the amount of overhead.
A domain user account must be created in the same domain as the nodes. However, if a trust relationship exists, the account can reside in another domain. This account is used by the Cluster Service running on each node.
Although each node should have two NICs, one for the public network and one for the private network, you can configure one card per node. Note, however, that Microsoft does not support this configuration.
Cluster Planning Checklist
The following checklist can further help you plan your cluster implementation.

Assemble the planning team. The team should include members from various technical and business groups in the organization. Remember to include team members that can contribute information regarding third-party applications in addition to standard Microsoft technologies.
Identify which applications and services require high availability. These might include applications that have special hardware requirements, high volume of data, or unusual hours of operation in your organization. For example, an application might be needed 24 hours a day, seven days a week for multinational corporations with sales offices in many countries.
Decide which cluster technology to implement. Once you determine the applications and services to be supported by a cluster technology, you must decide between Cluster Service and NLB. This involves determining which applications should be used with NLB and which should be used with Cluster Service.
Identify network risks, including points of failure and connectivity problems. Be sure to consider external points of failure, such as the local telephone company or power utility.
Determine server capacity requirements based on the clustering technology you've selected and the requirements of the applications and services. Also consider the client demand and load that will need to be managed.
Plan how each resource group will fail over and fail back. You can specify the following properties on a per–resource group basis:
Failover Timing This property affects when the resource group will fail over. You can also instruct Cluster Service to attempt to restart the resource a specified number of times. If it is possible to restart all the applications and services in the resource group, Cluster Service will not implement a failover.
Preferred Node You can specify a particular node that should run a resource group when the node is available. Consider setting this property when a certain node is better suited to supporting the resource.
Failback Timing You can specify that a resource that has failed over should fail back to its preferred node immediately or at a certain time of day. For example, you might want a resource to fail back only after normal business hours to ensure that service to your clients is not interrupted.
Choose the role of each server. You must consider whether the server should be configured as a domain controller or as a member server of a domain based on the applications and services it will support. For example, a domain controller typically requires additional overhead, so it might not be the best choice for installing a SQL Server database that will have heavy use.
Select a cluster model based on your organization's requirements.
Consider the hardware requirements of each server based on the applications and services you intend to include in your cluster and the cluster model. This includes the disk capacity required for the cluster, available RAM in each server, and CPU speeds.
Plan a strategy for backing up the data in the cluster and recovering from a catastrophic failure. This plan should include the following general considerations:
Synchronizing backups
Creating backup storage space
Storing backup media
Maintaining a backup catalog

Summary
This lesson introduced implementation considerations for Cluster Service and explained the implementation models, Shared Device and Shared Nothing. By default, Cluster Service uses the Shared Nothing model, but it can use the Shared Device model if an application provides its own DLM. This lesson also explained the five configuration models:

Model A: High Availability with Static Load Balancing
Model B: Hot Spare with Maximum Availability
Model C: Partial Cluster Service
Model D: Virtual Server–Only (No Failover)
Model E: Hybrid
This lesson also provided an overview of the hardware and networking requirements of Cluster Service. This included an overview of the SCSI and Fibre Channel drive technologies. Some of the key requirements include:

Windows 2000 Advanced Server or Windows 2000 Datacenter Server installed on the boot partition of each server
Two PCI NICs in each server
One or more external drives that can be connected to all of the servers
Formatting of every partition on the shared disks using the NTFS file system
Selecting unique IP addresses and NetBIOS names for each node, each virtual server in the cluster, and the cluster itself

This lesson also provided a cluster-planning checklist that included 10 considerations for planning the deployment of Cluster Service.