Condividi tramite

What's New in Failover Clusters in Windows Server 2008 R2

  • Articolo

Applies To: Windows Server 2008 R2

What are the major changes?

In Windows Server® 2008 R2 Enterprise and Windows Server 2008 R2 Datacenter, the changes in failover clusters include the following:

  • Improvements to the validation process for a new or existing cluster. For more information, see Additional tests in cluster validation, later in this topic.

  • Improvements in functionality for clustered virtual machines (which run with the Hyper-V feature). These improvements help to increase the uptime and simplify the management of clustered virtual machines. For more information, see the description of Cluster Shared Volumes in What new functionality does failover clustering provide?, and see Options for moving a virtual machine to another node with little or no interruption for clients, later in this topic.

  • The addition of a Windows PowerShell interface. For more information, see What new functionality does failover clustering provide?, later in this topic.

  • Additional options for migrating settings from one cluster to another. For more information, see Additional options for migrating settings from one cluster to another, later in this topic.

Note

The failover cluster feature is not available in Windows® Web Server 2008 R2 or Windows Server® 2008 R2 Standard.

The sections that follow provide more detail about these changes.

What does a failover cluster do?

A failover cluster is a group of independent computers that work together to increase the availability of applications and services. The clustered servers (called nodes) are connected by physical cables and by software. If one of the cluster nodes fails, another node begins to provide service (a process known as failover). Users experience a minimum of disruptions in service.

Who will be interested in failover clustering?

Failover clusters are used by IT professionals who need to provide high availability for services or applications.

Are there any special considerations?

Microsoft supports a failover cluster solution only if all the hardware components are marked as "Certified for Windows Server 2008 R2." In addition, the complete configuration (servers, network, and storage) must pass all tests in the Validate a Configuration wizard, which is included in the Failover Cluster Manager snap-in.

Note that this policy differs from the support policy for server clusters in Windows Server 2003, which required the entire cluster solution to be listed in the Windows Server Catalog under Cluster Solutions.

What new functionality does failover clustering provide?

  • Windows PowerShell cmdlets for failover clusters. Windows PowerShell is a new command-line shell and scripting technology that uses consistent syntax and naming patterns across the roles and features in Windows Server 2008 R2. The new cmdlets for failover clusters provide powerful ways to script cluster configuration and management tasks. Windows PowerShell cmdlets will eventually replace the Cluster.exe command-line interface.

    If you use the Server Core installation option of Windows Server 2008 R2 for your failover cluster, the Windows PowerShell cmdlets for failover clusters simplify the local management of the cluster.

  • Read-only permissions option. You can assign read-only permission to a user or group who might need to see the cluster but not change the configuration of the cluster.

  • Cluster Shared Volumes. With Cluster Shared Volumes, the configuration of clustered virtual machines (supported by the Hyper-V feature) is much simpler than before. With Cluster Shared Volumes:

    • You can reduce the number of LUNs (disks) required for your virtual machines, instead of having to manage one LUN per virtual machine. (Previously, the recommended configuration was one LUN per virtual machine, because the LUN was the unit of failover.) Many virtual machines can use a single LUN and can fail over without causing the other virtual machines on the same LUN to also fail over.

    • You can make better use of disk space, because you do not need to place each Virtual Hard Disk (VHD) file on a separate disk with extra free space set aside just for that VHD file. Instead, the free space on a Cluster Shared Volume can be used by any VHD file on that LUN.

    • You can more easily track the paths to VHD files and other files used by virtual machines. You can specify the path names, instead of identifying disks by drive letters (limited to the number of letters in the alphabet) or identifiers called GUIDs (which are hard to use and remember). With Cluster Shared Volumes, the path appears to be on the system drive of the node, under the \ClusterStorage folder. However, this path is the same when viewed from any node in the cluster.

    • If you use a few Cluster Shared Volumes to create a configuration that supports many clustered virtual machines, you can perform validation more quickly than you could with a configuration that uses many LUNs to support many clustered virtual machines. With fewer LUNs, validation runs more quickly. (You perform validation by running the Validate a Configuration Wizard in the snap-in for failover clusters.)

    • There are no special hardware requirements beyond what is already required for storage in a failover cluster (although Cluster Shared Volumes require NTFS).

    • Resiliency is increased, because the cluster can respond correctly even if connectivity between one node and the SAN is interrupted, or part of a network is down. The cluster will re-route the Cluster Shared Volumes traffic through an intact part of the SAN or network.

What existing functionality is changing?

The following list briefly summarizes the improvements in failover clusters:

  • Additional tests in cluster validation. With the additional tests built into the Cluster Validation Wizard in the failover cluster snap-in, you can fine-tune your cluster configuration, track the configuration, and identify potential cluster configuration issues before they cause downtime.

  • Support for additional clustered services. In addition to the services and applications you could previously configure in a cluster, you can now cluster Distributed File System (DFS) Replication member servers and a Remote Desktop Connection Broker (formerly Terminal Services Session Broker).

  • Additional options for migrating settings from one cluster to another. The Migration Wizard built into the failover cluster snap-in can migrate settings from clusters running Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2, not just from clusters running Windows Server 2003 as was previously the case. The wizard can also migrate the settings for additional types of resources and resource groups.

  • Options for moving a virtual machine to another node with little or no interruption for clients. Windows Server 2008 R2 includes live migration, an option for moving a virtual machine to another node in a way that usually leaves the clients connected to the virtual machine. It also includes quick migration and moving of virtual machines, which are options similar to what was available in clusters running Windows Server 2008.

Additional tests in cluster validation

