Pourquoi un blocage de serveur ferait-il tomber d'autres serveurs du réseau?

Nous avons quelques dizaines de serveurs Proxmox (Proxmox fonctionne sur Debian), et environ une fois par mois, l'un d'eux panique et se bloque. Le pire de ces verrouillages est que lorsqu'il s'agit d'un serveur qui se trouve sur un commutateur distinct du maître de cluster, tous les autres serveurs Proxmox sur ce commutateur cesseront de répondre jusqu'à ce que nous puissions trouver le serveur qui s'est réellement écrasé et le redémarrer.

Lorsque nous avons signalé ce problème sur le forum Proxmox, il nous a été conseillé de passer à Proxmox 3.1 et nous sommes en train de le faire depuis plusieurs mois. Malheureusement, l'un des serveurs que nous avons migrés vers Proxmox 3.1 s'est bloqué vendredi avec une panique du noyau, et à nouveau tous les serveurs Proxmox qui étaient sur ce même commutateur étaient inaccessibles sur le réseau jusqu'à ce que nous puissions localiser le serveur en panne et le redémarrer.

Eh bien, presque tous les serveurs Proxmox sur le commutateur ... J'ai trouvé intéressant que les serveurs Proxmox sur ce même commutateur qui étaient toujours sur Proxmox version 1.9 n'aient pas été affectés.

Voici une capture d'écran de la console du serveur en panne:

entrez la description de l'image ici

Lorsque le serveur s'est verrouillé, les autres serveurs du même commutateur qui exécutaient également Proxmox 3.1 sont devenus inaccessibles et ont craché ce qui suit:

e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
...etc...

uname -a sortie du serveur verrouillé:

Linux ------ 2.6.32-23-pve #1 SMP Tue Aug 6 07:04:06 CEST 2013 x86_64 GNU/Linux

pveversion -v sortie (en abrégé):

proxmox-ve-2.6.32: 3.1-109 (running kernel: 2.6.32-23-pve)
pve-manager: 3.1-3 (running version: 3.1-3/dc0e9b0e)
pve-kernel-2.6.32-23-pve: 2.6.32-109

Deux questions:

Des indices sur la cause de la panique du noyau (voir l'image ci-dessus)?
Pourquoi d'autres serveurs sur le même commutateur et la même version de Proxmox seraient-ils déconnectés du réseau jusqu'à ce que le serveur verrouillé soit redémarré? (Remarque: il y avait d'autres serveurs sur le même commutateur qui exécutaient l'ancienne version 1.9 de Proxmox qui n'étaient pas affectés. En outre, aucun autre serveur Proxmox dans le même cluster 3.1 n'a été affecté qui n'était pas sur ce même commutateur.)

Merci d'avance pour tout conseil.

— Curtis
source

Pouvez-vous donner le crashdump complet? L'image ci-dessus a coupé les parties intéressantes. Avez-vous également posté le crashdump sur lkml ? Cependant, en y repensant, il s'agit d'un noyau assez ancien, est-il prévu de mettre à niveau Debian vers une version stable actuelle?

— ckujau

Malheureusement, nous n'avons pas de vidage sur incident. Je l'ai ajouté à ma liste pour configurer une console série et / ou kdump. Quant au noyau étant ancien, Proxmox utilise un noyau d'OpenVZ qui est une branche du noyau traditionnel. Donc, une fois que je pourrai faire fonctionner les vidages sur incident, je contacterai les développeurs OpenVZ pour obtenir de l'aide. Merci pour votre commentaire ... cela m'a aidé à être pointé dans la bonne direction.

— Curtis

Quel genre de commutateur?

— ETL

Le problème s'est produit avec 3 commutateurs différents (un dlink et 2 cisco). Je n'ai pas les numéros de modèle sur les deux commutateurs précédents, mais le dernier est un Cisco SG102-24. Puisqu'il n'affecte que les serveurs sur le commutateur qui exécutent le même noyau, et parce que je suis sur mon troisième commutateur, il semble peu probable que le commutateur soit à blâmer (même si c'était ma pensée d'origine aussi).

— Curtis

J'ai reçu une notification par e-mail que quelqu'un a posté le commentaire suivant ici ... "J'ai un problème similaire sauf que je peux faire planter le mien avec quelques conteneurs faisant du noyau dur ..." Malheureusement, il a été coupé là et quand je suis venu ici, l'auteur avait supprimé son commentaire donc je ne sais pas ce que c'était. Mais, j'ajouterai que j'ai noté que le problème semble se produire le plus souvent lorsqu'il y a un trafic réseau important (comme lorsque les sauvegardes sont en cours d'exécution). Peut-être que ce commentaire était "des transferts réseau hardcore"?

— Curtis

Réponses:

Je suis presque certain que votre problème n'est pas causé par un seul facteur, mais plutôt par une combinaison de facteurs. Ces facteurs individuels ne sont pas certains, mais le plus probable est l’interface réseau ou le pilote et un autre facteur se trouve sur le commutateur lui-même. Par conséquent, il est très probable que le problème ne peut être reproduit qu'avec cette marque particulière de commutateur combinée à cette marque particulière d'interface réseau.

Vous semblez que le déclencheur du problème est que quelque chose se passe sur un serveur individuel qui a alors une panique du noyau qui a des effets qui parviennent en quelque sorte à se propager à travers le commutateur. Cela semble probable, mais je dirais qu'il est à peu près aussi probable que le déclencheur soit ailleurs.

Il se peut que quelque chose se passe sur le commutateur ou l'interface réseau, ce qui provoque simultanément la panique du noyau et des problèmes de liaison sur le commutateur. En d'autres termes, même si le noyau n'avait pas eu de panique du noyau, le déclencheur pourrait très bien avoir réduit la connectivité sur le commutateur.

Il faut se demander ce qui pourrait arriver sur le serveur individuel, ce qui pourrait avoir cet effet sur les autres serveurs. Cela ne devrait pas être possible, donc l'explication doit impliquer une faille quelque part dans le système.

Si ce n'était que le lien entre le serveur en panne et le commutateur qui est tombé en panne ou est devenu instable, cela ne devrait pas avoir d'effet sur l'état du lien vers les autres serveurs. Si c'est le cas, cela compterait comme une faille dans le commutateur. Et en termes de trafic, les autres serveurs devraient voir un peu moins de trafic une fois que le serveur en panne a perdu la connectivité, ce qui ne peut pas expliquer pourquoi ils voient le problème qu'ils rencontrent.

Cela m'amène à croire qu'un défaut de conception sur le commutateur est probable.

Cependant, un problème de lien n'est pas la première explication que l'on doit rechercher en essayant d'expliquer comment un problème sur un serveur peut causer des problèmes aux autres serveurs du commutateur. Une tempête de diffusion serait une explication plus évidente. Mais pourrait-il y avoir un lien entre un serveur ayant une panique du noyau et une tempête de diffusion?

La multidiffusion et les paquets destinés à des adresses MAC inconnues sont plus ou moins traités de la même manière que les diffusions, donc une tempête de tels paquets compterait également. Le serveur paniqué peut-il essayer d'envoyer un crashdump sur le réseau à une adresse MAC non reconnue par le commutateur?

Si c'est le déclencheur, alors quelque chose ne va pas sur les autres serveurs. Parce qu'une tempête de paquets ne devrait pas provoquer ce type d'erreur sur l'interface réseau. Reset adapter unexpectedlyne ressemble pas à une tempête de paquets (ce qui devrait simplement entraîner une baisse des performances mais pas d'erreurs en tant que telles), et cela ne ressemble pas à un problème de lien (ce qui aurait dû entraîner des messages sur les liens en baisse, mais pas l'erreur que vous êtes voyant).

Il est donc probable qu'il y ait une faille dans le matériel ou le pilote de l'interface réseau, qui est déclenchée par le commutateur.

Quelques suggestions qui peuvent donner des indices supplémentaires:

Pouvez-vous brancher un autre équipement sur le commutateur et regarder quel trafic vous voyez sur le commutateur lorsque le problème se présente (je prédis qu'il se calme ou que vous voyez une inondation).
Serait-il possible de remplacer l'interface réseau sur l'un des serveurs par une marque différente en utilisant un pilote différent pour voir comment le résultat se déroule différemment?
Est-il possible de remplacer l'un des commutateurs par une autre marque? Je m'attends à ce que le remplacement du commutateur garantisse que le problème n'affecte plus plusieurs serveurs. Ce qui est plus intéressant à savoir, c'est si cela empêche également les paniques du noyau de se produire.

— kasperd
source

Merci pour votre réponse réfléchie. En termes de vos 3 suggestions: 1) Quel type d'équipement / logiciel ferait cela? 2) J'aimerais bien, mais il y a beaucoup de serveurs impliqués et je ne sais pas où le problème va se produire ensuite. 3) J'ai déjà essayé 3 commutateurs différents (3 modèles différents, 2 marques différentes). Il est également intéressant de noter que seuls les serveurs de la même version de Proxmox sont affectés. Proxmox a un mécanisme de synchronisation de cluster, donc je soupçonne que cela a quelque chose à voir avec cela. Heureusement, cela fait quelques mois que le problème est survenu maintenant.

