Introduction to Windows Server R2 cluster failover

A failover cluster is a set of independent computers that work together to improve the availability and extensibility of clustered roles (formerly known as clustered applications and services). A clustered server (called a node) is connected by a physical cable and software. If one or more group aggregation points fail, the other nodes can continue to serve (this process is called failover). In addition, the cluster role can proactively monitor to verify that the node is working correctly. If it does not work correctly, it will be restarted or transferred to another node. The failover cluster also provides a cluster shared volume (CSV) feature that provides a consistent distributed namespace for cluster roles, which allows the cluster nodes to access shared storage for all nodes. By using the Failover Clustering feature, users experience minimal disruption to the service. Failover clustering has several typical practical scenarios:

1) provide highly available or continuously available file share storage for applications such as Microsoft SQL Server and Hyper-V virtual machines.

2) A highly available cluster role, such as a clustered DHCP server, running within a virtual machine that is running on a physical server or a Hyper-V server.

Windows Server R2 Failover Clustering Features:

1. Create a cluster of up to 64 nodes, extending the administrator's environment, while the older version can contain only 16 nodes.

2. By scaling the infrastructure, each cluster can run up to 8,000 virtual machines, and each node can run up to 1,024 virtual machines.

3. Has the ability to control virtual cluster set management and other cluster roles.

4. Increased support for extended file servers compared to Windows Server R2.

5. Support for cluster-aware update (CAU), cluster-aware update (CAU) is an automated feature that allows updates to be applied automatically to the host operating system in a clustered server, with minimal or zero availability loss during the update

6. In a cluster running Windows Server R2, an administrator can configure the monitoring of services on a clustered virtual machine that is running Windows Server R2 concurrently.

From a virtualization perspective, failover clustering provides highly available virtual machines. If the physical host fails, the virtual machine running on that host will also be interrupted. This can cause disruptive shutdowns and cause virtual machine downtime. However, because the physical nodes are part of the cluster, the remaining cluster nodes can be restarted again by coordinating the virtual machines that will be down, and then starting again quickly through the other nodes in the cluster. This process is automated and requires no IT administrator intervention, so you can ensure that the load running in the cluster is higher availability than the load running in the standalone physical server.

In Windows Server R2 and older versions, running virtual machines in a cluster requires that the virtual machine must use shared storage. Shared storage In this scenario means an ISCSI or Fibre Channel-connected SAN. In Windows Server 2012 and subsequent Windows Server R2, a failover cluster can support placing a virtual machine on a file share, using the SMB 3.0 protocol for network access. This enables administrators to gain greater flexibility in deploying the infrastructure and to simplify the deployment and management experience.

For customers who still want to take advantage of SAN storage as a shared storage solution, it is highly recommended to present the LUNs of the San directly to each node of the cluster and use those LUNs as cluster shared volumes.

One, cluster Shared volumes:

The cluster shared volume (CSV) feature of the Windows Server R2 failover cluster enables multiple nodes of a cluster to read and write access to NTFS volumes supplied in the same LUN (disk) concurrently. By using CSV, cluster roles can quickly fail over from one node to another without changing the ownership of the drive or disconnecting and reloading the volume. CSV also helps simplify the management of a large number of LUNs in a failover cluster. For each node in the cluster, the CSV is rendered as a consistent file namespace, such as C:\ClusterStorage\Volume1. CSV provides a general-purpose clustered file system based on NTFS and is not intended to be used only for the specified cluster load. (In Windows Server R2, CSV only supports Hyper-V load.) Applications for CSV include:

1) The Clustered virtual disk (VHD) file that is used for the clustered Hyper-V virtual machine.

2) Use scale-out file sharing to store application data for scale-out file server roles. Examples of such applications include hyper-V virtual machine files and Microsoft SQL Server data.

1. Optimized CSV placement Policy:

In a failover cluster, there is a node that is considered the owner of the CSV or the "Coordination node". The coordination node has a physical disk resource that has a logical unit number (LUN) associated with it. All I/O operations against the file system need to be done through the coordination node. Distributed CSV ownership improves disk performance because it helps load balance disk I/O.

