Tworzenie nowej grupy dostępności

Wiemy już mniej więcej czym są i jak działają grupy dostępności Always On, tak więc przyszedł teraz czas na zaprezentowanie sposobu tworzenia takiej grupy w przykładowym środowisku. Jak już wspominaliśmy w poprzedniej publikacji, działanie tego rozwiązania opiera się bezpośrednio na funkcjonalności klastra pracy awaryjnej systemu Windows Server, tak więc zanim w ogóle rozpoczniemy proces tworzenia nowej grupy dostępności musimy uprzednio zdefiniować sobie taki klaster. Jako że funkcja klastra pracy awaryjnej nie jest częścią systemu SQL Server, lecz należy do systemu operacyjnego Windows Server, dokładne informacje w zakresie działania tej technologii i sposobów jej implementacji przedstawiliśmy w dziale poświęconym produktowi Windows Server.

Na każdym węźle klastra, który ma być wykorzystywany w ramach grupy dostępności, należy zainstalować samodzielną instancję systemu SQL Server w edycji Enterprise. Żadna inna edycja tego systemu nie obsługuje grup dostępności Always On.

Włączanie grup dostępności w obrębie klastra pracy awaryjnej

Pierwszym krokiem prowadzącym do utworzenia nowej grupy dostępności Always On jest włączenie wsparcia dla tej technologii w obrębie klastra pracy awaryjnej Windows Server, na którym ma ona zostać wdrożona. Krok ten jest bardzo prosty i sprowadza się do odwiedzenia kolejno każdego z węzłów klastra pracy awaryjnej, a następnie aktywowanie w nim funkcji Always On Availability Groups. Aby tego dokonać, należy zalogować się na zadanym węźle klastra, a następnie uruchomić na nim konsolę SQL Server Configuration Manager, pozwalającą na skonfigurowanie lokalnej instancji serwera. W panelu po lewej należy wybrać element SQL Server Services, co spowoduje wyświetlenie w głównym oknie wszystkich usług należących do zainstalowanej instancji serwera bazy danych. Usługę serwera bazy danych o nazwie SQL Server (MSSQLServer) - lub podobnej w przypadku instancji nazwanej - należy kliknąć prawym przyciskiem, a następnie wybrać opcję Properties, co spowoduje wyświetlenie okna właściwości tej usługi. W oknie dialogowym SQL Server (MSSQLSERVER) Properties należy przejść na kartę AlwaysOn High Availability, a następnie zaznaczyć pole wyboru Enable AlwaysOn Availability Groups. Zgodnie z zamieszczonym pod tym polem opisem włączanie tej funkcji umożliwi nam wykorzystanie bieżącej instancji SQL Server w ramach grupy dostępności, w celu zapewnienia wysokiej dostępności i umożliwienia odzyskiwania danych.

Zanim klikniemy OK, warto jeszcze zajrzeć na kartę Log On, gdzie będziemy mogli zmienić konto wykorzystywane do logowania się do tej instancji. Wybrane przez nas konto powinno może (ale nie musi) być takie samo dla wszystkich pozostałych instancji należących do grupy dostępności i musi być w stanie uzyskać dostęp do każdej z nich.

Po zakończeniu należy zamknąć to okno dialogowe poprzez kliknięcie przycisku OK. Jako że po wprowadzeniu tych modyfikacji usługa silnika bazy danych wymagać będzie ponownego uruchomienia, przed zamknięciem konsoli SQL Server Cofiguration Manager należy ponownie kliknąć usługę SQL Server prawym przyciskiem, a następnie wybrać opcję Restart.

Powyższy proces należy powtórzyć na każdym z węzłów klastra pracy awaryjnej systemu Windows Server, którego instancję SQL Server zamierzamy wykorzystać w ramach tworzonej grupy dostępności. Jeśli nie zależy nam na modyfikowaniu żadnych ustawień domyślnych, wówczas funkcję Always On Avaliability Groups możemy w prosty sposób aktywować na każdej z instancji za pomocą polecenia PowerShell o nazwie Enable-SQLAlwaysOn. Jak pamiętamy, najwygodniejszym sposobem uruchamiania powłoki PowerShell w kontekście danej instancji SQL Server jest kliknięcie prawym przyciskiem nazwy tej instancji w oknie Object Explorer programu SQL Server Management Studio i skorzystanie z opcji Start PowerShell.

Uruchamianie kreatora tworzenia nowej grupy dostępności

Po wstępnym przygotowaniu klastra pod obsługę grup dostępności Always On możemy przystąpić do procesu tworzenia takiej grupy. Najłatwiejszym sposobem utworzenia nowej grupy dostępności jest skorzystanie z dedykowanego kreatora New Availability Groyp Wizard. Aby ten kreator uruchomić, należy kliknąć prawym przyciskiem węzeł AlwaysOn High Availability (lub jego podwęzeł Availability Groups) widoczny w oknie Object Explorer narzędzia SQL Server Management Studio, a następnie wybrać opcję New Availability Group Wizard. Zostanie wówczas wyświetlona pierwsza i czysto opisowa strona tego kreatora, której wyświetlania możemy zrezygnować poprzez zaznaczenie pole wyboru Do not show this page again. Aby rozpocząć konfigurację nowej grupy dostępności, klikamy przycisk Next.