— Curtis

Pour regarder le trafic sur le commutateur, je pensais connecter un PC ordinaire avec tcpdump et / ou wirehark. Évidemment, vous voudriez éviter que les logiciels concernés soient installés sur ce PC. Mais il semble qu'il doit y avoir en fait un bogue dans le code que Proxmox installe dans le noyau. Si cela se produit si rarement, que vous ne le voyez qu'une fois par mois et sur un seul commutateur à la fois, cela peut prendre beaucoup de temps pour le retrouver. J'y réfléchirai un peu et commenterai, si d'autres idées surgissent.

— kasperd

Cela me semble être un bug dans le pilote Ethernet ou le matériel / firmware, ceci étant un drapeau rouge:

e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly

Je les ai déjà vus auparavant et cela peut mettre le serveur hors ligne. Je ne me souviens pas exactement si c'était sur des cartes Ethernet Intel mais je le crois. Cela pourrait même être lié à un bogue dans les cartes Ethernet elles-mêmes. Je me souviens avoir lu quelque chose sur des cartes Ethernet particulières ayant de tels problèmes. Mais j'ai perdu le lien de l'article.

J'imagine que le déclencheur dépend en partie du pilote (version) utilisé, le fait qu'une ancienne version du logiciel fonctionne bien semble le confirmer. Vous dites que le fournisseur utilise son propre noyau personnalisé, essayez de mettre à jour le module de pilote Ethernet utilisé pour votre matériel Ethernet particulier. Soit un de votre fournisseur, soit un de l'arborescence officielle des sources du noyau.

Regardez également dans la liaison de votre matériel Ethernet, normalement un serveur aurait deux ports Ethernet, intégrés et / ou ajouter des cartes. De cette façon, si une carte Ethernet rencontre ce problème, l'autre s'en ira. J'utilise le mot "carte" mais il s'applique bien sûr à tout matériel Ethernet.

Le remplacement du matériel Ethernet peut également le corriger. Remplacez ou ajoutez une nouvelle carte Ethernet (Intel) et utilisez-la à la place. Il y a de fortes chances que si le problème provient du matériel / micrologiciel, une carte plus récente ait un correctif (ou une version plus ancienne?).

— aseq
source

Les machines ont toutes deux ports Ethernet, cependant, cette erreur se produit sur plusieurs serveurs en même temps qui sont sur le même commutateur au moment même où l'une des machines se bloque. Au moment où le serveur verrouillé est redémarré, tous les serveurs affectés redeviennent instantanément accessibles. Cela semble indiquer que le serveur verrouillé n'est pas complètement verrouillé mais inonde en quelque sorte la réinitialisation des machines sur le même commutateur. Il serait intéressant de voir si une mise à jour du pilote pourrait aider, mais je ne pense pas que l'activation de l'autre carte Ethernet puisse aider sur la base des preuves.

— Curtis

Ancien thread, mais même avec le modèle de carte réseau Intel e1000e 82574L et l'une des versions ProxMox les plus récentes de 5.0-23 / af4267bf, les problèmes de réseau persistent. Je peux afficher mon ordinateur portable Windows (sortir du sommeil ou simplement me connecter) connecté au même commutateur et le serveur ProxMox redémarre à chaque fois. Je l'ai également vu redémarrer sporadiquement lorsqu'il n'est pas connecté au commutateur. Et il redémarrera lorsque je le connecterai pour la première fois au commutateur. Le pilote actuel est 3.3.5.3 et il y a un 3.3.5.10, 3.3.6 et 3.4.0.2 donc je vais probablement essayer de les construire et de les utiliser. Mon .02c.

— JGlass