Because CSV ownership can be balanced across all cluster nodes, the number of CSV owned by the node will no longer be asymmetric, so if one node fails, the transition to CSV ownership becomes more efficient. For scale-out file server clusters that use storage space, this feature is important because it ensures the dispersion of storage space ownership.

In addition, in Windows Server R2, ownership is automatically rebalanced for situations such as CSV failover, node rejoin, adding new nodes to the cluster, restarting cluster nodes, or restarting the failover cluster after shutting down.

2. Enhance the adaptability of CSV: Windows Server R2 contains the following improvements on CSV adaptability:

1) Multiple Server service instances per failover cluster node. The default instance is responsible for processing incoming traffic from the server Message Block (SMB) client and accessing the file share, which assists the CSV instance in processing the CSV traffic between the nodes. This inter-node communication includes meta-data access and I/O communication redirection.

2) CSV health monitoring for server services.

CSV uses SMB as the transport for I/O forwarding between cluster nodes and is used to implement metadata updates. If the server service becomes unhealthy, it can affect I/O performance and the ability to access storage. Because the cluster nodes can now contain multiple Server service instances, the CSV will get a greater degree of adaptability if the default instance encounters problems. In addition, this change also improves the extensibility of SMB communication between CSV nodes.

If the server service becomes unhealthy, it may affect the ability of the CSV coordination node to accept other node I/O requests, as well as the operation to perform metadata updates. In Windows server R2, if a node's server service becomes unhealthy, CSV ownership is automatically transferred to other nodes to ensure adaptability.

In Windows Server 2012, there is only one instance of the server service for each node, and the Server service is not monitored.

Second, Active Directory-separated clusters

In Windows Server R2, you can deploy a failover cluster without relying on Active Directory Domain Services (AD DS) as the network name. This cluster is also known as a separate cluster for Active Directory. When a cluster is deployed in this way, the network name of the cluster network name (also called the Management access point) and any cluster nodes used by the client access point will need to be registered in the Domain Name System (DNS). However, in AD DS, you do not need to create computer objects for such a cluster, including the computer objects of the cluster itself (also known as the Cluster name object, CNO), and the objects that are created when you access the clustered role for any client access point in AD DS (also known as a virtual computer object, or VCO). (cluster nodes still need to be part of an Active Directory domain.) ）

This deployment allows you to create a failover cluster directly without the required permissions to create computer objects, or without resorting to Active Directory administrators to update computer objects in AD ds. In addition, you do not need to manage and maintain cluster computer objects for such a cluster. For example, you can avoid problems that occur when an Active Directory administrator accidentally deletes a cluster computer object, which can have a significant impact on the availability of the cluster payload.

The option to create an Active Directory detach cluster is not included in Windows Server 2012. In Windows Server 2012, you can deploy a failover cluster only if the cluster network name is present in both DNS and AD DS.

Active Directory-Detached clusters use Kerberos to authenticate intra-cluster traffic. However, if authentication is required for the cluster network name, the cluster will use the NTLM protocol.

Windows Server 2012 and Windows Server R2 clusters can also be started without relying on AD DS, so a greater degree of flexibility is provided for data centers that run virtualized domain controllers in the cluster.

III. cluster arbitration and dynamic testimony

Quorum for a cluster is determined by the number of voting elements, which ensures that the cluster can start and run continuously. In general, each node in the cluster has a quorum vote, and the quorum witness (after configuration) can have an additional quorum vote. In Windows Server 2012, you can configure a quorum witness for each cluster. The quorum witness can be a specified disk resource or a file share resource. Each element can determine whether the cluster is operational by casting its own "ticket". The quorum result for the cluster to work correctly is determined by the majority of voting elements in the active cluster relationship.

To improve the availability of the cluster and the hosted roles in the cluster, the settings for the clustered quorum configuration must be cautious.

The cluster quorum configuration will directly affect the high availability of the entire cluster because:

1) helps to ensure that the failover cluster is still up and running after a change in the active membership. The change in membership may be due to a node's planned or unplanned shutdown, or the interruption of the connection between the node and the cluster storage.

2) When a subset of nodes cannot communicate with other subsets of a node (split cluster), the cluster quorum configuration helps ensure that only one subset of the cluster can run continuously. A subset that lacks enough quorum voting will stop running as a cluster. A subset with most quorum votes can continue to assume the cluster role. This prevents the cluster from generating partitions and ensures that the same application is not hosted by multiple partitions at the same time.

In a clustered environment, running with cluster full functionality also depends on the following factors:

1) network connection between group aggregation points.

2) The capacity placed on each node that hosts the cluster resource.

3) Priority setting for the cluster role.

1. Witness configuration:

As a general rule, when you configure quorum, the voting elements in the cluster must be odd. Therefore, if the cluster contains an even number of polling nodes, you must configure the disk witness or file share witness. The cluster can withstand the failure of one additional node. Additionally, adding a witness poll allows the cluster to continue to function correctly with half of the nodes failing or disconnecting at the same time.

A disk witness is generally recommended if all nodes have access to the disk, and a file share witness is recommended if you need to implement multi-site disaster recovery through replication storage. You can configure a disk witness for an environment that contains replication storage only if the storage vendor supports read-write access to replication storage from all sites.

2. Allocation of node votes "

In Windows Server 2012, an administrator can choose to assign or cancel a quorum vote for each node as an advanced quorum configuration option. By default, all nodes can vote, no matter how the votes are allocated, all nodes can work in the cluster, get updates to the cluster database, and host the application.

Under certain disaster recovery configurations, administrators may want to cancel the polling of certain nodes. For example, in a multi-site cluster, you can cancel the voting rights of nodes within a site, so that these nodes do not affect the results of the quorum calculation. However, this is only recommended for environments with manual failover across sites.

To view the voting options for a node configuration, use the Get-clusternode Windows PowerShell cmdlet to view the common properties NodeWeight for the cluster nodes. A value of "0" means that the node cannot participate in the quorum vote, and if the value is "1" it means that the node will participate in the quorum vote and be managed by the cluster. Voting allocations for all cluster nodes can be verified using Validate Cluster Quorum validation tests.

3. Dynamic arbitration management:

In Windows Server 2012, as an advanced quorum configuration option, administrators can choose to enable dynamic quorum management for clustering. When this option is enabled, the cluster can dynamically manage the node's voting allocations based on the state of each node. A node that leaves an active cluster relationship is automatically canceled, and the node that rejoin the cluster can get a vote again. Dynamic quorum management is enabled by default. Note – with dynamic quorum management, most of the cluster quorum will be determined by the nodes at any time within the cluster active member relationship. This is very different from the cluster quorum for Windows Server R2, where the majority of the previous quorum is fixed, depending on the initial cluster configuration. With dynamic quorum management, the cluster can also function properly through the last surviving cluster node. By dynamically adjusting the majority of the quorum requirements, the cluster can sustain the shutdown of the node until the last node remains.

The dynamic polling that the cluster assigns to the nodes can be verified by using the Get-clusternode Windows PowerShell cmdlet to view the common properties of the cluster nodes dynamicweight. A value of "0" means that the node does not have a quorum vote, and a value of "1" means that the node has a quorum vote.

4. Dynamic Witness:

In Windows Server R2, if the cluster is configured to use dynamic quorum (the default setting), the witness poll will also dynamically adjust based on the number of voting nodes in the current cluster relationship. If there is an odd number of votes, the arbitration witness will not participate in the voting, and if an even number of votes are cast, the arbitration witness will participate in the vote.

650) this.width=650; "height=" 424 "title=" clip_image002 "style=" margin:0px;border:0px;padding-top:0px; Padding-right:0px;padding-left:0px;background-image:none, "alt=" clip_image002 "src=" http://s3.51cto.com/wyfs02/ M00/57/b1/wkiol1sippri-mjraae_h-q3eqq647.jpg "border=" 0 "/>

