Website under construction

Figure 2-35:
Choosing replica VHDs 
Improved cluster logs 
Getting as much critical data as possible in a timely fashion can help to quickly resolve failover 
clustering problems. Getting the right data at the right time can be critical for restoring services. With 
all the Service-Level Agreements (SLAs) available, the right diagnostics is crucial to many businesses. 
From a diagnostic standpoint, the first improvement in Windows Server 2016 is with the cluster 
diagnostics log. The cluster log has always been useful for identifying an error, what led to an error, 
what was happening at the time of the error, and so on. But using the cluster log to determine things 
such as the configuration of the cluster is a more involved process. 

---

36 
CHAPTER 2 | Software-defined datacenter 
For example, if you want to know the resources in the cluster, as long as the cluster log shows the 
cluster service starting, the required information is there, but finding it requires searching through 
many lines to piece it all together, as demonstrated in the following example: 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Getting just this little bit of information entails going through 1,000 or more lines in the logs; a time-
consuming task, to be certain. Looking up other specific information about the configuration can take 
you back through these same sets of entries, plus more. 
You can get this type of information from other logs or the registry, but that requires reviewing 
information from multiple files. If you are not at the machine and someone else gathers logs for you, 
that person might not include all of the logs. This can delay things further as you wait to get the 
proper information. 
This complexity was an important consideration for Windows Server 2016 as it relates to failover 
clustering. Because of this, the cluster diagnostics log has been redesigned. When you generate a 
cluster log in Windows Server 2016, it includes additional information that you can access quickly, 
broken down into various sections, as illustrated here: 
[=== Cluster ===] 
This section gives information about the version, time running, node name the log came from, etc 
[=== Resources ===] 
List of all resources (including the GUID) and the configurations/parameters of those resources 
[=== Groups ===] 
List of all groups (including the GUID) and the configurations/parameters of those groups, owner node, etc 
[=== Resource Types ===] 
List of all resource types (including the GUID) and the configurations/parameters of those resource types 
[=== Nodes ===] 
This section gives information about the nodes including the version, time running, node id, etc 
[=== Networks ===] 
This section gives information about the networks including the role, the network scheme, metric, if RSS 
capable, etc 
[=== Network Interfaces ===] 
This section gives information about the networks including the name, IP Address information, etc 
[=== System ===] 
All System Event Log entries with Failover Clustering as the source 
[=== Microsoft-Windows-FailoverClustering/Operational logs ===] 
All events from the Microsoft-Windows-FailoverClustering/Operational channel that gives you information about 
the forms of a cluster, node joins, group moves, etc 
[=== Microsoft-Windows-ClusterAwareUpdating-Management/Admin logs ===] 
All events from the Microsoft-Windows-ClusterAwareUpdating-Management/Admin channel that gives you 
information about Cluster Aware Updating 

---

37 
CHAPTER 2 | Software-defined datacenter 
[=== Microsoft-Windows-ClusterAwareUpdating/Admin logs ===] 
All events from the Microsoft-Windows-ClusterAwareUpdating/Admin channel that gives you information about 
Cluster Aware Updating 
[=== Microsoft-Windows-FailoverClustering/DiagnosticVerbose ===] 
This is actually a new event channel that gives you the similar output as Debug Level 5 for a Cluster Log 
without having to set it. You can use this information to get deeper into the calls and goings on with the 
cluster and gives it in a more verbose output. 
[=== Cluster Logs ===] 
This is the output that you normally see in a cluster log. 
Clearly, there is a lot to this log now. Using this one log can reduce the time you spend looking for 
information or trying to resolve an issue. Instead of having to review three or more files that might be 
loaded in three different applications with their own formats, you now need only review one file. 
The other useful thing about the log is that if you generate it with no switches, everything in an event 
channel (for example, the System Event) is shown. So you can actually get any history pertaining to a 
particular problem. For cases in which you can reproduce an error condition and do not need all of 
the history, you can generate a log for the last five minutes (
TimeSpan=5
). Helpfully, the new cluster log 
uses this same five-minute time span for all of the event channels and gives you only those, so you 
don’t need to deal with an unnecessarily large file.