Zawsze włączone grupy dostępności programu SQL Server to najnowsza technologia firmy Microsoft służąca zaspokajaniu potrzeb organizacji korzystających z programu SQL Server w zakresie wysokiej dostępności i odzyskiwania po awarii. Dużą zaletą AlwaysOn jest możliwość obsługi zarówno HA, jak i DR w jednej implementacji. Kluczowe korzyści z AlwaysOn, których doświadczyliśmy, są następujące:
Możemy zgrupować powiązane bazy danych w ramach jednej grupy dostępności i w razie potrzeby przełączyć je w tryb awaryjny. Jest to szczególnie przydatne w przypadku aplikacji, które zależą od więcej niż jednej bazy danych, takich jak Microsoft Office SharePoint, Microsoft Lync lub Sage.
W porównaniu z instancjami klastra pracy awaryjnej SQL Server, okazuje się, że pamięć masowa jako pojedynczy punkt awarii została wyeliminowana, ponieważ każda instancja stanowiąca replikę ma przypisaną własną pamięć masową.
Dzięki AlwaysOn możliwe jest jednoczesne skonfigurowanie HA i DR. Osiąga się to poprzez tworzenie klastrów pracy awaryjnej systemu Windows z wieloma lokacjami jako podstawy konfiguracji AlwaysOn. Wykonywanie zmiany ról podczas korzystania z AlwaysOn jest znacznie prostsze niż w przypadku korzystania z przesyłania dziennika transakcji.
Zależność WSFC
W przypadku korzystania z programu SQL Server AlwaysOn AG na potrzeby wysokiej dostępności i odzyskiwania po awarii najpierw należy skonfigurować klaster pracy awaryjnej systemu Windows. AlwaysOn AGs zależą od WFCS, aby zarządzać AlwaysOn AG jako rolą, która składa się z takich zasobów klastra, jak nazwa grupy dostępności, nazwa udziału plików, nazwa odbiornika i adres IP.
Rys. 1 AlwaysOn AG jako zasób klastra
Kworum
Kworum to minimalna liczba głosów wymagana do uzyskania większości w klastrze pracy awaryjnej. Kworum określa liczbę awarii węzłów, które może wytrzymać klaster. Za pośrednictwem sieci prywatnej na porcie 3343 wszystkie węzły klastra przekazują informacje o stanie zdrowia i monitorowaniu zasobów. W przypadku niepowodzenia głosy pokazują, które węzły mają status „Up” i na których węźle zasoby muszą być włączone.
Od systemu Windows Server 2012 maksymalna obsługiwana liczba węzłów klastra wynosi szesnaście. Jednak w większości znanych mi środowisk często występują klastry dwuwęzłowe. Klaster składający się z dwóch węzłów stwarza mały problem pod względem osiągnięcia kworum, ponieważ każdy węzeł ma jeden głos i jeśli wystąpi problem z komunikacją między nimi, każdy z nich może założyć, że drugi nie jest zdrowy. Nazywa się to scenariuszem rozszczepienia mózgu. Scenariusze z rozszczepieniem mózgu są powodem skonfigurowania rozstrzygania rozstrzygnięć, takiego jak dysk lub udział plików.
Jeśli masz nieparzystą liczbę węzłów, nie jest konieczne konfigurowanie rozstrzygania remisów. Dynamic Quorum Configuration i Dynamic Witness zostały wprowadzone odpowiednio w systemach Windows Server 2012 i Windows Server 2012 R2. Za pomocą tych technologii system Windows automatycznie redystrybuuje głosy w klastrze, dzięki czemu liczba węzłów w klastrze nie ma znaczenia przy ustanawianiu Kworum. Głos węzła klastra jest usuwany przez ustawienie właściwości klastra „NodeWeight” na 0. Te funkcje są domyślnie włączone.
Rys. 2 Pobieranie wszystkich właściwości klastra za pomocą PowerShell
Rys. 3 przypisane głosy w dwuwęzłowym klastrze
Korzystanie z PowerShell
Za pomocą polecenia Get-Cluster programu PowerShell można sprawdzić konfigurację kworum w klastrze systemu Windows. Rys. 4 pokazuje, jak sprawdzić wszystkie właściwości klastra związane z Quorum w klastrze, a rys. 5 przedstawia właściwości wskaźnika udostępniania plików. Istnieje wiele innych poleceń PowerShell do sprawdzania i zarządzania klastrami Windows.
Get-Cluster | Format-List –Property *Quorum*
Rys. 4 Polecenie PowerShell do sprawdzenia właściwości związanych z kworum
Get-ClusterResource
Get-ClusterResource -Name "File Share Witness" | Get-ClusterParameter
Rys. 5 Polecenie PowerShell do sprawdzania szczegółów właściwości świadków udostępniania plików
Tryby kworum
Windows Server Failover Cluster umożliwia skonfigurowanie do czterech trybów. Tryby kworum to zasadniczo opcje, które wybierasz, aby określić, w jaki sposób klaster będzie obsługiwał awarie węzłów.
1. Większość węzłów
Ten tryb kworum może wytrzymać awarie do (n/2)-1 węzłów. Jest zalecany dla klastrów o nieparzystej liczbie węzłów. Na przykład w klastrze z pięcioma węzłami awaria dwóch węzłów spowodowałaby awarię klastra.
2. Większość węzłów i dysków
Może podtrzymywać awarie do połowy liczby węzłów klastra, o ile monitor dysku (nazywany również dyskiem kworum) pozostaje w trybie online.
3. Większość węzłów i udziałów plików
Ten tryb kworum może wytrzymać awarie nawet o połowę mniejszej liczby węzłów klastra, o ile udział plików pozostaje dostępny. Począwszy od systemu Windows Server 2012 R2, firma Microsoft zaleca, aby podczas tworzenia klastra zawsze konfigurować monitor (dysk lub udział plików).
4. Brak większości
To jest tryb Tylko dysk. Ten tryb może podtrzymywać awarie wszystkich węzłów z wyjątkiem jednego, dopóki dysk jest w trybie online. Ten tryb nie jest zalecany, ponieważ dysk staje się pojedynczym punktem awarii.
Wskazówki dotyczące konfiguracji większości węzłów i udziałów plików
Zawsze włączone grupy dostępności obsługują tylko dwa z tych trybów kworum:większość węzłów oraz większość węzłów i udziałów plików. Podczas tworzenia klastra AlwaysOn Availability Group programu SQL Server należy pamiętać o kilku kwestiach:
1. Korzystanie z serwerów fizycznych
Podczas konfigurowania dwuwęzłowego klastra w trybie AlwaysOn węzły muszą znajdować się w różnych fizycznych stojakach. Serwer, na którym znajduje się Twój udział plików, musi znajdować się w trzeciej szafie.
2. Korzystanie z serwerów wirtualnych
Podczas konfigurowania dwuwęzłowego klastra dla funkcji AlwaysOn Twoje maszyny wirtualne muszą znajdować się na osobnych hostach. Maszyna wirtualna obsługująca Twój udział plików musi znajdować się na trzecim hoście.
3. Klastrowanie wielu witryn
Podczas konfigurowania wielowęzłowego klastra dla funkcji AlwaysOn w centrach danych, w idealnym scenariuszu serwer plików hostujący udział plików musi znajdować się w trzecim centrum danych.
4. Uprawnienia do udostępniania plików
Obiekt nazwy klastra powinien mieć uprawnienia do udziału plików używanego jako świadek kworum. Bez tego zwykle przy próbie skonfigurowania Świadka kworum wystąpiły błędy.
Rys. 6 uprawnień do udostępniania plików
5. Konfiguracja online
Tryby kworum można skonfigurować, gdy klaster jest w trybie online. Dlatego w przypadku awarii serwera udostępniania plików lub konieczności jego ponownej konfiguracji, upewnij się, że dokonasz szybkiej ponownej konfiguracji, aby zagwarantować, że nie wystąpią nieoczekiwane awarie, szczególnie w klastrze z dwoma węzłami.
Przypadek użycia na żywo
Schemat na Rys. 7 przedstawia prawdziwy klaster Multi-Site AlwaysOn AG. Jest to czterowęzłowy klaster z dwoma węzłami w jednej lokacji i dwoma innymi w zdalnej lokacji DR. Serwer plików, na którym znajduje się udział pliku używany jako rozstrzygający, znajduje się w trzecim centrum danych. W tym przypadku serwer plików znajduje się w tym samym mieście, co główne centrum danych, ale jeśli możesz sobie na to pozwolić, idealnie byłoby mieć serwer plików w innym mieście. Komunikacja między trzema stronami musi być dobrej jakości, aby uniknąć fałszywych alarmów.
Na przykład w naszej początkowej implementacji tego klastra użyliśmy „Synchronicznej replikacji z automatycznym przełączaniem awaryjnym” w witrynach Live i DR. Niejednokrotnie doświadczyliśmy usterki w komunikacji, która spowodowała automatyczne przełączenie awaryjne na stronę DR i ujawniła błąd w naszej konfiguracji. Spowodowało to, że nazwa odbiornika została rozpoznana na skojarzone adresy IP w lokacji DR, a klienci nie mogli się już łączyć, ponieważ komunikacja z tym nowym adresem IP nie była dozwolona w zaporach sieciowych. Po prostu nie udało nam się wrócić do lokacji głównej, aby złagodzić problem i zmieniliśmy konfigurację na „Replikacja asynchroniczna z ręcznym przełączaniem awaryjnym” dla węzłów znajdujących się w różnych centrach danych. Planujemy omówić aspekt rozwiązywania nazw w naszym następnym artykule „Zawsze włączony”.
Rys. 7 Prawdziwy przypadek użycia
Wniosek
Funkcja AlwaysOn Availability Groups została wprowadzona w SQL Server 2012 i jest najnowszą technologią firmy Microsoft, która zaspokaja potrzeby zarówno w zakresie wysokiej dostępności, jak i odzyskiwania po awarii. Konfigurowanie grup dostępności AlwaysOn zależy w dużej mierze od usługi klastra pracy awaryjnej systemu Windows. Z kolei klastry pracy awaryjnej w dużej mierze zależą od prawidłowej konfiguracji kworum. Podczas kompilowania AlwaysOn na klastrach Multi-Site Clusters naprawdę ma znaczenie opóźnienie między węzłami w różnych witrynach i udziałem plików używanym jako arbitra. Upewnij się, że konfiguracja kworum jest zawsze w najlepszym stanie, aby uniknąć nieoczekiwanych zachowań z grupami dostępności.
Referencje
Przegląd zawsze włączonych grup dostępności
Klaster pracy awaryjnej Windows z SQL Server
Dokumentacja PowerShell
Zrozumienie kworum klastra trybu failover systemu Windows Server
