Funkcjonalność Grup dostępności Always On (ang. Always On Availability Groups) - będąca jednocześnie rozwiązaniem wysokiej dostępności (HA) i odzyskiwania danych po awarii (DR), przez co określana jest niekiedy akronimem HADRON - została wprowadzona w systemie SQL Server 2012 jako rozwiązanie alternatywne dla funkcji dublowania bazy danych. Należy jednak zaznaczyć, że z uwagi na swoją złożoność i wysokie koszty implementacji rozwiązanie to przeznaczone jest głównie dla dużych środowisk klasy enterprise. Zanim przejdziemy do omawiania tego zagadnienia warto nadmienić, że kluczem do pełnego zrozumienia tematu grup dostępności jest dobre zapoznanie się z obowiązującą w nim terminologią.
W przeciwieństwie do pozostałych funkcji systemu SQL Server o podobnym charakterze, takich jak klaster pracy awaryjnej czy dublowanie bazy danych, które przełączenia w tryb pracy awaryjnej po awarii dokonują odpowiednio na poziomie instancji serwera i pojedynczej bazy danych, grupy dostępności Always On wykonują tę operację na poziomie dedykowanych kontenerów grupujących bazy danych, nazywanych właśnie grupami dostępności. Tym samym w razie wystąpienia awarii na serwerze głównym, przełączeniu w tryb pracy awaryjnej podlegają wszystkie bazy w danej grupie. Takie podejście pozwala więc zmaksymalizować dostępność wykorzystywanych w środowisku baz danych, określanych w takiej grupie mianem baz danych dostępności (ang. availability databases).
W ramach rozwiązania grupy dostępności Always On możemy utworzyć jedną podstawową bazę danych (ang. primary database) zdolną do odczytywania i zapisywania informacji, a także od jednej do ośmiu baz drugorzędnych (ang. secondary databases), będących kopiami tylko do odczytu bazy podstawowej. Łącznie w ramach pojedynczej grupy dostępności możemy więc mieć maksymalnie dziewięć instancji bazy danych, które nazywane są formalnie replikami dostępności (ang. availability replicas). Inaczej mówiąc, każda replika dostępności odpowiada w obrębie grupy dostępności konkretnej instancji bazy danych - podstawowej lub drugorzędnej.
Jak już wspomnieliśmy, grupy dostępności są rozwiązaniem dosyć złożonym i stosunkowo drogim w implementacji, ponieważ każda replika dostępności danej grupy musi znajdować się na osobnym węźle tego samego klastra pracy awaryjnej systemu Windows Server. Tym samym w przypadku utworzenia grupy dostępności złożonej z dziewięciu replik musimy dysponować klastrem złożonym z dziewięciu węzłów (hostów skłądowych), co podnosi koszty zakupu sprzętu i licencji na oprogramowanie.
Grupy dostępności, a konkretniej zawarte w nich repliki dostępności, mogą działać w jednym z dwóch trybów: asynchronicznym lub synchronicznym. Tryb asynchroniczny niejako przekształca grupę dostępności w rozwiązanie do odzyskiwania danych po awarii, także najlepiej sprawdza się on wtedy, gdy poszczególne repliki rozproszone są na duże odległości. W trybie tym mogą pracować wszystkie repliki dostępności. Z kolei tryb synchroniczny stosujemy wtedy, gdy bardziej niż na wydajności zależy nam na ochronie danych i zachowaniu wysokiej dostępności, gdyż wprowadza on zauważalne opóźnienia przy wykonywaniu transakcji. Każda grupa dostępności może dysponować maksymalnie trzema replikami pracującymi w tym trybie, wliczając w to replikę podstawową. O trybach dostępności powiemy sobie jeszcze w osobnym artykule.
Wymagania wstępne i ograniczenia
Abyśmy mogli wdrożyć i rozpocząć korzystanie z grup dostępności w naszym środowisku, musimy go najpierw odpowiednio przygotować. Jak już wspomnieliśmy, każda grupa dostępności składa się z jednej lub kilku instancji SQL Server nazywanych replikami dostępności. Każda taka replika, podstawowa lub drugorzędna, musi być osobną instancją SQL Server, przy czym może to być instancja samodzielna lub instancja klastra pracy awaryjnej SQL Server (nie mylić z klastrem pracy awaryjnej systemu Windows). Na ogół będziemy korzystać w tym celu z samodzielnych instancji rozlokowanych po poszczególnych węzłach klastra pracy awaryjnej Windows Server, jako że klaster SQL Server, budowany na bazie współdzielonych woluminów klastra, wnosi pewne dodatkowe ograniczenia. Przykładowo klaster ten w ramach grupy dostępności nie wspiera automatycznego przełączania po awarii, zaś jego węzły mogą przechowywać tylko jedną replikę danej grupy dostępności.
Repliki dostępności danej grupy zawsze spoczywają na odrębnych węzłach tego samego klastra Windows Server, zaś jedynym przypadkiem kiedy grupa dostępności będzie mogła być obecna na dwóch różnych klastrach jednocześnie jest moment jej migracji.
Aby baza danych mogła zostać przypisana do konkretnej grupy dostępności, musi ona spełniać określone wymagania. Baza kandydująca do miana repliki dostępności określonej grupy musi być bazą danych użytkownika; musi istnieć i być dostępna na serwerze, gdzie tworzona jest dana grupa dostępności; musi umożliwiać zarówno odczyt, jak i zapis informacji; musi być bazą danych pozbawioną ograniczenia co do liczby jej użytkowników; nie może być automatycznie zamykana; musi korzystać z pełnego modelu odzyskiwania; musi dysponować co najmniej jedną pełną kopią zapasową; nie może należeć do żadnej innej grupy dostępności oraz nie może być skonfigurowania pod dublowanie.
