Jądro systemu Linux 6.x: istotne zmiany dla serwerów hostingowych

Prawidłowe sklasyfikowanie stanu jądra

Określenie „Linux 6.x” obejmuje wiele głównych wydań, a nie jeden jednolity stan funkcjonalny. Za główną gałąź uważa się gałąź rozwijaną przez Linusa Torvaldsa: po zakończeniu okresu scalania (merge window) zazwyczaj pojawiają się wersje kandydackie (release candidates), aż do ostatecznego wydania głównego. Należy je odróżnić od gałęzi stabilnych i LTS, które zapewniają dalszą obsługę opublikowanych jądra z wybranymi poprawkami. Z kolei jądra dystrybucji podlegają własnym wersjom pakietów, zobowiązaniom dotyczącym wsparcia oraz decyzjom integracyjnym.

Szczególnie w przypadku serwerów hostingowych są Backporty Co istotne: dystrybucja może włączać poszczególne funkcje, ulepszenia sterowników lub poprawki bezpieczeństwa do starszego jądra, które jest utrzymywane w dłuższej perspektywie. Z drugiej strony może ona wyłączać funkcje, modyfikować poprawki lub ograniczać je poprzez konfigurację. Na podstawie numeru wersji nie można zatem wywnioskować ani pełnego zakresu funkcji, ani konkretnego wpływu na działanie systemu.

Polecenie uname -r identyfikuje bieżący ciąg wersji i stanowi sensowny punkt wyjścia do inwentaryzacji i porównania pakietów. Nie dowodzi jednak, że dana funkcja została skompilowana, aktywowana w czasie wykonywania lub jest dostępna dla danej aplikacji. Nawet nowa wersja jądra nie zastępuje sprawdzenia konfiguracji i dokumentacji udostępnionej przez dystrybutora.

Aby uzyskać rzetelną klasyfikację, należy sprawdzić kilka poziomów: dystrybucję i wersję pakietów, konfigurację jądra, parametry rozruchowe oraz dostępne interfejsy uruchomieniowe. Do tego dochodzą sprzęt, oprogramowanie układowe i sterowniki, na przykład w przypadku pamięci masowej lub wirtualizacji. W końcu wykorzystywana aplikacja musi faktycznie korzystać z danego interfejsu; sama obecność funkcji jądra nie powoduje automatycznie zmian w serwerze WWW.

W związku z tym niniejszy artykuł nie stanowi pełnej chronologii wydanych wersji. Omówiono w nim funkcje istotne dla działania współczesnych jąder serii 6.x. Nie każda z nich została wprowadzona dopiero w serii 6.x; decydujące znaczenie mają: zakres funkcji dostępnych w konkretnym jądrze, możliwe rozszerzenia oraz wpływ na zachowanie pamięci, współdzielenie procesora, izolację procesów i konserwację.

Cztery obszary działalności w zakresie hostingu

W przypadku serwerów hostingowych szczególne znaczenie mają cztery obszary działalności: ciśnienie w zbiorniku, rywalizacja o zasoby procesora, dodatkowa izolacja procesów oraz konserwacja. Nie chodzi tu o jak największą liczbę włączonych funkcji jądra, lecz o odpowiednie narzędzia do rozwiązania konkretnego problemu. Pule PHP-FPM, bazy danych, pamięci podręczne, zadania wsadowe i wyspecjalizowane procesy robocze stawiają różne wymagania, których nie da się wywnioskować wyłącznie na podstawie wersji jądra.

cgroup v2 jest to zagadnienie o charakterze przekrojowym, ale nie stanowi nowości w serii 6.x. Hierarchia ta porządkuje zasoby pamięci i procesora dla usług, kontenerów lub grup klientów. Które kontrolery są dostępne i aktywowane w danej podhierarchii, należy sprawdzić w odpowiednim punkcie montowania cgroup-v2. Dlatego dedykowany serwer WWW wymaga innego podejścia niż host kontenerów lub maszyn wirtualnych.

W tabeli celowo rozróżniono konfigurację kompilacji, aktywację podczas rozruchu, interfejs środowiska uruchomieniowego oraz rzeczywiste wykorzystanie. Funkcja może być zawarta w jądrze, ale może być wyłączona lub nie mieć znaczenia dla danej aplikacji. Podobnie dystrybucje mogą cofać funkcje. Dlatego zmiany należy oceniać na podstawie wykresów obciążenia, struktury cgroup, sprzętu i pomiarów aplikacji, a nie na podstawie najwyższego dostępnego numeru wersji.

