Wysoka dostępność baz: Always On, klaster czy chmura

Krok 1. RTO i RPO zapisane liczbą

W wielu firmach wymaganie dostępności brzmi „baza ma działać”. To życzenie, a nie parametr, na podstawie którego można zaprojektować rozwiązanie. Do wyboru architektury potrzebne są dwie wartości, ustalone osobno dla każdego systemu:

• RTO (Recovery Time Objective) - maksymalny akceptowalny czas od awarii do przywrócenia działania,
• RPO (Recovery Point Objective) - maksymalna ilość danych, liczona w czasie, którą organizacja może utracić.

Te liczby ustala biznes, a nie administrator. Rolą IT jest pokazanie, ile kosztuje każdy poziom: RPO równe zeru wymaga replikacji synchronicznej, która wpływa na czas zapisu, a RTO liczone w sekundach wymaga automatycznego przełączania i aplikacji, które potrafią ponowić połączenie. Często okazuje się przy tym, że system uznawany za krytyczny może stać godzinę, a pozornie pomocnicza integracja z firmą kurierską zatrzymuje wysyłki już po kwadransie.

Przy kilkunastu lub kilkudziesięciu systemach warto pogrupować je w kilka klas, na przykład krytyczne, ważne i pomocnicze, i dla każdej klasy przyjąć wspólne wartości RTO i RPO. Uprości to projekt i rozmowę o budżecie, bo zamiast dyskutować o każdym systemie osobno, zarząd zatwierdza poziom ochrony dla klasy i listę systemów, które do niej należą.

Krok 2. Grupy dostępności Always On

Grupy dostępności Always On replikują wybrane bazy między instancjami SQL Server, z których każda ma własną kopię danych na własnych dyskach. Replika w trybie synchronicznym zatwierdza transakcję dopiero po utrwaleniu jej w dzienniku repliki pomocniczej, co pozwala na automatyczne przełączenie bez utraty danych. Repliki asynchroniczne nadają się do odległych lokalizacji, gdzie opóźnienie sieci wykluczałoby tryb synchroniczny, ale przy przełączeniu dopuszczają utratę ostatnich transakcji.

Zaletą tego rozwiązania jest brak wspólnego magazynu danych, możliwość odciążenia repliki podstawowej przez przeniesienie raportów i kopii zapasowych na repliki do odczytu oraz odbiornik (listener), który ukrywa przed aplikacjami, na którym serwerze działa aktualnie replika podstawowa. Trzeba jednak pamiętać o ograniczeniach:

• pełne grupy dostępności wymagają edycji Enterprise, a edycja Standard oferuje grupy podstawowe, z jedną bazą w grupie, dwiema replikami i bez odczytu z repliki pomocniczej,
• obiekty spoza bazy, takie jak loginy, zadania SQL Server Agent czy serwery połączone, trzeba synchronizować osobno,
• transakcje rozproszone i zapytania między bazami trzeba sprawdzić pod kątem zachowania po przełączeniu,
• repliki wymagają licencji, chyba że replika pełni wyłącznie rolę pasywną i obejmują ją uprawnienia wynikające z Software Assurance.

Problem obiektów spoza bazy częściowo rozwiązują grupy dostępności typu contained, dostępne od SQL Server 2022, które przenoszą razem z bazami także loginy i zadania Agenta. W starszych wersjach potrzebny jest skrypt albo narzędzie, które regularnie porównuje i synchronizuje te obiekty między replikami. Bez tego pierwsze przełączenie kończy się aplikacją, która nie może się zalogować, albo zadaniami nocnymi, które przestały się uruchamiać.

Krok 3. Klaster przełączania awaryjnego

Wystąpienie klastra przełączania awaryjnego (FCI) chroni całą instancję SQL Server: bazy systemowe, loginy, zadania i konfigurację. W danym momencie instancja działa na jednym węźle klastra Windows, a po awarii uruchamia się na innym, korzystając z tych samych plików bazy we wspólnym magazynie danych.

Z perspektywy aplikacji i administracji to rozwiązanie jest proste, bo przełącza się cała instancja razem ze wszystkim, co w niej jest. Ma jednak słaby punkt: dane istnieją w jednej kopii. Awaria macierzy, błąd konfiguracji magazynu albo uszkodzenie plików bazy dotyka wszystkich węzłów jednocześnie. Przełączenie trwa też zwykle dłużej niż w grupach dostępności, bo instancja musi wystartować na nowym węźle i przeprowadzić odzyskiwanie baz.

Klaster sprawdza się tam, gdzie głównym ryzykiem jest awaria serwera lub systemu operacyjnego, a magazyn danych ma własną, sprawdzoną nadmiarowość. Często łączy się go z grupami dostępności: klaster chroni instancję w ośrodku podstawowym, a asynchroniczna replika w drugiej lokalizacji odpowiada za odporność na awarię całego ośrodka.

Klaster można zbudować także na maszynach wirtualnych w Azure, korzystając na przykład z dysków współdzielonych Azure albo z Storage Spaces Direct. Wymaga to jednak starannego zaprojektowania sieci i magazynu, dlatego w chmurze częściej wybieramy grupy dostępności albo usługę zarządzaną, chyba że aplikacja wymaga ochrony całej instancji.

Krok 4. Wysoka dostępność w Azure

