Klaster trybu failover systemu Windows Server z programem SQL Server na maszynach wirtualnych platformy Azure

Artykuł
07/31/2023

Dotyczy:SQL Server na maszynie wirtualnej platformy Azure

W tym artykule opisano różnice w przypadku korzystania z funkcji klastra trybu failover systemu Windows Server z programem SQL Server na maszynach wirtualnych platformy Azure w celu zapewnienia wysokiej dostępności i odzyskiwania po awarii (HADR), takich jak zawsze włączone grupy dostępności lub wystąpienia klastra trybu failover (FCI).

Aby dowiedzieć się więcej na temat samej funkcji systemu Windows, zobacz dokumentację klastra trybu failover systemu Windows Server.

Omówienie

Rozwiązania wysokiej dostępności programu SQL Server w systemie Windows, takie jak zawsze włączone grupy dostępności lub wystąpienia klastra trybu failover (FCI, failover cluster instances) polegają na podstawowej usłudze klastra trybu failover systemu Windows Server (WSFC).

Usługa klastrowania monitoruje połączenia sieciowe i kondycję węzłów w klastrze. To monitorowanie jest dodatkiem do kontroli kondycji, które program SQL Server wykonuje w ramach funkcji grupy dostępności lub wystąpienia klastra trybu failover. Jeśli usługa klastrowania nie może nawiązać połączenia z węzłem lub jeśli rola grupy dostępności lub wystąpienia klastra klastra stanie się w złej kondycji, usługa klastra inicjuje odpowiednie akcje odzyskiwania w celu odzyskania i przełączania aplikacji i usług w tryb online, w tym samym lub w innym węźle w klastrze.

Monitorowanie kondycji klastra

Aby zapewnić wysoką dostępność, klaster musi zapewnić kondycję różnych składników tworzących rozwiązanie klastrowane. Usługa klastra monitoruje kondycję klastra na podstawie wielu parametrów systemu i sieci w celu wykrywania awarii i reagowania na nie.

Ustawienie progu deklarowania błędu jest ważne w celu osiągnięcia równowagi między natychmiastowym reagowaniem na awarię i unikaniem fałszywych błędów.

Istnieją dwie strategie monitorowania:

Monitorowanie	opis
Agresywne	Zapewnia szybkie wykrywanie awarii i odzyskiwanie twardych awarii, co zapewnia najwyższy poziom dostępności. Usługa klastrowania i program SQL Server są mniej forgiving awarii przejściowej, a w niektórych sytuacjach może przedwcześnie przejść w tryb failover zasobów w przypadku przejściowych awarii. Po wykryciu błędu akcja naprawcza, która następuje, może zająć dodatkowy czas.
Zrelaksowany	Zapewnia więcej możliwości wykrywania błędów z większą tolerancją dla krótkich przejściowych problemów z siecią. Unika przejściowych awarii, ale także wprowadza ryzyko opóźnienia wykrywania prawdziwej awarii.

Agresywne ustawienia w środowisku klastra w chmurze mogą prowadzić do przedwczesnych awarii i dłuższych awarii, dlatego zalecana jest złagodzona strategia monitorowania dla klastrów trybu failover na maszynach wirtualnych platformy Azure. Aby dostosować ustawienia progowe, zobacz najlepsze rozwiązania dotyczące klastra, aby uzyskać więcej szczegółów.

Puls klastra

Podstawowe ustawienia wpływające na bicie serca klastra i wykrywanie kondycji między węzłami:

Ustawienie	opis
Opóźnienie	Określa częstotliwość wysyłania pulsów klastra między węzłami. Opóźnienie to liczba sekund przed wysłaniem następnego pulsu. W tym samym klastrze mogą istnieć różne ustawienia opóźnienia skonfigurowane między węzłami w tej samej podsieci i między węzłami, które znajdują się w różnych podsieciach.
Próg	Próg to liczba pulsów, które mogą zostać pominięte przed podjęciem akcji odzyskiwania przez klaster. W tym samym klastrze mogą istnieć różne ustawienia progowe skonfigurowane między węzłami w tej samej podsieci i między węzłami, które znajdują się w różnych podsieciach.