As seen in, for this cluster with 64 nodes, we used the "node and disk majority" quorum configuration, and this is the default recommended setting, but there are altogether 64 votes – even number. We need an odd number of votes, so we use the witness disk as a 65th vote. However, if a node is about to be lost, then there are 63 running nodes left:

650) this.width=650; "height=" 423 "title=" clip_image004 "style=" margin:0px;border:0px;padding-top:0px; Padding-right:0px;padding-left:0px;background-image:none, "alt=" clip_image004 "src=" http://s3.51cto.com/wyfs02/ M01/57/b1/wkiol1sipprgba5jaae6v8-uaxa263.jpg "border=" 0 "/>

In this example, the load has failed over to the other node, and the voting for the Shut down node is canceled. This leaves us with 63 nodes, one for each node, and one for the witness disk. So there are 64 votes in total – and an even number. As already mentioned, we need to make sure that the number of votes is odd, and in Windows Server R2, we can automatically adjust the number of tickets for the witness disk to 0. Cluster quorum is also automatically adjusted, and this time it becomes "node majority".

The quorum witness vote can also be adjusted dynamically based on the health of the witness resources. If the witness resource goes offline or fails, the cluster sets the witness poll to "0".

The dynamic witness feature greatly reduces the risk of cluster downtime due to witness resource failures. The cluster determines whether or not to use a witness vote based on the number of node votes currently available.

This change also greatly simplifies the configuration of the cluster witness. The administrator no longer needs to decide whether to configure the quorum witness, because the recommended configuration for Windows Server R2 always includes the quorum witness. The cluster can automatically decide when to use the witness.

Four. Empty the virtual machine when shutting down

In Windows Server 2012, if the node is not emptied before the group staging point is closed, the virtual opportunity is switched to the save state and then to the other node for recovery. This means that the availability of the virtual machine will be interrupted. If it takes too long to save the virtual machine state, the virtual machine can be shut down and then restarted on the other nodes. However, in Windows Server R2, the cluster can automatically migrate the running virtual machines to other nodes in real time before shutting down.

This change provides a more secure mechanism to ensure that the server shuts down (or any case where the Cluster service needs to be shut down) does not cause unplanned downtime for virtual machines. This design improves the availability of the applications running within the guest operating system.

Microsoft officials recommend that administrators put the cluster node in maintenance mode before shutting it down, or move all virtual machines to another node. This is the safest way to clear a running cluster role.

To enable or disable this feature, you need to configure common properties for the Drainonshutdown cluster. This property is enabled by default (the value is "1").

Five, virtual machine network health detection

In Windows Server 2012, if a network outage occurs at the virtual machine level, the virtual machine is still running correctly on the computer, although it is not available to users.

In Windows Server R2, a new protection network option is added to the virtual machine's setup interface. If a protected virtual network is disconnected, the cluster migrates the affected virtual machines to other host computers that are available to the external virtual network in real time. There must be multiple network paths between the cluster nodes.

650) this.width=650; "height=" 106 "title=" clip_image006 "style=" margin:0px;border:0px;padding-top:0px; Padding-right:0px;padding-left:0px;background-image:none, "alt=" clip_image006 "src=" http://s3.51cto.com/wyfs02/ M02/57/b1/wkiol1sipprjxej9aacfkiunpiq318.jpg "border=" 0 "/>

This setting is located under Advanced features of the network adapter. This setting is enabled by default. Administrators can modify this setting for each network for each virtual machine, so if you have a low-priority network, such as a network for testing or backup, you can choose not to migrate the virtual machine in real time after such a network is disconnected.

If there are no available networks to connect to other nodes of the cluster, the cluster removes this node from the cluster membership, transfers ownership of the virtual machine files, and then restarts the virtual machines on the other nodes.

This change increases the availability of virtual opportunities to network problems. In real-time migrations, because live migration can maintain the session state of a virtual machine, no downtime is incurred.