W chmurze część pracy przejmuje dostawca, ale wybór usługi nadal decyduje o tym, co jest chronione automatycznie, a co trzeba zaprojektować i skonfigurować samodzielnie.

Usługi zarządzane zdejmują z zespołu instalację, aktualizacje i konfigurację klastra, a kopie zapasowe z możliwością odtworzenia do wybranego momentu wykonują się automatycznie. Maszyny wirtualne dają pełną kontrolę i zgodność z dotychczasowym środowiskiem, ale odpowiedzialność za architekturę wysokiej dostępności zostaje po stronie firmy, dokładnie tak jak we własnej serwerowni. Przy porównaniu warto też sprawdzić, jaki poziom SLA dostawca deklaruje dla wybranej konfiguracji i czy obejmuje on scenariusze, które są dla firmy istotne.

W usługach zarządzanych znaczenie ma też warstwa usługi. W Azure SQL Database i Managed Instance warstwa Business Critical utrzymuje kilka replik z danymi na lokalnych dyskach i udostępnia replikę do odczytu, co skraca przełączenie i pozwala odciążyć bazę z raportów. Warstwa General Purpose opiera się na zdalnym magazynie, jest tańsza, ale przełączenie może trwać dłużej. Wybór warstwy przekłada się więc bezpośrednio na osiągalne RTO.

Krok 5. Kiedy replika obok nie wystarcza

Replika w tej samej serwerowni, a nawet w tym samym centrum danych, chroni przed awarią serwera. Nie chroni przed zdarzeniami, które dotykają całego ośrodka albo wszystkich kopii naraz:

• awarią zasilania, chłodzenia lub sieci w całym budynku,
• błędem konfiguracji wspólnej infrastruktury, na przykład przełącznika sieciowego czy kontrolera domeny,
• przypadkowym usunięciem danych albo błędną aktualizacją, która w ciągu milisekund trafia na wszystkie repliki,
• atakiem ransomware, który szyfruje dane na każdym serwerze dostępnym z tej samej domeny.

Dlatego plan ciągłości działania obejmuje trzy elementy: wysoką dostępność w ośrodku podstawowym, replikę lub kopię w odrębnej lokalizacji oraz kopie zapasowe odizolowane od produkcji, najlepiej niezmienialne. Wysoka dostępność skraca przerwę przy typowej awarii, a odizolowane kopie chronią przed scenariuszem, w którym wszystkie repliki mają ten sam błąd.

Kopie odizolowane od produkcji to w praktyce kopie, których nie da się usunąć ani nadpisać przy użyciu kont z domeny produkcyjnej. Mogą to być magazyny z blokadą niezmienialności, osobna subskrypcja lub dzierżawa z oddzielnymi poświadczeniami albo nośniki fizycznie odłączone od sieci. Niezależnie od formy trzeba regularnie sprawdzać, czy da się z nich odtworzyć bazę w czasie zgodnym z RTO dla scenariusza ataku.

Druga lokalizacja ma sens tylko wtedy, gdy da się w niej uruchomić cały system, a nie samą bazę. Przełączenie bazy do zapasowego ośrodka nic nie da, jeśli serwery aplikacji, usługi katalogowe, certyfikaty i połączenia z partnerami nadal wskazują na ośrodek podstawowy. Dlatego plan odtworzenia po awarii opisuje kolejność uruchamiania wszystkich elementów, zmiany w DNS i sposób poinformowania użytkowników.

Replikacja kopiuje także błędy. Przed skasowanymi danymi chroni dopiero kopia zapasowa, której nie da się zmienić.

Krok 6. Wybór rozwiązania i test przełączenia

1. Zbierz RTO i RPO dla każdego systemu i każdego scenariusza awarii.
2. Sprawdź, które systemy dzielą instancję, bo najostrzejsze wymaganie wyznacza poziom ochrony całej instancji.
3. Oceń ograniczenia edycji i licencji SQL Server oraz zależności aplikacji od obiektów spoza bazy.
4. Wybierz mechanizm dla awarii lokalnej i osobno dla awarii ośrodka.
5. Przygotuj instrukcję przełączenia i powrotu z przypisanymi osobami.
6. Przeprowadź test przełączenia w uzgodnionym oknie i zmierz rzeczywisty czas.

Ostatni krok jest najczęściej pomijany. Rozwiązanie, którego nikt nie przełączył, ma nieznane RTO, a aplikacje, które nie potrafią ponowić połączenia, zamieniają kilkusekundowe przełączenie bazy w wielominutową awarię odczuwalną dla użytkowników. Test powtarzamy po każdej większej zmianie i przynajmniej raz w roku, a jego wynik zapisujemy obok RTO uzgodnionego z biznesem.

Przed testem warto sprawdzić konfigurację po stronie aplikacji. Połączenie powinno iść przez odbiornik grupy dostępności albo nazwę grupy przełączania awaryjnego, a nie przez nazwę konkretnego serwera. Gdy repliki stoją w różnych podsieciach, w ciągu połączenia ustawia się parametr MultiSubnetFailover, który skraca czas ponownego połączenia. Logika ponawiania prób w aplikacji pozwala z kolei przejść przez przełączenie bez błędów widocznych dla użytkownika.

Wiecie, ile czasu wasza baza może nie działać?

Pomożemy zapisać RTO i RPO, dobrać architekturę wysokiej dostępności i przeprowadzić test przełączenia.

Porozmawiaj z ekspertem