Wartości domyślne tych ustawień mogą być zbyt niskie w przypadku środowisk w chmurze i mogą powodować niepotrzebne błędy z powodu przejściowych problemów z siecią. Aby zapewnić większą tolerancję, użyj ustawień złagodzonego progu dla klastrów trybu failover na maszynach wirtualnych platformy Azure. Aby uzyskać więcej szczegółowych informacji, zobacz najlepsze rozwiązania dotyczące klastra.

Kworum

Mimo że klaster dwuwęźle będzie działać bez zasobu kworum, klienci muszą ściśle używać zasobu kworum do obsługi produkcyjnej. Walidacja klastra nie przekaże żadnego klastra bez zasobu kworum.

Technicznie klaster z trzema węzłami może przetrwać utratę jednego węzła (do dwóch węzłów) bez zasobu kworum. Jednak po wyłączeniu klastra do dwóch węzłów istnieje ryzyko, że klastrowane zasoby zostaną przełączone w tryb offline, aby zapobiec scenariuszowi podziału mózgu, jeśli węzeł zostanie utracony lub wystąpi błąd komunikacji między węzłami. Skonfigurowanie zasobu kworum umożliwi zasobom klastra pozostanie w trybie online tylko z jednym węzłem w trybie online.

Monitor dysku jest najbardziej odporną opcją kworum, ale aby użyć monitora dysku w programie SQL Server na maszynie wirtualnej platformy Azure, musisz użyć dysku udostępnionego platformy Azure, który nakłada pewne ograniczenia na rozwiązanie wysokiej dostępności. W związku z tym należy użyć monitora dysku podczas konfigurowania wystąpienia klastra trybu failover z dyskami udostępnionymi platformy Azure, w przeciwnym razie użyj monitora w chmurze, jeśli to możliwe.

W poniższej tabeli wymieniono opcje kworum dostępne dla programu SQL Server na maszynach wirtualnych platformy Azure:

	Monitor chmury	Monitor dysku	Monitor udziału plików
Obsługiwany system operacyjny	Windows Server 2016+	Wszystko	Wszystko
Opis	Monitor w chmurze to typ monitora kworum klastra trybu failover, który używa platformy Microsoft Azure do głosowania w kworum klastra. Domyślny rozmiar wynosi około 1 MB i zawiera tylko sygnaturę czasową. Monitor w chmurze jest idealny do wdrożeń w wielu lokacjach, wielu strefach i wielu regionach. Jeśli to możliwe, użyj monitora w chmurze, chyba że masz rozwiązanie klastra trybu failover z udostępnionym magazynem.	Monitor dysku to mały dysk klastrowany w grupie Dostępny magazyn klastra. Ten dysk jest wysoce dostępny i może przejść w tryb failover między węzłami. Zawiera kopię bazy danych klastra o domyślnym rozmiarze mniejszym niż 1 GB. Monitor dysku jest preferowaną opcją kworum dla każdego klastra, który korzysta z dysków udostępnionych platformy Azure (lub dowolnego rozwiązania udostępnionego dysku, takiego jak współużytkowany interfejs SCSI, iSCSI lub sieć SAN fibre channel). Klastrowany udostępniony wolumin nie może być używany jako monitor dysku. Skonfiguruj dysk udostępniony platformy Azure jako monitor dysku.	Monitor udziału plików to udział plików SMB, który jest zwykle skonfigurowany na serwerze plików z systemem Windows Server. Przechowuje informacje klastrowania w pliku witness.log, ale nie przechowuje kopii bazy danych klastra. Na platformie Azure można skonfigurować udział plików na oddzielnej maszynie wirtualnej w tej samej sieci wirtualnej. Użyj monitora udziału plików, jeśli monitor dysku lub monitor w chmurze jest niedostępny w danym środowisku.

