Windows server failover cluster nodes

Preferred owner A node on which a resource group prefers to run. Each resource group is associated with a list of preferred owners sorted in order of preference. During automatic failover, the resource group is moved to the next preferred node in the preferred owner list. Possible owner A secondary node on which a resource can run.

Each resource group is associated with a list of possible owners. Roles can fail over only to nodes that are listed as possible owners. Quorum mode The quorum configuration in a failover cluster that determines the number of node failures that the cluster can sustain.

Force quorum The process to start the cluster even though only a minority of the elements that are required for quorum are in communication. Windows Server Failover Clustering provides infrastructure features that support the high-availability and disaster recovery scenarios of hosted server applications such as Microsoft SQL Server and Microsoft Exchange. If a cluster node or service fails, the services that were hosted on that node can be automatically or manually transferred to another available node in a process known as failover.

Distributed metadata and notifications. WSFC service and hosted application metadata is maintained on each node in the cluster. This metadata includes WSFC configuration and status in addition to hosted application settings. Changes to a node's metadata or status are automatically propagated to the other nodes in the WSFC. Resource management. Individual nodes in the WSFC may provide physical resources such as direct-attached storage, network interfaces, and access to shared disk storage.

Hosted applications register themselves as a cluster resource, and may configure startup and health dependencies upon other resources. Health monitoring. Inter-node and primary node health detection is accomplished through a combination of heartbeat-style network communications and resource monitoring.

Failover coordination. Each resource is configured to be hosted on a primary node, and each can be automatically or manually transferred to one or more secondary nodes. A health-based failover policy controls automatic transfer of resource ownership between nodes. Nodes and hosted applications are notified when failover occurs so that they may react appropriately.

The Always On features provide integrated, flexible solutions that increase application availability, provide better returns on hardware investments, and simplify high availability deployment and management.

Related resources are combined into a role , which can be made dependent upon other WSFC cluster resources. This type of instance depends on resources for storage and virtual network name. The virtual network name resource depends on one or more virtual IP addresses, each in a different subnet. In the event of a failover, the WSFC service transfers ownership of instance's resources to a designated failover node.

The SQL Server instance is then re-started on the failover node, and databases are recovered as usual. At any given moment, only a single node in the cluster can host the FCI and underlying resources. The shared disk storage volumes must be available to all potential failover nodes in the WSFC cluster.

This will make things easier when you want to create a stretched Failover Cluster. Since we just mentioned Storage Spaces Direct, one of the talked about features of it is repair. As a refresher, as data is written to drives, it is spread throughout all drives on all the nodes. When a node goes down for maintenance, crashes, or whatever the case may be, once it comes back up, there is a "repair" job run where data is moved around and onto the drives, if necessary, of the node that came back.

A repair is basically a resync of the data between all the nodes. Depending on the amount of time the node was down, the longer it could take for the repair to complete. A repair in previous versions would take the extent block of data that is normally 1 gigabyte or megabyte in size and resync it in its entirety.

It did not matter how much of the extent was changed for example 1 kilobyte , the entire extent is copied. In Windows Server , we have changed this thinking and now work off of "sub-extents". A sub-extent is only a portion of the entire extent. This is normally set at the interleave setting which is kilobytes. Now, when 1 kilobyte of a 1 gigabyte extent is changed, we will only move around the kilobyte sub-extent.

This will make repair times much faster and quicker to complete. To combat that, we also added the capability to throttle the resources up or down, depending on when it may be done. Therefore, you may want to set it on low so it more runs in the background. However, if you were to do it overnight on a weekend, you can afford to crank it up to a higher setting so it completes faster.

BitLocker Drive Encryption is a data protection feature that integrates with the operating system and addresses the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned computers. BitLocker on volumes within a cluster are managed based on how the cluster service "views" the volume to be protected.

BitLocker will unlock protected volumes without user intervention by attempting protectors in the following order:. Failover Cluster requires the Active Directory-based protector option 3 above for a cluster disk resource or CSV resources. Because it is Active Directory-based, a domain controller must be available in order to obtain the key protector to mount the drive. If a domain controller is not available or slow in responding, the clustered drive is not going to mount.

