Jak uniknąć przestojów w systemie Linux?

Często aktualizacje oprogramowania Ubuntu wymagają ponownego uruchomienia komputera (co może mieć skutki uboczne, takie jak przestój).

Widzę, że Ubuntu ma https://www.ubuntu.com/livepatch, który pozwala na aktualizacje jądra bez restartów, jednak jest to usługa płatna. Istnieje również ksplice .

Czy istnieją dystrybucje / procesy dla Linuksa, w których aktualizacje / poprawki nigdy nie wymagają ponownego uruchamiania?

(Wiem, że konfigurowanie serwerów wysokiej dostępności (HA) i posiadanie serwerów jednorazowych to najlepsze praktyki - więc nie pytam o utrzymanie usługi, ale na rzeczywistych serwerach).

Na twoje pytanie: „Czy istnieją dystrybucje / procesy dla Linuksa, w których aktualizacje / łaty nigdy nie wymagają ponownego uruchomienia?”, Nie jestem świadomy żadnego z nich i jestem bardzo wątpliwy, czy kiedykolwiek pojawią się takie, które są naprawdę wolne od ponownego uruchomienia. Oprócz komentarza Michaela Hamptona, dlaczego łatanie na żywo nie jest nigdzie gotowym doświadczeniem, łatanie na żywo również nie osiąga takiego samego rezultatu jak ponowne uruchomienie.

Anegdota, aby to zilustrować: Niedawno zbadałem problem polegający na tym, że pewne narzędzie zaczęło segregować na dużej liczbie komputerów. Próbowałem spojrzeć na współdzielone biblioteki, które kiedyś sprawdzały, czy coś, co ostatnio zostało zaktualizowane, zepsuło; ldd powiedział, że nie jest to plik wykonywalny (chociaż kiedy ściągnąłem ten sam plik binarny do mojego laptopa, ldd dobrze widział zależności współdzielonej biblioteki). Próbowałem przejść przez to w gdb; segregował, zanim dotarł do pierwszej instrukcji.

Patrząc na czas wystąpienia usterki, zauważyłem, że łatka Ksplice została niedawno zastosowana. Wycofałem łatkę, a plik binarny nie segregował się, a następnie dodałem go z powrotem i znów zaczął się segregować. Ponowne uruchomienie jądra z równo załatanym jądrem działało dobrze. Okazało się, że jest to łatka na 32-bitową obsługę, której członkowie Ksplice nie zastosowali całkiem poprawnie. Trzeba przyznać, że w ciągu kilku godzin wydali poprawkę, która wróciła do prawidłowego działania naszej floty bez interwencji.

Kolejny przykład: łaty Meltdown / Spectre były tak inwazyjne, że zespół jądra Ubuntu zdecydował, że łatanie na żywo jest niepraktyczne i wymagał od ludzi ponownego uruchomienia systemu w stałym jądrze przed ponownym otrzymaniem łatek na żywo.

Działamy w pracy duża flota serwerów fizycznych i wirtualnych, z dużą liczbą systemów Ksplice i Canonical Livepatch. Oba były znacznie bardziej niezawodne niż wiele innych programów, ale wolałbym raczej, aby nasze usługi były zaprojektowane z architekturą przyjazną dla restartów, niż polegać na łataniu jądra na żywo.

Istnieje istotna różnica między uczynieniem usługi wysoce dostępną a wysoce indywidualną maszyną.

W większości przypadków celem jest zapewnienie wysokiej dostępności usługi, a dostępność poszczególnych maszyn jest jedynie środkiem do osiągnięcia tego celu. Istnieje jednak limit, jak daleko można osiągnąć cel, poprawiając dostępność poszczególnych maszyn.

Nawet jeśli możesz usunąć wszystkie przestoje z powodu konieczności aktualizacji oprogramowania, poszczególne komputery nadal nie będą w 100% dostępne. Dlatego, aby zwiększyć dostępność usługi ponad dostępność poszczególnych maszyn, należy zaprojektować redundancję na wyższym poziomie. Ostatnie zdanie twojego pytania pokazuje, że przynajmniej w zasadzie o tym wiesz.

Jeśli zaprojektujesz usługę, która będzie bardziej dostępna niż pojedyncze maszyny, to nie będzie już presji na osiągnięcie wysokiej dostępności poszczególnych maszyn. Dlatego w przypadku wysoce dostępnych usług nie trzeba unikać ponownego uruchamiania. Zamiast tego możesz poświęcić pewną niezawodność poszczególnych maszyn, aby uzyskać oszczędności, które można przeznaczyć na inne obszary, w których można uzyskać znacznie wyższy wzrost niezawodności.

Kiedy system wysokiego poziomu zostanie zaprojektowany tak, aby był niezawodny w przypadku awarii poszczególnych komponentów sprzętowych, łatanie jądra na żywo zmienia się z przewagi w ryzyko.

Jest to ryzyko, ponieważ mogą występować subtelne różnice między zachowaniem maszyny, która została załatana na żywo, a maszyną uruchomioną z najnowszą wersją jądra. Może to spowodować ukryty błąd, który może spowodować awarię przy następnym uruchomieniu komputera. Ryzyko to zwiększa się poprzez ponowne uruchomienie, aby uzyskać czystą kartę, która jest postrzegana jako metoda łagodzenia niektórych awarii.

Pewnego dnia możesz mieć awarię, w której Twoim zdaniem może pomóc ponowne uruchomienie komputera. Ale podczas restartu zostajesz dotknięty ukrytym błędem, który uniemożliwia maszynie powrót do pożądanego stanu. Patchowanie na żywo nie jest jedynym sposobem, w jaki może wystąpić taki ukryty błąd, może się również zdarzyć, ponieważ coś tak przyziemnego jak usługa została włączona ręcznie i nigdy nie została skonfigurowana do uruchamiania podczas rozruchu lub została skonfigurowana do uruchamiania zbyt wcześnie, aby nie pojawia się z powodu niezadowolonych zależności.

Z tych powodów wysoce dostępna usługa może być łatwiejsza do osiągnięcia przy regularnym ponownym uruchamianiu poszczególnych komputerów w wystarczająco wolnym tempie, aby można było wykryć problemy i wstrzymać sekwencję ponownego uruchamiania, gdy tylko wystąpią problemy.