Vi. Enhanced cluster dashboards

In Windows Server 2012, you need to click the name of each failover cluster to view status information. In Windows Server R2, the new cluster dashboard for failover Cluster Manager allows administrators to quickly view the health status of all managed failover clusters. The administrator can see the name of the failover cluster and, through the icons, understand the running state of the cluster, the number and status of the cluster roles, and the node status and event status.

650) this.width=650; "height=" 482 "title=" clip_image008 "style=" margin:0px;border:0px;padding-top:0px; Padding-right:0px;padding-left:0px;background-image:none, "alt=" clip_image008 "src=" http://s3.51cto.com/wyfs02/ M00/57/b1/wkiol1sippqdhfg4aae07licm9u741.jpg "border=" 0 "/>

If you are managing multiple failover clusters, the dashboard makes it easier for administrators to quickly see the health of the failover cluster.

Vii. Virtual Machine Monitoring

In a cluster running Windows Server 2012 and Windows Server R2, administrators can monitor services within a clustered virtual machine that is also running Windows Server 2012 or Windows Server R2. Administrators can monitor any Windows service within a virtual machine (such as SQL or IIS), or any ETW events that occur on a virtual machine. When an administrator-monitored condition is triggered, the Cluster service logs the host's error log and performs a recovery operation. These operations may be restarting the service or restarting or moving the clustered virtual machine on another node (depending on the service restart settings cluster and failover settings).

You can only see the services running with your own processes in the list, such as SQL, Exchange, but IIS and the Print Spooler service are not limited by this rule. However, you can monitor any NT service by using the Windows PowerShell Add-clustervmmonitoreditem cmdlet settings – there is no limit to this command:

Add-clustervmmonitoreditem–virtualmachine Bj-vm-03-service Spooler

650) this.width=650; "height=" 195 "title=" clip_image010 "style=" margin:0px;border:0px;padding-top:0px; Padding-right:0px;padding-left:0px;background-image:none, "alt=" clip_image010 "src=" http://s3.51cto.com/wyfs02/ M01/57/b1/wkiol1sippvihkqaaadzopqxis0184.jpg "border=" 0 "/>

650) this.width=650; "height=" 499 "title=" clip_image012 "style=" margin:0px;border:0px;padding-top:0px; Padding-right:0px;padding-left:0px;background-image:none, "alt=" clip_image012 "src=" http://s3.51cto.com/wyfs02/ M02/57/b1/wkiol1sippzcow_haairc7cw_au342.jpg "border=" 0 "/>

650) this.width=650; "height=" 499 "title=" clip_image014 "style=" margin:0px;border:0px;padding-top:0px; Padding-right:0px;padding-left:0px;background-image:none, "alt=" clip_image014 "src=" http://s3.51cto.com/wyfs02/ M00/57/b1/wkiol1sipp3jwcxqaaglejhello841.jpg "border=" 0 "/>

650) this.width=650; "height=" 499 "title=" clip_image016 "style=" margin:0px;border:0px;padding-top:0px; Padding-right:0px;padding-left:0px;background-image:none, "alt=" clip_image016 "src=" http://s3.51cto.com/wyfs02/ M01/57/b1/wkiol1sipp6dvbn_aahyhj9fkqc020.jpg "border=" 0 "/>

When a monitored service encounters an unexpected failure, subsequent recovery operations are determined by the service's recovery operations. These recovery actions can be viewed and configured within the guest system using service Control Manager. In the example shown, Service Control Manager will restart these services after the first and second failures, and if it fails again, Service Control Manager will not take any action. And the recovery operation is handled by the Cluster service that the host is running.

650) this.width=650; "height=" 499 "title=" clip_image018 "style=" margin:0px;border:0px;padding-top:0px; Padding-right:0px;padding-left:0px;background-image:none, "alt=" clip_image018 "src=" http://s3.51cto.com/wyfs02/ M02/57/b1/wkiol1sipp7bxht5aagqzp7txwc794.jpg "border=" 0 "/>

