Jak często powinienem restartować serwery Linux?


30

Mam wiele serwerów Linux (SUSE 9 i 10) używanych do uruchamiania usług internetowych dostarczających dane do dużych siatek obliczeniowych. Ostatnio mieliśmy kilka trudnych do wyjaśnienia przestojów (tj. Dzienniki sprzętu i oprogramowania nie pokazują żadnych oczywistych błędów) i zaczynamy zastanawiać się, czy problemem jest długi czas bezawaryjnej pracy (zwykle 200-300 dni). Biorąc pod uwagę, że serwery te są intensywnie wykorzystywane, czy powinienem rozważyć regularny cykl ponownego uruchamiania?

Odpowiedzi:


47

Musisz ponownie uruchomić komputer po aktualizacji jądra (chyba że używasz KSplice), wszystko inne jest opcjonalne. Osobiście uruchamiam ponownie w cyklu miesięcznym w oknie konserwacji, aby upewnić się, że serwer i wszystkie usługi powrócą zgodnie z oczekiwaniami. W ten sposób mogę być całkiem pewny, jeśli będę musiał dokonać restartu poza harmonogramem (tj. Krytyczna aktualizacja jądra), że system wróci poprawnie. Zautomatyzowane monitorowanie serwerów i usług (np. Nagios) również pomaga w tym procesie (uruchom ponownie, obserwuj, jak kontrolki zapalają się na czerwono, a następnie, mam nadzieję, z powrotem na zielono).

