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:
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.
la source
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:
la source
Cela me semble être un bug dans le pilote Ethernet ou le matériel / firmware, ceci étant un drapeau rouge:
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?).
la source