Always On Availability Groups zwiększa dostępność baz danych Microsoft SQL Server, ograniczając ryzyko przestoju w razie awarii.

Na czym polega ta usługa

Usługa obejmuje skonfigurowanie Always On Availability Groups w Microsoft SQL Server oraz przetestowanie mechanizmu przełączania.

Dla kogo ma sens

Usługa jest przydatna dla firm korzystających z Microsoft SQL Server, którym zależy na wysokiej dostępności baz danych.

Ile to trwa

Konfiguracja mieści się z reguły w standardowym czasie do 3 dni.

Warunki

Diagnoza wstępna i wycena są bezpłatne, a usługa objęta jest gwarancją do 12 miesięcy.

Architektura i wymagania wstępne rozwiązania Always On

Wdrożenie Always On Availability Groups (grup dostępności Always On – zaawansowanego rozwiązania wysokiej dostępności i odzyskiwania po awarii w Microsoft SQL Server) wymaga odpowiednio przygotowanej infrastruktury systemowej oraz sieciowej. Podstawą działania mechanizmu jest usługa WSFC (Windows Server Failover Clustering – klaster trybu pracy awaryjnej w systemie operacyjnym Windows Server). SQL Server wykorzystuje strukturę klastra Windows do monitorowania stanu węzłów oraz sterowania procesem przełączania ról, chociaż same bazy danych nie wymagają instalacji instancji klastrowej ani współdzielonej przestrzeni dyskowej.

Kluczowym elementem stabilnej architektury jest poprawna konfiguracja mechanizmu kworum (quorum – algorytmu większościowego decydującego o tym, które węzły mają prawo utrzymać działanie klastra w razie awarii komunikacji). W przypadku klastrów o parzystej liczbie serwerów konieczne jest wdrożenie świadka kworum, takiego jak File Share Witness (świadek udziału plikowego na osobnym serwerze sieciowym) lub Cloud Witness (świadek w chmurze obliczeniowej). Zapobiega to sytuacji, w której utrata łączności między dwoma węzłami unieruchamia całe środowisko bazodanowe.

Na poziomie sieciowym niezbędne jest zapewnienie dedykowanych interfejsów sieciowych do obsługi ruchu replikacyjnego (strumienia przesyłania bloków dziennika transakcji między serwerami). Niskie opóźnienia sieciowe oraz odpowiednia przepustowość łączy mają bezpośredni wpływ na wydajność zapisu transakcji w bazach produkcyjnych. Konfiguracja obejmuje także przygotowanie domenowych kont serwisowych w Active Directory (usłudze katalogowej przedsiębiorstwa), rejestrację rekordów SPN (Service Principal Name – identyfikatorów usług w protokole Kerberos) oraz właściwe reguły na zaporach sieciowych dla portów komunikacyjnych SQL Server.

Tryby replikacji i warianty przełączania awaryjnego

Grupy dostępności Microsoft SQL Server mogą pracować w dwóch głównych trybach synchronizacji danych, dobieranych w zależności od wymagań biznesowych dotyczących ochrony danych i dopuszczalnych opóźnień:

Tryb synchroniczny (synchronous-commit mode – tryb zatwierdzania synchronicznego): transakcja na serwerze podstawowym zostaje potwierdzona dopiero po odebraniu informacji o zapisaniu bloku dziennika transakcji na serwerze pomocniczym. Gwarantuje to zerowy wskaźnik RPO (Recovery Point Objective – brak utraty jakichkolwiek zatwierdzonych danych w razie awarii) i umożliwia wdrożenie automatycznego przełączania awaryjnego (automatic failover).
Tryb asynchroniczny (asynchronous-commit mode – tryb zatwierdzania asynchronicznego): serwer podstawowy potwierdza transakcje bez oczekiwania na odpowiedź od serwera pomocniczego. Rozwiązanie to eliminuje wpływ opóźnień sieciowych na wydajność aplikacji, co czyni je optymalnym wyborem dla replikacji geograficznej do odległych serwerowni w ramach planu Disaster Recovery (odzyskiwania po katastrofie).

W typowej architekturze korporacyjnej wdraża się model mieszany. Dwa lokalne serwery pracują w trybie synchronicznym z automatycznym przełączaniem awaryjnym w celu ochrony przed lokalną awarią sprzętu, natomiast trzeci węzeł w zdalnej lokalizacji odbiera dane asynchronicznie, zabezpieczając ciągłość działania firmy na wypadek awarii całego głównego budynku.