PS, jeśli regularnie uruchamiasz ponownie, upewnij się, że dostroiłeś swoje kontrole fsck (tj. Maksymalna liczba montowań między kontrolami odpowiednio, w przeciwnym razie szybki 2-minutowy restart może potrwać 30 minut, jeśli serwer rozpocznie fsck'owanie kilku terabajtów danych. Zazwyczaj ustawiam liczbę montowań na 0 (tune2fs-c 0) i odstęp między sprawdzeniami na około 6 miesięcy, a następnie ręcznie wymuszam fsck co jakiś czas i resetuję licznik.


1
Regularne testowanie DRBCP jest koniecznością, a ten rodzaj kontroli jest świetnym początkiem w tym kierunku.
Scott Pack

Nie musisz restartować się po aktualizacji jądra - ksplice.com
raspi

1
KSplice jest poprawny, dzięki KSplice możesz na żywo instalować oprogramowanie do łatania (jądro, baza danych itp.). Jednak odkąd Oracle kupiło KSplice, prawdopodobnie nie jest to rozwiązanie dla każdego, kto nie korzysta z rzeczy Oracle (który niedawno kupił KSplice).
Kurt,

11

Naprawdę restartuję swoje serwery dość regularnie, za każdym razem, gdy dokonane zostaną poważne zmiany w konfiguracji. Ważne jest, aby wiedzieć, że w przypadku awarii oprogramowanie serwera pojawi się bezproblemowo. Ostatnią rzeczą, jakiej chcesz, to być w sytuacji, w której próbujesz odzyskać po awarii, ale musisz zepsuć konfigurację serwera, ponieważ nie dokładnie go przetestowałeś podczas konfiguracji.


6

Serwery Linux nigdy nie muszą być restartowane, chyba że absolutnie musisz zmienić działającą wersję jądra. Większość problemów można rozwiązać, zmieniając plik konfiguracyjny i ponownie uruchamiając usługę za pomocą skryptu inicjującego.

Musisz uważać na ponowne uruchomienie ... jeśli zmieniłeś cokolwiek „w locie” bez odzwierciedlenia zmian w pliku konfiguracyjnym usługi, zmiany te nie zostaną zastosowane po ponownym uruchomieniu.

Zwykle jednak restartuję po zaplanowanych aktualizacjach systemu. Zasadniczo nie jest to konieczne, ale robię je, gdy nikogo nie ma w biurze, więc dlaczego nie? W każdym razie często pojawiają się aktualizacje jądra, kiedy mogę je zaktualizować.


Oczywiście od czasu do czasu muszą się restartować. Gdy aktualizujesz oprogramowanie i aktualnie działa ono, nadal będziesz używać starej wersji oprogramowania, ponieważ kopia starej wersji jest nadal aktywna w pamięci RAM. Musisz ponownie uruchomić to oprogramowanie (przez ponowne uruchomienie usługi lub ponowne uruchomienie), aby aktualizacja miała wpływ. Niektóre aplikacje wymagają ponownego uruchomienia i nie można ich zaktualizować przez ponowne uruchomienie usługi
BlueWizard

1
@JonasDralle, usługi powinny zostać automatycznie zatrzymane i uruchomione ponownie po aktualizacji. W przeciwnym razie jest to błąd we wdrażaniu tej usługi!
Alexis Wilke

4

Naprawdę nie wymagane, obsługa pamięci linux jest doskonała. Ale jeśli masz przestoje o takiej długości, prawdopodobnie używasz jąder, które mają znane luki - możesz to obejrzeć.


3
Linux może sobie poradzić z pamięcią, ale poszczególne aplikacje mogą nie - ich stosy mogą ulec fragmentacji, jeśli będą działać przez długi czas. Oczywiście rzeczy takie jak prefork Apache (który przetwarza swoje procesy) na ogół nie cierpią z tego powodu. Inne rzeczy, które wykorzystują jeden bardzo długotrwały proces (np. Mysql) mogą. Zależy od twojej aplikacji.
MarkR

4

Myślę, że powinieneś zrestartować się, jeśli pojawiła się ostatnia aktualizacja jądra LUB aktualizacja libc. Wiele rzeczy jest powiązanych z libc i naprawdę nie jest możliwe całkowite rozładowanie tej biblioteki z pamięci i zastąpienie jej nową wersją, chyba że uruchomisz ponownie komputer.

Na przykład nawet podstawowe rzeczy, takie jak / bin / ls i inne rzeczy w / bin używają libc. Jeśli tylko uruchamiasz konsolę i używasz bash, używasz libc.

$ ldd /bin/bash
        linux-gate.so.1 =>  (0xffffe000)
        libtermcap.so.2 => /lib/libtermcap.so.2 (0xb8029000)
        libdl.so.2 => /lib/libdl.so.2 (0xb8025000)
        libc.so.6 => /lib/libc.so.6 (0xb7ed9000)
        /lib/ld-linux.so.2 (0xb804b000)

$ ldd /bin/ls
        linux-gate.so.1 =>  (0xffffe000)
        librt.so.1 => /lib/librt.so.1 (0xb7f3a000)
        libacl.so.1 => /lib/libacl.so.1 (0xb7f33000)
        libc.so.6 => /lib/libc.so.6 (0xb7de7000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7dd0000)
        /lib/ld-linux.so.2 (0xb7f61000)
        libattr.so.1 => /lib/libattr.so.1 (0xb7dcc000)

I tak, jeśli zmienisz pliki w /etc/init.d, które w jakiś sposób wpływają na uruchamianie, zaleciłbym ponowne uruchomienie. Nie chcesz dowiedzieć się, że popełniłeś niewielki błąd w pliku startowym, gdy potrzebujesz szybko przywrócić działanie.

Jeśli serwer minął wiele dni bez restartu, oznacza to, że nie ma sposobu, aby upewnić się, że uruchomi się ponownie poprawnie. Ponownie dzieje się tak, ponieważ wiele plików konfiguracyjnych mogło zostać w nim zmienionych i nikt nie uruchomił go ponownie przez długi czas, aby upewnić się, że się pojawi. Ponadto, jeśli serwer wymaga wielu aktualizacji i nie uruchomiono go ponownie przez długi czas, uruchom ponownie przed zastosowaniem aktualizacji, w przeciwnym razie, jeśli wystąpi problem, nie możesz być pewien, że przyczyną był błąd konfiguracji dawno temu lub nowe aktualizacje, które zastosowałeś.

Na koniec, jeśli zrestartujesz krytyczny serwer po bardzo długim czasie, fsck może oznaczać, że będziesz musiał bardzo długo czekać na jego ponowne uruchomienie. Możesz użyć tune2fs, aby tego uniknąć, ale przypuszczam, że warto to sprawdzać regularnie. Dlatego nie powinieneś być w sytuacji, w której jesteś zależny tylko od 1 serwera, a jeśli tak się stanie, cała witryna zniknie. Powinieneś mieć kolejny w trybie gotowości.


3
+1 za „restart przed”
kubańczyk

2

Inną rzeczą, na którą należy zwrócić uwagę przy tym nieoczekiwanym przestoju, jest sprawdzenie, w jaki sposób dokładnie używana jest pamięć i procesor oraz jakie programy. toppowinien być w stanie określić, które procesy są odpowiedzialne za utratę zasobów, a następnie być w stanie zarządzać nimi bezpośrednio. Innym pomysłem byłoby zainicjowanie pracy kroniki w celu zamknięcia i ponownego uruchomienia procesów według określonego harmonogramu.


+1 - Nie wszystkie przerwy są spowodowane przez problem z jądrem.
pcapademic

2

Ponowne uruchomienie komputera nie jest złym pomysłem, jeśli trwało to tak długo, aby można było uruchomić kontrolę dysku (fsck) na partycji głównej. Twój argument może być taki, że pomaga to zapewnić integralność danych.


1

Prawidłowo uruchomiony serwer Linux powinien wymagać ponownego uruchomienia tylko w celu aktualizacji jądra. Tego samego nie zawsze można powiedzieć o niektórych programach - na przykład czasami muszę ponownie uruchomić apache2 lub listonosza.


0

Moja infrastruktura ma dwa serwisy danych, alpha (gdzie operacje odbywają się codziennie) i beta (strona zapasowa, na wypadek, gdyby w alpha sprawy potoczyły się bardzo źle). Chociaż obecnie tak nie jest, staram się zaplanować przestoje w witrynie alfa co 6 miesięcy, abyśmy mogli uruchomić wszystkie usługi z wersji beta.

Osiągnie to dwie rzeczy. Po pierwsze, udowodni to, że nasza strona odzyskiwania po awarii jest całkowicie opłacalna. Po drugie, da mi tydzień czasu na usunięcie nagromadzonego cruftu w alfa.

W tej chwili nie uruchamiam ponownie serwerów tak często, jak powinienem. Zgadzam się z innymi plakatami, które powiedziały, że ważne jest, aby wiedzieć, że twoje serwery wrócą, kiedy będziesz ich potrzebować. Nie chcesz „myśleć”, że to zrobią, tylko po to, aby dowiedzieć się, że coś zmieniłeś i nie zrobiłeś tego poprawnie lub nie udokumentowałeś tego.


0

Możesz dodatkowo napisać kilka skryptów, które sprawdzą (w miarę możliwości), czy bieżącym stanem komputera będzie stan po ponownym uruchomieniu komputera.

Rozumiem przez to ...

  • /etc/init.d/*
    • Sprawdź, czy wszystkie aktualnie uruchomione usługi są oznaczone do uruchomienia podczas rozruchu
    • Sprawdź, czy wszystkie usługi, które nie działają, są oznaczone, aby nie uruchamiały się podczas rozruchu
  • /etc/fstab
    • Sprawdź, czy wszystkie zamontowane systemy plików (tj. /etc/mtab) Mają odpowiedni wpis w/etc/fstab
    • Sprawdź, czy wszystkie systemy plików określone do zainstalowania podczas rozruchu /etc/fstabsą również podłączone.

Nie jest to oczywiście pełna kontrola w żaden sposób, ale zmniejsza ryzyko problemów po ponownym uruchomieniu.

Oprócz tego powinieneś (imo) ustawić zasady dotyczące aktualizacji pakietów serwerów, w rozsądnej kolejności, powiedzmy 1 grupę na tydzień ...

  • Crash & Burn Servers
  • Serwery programistyczne, serwery szkoleniowe
  • Testuj serwery
  • Serwery przedprodukcyjne
  • Serwery produkcyjne

Mają także ogólny plan, taki jak: „Wszystkie serwery przechodzą pełną aktualizację systemu operacyjnego co 6 miesięcy”.


0

Zależy od zadań uruchomionych na serwerze. W przypadku niektórych serwerów wirtualnych często używamy ponownego uruchomienia zamiast np. Restartu Apachectl i zajmuje to tylko 5-10 sekund dłużej. Jednak niektóre mocno obciążone maszyny są uruchamiane ponownie kilka razy w roku, a cała ekipa administracyjna monitoruje ten proces.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.