Ciśnienie w pamięci i odzyskiwanie stron

System Linux chętnie wykorzystuje wolną pamięć operacyjną jako pamięć podręczną plików. Duże zużycie pamięci RAM nie jest zatem samo w sobie błędem ani dowodem marnotrawstwa pamięci: buforowane strony plików można odzyskać w razie potrzeby. Dla celów diagnostycznych większe znaczenie mają raczej przebieg i skutki obciążenia, takie jak czasy odpowiedzi, aktywność partycji swap, logi błędów oraz przerwania procesów.

Decyduje ciśnienie w zbiorniku Odzyskiwanie pamięci , które strony można usunąć z pamięci podręcznej lub, w razie potrzeby, przenieść do pamięci zewnętrznej. Jądro może wykonywać tę operację asynchronicznie poprzez kswapd wykonanie. Jeśli proces musi samodzielnie odzyskać strony w odpowiedzi na żądanie zapisu, dokumentacja jądra określa to jako bezpośrednie odzyskiwanie; może to negatywnie wpłynąć na działanie procesu wysyłającego żądanie, a tym samym na obserwowane opóźnienia.

Sygnały ostrzegawcze pojawiają się zazwyczaj w połączeniu: długotrwałe przenoszenie danych do lub z pamięci wymiany, zdarzenia OOM, rosnące czasy oczekiwania oraz błędy na poziomie aplikacji powinny zostać przedstawione na wspólnej osi czasu. Jednorazowym odchyleniem może natomiast być zaplanowane zadanie wsadowe. Również usługa buforowania zajmująca dużą część pamięci RAM nie jest automatycznie przyczyną, o ile jej grupa cgroup oraz pozostałe procesy zachowują wystarczającą zdolność do działania.

cgroup v2 rozszerza widok globalny o granice usług lub kontenerów. Kontroler pamięci udostępnia liczniki zdarzeń; memory.events ma strukturę hierarchiczną, podczas gdy memory.events.local wyświetla wyłącznie zdarzenia lokalne danej grupy cgroup. Dzięki temu można ustalić, czy problem wynika z limitu danej usługi, czy też z obciążenia w strukturze nadrzędnej.

Te podstawowe informacje nie wskazują jeszcze na konieczność tuningu. Zanim zmienisz limity, strategię swapowania lub interfejsy jądra, uporządkuj źródła obciążenia, przypisania do grup cgroup oraz korelacje czasowe. Szczególnie rygorystyczny limit pamięci może spowodować przedwczesną awarię usługi, zamiast rozwiązać problem związanego z nią szczytu obciążenia. Dopiero diagnoza pokazuje, czy dana zmiana w ogóle stanowi odpowiedni element regulacyjny.

Celowa kontrola modułów LRU z wielu generacji

Multi-Gen LRU to alternatywna implementacja dla Odzyskiwanie pamięci i jest opisany w omawianej tutaj dokumentacji jądra, począwszy od wersji Linux 6.1. W sytuacji niedoboru pamięci jądro musi zdecydować, które strony z pamięci podręcznej plików lub strony pamięci anonimowej można odzyskać. W tym celu algorytm Multi-Gen LRU przypisuje strony do generacji w zależności od czasu ostatniego dostępu i uwzględnia wzorce dostępu, dzięki czemu strony rzadziej wykorzystywane są rzadziej wybierane do odzyskania.

Ma to znaczenie w przypadku mocno obciążonego serwera hostingowego, na którym pule PHP-FPM, baza danych i usługa pamięci podręcznej jednocześnie zajmują pamięć RAM. Funkcja ta może wpłynąć na wybór podczas odzyskiwania pamięci, nie stanowi jednak ani rozszerzenia pamięci, ani gwarancji skrócenia czasu odpowiedzi. Obciążenie, ilość pamięci RAM, obszar wymiany, pamięć masowa oraz limity cgroup usług nadal decydują o tym, czy i w jaki sposób efekt ten będzie zauważalny.

