Serveur d'impression

Améliorations apportées au dépannage du cluster de basculement Windows Server 2016 – Journal du cluster – Communauté Microsoft Tech – Serveur d’impression

Par Titanfall , le 17 novembre 2019 - 10 minutes de lecture

Publié pour la première fois sur MSDN le 14 mai 2015

Améliorations apportées au journal du cluster

Il s'agit du premier d'une série de blogs qui fournit des détails sur les améliorations apportées aux outils et méthodes de dépannage des clusters de basculement avec Windows Server 2016.

Le cluster de basculement dispose de journaux de diagnostic qui s'exécutent sur chaque serveur et permettent un dépannage approfondi des problèmes sans avoir à reproduire le problème. Ce journal est précieux pour le support technique de Microsoft ainsi que pour ceux qui possèdent une expertise en matière de dépannage des clusters de basculement.

Pointe:

Toujours consulter d'abord le journal des événements système lors du dépannage d'un problème. Le cluster de basculement publie dans le journal des événements système des événements suffisamment nombreux pour permettre de comprendre la nature et l'étendue du problème. Il vous donne également la date et l'heure spécifiques du problème, ce qui est utile si vous consultez d'autres journaux d'événements ou si vous fouillez le fichier cluster.log si nécessaire.

Génération du cluster.log

Ce n’est pas une nouveauté, mais des informations utiles pour ceux qui ne sont pas familiarisés avec la génération du journal du cluster.

Get-ClusterLog

est la cmdlet Windows PowerShell qui générera le fichier cluster.log sur chaque serveur membre du cluster et en cours d'exécution. La sortie ressemble à ceci sur un cluster à 3 nœuds:

Les fichiers Cluster.log peuvent être trouvés dans le

cluster reports

répertoire (généralement c: windows cluster reports) sur chaque nœud.

Vous pouvez utiliser le

-Destination

paramètre permettant de copier les fichiers dans un répertoire spécifié avec le nom du serveur ajouté au nom du journal, ce qui facilite beaucoup l'obtention et l'analyse des journaux de plusieurs serveurs:

D'autres paramètres utiles sont discutés dans le reste de ce blog.

Quoi de neuf

Je vais mettre en évidence les améliorations apportées aux informations du cluster.log de Windows Server 2016 qui seront les plus intéressantes et utiles pour le grand public intéressé par le dépannage des clusters de basculement, et laisserons en détail chaque élément du journal à un autre blog ( s). J'inclus des références et des liens vers des ressources relatives au dépannage des grappes et à l'utilisation du journal des grappes à la fin de ce blog.

Informations sur le fuseau horaire

Cluster.log est un vidage des informations du système et capturé dans un fichier texte. L'heure par défaut est UTC (certaines personnes appellent GMT). Par conséquent, si vous vous trouvez dans un fuseau horaire au format UTC + 8, vous devez consulter l'horodatage dans le journal du cluster et ajouter 8 heures. Par exemple, si vous vous trouvez dans ce fuseau horaire et qu'un problème survient à 13 h 38 (13 h 38), l'horodatage UTC dans le journal du cluster est 21 h 38.

Nous proposons 2 améliorations dans le fichier cluster.log pour rendre ce fuseau horaire et ce décalage UTC plus faciles à découvrir et à utiliser:

  1. Offset UTC du serveur:

    Le haut du fichier cluster.log note l'offset UTC du serveur d'origine. Dans l'exemple ci-dessous, il est noté que le serveur est défini sur UTC + un décalage de 7 heures (420 minutes). Le fait de noter spécifiquement ce décalage dans le journal élimine les incertitudes liées au réglage du fuseau horaire du système.

  2. Le journal du cluster utilise l'heure UTC ou locale

    . La partie supérieure du fichier cluster.log indique si le journal a été créé à l'aide de l'heure UTC ou de l'heure locale pour l'horodatage. le

    –UseLocalTime

    paramètre pour

    Get-ClusterLog

    permet à cluster.log d'écrire des horodatages déjà ajustés pour le fuseau horaire du serveur au lieu d'utiliser l'heure UTC. Ce n’est pas nouveau, mais il est devenu évident qu’il est utile de savoir si ce paramètre a été utilisé ou non, c’est donc noté dans le journal.