Aby rozpocząć, zobacz Konfigurowanie kworum klastra.

Nazwa sieci wirtualnej

Aby dopasować środowisko lokalne do nawiązywania połączenia z odbiornikiem grupy dostępności lub wystąpieniem klastra trybu failover, wdróż maszyny wirtualne programu SQL Server w wielu podsieciach w tej samej sieci wirtualnej. Posiadanie wielu podsieci neguje potrzebę dodatkowej zależności od usługi Azure Load Balancer w celu kierowania ruchu do rozwiązania HADR. Aby dowiedzieć się więcej, zobacz Grupy dostępności z wieloma podsieciami i Wystąpienie klastra trybu failover z wieloma podsieciami.

W tradycyjnym środowisku lokalnym klastrowane zasoby, takie jak wystąpienia klastra trybu failover lub zawsze włączone grupy dostępności, polegają na nazwie sieci wirtualnej w celu kierowania ruchu do odpowiedniego miejsca docelowego — wystąpienia klastra trybu failover lub odbiornika zawsze włączonej grupy dostępności. Nazwa wirtualna wiąże adres IP w systemie DNS, a klienci mogą używać nazwy wirtualnej lub adresu IP, aby nawiązać połączenie z obiektem docelowym wysokiej dostępności, niezależnie od tego, który węzeł jest obecnie właścicielem zasobu. Sieć wirtualna to nazwa sieci i adres zarządzany przez klaster, a usługa klastra przenosi adres sieciowy z węzła do węzła podczas zdarzenia trybu failover. Podczas awarii adres jest przełączony w tryb offline w oryginalnej repliki podstawowej i jest w trybie online w nowej repliki podstawowej.

W usłudze Azure Virtual Machines w jednej podsieci dodatkowy składnik jest niezbędny do kierowania ruchu z klienta do nazwy sieci wirtualnej zasobu klastrowanego (wystąpienia klastra trybu failover lub odbiornika grupy dostępności). Na platformie Azure moduł równoważenia obciążenia przechowuje adres IP dla sieci wirtualnej, z której korzystają klastrowane zasoby programu SQL Server i jest niezbędny do kierowania ruchu do odpowiedniego celu wysokiej dostępności. Moduł równoważenia obciążenia wykrywa również błędy ze składnikami sieciowymi i przenosi adres do nowego hosta.

Moduł równoważenia obciążenia dystrybuuje przepływy przychodzące, które docierają do frontonu, a następnie kieruje ten ruch do wystąpień zdefiniowanych przez pulę zaplecza. Przepływ ruchu można skonfigurować przy użyciu reguł równoważenia obciążenia i sond kondycji. W przypadku wystąpienia klastra trybu failover programu SQL Server wystąpienia puli zaplecza to maszyny wirtualne platformy Azure z uruchomionym programem SQL Server, a w przypadku grup dostępności pula zaplecza jest odbiornikiem. Podczas korzystania z modułu równoważenia obciążenia występuje niewielkie opóźnienie pracy w trybie failover, ponieważ sonda kondycji przeprowadza kontrole aktywne co 10 sekund domyślnie.

Aby rozpocząć, dowiedz się, jak skonfigurować usługę Azure Load Balancer dla wystąpienia klastra trybu failover lub grupy dostępności.

Obsługiwany system operacyjny: wszystkie
Obsługiwana wersja SQL: wszystkie
Obsługiwane rozwiązanie HADR: wystąpienie klastra trybu failover i grupa dostępności

Konfiguracja sieci wirtualnej sieci wirtualnej może być uciążliwa, jest to dodatkowe źródło awarii, może to spowodować opóźnienie wykrywania błędów, a koszty związane z zarządzaniem dodatkowym zasobem są związane z zarządzaniem dodatkowym zasobem. Aby rozwiązać niektóre z tych ograniczeń, program SQL Server wprowadził obsługę funkcji Nazwa sieci rozproszonej.

