Podstawy

SQL Server Failover Cluster Instance (FCI) – wysoka dostępność bazy danych

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

 


LEKCJA 9

SQL Server Failover Cluster Instance (FCI) – wysoka dostępność bazy danych


Cel lekcji

Po tej lekcji kursant:

  • rozumie czym jest SQL Server FCI

  • wie czym FCI różni się od Always On

  • zna wymagania sprzętowe i systemowe

  • potrafi logicznie zaplanować instalację

  • rozumie jak FCI działa w praktyce (np. hotel)


9.1 Dlaczego w ogóle FCI?

SQL Server to:

  • serce systemów hotelowych (PMS, S4H, POS)

  • jeden punkt awarii

Bez HA:

  • padnie serwer → recepcja stoi

  • brak meldunków, płatności, raportów

FCI = SQL działa mimo awarii serwera


9.2 Czym jest SQL Server Failover Cluster Instance

SQL Server FCI to:

  • jedna instancja SQL

  • jedna baza danych

  • jeden wspólny storage

  • wiele serwerów (nodów)

Ale:

  • SQL działa zawsze tylko na jednym nodzie

  • drugi node jest w trybie standby


9.3 Co się przełącza w SQL FCI

Podczas failover:

  • instancja SQL

  • baza danych

  • adres IP

  • nazwa SQL (Virtual Network Name)

Dla aplikacji:

 
Server = SQL-CLUSTER

A nie:

 
Server = SQL01 Server = SQL02

9.4 Czego FCI NIE robi (bardzo ważne)

❌ nie replikuje danych
❌ nie daje load balancingu
❌ nie chroni przed usunięciem danych
❌ nie zastępuje backupu

FCI = HA, nie DR


9.5 Wymagania techniczne SQL FCI

1️⃣ System

  • Windows Server (2019 / 2022)

  • Failover Clustering zainstalowany

  • Nody w tej samej domenie AD


2️⃣ Storage (KLUCZOWE)

  • wspólny dysk

  • dostępny przez:

    • iSCSI

    • SAN

    • Synology (iSCSI block, NIE SMB)

❌ niedozwolone:

  • \\nas\share

  • lokalne dyski na obu serwerach


3️⃣ SQL Server

  • SQL Server Standard lub Enterprise

  • ❌ SQL Express – NIE OBSŁUGUJE FCI


9.6 Dlaczego SQL Express nie działa w klastrze

SQL Express:

  • brak FCI

  • brak agentów

  • brak HA

➡️ Do produkcji hotelowej – odpada


9.7 Schemat logiczny SQL FCI

 
[ PMS / S4H ] | v [ SQL-CLUSTER (name + IP) ] | +----+----+ | | [Node1] [Node2] | | +----[ Shared Disk ]----+

9.8 Jak działa failover SQL FCI (krok po kroku)

1️⃣ Node1 działa (SQL aktywny)
2️⃣ Node1 pada
3️⃣ Klaster wykrywa awarię
4️⃣ Dysk zostaje odłączony
5️⃣ Dysk przechodzi na Node2
6️⃣ SQL startuje na Node2
7️⃣ Klienci łączą się dalej

⏱️ Typowo: 20–60 sekund


9.9 Instalacja SQL FCI – logika (bez klikania)

Etap 1 – klaster

  • klaster działa

  • quorum OK

  • dysk klastrowy widoczny


Etap 2 – Node1

  • instalacja SQL → New SQL Failover Cluster Installation

  • wskazanie:

    • nazwy SQL

    • IP

    • dysku

    • konta usługi


Etap 3 – Node2

  • Add node to SQL Failover Cluster

  • zero nowych baz

  • tylko dołączenie


9.10 Konto usług SQL (częsty błąd)

SQL FCI wymaga:

  • domenowego konta usług

  • NIE local system

  • NIE local user

Przykład:

 
DOMAIN\sqlsvc

9.11 Najczęstsze błędy przy SQL FCI

❌ SQL Express
❌ dysk SMB
❌ dysk online na obu nodach
❌ brak SCSI-3 PR
❌ złe quorum
❌ instalacja SQL przed klastrem


9.12 SQL FCI vs Always On (egzamin / rekrutacja)

Cecha FCI Always On
Wspólny dysk
Replikacja
HA
DR
Złożoność Niska Wysoka
Koszt Wysoki Bardzo wysoki

📌 Hotele → FCI (90%)


9.13 Przykład hotelowy (konkretny)

Hotel 500 pokoi:

  • 2× Windows Server

  • SQL Server Standard

  • Synology iSCSI

  • File Share Witness

Efekt:

  • awaria jednego serwera ≠ przerwa pracy recepcji

  • koszt akceptowalny

  • rozwiązanie stabilne


9.14 Co sprawdzają na rozmowach

Pytania typu:

  • „Dlaczego nie SMB?”

  • „Czy SQL Express wystarczy?”

  • „Co się przełącza w FCI?”

  • „Czy dane się kopiują?”

Jeśli umiesz to wyjaśnić → senior-level answer


9.15 Jedno zdanie do zapamiętania

SQL FCI to jedna baza, jeden dysk, jeden SQL – ale dwa serwery gotowe na awarię.


Zadania po lekcji

  1. Dlaczego SQL Express nie nadaje się do FCI?

  2. Co musi być wspólne w SQL FCI?

  3. Czy FCI chroni przed usunięciem danych?

Notatki (opcjonalnie)