The Cluster service monitors the status of the clustered virtual machine through periodic health checks. When the Cluster service determines that a virtual machine is in a critical state, such as an application or service that is inside the virtual machine is unhealthy, the Cluster service performs the following recovery operations:

1) host record ID 1250 event – which can then be monitored by a centralized monitoring solution, such as System Center Operations Manager.

2) The virtual machine status in Failover Cluster Manager will show that the virtual machine is in the "Application critical" state.

3) Perform recovery operations on virtual machines in the "Application critical" state. Restart the virtual machine on the same node first. Note – The restart of the virtual machine is mandatory and does not allow cancellation. If the second failure occurs, the virtual machine restarts and fails over to the other nodes of the cluster. Note – failover, or restart on the same node, this decision is configurable and can be determined by the failover properties of the virtual machine.

Viii. priority for failover, correlation and inverse correlation

1. Priority level

In Windows Server 2012 and subsequent Windows Server R2, failover provides new features that enable administrators to define the boot order of virtual machines in a cluster so that, in the event of a failure, a large number of virtual machines need to be restarted as soon as possible, depending on the option settings, Some virtual machines can be prioritized for restart processing.

This feature helps administrators ensure that if a failover results in a high resource footprint, the most important virtual machines can always take precedence over all the resources they need before starting to process virtual machines that are of high importance.

650) this.width=650; "height=" 499 "title=" clip_image020 "style=" margin:0px;border:0px;padding-top:0px; Padding-right:0px;padding-left:0px;background-image:none, "alt=" clip_image020 "src=" http://s3.51cto.com/wyfs02/ M00/57/b1/wkiol1sipp-jbiyuaaieimiphz0944.jpg "border=" 0 "/>

Also, after a node failure, if a high-priority virtual machine fails to get enough memory and other resources needed to complete the boot operation, the Cluster service temporarily takes the low-priority virtual machine offline. Resources that are then freed can be assigned to high-priority virtual machines. When necessary, you can preempt a virtual machine that starts the lowest priority, and then continue to start a high-priority virtual machine. Preemption-initiated virtual opportunities are restarted in priority order.

2. Relevance

In Windows Server 2012 and Windows Server R2 failover clusters, administrators can configure preferred and possible owners.

650) this.width=650; "height=" 499 "title=" clip_image022 "style=" margin:0px;border:0px;padding-top:0px; Padding-right:0px;padding-left:0px;background-image:none, "alt=" clip_image022 "src=" http://s3.51cto.com/wyfs02/ M01/57/b1/wkiol1sipqdzdu9iaafrlew6iv0238.jpg "border=" 0 "/>

For a specific virtual machine (technically, any cluster group), you can configure the order of the nodes used in the failover. Assuming that the virtual machine is typically run on node A and the administrator wants to move it to node C as far as feasible, the preferred owner option defines the node that was first transferred to, the node to which it was transferred, and the node to which it was subsequently transferred. This is a list of priorities that the cluster will use to determine where to place the virtual machine. Therefore, the administrator can explicitly control the location of the virtual machine.

The possible owner, on the other hand, is that for a specific virtual machine (technically, any cluster resource), you can configure the nodes that the virtual machine might place on failover. This refers to all nodes by default, but if you do not want any virtual machines to fail over to a specific node, you can remove them from the list of possible owners and prevent them from being transferred to that node.

3. Anti-dependency

A possible owner is a way to make sure that the associated virtual machine-related virtual machines are dispersed across nodes, each with a relatively independent possible owner, but there is a different approach to this.

650) this.width=650; "height=" 371 "title=" clip_image024 "style=" margin:0px;border:0px;padding-top:0px; Padding-right:0px;padding-left:0px;background-image:none, "alt=" clip_image024 "src=" http://s3.51cto.com/wyfs02/ M02/57/b1/wkiol1sipqcivimraadflgdhubu034.jpg "border=" 0 "/>

