Espace de stockage direct: SMB
Nous avons donc ce cluster à 4 nœuds Storage Space Direct (S2D), fonctionnant pendant plus de 1,5 an sans problème majeur. Le système d'exploitation est Windows Server 2016.
- Pare-feu en panne pour tous les profils
- Aucun antivirus installé, Windows Defender désactivé
- Délégations Active Directory intactes
- Aucun changement dans l'infrastructure réseau n'a été signalé
- RDMA a été désactivé il y a 1 an, car nous avons découvert que le NIC ne le supportait pas entièrement
Il y a deux jours, nous avons remarqué de nombreux messages d'erreur dans le journal des événements du cluster, et les travaux de sauvegarde de tous les Hyper-V VM hébergés sur le cluster ont échoué (via VEEAM).
L'enquête a rapidement montré qu'il y avait de nombreux problèmes avec les connexions SMB.
L'un des 4 hôtes:
- peut cingler d'autres ressources dans le réseau
- ne peut pas connecter de dossiers partagés
- la synchronisation NTP échoue (
net time \\serveréchoue, tout commew32tm /monitor)
De toute évidence, le témoin de partage de fichiers échoue également, et un problème avec les services de domaine doit être signalé ...
Nous avons essayé de redémarrer les nœuds séparément, et après un redémarrage, les connexions SMB sont très bien ... pendant quelques minutes/heures, puis le problème se pose à nouvea .
L'impact sur le cluster, ainsi que le témoin de partage de fichiers étant hors ligne, est que nous ne pouvons pas facilement effectuer une migration en direct des machines virtuelles entre les nœuds (réussit au hasard). Une migration rapide se produit cependant comme un charme. Comme SMB ne sont pas possibles, nous ne pouvons pas déplacer VM vers un autre cluster ou l'hôte autonome).
Nous craignons que le cluster ne se détraque si un nœud tombe en panne de manière incontrôlable. Même si les VM sont stables, nous ne pouvons toujours pas effectuer de sauvegarde (nous pourrions effectuer une exportation).
Avez-vous entendu parler de ce problème avec S2D ou le rôle de cluster de basculement Microsoft? Il peut également être indépendant du cluster lui-même ...
Que peut-on faire pour trouver la cause première de ce problème?
Voici des exemples de journaux trouvés dans le rôle de cluster et dans les journaux d'événements pour SMBCLient:
Depuis la console du cluster:
La ressource de nom de réseau de cluster "Nom de cluster" a rencontré une erreur lors de l'activation du nom de réseau sur ce nœud. La raison de l'échec était: "Impossible d'obtenir un jeton de connexion".
Le code d'erreur était '1311'.
Vous pouvez mettre la ressource de nom de réseau hors ligne et à nouveau en ligne pour réessayer.
Événement avec ID 30803:
Impossible d'établir une connexion réseau.
Erreur: {Device Timeout} L'opération d'E/S spécifiée sur% hs n'a pas été terminée avant l'expiration du délai d'expiration.
Nom du serveur: server.domain.com
Adresse du serveur: x.x.x.x: 445 Type de connexion: Wsk
Conseils: cela indique un problème avec le réseau ou le transport sous-jacent, comme TCP/IP, et non avec SMB. Un pare-feu qui bloque TCP port 445 ou TCP port 5445 lors de l'utilisation d'un adaptateur RDMA iWARP) peut également provoquer ce problème.
n autre, ID 30804:
Une connexion réseau a été déconnectée.
Nom du serveur:\server.domain.com Adresse du serveur: x.x.x.x: 445 Type de connexion: Wsk
Conseils: cela indique que la connexion du client au serveur a été déconnectée.
Des déconnexions fréquentes et inattendues lors de l'utilisation d'un adaptateur RDMA sur Ethernet convergé (RoCE) peuvent indiquer une mauvaise configuration du réseau. RoCE requiert que le contrôle de flux prioritaire (PFC) soit configuré pour chaque hôte, commutateur et routeur sur le réseau RoCE. Le fait de ne pas configurer correctement PFC entraînera une perte de paquets, des déconnexions fréquentes et de mauvaises performances.
J'ai trouvé la solution, c'était une chose stupide. Les hôtes avaient plusieurs NIC pour l'accès réseau à différents VLAN. Certains des NIC étaient mappés à un commutateur virtuel, et certains d'entre eux étaient partagés avec le système d'exploitation) ('Autoriser le système d'exploitation de gestion à partager cette carte résea').
J'ai remarqué que le paquet SMB utilisait souvent la mauvaise interface (DMZ), et bien sûr la demande a été refusée.
La commande Powershell que j'ai utilisée pour identifier la mauvaise route utilisée par le trafic SMB:
Find-NetRoute -RemoteIPAddress x.x.x.x
(où x.x.x.x est une ressource distante sur votre réseau)
Cela a montré l'interface DMZ, au lieu de l'interface LAN. Suppression du 'Autoriser le système d'exploitation de gestion à partager cette carte résea' sur le DMZ vSwitch a résolu le problème pour moi.
Je ne comprends toujours pas comment ce cluster a si bien fonctionné pendant 1,5 an, avec cette configuration. Mais bon, maintenant c'est résolu, le FSW et toutes les autres opérations fonctionnent bien.
J'espère que cela peut vous aider;)