Nazwa sieci rozproszonej

Aby dopasować środowisko lokalne do nawiązywania połączenia z odbiornikiem grupy dostępności lub wystąpieniem klastra trybu failover, wdróż maszyny wirtualne programu SQL Server w wielu podsieciach w tej samej sieci wirtualnej. Posiadanie wielu podsieci neguje potrzebę dodatkowej zależności od sieci rozproszonej w celu kierowania ruchu do rozwiązania HADR. Aby dowiedzieć się więcej, zobacz Grupy dostępności z wieloma podsieciami i Wystąpienie klastra trybu failover z wieloma podsieciami.

W przypadku maszyn wirtualnych z programem SQL Server wdrożonych w jednej podsieci funkcja nazwy sieci rozproszonej umożliwia klientom programu SQL Server łączenie się z wystąpieniem klastra trybu failover programu SQL Server lub odbiornikiem grupy dostępności bez używania modułu równoważenia obciążenia. Funkcja sieci rozproszonej jest dostępna od programu SQL Server 2016 SP3, PROGRAMU SQL Server 2017 CU25, programu SQL Server 2019 CU8 w systemie Windows Server 2016 lub nowszym.

Po utworzeniu zasobu sieci rozproszonej klaster wiąże nazwę DNS z adresami IP wszystkich węzłów w klastrze. Klient spróbuje nawiązać połączenie z każdym adresem IP na tej liście, aby znaleźć zasób do nawiązania połączenia. Ten proces można przyspieszyć, określając MultiSubnetFailover=True w parametrach połączenia. To ustawienie nakazuje dostawcy równoległe wypróbowanie wszystkich adresów IP, aby klient mógł natychmiast nawiązać połączenie z klastrem trybu failover lub odbiornikiem.

Zalecana jest nazwa sieci rozproszonej za pośrednictwem modułu równoważenia obciążenia, jeśli jest to możliwe, ponieważ:

Kompleksowe rozwiązanie jest bardziej niezawodne, ponieważ nie trzeba już utrzymywać zasobu modułu równoważenia obciążenia.
Wyeliminowanie sond modułu równoważenia obciążenia minimalizuje czas trwania trybu failover.
Nazwa sieci rozproszonej upraszcza aprowizowanie wystąpienia klastra trybu failover lub odbiornik grupy dostępności i zarządzanie nim za pomocą programu SQL Server na maszynach wirtualnych platformy Azure.

Większość funkcji programu SQL Server działa w sposób niewidoczny dla klastra trybu failover i grup dostępności podczas korzystania z nazwy sieci rozproszonej, ale istnieją pewne funkcje, które mogą wymagać specjalnej uwagi.

Obsługiwany system operacyjny: Windows Server 2016 lub nowszy
Obsługiwana wersja SQL: SQL Server 2019 CU2 (FCI) i SQL Server 2019 CU8 (AG)
Obsługiwane rozwiązanie HADR: wystąpienie klastra trybu failover i grupa dostępności

Aby rozpocząć, dowiedz się, jak skonfigurować zasób nazwy rozproszonej sieci dla wystąpienia klastra trybu failover lub grupy dostępności.

Podczas korzystania z nazwy sieci rozproszonej z innymi funkcjami programu SQL Server należy wziąć pod uwagę dodatkowe zagadnienia. Aby dowiedzieć się więcej, zobacz Współdziałanie klastra trybu failover i sieci rozproszonej sieci rozproszonej oraz współdziałanie sieci rozproszonej i sieci rozproszonej.

Akcje związane z odzyskiwaniem

Usługa klastrowania podejmuje działania naprawcze po wykryciu błędu. Może to spowodować ponowne uruchomienie zasobu w istniejącym węźle lub przełączenie zasobu w tryb failover do innego węzła. Po zainicjowaniu środków naprawczych ich ukończenie zajmuje trochę czasu.