AntiAffinityClassNames is another cluster group property that the Windows failover cluster uses to determine which cluster groups should not be located on the same node. When using a clustered Hyper-V environment, there is a 1:1 relationship between the group and the virtual machine, so you can use the AntiAffinityClassNames property to configure the inverse affinity for the virtual machine.

Once configured, the failover cluster tries to ensure that virtual machines belonging to the same group are dispersed across different nodes of the cluster whenever possible. With failover priority combined with preferred and possible owner features, the placement of critical virtualization loads can be more granular controlled.

Ix. Cluster-aware update

In older versions of Windows server, the Server Update tool (for example, WSUS) could not consider a group of servers that might be a highly available cluster member. Because the purpose of a highly available cluster is to provide high availability for services hosted in a cluster, it is not possible to install patches on all nodes of the cluster at the same time. Patch installation work for failover clusters is often done manually in batches, or with specialized scripts/tools, and requires close attention from the administrator to successfully install patches for all nodes in a short monthly maintenance window.

Cluster-aware update (CAU) is an important feature of Windows Server R2 built-in that solves this problem. CAU is available to administrators to update the clustered server, and the update process has little or no impact on availability or minimal impact. During the update, CAU will transparently set each node in the cluster to node maintenance mode, temporarily failover the cluster role to another node, install updates and other necessary content for the node, perform a restart operation when needed, leave the node out of maintenance mode, and re-transfer the initial cluster role to this node , and updates are performed on the next node. The work of CAU is independent of the specific load and is ideal for Hyper-V and various file server workloads.

In particular, from a hyper-V perspective, CAU can be used in conjunction with the Failover Clustering feature to migrate running virtual machines to different physical nodes, ensuring that critical applications and workloads running in the virtual machine are not down, and that the host facility can install the necessary updates and stay up to date.

After an administrator triggers a CAU scan, CAU will work with the node itself to perform an update check on the update source, such as the update source may be Microsoft update, Windows Update, or WSUS.

CAU helps organizations to promote consistency in IT processes. Updating run profiles can be created for different types of failover clusters and centrally managed through file sharing to ensure that CAU is deployed in a consistent manner across the IT organization, even if the cluster is managed by other lines of business or administrators.

The updated run can be scheduled, daily, weekly, or monthly, to ensure that the cluster's updates are consistent with other IT management processes, and CAU provides an extensible architecture that can update the cluster software inventory in a cluster-aware manner. This allows developers to reconcile software updates that are not released through Windows update or Microsoft Update, or update installations that are not from Microsoft, such as driver updates for non-Microsoft devices.

CAU's self-updating mode facilitates an "all-in-one cluster" appliance (a set of cluster environments running Windows Server 2012 and Windows Server R2, typically installed into a chassis) to update itself. In general, these devices are deployed in branch offices and lack local IT staff to administer the cluster. Self-updating patterns can provide tremendous value for such environments.

CAU has two modes: the self-updating mode as shown in the first diagram below, and the remote update mode as shown in the second figure.

In self-updating mode, you need to run the CAU role on one node and act as the coordinator of the update effort. Update Coordinator This node ensures that the update will be installed successfully throughout the cluster. The CAU role can also be cluster-aware, so the CAU Update coordinator role can be assumed by multiple nodes – but only one node at a time is the update coordinator.

650) this.width=650; "height=" 325 "title=" clip_image025 "style=" margin:0px;border:0px;padding-top:0px; Padding-right:0px;padding-left:0px;background-image:none, "alt=" clip_image025 "src=" http://s3.51cto.com/wyfs02/ M01/57/b4/wkiom1sipeutrgv7aacnnc8qyg8283.jpg "border=" 0 "/>

On the other hand, remote update mode makes it possible for a remote computer running Windows Server 2012, Windows Server R2, Windows 8, or Windows 8.1 to act as a CAU update coordinator. This approach is best for using CAU to install updates to the Windows server 2012/R2 Server Core operating system and to see the update progress in real time.