Konfiguracja nasłuchiwacza i kierowanie ruchu tylko do odczytu

Centralnym punktem dostępowym dla systemów korzystających z bazy danych jest Availability Group Listener (nasłuchiwacz grupy dostępności – wirtualna nazwa sieciowa z przypisanym unikalnym adresem IP). Dzięki nasłuchiwaczowi aplikacje łączą się zawsze pod jeden stały adres, niezależnie od tego, który serwer fizyczny pełni w danej chwili rolę węzła podstawowego (primary replica). W momencie wystąpienia awarii i przełączenia ról następuje automatyczne przekierowanie ruchu sieciowego bez konieczności modyfikowania ciągów połączeniowych (connection strings) w konfiguracji programów.

Technologia Always On umożliwia również uruchomienie mechanizmu read-only routing (kierowania zapytań tylko do odczytu). Pozwala to na wykorzystanie węzłów pomocniczych (secondary replicas) do obsługi ciężkich zapytań analitycznych, generowania raportów, zestawień księgowych czy zrzutów magazynowych. Aplikacja zgłaszająca chęć odczytu danych zostaje automatycznie skierowana przez nasłuchiwacz na serwer pomocniczy, co całkowicie odciąża główną bazę transakcyjną i zapobiega blokowaniu bieżącej pracy użytkowników.

Integracja z oprogramowaniem biznesowym i systemami ERP

Wdrożenie Always On Availability Groups znajduje zastosowanie w środowiskach obsługujących krytyczne systemy zarządzania przedsiębiorstwem, w tym Comarch ERP (Optima, XL, Altum), InsERT (linie nexo oraz GT, w tym Subiekt i Rewizor), WAPRO ERP (Mag, Fakir, Gang), Symfonia, enova365 czy RAKS SQL. Wdrożenie wymaga uwzględnienia specyfiki tych aplikacji oraz obiektów znajdujących się poza samymi bazami danych użytkownika.

Podczas uruchamiania klastra konieczne jest przeprowadzenie synchronizacji elementów instancji serwera, które nie podlegają automatycznej replikacji w ramach Always On. Należą do nich:

Konta logowania i uprawnienia użytkowników na poziomie serwera (server-level logins): wymagają przeniesienia wraz z zachowaniem identyfikatorów bezpieczeństwa SID (Security Identifier), aby po przełączeniu awaryjnym użytkownicy nie utracili dostępu do baz.
Harmonogramy i zadania agenta (SQL Server Agent Jobs): skrypty konserwacji, przeliczania stanów magazynowych oraz integracji zewnętrznych muszą istnieć na wszystkich węzłach i zawierać warunek sprawdzający, czy dany serwer jest aktualnie instancją nadrzędną.
Poświadczenia i klucze szyfrowania (credentials oraz master keys): niezbędne do prawidłowego działania połączeń szyfrowanych, integracji z usługami sieciowymi oraz zewnętrznymi bazami danych.
Pakiety integracyjne SSIS (SQL Server Integration Services) oraz powiązane bazy pomocnicze.

Typowe błędy i zagrożenia przy samodzielnej konfiguracji

Nieprawidłowo przeprowadzone wdrożenie grup dostępności może prowadzić do przestojów w pracy firmy lub pozornego poczucia bezpieczeństwa. Do najczęściej spotykanych błędów należą:

Brak świadka kworum w klastrze dwuwęzłowym: w razie utraty komunikacji między serwerami oba węzły tracą większość głosów i klaster ulega automatycznemu zatrzymaniu, co unieruchamia całą bazę danych.
Zjawisko split-brain (rozszczepienie klastra): sytuacja, w której w wyniku wadliwej konfiguracji sieciowej i mechanizmu głosowania dwa odizolowane serwery uznają się jednocześnie za węzły podstawowe, co prowadzi do rozbieżności danych i uszkodzenia spójności bazy.
Przepełnienie dysków przez niekontrolowany wzrost dziennika transakcji (transaction log): w Always On dziennik transakcji nie może zostać obcięty, dopóki wszystkie synchroniczne i asynchroniczne repliki nie odbiorą zmian. Brak monitorowania stanu replikacji lub awaria węzła zapasowego może doprowadzić do zapełnienia całej przestrzeni dyskowej serwera głównego.
Zaniechanie okresowych testów przełączania awaryjnego (failover drills): środowisko niesprawdzane pod kątem rzeczywistej awarii może zawieść w krytycznym momencie z powodu nieaktualnych uprawnień, błędów w rekordach DNS lub nieobsługiwanych parametrów połączenia w starszych wersjach oprogramowania klienckiego.
Niewłaściwa konfiguracja bazy tempdb (bazy tymczasowej): umieszczenie tempdb na wolnych nośnikach na którymkolwiek z węzłów powoduje drastyczny spadek wydajności całego systemu po przełączeniu roli głównej na ten serwer.

