Kolejność startu to opóźnienie, a nie zależność

Wszyscy ustawiają kolejność startu w przekonaniu, że druga maszyna zaczeka, aż pierwsza będzie gotowa. Nie czeka. Odczekuje ustaloną liczbę sekund i startuje mimo wszystko, i dlatego kolejność działająca na testach zawodzi rankiem po prawdziwej awarii zasilania.

AtlasPVE ·

Ten wpis odpowiada na

  • proxmox kolejność uruchamiania
  • proxmox boot order nie działa
  • proxmox opóźnienie startu vm
  • proxmox kolejność wyłączania
  • proxmox start order

Host wraca po awarii zasilania i połowa tego, co powinno działać, nie działa. Maszyna z bazą danych wstała, ale aplikacja przed nią się poddała, albo kontener nie zdołał zamontować magazynu, który inny kontener dopiero podnosił. Nic nie jest zepsute i nikt nie zapisał błędu wartego przeczytania. Elementy po prostu wstały w złej kolejności.

To tutaj kształt twojej instalacji, czyli kto od kogo zależy, przestaje być szkicem w głowie i staje się czymś, co maszyna naprawdę wykonuje. Warto dokładnie wiedzieć, co robi ten mechanizm, bo jest węższy, niż większość zakłada.

Zdanie wyjaśniające większość niespodzianek

Opóźnienie startu to odstęp, a nie warunek.

Kiedy nadasz gościowi opóźnienie, Proxmox VE uruchamia tego gościa, odczekuje podaną liczbę sekund i przechodzi do następnego. Nie sprawdza, czy uruchamianie wewnątrz gościa się zakończyło. Nie sprawdza, czy jakaś usługa odpowiada. Czeka i idzie dalej.

Zatem układ w twojej głowie, "aplikacja czeka na bazę danych", nigdy nie zostaje skonfigurowany. Konfiguruje się co innego: "aplikacja startuje dziewięćdziesiąt sekund po tym, jak bazie kazano wystartować". Przy spokojnym restarcie testowym te dwa przypadki są nierozróżnialne. Po prawdziwej awarii zasilania, gdy dyski są wolniejsze, uruchamia się sprawdzanie systemu plików albo gość wchodzi w tryb ratunkowy, różnica się ujawnia.

Cztery zasady warte poznania przed wpisaniem liczb

Mniejszy startuje pierwszy i wyłącza się ostatni. Kolejność wyłączania jest odwróceniem kolejności startu; nie ma osobnego ustawienia. Gość z kolejnością 1 wstaje pierwszy i kładzie się ostatni, a zwykle właśnie tego chcemy dla tego, od czego zależy cała reszta.

Równe liczby nie oznaczają losowości. Goście o tej samej kolejności są dodatkowo sortowani rosnąco po identyfikatorze. Remisy są więc stabilne i przewidywalne, a żeby uzyskać powtarzalne zachowanie, nie musisz nadawać każdemu gościowi osobnego numeru.

Goście bez kolejności zawsze startują po tych, którzy ją mają. To bardziej użyteczne, niż brzmi. Nie musisz numerować wszystkiego. Ponumeruj te trzy albo cztery rzeczy, które naprawdę muszą być wcześnie, a resztę zostaw.

Kolejność obowiązuje w obrębie jednego hosta, nie klastra. Nie wyrazi warunku "ten gość na węźle A musi wstać przed tamtym na węźle B". W chwili, gdy zależność przekracza granicę węzła, ten mechanizm nie ma nic do powiedzenia.

Pułapka, która pojawia się później

Goście zarządzani przez warstwę wysokiej dostępności ignorują zarówno start przy uruchomieniu, jak i kolejność startu. Procedura startu i zatrzymania pomija ich całkowicie, bo o tym, kiedy działają, decyduje menedżer wysokiej dostępności.

Ta pułapka gryzie późno. Pojedynczy host ze starannie dobraną kolejnością działa przez rok. Potem pojawia się drugi węzeł, część gości przechodzi pod wysoką dostępność, a ich kolejność po cichu przestaje obowiązywać. Nic cię nie ostrzeże, bo nic nie jest zepsute; zmieniła się tylko odpowiedzialność.

Opóźnienie, którego naprawdę chcesz, bywa inne

Częstym powodem sięgania po opóźnienia gości jest zasób zewnętrzny: magazyn sieciowy, który musi być osiągalny, zanim ktokolwiek go zamontuje, albo przełącznik potrzebujący chwili. Kupowanie tego czasu przez rozstawianie pojedynczych gości jest niezgrabne, bo rozciąga całą sekwencję.

Istnieje osobne ustawienie na poziomie węzła właśnie do tego: opóźnienie między zakończeniem startu hosta a pierwszym gościem uruchamianym automatycznie. Jedna liczba, zastosowana raz, dokładnie tam, gdzie czekanie faktycznie należy.

Liczba, której nikt nie ustawia, dopóki nie zaboli

Limit czasu wyłączania wynosi domyślnie 180 sekund na gościa. Proxmox VE prosi gościa o wyłączenie, czeka, a jeśli po upływie limitu gość nadal działa, zostaje zatrzymany siłowo. Zbiorowe zatrzymanie wszystkich gości ma własny łączny limit trzech minut, po którym dzieje się to samo.

Dla maszyny, która przy wyłączaniu zrzuca dane na dysk, ten pułap warto sprawdzić celowo, a nie odkryć w trakcie awarii. Wartość domyślna jest hojna dla większości gości i za krótka dla kilku, a te kilka to dokładnie ci, przy których wymuszone zatrzymanie coś kosztuje.

Co widać w praktyce

Na hoście użytym do sprawdzenia opisanego tu zachowania skonfigurowanych było dziewięciu gości, a trzech ustawiono na start przy uruchomieniu. Żaden nie miał kolejności startu.

To normalny stan rzeczy i często zupełnie w porządku. Maszyny, które od siebie nie zależą, nie potrzebują kolejności. Cel tego tekstu jest węższy: jeśli kiedykolwiek powiedziałeś na głos, że jeden gość potrzebuje, by inny wstał pierwszy, to zdanie mieszka obecnie wyłącznie w twojej pamięci, a awaria zasilania twojej pamięci nie czyta.

Co robi Atlas

Atlas niczego za ciebie nie przestawia i nie wymyśla systemu zależności na wierzchu tego, który ma Proxmox VE. Robi tyle, że pokazuje powiązania na jednym obrazie zamiast gość po gościu, żeby pytanie "co tu naprawdę od czego zależy" dało się zadać, gdy maszyna jest spokojna, a nie gdy właśnie wraca.

Zobaczenie kształtu nie konfiguruje go. Ale nikt nie ustawia rozsądnej kolejności dla układu, którego nigdy nie widział narysowanego.

Źródła

Własna dokumentacja Proxmoksa. Po angielsku i to ona ma ostatnie słowo w tej sprawie.

Powiązane wpisy

Jak to wygląda wewnątrz Atlasa?

Przejdź do strony produktu