LEKCJA 10
Scenariusz hotelowy end-to-end (AD, SQL FCI, NAS, PMS/S4H)
Jak wygląda prawdziwa infrastruktura HA „po ludzku”
Cel lekcji
Po tej lekcji kursant:
-
potrafi zaprojektować całą infrastrukturę hotelową
-
rozumie dlaczego coś jest klastrem, a coś nie
-
wie gdzie HA ma sens, a gdzie nie
-
umie odpowiedzieć na pytanie: „czy macie klaster?”
-
rozumie kompromisy koszt ↔ bezpieczeństwo
To jest dokładnie ten poziom, na którym odróżnia się admin od klikacza.
10.1 Punkt wyjścia – realny hotel
Założenia (typowe):
-
300–500 pokoi
-
Recepcja 24/7
-
System PMS / S4H
-
POS, restauracja, parking
-
Brak zgody na długie przestoje
-
Budżet nie korporacyjny
Kluczowe pytanie:
Co MUSI działać zawsze, a co może poczekać?
10.2 Złota zasada architektury hotelowej
HA robimy tylko tam, gdzie przestój = paraliż operacyjny
Czyli:
-
✅ baza danych → TAK
-
❌ aplikacja kliencka → NIE
-
❌ Active Directory → NIE
-
❌ File server biurowy → raczej NIE
10.3 Minimalna sensowna architektura (bardzo ważne)
Sprzęt:
-
2 × fizyczny serwer (lub 2 VM na Proxmox)
-
1 × NAS (Synology / QNAP)
-
1 × switch (core)
-
backup (oddzielnie!)
10.4 Rola Active Directory (bez mitu)
AD:
-
1 × Domain Controller
-
DNS
-
DHCP (opcjonalnie)
❗ AD:
-
nie jest w klastrze
-
nie potrzebuje HA
-
awaria AD ≠ awaria hotelu (przez kilka godzin)
10.5 Serwery aplikacyjne (PMS / S4H)
Jak działa aplikacja:
-
uruchomiona na:
-
PC recepcji
-
serwerze aplikacyjnym
-
-
łączy się z SQL
Aplikacja:
-
❌ nie jest klastrowana
-
❌ nie jest HA
-
✅ może się po prostu ponownie połączyć
10.6 Serce systemu – SQL Server FCI
Tu jest cała magia HA.
Skład:
-
2 × Windows Server (Node1, Node2)
-
Failover Cluster
-
SQL Server Standard
-
1 × wspólny dysk iSCSI (NAS)
Efekt:
-
SQL działa zawsze na jednym nodzie
-
drugi node czeka
-
aplikacje nic nie wiedzą o awarii
10.7 NAS – do czego naprawdę służy
NAS (Synology):
-
❌ nie przechowuje bazy jako SMB
-
❌ nie „hostuje SQL”
-
✅ udostępnia:
-
iSCSI LUN (block storage)
-
File Share Witness
-
backupy
-
NAS = tani substytut SAN
10.8 Quorum w hotelu (praktyka)
Konfiguracja:
-
2 nody klastra
-
File Share Witness na NAS
Dlaczego:
-
tanio
-
stabilnie
-
oddzielone od klastra
10.9 Co się dzieje przy awarii – scenariusz
Awaria Node1:
-
SQL zatrzymuje się
-
Klaster przełącza rolę
-
SQL startuje na Node2
-
PMS traci połączenie (chwilowo)
-
PMS reconnect
⏱️ 20–60 sekund
Recepcja: „na chwilę zawisło”
👉 To jest akceptowalne HA
10.10 Co NIE jest klastrem (a ludzie mówią, że jest)
❌ „Mamy dwa serwery”
❌ „Mamy replikę VM”
❌ „Mamy NAS z RAID”
❌ „Mamy backup co godzinę”
Klaster =
automatyczne przejęcie pracy przez drugi serwer
10.11 Dlaczego 95% hoteli NIE ma HA aplikacji
Bo:
-
aplikacje PMS nie wspierają klastrów
-
koszt byłby ogromny
-
nie ma takiej potrzeby
Zamiast tego:
-
HA bazy
-
szybkie ponowne połączenie
10.12 Koszty – real talk
| Element | Koszt |
|---|---|
| Windows Server ×2 | wysoki |
| SQL Server Standard | bardzo wysoki |
| NAS | umiarkowany |
| Backup | konieczny |
Dlatego:
HA robi się tylko tam, gdzie musi
10.13 Jak odpowiadać na pytanie rekrutacyjne
❓ „Czy macie klaster?”
ZŁA odpowiedź:
„Tak, mamy dwa serwery”
DOBRA odpowiedź:
„Mamy SQL Server Failover Cluster Instance na dwóch nodach, wspólny storage iSCSI na NAS oraz File Share Witness. Aplikacje klienckie łączą się przez nazwę klastra.”
💥 To jest odpowiedź seniora
10.14 Co robisz jako administrator hotelu
Twoje zadania:
-
monitorujesz klaster
-
testujesz failover (raz na jakiś czas)
-
pilnujesz backupów
-
NIE dotykasz dysków ręcznie
-
NIE kombinujesz „bo działa”
10.15 Najważniejsze zdanie całego kursu
Klaster w hotelu istnieje po to, żeby recepcja nie przestała pracować, a nie po to, żeby było „ładnie w dokumentacji”.
Podsumowanie całego kursu (w 6 punktach)
1️⃣ Klaster ≠ backup
2️⃣ HA robimy głównie dla SQL
3️⃣ SQL Express ≠ FCI
4️⃣ Wspólny storage to podstawa
5️⃣ Quorum ratuje przed split-brain
6️⃣ Prostota > „enterprise overkill”