Podstawy

Failover ról i testy awarii – jak sprawdzić, czy klaster naprawdę działa

3 min czytaniaPostęp: 61/78Nieukończona

LEKCJA 8

Failover ról i testy awarii – jak sprawdzić, czy klaster naprawdę działa


Cel lekcji

Po tej lekcji kursant:

  • rozumie czym jest rola w klastrze

  • wie co dokładnie się przełącza podczas failover

  • potrafi ręcznie wywołać failover

  • umie wykonać test awarii bez uszkodzenia danych

  • rozumie co sprawdzać po przełączeniu


8.1 Co to jest „rola” w Failover Cluster

W klastrze NIE przełączamy serwera.
Przełączamy ROLĘ (ROLE).

Rola może zawierać:

  • nazwę sieciową (Cluster Name)

  • adres IP

  • dysk / dyski klastrowe

  • usługę (np. SQL, File Server)

  • aplikację

📌 Failover = przeniesienie roli na inny node


8.2 Co NIE jest rolą (ważne!)

❌ system Windows
❌ Active Directory
❌ Hypervisor (Proxmox / ESXi)
❌ aplikacja bez wsparcia HA

Klaster nie ratuje wszystkiego – tylko to, co jest rolą.


8.3 Przykład roli (bardzo ważny)

Rola: File Server

Składa się z:

  • Name: FS-CLUSTER

  • IP: 192.168.1.100

  • Disk: Cluster Disk 1

  • Service: File Server

Dla użytkownika:

„Zawsze łączę się z \FS-CLUSTER”

Nie obchodzi go:

  • który node działa

  • czy nastąpił failover


8.4 Co się dzieje podczas failover (krok po kroku)

1️⃣ Klaster wykrywa problem
2️⃣ Rola jest Offline
3️⃣ Dysk zostaje odmontowany z Node A
4️⃣ SCSI-3 PR przenosi własność
5️⃣ Dysk montuje się na Node B
6️⃣ Usługa startuje na Node B
7️⃣ IP i nazwa sieciowa migrują

⏱️ Czas:

  • File Server: kilka sekund

  • SQL: kilkanaście–kilkadziesiąt sekund


8.5 Rodzaje failover

🔹 Automatyczny

  • node padł

  • sieć padła

  • usługa przestała odpowiadać

👉 klaster sam przenosi rolę


🔹 Ręczny (kontrolowany)

  • administrator wywołuje przełączenie

  • używany do:

    • testów

    • prac serwisowych

    • aktualizacji


8.6 Ręczny failover – krok po kroku

KROK 1

Failover Cluster Manager → Roles

KROK 2

Prawy klik na rolę → Move → Select Node

KROK 3

Wybierz drugi node

KROK 4

Obserwuj:

  • Status → Moving → Online

  • Owner Node → zmiana

✅ Jeśli wróci Online → failover działa


8.7 Co MUSI się zmienić po failover

Sprawdź zawsze:

Element Co sprawdzić
Owner Node zmienił się
Disk Online tylko na nowym nodzie
IP przypisane do nowego noda
Usługa uruchomiona
Event Log brak błędów

8.8 Test awarii – bezpieczny sposób (LAB / PRODUKCJA)

✅ Poprawne metody testu:

  • Stop-Service (np. SQL)

  • Pause Node

  • Shutdown node (kontrolowany)

  • Restart VM

❌ Złe metody:

  • pull power cable

  • kill -9

  • reset storage

  • „a zobaczymy co się stanie”


8.9 Test: zatrzymanie noda (najlepszy)

1️⃣ Failover Cluster Manager
2️⃣ Nodes → Prawy klik → Pause → Drain Roles
3️⃣ Role migrują
4️⃣ Node bezpieczny do restartu

📌 To jest procedura produkcyjna.


8.10 Test: symulacja awarii (egzamin / LAB)

  • Wyłącz VM Node1

  • Obserwuj:

    • po ilu sekundach role przechodzą

    • czy wracają Online

Jeśli:

  • rola przejdzie → OK

  • rola się nie podniesie → ❌


8.11 Najczęstsze problemy przy failover

❌ Dysk Online na dwóch nodach
❌ Brak quorum
❌ Usługa startuje zbyt długo
❌ Aplikacja nie wspiera HA
❌ Zły witness


8.12 Failover a dane – kluczowa zasada

Failover NIE jest backupem

Failover:

  • chroni przed awarią serwera

  • NIE chroni przed:

    • usunięciem plików

    • ransomware

    • błędem użytkownika

Backup jest nadal obowiązkowy.


8.13 Przykład hotelowy (konkret)

Recepcja:

  • aplikacja PMS

  • baza SQL w klastrze

Node1 pada:

  • failover 20–30 s

  • aplikacja traci połączenie

  • po chwili wraca

Recepcjonista:

„na chwilę zawiesiło, potem działa”

To jest dobrze działający klaster.


8.14 Jedno zdanie do zapamiętania

Failover przełącza rolę, nie serwer.
Testy robimy ręcznie, zanim zrobi je życie.


Zadania po lekcji

  1. Czym jest rola w klastrze?

  2. Co dokładnie migruje podczas failover?

  3. Jaki jest najbezpieczniejszy sposób testu awarii?

Notatki (opcjonalnie)