Przed każdą oceną należy najpierw sprawdzić, czy interfejs środowiska uruchomieniowego jest dostępny i czy można go odczytać. Aktualna dokumentacja jądra podaje w tym celu następujące opcje konfiguracyjne: CONFIG_LRU_GEN oraz CONFIG_LRU_GEN_ENABLED oraz ścieżkę pod adresem /sys/kernel/mm/lru_gen/. Jądro dystrybucji może przenosić wersje funkcji do wcześniejszych wydań lub konfigurować je w inny sposób; sam numer wersji nie stanowi zatem wiarygodnego dowodu.

test -r /sys/kernel/mm/lru_gen/enabled && cat /sys/kernel/mm/lru_gen/enabled

Wyświetlenie tego komunikatu potwierdza na razie jedynie, że udokumentowany interfejs sysfs istnieje i jest dostępny do odczytu. Dla stanu aktywacji istotna jest wartość bitowa: 0x0001 jest to bit przełącznika głównego modułu LRU Multi-Gen. Jeśli ten bit nie jest ustawiony, plik może wskazywać wyłączony przełącznik główny, mimo że interfejs jest dostępny; pozostałe bity dotyczą dodatkowych komponentów. Nawet ustawiony bit główny nie stanowi ogólnej rekomendacji, by zmieniać tę wartość w środowisku produkcyjnym.

Dostęp zapisu do sysfs nie jest zatem standardową metodą optymalizacji. Najpierw należy zebrać szeregi czasowe dotyczące funkcji „Reclaim”, „Swap”, opóźnień oraz zdarzeń cgroup, a w przypadku uzasadnionej zmiany udokumentować wartość początkową i określić sposób powrotu do stanu wyjściowego. Dzięki temu będzie można ustalić, czy faktycznie zaobserwowany problem uległ zmianie, czy też po prostu jednocześnie zmieniono kilka zmiennych regulacyjnych.

Należy zachować szczególną ostrożność w przypadku ograniczonej przestrzeni dyskowej i przeciążonych usług. Zmodyfikowany algorytm odzyskiwania zasobów nie koryguje zbyt dużych pul procesów roboczych PHP, nieodpowiednich pamięci podręcznych baz danych ani braku rozdzielenia konkurujących ze sobą klientów. Właściwa kolejność działań wygląda następująco: należy określić przyczynę i dotkniętą grupę cgroup, ograniczyć lub rozłożyć obciążenie, a dopiero potem ocenić dostępną funkcję jądra jako potencjalny czynnik wpływający na sytuację.

Skuteczne zawężanie zakresu problemów z pamięcią

Zajęta pamięć RAM sama w sobie nie stanowi błędu: system Linux wykorzystuje wolną pamięć jako pamięć podręczną plików. Konieczność podjęcia działań pojawia się raczej wtedy, gdy wymagania w bezpośredni odzysk działają, wzrasta aktywność swapowania, pojawiają się zdarzenia OOM lub jednocześnie spowalniają się zapytania. Asynchroniczne odzyskiwanie pamięci poprzez kswapd działa w tle; bezpośrednie odzyskiwanie danych odbywa się natomiast w kontekście zadania wymagającego pamięci i może opóźnić jego wykonanie.

Plik zdarzeń memory.events zlicza zdarzenia hierarchicznie, czyli uwzględniając podrzędne grupy cgroup. W przypadku widoku wyłącznie lokalnego stosuje się memory.events.local gotowy. high oznacza ograniczenie przepływu i bezpośrednie odzyskiwanie po przekroczeniu memory.high, podczas gdy oom liczy się jako nieudana alokacja, która grozi przekroczeniem limitu cgroup. oom_kill Z kolei uwzględnia procesy z tej grupy cgroup, które zostały zakończone przez dowolny rodzaj mechanizmu OOM-Killer.

Rozpocznij diagnostykę od jasnego określenia: która usługa lub kontener należy do podejrzanej grupy cgroup, kiedy wystąpiły zdarzenia i jakie sygnały aplikacji pojawiły się w tym samym czasie? Następnie porównaj liczniki lokalne z hierarchicznymi, dziennik systemowy, historię wymiany pamięci, a także opóźnienia HTTP, czasy oczekiwania w bazie danych lub wskaźniki błędów. W przypadku wystąpienia błędu OOM należy dodatkowo ustalić, czy dane wskazują na proces związany z cgroup, czy też na ewentualny globalny brak pamięci.

