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:

Aby bezpłatnie odblokować dalszą treść kliknij "Zapisz się" - dostaniesz nielimitowany dostęp do wszystkich treści i wyślę Ci na maila kilka wyjątkowych bonusów !
Jeśli jesteś już zapisany - Kliknij "Zaloguj się" i podaj swojego maila - treść zostanie odblokowana:
Zaloguj się lub Zapisz się
Sprawdź Przejdź do zapisu
Anuluj
Dalsza część artykułu jest dostępna tylko dla zapisanych do newslettera. Aby zapisać się do newslettera Kliknij tutaj , lub wypełnij pola w bocznym panelu.
Jeśli jesteś już zapisany - podaj poniżej swój adres e-mail: Odblokuj
adotpay
Anuluj

Drugi – local resource manager (lrm) zarządza lokalnie serwerem, wykonuje start/stop/migracje maszyn
Aby bezpłatnie odblokować tą treść kliknij w ten przycisk i zapisz się do naszej społeczności - dostaniesz nielimitowany dostęp do wszystkich treści !

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:
Aby bezpłatnie odblokować tą treść kliknij w ten przycisk i zapisz się do naszej społeczności - dostaniesz nielimitowany dostęp do wszystkich treści !

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:

  1. 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
  2. crm zmienia status srv3 z unknown na fence, zmienia też status naszej vm100 z started na fence
  3. 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:
Aby bezpłatnie odblokować tą treść kliknij w ten przycisk i zapisz się do naszej społeczności - dostaniesz nielimitowany dostęp do wszystkich treści !

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:

  1. W momencie braku połączenia crm z srv3 zmienia się timestamp i identyfikator
  2. status srv3 zmienia się na unknown
  3. status srv3 zmienia się na fence , to samo z vm100
  4. crm aktualizuje informacje by vm100 uruchomiło się na srv1
  5. srv1 odbiera informacje , i uruchamia serwer
  6. serwer działa na srv1 , każdy lrm ma identyfikator identyczny jak crm prócz srv3
  7. w momencie uruchomienia srv3 pobiera on status z crm i wie, że vm100 ma u niego nie działać – aktualizuje identyfikator
  8. 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:
Aby bezpłatnie odblokować tą treść kliknij w ten przycisk i zapisz się do naszej społeczności - dostaniesz nielimitowany dostęp do wszystkich treści !
 

Dlatego realokacja vps-a wynosi trochę dłużej niż minutę, by zapobiegać sytuacji gdy kontener działa jednocześnie na 2 serwerach.

Podsumowanie

Jest to piąta część serii o proxmoxie – jeśli dopiero trafiłeś na ten wpis polecam zapoznać się z poprzednimi:

  1. Instalacja proxmoxa na serwerze z systemem debian 9
  2. Instalacja proxmoxa z obrazu ISO
  3. Tworzymy klaster wysokiej dostępności
  4. Tworzymy nasz pierwszy serwer w HA
  5. HA od strony systemu – proxmox

Za tydzień przejdziemy do analizy działania ceph-a.

5 (100%) Ocen: 1