W dzisiejszych czasach nowoczesne technologie stanowią podstawę działania praktycznie każdej prosperującej na rynku firmy. Z tego powodu ważne jest, aby technologie te, a w szczególności napędzająca je infrastruktura, były dostępne dla pracowników i klientów przez cały czas. Kto zalicza tzw. downtime, czyli czas, w którym jego firma z powodu problemów technicznych przestaje chwilowo świadczyć swoje usługi, może narazić się na poważne straty finansowe, a nawet ostatecznie wypaść z rynku. Niestety, jako że stosowane na świecie oprogramowanie nie jest pozbawione wad, a wykorzystywany na co dzień sprzęt nie jest niezawodny, do tego rodzaju sytuacji dochodzi na świecie dziesiątki razy każdego dnia.
Z tego powodu administratorzy IT robią co tylko mogą, aby uchronić się przed tego typu awariami, których to nawet kilkunastominutowe wystąpienia (w skali całego roku) mogą przyczynić się do całkowitej utraty danych lub naruszenia umowy o gwarantowanym poziomie świadczenia usług (ang. service-level agreement, SLA), jaka nawiązywana jest z klientami firmy. Na potrzeby zminimalizowania tego problemu specjaliści nieustannie pracują nad coraz to nowszymi rozwiązaniami wysokiej dostępności i odzyskiwania danych, które implementowane są na wielu różnych poziomach infrastruktury.
Aby umożliwić sobie realne oszacowanie kosztów na jakie możemy zostać narażeni w przypadku utraty danych, a także by przewidzieć potencjalny czas trwania określonej awarii, w biznesie definiuje się dwa podstawowe wymagania: cel punktu odzyskiwania (ang. recovery point objective, RPO) oraz cel czasu odzyskiwania (ang. recovery time objective, RTO). RPO jest maksymalnym akceptowalnym poziomem utraty danych w przypadku wystąpienia awarii i należy go rozpatrywać w kontekście punktu w czasie, do którego dane mogą zostać odzyskane. Z kolei RTO jest maksymalnym dozwolonym czasem awarii, czy jak kto woli czasem, jaki dany biznes ma na jej usunięcie i przywrócenie świadczonych usług do pełnej sprawności. Zarówno te, jak i kilka innych wymagań, dokumentuje się zazwyczaj w umowie dotyczącej poziomu świadczenia usług, zawieranej z bezpośrednio z klientami firmy.
System SQL Server oferuje kilka różnych rozwiązań wysokiej dostępności i odzyskiwania danych (ang. HA/DR), których ostateczny wybór uzależniony będzie od naszych potrzeb oraz możliwości finansowych i sprzętowych. Zależnie od tego, jakiej ochrony potrzebujemy, możemy skorzystać z udostępnionych nam narzędzi wysokiej dostępności (ang. high availability, HA), odzyskiwania danych (ang. data recovery, DR) lub rozwiązań, które stanowią niejako połączenie tych dwóch światów, przez co nazywane są rozwiązaniami HA/DR. Dalsza część tego artykułu zawiera krótki przegląd tych narzędzi, z których każde zostanie szczegółowo omówione w oddzielnych publikacjach.
Instancje klastra pracy awaryjnej
Instancja klastra pracy awaryjnej (ang. failover cluster instance, FCI) jest instancją serwera bazy danych SQL Server, która zainstalowana jest na poszczególnych węzłach klastra pracy awaryjnej systemu Windows Server. Fizycznie instancja ta znajduje się więc na odrębnych maszynach, jednak z perspektywy użytkownika działa ona tak samo, jak zwykła instancja serwera. Oczywiście, aby połączenie się z taką instancją było możliwe, użytkownik zamiast bezpośrednio z danym węzłem klastra łączy się z adresem wirtualnego serwera, który odpowiednio przekierowuje go do konkretnej maszyny. Gdy jeden z węzłów klastra ulega awarii, kolejny węzeł natychmiastowo przejmuje jego pracę. Takie przesunięcie obciążeń roboczych z jednego węzła na drugi w obrębie klastra nazywamy przełączeniem w tryb pracy awaryjnej. Operacja ta możliwa jest dzięki temu, że wszystkie obiekty bazy danych przechowywane są w magazynie współdzielonym przez wszystkie węzły klastra, co w przypadku awarii jednego z serwerów nie powoduje utraty informacji. Oczywiście należy pamiętać o odpowiednim zabezpieczeniu takiego klastra, który nie oferuje żadnej nadmiarowości danych, a także zabezpieczeniu magazynu, który może być potencjalnie pojedynczym punktem podatności na awarię). Takie rozwiązanie w postaci sklastrowanej instancji ma kilka dodatkowych zalet, bo z uwagi na obsługę przez klaster różnych podsieci może ona zostać rozproszona po kilku centrach danych, odseparowanych od siebie ma duże odległości.
W systemie SQL Server 2012 funkcja instancji klastra pracy awaryjnej stałą się częścią zestawu rozwiązań Always On i została przemianowana na funkcję Always On Failover Cluster. W wydaniach 2014 i 2016 doczekała się ona kilku znaczących usprawnień, o których powiemy sobie przy okazji szczegółowego omawiania tej funkcji.
Dublowanie bazy danych
Funkcja dublowania bazy danych (ang. database mirroring) polega na utworzeniu pojedynczej kopii istniejącej bazy danych. W przeciwieństwie do klastra pracy awaryjnej, który działa na poziomie instancji, dublowanie bazy danych, zgodnie ze swoją nazwą, obejmuje swoim działaniem jedynie konkretną bazę danych. Tym samym replikowane są tu wyłącznie obiekty należące dublowanej bazy. Proces synchronizacji repliki z jej oryginałem może przebiegać w trybie synchronicznym lub asynchronicznym. Dublowanie w trybie asynchronicznym stosowane jest zazwyczaj wtedy, gdy obie te instancje odseparowane są od siebie na duże odległości, jak w przypadku dwóch dowolnych centrów danych. W tym kontekście dublowanie bazy danych przyjmuje charakter rozwiązania odzyskiwania danych. Z kolei tryb synchroniczny zapewnia nam rozwiązanie wysokiej dostępności i stosuje się je zazwyczaj w obrębie pojedynczego centrum danych. W tym przypadku możemy dodatkowo skorzystać z pomocy serwera monitorującego, który zapewni nam możliwość automatycznego i niemal natychmiastowego przełączenia w tryb pracy awaryjnej.
Dublowanie bazy danych jest funkcją przestarzałą, która w przyszłych wydaniach SQL Server zostanie wycofana. Biorąc jednak pod uwagę, że na rynku najczęściej stosowane są wersje 2005 i 2008 tego systemu, rozwiązanie to jeszcze przez wiele lat będzie nadal szeroko wspierane w większości przedsiębiorstw. Dublowanie bazy danych zostało zastąpione w grupami dostępności Always On.
Wysyłanie dziennika
Wysyłanie dziennika (ang. log shipping) również działa na poziomie bazy danych, jednak w tym przypadku możemy utworzyć jedną lub więcej tzw. drugorzędnych baz danych, będących kopiami bazy podstawowej. W przypadku awarii serwera podstawowego możemy przełączyć się na jedną z kopii i kontynuować pracę bazy. Każda z drugorzędnych baz danych aktualizowana jest na bieżąco przy wykorzystaniu wpisów z dziennika transakcji pochodzącego z bazy podstawowej, co z kolei wymusza na tej bazie pracę w trybie pełnego odzyskiwania. Działanie funkcji wysyłania dziennika sprowadza się wiec do okresowego sporządzania kopii zapasowej dziennika transakcji podstawowej bazy danych, przesyłania kopii dziennika na serwery drugorzędne, a następnie odtwarzanie zawartych tam w wpisów w drugorzędnych bazach danych. Proces ten nadzorowany i wykonywany jest przez agentów SQL Server.
Wysyłanie dziennika stosowane jest zazwyczaj pomiędzy instancjami zlokalizowanymi w oddzielnych centrach danych, a tym samym przyjmuje charakter narzędzia do odzyskiwania danych. Funkcja ta zostanie szczegółowo omówiona w osobnym artykule.
Replikacja
Replikacja polega na kopiowaniu zawartości bazy danych z jednej lokalizacji do drugiej. Rozwiązanie to zostało wprowadzone w systemie SQL Server jeszcze w latach 90-tych i początkowo służyło za mechanizm tworzenia kopii bazy danych, które służyły głównie za źródło danych dla aplikacji raportowania. Od tego czasu funkcja replikacji została znacznie rozbudowana o nowe możliwości, przez co teraz uchodzi w dużej mierze za rozwiązanie HA/DR.
Działanie replikacji odbywa się na zasadzie subskrypcji, zaś cały proces rozpoczyna się od wskazania konkretnych obiektów bazy danych, które chcemy skopiować. Obiekty te, nazywane artykułami, grupowane są w tzw. publikacje, zaś udostępniająca je instancja SQL Server nazywana jest wydawcą. W procesie replikacji dane kopiowane są z serwera wydawcy do tzw. subskrybentów, którymi mogą być dowolne instancje SQL Server, usługi lub aplikacje wyrażające chęć pozyskiwania tych informacji.
Do dyspozycji mamy kilka rodzajów replikacji, za pomocą których dane pomiędzy wydawcami i subskrybentami możemy przenosić na różne sposoby. Dostępne są m.in. replikacja migawki, replikacja transakcyjna, replikacja scalająca i replikacja równorzędna. Omówimy je sobie szczegółowo w artykule poświęconym zagadnieniom replikacji.
Always On
Pod nazwą Always On kryją się tak naprawdę dwa różne rozwiązania, które realizują funkcję wysokiej dostępności i odzyskiwania danych. Są to grupy dostępności Always On (ang. Always On availability groups) oraz instancje klastra pracy awaryjnej Always On (Always On failover cluster instances). Konieczność istnienia tych rozwiązań podyktowana jest głównie niedoskonałością powyższych funkcji. Przykładowo dublowanie bazy danych nie umożliwia tworzenia więcej niż jednej bazy drugorzędnej, a przy tym operacji dublowania danych dokonuje się na każdej bazie z osobna. Wysyłanie dziennika może doprowadzić do mniejszej lub większej utraty danych, a przy tym nie obsługuje automatycznego przełączanie w tryb pracy awaryjnej. Warto także zaznaczyć, że rozwiązanie to marnuje dostępną moc serwerów, jako że przez większość czasu te pasywne maszyny nie wykonują żadnej pracy. Z kolei klastry pracy awaryjnej do swojego działania wykorzystują współdzielone magazyny, które stanowią pojedynczy punkt awarii.
Instancje klastra pracy awaryjnej Always On rozszerzają dotychczasową funkcjonalność klastra pracy awaryjnej SQL Server, które już pokrótce sobie nakreśliliśmy. Czym więc funkcja ta różni się od grup dostępności Always On? Przede wszystkim nie jest to nowe rozwiązanie, lecz lekko rozszerzona dotychczasowa funkcjonalność kastrowania ubrana w nieco zmienioną nazwę. Umożliwia ona przełączanie w tryb pracy awaryjnej z jednego serwera na drugi, będących częścią tego samego klastra pracy awaryjnej. Funkcja ta do działania wymaga współdzielonego magazynu danych i wykorzystuje pasywne (oczekujące) węzły drugorzędne, które mogą wydłużyć czas przełączenia po awarii do nawet kilku minut.
Z kolei grupy dostępności Always On, wprowadzone po raz pierwszy w systemie SQL Server 2012, można uznać za rozszerzoną wersję funkcji dublowania bazy danych, przy czym jest to zupełnie nowa technologia, która podobnie jak instancje klastra pracy awaryjnej AlwaysOn wymaga obecności klastra pracy awaryjnej systemu Windows Server. Grupy dostępności pozwalają na tworzenie więcej niż jednej kopii bazy danych, dublowanie w ramach pojedynczej sesji i automatyczne przełączanie w tryb pracy awaryjnej kilku baz danych, a także automatyczne naprawianie stron. Grupy dostępności wykorzystują aktywne serwery repliki, stąd czas potrzeby na przełączenie w tryb pracy awaryjnej wynosi mniej niż 30 sekund. Z kolei zamiast współdzielonego magazynu danych wykorzystuje się w tym przypadku magazyny przyłączane bezpośrednio.
Zadaniem obu powyższych funkcji jest świadczenie wysokiej dostępności i umożliwienie odzyskiwania danych, a mówiąc językiem zarządzania, zminimalizowanie celu punktu odzyskiwania (RPO) i celu czasu odzyskiwania (RTO).