Wartość memory.max jest to ścisły limit cgroup i nie stanowi pierwszego standardowego środka. Węższy limit może chronić klientów, ale może też szybciej doprowadzić aplikację do sytuacji OOM; wyższy limit może nasilić wypieranie sąsiednich usług. Dlatego najpierw sprawdź liczbę procesów roboczych, rozmiary pamięci podręcznej, szczyty obciążenia oraz strukturę cgroup. Następnie zmień tylko jedną uzasadnioną zmienną regulacyjną, uwzględniając okres obserwacji i plan powrotu do poprzednich ustawień.

Zrozumieć EEVDF i rywalizację między procesorami

Aktualna oficjalna dokumentacja jądra określa początek przejścia na EEVDF Linux 6.6. Algorytm „Earliest Eligible Virtual Deadline First” zmienia sposób wyboru zwykłych zadań planowanych zgodnie z zasadą sprawiedliwości: uwzględniane są wirtualny czas wykonania, opóźnienie jako odchylenie od idealnego rozkładu oraz wirtualne terminy. Dzięki temu zadania kwalifikujące się, które mają najwcześniejszy wirtualny termin, mogą jako pierwsze otrzymać czas procesora.

Sformułowanie „przejście“ ma tu duże znaczenie. EEVDF nie zastępuje decyzji dotyczącej wyboru klasy Fair Scheduling w tym sensie, że nie powoduje to zniknięcia wszystkich struktur danych, interfejsów i koncepcji, które historycznie określano jako CFS. Również aktualna dokumentacja nadal porównuje EEVDF z CFS. W przypadku konkretnego jądra dystrybucji należy zatem sprawdzić jego zintegrowany stan poprawek i funkcji, zamiast opierać się wyłącznie na 6.6 lub wyższym poziomie można wywnioskować, że zachowanie jest całkowicie jednolite.

W przypadku hostingu zmiana ta ma znaczenie przede wszystkim przy obciążeniu mieszanym. Żądania internetowe, operacje na bazach danych i monitorowanie konkurują na przykład z importami, kompresją lub tworzeniem kopii zapasowych. Możliwe jest uzyskanie innego profilu opóźnień między wersjami jądra, ale nie oznacza to automatycznie większej łącznej przepustowości. Harmonogram nie rozwiązuje problemów związanych z rdzeniami stale obciążonymi, zablokowanymi procesami, opóźnieniami we/wy oraz nieodpowiednimi konfiguracjami aplikacji.

Rozdzielenie operacyjne nadal odbywa się w oparciu o granice usług i platform. Wagi procesora wpływają na względny rozkład w przypadku konkurencji, natomiast limity mogą ograniczać dostępny czas obliczeniowy. Jeśli obciążenia internetowe, dla których opóźnienia mają kluczowe znaczenie, muszą być niezawodnie oddzielone od rozbudowanych zadań wsadowych, odpowiednim rozwiązaniem może być również osobna maszyna wirtualna (VM) lub oddzielny host. EEVDF zastępuje te rozwiązania Planowanie zasobów nie.

Przed wysłaniem zapytania o cgroup.controllers musisz sprawdzić, czy i gdzie jest zamontowana grupa cgroup v2. Poniższa procedura odczytu wyszukuje punkt montowania cgroup-v2 zamiast standardowej ścieżki /sys/fs/cgroup należy założyć. W systemie opartym wyłącznie na cgroup-v1 zmienna ta pozostaje pusta; w przypadku hierarchii hybrydowej wskazuje ona jedynie znalezione montowanie v2.

uname -r
findmnt -t cgroup2 -o TARGET,FSTYPE,OPTIONS
CG2=$(findmnt -n -t cgroup2 -o TARGET | head -n 1)
if [ -n "$CG2" ] && [ -r "$CG2/cgroup.controllers" ]; then
    printf 'cgroup-v2 mount: %s\n' "$CG2"
    cat "$CG2/cgroup.controllers"
    test -r "$CG2/cgroup.subtree_control" && cat "$CG2/cgroup.subtree_control"
fi
systemd-cgtop

