Dlaczego blokowanie serwerów miałoby powodować wyłączenie innych serwerów z sieci?

Mamy kilkadziesiąt serwerów Proxmox (Proxmox działa na Debianie), a mniej więcej raz w miesiącu jeden z nich będzie miał panikę jądra i blokuje się. Najgorsze w tych blokadach jest to, że gdy jest to serwer, który jest na innym przełączniku niż master klastra, wszystkie inne serwery Proxmox na tym przełączniku przestaną odpowiadać, dopóki nie znajdziemy serwera, który faktycznie się zawiesił i uruchomi się ponownie.

Gdy zgłosiliśmy ten problem na forum Proxmox, doradzono nam uaktualnienie do wersji Proxmox 3.1 i pracujemy nad tym od kilku miesięcy. Niestety, jeden z serwerów, które migrowaliśmy do Proxmox 3.1, został zamknięty w piątek z powodu paniki jądra, i znowu wszystkie serwery Proxmox, które były na tym samym przełączniku, były nieosiągalne przez sieć, dopóki nie zdołaliśmy zlokalizować uszkodzonego serwera i zrestartować go.

Cóż, prawie wszystkie serwery Proxmox na przełączniku ... Uważam za interesujące, że serwery Proxmox na tym samym przełączniku, które były jeszcze w wersji Proxmox 1.9, nie uległy zmianie.

Oto zrzut ekranu konsoli uszkodzonego serwera:

wprowadź opis zdjęcia tutaj

Po zablokowaniu serwera pozostałe serwery na tym samym przełączniku, na których działał także Proxmox 3.1, stały się nieosiągalne i wyrzucały następujące informacje:

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-wyjście zablokowanego serwera:

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

pveversion -v wyjście (w skrócie):

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

Dwa pytania:

Jakieś wskazówki, co spowodowałoby panikę jądra (patrz obrazek powyżej)?
Dlaczego inne serwery na tym samym przełączniku i wersji Proxmox byłyby usuwane z sieci do momentu ponownego uruchomienia zablokowanego serwera? (Uwaga: na tym samym przełączniku były inne serwery, na których działała starsza wersja Proxmoxa w wersji 1.9, których to nie dotyczyło. Nie dotyczyło to również innych serwerów Proxmox w tym samym klastrze 3.1, które nie były na tym samym przełączniku.)

Z góry dziękuję za wszelkie porady.

— Curtis
źródło

Czy możesz dać pełny zrzut awaryjny? Zdjęcie powyżej uciąło ciekawe części. Ponadto, czy opublikowałeś zrzut awaryjny na lkml ? Jednak patrząc na to ponownie, jest to dość stare jądro, czy są plany uaktualnienia Debiana do bieżącej stabilnej wersji?

— ckujau

Niestety nie mamy zrzutu awaryjnego. Dodałem go do mojej listy, aby skonfigurować konsolę szeregową i / lub kdump. Jeśli chodzi o stare jądro, Proxmox używa jądra OpenVZ, które jest odgałęzieniem głównego jądra. Więc kiedy będę mógł uruchomić zrzuty awarii, skontaktuję się z deweloperami OpenVZ w celu uzyskania pomocy. Dzięki za komentarz ... pomógł mi wskazać właściwy kierunek.

— Curtis

Jakiego rodzaju przełącznik?

— ETL

Problem wystąpił w przypadku 3 różnych przełączników (jeden dlink i 2 cisco). Nie mam numerów modeli na dwóch poprzednich przełącznikach, ale najnowszy to Cisco SG102-24. Ponieważ wpływa to tylko na serwery na przełączniku, które działają na tym samym jądrze, a ponieważ jestem na moim trzecim przełączniku, wydaje się mało prawdopodobne, aby to on był winny (chociaż to była moja pierwotna myśl).

— Curtis,

Otrzymałem e-mail z powiadomieniem, że ktoś zamieścił tutaj następujący komentarz ... „Mam podobny problem, z wyjątkiem tego, że mogę spowodować awarię kopalni z kilkoma pojemnikami robiącymi twardy rdzeń ...” Niestety, został przerwany i kiedy przyjechałem tutaj autor usunął swój komentarz, więc nie wiem, jaka była reszta. Dodam jednak, że zauważyłem, że problem zdarza się najczęściej, gdy występuje duży ruch sieciowy (na przykład podczas wykonywania kopii zapasowych). Być może ten komentarz brzmiał „hardkorowe transfery sieciowe”?