[===Cluster ===]

UTC = heure locale + décalage du fuseau horaire; à l'heure avancée, le décalage horaire de cette machine est de 420 minutes ou 7 heures

Les journaux ont été générés en utilisant le temps universel coordonné (UTC). 'Get-ClusterLog -UseLocalTime' sera généré dans l'heure locale.

Pointe:

Les sections du cluster.log sont encapsulées dans [===   ===], ce qui facilite la consultation du journal vers chaque section en effectuant une recherche sur «[=== ”. Comme format, ce format a été choisi parce qu’il ressemble à un Tie Fighter et nous avons pensé que c’était cool.

Objets de cluster

Le cluster a des objets qui font partie de sa configuration. Obtenir les détails de ces objets peut être utile pour diagnostiquer des problèmes. Ces objets incluent des ressources, des groupes, des types de ressources, des nœuds, des réseaux, des interfaces réseau et des volumes. Le cluster.log vide maintenant ces objets dans une liste de valeurs séparées par des virgules avec des en-têtes.

Voici un exemple:

[===Networks ===]

Nom, ID, description, rôle, transport, ignorer, AssociatedInterfaces, PrefixList, adresse, addressMask, ipV6Address, state, linkSpeed, rdmaCapable, rssCapable, autoMetric, métrique,

Il y a encore des bûches dans le réseau de grappes suivantes 10.10.1.0/24, 10.10.1.0, 255.255.255.0, 3,1000000000, false, false, true, 39984,

Cluster réseau 2 10.10.3.0/24, 10.10.3.0, 255.255.255.0, 3,1000000000, false, false, true, 39985,

Cluster réseau 3,1a5029c7-7961-40bbb6b9-dc434834, 3, TCP / IP, faux, d3cdef35-4cb4c8-4b8-4b5b8-4b8-4b5-4b8-4b5-4b8-4b8-4b8-4b8-4b8-480-7-7-7-7-7-7-7-7-7-7-7-7-7-7-7-7-7-7-7-8-8-8-7-8-7-8-7-8-7-8-7-8-7-8-7-8-7-8-8-8-7-8-8-8-7-7-8-8-8-7-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8-8- bb- 157.59.132.0/22 ​​2001: 4898: 28: 4 :: / 64,157.59.132.0,255.255.252.0,2001: 4898: 28: 4 ::, 3,100000000, false, false, true, 80000,

Ces sections peuvent être utilisées par toute application capable d'analyser du texte CSV. Ou bien, vous pouvez copier / coller dans une feuille de calcul Excel, ce qui facilite la lecture et fournit un filtre / tri / recherche. Pour l’exemple ci-dessous, j’ai collé la section ci-dessus dans une feuille de calcul, puis j’ai utilisé l’action «Texte en colonnes» de l’onglet «DONNÉES» d’Excel de Microsoft.


Nouveau journal détaillé

Nouveau pour Windows Server 2016: le canal d'événements DiagnosticVerbose. Il s'agit d'un nouveau canal qui s'ajoute au canal de diagnostic pour FailoverClustering.

Dans la plupart des cas, le canal de diagnostic, avec le niveau de journalisation par défaut défini sur 3, obtient suffisamment d'informations pour qu'un dépanneur expert ou les ingénieurs du support technique de Microsoft puissent comprendre un problème. Cependant, dans certains cas, nous avons besoin d’une journalisation plus détaillée et il est nécessaire de définir le niveau de journalisation du cluster sur 5, ce qui permet au canal de diagnostic d’ajouter le niveau de consignation des événements au journal. Après avoir modifié le niveau de journalisation, vous devez reproduire le problème et analyser à nouveau les journaux.

La question se pose, pourquoi ne pas suggérer de garder le niveau de log à 5? La réponse est que cela provoque plus d'événements dans les journaux et donc un bouclage plus rapide. Il est également souhaitable de pouvoir consulter les journaux pendant des heures ou des jours, de sorte que le wrapping rapide pose son propre problème de dépannage.

Afin de répondre aux exigences de consignation détaillée pour la dernière période et d'avoir une consignation adéquate de l'historique, nous avons mis en place un canal de diagnostic parallèle appelé DiagnoticVerbose. Le journal DiagnosticVerbose est toujours défini pour l'équivalent du niveau de journal du cluster 5 (détaillé) et s'exécute en parallèle sur le canal Diagnostic pour FailoverClustering.

Vous pouvez trouver la section DiagnosticVerbose dans le fichier cluster.log en effectuant une recherche sur «DiagnosticeVerbose». Il ira l'en-tête de section:

[=== Microsoft-Windows-FailoverClustering/DiagnosticVerbose ===]

[Verbose] 00000244.00001644 :: 2015/04 / 22-01: 04: 29.623 DBG

[RCM] rcm :: PreemptionTracker :: GetPreemptedGroups ()

[Verbose] 00000244.00001644 :: 2015/04 / 22-01: 04: 29.623 DBG

[RCM] a été demandé pour les groupes préemptés, retournant 0 enregistrements

Le canal de diagnostic (niveau de journal par défaut de 3) peut être trouvé en effectuant une recherche dans «Journaux de cluster»:

[=== Cluster Logs ===]

00000e68.00000cfc :: 2015/03 / 23-22: 12: 24.682 DBG [NETFTAPI] reçu NsiInitialNotification

00000e68.00000cfc :: 2015/03 / 23-22: 12: 24.684 DBG [NETFTAPI] reçu NsiInitialNotification

Événements d'autres canaux

Il y a un «conseil» ci-dessus qui note la recommandation de commencer par le journal des événements système. Cependant, il n’est pas rare qu’une personne génère les journaux du cluster et les envoie à son serveur interne.

rd

support de niveau ou à d'autres experts. Le fait de revenir en arrière et d'obtenir le système ou d'autres journaux d'événements pouvant être utiles pour diagnostiquer le problème peut prendre du temps, et parfois les journaux sont déjà bouclés ou effacés.

Nouveauté du journal de cluster de Windows Server 2016, les canaux d'événements suivants seront également vidés dans le fichier cluster.log pour chaque nœud. Comme ils sont tous dans un fichier, vous n'avez plus besoin d'aller aux nœuds et d'extraire chaque journal individuellement.

[=== System ===]

[=== Microsoft-Windows-FailoverClustering/Operational logs ===]

[=== Microsoft-Windows-ClusterAwareUpdating-Management/Admin logs ===]

[=== Microsoft-Windows-ClusterAwareUpdating/Admin logs ===]

Voici un exemple:

[=== System ===]

[System]

00000244.00001b3c :: 2015/03 / 24-19: 46: 34.671 ERR

Machine virtuelle de la ressource de cluster 'de type' virtuel

Machine 'en cluster'' échoué.

En fonction des stratégies d'échec pour la ressource et le rôle, le service de cluster peut essayer de mettre la ressource en ligne sur ce nœud ou de déplacer le groupe sur un autre nœud du cluster, puis de le redémarrer. Vérifiez la ressource et l'état du groupe à l'aide du gestionnaire de cluster de basculement ou de la cmdlet Windows PowerShell Get-ClusterResource.

[System] 00000244.000016dc :: 2015/04 / 14-23: 43: 09.458 INFO Le service de cluster a changé le mot de passe du compte 'CLIUSR' sur le noeud '.'.

Pointe:

Si la taille du fichier cluster.log est supérieure à celle souhaitée, le commutateur –TimeSpan pour Get-ClusterLog limitera la distance (en minutes) à laquelle il retournera pour les événements. Par exemple, Get-Clusterlog –TimeSpan 10 entraînera la création du fichier cluster.log sur chaque nœud et inclura uniquement les événements des 10 dernières minutes. Cela inclut les canaux Diagnostic, DiagnosticVerbose et autres inclus dans le rapport.

Cluster.log Références:

Dépannage des clusters de basculement Windows Server 2012, comment accéder à la racine du problème:

http: //windowsitpro.com/windows-server-2012/troubleshooting-windows-server-2012-failover-cluster …

Get-ClusterLog:

https://technet.microsoft.com/en-us/library/hh847315.aspx

Set-ClusterLog:

https://technet.microsoft.com/en-us/library/ee461043.aspx

Click to rate this post!
[Total: 0 Average: 0]

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.