650) this.width=650; "height=" 307 "title=" clip_image027 "style=" margin:0px;border:0px;padding-top:0px; Padding-right:0px;padding-left:0px;background-image:none, "alt=" clip_image027 "src=" http://s3.51cto.com/wyfs02/ M00/57/b4/wkiom1sipezwybiiaadx-z9q6g8584.jpg "border=" 0 "/>

To deploy a failover cluster and take advantage of other features of the failover cluster, the following conditions are true:

1. Windows Server R2 or Hyper-V server R2 with Hyper-V.

2. For cluster shared volumes, shared storage is required and is connected via ISCSI or Fibre Channel.

3. For virtual machine monitoring, you need to create the appropriate firewall exception and provide the required domain configuration.

4. For cluster-aware updates, you need the WSUS infrastructure, or connect to the Internet from a cluster node to access the Microsoft/windows update.

Ten, guest cluster

In Windows Server-Hyper-V, Microsoft provides full support for the virtualization of virtual machines themselves, both from the cluster to the guest operating system. For example, a clustered SQL AlwaysOn configuration, which itself requires multiple nodes, all nodes are virtual machines, and access to shared storage is also required. The configuration looks similar to the following:

650) this.width=650; "height=" 463 "title=" clip_image029 "style=" margin:0px;border:0px;padding-top:0px; Padding-right:0px;padding-left:0px;background-image:none, "alt=" clip_image029 "src=" http://s3.51cto.com/wyfs02/ M01/57/b4/wkiom1sipezq4qiyaaewch9g43w637.jpg "border=" 0 "/>

In the example above, there is a simple three-node Hyper-V physical cluster that creates a two-node guest cluster with two virtual machines on top of the cluster, all of which have direct access to shared storage. Guest clusters that use shared storage can take advantage of the many different storage options available in the Microsoft platform. For example, if you use SMB storage as the primary means of storage for Hyper-V clusters, the SMB store is also available for use over the network for virtual machines. In this way, the virtual machine can access ISCSI storage with the help of a virtual network adapter. However, these scenarios require that the underlying storage facility be provided directly to the virtual machine through a virtual network adapter, rather than using a VHD or VHDX file saved on the shared storage.

Virtual Fibre Channel was first introduced in Windows Server 2012. As described above, this technology allows virtual light storage to be supplied directly to a virtual machine and can be directly built into a guest cluster by accessing shared storage.

As mentioned earlier, the guest cluster configuration is fully supported by Microsoft and can be used with other features such as live migration and dynamic memory, which means that customers can virtualize the cluster load without compromising important features such as density and agility. In addition, guest clustering can benefit from the features described above, such as failover prioritization, correlation, and anti-dependency, to ensure that guest cluster nodes can be optimally placed between each other and with the underlying physical host.

The advantage of a guest cluster is that it provides an additional layer of adaptability. If the physical host fails, it only causes a subset of nodes in the guest cluster to experience a failure, and the application-level adaptability provided by the guest cluster can still quickly restore the load.

650) this.width=650; "height=" 384 "title=" clip_image031 "style=" border:0px;padding-top:0px;padding-right:0px; Padding-left:0px;background-image:none, "alt=" clip_image031 "src=" http://s3.51cto.com/wyfs02/M02/57/B1/ Wkiol1sipqgzn2mxaadnimsj-pe809.jpg "border=" 0 "/>

When a physical node fails, a virtual machine that was previously running on that node also stops running, but the physical Hyper-V cluster ensures that the virtual machine is quickly restarted in the guest cluster virtual machine that the other node is running. Application-level adaptability ensures that the application or load will only experience a short outage over time, as a whole.

The challenge, however, is that in these configurations, the underlying storage (FC, ISCSI, SMB) needs to be supplied directly to the virtual machine. In a private or public cloud environment, it is often necessary to hide the details of the underlying facility for the user or tenant administrator.

This article is from the "Xu Ting blog" blog, make sure to keep this source http://ericxuting.blog.51cto.com/8995534/1597930

Introduction to Windows Server R2 cluster failover