Na przykład ponownie uruchomiona grupa dostępności jest dostępna w trybie online zgodnie z następującą sekwencją:

Adres IP odbiornika jest dostępny w trybie online
Nazwa sieci odbiornika jest w trybie online
Grupa dostępności jest dostępna w trybie online
Poszczególne bazy danych przechodzą przez odzyskiwanie, co może zająć trochę czasu w zależności od wielu czynników, takich jak długość dziennika ponownego wykonania. Połączenia są kierowane przez odbiornik tylko wtedy, gdy baza danych zostanie w pełni odzyskana. Aby dowiedzieć się więcej, zobacz Szacowanie czasu pracy w trybie failover (RTO) .

Ponieważ odzyskiwanie może zająć trochę czasu, agresywne monitorowanie ustawione w celu wykrycia awarii w ciągu 20 sekund może spowodować awarię minut, jeśli wystąpi zdarzenie przejściowe (takie jak konserwacja maszyny wirtualnej platformy Azure zachowująca pamięć). Ustawienie monitorowania na bardziej zrelaksowaną wartość 40 sekund może pomóc uniknąć dłuższej przerwy w działaniu usługi.

Aby dostosować ustawienia progowe, zobacz najlepsze rozwiązania dotyczące klastra, aby uzyskać więcej szczegółów.

Lokalizacja węzła

Węzły w klastrze systemu Windows na maszynach wirtualnych na platformie Azure mogą być fizycznie oddzielone w tym samym regionie świadczenia usługi Azure lub mogą znajdować się w różnych regionach. Odległość może powodować opóźnienie sieci, podobnie jak rozmieszczenie węzłów klastra między lokalizacjami we własnych obiektach. W środowiskach w chmurze różnica polega na tym, że w regionie może nie być świadomy odległości między węzłami. Ponadto niektóre inne czynniki, takie jak składniki fizyczne i wirtualne, liczba przeskoków itp. może również przyczynić się do zwiększenia opóźnienia. Jeśli opóźnienie między węzłami jest problemem, rozważ umieszczenie węzłów klastra w grupie umieszczania w pobliżu, aby zagwarantować bliskość sieci.

Limity zasobów

Podczas konfigurowania maszyny wirtualnej platformy Azure określasz limity zasobów obliczeniowych dla procesora CPU, pamięci i operacji we/wy. Obciążenia wymagające większej ilości zasobów niż zakupiona maszyna wirtualna platformy Azure lub limity dysków mogą powodować problemy z wydajnością maszyny wirtualnej. Obniżenie wydajności może spowodować niepowodzenie sprawdzania kondycji usługi klastra lub funkcji wysokiej dostępności programu SQL Server. Wąskie gardła zasobów mogą sprawić, że węzeł lub zasób pojawią się w dół do klastra lub programu SQL Server.

Intensywne operacje we/wy SQL lub operacje konserwacji, takie jak tworzenie kopii zapasowych, indeks lub konserwacja statystyk, może spowodować, że maszyna wirtualna lub dysk osiągną limity przepływności operacji we/wy na sekundę lub MBPS, co może spowodować, że program SQL Server nie odpowiada na kontrolę IsAlive/LooksAlive.

Jeśli w programie SQL Server występują nieoczekiwane przejścia w tryb failover, upewnij się, że przestrzegasz wszystkich najlepszych rozwiązań dotyczących wydajności i monitoruj serwer pod kątem ograniczenia na poziomie dysku lub maszyny wirtualnej.

Konserwacja platformy Azure

Podobnie jak każda inna usługa w chmurze, platforma Azure okresowo aktualizuje swoją platformę, aby zwiększyć niezawodność, wydajność i bezpieczeństwo infrastruktury hosta dla maszyn wirtualnych. Zakres aktualizacji obejmuje tematykę od poprawek składników oprogramowania w środowisku hostingu do uaktualniania składników sieci lub likwidowania sprzętu.

