Podstawy

Storage w Failover Cluster – jak to działa naprawdę (SAN, iSCSI, SCSI-3 PR)

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

LEKCJA 4 (rozszerzona)

Storage w Failover Cluster – jak to działa naprawdę (SAN, iSCSI, SCSI-3 PR)


Cel lekcji

Po tej lekcji kursant:

  • rozumie dlaczego storage jest najważniejszym elementem klastra

  • wie, jakie typy storage są obsługiwane

  • rozumie pojęcie shared storage

  • zna SCSI-3 Persistent Reservations (PR) i ich znaczenie

  • rozumie, dlaczego „dysk widoczny” ≠ „dysk klastrowy”

  • potrafi odróżnić LAB od produkcji


4.1 Najważniejsza zasada klastra (fundament)

Failover Cluster NIE replikuje danych.
Klaster tylko przełącza dostęp do nich.

To oznacza:

  • dane muszą być wspólne

  • dane nie mogą być lokalne

  • klaster nie kopiuje plików między węzłami

Jeżeli dane są tylko na jednym serwerze:

  • failover uruchomi usługę

  • ale usługa nie będzie miała danych

  • albo w ogóle nie wystartuje


4.2 Co to jest shared storage (wspólny storage)

Definicja

Shared storage to:

  • ten sam fizyczny lub logiczny dysk (LUN)

  • widoczny jednocześnie przez wszystkie węzły

  • z dostępem kontrolowanym przez klaster

Przykład:

  • węzeł A widzi dysk X

  • węzeł B widzi dysk X

  • klaster decyduje, kto ma prawo zapisu


4.3 Typy storage używane w klastrach

4.3.1 SAN (klasyczne rozwiązanie produkcyjne)

  • Fibre Channel

  • iSCSI (sprzętowe SAN)

Zalety:

  • pełne wsparcie SCSI-3 PR

  • certyfikacja Microsoft

  • wysoka stabilność

Wady:

  • koszt

  • złożoność


4.3.2 iSCSI (najczęstsze w LAB i małych firmach)

  • Windows iSCSI Target

  • Linux LIO (targetcli)

  • NAS (Synology, QNAP)

Zalety:

  • tanie

  • elastyczne

  • dobre do nauki

Wady:

  • nie każdy target wspiera PR

  • łatwo o błędną konfigurację


4.3.3 Storage Spaces Direct (S2D)

  • brak zewnętrznego SAN

  • lokalne dyski + sieć

  • dane rozproszone między węzłami

Wymaga:

  • minimum 2–3 węzłów

  • bardzo dobrej sieci

  • edycji Datacenter


4.4 SCSI-3 Persistent Reservations – KLUCZ DO WSZYSTKIEGO

4.4.1 Co to jest SCSI-3 PR

To mechanizm:

  • blokowania dostępu do dysku

  • kontrolowany przez klaster

  • niezależny od systemu plików

Klaster:

  • rezerwuje dysk

  • nadaje „ownership” jednemu węzłowi

  • pozostałym węzłom odbiera prawo zapisu


4.4.2 Dlaczego bez PR klaster NIE DZIAŁA

Jeśli storage:

  • nie obsługuje PR

  • albo obsługuje je niepoprawnie

To:

  • klaster nie może zagwarantować wyłącznego dostępu

  • Windows blokuje użycie dysku

  • pojawiają się błędy:

    • No disks suitable for cluster disks

    • Cluster Disk failed

    • Authorization failure

👉 Dysk może być RAW, ONLINE i widoczny — i nadal być odrzucony.


4.5 Najczęstszy błąd (dokładnie Twój case)

„Klaster widzi dysk dopiero jak go zainicjalizuję”

To fałszywa intuicja.

Jak myśli Windows:

  • inicjalizacja = przygotowanie do użytku lokalnego

Jak myśli klaster:

  • inicjalizacja = ingerencja obcego systemu

  • klaster chce dysk RAW

Jeśli zainicjalizujesz dysk ręcznie — klaster go odrzuci.


4.6 Wymagany stan dysku PRZED dodaniem do klastra

Dysk musi być:

Cecha Stan
Partition style RAW
Partycje brak
Litera brak
Wolumin brak
Online tylko na 1 węźle
Read-Only False

4.7 EXCLUSIVE ACCESS – jeden właściciel

Kluczowa zasada

Dysk klastrowy może być ONLINE tylko na JEDNYM węźle.

Jeśli:

  • węzeł A → Online

  • węzeł B → Online

To:

  • klaster odrzuci dysk

  • bo nie ma wyłącznej kontroli

To dokładnie widziałeś w labie.


4.8 Jak klaster przejmuje dysk (co robi w tle)

Po kliknięciu Add Disk:

  1. sprawdza PR

  2. zakłada rezerwację SCSI-3

  3. ustawia ownera

  4. ustawia dysk jako:

    • Offline

    • Read-Only

  5. udostępnia go jako Available Storage

Windows poza klastrem:

  • traci kontrolę nad dyskiem


4.9 Dlaczego DiskPart nagle „przestaje działać”

Jeśli dysk ma:

  • Clustered Disk = Yes

  • IsReadOnly = True

To:

  • DiskPart NIE MA PRAWA go modyfikować

  • to ochrona przed uszkodzeniem danych

Jedyny sposób:

  • Remove from Cluster

  • dopiero potem DiskPart


4.10 LAB vs PRODUKCJA – bardzo uczciwie

LAB:

  • Linux LIO

  • plik jako backend

  • brak certyfikacji

  • możliwe problemy z PR

✔️ OK do nauki
❌ niepewne do produkcji


PRODUKCJA:

  • certyfikowany SAN

  • sprzętowe PR

  • MPIO

  • monitoring

✔️ stabilność
✔️ przewidywalność
✔️ wsparcie producenta


4.11 Najczęstsze błędy związane ze storage

  1. Inicjalizacja dysku przed klastrem

  2. Online na dwóch węzłach

  3. iSCSI bez SCSI-3 PR

  4. NAS „jakikolwiek”

  5. Testy w LAB, wdrożenie w produkcji tym samym rozwiązaniem


4.12 Jedno zdanie do zapamiętania (egzamin + życie)

Failover Cluster nie potrzebuje „gotowego” dysku.
Potrzebuje „czystego” dysku, który sam przejmie.

Notatki (opcjonalnie)