Wraz z SQL Server 2012 firma Microsoft wprowadziła funkcję Grup Dostępności Always On (Always On Availability Groups), od tego czasu rozwiązanie jest szeroko stosowane tam gdzie musimy zapewnić niezawodne rozwiązanie i wysokie SLA dla naszego środowiska. Poniżej przedstawie Wam wymagania wstępne oraz kroki instalacji Always On w trzy nodowym środowisku SQL Server 2019
Zacznijmy od potrzebnych zasobów dla naszego środowiska testowego:
- 4 maszyny wirtualne (kontroler domeny + trzy maszyny które będą nodami SQL)
- instalacja i konfiguracja systemów operacyjnych (w naszym przypadku Windows Server 2022 Standard), aktualizacje, przypisanie odpowiednich adresów IP, strefy czasowe itp
- dodanie roli kontrolera domeny na jednym z środowisk, wypromowanie kontrolera, wstępna konfiguracja Active Directory (w naszym przypadku domena o funkcjonalności na poziomie 2019, przygotowane OU dla SQL server ustawienie odpowiednich hostname, dodanie pozostałych trzech maszyn do domeny, utworzone konto gMSA dla usług SQL, instalacja konta gMSA na trzech przyszłych nodach)
- włączenie WinRM na trzech hostach dla nodów SQL (w naszym przykładzie role Windows Failover Cluster będziemy instalować zdalnie, w ten sam sposób dodamy reguły zapory)
- pobrane ISO MS SQL Server 2019
Nie będę opisywał procesu przygotowania powyższych elementów ale mając takie zasoby możemy przystąpić do pierwszych kroków instalacji i konfiguracji naszego Always On Availability Groups.
Zacznijmy od kontrolera Active Directory, otwórzmy w nim PowerShell ISE jako administrator i zainstalujmy na naszych trzech nodach rolę Windows Failover Cluster z pomocą takiego polecenia:
# sprawdzone.it
# remote install Windows Failover Cluster Feature
Invoke-Command -ComputerName vm01,vm02,vm03 -ScriptBlock {
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools -Restart
}
Sama instalacja chwile zajmę, po jej ukończeniu zobaczymy poniższe podsumowanie:
Przejdźmy na jeden z przyszłych nodów w celu konfiguracji klastra, z poziomu pulpitu otwórzmy Failower Cluster Manager i rozpocznijmy od walidacji konfiguracji:
W następnym kroku dodajemy wszystkie nasze maszyny które mają być nodami klastra:
Uruchamiamy wszystkie testy:
Weryfikujemy ewentualne informacje i ostrzeżenia – w naszym wypadku są to uwagi że maszyny mają tylko jedną kartę sieciową i stanowi to potencjalny punkt awarii.
Możemy już teraz rozpocząć właściwe tworzenie Windows Failover Cluster:
Nadajemy nazwę naszego klastra oraz wskazujemy jego przyszły adres IP (musi być wolny w chwili tworzenia):
Nie dodajemy dysków – ponieważ nie będziemy współdzielić zasobów dyskowych, każdy node Always On będzie miał swoją kopie bazy lokalnie na swoim dysku:
I klaster gotowy!
Sprawdzamy jeszcze jego działanie poprzez dodanie pustej roli w Failover Cluster Manager:
Wróćmy na nasz kontroler domeny i dodajmy jeszcze odpowiednie uprawnienia. Otwórzmy przystawkę Active Directory Users and Computer i w OU w którym mamy nasze nody i świeżo utworzony klaster dodajmy uprawnienia korzystając z zakładki Security:
Dodajmy nasz klaster:
Dajemy uprawnienia Full control:
UWAGA: w środowisku produkcyjnym powinniśmy maksymalnie ograniczać uprawnienia i z poziomu uprawnień zaawansowanych dodać tylko: Create Computer objects
Takie same uprawnienia jak dla OU nadajemy dla naszego obiektu klastra czyli sqlcluster – dodając tam 3 nasze nody – z tego względu że obiekt sqlcluster utworzy kolejny obiekt typu komputer wraz z dodaniem roli:
Z tak skonfigurowanym i działającym klastrem możemy przejść do instalacji MS SQL Server.
W naszym przykładzie wykonamy nadzorowaną instalacje z GUI na jednym z nodów a na dwóch pozostałych nodach postaramy zautomatyzować ten proces instalacją nienadzorowaną.
W przypadku klastra MS SQL Server konta użyte do obsługi usług SQL powinny być te same na wszystkich nodach – dotyczy się to również Always On. Podczas przygotowania środowiska utworzyliśmy i zainstalowaliśmy na każdym z przyszłych nodów jedno konto gMSA Group Managed Service Accounts. I to właśnie tego konta użyjemy do zarządzania usługami MS SQL Server, podając je podczas instalacji
Na każdym nodzie uruchamiamy instalator MS SQL Server i wybieramy opcje New SQL Server stand-alone (w przeciwieństwie do tego gdybyśmy konfigurowali SQL Server Failover Cluster) – w przypadku Always On każda z instancji działa oddzielnie.
Na potrzeby naszego przykładu przyśpieszamy proces instalacji rezygnując z Microsoft Update podczas procesu instalacji:
Ostrzeżenie dotyczące zapory, odpowiednie reguły dodamy za chwilę.
Z dostępnych funkcji aznaczamy tylko Database Engine Services
Dla porządku nazywamy każdą z naszych instancji: instance01, instance02, instance03
Nasze usługi uruchamiamy z użyciem konta gMSA o nazwie account_gMSA – wprowadzając je w polu Account Name pamietamy aby poprzedzić je nazwą domeny i dodać znak $ na końcu – nie będziemy zmuszeni do wprowadzania hasła zostanie to zrobione automatycznie za nas. Zmieniamy tryb uruchamiania usługi SQL Server Agent na automatyczny:
Zakładkę Collation ustawiamy zgodnie z naszymi danymi lokalizacyjnymi:
W naszym przykładzie ustawiamy autentykacje w trybie Mixed Mode, podajemy hasło dla SA i dodajemy bieżącego użytkownika jako administratora:
Ważne: zmieniamy katalogi lokalizacji! W naszym labie używamy instancji nazwanych zatem domyślnie ścieżka będzie zawierać nazwę instancji a to uniemożliw nam utworzenie Availbility Groups – lokalizacja baz musi mieć te same ścieżki na każdym nodzie:
W ten sam sposób zmieniamy lokalizacje dla TempDB:
Zakładkę MaxDOP również pozostawiamy z domyślną konfiguracją:
Zakładka Memory: środowisku produkcyjnym warto zdefiniować inaczej SQL Server „zje” wszystko – tutaj zostawiamy domyślne wartości:
Zakładka FILESTREAM również bez zmian:
Mamy gotową konfiguracje, i jej podsumowanie. Zanim rozpoczniemy właściwy proces instalacji kopiujemy ścieżkę do pliku konfiguracji, po drobnej edycji przyda się do nienadzorowanej instalacji na pozostałych maszynach – po co klikać jeszcze raz to samo na pozostałych nodach:
Instalacja na vm01 (pierwszym nodzie klastra) zakończyła się sukcesem, możemy więc czynność powtórzyć na pozostałych dwóch maszynach vm02 i vm02, oczywiście można to uprościć i zautomatyzować – po to mamy skopiowaną lokalizacje pliku ConfigFile.ini
Nasze instancje działają poprawnie, przejdźmy na pierwszego noda vm01 i otwórzmy SQL Server Configuration Manager, następnie włączmy w protokołach Named Pipes
Następnie na usługach wejdziemy we właściwości usługi SQL Server:
i włączymy Always On Availability Groups (nasza nazwa klastra podpowie się z automatu):
Nazwane instancje a takie utworzyliśmy: VM01\INSTANCE01 VM02\INSTANCE02 i VM03\INSTANCE03 domyślnie pracują na portach dynamicznych dlatego zmienimy je na standardowe dla usług SQL Server.
Otwieramy Sql Server Configuration Manager i wprowadzamy odpowiednia dla nas wartość np 1433:
Pozostaje jeszcze restart usługi SQL i powtórzenie tej czynności na pozostałych instancjach vm02 i vm03.
W międzyczasie na każdej maszynie zainstalujemy SQL Server Management Studio – będzie nam potrzebny do dalszych prac.
Bardzo ważną rzeczą jest kwestia ustawień zapory sieciowej na wszystkich trzech instancjach, proponuje dodanie wyjątków dla środowiska SQL zautomatyzować poniższym skryptem PowerShell. Skrypt możemy uruchomić z dowolnej maszyny – warunek WinRM:
# sprawdzone.it
# enabling SQL Server Ports
Invoke-Command -ComputerName vm01,vm02,vm03 -ScriptBlock {
New-NetFirewallRule -DisplayName “SQL Server” -Group "SQL Server" -Direction Inbound –Protocol TCP –LocalPort 1433 -Action allow
New-NetFirewallRule -DisplayName “SQL Admin Connection” -Group "SQL Server" -Direction Inbound –Protocol TCP –LocalPort 1434 -Action allow
New-NetFirewallRule -DisplayName “SQL Database Management” -Group "SQL Server" -Direction Inbound –Protocol UDP –LocalPort 1434 -Action allow
New-NetFirewallRule -DisplayName “SQL Service Broker” -Group "SQL Server" -Direction Inbound –Protocol TCP –LocalPort 4022 -Action allow
New-NetFirewallRule -DisplayName “SQL Server Browse Button Service” -Group "SQL Server" -Direction Inbound –Protocol UDP –LocalPort 1433 -Action allow
New-NetFirewallRule -DisplayName “SQL Server DBM/AG Endpoint” -Group "SQL Server" -Direction Inbound –Protocol TCP –LocalPort 5022 -Action allow
}Skoro mamy już SQL Server Management Studio dodajmy jeszcze uprawnienia SQL dla naszej usługi gMSA.
Na każdej instancji dodajemy role sysadmin dla usługi która startuje MS SQL Server:
Czas na szybkie podsumowanie naszych prac:
- mamy gotowy działający klaster Windows Failover (3 nody)
- na każdym z nodów klastra mamy zainstalowaną instancje MS SQL Server
- każdą z instancji odpowiednio skonfigurowaliśmy
- dodaliśmy uprawnienia
- utworzyliśmy reguły zapory
Rozpoczynamy właściwe tworzenie Always On Availabity Groups i aby to zrobić potrzebujemy jeszcze tylko bazy danych.
W naszym przykładzie użyjemy bazy AdventureWorks – należy ją pobrać i odtworzyć. Zrobimy to na nodzie pierwszym klastra czyli vm01 z poziomu SSMS
Aby baza mogła być w grupie Always On musi mieć model recovery w trybie Full – zmieniamy wiec ustawienia naszej AdventureWorks (domyślnie ma simple):
Mamy już bazę, możemy przystąpić do tworzenia naszej grupy Always On.
Uruchamiamy SSMS i przechodzimy na Always In High Availability –> Availability Groups . Użyjemy kreatora do utworzenia naszej pierwszej grupy wybieramy: New Availability Group Wizard
Nadajemy nazwę dla naszej grupy: ag01, wybieramy typ klastra, dajemy check na Database Level Health Detection (gdy baza danych nie jest już w stanie online, gdy coś pójdzie nie tak, uruchamia się automatyczne przełączanie awaryjne):
Wybieramy bazę którą chcemy dodać do grupy, w naszym przykładzie status bazy wymaga wykonania wcześniej pełnego backupu (klikamy w SSMS na bazę i wykonujemy jej backup)
Wracamy do kreatora odświeżamy i zaznaczamy naszą bazę:
W oknie repliki dodajemy kolejnego noda który będzie od tej chwili Repliką w naszej ag01:
Poprawne nawiązanie połączenia z instancją MS SQL która chcemy dodać do Grupy Dostępności skutkuje dodaniem go do listy replik. W naszym przykładzie dodajemy wszystkie nasze pozostałe instancje (vm02 i vm03). Dla każdej repliki wybieramy odpowiedni tryb dostępności, zaznaczamy lub nie Automatic Failover.
Zakładkę Endpoint pozostawiamy bez zmian:
Tak samo jeżeli chodzi o backup, ekskludujemy replikę nr 3, pozostawiając resztę bez zmian:
nie tworzymy Listenera (zrobimy to ręcznie za chwile)
Ustawienia Read-Only Routing również pozostawiamy na potrzeby testu bez zmian:
Pierwszą synchronizacje danych również pozostawimy automatyczną (bez zmian):
Sprawdzamy naszą konfiguracje (ostrzeżenie o braku Listenera ignorujemy – tak jak pisałem wcześniej będziemy go konfigurować ręcznie):
Grupa Always On o nazwie ag01 utworzona – przejdźmy do naszego SSMS i odświeżamy widok – możemy również połączyć się z drugą i trzecią instancją – trwa synchronizacja – poczekajmy chwilę
W tym czasie możemy utworzyć Listenera, nadajemy mu nazwę dns, w naszym wypadku będzie to proste: sql
Wskazujemy port np 1433 i dajemy adres IP (musi być wolny):
Listener jest gotowy i widoczny z poziomu SSMS:
Otwórzmy jeszcze na chwile Failover Cluster Manager i sprawdźmy czy utworzyła się odpowiednia rola o nazwie naszej Availabiliy Group:
Brawo mamy działające Always On – wszystko działa poprawnie, sprawdzimy jeszcze dashboard naszej grupy:
Spróbujmy też połączyć się z naszym Listenerem po jego adresie IP, zrobię to z zupełnie innej maszyny (poza domeną)
Gratuluje mamy działające środowisko Always On High Availability Groups!
Pobawcie się jeszcze testując kontrolowane i nie kontrolowane przełączenia – pingujcie w tym czasie adres/nazwę Listenera – zobaczcie jak działają usługi – prawda że wysoka dostępność SQL?