Nazwa grupy dostępności i ochrona na poziomie bazy danych

Na stronie Specify Name kreatora wprowadzamy nazwę dla tworzonej grupy dostępności. Należy podkreślić, że nazwa ta nie jest wykorzystywana do łączenia się z grupą dostępności, a jedynie służy nam w celu umożliwienia identyfikacji tej grupy. W systemie SQL Server 2016 i nowszych na stronie tej dostępne jest również pole wyboru Database Level Health Detection, odpowiedzialne za włączenie funkcji monitorowania stanu zdrowia baz danych zawartych w danej grupie dostępności. Jest to nowe rozwiązanie, które do dotychczasowego procesu monitorowania stanu zdrowia instancji dorzuca monitorowanie na poziomie baz danych. Jest to bardzo przydatne rozwiązanie, ponieważ do tej pory monitorowanie to odbywało się tylko na poziomie poszczególnych instancji, a co za tym idzie nawet w przypadku uszkodzenia pojedynczej bazy danych w grupie dostępności nie dochodziło do automatycznego przełączenia w tryb pracy awaryjnej z powodu braku wiedzy o takiej awarii. Po zaznaczeniu opcji dodatkowego monitorowania na poziomie bazy należny kliknąć Next.

Wybór baz danych

W kolejnym kroku wybieramy bazy danych użytkownika, które mają stać się częścią tworzonej grupy dostępności. Zgodnie z nakreślonymi przez nas wcześniej wymogami stawianymi kandydującym do grupy dostępności bazom danych, baza taka musi działać w pełnym trybie odzyskiwania, a co za tym idzie musi dla niej zostać utworzona pełna kopia zapasowa. Jeśli któraś z baz nie spełnia tego wymagania, nie będziemy mogli jej w tym miejscu zaznaczyć, a zamiast tego obok jej nazwy w kolumnie Status pojawi się odpowiedni komunikat definiujący wykryty problem. Jeśli interesująca nas baza spełnia wszystkie wymagania, aby stać się częścią grupy dostępności, w kolumnie Status widnieć będzie tekst "Meets prerequisites". W przypadku zaszyfrowanych baz danych konieczne będzie również podanie dla nich hasła w polu Password. Kreator sam wykrywa i ewentualnie prosi o uzupełnienie takiego pola dla zadanej bazy danych. Po wybraniu wszystkich docelowych baz danych dla tworzonej grupy należy kliknąć Next.

Weryfikacja serwerów repliki

Na stronie Specify Replicas mamy do dyspozycji cztery różne karty, w ramach których konfigurujemy ustawienia związane z pozostałymi instancjami SQL Server, które wykorzystywane będą jako serwery repliki. Na karcie Replicas za pomocą przycisku Add Replica dodajemy do listy kolejne węzły klastra pracy awaryjnej, które przechowywać będą zdublowane informacje. Dla każdej instancji repliki możemy określić jej rolę początkową (Podstawowa/Drugorzędna), Automatyczne przełączanie w tryb pracy awaryjnej (Tak/Nie), tryb działania (Synchroniczny/Asynchroniczny) oraz możliwość odczytywania z niej informacji (Tak/Nie). O ustawieniach tych porozmawiamy za moment.

Samo dodanie konkretnej instancji serwera sprowadza się do zdefiniowania danych jego połączenia w wyświetlonym oknie Connect to Server, znanym nam z codziennej pracy z programem SQL Server Management Studio. Po wprowadzeniu nazwy serwera dla danej instancji klikamy przycisk Connect i powtarzamy ten proces dla każdego węzła klastra. Gdy na liście instancji widnieją już wszystkie serwery mające brać udział w grupie dostępności, możemy je odpowiednio skonfigurować. Opcja Automatic Failover pozwala nam określić, czy dana instancja ma być uznawana za partnera w procesie automatycznego przełączania w tryb pracy awaryjnej. Opcję te zaznaczamy dla repliki podstawowej i i maksymalnie dla trzech replik drugorzędnych. Każda replika z zaznaczonym polem wyboru Automatic Failover działać będzie w synchronicznym trybie dostępności, który to jest kolejnym dostępnym ustawieniem instancji. Opcja Synchronous Commit konfiguruje replikę do korzystania z trybu synchronicznego (po zaznaczeniu) lub asynchronicznego (po odznaczeniu). W tym pierwszym przypadku możemy mieć tylko trzy takie repliki. Ostatnie ustawienie, Readable Secondary, oferuje nam trzy opcje: Tak (wszystkie połączenia do drugorzędnej bazy danych są do odczytu), Read-intent only (bazy są dostępne do odczytu tylko dla połączeń zawierających odpowiednią właściwość w ramach parametrów połączenia) oraz No (bazy nie są dostępne do odczytu a tym samym nie będą odrzucać jakiekolwiek bezpośrednie połączenia).

Konfiguracja punktów końcowych

