Mam 15 identycznych 64-bitowych serwerów Linux RH 4.7. Prowadzą bazę danych klastrów (klaster jest na poziomie aplikacji). Czasami (co miesiąc) losowe pudełko (choć nie takie samo) zawiesza się.
Mogę pingować pudełko i ping działa. Jeśli spróbuję ssh w polu otrzymuję:
ssh_exchange_identification: Connection closed by remote host
SSH jest poprawnie skonfigurowany.
Kiedy idę do serwerowni i próbuję zalogować się bezpośrednio do konsoli, mogę przełączać konsole za pomocą Alt+ Fn, mogę wprowadzić nazwę użytkownika, a znaki się wyświetlają, ale po naciśnięciu Enternic się nie dzieje. Czekałem 8 godzin i to się nie zmieniło.
Syslog skonfigurowałem tak, aby rejestrował wszystko na zdalnym hoście i w tych dziennikach nie ma nic. Po ponownym uruchomieniu komputera działa bez problemu. Przeprowadziłem testy sprzętu - wszystko jest w porządku i nic nie jest w logach. Maszyny są również monitorowane za pomocą NAGIOS, i nie ma nietypowego obciążenia lub aktywności przed zamrożeniem.
Skończyły mi się pomysły; co jeszcze mogę zrobić lub sprawdzić?
Odpowiedzi:
Wygląda na to, że twoje jądro spanikowało w taki sposób, że sshd nie mógł wysłać kluczy serwera. Być może jądro zostało zaklinowane w taki sposób, że stos sieciowy wciąż był włączony, ale warstwa VFS była niedostępna.
Kiedy wystąpiły podobne problemy w systemie RHEL4, skonfigurowałem usługi netdump i netconsole oraz dedykowany serwer netdump i syslog do przechwytywania zrzutów awaryjnych i informacji o panice jądra. Ustawiłem także kernel.panic sysctl na 10. W ten sposób, gdy system wpadnie w panikę, otrzymasz zarówno ślad jądra, jak i kopię pamięci w tym systemie, którą możesz przeanalizować za pomocą narzędzia „crash”.
Z pewnością skorzystałbyś także na skonfigurowaniu konsoli szeregowej dla hostów, abyś mógł zobaczyć, jak konsola jest gotowa i potencjalnie uderzyć w magiczne klucze systemowe. Ponadto, jeśli chcesz skonfigurować sieć i masz sprzęt, który ją obsługuje, możesz używać IPMI do zdalnego wyłączania, włączania, restartowania i odpytywania sprzętu.
(o ile jest to warte, RHEL5 ma podobną funkcjonalność z kexec / kdump, tylko zrzut awaryjny jest przechowywany lokalnie)
źródło
Postawię dolary na pączki, że zabraknie ci pamięci. System się zatrzymuje, gdy próbuje dowiedzieć się, skąd go wziąć. Może się to dziać tak szybko, że monitorowanie go nie wykrywa. Zintensyfikowałbym monitorowanie, w tym zdalne rejestrowanie zużycia pamięci. Sprawdź także w dziennikach komunikaty OOM.
(Możesz nawet chcieć mieć otwarte okna ssh z uruchomioną górą.)
źródło
Dla mnie brzmi to tak, jakby w systemie zabrakło zasobów, więc proces potrzebny po stronie serwera ssh nie może zostać przydzielony.
Rzeczywiste wąskie gardło może się różnić - poza procesami lub brakiem pamięci - a jedynym sposobem, aby się upewnić, jest spojrzenie na dzienniki i konsolę, aby sprawdzić, czy coś tam jest. Możesz skonfigurować scenariusz wstępnie uruchomionych zadań ssh - po jednym na każdą maszynę - po prostu przygotować się następnym razem.
Jeśli jest naprawdę źle, możesz rozważyć uruchomienie kolejnej powłoki z większą liczbą wbudowanych poleceń, abyś mógł zbadać więcej bez konieczności uruchamiania dodatkowego procesu, ponieważ może to nie być możliwe. Również „tail -f / var / log / *” może być bardzo przydatne.
Powodzenia.
źródło
Jedyny raz, kiedy widziałem coś podobnego, to użycie przełącznika KVM i skrótu klawiaturowego (np. Alt + n) do przełączania między serwerami. Nie zdarzało się to za każdym razem i dotyczyło to wyłączenia serwera, więc nie było to natychmiast zauważalne. Nie nastąpiłyby żadne blokady, gdyby do przełączania między serwerami używany był fizyczny przycisk na samym przełączniku KVM. Jeśli klawisz skrótu był często używany, czasami serwer nie pozwalał na nowe logowanie. Istniejące sesje SSH pozostały niezmienione.
źródło