Prokursy Online

Podstawy

Wymagania techniczne Failover Cluster (co MUSI być spełnione)

3 min czytania•Postęp: 55/78•Nieukończona

LEKCJA 2 (rozszerzona)

Wymagania techniczne Failover Cluster (co MUSI być spełnione)

Cel lekcji

Po tej lekcji kursant:

  • rozumie jakie warunki MUSZĄ być spełnione, żeby klaster w ogóle miał sens

  • wie, które wymagania są:

    • absolutnie obowiązkowe

    • zalecane

    • opcjonalne

  • rozumie, dlaczego klaster często „nie wstaje”, mimo że „wszystko wygląda OK”

  • potrafi odróżnić LAB od produkcji

2.1 Minimalna architektura klastra

2.1.1 Liczba serwerów (węzłów)

Minimalnie:

  • 2 węzły (node)

Dlaczego nie 1?

  • jeden serwer = brak failover

  • brak redundancji

  • brak quorum (lub quorum bez sensu)

👉 Klaster z jednym węzłem nie daje HA.

2.1.2 Typ węzłów

Węzłem może być:

  • serwer fizyczny (bare metal)

  • maszyna wirtualna (np. Proxmox, Hyper-V, VMware)

Ważne:

  • wszystkie węzły MUSZĄ być:

    • tej samej wersji Windows Server

    • w tej samej domenie AD

    • mieć zsynchronizowany czas

2.2 Wersja systemu operacyjnego

2.2.1 Wspierane systemy

  • Windows Server Standard

  • Windows Server Datacenter

❌ Windows 10 / 11:

  • NIE wspiera Failover Cluster jako węzeł produkcyjny

  • może być użyty tylko w labie (niezalecane)

2.2.2 Zasada zgodności

Wszystkie węzły:

  • ta sama edycja (Standard/Datacenter)

  • ta sama wersja (np. 2019 lub 2022)

  • te same poprawki (zalecane)

2.3 Active Directory – dlaczego jest wymagane

2.3.1 Po co klastrowi domena

Failover Cluster:

  • tworzy obiekty komputerów (CNO, VCO)

  • używa Kerberos

  • korzysta z DNS

Bez AD:

  • klaster nie działa

2.3.2 Wymagania AD

  • wszystkie węzły:

    • są członkami tej samej domeny

  • poprawnie działa:

    • DNS

    • synchronizacja czasu (NTP)

❗ Kontroler domeny nie powinien być w klastrze.

2.4 Sieć – najczęstsze źródło problemów

2.4.1 Minimalne wymagania sieciowe

  • stabilna sieć LAN

  • niskie opóźnienia

  • brak NAT między węzłami

  • pełna komunikacja TCP/UDP

Klaster jest bardzo wrażliwy na sieć.

2.4.2 Sieci logiczne klastra

Najczęściej:

  1. Publiczna – dostęp użytkowników

  2. Heartbeat / Cluster – komunikacja między węzłami

W labie:

  • może być jedna sieć
    W produkcji:

  • zalecane minimum 2

2.4.3 Heartbeat (komunikacja klastra)

Klaster:

  • wysyła „pakiety życia” (heartbeat)

  • sprawdza, czy węzły żyją

Jeśli heartbeat ginie:

  • klaster uznaje węzeł za martwy

  • uruchamia failover

👉 Zła sieć = fałszywe failovery.

2.5 Storage – bez tego klaster się rozsypie

2.5.1 Wspólny storage – definicja

Wspólny storage to:

  • TEN SAM dysk

  • widoczny przez WSZYSTKIE węzły

  • jednocześnie

  • bez lokalnych kopii

Przykłady:

  • SAN (Fibre Channel)

  • iSCSI

  • Storage Spaces Direct (S2D)

2.5.2 Najważniejsza zasada

Klaster NIE kopiuje danych między węzłami.

Jeśli nie ma wspólnego storage:

  • failover przeniesie usługę

  • ale dane zostaną na starym węźle

2.6 SCSI-3 Persistent Reservations (kluczowa technologia)

2.6.1 Co to jest

Mechanizm, który:

  • blokuje dysk przed dostępem z wielu węzłów

  • pozwala klastrowi zdecydować:

    • kto jest właścicielem

    • kto ma prawo zapisu

2.6.2 Wniosek praktyczny

Jeśli storage nie obsługuje SCSI-3 PR → klaster nie zadziała.

  • dysk RAW

  • iSCSI działa

  • ale klaster nie mógł przejąć kontroli

2.7 Quorum – warunek „prawa do życia”

2.7.1 Dlaczego quorum jest potrzebne

Quorum decyduje:

  • czy klaster ma większość

  • czy może działać

  • zapobiega split-brain

Bez quorum:

  • klaster się zatrzymuje

2.7.2 Typowe konfiguracje quorum

  • 2 węzły + File Share Witness (najczęstsze)

  • 3 węzły – Node Majority

  • większe klastry – różne kombinacje

2.8 Synchronizacja czasu (często ignorowana)

Wszystkie węzły MUSZĄ:

  • mieć zsynchronizowany czas

  • korzystać z tego samego źródła

Brak synchronizacji:

  • błędy Kerberos

  • problemy z AD

  • losowe błędy klastra

2.9 Uprawnienia i konta (o czym się zapomina)

2.9.1 Konto administratora

  • użytkownik tworzący klaster:

    • musi być Local Administrator na wszystkich węzłach

    • musi mieć prawa w AD

2.9.2 Obiekty w AD

Klaster tworzy:

  • CNO (Cluster Name Object)

  • VCO (Virtual Computer Objects)

Jeśli AD blokuje ich tworzenie:

  • klaster się nie utworzy

  • role nie wstaną

2.10 LAB vs PRODUKCJA – jasne rozróżnienie

LAB:

  • Proxmox / VirtualBox

  • Linux iSCSI

  • jeden NIC

  • brak certyfikacji

✔️ OK do nauki

PRODUKCJA:

  • certyfikowany storage

  • wiele ścieżek (MPIO)

  • monitoring

  • backup niezależny od klastra

2.11 Najczęstsze błędy na etapie wymagań

  1. „Jak się nie uda, to coś klikniemy”

  2. „Wystarczy, że dysk jest widoczny”

  3. „Każdy iSCSI działa tak samo”

  4. „Zrobimy klaster, a storage ogarniemy później”

👉 To są główne powody porażek projektów HA.

Notatki (opcjonalnie)
PoprzedniaNastępna