Kolejnym krokiem jest konfiguracja punktów końcowych (ang. endpoints), którą możemy przeprowadzić na drugiej karcie bieżącej strony Specify Replicas. Punkty końcowe są najzwyczajniej obiektami, za pomocą których poszczególne aplikacje mogą łączyć się z konkretnymi instancjami bazy danych SQL Server. Domyślnie grupy dostępności wykorzystują do komunikacji port 5022, a więc domyślny port funkcji dublowania bazy danych. Port ten możemy oczywiście zmienić, podobnie z resztą jak ustawienie dotyczące szyfrowania przesyłanych przez ten punkt danych (kolumna Encrypt Data). Należy pamiętać, że wskazany przez nas port musi zostać otwarty w zaporze sieciowej, gdyż inaczej operacja utworzenia grupy dostępności nie powiedzie się.

Preferencje kopii zapasowej

Trzecia karta dotyczy ustawień związanych z wykonywaniem automatycznych kopii zapasowych, sporządzanych dla poszczególnych instancji repliki w obrębie ich grupy dostępności. Dostępne opcje to Prefer Secondary (kopie wykonywane są na replice drugorzędnej, chyba że jedyną aktywną repliką jest replika podstawowa), Secondary only (kopie zawsze wykonywane są na replice drugorzędnej, a w przypadku braku takiej repliki nie są wykonywane wcale), Primary (kopie sporządzane są zawsze na replice podstawowej; ustawienie dedykowane m.in. różnicowym kopiom zapasowym) oraz Any replica (kopia może zostać wykonana na replice dowolnego rodzaju, zgodnie z priorytetem określonym w dolnej części okna. Nadawanie priorytetów poszczególnym replikom polega na przydzieleniu im wartości priorytetu z przedziału od 1 do 100. Wartość 1 oznacza najniższy priorytet, a wartość 100 priorytet najwyższy.

Konfiguracja odbiornika

Kolejny krok dotyczy konfiguracji odbiornika (ang. listener) grupy dostępności. Utworzenie nowego odbiornika nie jest na tym etapie wymagane, ale jeśli chcemy, możemy zdefiniować go już teraz. Aby to zrobić, należy zaznaczyć opcję Create an availability group listener, po czym określić dla tworzonego odbiornika nazwę, port oraz tryb sieci. Nazwa odbiornika musi być unikalna w obrębie całej domeny i może składać się co najwyżej z 15 znaków. Jeśli chodzi o port, to domyślnie wykorzystywany jest port o numerze 1433, którego użycie nie wymusza na nas modyfikacji parametrów połączenia. Należy się jednak upewnić, że ten port nie jest już wykorzystywany w żadnym innym celu. Jeśli jednak zdecydujemy się na użycie innego numeru portu, będziemy musieli jawnie uwzględnić go w ramach parametrów połączenia. Z kolei w ramach opcji Network Mode decydujemy, czy nasłuch ma być prowadzony na adresie pozyskanym dynamicznie (DHCP), czy też wprowadzonym statycznie (Static IP). W przypadku wybrania opcji protokołu DHCP nasłuch będzie prowadzony tylko w obrębie pojedynczej podsieci. Jeśli więc zależy nam na skonfigurowaniu grupy dostępności rozciągającej się na kilka podsieci, należy uwzględnić je w ramach opcji Static IP. Jeśli wybraliśmy taki scenariusz, za pomocą przycisku Add konfigurujemy kolejne podsieci grupy dostępności. Natomiast gdy grupa ta znajdować się będzie w całości w obrębie jednej podsieci, wystarczy skonfigurować jedną taką podsieć (odpowiednio statycznie lub dynamicznie).

Synchronizacja danych

Na stronie Select Data Synchronization konfigurujemy sposób wstępnej synchronizacji dla nowych drugorzędnych baz danych. Jeśli nie chcemy wykonywać tej czynności, bo sami będziemy ręcznie wykonywać kopie zapasowe bazy danych i dziennika podstawowej bazy, wybieramy opcję Skip initial data synchronization. Jeśli dokonaliśmy już przywrócenia podstawowej bazy danych i jej dziennika na replikach drugorzędnych, należny skorzystać z opcji Join only. Z kolei wybór opcji Full spowoduje rozpoczęcie procesu, w ramach którego dla bazy podstawowej i jej dziennika zostaną utworzone pełne kopie zapasowe, mające zostać przywrócone na poszczególnych serwerach repliki. Jako że proces ten będzie wykonywany przy wykorzystaniu udostępnionej lokalizacji sieciowej dostępnej dla wszystkich serwerów, należy wskazać taką lokalizację w przeznaczonym do tego polu.

Weryfikacja końcowa

Podsumowanie

Na tym etapie nowa grupa dostępności jest już zdefiniowana i możemy zacząć z niej korzystać. Aby jednak upewnić się, że wszystko poszło zgodnie z planem i rozwiązanie to działa dokładnie tak, jak tego oczekujemy, warto wykonać kilka prostych zadań poinstalacyjnych, w ramach których będziemy mogli podejrzeć wszystkie ważniejsze zasoby powstałe w ramach wdrożenia nowej grupy dostępności, a także zapoznać się ze sposobami łączenia się z taką grupą.