Kiedy grupy dostępności to za dużo – porównanie z innymi technologiami

Always On Availability Groups to zaawansowane rozwiązanie, które nie w każdym scenariuszu jest optymalnym wyborem pod względem kosztów licencyjnych i złożoności administracyjnej. W zależności od profilu działalności firmy stosuje się także inne mechanizmy:

Failover Cluster Instances (FCI – instancje klastra trybu failover): chronią całą instancję SQL Server wraz ze wszystkimi bazami systemowymi i zadaniami agenta, jednak wymagają współdzielonej pamięci masowej (macierzy SAN lub iSCSI), która sama w sobie może stanowić pojedynczy punkt awarii (single point of failure).

Log Shipping (wysyłanie dziennika transakcji): prosty, ekonomiczny mechanizm polegający na cyklicznym tworzeniu kopii dziennika na serwerze głównym, przesyłaniu go przez sieć i odtwarzaniu na serwerze zapasowym. Charakteryzuje się opóźnieniem zależnym od harmonogramu (z reguły od kilkunastu minut do godziny) oraz wymaga ręcznego przełączenia aplikacji, jednak doskonale sprawdza się jako tania kopia zapasowa do celów Disaster Recovery na tańszych licencjach SQL Server Standard.

Replikacja transakcyjna (Transactional Replication): stosowana głównie do selektywnego przesyłania wybranych tabel i obiektów między różnymi bazami danych, np. w celu zasilania sklepów internetowych lub zewnętrznych platform wymiany danych B2B, a nie jako pełny mechanizm wysokiej dostępności całej bazy.

Należy pamiętać, że żadna technologia replikacji wysokiej dostępności nie zastępuje regularnych kopii zapasowych (backupów pełnych, różnicowych i dziennika transakcji). Błąd ludzki, przypadkowe usunięcie danych czy uszkodzenie logiczne struktury bazy zostają natychmiast zreplikowane na wszystkie węzły klastra Always On, a jedyną metodą ratunku pozostaje wówczas odtworzenie danych z niezależnego archiwum.

Metodyka wdrożenia i scenariusze testowe w środowisku produkcyjnym

Proces wdrożenia Always On Availability Groups realizowany jest według ściśle określonych etapów w celu wyeliminowania ryzyka przestoju produkcyjnego:

Audyt wstępny infrastruktury: weryfikacja parametrów serwerów, wersji systemów operacyjnych Windows Server, edycji Microsoft SQL Server, topologii sieci LAN/WAN oraz polityk domeny Active Directory.
Przygotowanie klastra WSFC i konfiguracja kworum: instalacja funkcji klastrowania na serwerach, utworzenie klastra bazowego oraz konfiguracja odpowiedniego świadka udziału sieciowego.
Konfiguracja instancji SQL Server: włączenie funkcji Always On w menedżerze konfiguracji SQL Server (SQL Server Configuration Manager), przygotowanie punktów końcowych dublowania baz danych (database mirroring endpoints) oraz właściwych certyfikatów zabezpieczających ruch sieciowy.
Inicjalizacja grupy dostępności: utworzenie grupy, dodanie baz danych, wykonanie pełnej kopii zapasowej inicjującej i synchronizacja stanu początkowego na serwerach pomocniczych.
Wdrożenie nasłuchiwacza i reguł trasowania: przypisanie adresu IP, konfiguracja rekordów DNS oraz parametrów read-only routing dla połączeń raportowych.
Synchronizacja zadań pomocniczych: sklonowanie kont logowania, zadań SQL Server Agent oraz skryptów monitorujących.
Kontrolowane testy przełączania: przeprowadzenie planowanego przełączenia ról serwerów (planned manual failover) oraz symulacji nagłej awarii węzła głównego (np. odcięcie zasilania lub restart interfejsu sieciowego) wraz z pomiarem czasu powrotu aplikacji do pełnej sprawności.

Najczęściej zadawane pytania (FAQ)