The cluster validation wizard previously included tests that helped you test a set of servers, their networks, and the attached storage before you brought them together in a cluster. The tests were also useful for re-testing a cluster after you made a change, for example, a change to the storage configuration. These tests continue to be available, with an additional set of tests. The new tests are called the Cluster Configuration tests, and they help you to check settings that are specified within the cluster, such as the settings that affect how the cluster communicates across the available networks. These tests analyze your current configuration down to the private properties of clustered resources to see if best practices are employed. You can also use the Cluster Configuration tests to review and archive the configurations of your clustered services and applications (including settings for the resources within each clustered service or application).

With these tests, you can fine-tune your cluster configuration, track the configuration, and identify potential cluster configuration issues before they cause downtime. This can help you optimize your configuration and compare it against the best practices that you have identified for your organization.

Support for additional clustered services

In addition to the services and applications you could previously configure in a failover cluster, you can now configure the following:

  • Remote Desktop Connection Broker (formerly Terminal Services Session Broker): Remote Desktop Connection Broker supports session load balancing and session reconnection in a load-balanced remote desktop server farm. RD Connection Broker is also used to provide users access to RemoteApp programs and virtual desktops through RemoteApp and Desktop Connection.

  • DFS Replication: DFS Replication is an efficient, multiple-master replication engine that you can use to keep folders synchronized between servers across limited bandwidth network connections. You can cluster any member server in the replication group.

Additional options for migrating settings from one cluster to another

The Migration Wizard built into the failover cluster snap-in can migrate settings from clusters running Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2, not just from a cluster running Windows Server 2003 as was previously the case. As before, the wizard can migrate settings from the following resource groups:

  • File server

  • Dynamic Host Configuration Protocol (DHCP)

  • Generic Application

  • Generic Script

  • Generic Service

  • WINS Server

In Windows Server 2008 R2, the Migration Wizard can also migrate settings from the following resource groups:

  • Distributed File System Namespace (DFS-N)

  • Distributed Transaction Coordinator (DTC)

  • Internet Storage Name Service (iSNS) Server

  • Message Queuing (also called MSMQ)

  • Network File System (NFS)

  • Other Server (client access point and storage only)

  • Remote Desktop Connection Broker

Note that other migration processes exist for additional clustered servers, such as clustered print servers.

Options for moving a virtual machine to another node with little or no interruption for clients

Failover clusters in Windows Server 2008 R2 provide multiple ways to move a virtual machine from one cluster node to another:

  • Live migration: When you initiate live migration, the cluster copies the memory being used by the virtual machine from the current node to another node, so that when the transition to the other node actually takes place, the memory and state information is already in place for the virtual machine. The transition is usually fast enough that a client using the virtual machine does not lose the network connection. If you are using Cluster Shared Volumes, live migration is almost instantaneous, because no transfer of disk ownership is needed.

    A live migration can be used for planned maintenance but not for an unplanned failover. On a given server running Hyper-V, only one live migration (to or from the server) can be in progress at a given time. For example, if you have a four-node cluster, up to two live migrations can occur simultaneously if each live migration involves different nodes.

  • Quick migration: When you initiate quick migration, the cluster copies the memory being used by the virtual machine to a disk in storage, so that when the transition to another node actually takes place, the memory and state information needed by the virtual machine can quickly be read from the disk by the node that is taking over ownership.

    A quick migration can be used for planned maintenance but not for an unplanned failover. You can use quick migration to move multiple virtual machines simultaneously.

  • Moving: When you initiate a move, the cluster prepares to take the virtual machine offline by performing an action that you have specified in the cluster configuration for the virtual machine resource:

    • Save (the default) saves the state of the virtual machine, so that the state can be restored when bringing the virtual machine back online.

    • Shut down performs an orderly shutdown of the operating system (waiting for all processes to close) on the virtual machine before taking the virtual machine offline.

    • Shut down (forced) shuts down the operating system on the virtual machine without waiting for slower processes to finish, and then takes the virtual machine offline.

    • Turn off is like turning off the power to the virtual machine, which means that data loss may occur.

    The setting that you specify for the offline action does not affect live migration, quick migration, or unplanned failover. It affects only moving (or taking the resource offline through the action of Windows PowerShell or an application).

Do I need to change any existing code or scripts to work with Windows Server 2008 R2?

If an application or service ran on a cluster with Windows Server 2008, you do not need to change the code to run the application or service on a cluster with Windows Server 2008 R2. If you have scripts based on Cluster.exe, you can continue to use them in Windows Server 2008 R2, but we recommend that you rewrite them with Windows PowerShell cmdlets. In future releases, Windows PowerShell will be the only command-line interface available for failover clusters.

How should I prepare to deploy this feature?

Carefully review the hardware on which you plan to deploy a failover cluster to ensure that it is compatible with Windows Server 2008 R2. This is especially necessary if you are currently using that hardware for a server cluster running Windows Server 2003. Hardware that supports a server cluster running Windows Server 2003 may not necessarily support a failover cluster running Windows Server 2008 R2. For more information, see Are there any special considerations?, earlier in this topic.

Note

You cannot perform a rolling upgrade from a cluster running Windows Server 2003 or Windows Server 2008 to a cluster running Windows Server 2008 R2. However, after you create a failover cluster running Windows Server 2008 R2, you can use a wizard to migrate certain resource settings to it from an existing cluster.

If you are planning to use Cluster Shared Volumes, set up the operating system of each server in your cluster so that it boots from the same drive letter as all other servers in the cluster. In other words, if one server boots from drive letter C, all servers in the cluster should boot from drive letter C.

Which editions include failover clustering?

The failover cluster feature is available in Windows Server 2008 R2 Enterprise and Windows Server 2008 R2 Datacenter. The feature is not available in Windows Web Server 2008 R2 or Windows Server 2008 R2 Standard.