Gdy aplikacja biznesowa nie może pozwolić sobie na przestój dłuższy niż kilkadziesiąt sekund, wybór między klastrem trybu failover (FCI) a grupami dostępności Always On (AG) w SQL Server staje się decyzją architektoniczną o krytycznym znaczeniu. Obie technologie służą temu samemu celowi — eliminacji pojedynczego punktu awarii serwera bazy danych — jednak różnią się diametralnie w sposobie działania, wymaganiach sprzętowych, licencjonowaniu i scenariuszach, w których sprawdzają się najlepiej. Po dwudziestu latach ewolucji klastrowania Windows Server i dekadzie dojrzałości Always On, w roku 2026 środowisko jest wystarczająco stabilne, by móc wskazać jasne kryteria wyboru. W praktyce najczęściej wdraża się hybrydę obu rozwiązań: FCI chroni instancję na poziomie serwera, a AG replikuje bazy danych między lokalizacjami — jednak każda architektura zaczyna się od zrozumienia fundamentów.
Werdykt w skrócie: FCI czy Always On — co wybrać
Zanim zagłębimy się w szczegóły techniczne, oto tabela decyzyjna dla najczęstszych scenariuszy wdrożeniowych w 2026 roku:
| Kryterium | Klaster trybu failover (FCI) | Always On (grupy dostępności) |
|---|---|---|
| Mechanizm ochrony | Współdzielona pamięć masowa — jeden zestaw plików | Replikacja na poziomie bazy — każdy węzeł ma własną kopię |
| Czas failover | 15–45 sekund (restart usługi na drugim węźle) | 2–10 sekund (przełączenie roli na replikę) |
| Wymagana pamięć masowa | SAN, iSCSI, S2D — storage współdzielony | Każdy węzeł z własnymi dyskami — lokalny storage |
| Ochrona na poziomie | Instancji SQL Server | Pojedynczej bazy danych lub grupy baz |
| Wymagana edycja SQL Server | Standard (2 węzły) lub Enterprise (do 16 węzłów) | Enterprise (pełna funkcjonalność) lub Standard (Basic AG) |
| Windows Server Failover Cluster | Wymagany | Wymagany |
| Replika tylko do odczytu | Nie | Tak (do 8 replik pomocniczych) |
| Autonomiczna kopia zapasowa na replice | Nie (jedna kopia danych) | Tak (każda replika to osobna kopia) |
| Odległość między węzłami | Ograniczona przez latency storage (zazwyczaj to samo DC) | Dowolna — repliki w różnych miastach i chmurach |
| Licencjonowanie | SQL Server na każdym węźle (aktywny + pasywny) | Enterprise na każdym serwerze (lub Standard z Basic AG) |
Wybór sprowadza się do pytania: czy potrzebujesz ochrony na wypadek awarii sprzętu w jednej serwerowni (FCI), czy na wypadek katastrofy całego data center (Always On). W środowiskach produkcyjnych oba mechanizmy często współistnieją — FCI zapewnia wysoką dostępność lokalną, a AG odpowiada za disaster recovery między lokalizacjami.
Klaster trybu failover (FCI) — jak działa i kiedy go stosować
Klaster trybu failover (Failover Cluster Instance, FCI) to najstarsza i najbardziej dojrzała technologia wysokiej dostępności SQL Server, sięgająca korzeniami SQL Server 6.5 z 1998 roku. Mechanizm opiera się na usłudze Windows Server Failover Clustering (WSFC), która zarządza grupą serwerów (węzłów) połączonych ze współdzieloną pamięcią masową. W danym momencie tylko jeden węzeł jest aktywny i posiada wyłączny dostęp do plików bazy danych na macierzy SAN, iSCSI lub w klastrze Storage Spaces Direct. W przypadku awarii aktywnego serwera — sprzętowej, systemowej lub samej usługi SQL Server — WSFC przenosi własność dysku i adresu IP na węzeł zapasowy, uruchamia tam instancję SQL Server i odtwarza bazy danych z transakcyjnego dziennika (roll-forward recovery).
FCI działa przezroczysto dla aplikacji klienckich — łączą się one z wirtualną nazwą sieciową (VNN) lub — od SQL Server 2019 — z Distributed Network Name (DNN), która zawsze wskazuje na aktualnie aktywny węzeł. Aplikacje nie muszą wiedzieć, który fizyczny serwer obsługuje żądania. Czas failover w typowym środowisku produkcyjnym wynosi od 15 do 45 sekund: kilka sekund na wykrycie awarii przez WSFC (heartbeat co 1 sekundę, threshold domyślnie 5 utraconych odpowiedzi), kilka sekund na przeniesienie zasobów dyskowych, a reszta na restart usługi SQL Server i odtworzenie baz.
Główną zaletą FCI jest prostota administracyjna. Administrator zarządza jedną kopią danych — nie ma synchronizacji między replikami, nie ma problemu rozbieżności danych ani konfliktów. Backup wykonuje się raz, maintenance plan dotyczy jednej instancji, a zadania Agent SQL Server nie duplikują się. Wadą jest pojedynczy punkt awarii w postaci macierzy dyskowej — jeśli SAN ulegnie uszkodzeniu, żaden węzeł nie przejmie pracy. Dlatego w środowiskach o krytycznym znaczeniu macierz jest redundantna (podwójne kontrolery, wiele ścieżek FC/iSCSI), a w nowszych wdrożeniach stosuje się replikację storage na poziomie SAN między dwoma data center — jednak to już rozwiązanie wykraczające poza sam FCI.
Grupy dostępności Always On — architektura i możliwości
Always On Availability Groups (AG) to technologia wprowadzona w SQL Server 2012 i systematycznie rozwijana przez kolejne wersje — w SQL Server 2022 osiągnęła pełną dojrzałość dzięki funkcjom Contained Availability Groups, ulepszonej wydajności replikacji synchronicznej i integracji z Azure Arc. W odróżnieniu od FCI, Always On replikuje dane na poziomie pojedynczej bazy danych, wysyłając każdą zatwierdzoną transakcję z repliki głównej do maksymalnie ośmiu replik pomocniczych. Każda replika posiada własną, niezależną kopię plików bazy danych na lokalnych dyskach — nie ma współdzielonej pamięci masowej.
Sercem AG jest grupa dostępności — kontener obejmujący zestaw baz danych, które przełączają się razem jako jednostka. Replika główna przyjmuje wszystkie zapisy i odczyty; repliki pomocnicze mogą być skonfigurowane jako:
- Synchroniczne — transakcja na głównej replice zostaje zatwierdzona dopiero po potwierdzeniu zapisu na replice pomocniczej (zero utraty danych, ale wyższe opóźnienie przy zapisie).
- Asynchroniczne — replika główna nie czeka na potwierdzenie (minimalny wpływ na wydajność, ale możliwa utrata ostatnich kilku transakcji przy awarii).
Tryb synchroniczny wymaga, by replika pomocnicza znajdowała się w tej samej lokalizacji (opóźnienie sieciowe poniżej 1–2 ms w praktyce), natomiast repliki asynchroniczne mogą działać przez łącza WAN między miastami, krajami, a nawet kontynentami. To właśnie ta elastyczność sprawia, że Always On jest podstawowym mechanizmem disaster recovery w SQL Server.
Repliki pomocnicze w trybie odczytu (readable secondary) odciążają serwer główny — raporty, zapytania analityczne i zadania ETL mogą być kierowane na repliki zapasowe bez obciążania produkcji. Funkcjonalność autonomicznych kopii zapasowych (od SQL Server 2016) pozwala wykonywać backup bezpośrednio na replice pomocniczej, eliminując obciążenie serwera produkcyjnego nawet z zadań administracyjnych.
Wymagania licencyjne są jednak restrykcyjne: pełna funkcjonalność grup dostępności — repliki synchroniczne i asynchroniczne, czytelne repliki pomocnicze, automatyczny failover — wymaga SQL Server Enterprise Edition. Edycja Standard od SQL Server 2016 oferuje Basic Availability Groups, ograniczone do jednej bazy, jednej repliki i bez możliwości odczytu na replice pomocniczej. W 2026 roku ograniczenie to pozostaje kluczowym czynnikiem kosztowym — licencja Enterprise na 4 rdzenie to wydatek rzędu 58 000 PLN, podczas gdy Standard na ten sam sprzęt kosztuje około 14 500 PLN.
Porównanie techniczne: FCI vs. Always On
Poniższa tabela zestawia kluczowe parametry techniczne obu rozwiązań w kontekście wdrożeń z 2026 roku na Windows Server 2025 i SQL Server 2022:
| Parametr | FCI | Always On |
|---|---|---|
| Poziom ochrony | Instancja SQL Server (wszystkie bazy) | Pojedyncza baza lub grupa baz |
| Model replikacji | Brak replikacji — jedna kopia danych | Synchroniczna lub asynchroniczna replikacja transakcji |
| Failover automatyczny | Tak (tylko nieplanowany) | Tak (planowany i nieplanowany, max 3 repliki synchroniczne) |
| RPO (Recovery Point Objective) | 0 (brak utraty danych — jedna kopia) | 0 (synchroniczny) / kilka sekund (asynchroniczny) |
| RTO (Recovery Time Objective) | 15–45 sekund | 2–10 sekund |
| Ochrona przed awarią storage | Nie (chyba że SAN jest redundantny) | Tak (niezależny storage na każdym węźle) |
| Ochrona przed awarią całego DC | Nie (bez replikacji SAN między DC) | Tak (repliki geograficzne) |
| Koszty storage | Wysokie (SAN/FC/iSCSI) | Niskie (lokalne dyski SSD/NVMe) |
| Maksymalna liczba węzłów | 2 (Standard) / 16 (Enterprise) | 1 główna + 8 pomocniczych (Enterprise) |
| TempDB na dysku lokalnym | Tak (od SQL Server 2012) | Tak (domyślnie) |
| Listener | VNN lub DNN | Availability Group Listener (VNN lub DNN) |
| Wsparcie dla SQL Server Reporting Services | Pełne | Ograniczone (wymaga konfiguracji) |
| Wsparcie dla SQL Server Agent | Pełne (jedna instancja) | Ograniczone (zadania wymagają logiki świadomej AG) |
Różnica w czasie failover jest znacząca — Always On przełącza się 3 do 4 razy szybciej niż FCI, ponieważ nie musi montować dysków ani uruchamiać całej instancji SQL Server, a jedynie zmienić rolę repliki z pomocniczej na główną. W praktyce wpływa to na aplikacje z krótkim timeoutem połączeń — przy FCI klient może potrzebować logiki ponawiania (retry), podczas gdy przy AG często nawet nie zauważy przerwy.
Z drugiej strony FCI chroni Systemowe bazy danych — master, model, msdb — automatycznie, ponieważ są one częścią instancji. Always On replikuje wyłącznie bazy użytkownika dodane do grupy dostępności; loginy, zadania Agent SQL Server, pakiety SSIS i konfiguracja na poziomie serwera muszą być replikowane ręcznie lub przez skrypty automatyzujące.
Scenariusze wdrożeniowe: kiedy FCI, kiedy Always On, a kiedy oba
Wybór architektury zależy od trzech czynników: budżetu licencyjnego, topologii infrastruktury i poziomu krytyczności biznesowej aplikacji. Poniżej cztery najczęstsze scenariusze spotykane w polskich firmach w 2026 roku.
Serwer produkcyjny z ograniczonym budżetem — FCI na SQL Server Standard
Firma posiada dwa serwery fizyczne, macierz SAN i licencję SQL Server Standard. Cel: ochrona przed awarią sprzętu i możliwość serwisowania serwerów bez przestoju. FCI z 2 węzłami na licencji Standard to rozwiązanie optymalne — zapewnia automatyczny failover, nie wymaga Enterprise i wykorzystuje istniejącą infrastrukturę SAN. Backup nadal musi być realizowany osobno (najlepiej na NAS lub do chmury), ponieważ awaria SAN wyłącza cały klaster.
Aplikacja krytyczna z kopią zapasową off-site — Always On Enterprise
Organizacja z oddziałami w dwóch miastach, każde z własną serwerownią i łączem światłowodowym 10 Gbps. Wymagana jest zarówno wysoka dostępność lokalna, jak i ochrona przed katastrofą całego obiektu. Architektura: dwa węzły w data center A (replika główna + synchroniczna), jeden węzeł w data center B (replika asynchroniczna). Failover automatyczny w obrębie DC A (czas przełączenia 2–3 sekundy), failover ręczny między miastami w przypadku pożaru lub powodzi. Backup realizowany wyłącznie na replice asynchronicznej, bez obciążania produkcji.
Najwyższy poziom dostępności — FCI + Always On (architektura hybrydowa)
System ERP obsługujący 3000 użytkowników, tolerancja przestoju praktycznie zerowa. Architektura łącząca obie technologie:
- Lokalnie: dwa węzły w FCI ze współdzielonym storage na macierzy all-flash. FCI chroni przed awarią pojedynczego serwera (sprzęt, aktualizacje Windows, reboot).
- Geograficznie: grupa dostępności Always On między FCI w DC A a FCI w DC B. Chroni przed awarią całego data center.
W tym wariancie AG operuje na instancjach FCI jako replikach — technologia ta, nazywana Always On Failover Cluster Instance (FCI) jako replika, jest w pełni wspierana od SQL Server 2012 i pozostaje złotym standardem w sektorze bankowym i telekomunikacyjnym.
Small business na jednym serwerze — Basic Availability Groups
Jednoosobowa działalność gospodarcza lub mały startup z jednym serwerem i budżetem na dwie licencje Standard. SQL Server 2022 Standard z Basic AG pozwala utworzyć grupę dostępności z jedną repliką pomocniczą — bez odczytu na replice, ale z automatycznym failoverem. To najtańsza ścieżka do wysokiej dostępności, kosztująca około 3 000 PLN za dwie licencje Standard (po 4 rdzenie każda) zamiast 116 000 PLN za dwie licencje Enterprise.
Pułapki konfiguracyjne i najczęstsze błędy
Wieloletnie doświadczenia wdrożeniowe w polskich firmach ujawniają powtarzające się błędy, które dyskwalifikują starannie zaprojektowaną architekturę HA/DR przy pierwszym prawdziwym incydencie.
Quorum i split-brain w klastrze WSFC. Zarówno FCI, jak i Always On bazują na Windows Server Failover Cluster, który do poprawnego działania wymaga mechanizmu quorum — świadka (witness) rozstrzygającego, która część klastra ma rację w przypadku utraty komunikacji między węzłami. Najczęstszym błędem jest skonfigurowanie świadka na tym samym storage co dane — awaria SAN wyłącza quorum i zatrzymuje cały klaster. Świadek powinien znajdować się na niezależnym udziale plikowym (File Share Witness) na trzecim serwerze, w chmurze (Cloud Witness na Azure) lub na dysku niezależnym od głównej macierzy.
Listener AG bez poprawnie skonfigurowanego DNS. Availability Group Listener wymaga rekordu DNS i obiektu komputera w Active Directory. Jeśli listener nie odpowiada na ping, 99% przypadków to brak uprawnień konta klastra do utworzenia obiektu komputera w OU (Organizational Unit) AD lub konflikt z istniejącym rekordem DNS o tej samej nazwie. Problem często ujawnia się dopiero przy teście failover, gdy administrator odkrywa, że aplikacje nie mogą się połączyć z nową repliką główną.
Synchronizacja logowań i zadań Agent między replikami AG. Always On replikuje bazy użytkownika, ale nie replikuje loginów SQL Server, ról serwerowych, zadań Agent, operatorów ani pakietów SSIS. Po failoverze użytkownicy nie mogą się zalogować, ponieważ ich konta (SID-y) istnieją w bazie, ale nie na poziomie instancji. Rozwiązaniem jest skrypt PowerShell (Copy-DbaLogin z modułu dbatools) uruchamiany cyklicznie lub po każdej zmianie, albo przechowywanie loginów w contained database (baza częściowo autonomiczna) od SQL Server 2012.
Nieprzetestowany failover. Ponad połowa zgłoszeń serwisowych po awariach produkcyjnych dotyczy środowisk, w których failover nigdy nie został przetestowany na produkcji ani nawet na środowisku testowym o identycznej konfiguracji. Wykonanie ALTER AVAILABILITY GROUP [nazwa] FAILOVER na produkcji bez wcześniejszego testu na stagingu to proszenie się o incydent — zwłaszcza gdy aplikacje mają zahardkodowane connection stringi wskazujące na konkretny serwer zamiast na listener AG.
Brak monitoringu stanu synchronizacji. AG działa poprawnie do momentu, gdy nie działa — a jedynym sygnałem, że replika jest zsynchronizowana, jest regularny monitoring DMV sys.dm_hadr_availability_replica_states. Administratorzy, którzy nie skonfigurowali alertów na stan NOT SYNCHRONIZING lub SYNCHRONIZING (zamiast SYNCHRONIZED), dowiadują się o problemie dopiero przy awarii repliki głównej — gdy okazuje się, że replika zapasowa jest opóźniona o 3 godziny i dane zostały bezpowrotnie utracone.
Licencjonowanie SQL Server w kontekście FCI i Always On
Licencjonowanie SQL Server 2022 dla scenariuszy wysokiej dostępności to jeden z najczęściej błędnie rozumianych aspektów planowania architektury. Kluczowe reguły obowiązujące w 2026 roku:
-
FCI z licencją pasywną: licencja Standard pozwala na klaster dwuwęzłowy — jeden węzeł aktywny, drugi pasywny. Przy więcej niż 2 węzłach wymagany jest Enterprise. Węzeł pasywny nie potrzebuje osobnej licencji, o ile nie obsługuje ruchu produkcyjnego — warunkiem jest, by nie przyjmował zapytań i nie wykonywał operacji wykraczających poza utrzymanie roli pasywnej (dozwolone: synchronizacja, backup kopii, DBCC CHECKDB).
-
Always On z replikami pomocniczymi: każdy serwer z instancją SQL Server, który przyjmuje zapytania — w tym zapytania tylko do odczytu na replice pomocniczej — wymaga pełnej licencji. Jeśli replika pomocnicza jest nieaktywna (nieczytelna) i służy wyłącznie jako zapasowa, może korzystać z licencji pasywnej na tych samych zasadach co FCI. W praktyce każda czytelna replika pomocnicza to dodatkowy koszt pełnej licencji Enterprise.
-
Edycja Standard a Basic AG: od SQL Server 2016 Standard oferuje Basic Availability Groups — limitowane do jednej bazy danych, jednej repliki (synchronicznej lub asynchronicznej), bez możliwości odczytu na replice pomocniczej i bez backupu na replice. Dla małych środowisk z pojedynczą krytyczną bazą (np. systemem ERP na jednej bazie) jest to wystarczające i dramatycznie tańsze od Enterprise.
-
Licencje na rdzeń (core-based): od SQL Server 2012 Microsoft sprzedaje licencje w pakietach po 2 rdzenie. Serwer 16-rdzeniowy wymaga 8 pakietów — zarówno dla Standard, jak i Enterprise. Cena rynkowa pakietu 2-rdzeniowego SQL Server 2022 Standard w Polsce to około 3 600 PLN netto, Enterprise — około 14 500 PLN netto. Dla serwera 16-rdzeniowego daje to odpowiednio 28 800 PLN (Standard) i 116 000 PLN (Enterprise) za jedną instancję.
Wybór licencji jest więc decyzją strategiczną podejmowaną przed wyborem architektury HA — zwłaszcza że migracja z FCI na Standardzie do AG na Enterprise po fakcie wymaga zakupu nowych licencji.
Windows Server 2025 i SQL Server 2022 — stan technologii w 2026 roku
Aktualny krajobraz technologiczny w połowie 2026 roku przedstawia się następująco. Windows Server 2025 (wydany jesienią 2024) to standardowa platforma dla nowych wdrożeń — wprowadza Storage Spaces Direct z szyfrowaniem end-to-end, ulepszone klastrowanie z Cloud Witness natywnie w Azure, oraz szybszy failover WSFC dzięki zoptymalizowanemu heartbeatowi. Wszystkie funkcje FCI i Always On działają na Windows Server 2025 bez zastrzeżeń, a Microsoft zadeklarował wsparcie główne do października 2029 roku.
SQL Server 2022 (wydany w listopadzie 2022, build 16.0.x) jest aktualną wersją produkcyjną i pozostanie nią do premiery następcy — plotki o SQL Server 2025 na razie się nie potwierdziły, a roadmapa Microsoftu na 2026 rok koncentruje się na rozwoju Azure SQL i integracji Copilot. SQL Server 2022 z najnowszym CU (Cumulative Update 15, luty 2026) wprowadza kluczowe usprawnienia dla Always On: Contained Availability Groups eliminują konieczność ręcznej synchronizacji obiektów na poziomie instancji, a ulepszona replikacja synchroniczna redukuje narzut latency o 25% względem SQL Server 2019. Funkcja Link do Azure SQL Managed Instance pozwala na utrzymanie repliki Always On bezpośrednio w chmurze Azure bez dodatkowych serwerów fizycznych.
W kontekście FCI, SQL Server 2022 kontynuuje wsparcie dla Distributed Network Name (DNN) jako alternatywy dla VNN — DNN nie wymaga tworzenia obiektu komputera w Active Directory, co upraszcza wdrożenie w środowiskach bez dedykowanego OU dla klastra lub z ograniczonymi uprawnieniami administratora domeny.
Częste pytania
Czym się różni klaster trybu failover (FCI) od Always On Availability Groups?
FCI chroni całą instancję SQL Server przy użyciu współdzielonej pamięci masowej — wszystkie bazy danych instancji przełączają się razem na węzeł zapasowy. Always On chroni pojedyncze bazy danych przez replikację transakcji między niezależnymi serwerami, z których każdy ma własną kopię plików. FCI eliminuje pojedynczy punkt awarii serwera; Always On eliminuje również pojedynczy punkt awarii storage.
Czy Always On wymaga Windows Server Failover Cluster?
Tak. Zarówno FCI, jak i Always On bazują na usłudze WSFC. Always On nie może istnieć bez klastra — nawet jeśli dane są replikowane między serwerami, mechanizm failover i quorum dostarczany jest przez WSFC.
Czy mogę użyć Always On z SQL Server Standard?
Tak, ale w ograniczonej formie Basic Availability Groups: jedna baza danych, jedna replika, bez możliwości odczytu na replice, bez backupu na replice. Pełna funkcjonalność AG z wieloma replikami i czytelnymi replikami pomocniczymi wymaga Enterprise.
Ile replik Always On mogę mieć?
Maksymalnie 8 replik pomocniczych plus 1 replika główna — razem 9 replik w jednej grupie dostępności (SQL Server Enterprise). Dodatkowo, od SQL Server 2016 można tworzyć Distributed Availability Groups łączące wiele grup dostępności — teoretycznie bez limitu replik łącznie.
Czy przy FCI węzeł pasywny potrzebuje osobnej licencji SQL Server?
Nie, o ile węzeł pasywny nie obsługuje ruchu produkcyjnego. Warunek: liczba rdzeni na węźle pasywnym nie może przekraczać liczby rdzeni na węźle aktywnym, a failover nie może trwać dłużej niż 30 dni w roku (tzw. zasada Software Assurance). W praktyce oznacza to, że klaster dwuwęzłowy na SQL Server Standard wymaga jednej licencji.
Co się stanie z transakcjami w locie podczas failover Always On?
W trybie synchronicznym: transakcje zatwierdzone na replice głównej są już utrwalone na replice pomocniczej — utrata danych wynosi zero. Transakcje niezakończone (in-flight) są automatycznie wycofywane (rollback) i aplikacja musi je ponowić. W trybie asynchronicznym: transakcje wysłane, ale jeszcze niepotwierdzone, mogą zostać utracone — dotyczy to zazwyczaj ostatnich 1–5 sekund aktywności.
Czy mogę wykonywać backup na replice pomocniczej Always On?
Tak, od SQL Server 2016 (Enterprise Edition). Backup na replice pomocniczej odciąża serwer produkcyjny i jest szczególnie użyteczny w środowiskach 24/7, gdzie okno backupowe na głównej instancji jest krótkie. W SQL Server 2022 dodano możliwość backupu do Azure Blob Storage bezpośrednio z repliki pomocniczej.
Czy FCI działa na Azure?
Tak, Azure oferuje natywny mechanizm FCI przez Azure Shared Disks (dyski Ultra SSD i Premium SSD v2 współdzielone między maszynami wirtualnymi) oraz przez Storage Spaces Direct na Azure Stack HCI. Always On również działa na maszynach wirtualnych Azure, a dodatkowo Azure SQL Managed Instance oferuje wbudowane grupy dostępności bez konieczności ręcznej konfiguracji WSFC.
Jaka jest różnica w cenie między licencją Enterprise a Standard przy wdrożeniu Always On?
Dla serwera 16-rdzeniowego: SQL Server 2022 Standard kosztuje około 28 800 PLN netto, Enterprise około 116 000 PLN netto — różnica wynosi 87 200 PLN. Przy dwóch serwerach (główny + replika) różnica rośnie do 174 400 PLN. To główny powód, dla którego małe i średnie firmy wybierają FCI na Standardzie zamiast Always On.
Czy mogę połączyć FCI z Always On?
Tak i jest to zalecana architektura dla środowisk o najwyższych wymaganiach dostępności. Każda replika grupy dostępności może być instancją klastra failover (FCI). Przykład: FCI w Warszawie (2 węzły) jako replika główna AG, FCI w Krakowie (2 węzły) jako replika pomocnicza. Chroni to zarówno przed awarią pojedynczego serwera (FCI), jak i awarią całego data center (AG).
Gdzie kupić legalną licencję SQL Server 2022 do wdrożenia FCI lub Always On?
Legalne klucze do SQL Server 2022 Standard i Enterprise, wraz z niezbędnymi licencjami Windows Server 2025, dostępne są w ofercie KluczeSoft.pl — z dostawą w kilka minut, fakturą VAT 23% i wsparciem technicznym przy wyborze odpowiedniej edycji do planowanej architektury wysokiej dostępności.