uname -r określa jedynie bieżący ciąg znaków wersji. cgroup.controllers wyświetla listę kontrolerów dostępnych do aktywacji właśnie w tej grupie cgroup; nie potwierdza jednak, że zostały one włączone w odpowiednich podhierarchiach. Do tego służy między innymi cgroup.subtree_control należy sprawdzić na odpowiednich poziomach hierarchii. Kontrolery są udostępniane odgórnie, co oznacza, że podgrupa cgroup może przekazywać dalej wyłącznie kontrolery udostępnione przez węzeł nadrzędny.

systemd-cgtop również dostarcza jedynie migawkę sytuacji i nie stanowi analizy przyczyn. Zbierz dane dotyczące obciążenia procesora w podziale na grupy usług, opóźnień żądań, czasów wykonania zadań wsadowych oraz, w razie potrzeby, czasów oczekiwania na operacje wejścia/wyjścia z kilku porównywalnych faz obciążenia. Jeśli opóźnienia występują wyłącznie podczas tworzenia kopii zapasowej, to jej przedział czasowy, obciążenie procesora lub limit są zazwyczaj bardziej konkretnymi punktami wyjścia do regulacji niż domniemane dostosowanie harmonogramu.

Landlock dla wyspecjalizowanych pracowników

Funkcja Landlock została wprowadzona po raz pierwszy w systemie Linux 5.13, dlatego nie jest to nowość wprowadzona w serii 6.x. W jądrach serii 6.x dostępne są różne, rozszerzone wersje ABI, w zależności od wydania i jądra dystrybucji. Funkcja ta stanowi dodatkowy mechanizm zabezpieczający, dzięki któremu proces może samodzielnie nałożyć na siebie dalsze ograniczenia.

Landlock, jako moduł zabezpieczeń systemu Linux działający w trybie nakładania się, funkcjonuje jako uzupełnienie już obowiązujących decyzji dotyczących dostępu; nie zastępuje on ani uprawnień do plików w systemie Unix, ani SELinux, AppArmor, przestrzeni nazw ani kontenerów. Reguły mogą między innymi ograniczać dostęp do systemu plików i są przekazywane do uruchamianych następnie procesów potomnych. Rzeczywisty zakres funkcji zależy od dostępnego interfejsu ABI oraz konfiguracji jądra.

Warto Bez dostępu do morza zwłaszcza w przypadku procesów opracowanych we własnym zakresie lub celowo wybranych. Konwerter do plików przesyłanych przez klientów mógłby odczytywać pliki wyłącznie z jednego folderu wejściowego i zapisywać wyniki wyłącznie w jednym folderze wyjściowym. Nawet w przypadku nieprawidłowego działania usługi nie powinna ona mieć możliwości odczytu kluczy SSH, tajnych danych aplikacji ani ogólnych ścieżek systemowych. Ograniczenie to stanowi uzupełnienie starannego przypisywania uprawnień, ale nie czyni go zbędnym.

Reguła dotycząca wydajności nie może opierać się wyłącznie na aktualnej wersji jądra. Landlock posiada wersje ABI; aplikacja powinna sprawdzać dostępny interfejs ABI w czasie wykonywania i żądać wyłącznie uprawnień dostępu lub funkcji obsługiwanych przez ten interfejs. Dzięki temu może ona działać w trybie ograniczonym na starszych systemach, zamiast całkowicie przestać działać z powodu niedostępnego interfejsu.

Osobno określa się handled_access_fs wyraźnie określa, które operacje na systemie plików są obsługiwane przez zestaw reguł, a które – w przypadku braku odpowiedniej reguły – są domyślnie blokowane. Ta wyraźna umowa między aplikacją a jądrem zapobiega sytuacji, w której piaskownica staje się niepostrzeżenie bardziej restrykcyjna wyłącznie w wyniku aktualizacji systemu, co mogłoby spowodować awarie aplikacji. Zapytanie o ABI i wyraźnie określone uprawnienia są zatem ze sobą powiązane, ale rozwiązują różne problemy związane z kompatybilnością.