Większość aktualizacji platformy nie ma wpływu na maszyny wirtualne klienta. Jeśli aktualizacja nie ma wpływu na nie jest możliwa, platforma Azure wybiera mechanizm aktualizacji, który ma najmniejszy wpływ na maszyny wirtualne klienta. Większość konserwacji niezerowej wstrzymuje maszynę wirtualną przez mniej niż 10 sekund. W niektórych przypadkach platforma Azure używa mechanizmów konserwacji zachowujących pamięć. Te mechanizmy wstrzymuje maszynę wirtualną przez maksymalnie 30 sekund i zachowuje pamięć w pamięci RAM. Maszyna wirtualna jest następnie wznawiana, a jej zegar jest automatycznie synchronizowany.

Konserwacja zachowująca pamięć działa dla ponad 90 procent maszyn wirtualnych platformy Azure. Nie działa w przypadku serii G, M, N i H. Platforma Azure coraz częściej korzysta z technologii migracji na żywo i ulepsza mechanizmy konserwacji chroniące pamięć w celu skrócenia czasu trwania wstrzymania. Gdy maszyna wirtualna jest migrowana na żywo do innego hosta, niektóre wrażliwe obciążenia, takie jak PROGRAM SQL Server, mogą spowodować niewielkie obniżenie wydajności w ciągu kilku minut poprzedzających wstrzymanie maszyny wirtualnej.

Wąskie gardło zasobów podczas konserwacji platformy może sprawić, że grupa dostępności lub wystąpienie klastra wystąpią w dół do usługi klastra. Aby dowiedzieć się więcej, zobacz sekcję Limity zasobów w tym artykule.

Jeśli używasz agresywnego monitorowania klastra, rozszerzona pauza maszyny wirtualnej może wyzwolić tryb failover. Przejście w tryb failover często spowoduje więcej przestojów niż wstrzymanie konserwacji, dlatego zaleca się użycie zrelaksowanego monitorowania w celu uniknięcia wyzwolenia trybu failover podczas wstrzymania maszyny wirtualnej w celu przeprowadzenia konserwacji. Zobacz najlepsze rozwiązania dotyczące klastra, aby uzyskać więcej informacji na temat ustawiania progów klastra na maszynach wirtualnych platformy Azure.

Ograniczenia

Podczas pracy z klastrem trybu failover lub grup dostępności i programu SQL Server na maszynach wirtualnych platformy Azure należy wziąć pod uwagę następujące ograniczenia.

MSDTC

Usługa Azure Virtual Machines obsługuje koordynatora transakcji rozproszonych firmy Microsoft (MSDTC) w systemie Windows Server 2019 z magazynem na udostępnionych woluminach klastrowanych (CSV) i w usłudze Azure Load Balancer w warstwie Standardowa lub na maszynach wirtualnych programu SQL Server korzystających z dysków udostępnionych platformy Azure.

W usłudze Azure Virtual Machines usługa MSDTC nie jest obsługiwana w systemie Windows Server 2016 lub starszym z udostępnionymi woluminami klastra, ponieważ:

Nie można skonfigurować klastrowanego zasobu MSDTC do korzystania z magazynu udostępnionego. W systemie Windows Server 2016, jeśli tworzysz zasób MSDTC, nie będzie on pokazywał żadnego udostępnionego magazynu dostępnego do użycia, nawet jeśli magazyn jest dostępny. Ten problem został rozwiązany w systemie Windows Server 2019.
Podstawowy moduł równoważenia obciążenia nie obsługuje portów RPC.

Następne kroki

Teraz, po zapoznaniu się z różnicami w przypadku korzystania z klastra trybu failover systemu Windows z programem SQL Server na maszynach wirtualnych platformy Azure, dowiedz się więcej o grupach dostępności funkcji wysokiej dostępności lub wystąpieniach klastra trybu failover. Jeśli wszystko jest gotowe do rozpoczęcia pracy, zapoznaj się z najlepszymi rozwiązaniami dotyczącymi zaleceń dotyczących konfiguracji.