Shulou(Shulou.com)06/03 Report--

It is already 2018, so fast ah, here Lao Wang first wishes you good health in the new year, career success, in the new year Lao Wang will continue to share Microsoft enterprise technology for you, but also welcome you to discuss with me, learn together, this New Year's first Lao Wang wants to talk to you about WSFC cluster database, and some of its related components

First of all, we recall the basic concept of clustering introduced before, which mentions the operation mechanism of Windows clustering. During the operation of clustering, a cluster database will be generated and stored in the registry of each node. If there is a disk witness, it will also be stored in the disk witness. The cluster will record the status of each node and the cluster role hosted by the node in the registry, and then replicate on each node and disk witness. When one of the nodes goes down, Cluster Coordinates Other Living Nodes Check their own cluster database registry to see the roles hosted by the down node and perform failover

Therefore, you can see that the cluster database stores configuration data such as node state, cluster state, cluster role state, etc. during cluster operation. It needs to be replicated to each node. When disaster occurs, other nodes will refer to the cluster database for failover. Therefore, if important clusters occur, backups should be made for cluster node OS, and the system state will include cluster database.

Cluster database registry location, located under each node HKEY_LOCAL_MACHINE\Cluster unit, where you can see the cluster configuration, the status of each node, and the cluster role configuration

Among them, paxos is marked as the new function of WSFC since 2008. Before 2008, only the "quorum drive" of the cluster will save the latest copy of the cluster database. Each node needs to synchronize with the quorum disk. The cluster database will be copied to each node by the quorum disk. After shutdown and restart, each node must also connect to the quorum disk to download the cluster database synchronously. If the quorum disk fails, the cluster will not start. Therefore, before 2008, The quorum disk became a single point of failure. Since 2008, the cluster has introduced the paxos tag mechanism. Each node itself can save the latest copy of the cluster database. If a node modifies the cluster data, the paxos tag of the node increases. Then each node senses that there is an updated paxos tag and automatically synchronizes with the cluster database content. After the node is down and recovered, it compares its paxos tag with the disk witness paxos tag. If the disk witness is updated, the cluster database syncs with it and goes online if disk witness detects that the cluster node has an updated paxos tag

By default, the Node Cluster service checks the Cluster Database Registry hive every time it starts, ensuring it is complete before it can start the cluster properly. If it is not up to date, it needs to synchronize the Cluster Database with other nodes or disk witnesses. If the Node Cluster service is not started, the Cluster Database hive will not be loaded, except for the Cluster Database Registry hive of each node itself. If the node is the node where the witness disk resides, An additional 0.Cluster hive is also loaded, which is not loaded for non-witness disk owner nodes

In the cluster database registry we can see the configuration information about the cluster, we may need to change them when we encounter some difficult problems, such as some resources can not be deleted in the graphical interface or command line interface, then you can delete them in the registry, but the official does not recommend doing so, the following is the official recommended practice: delete cluster resources standard operation, recommended standard practice, do not easily operate the registry directly

In addition to the registry, we can also find files about the cluster database in another location, C:\Windows\Cluster directory. In fact, CLUSDB is the entity of the cluster database. Every time the cluster service starts, CLUSDB will be loaded into the registry hive. We can only see the contents of the cluster database from the registry hive. As for why we want to design such an architecture, Lao Wang guessed that it may be because it is easier to transfer between nodes when stored in a file format, or backup and restore operations.

Open the cluster witness disk and you will see the disk file for 0.Hive, which will be loaded into the registry hive of the node where the witness disk resides

Let's actually verify the synchronization of the cluster database. First, let's modify the cluster configuration on any node.

Modify the pre-node paxos tag

Modified node paxos tag

Other nodes detect paxos tag updates on other nodes, synchronize cluster database with them, and paxos tag is updated after synchronization

0. Cluster witness disk registry unit is also synchronized Cluster database is up-to-date, paxos tags are updated consistently

Other nodes view the cluster registry to see the latest cluster database configuration since synchronization

0.Cluster Witness Disk Registry Unit can also see the latest cluster database configuration after synchronization

View Cluster Log

This is the analysis after Lao Wang modified the cluster real-time migration network.

GUM (Global Update Manager), detects changes in the cluster configuration of nodes, paxos updates, reminds Node2 to update it, Node2 receives the request and synchronizes with Node1 the latest cluster database

After receiving the GUM signal, the Database Manager component is responsible for database synchronization. Further, we can see that the specific synchronization is those registry keys. It can be seen that each time the cluster database is incremental, only the modified contents are synchronized. After synchronization is completed, ensure that the cluster database is up-to-date and update the node paxos tag.