W przypadku konwertera plików oznacza to wprowadzenie stopniowe: należy określić wymagane katalogi odczytu, zapisu i robocze na podstawie rzeczywistego przebiegu procesu, uwzględnić ścieżki błędów i najpierw przetestować je w środowisku testowym. Zwięzły przykładowy schemat nie stanowiłby niezawodnej recepty na środowisko produkcyjne, ponieważ pliki tymczasowe, biblioteki zewnętrzne i uruchomione programy pomocnicze mogą wymagać dodatkowego dostępu. Dalsze działania dotyczące izolacji usług omówiono również w artykule poświęconym Wzmocnienie zabezpieczeń jądra dla serwerów hostingowych.

Należy zachować szczególną ostrożność w przypadku OverlayFS. Reguły dotyczące warstwy nakładkowej nie ograniczają automatycznie połączonej hierarchii montowania i odwrotnie. Środowiska kontenerowe i kompilacyjne z nakładkami wymagają zatem osobnej weryfikacji konkretnych montowań i ścieżek dostępu. Landlock stanowi w tym przypadku potencjalną dodatkową warstwę, ale nie zapewnia ogólnego oddzielenia klientów i nie zastępuje solidnej koncepcji kontenerowej ani koncepcji uprawnień.

DAMON – wyłącznie w wyjątkowych przypadkach

Nie można ogólnie uznać, że DAMON i oparte na nim mechanizmy odzyskiwania pamięci zostały wprowadzone po raz pierwszy w systemie Linux 6.x. Dla administratorów liczy się stan funkcjonalny konkretnie stosowanego jądra wersji 6.x lub jądra dystrybucji. DAMON monitoruje operacje dostępu do pamięci w celu klasyfikacji obszarów na podstawie ich wzorców użytkowania.

W oparciu o to próbuje się DAMON_RECLAIM, polegające na proaktywnym odzyskiwaniu pamięci, która od dawna nie była używana, poprzez wywieranie niewielkiego nacisku. Metoda ta stanowi uzupełnienie standardowego odzyskiwania opartego na algorytmie LRU; nie ma ona na celu jego zastąpienia. Dokumentacja jądra przypisuje ją do ogólnych systemów pamięci z nadmiarem rezerw i podaje jako przykład wirtualizację opartą na raportowaniu wolnych stron (Free Pages Reporting).

W tym scenariuszu wirtualizacji kluczowe znaczenie ma poziom: goście zgłaszają hostowi wolne strony pamięci, które host może przydzielić innym gościom. Jeśli gość zgłasza niewiele wolnej pamięci, mimo że przechowuje strony, które od dawna nie były używane, proaktywne odzyskiwanie pamięci jako gość przyczynić się do zgłoszenia większej liczby wolnych stron do hosta. W związku z tym DAMON_RECLAIM nie jest – bez dalszej weryfikacji – rozwiązaniem po stronie hosta dla niewykorzystanej pamięci operacyjnej gości.

W przypadku pojedynczego serwera WWW lub serwera bazy danych nie jest to zatem standardowe działanie. Również w środowiskach wirtualnych należy najpierw ustalić, na jakim poziomie powstaje obciążenie i czy rzeczywiście przyczyną są obszary pozostające przez długi czas niewykorzystane. Wąskie gardła procesora, powolna pamięć masowa, nieodpowiednie limity cgroup lub aktywne pamięci podręczne aplikacji mogą wyjaśniać te same objawy, a proaktywne odzyskiwanie zasobów nie byłoby w takich przypadkach właściwym rozwiązaniem.

Współczynniki, limity wiekowe i poziomy wody określają, kiedy i w jakim zakresie działa DAMON_RECLAIM. Nie są to standardowe wartości, które można po prostu przenieść: zbyt agresywny dobór może przedwcześnie wyprzeć przydatną pamięć podręczną plików lub strony pamięci, które są regularnie potrzebne. Może to spowodować dodatkowe operacje wejścia/wyjścia (I/O) i pochłonąć czas procesora na ponowne przetwarzanie danych, mimo że nominalna ilość wolnej pamięci wzrasta.

Podjęcie trafnej decyzji wymaga zatem pomiarów opartych na jasnych wskaźnikach porównawczych, takich jak wolna przestrzeń dyskowa zgłoszona przez użytkownika, aktywność odzyskiwania przestrzeni, zachowanie pamięci wymiany, opóźnienia pamięci masowej oraz czasy odpowiedzi aplikacji. Zmiany należy najpierw przetestować w podobnym środowisku testowym, określić plan awaryjny i obserwować je w reprezentatywnych fazach obciążenia. Jeśli te warunki nie są spełnione lub przyczyna obciążenia pamięci masowej pozostaje niejasna, DAMON pozostaje celowo wyłączony.