With this thinking, we needed to have a "backup" plan. With Windows Server , when a drive is enabled for Bitlocker encryption while it is a part of Failover Cluster, we will now create an additional key protector just for cluster itself. By doing this, it will still go out to a domain controller first to get the key.

If the domain controller is not available, it will then use the locally kept additional key to mount the drive. The default will always be to go to the domain controller first. We have also built in the ability to manually mount a cluster drive using new PowerShell cmdlets and passing the locally kept recovery key.

Another thing about this is that it now opens up the ability to Bitlocker drives that are a part of a workgroup or cross-domain cluster where a Cluster Name Object does not exist. Now data is encrypted before placement, leading to relatively minor performance degradation while adding AES and AES protected packet privacy. This means that when using Storage Spaces Direct and SMB Direct, you can decide to encrypt the east-west communications within the cluster itself for higher security.

Cluster resources are categorized by type. Failover Clustering defines several types of resources and provides resource DLLs to manage these types. In Windows Server , we have added three new resource types.

There's a ton of really cool low-level technical work that went into enabling containers on Windows, and we needed to make sure they were easy to use. This seems very simple, but figuring out the right approach was surprisingly tricky.

Our first thought was to extend our existing management technologies e. The topic covers a typical deployment, where computer objects for the cluster and its associated clustered roles are created in Active Directory Domain Services AD DS.

You can also deploy an Active Directory-detached cluster. This deployment method enables you to create a failover cluster without permissions to create computer objects in AD DS or the need to request that computer objects are prestaged in AD DS. This option is only available through Windows PowerShell, and is only recommended for specific scenarios. This requirement does not apply if you want to create an Active Directory-detached cluster in Windows Server R2.

You must install the Failover Clustering feature on every server that you want to add as a failover cluster node. On the Select installation type page, select Role-based or feature-based installation , and then select Next. On the Select destination server page, select the server where you want to install the feature, and then select Next.

On the Select features page, select the Failover Clustering check box. To install the failover cluster management tools, select Add Features , and then select Next. On the Confirm installation selections page, select Install. A server restart is not required for the Failover Clustering feature. After you install the Failover Clustering feature, we recommend that you apply the latest updates from Windows Update. Also, for a Windows Server based failover cluster, review the Recommended hotfixes and updates for Windows Server based failover clusters Microsoft Support article and install any updates that apply.

Before you create the failover cluster, we strongly recommend that you validate the configuration to make sure that the hardware and hardware settings are compatible with failover clustering.

Microsoft supports a cluster solution only if the complete configuration passes all validation tests and if all hardware is certified for the version of Windows Server that the cluster nodes are running.

You must have at least two nodes to run all tests. If you have only one node, many of the critical storage tests do not run. On the Select Servers or a Cluster page, in the Enter name box, enter the NetBIOS name or the fully qualified domain name of a server that you plan to add as a failover cluster node, and then select Add.

Repeat this step for each server that you want to add. To add multiple servers at the same time, separate the names by a comma or by a semicolon. For example, enter the names in the format server1. When you are finished, select Next. On the Testing Options page, select Run all tests recommended , and then select Next. If the results indicate that the tests completed successfully and the configuration is suited for clustering, and you want to create the cluster immediately, make sure that the Create the cluster now using the validated nodes check box is selected, and then select Finish.

Then, continue to step 4 of the Create the failover cluster procedure. If the results indicate that there were warnings or failures, select View Report to view the details and determine which issues must be corrected. Realize that a warning for a particular validation test indicates that this aspect of the failover cluster can be supported, but might not meet the recommended best practices. If you receive a warning for the Validate Storage Spaces Persistent Reservation test, see the blog post Windows Failover Cluster validation warning indicates your disks don't support the persistent reservations for Storage Spaces for more information.

For more information about hardware validation tests, see Validate Hardware for a Failover Cluster. To complete this step, make sure that the user account that you log on as meets the requirements that are outlined in the Verify the prerequisites section of this topic. If the Select Servers page appears, in the Enter name box, enter the NetBIOS name or the fully qualified domain name of a server that you plan to add as a failover cluster node, and then select Add.