For cluster database processing, disk witness and file share witness are different. As mentioned above, disk witness also stores a copy of cluster database. Using CLFS component and DM component, ensure that database files in disk witness are up-to-date. File share and cloud witness do not store a copy of cluster database in directory, but only store a log to record which node of cluster currently has the latest paxos tag.

Lao Wang once told you about a time partition scenario. Node 1 and node 2 use file sharing witness or cloud witness. Node 1 goes down, node 2 modifies the cluster configuration content, and then node 2 goes down. Node 1 is powered up and online, and it will be found that it cannot be connected. Why? Because GUM components will find that the current node 1 does not have the latest cluster database, it will prevent this node from being connected. In this case, node 1 can only be started unless forced arbitration. However, node 1 is a golden copy after startup, and node 2 will lose its previously modified content when it is restarted.

If it is a witness disk, it will not. In the same scenario, if node 2 modifies the contents, node 1 is not present, then the modified contents will be synchronized to the witness disk, that is, the contents of the 0.Cluster registry unit. Then when node 1 is online, GUM will detect the comparison and inform node 1 that your cluster database is not current and needs to be synchronized with the witness disk. Before synchronization, nodes cannot obtain membership. Cluster node 1 goes online normally after synchronizing from witness disk to latest cluster database

Therefore, if the cluster changes something frequently, Lao Wang usually recommends using witness disks to avoid the problem of time partitioning.

Cluster databases collaborate with other cluster components:

GUM: GUM is the cluster global update manager, responsible for coordinating the cluster nodes Cluster database content is up-to-date,GUM working mechanism is divided into the following

1. Global periodic updates, done automatically by the cluster, telling each node database manager to replicate the contents of the cluster database every four hours by default

2. Notification updates occur in the following scenarios: nodes are online, nodes are offline, cluster registry changes are modified, once the above changes are detected, the DM component of each node is immediately notified to copy the latest paxos tag database

3. Quorum updates, specific to the disk witness quorum model, when cluster changes cannot be replicated to other nodes, cluster modified configurations are stored as recovery logs on the witness disk, and automatically retrieved from the witness disk when a node recovers

GUM components have been built into cluster components since NT4 Cluster Server. This component has been operating on its own until 2012R2. The working mode cannot be modified. After 2012 R2, changes have taken place. Before 2012R2, GUM principles are that the latest cluster database has been updated. I need to notify all of you so that you can update the cluster database to the latest. All nodes of the cluster need to respond to GUM change notifications. If any node does not respond, Database change processing will be delayed and waiting. Starting from 2012R2, the following three modes are supported. For Hyper-V load, the default is 1. Database change processing can be completed as long as most hosts respond to GUM change notification. You can modify it by command.

（Get-Cluster).DatabaseReadWriteMode = 1

A potential problem when requesting information for nodes in a cluster is that the node must communicate with most nodes in the cluster for acknowledgement before it can send a response to the request. This is fine for requests that are not required, but when requests are frequently placed in clusters, this places a huge communication burden on the cluster and has a performance impact on virtual hosts, so Microsoft changed the default to 0 in 2016.

DM: Database Manager is the database manager responsible for running and maintaining a local copy of the cluster database on each node, including the cluster itself, cluster node membership, resource groups, resource types, and descriptions of specific resources such as disks and IP addresses, and the database manager uses Global Update Manager to replicate changes to other nodes

MM: MemberShip Manager is a node manager responsible for recording the qualifications of each node, replicating the node qualification list on each node to ensure that all nodes are consistent. The node manager receives the heartbeat detection results of each node, and notifies GUM to replicate the cluster database for it if a new member node is detected. If a node is detected to be unavailable, mark the node as unavailable from the node availability list. Next GUM replication will not notify the node marked as unavailable by MM to replicate the cluster database. Note that if the node is only offline, it will not be completely deleted from the cluster node availability list, but will be marked as unavailable. After recovery, GUM will be notified to complete the cluster database replication. If the node is evicted from the cluster, it will be completely deleted from the node list.

RHS&RCM: RHS is the cluster resource host subsystem, responsible for monitoring the operation status of each cluster resource. Once RHS detects that cluster resources are unavailable, it will report the result to RCM resource control manager. RCM will try to restart or failover resources according to the failover policy of resources. Once RCM transfers resources to other nodes, it will trigger node cluster database changes and update paxos flag. GUM will notify each node DM to copy the latest cluster database after receiving the changes.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.