LEKCJA 1 (rozszerzona)
Czym jest Failover Cluster i po co się go stosuje
Cel lekcji
Po tej lekcji kursant ma rozumieć:
-
czym naprawdę jest Windows Server Failover Clustering (WSFC)
-
jakie problemy rozwiązuje, a jakich nie
-
czym jest failover, role, zasób, węzeł
-
dlaczego bez quorum i storage klaster „nie ma sensu”
-
różnicę między: HA vs backup vs replikacja
Wysoka dostępność – co to znaczy w praktyce
Wysoka dostępność (High Availability, HA) oznacza, że usługa ma działać nawet wtedy, gdy coś się zepsuje.
Najczęstsze awarie:
-
padł serwer (hardware / VM crash)
-
system się zawiesił
-
padła usługa (np. SQL, File Server)
-
ktoś zrobił update i serwer nie wstał
HA nie oznacza braku awarii.
HA oznacza, że awaria ma jak najmniejszy wpływ na użytkowników.
Przykład:
-
Firma ma pliki na serwerze (udziały SMB).
-
Serwer się wyłącza.
-
Bez HA: użytkownicy tracą dostęp do plików na godziny.
-
Z HA: po chwili usługa startuje na drugim węźle → użytkownicy wracają do pracy.
Co to jest Failover
Failover = automatyczne przełączenie roli/usługi na inny serwer (węzeł), gdy aktualny przestaje działać.
W uproszczeniu:
-
Klaster ma węzeł A i węzeł B
-
Usługa działa na A
-
A pada
-
Klaster wykrywa problem
-
Usługa startuje na B
To przełączenie odbywa się według zasad:
-
co jest monitorowane
-
co jest krytyczne
-
jak długo czekamy
-
w jakiej kolejności uruchamiamy zasoby
Kluczowe pojęcia (muszą być jasne)
Węzeł (Node)
Serwer należący do klastra.
W praktyce:
-
fizyczny serwer (bare metal)
-
albo maszyna wirtualna
Zasób (Resource)
Najmniejszy element, który klaster potrafi kontrolować, np.:
-
adres IP
-
nazwa sieciowa (DNS/Computer Object)
-
dysk
-
usługa (np. SQL Server)
-
udział plików
Rola (Role / Clustered Role)
Zestaw zasobów, który ma działać jako „jeden serwis”.
Przykład roli File Server:
-
IP
-
Nazwa serwera plików
-
Dysk
-
Usługa File Server
Rola jest tym, co przełącza się między węzłami.
Owner Node
Węzeł, który aktualnie „posiada” rolę i na którym ona działa.
Co WSFC daje, a czego nie daje (bardzo ważne)
WSFC daje:
✅ automatyczne przełączenie usług (failover)
✅ centralne zarządzanie zasobami HA
✅ kontrolę nad dyskami wspólnymi (przejęcie, blokada dostępu)
✅ mechanizm quorum (zapobieganie split-brain)
✅ możliwość pracy na 2+ węzłach
WSFC NIE daje:
❌ backupu danych
❌ ochrony przed skasowaniem plików
❌ ochrony przed ransomware
❌ ochrony przed błędem użytkownika (np. usunięcie udziału)
❌ replikacji danych z automatu (to osobny temat)
Klaster utrzymuje dostępność, a backup chroni dane.
To są dwa różne światy.
Najprostszy model działania klastra (logika monitorowania)
Klaster „pilnuje”:
-
czy węzły żyją (heartbeat)
-
czy zasoby działają (resource health)
-
czy quorum jest spełnione (prawo do działania)
Jeśli coś siada:
-
klaster najpierw próbuje naprawić zasób
-
jak się nie uda → restart roli
-
jak się nie uda → przeniesienie roli na inny węzeł (failover)
To ważne w praktyce:
-
nie każdy błąd powoduje natychmiastowy failover
-
czasem to tylko restart usługi
Przykłady ról, które realnie klastruje się w firmach
) File Server (udziały plików)
Najprostszy i najczęstszy scenariusz.
Działa dobrze, ale wymaga wspólnego storage.
) SQL Server (Failover Cluster Instance)
Bardzo popularne w ERP (np. bazy dla systemów firmowych).
Tu storage i quorum muszą być zrobione „na tip-top”.
) DHCP (failover)
Można zrobić w klastrze, ale częściej robi się failover DHCP w samej usłudze (bez WSFC).
) Hyper-V
Klasyka: klaster Hyper-V + CSV (Cluster Shared Volumes).
Dlaczego bez wspólnego storage klaster często nie ma sensu
Failover = przenosimy rolę.
Ale rola zwykle potrzebuje danych:
-
plików
-
bazy
-
VHDX
Jeśli dane są tylko na węźle A, to po przeniesieniu na B:
-
usługa wstanie, ale nie będzie miała danych
-
albo nie wstanie wcale
Dlatego:
-
albo masz wspólny storage (SAN/iSCSI/CSV)
-
albo masz inną technologię (replika/DFS-R/replication)
To prowadzi do kolejnej lekcji: storage i quorum.
Split-brain (dlaczego quorum jest obowiązkowe)
Split-brain to sytuacja, w której:
-
oba węzły myślą, że są „główne”
-
oba próbują używać tego samego dysku/zasobu
Efekt:
-
korupcja danych
-
chaos
-
nieodwracalne błędy
Quorum ma temu zapobiegać:
klaster działa tylko wtedy, gdy ma „większość głosów”.
Przykład z życia (krótka historia do kursu)
Wyobraź sobie hotel/firmę:
-
system ERP i pliki pracują 24/7
-
jeden serwer to single point of failure
-
awaria dysku/Windows Update = przestój
Failover cluster pozwala:
-
podnieść usługę na drugim serwerze
-
skrócić przestój do minut
-
utrzymać pracę recepcji/księgowości/magazynu
Ale:
-
trzeba to dobrze zaprojektować (storage, quorum, sieci)
-
inaczej kończy się jak u Ciebie: „dysk widoczny, ale nie przyjmuje” 🙂
Sekcja „Najczęstsze błędne wyobrażenia” (do kursu)
-
„Jak mam klaster, to nie muszę robić backupu”
→ błąd. -
„Wystarczy, że podłączę dysk do dwóch serwerów”
→ błąd (PR, blokady, certyfikacja storage). -
„Jak jest iSCSI, to każdy iSCSI działa tak samo”
→ błąd (SCSI-3 PR). -
„Jak nie mam storage, to zrobię klaster i jakoś będzie”
→ zwykle nie będzie.