Przy klastrze złożonym z kilkunastu maszyn często storage jest na zewnętrznej macierzy. Mamy wtedy osobną sieć do komunikacji między serwerami i osobną dla storage.
Co się stanie w momencie gdy na jednym serwerze stracimy kontakt z innymi serwerami ( np awaria karty sieciowej), a storage będzie działało poprawnie?
Teoretycznie mogłoby dojść do sytuacji że nasza vm działa na 2 serwerach – ale praktycznie to się nie stanie, i o tym jest ten wpis.
Local Resource Manager i Cluster Resource Manager
Na każdym serwerze działają dwa demony odpowiedzialne za sprawdzenie poprawności działania klastra.
Pierwszy z nich – cluster resource manager (crm) odpowiada za decyzje przeniesienia zasobów na inny serwer:
Jeśli jesteś już zapisany - Kliknij "Zaloguj się" i podaj swojego maila - treść zostanie odblokowana:
Drugi – local resource manager (lrm) zarządza lokalnie serwerem, wykonuje start/stop/migracje maszyn
Jeśli więc jeden serwer przestanie działać, crm podejmuje decyzje o przeniesieniu kontenera na inny serwer i informuje o tym lrm.
Status ha możemy sprawdzić w pliku manager_status:
Ponieważ każdy serwer ma tą samą zawartość /etc/pve plik ten jest czytany przez każdy lrm i na jego podstawie są wykonywane instrukcje.
Sposób przełączania w momencie awarii.
Sprawdźmy krok po kroku co się dzieje gdy mamy awarię jednego serwera:
- srv3 uległ awarii – jego status zmienia się z “online” na “unknown” (oznacza to że crm ma problem z określeniem statusu srv3, ale nie wie czy to spowodowane jest problemem z obciążeniem, siecią czy awarią serwera). zmienia się tez timestamp
- crm zmienia status srv3 z unknown na fence, zmienia też status naszej vm100 z started na fence
- crm zmienia node dla vm100 z srv3 na srv1 i status z fence na started
Za każdym razem gdy zmienia się timestamp zmiany są wysyłane i zapisywane dla każdego lrm
Każdy lrm zapisuje je w swoim pliku:
lrm czyta plik manager_status z instrukcjami i zapisuje je do własnego katalogu i pliku.
Lrm używa zawsze takiego samego identyfikatora jak crm.
Crm odczytuje status na lrm i jeśli unikalny rekord się zgadza, wie że zadanie zostało wykonane poprawnie.
Pełna ścieżka w momencie awarii:
- W momencie braku połączenia crm z srv3 zmienia się timestamp i identyfikator
- status srv3 zmienia się na unknown
- status srv3 zmienia się na fence , to samo z vm100
- crm aktualizuje informacje by vm100 uruchomiło się na srv1
- srv1 odbiera informacje , i uruchamia serwer
- serwer działa na srv1 , każdy lrm ma identyfikator identyczny jak crm prócz srv3
- w momencie uruchomienia srv3 pobiera on status z crm i wie, że vm100 ma u niego nie działać – aktualizuje identyfikator
- crm zmienia status srv3 na online
Zapobieganie uruchomienia serwera na 2 instancjach
W pewnym przypadku (opisanym na wstępie) może wydarzyć się awaria po stronie sieci klastra.
Jeżeli crm nie będzie miał komunikacji z srv3 to po określonym czasie uruchomi naszą vm na srv1. Co jeśli problem jest tylko po stronie komunikacji z klastrem, a nasza vm poprawnie komunikuje się z storage?
Mogłoby dość do sytuacji że nasza vm czyta i zapisuje jednocześnie na 2 serwerach – srv3 ( który według crm jest uszkodzony) i srv1 na który został przepięty ruch.
Aby zapobiegać takim sytuacjom proxmox używa fencing wraz z watchdog zanim resouce manager relokuje naszą vm
Na każdym serwerze jest watchdog z timerem który aktualizuje się co 60 sekund. Gdy wszystko działa dobrze timer resetuje się co 60 sekund.
Jeżeli wystąpi jakiś problem i nasz srv3 nie może komunikować się z innymi serwerami traci on quorum. Jeśli nie może otrzymać czasu z watchdoga ma on tylko 60 sekund na ponowne uzyskanie połączenia i quorum.
Gdy to się nie uda watchdog restartuje nasz serwer – dzieje się tak dlatego iż nasz klaster nie wie co jest przyczyną problemów z srv3 a nie może być uruchomiony jeden kontener na jednocześnie 2 serwerach.
Po restarcie nasz srv3 zakłada że nasz kontener może być już uruchomiony na innym serwerze i ustawia wszystkie zasoby na off.
Nasz crm nadal nie wie jaki jest status na serwerze srv3; jednak wie że watchog dopilnował by zrestartować serwer i może bezpiecznie uruchomić usługi na innym serwerze.
Uruchomienie usług dokonuje się po minucie od czasu gdy srv3 nie jest w quorum.
Aby zobaczyć jak działa watchdog możemy wyłączyć interfejs i wpisać w konsoli:
Podsumowanie
Jest to piąta część serii o proxmoxie – jeśli dopiero trafiłeś na ten wpis polecam zapoznać się z poprzednimi:
- Instalacja proxmoxa na serwerze z systemem debian 9
- Instalacja proxmoxa z obrazu ISO
- Tworzymy klaster wysokiej dostępności
- Tworzymy nasz pierwszy serwer w HA
- HA od strony systemu – proxmox
Za tydzień przejdziemy do analizy działania ceph-a.