Czy Microsoft SQL Server w edycji Standard obsługuje Always On Availability Groups?

Edycja Standard w wersjach od SQL Server 2016 wzwyż obsługuje technologię pod nazwą Basic Availability Groups (podstawowe grupy dostępności). Różni się ona od pełnej wersji z edycji Enterprise kilkoma ograniczeniami: każda grupa może zawierać wyłącznie jedną bazę danych, klaster może składać się maksymalnie z dwóch węzłów (jeden główny i jeden pomocniczy), a na replice pomocniczej nie można włączyć trybu tylko do odczytu ani wykonywać operacji tworzenia kopii zapasowych. Mimo tych ograniczeń jest to rozwiązanie wystarczające do zabezpieczenia pojedynczej, kluczowej bazy danych systemu ERP.

Co dzieje się z aplikacjami biznesowymi podczas przełączania ról serwerów?

W momencie przełączenia awaryjnego istniejące aktywne połączenia transakcyjne zostają przerwane, a niezatwierdzone transakcje cofnięte (rollback). Nowy serwer podstawowy przejmuje rolę nadrzędną, a nasłuchiwacz Availability Group Listener kieruje nowe zapytania do sprawnego serwera. Nowoczesne systemy ERP potrafią automatycznie ponowić próbę połączenia po kilku sekundach, co sprawia, że dla użytkownika końcowego awaria sprzętu objawia się jedynie chwilowym zawieszeniem operacji bez utraty spójności danych.

Czy na serwerze pomocniczym można wykonywać kopie zapasowe baz danych?

Tak, w edycji SQL Server Enterprise możliwe jest oddelegowanie tworzenia kopii zapasowych dziennika transakcji oraz kopii zapasowych typu Copy-Only (kopii tylko do odczytu, nienaruszających sekwencji łańcucha kopii) na replikę pomocniczą. Pozwala to na znaczne odciążenie podsystemu dyskowego oraz procesora na serwerze produkcyjnym podczas operacji archiwizacji.

Czy technologia Always On wymaga posiadania wspólnej macierzy dyskowej?

Nie, jedną z największych zalet grup dostępności Always On w porównaniu do tradycyjnych klastrów FCI jest brak konieczności posiadania współdzielonej pamięci masowej (np. drogich macierzy SAN). Każdy serwer w klastrze posiada własne, niezależne dyski lokalne (np. szybkie nośniki NVMe), a dane są przesyłane i synchronizowane na poziomie silnika bazy danych przez sieć komputerową.

Jak rozwiązywana jest kwestia uprawnień użytkowników po przełączeniu na węzeł zapasowy?

Uprawnienia wewnątrz bazy danych przełączają się automatycznie wraz z samą bazą. Jednak loginy na poziomie serwera (server-level logins) muszą zostać zdefiniowane na obu instancjach przed wystąpieniem awarii. Podczas wdrożenia stosujemy procedury mapowania identyfikatorów SID, aby zapobiec powstawaniu tak zwanych osieroconych użytkowników (orphaned users), którzy po przełączeniu ról nie mogliby zalogować się do systemu.

Wsparcie techniczne na miejscu i audyt środowiska serwerowego

Wdrożenie mechanizmów wysokiej dostępności baz danych Microsoft SQL Server realizowane jest bezpośrednio w siedzibie przedsiębiorstwa. Dojeżdżamy do klientów na terenie całej Warszawy oraz w promieniu do 40 km w okolicznych powiatach (grodziski, legionowski, otwocki, piaseczyński, pruszkowski, warszawski zachodni, wołomiński). Przed przystąpieniem do prac na serwerach produkcyjnych oferujemy bezpłatny przegląd środowiska IT dla firm oraz podpisanie umowy o zachowaniu poufności (NDA), co zapewnia pełne bezpieczeństwo przetwarzanych informacji biznesowych.

Prace konfiguracyjne prowadzone są z zachowaniem ciągłości operacyjnej firmy, a kluczowe etapy przełączeń planowane są w oknach serwisowych minimalizujących wpływ na bieżącą pracę personelu. Po zakończeniu konfiguracji Always On Availability Groups przeprowadzana jest pełna weryfikacja działania mechanizmów redundancyjnych, a administratorzy otrzymują kompletną dokumentację powykonawczą wraz z instrukcją postępowania w sytuacjach awaryjnych.

22 378 48 09

Microsoft SQL Server — konfiguracja Always On Availability Groups