— Curtis,

Odpowiedzi:

Jestem prawie pewien, że twój problem nie jest spowodowany tylko jednym czynnikiem, ale raczej kombinacją czynników. To, czego te poszczególne czynniki nie są pewne, ale najprawdopodobniej jednym czynnikiem jest interfejs sieciowy lub sterownik, a inny czynnik znajduje się na samym przełączniku. Dlatego jest całkiem prawdopodobne, że problem można odtworzyć tylko w przypadku tej konkretnej marki przełącznika w połączeniu z tą konkretną marką interfejsu sieciowego.

Wydaje się, że przyczyną problemu jest coś, co dzieje się na pojedynczym serwerze, który następnie wywołuje panikę jądra, która ma efekty, które w jakiś sposób potrafią się rozprzestrzenić na przełączniku. Wydaje się to prawdopodobne, ale powiedziałbym, że spust jest gdzieś indziej.

Może się zdarzyć, że coś się dzieje na przełączniku lub interfejsie sieciowym, co jednocześnie powoduje panikę jądra i problemy z łączem na przełączniku. Innymi słowy, nawet jeśli jądro nie miało paniki w jądrze, wyzwalacz mógł równie dobrze obniżyć łączność na przełączniku.

Trzeba zapytać, co może się zdarzyć na pojedynczym serwerze, co może mieć taki wpływ na inne serwery. Nie powinno to być możliwe, więc wyjaśnienie musi zawierać usterkę gdzieś w systemie.

Jeśli było to tylko łącze między zawieszonym serwerem a przełącznikiem, które uległo awarii lub stało się niestabilne, nie powinno to mieć wpływu na stan łącza do innych serwerów. Jeśli tak się stanie, będzie to liczone jako wada przełącznika. Jeśli chodzi o ruch, pozostałe serwery powinny zobaczyć nieco mniejszy ruch, gdy serwer, który uległ awarii, utracił łączność, co nie może wyjaśnić, dlaczego widzą problem, który robią.

To prowadzi mnie do wniosku, że prawdopodobna jest wada projektowa przełącznika.

Jednak problem z łączem nie jest pierwszym wyjaśnieniem, którego należy szukać, próbując wyjaśnić, w jaki sposób problem na jednym serwerze może powodować problemy na innych serwerach w przełączniku. Burza telewizyjna byłaby bardziej oczywistym wyjaśnieniem. Ale czy może istnieć związek między serwerem z paniką jądra a burzą rozgłoszeniową?

Multiemisja i pakiety przeznaczone na nieznane adresy MAC są mniej więcej traktowane tak samo, jak rozgłaszanie, więc burza takich pakietów również się liczy. Czy spanikowany serwer może próbować wysłać zrzut awaryjny przez sieć na adres MAC nie rozpoznany przez przełącznik?

Jeśli to jest wyzwalacz, oznacza to, że coś działa nie tak na innych serwerach. Ponieważ burza pakietów nie powinna powodować tego rodzaju błędów w interfejsie sieciowym. Reset adapter unexpectedlynie brzmi jak burza pakietów (co powinno po prostu spowodować spadek wydajności, ale nie ma błędów jako takich) i nie brzmi jak problem z łączem (który powinien spowodować pojawienie się komunikatów o awarii łączy, ale nie o błędzie widzenie).

Jest więc prawdopodobne, że w sprzęcie lub sterowniku sieci występuje pewna wada, która jest wywoływana przez przełącznik.

Kilka sugestii, które mogą dać dodatkowe wskazówki:

Czy możesz podłączyć jakiś inny sprzęt do przełącznika i zobaczyć, jaki ruch widzisz na przełączniku, gdy pojawia się problem (przewiduję, że albo ucichnie, albo zobaczysz powódź).
Czy byłoby możliwe zastąpienie interfejsu sieciowego na jednym z serwerów inną marką przy użyciu innego sterownika, aby zobaczyć, jak wyniki wypadną inaczej?
Czy można wymienić jeden z przełączników na inną markę? Oczekuję, że wymiana przełącznika zapewni, że problem nie będzie już dotyczył wielu serwerów. Bardziej interesujące jest to, że jeśli powstrzyma to również panikę jądra.

— kasperd
źródło

