Sv translation | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CautionThis is an advanced topic. Use at your own risk and ALWAYS backup your data before. Useful CommandsView DRBD Status - DRBD 7
View DRBD Status - DRBD 9
Reload all parameters
Disconnect the share (useful for planned maintenance)
Down the share (useful for planned maintenance)
Up the share
Set the node to primary
Connect the share
PCS Cluster Commands (CentOS 8)
Split BrainBackgroundSee also: https://docs.linbit.com/doc/users-guide-84/s-resolve-split-brain/ Symptoms - CentOS 7 and earlier
cs:StandAlone means the node is not connected. This should be visible on both sides. Symptoms - CentOS 8 and earlier
The first command shows that DRBD is active on the first node, but not active on the second node. Note: this can be due to the second node being stopped or in standby. Find out which node is active in the PCS cluster - CentOS 7
In the example above, the first node is in standby. The most important thing to check, is on which server the resources are started. In this case, the resources are started on acd-store2. This will therefore be defined as the NON BROKEN node. Find out which node is active in the PCS cluster - CentOS 8
In the example above, the second node is offline. The most important thing to check, is on which server the resources are started. In this case, the resources are started on acd-lb1. This will therefore be defined as the NON BROKEN node. Standby the broken node in the PCS cluster (if necessary)This command can be run on either machine. CentOS 7
CentOS 8
On broken nodeNote: the first command will probably throw an error. Also, the share may not be mounted. This is OK.
On the healthy node
Check re-sync activityThe re-sync might take a long time. Watch the status of this using: cat /proc/drbd Example output:
Tune the transfer (Second Node) - Only CentOS 7.xCurrently there is no procedure for tuning the transfer on CentOS 8.x If the transfer is going to take ages, then tune it on the broken node:
Put broken node back to primary - CentOS 7.x ONLY
Restart PCS node
|
...
Untune the transfer (Second Node) - CentOS 7x onlyIf the transfer was tuned, then untune it (on the broken node). Note: it won't hurt to run this command anyway.
Check everything
File System Corrupt |
Check everything
Sometimes, when DRBD fails, the file system will also become corrupt. In this case both nodes might be primary, however neither will have the share mounted. The command mount /srv/jtel/shared will fail. In this case, it may be necessary to repair the file system. Symptoms
RepairingOne one of the nodes (need to choose one to become primary):
This should then mount and start the resources on that node. Then proceed with the other node as "broken" in the split brain situation. Stalled ResyncIf the DRBD resync stalls - the output will be "stalled" when cat /proc/drbd is executed - then it may be necessary to restart the machine. This has been observed once, and restarting resolved the situation. However not much more is known about this state, or the cause, at this time. Failed Connect (Unrelated data, aborting)When the secondary has been told to discard it's data, and all of the commands to start the sync have been entered on both the healthy and the broken node, sometimes cat /proc/drbd will not report a connection. Check /var/log/messages If you can see output like this:
Then the metadata has become corrupt. This requires that the metadata be completely reconstructed on the bad node. Use the following commands to recreate the data on the broken node:
Then proceed with the re-sync as above (start with the part "On the broken node" with the commands to place this in secondary and discard data. Failed Connect (Unknown Connection)This produces errors something like this:
In this case, drbd might not be loaded and enabled. Execute the following code on the broken node and then proceed as above:
|
Sv translation | ||||||
---|---|---|---|---|---|---|
| ||||||
|
Sv translation | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
AttentionC'est un sujet avancé. Utilisez-le à vos propres risques et TOUJOURS sauvegardez vos données avant. Commandes utilesVoir le statut de DRBD - DRBD 7
Voir le statut de DRBD - DRBD 9
Recharger tous les paramètres
Déconnecter l'action (utile pour la maintenance planifiée)
Réduction de l'action (utile pour la maintenance planifiée)
Augmenter la part
Régler le nœud sur le primaire
Connectez le partage
Commandes des clusters PCS (CentOS 8)
Cerveau fenduContexteVoir ici: https://docs.linbit.com/doc/users-guide-84/s-resolve-split-brain/ Symptômes - CentOS 7 et antérieurs
cs:StandAlone signifie que le nœud n'est pas connecté. Cela devrait être visible des deux côtés. Symptômes - CentOS 8 et antérieurs
La première commande montre que la DRBD est active sur le premier nœud, mais pas sur le second. Remarque : cela peut être dû au fait que le deuxième nœud est arrêté ou en attente. Découvrez quel nœud est actif dans le cluster PCS - CentOS 7
Dans l'exemple ci-dessus, le premier nœud est en veille. La chose la plus importante à vérifier est de savoir sur quel serveur les ressources sont lancées. Dans ce cas, les ressources sont mises en place sur acd-store2. Il sera donc défini comme le nœud NON brisé . Découvrez quel nœud est actif dans le cluster PCS - CentOS 8
Dans l'exemple ci-dessus, le deuxième nœud est hors ligne. La chose la plus importante à vérifier est de savoir sur quel serveur les ressources sont lancées. Dans ce cas, les ressources sont démarrées sur acd-lb1. Il sera donc défini comme le nœud NON brisé . Mettez en veille le nœud rompu dans le cluster PCS (si nécessaire)Cette commande peut être exécutée sur n'importe quelle machine. CentOS 7
CentOS 8
Sur un nœud briséNote : la première commande lancera probablement une erreur. De plus, il se peut que l'action ne soit pas montée. Cela ne pose pas de problème.
Sur le nœud sain
Vérifier l'activité de re-syncLa re-synchronisation pourrait prendre beaucoup de temps. Surveillez l'état de cette utilisation : cat /proc/drbd Exemple de sortie :
Régler le transfert (deuxième nœud) - uniquement CentOS 7.xActuellement, il n'existe pas de procédure pour régler le transfert sur CentOS 8.x Si le transfert doit prendre du temps, il faut alors le régler sur le nœud rompu :
Remettre le nœud rompu en position primaire - CentOS 7.x ONLY
Redémarrer le nœud PCS
Désactiver le transfert (deuxième nœud) - CentOS 7x seulementSi le transfert a été accordé, il faut le désaccorder (sur le nœud rompu). Note : de toute façon, cela ne fera pas de mal d'exécuter cette commande.
Tout vérifier
Système de fichiers corrompuParfois, lorsque le DRBD échoue, le système de fichiers devient également corrompu. Dans ce cas, les deux nœuds peuvent être primaires, mais la part ne sera pas montée non plus. La commande mount /srv/jtel/shared échouera. Dans ce cas, il peut être nécessaire de réparer le système de fichiers. Symptômes
RéparationUn des nœuds (il faut en choisir un pour devenir primaire) :
Celui-ci devrait ensuite monter et démarrer les ressources sur ce nœud. Ensuite, continuez avec l'autre nœud comme " brisé" dans la situation du cerveau divisé. Resync bloquéeSi la resynchronisation du DRBD est bloquée - la sortie sera "bloquée" lorsque cat /proc/drbd est exécuté - alors il peut être nécessaire de redémarrer la machine. Cela a été observé une fois, et le redémarrage a résolu la situation. Cependant, on n'en sait pas beaucoup plus sur cet état, ni sur sa cause, à l'heure actuelle. Échec de la connexion (données non pertinentes, abandon)Lorsqu'il a été demandé au secondaire de rejeter ses données, et que toutes les commandes pour lancer la synchronisation ont été entrées sur le nœud sain et le nœud cassé, il arrive que cat /proc/drbd ne signale pas de connexion. Vérifier /var/log/messages Si vous voyez une sortie comme celle-ci :
Alors les métadonnées sont devenues corrompues. Cela exige que les métadonnées soient complètement reconstruites sur le mauvais nœud. Utilisez les commandes suivantes pour recréer les données sur le nœud cassé :
Ensuite, procédez à la re-synchronisation comme ci-dessus (commencez par la partie "Sur le noeud cassé" avec les commandes pour placer celui-ci en secondaire et supprimer les données. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Code Block | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
pcs resource show cat /proc/drbd |