Aktualizacje, poprawki na żywo i ponowne uruchomienia

Konserwacja jądra rozpoczyna się od porównania komunikatu o zabezpieczeniach, zainstalowanego pakietu oraz faktycznie uruchomionego jądra. Następnie sprawdź w instrukcjach swojej dystrybucji, jaka poprawka jest przewidziana dla tej konkretnej gałęzi jądra oraz czy wymagane jest ponowne uruchomienie systemu. Sam wyższy numer wersji 6.x nie świadczy ani o zawartości poprawki, ani o dostępności odpowiedniej poprawki typu „livepatch”; poprawki bezpieczeństwa mogą być również przenoszone wstecz do starszych jądra dystrybucji.

Również Wprowadzanie poprawek na żywo nie została wprowadzona jako koncepcja dopiero w systemie Linux 6.x. Infrastruktura odpowiednia dla jądra 6.x pozwala na wprowadzanie określonych zmian w jądrze w trakcie działania systemu. Skumulowane poprawki na żywo mogą przy tym atomowo zastąpić starszą poprawkę nowszą. Udokumentowane ograniczenia dotyczą między innymi zmian stanu, wywołań zwrotnych oraz powrotu do poprzedniej poprawki.

To, czy dla konkretnego jądra dystrybucyjnego dostępna jest odpowiednia poprawka na żywo, należy sprawdzić na podstawie aktualnej oferty i informacji o zatwierdzeniach dostawcy. Z ogólnej infrastruktury jądra nie wynika ani to, że każda poprawka bezpieczeństwa jest dostępna w trybie live, ani to, że zainstalowana poprawka trwale zastępuje pełną aktualizację jądra. Dlatego należy nadal planować regularne okna serwisowe.

Najpierw oceń pilność i skutki aktualizacji, następnie porównaj stan pakietów i aktualnie uruchomionego jądra oraz sprawdź konkretną ofertę aktualizacji Livepatch. Po przeprowadzeniu standardowej aktualizacji jądra i ponownym uruchomieniu systemu sprawdź, czy oczekiwane jądro jest aktywne oraz czy krytyczne usługi, ścieżki sieciowe, kopie zapasowe i system monitorowania działają poprawnie. Ta kontrola stanowi część procedury konserwacyjnej i nie powinna opierać się wyłącznie na dostępności serwera.

A planowane ponowne uruchomienie może być nadal konieczne pomimo stosowania poprawek na żywo. Zmiany parametrów rozruchowych jądra zazwyczaj zaczynają obowiązywać dopiero przy następnym uruchomieniu. W przypadku sterowników, oprogramowania układowego urządzeń i sprzętu sposób postępowania zależy natomiast od danego komponentu, sposobu jego integracji oraz procedur producenta: w niektórych przypadkach wystarczy ponowne uruchomienie modułu, urządzenia lub usługi, w innych konieczny jest całkowity restart hosta.

Dodatkowy artykuł na temat Aplikowanie poprawek na żywo na serwerach AlmaLinux Dotyczy konkretnej implementacji zależnej od dystrybucji. Nie należy przenosić takich procedur bez weryfikacji na inne gałęzie jądra lub do innych dostawców. Decydujące znaczenie mają pakiety, obsługiwane wersje jądra oraz wskazówki dotyczące eksploatacji platformy faktycznie używanej.

• Nie należy celowo wprowadzać żadnych zmian, jeśli za zaobserwowaną usterką nie stoi jeszcze żadna rozpoznawalna przyczyna.
• Nie należy planować żadnych poprawek na żywo ani zmian w jądrze bez odpowiedniego testu w środowisku stagingowym i udokumentowanego planu awaryjnego.
• Nie należy aktywować żadnej funkcji, jeśli dana aplikacja lub platforma nie korzysta z jej interfejsu.
• Nie należy zakładać, że brak okresu konserwacji oznacza, iż funkcja Livepatching obejmuje każdą aktualizację jądra.