Dziękuję za miłą odpowiedź. Pod względem 3 sugestii: 1) Jaki sprzęt / oprogramowanie by to zrobił? 2) Szkoda, że nie mogę, ale jest w to zaangażowanych wiele serwerów i nie wiem, gdzie będzie problem. 3) Próbowałem już 3 różnych przełączników (3 różne modele, 2 różne marki). Interesujące jest również to, że dotyczy to tylko serwerów w tej samej wersji Proxmox. Proxmox ma mechanizm synchronizacji klastra, więc podejrzewam, że ma to coś wspólnego. Na szczęście minęło kilka miesięcy, odkąd problem wystąpił teraz.

— Curtis,

Przyglądając się ruchowi na przełączniku, pomyślałem o podłączeniu zwykłego komputera z tcpdump i / lub wireshark. Oczywiście nie chcesz instalować oprogramowania, którego dotyczy problem, na tym komputerze. Ale wygląda na to, że w kodzie instalowanym przez Proxmox musi znajdować się błąd. Jeśli zdarza się tak rzadko, że widzisz go tylko raz w miesiącu i tylko na jednym przełączniku na raz, odnalezienie go może zająć dużo czasu. Zastanowię się trochę i skomentuję, jeśli pojawi się więcej pomysłów.

— kasperd

Brzmi dla mnie jak błąd w sterowniku Ethernet lub sprzęcie / oprogramowaniu sprzętowym, co oznacza czerwoną flagę:

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

Widziałem je wcześniej i może on spowodować wyłączenie serwera w trybie offline. Nie pamiętam dokładnie, czy było na kartach Intel Ethernet, ale wierzę w to. Może to być nawet związane z błędem w samych kartach Ethernet. Pamiętam, że czytałem coś o konkretnych kartach Intel Ethernet, które mają takie problemy. Ale zgubiłem link do artykułu.

Wyobrażam sobie, że wyzwalacz tego zależy częściowo od zastosowanego sterownika (wersji), fakt, że starsza wersja oprogramowania działa dobrze, wydaje się to potwierdzać. Mówisz, że sprzedawca używa własnego niestandardowego jądra, spróbuj zaktualizować moduł sterownika Ethernet, który jest używany dla twojego konkretnego sprzętu Ethernet. Albo jeden od twojego dostawcy, albo jeden z oficjalnego drzewa źródeł jądra.

Spójrz również na związanie sprzętu Ethernet, zwykle serwer miałby dwa porty Ethernet, na pokładzie i / lub dodawał karty. W ten sposób, jeśli jedna karta Ethernet ma ten problem, druga odbierze. Używam słowa „karta”, ale oczywiście odnosi się ono do każdego sprzętu Ethernet.

Również wymiana sprzętu Ethernet może to naprawić. Wymień lub dodaj nowszą (Intel) kartę Ethernet i użyj jej zamiast tego. Są szanse, że jeśli problem dotyczy sprzętu / oprogramowania układowego, nowsza karta ma poprawkę (lub starszą?).

— aseq
źródło

Wszystkie komputery mają podwójne porty Ethernet, jednak ten błąd występuje na wielu serwerach jednocześnie, które znajdują się na tym samym przełączniku w momencie, gdy jeden z komputerów się blokuje. Gdy tylko jeden zablokowany serwer zostanie wyłączony, wszystkie dotknięte nim serwery natychmiast staną się ponownie dostępne. To wydaje się wskazywać, że zablokowany serwer nie jest całkowicie zablokowany, ale w jakiś sposób zalewa reset urządzeń na tym samym przełączniku. Ciekawie byłoby sprawdzić, czy aktualizacja sterownika mogłaby pomóc, ale nie sądzę, aby aktywacja drugiej karty Ethernet mogła pomóc na podstawie dowodów.

— Curtis

Stary wątek, ale nawet w przypadku Intel e1000e NIC Model 82574L i jednej z nowszych wersji ProxMox 5.0-23 / af4267bf problemy z siecią nadal występują. Mogę przywołać mojego laptopa z systemem Windows (wybudzić się ze stanu uśpienia lub po prostu zalogować się) podłączonego do tego samego przełącznika, a serwer ProxMox uruchamia się ponownie za każdym razem. Widziałem też, że sporadycznie restartuje się, gdy nie jest podłączony do przełącznika. I uruchomi się ponownie, kiedy po raz pierwszy podłączę go do przełącznika. Obecny sterownik to 3.3.5.3 i są wersje 3.3.5.10, 3.3.6 i 3.4.0.2, więc prawdopodobnie spróbuję je zbudować i użyć. Mój .02c.

— JGlass