Najlepsze rozwiązania dotyczące konfiguracji wysokiej dostępności i odzyskiwania po awarii (program SQL Server na maszynach wirtualnych platformy Azure)

  • Artykuł

Dotyczy:SQL Server na maszynie wirtualnej platformy Azure

Klaster trybu failover systemu Windows Server jest używany do wysokiej dostępności i odzyskiwania po awarii (HADR) z programem SQL Server na maszynach wirtualnych platformy Azure.

Ten artykuł zawiera najlepsze rozwiązania dotyczące konfiguracji klastra dla wystąpień klastra trybu failover igrup dostępności podczas korzystania z programu SQL Server na maszynach wirtualnych platformy Azure.

Aby dowiedzieć się więcej, zobacz inne artykuły z tej serii: Lista kontrolna, Rozmiar maszyny wirtualnej, Magazyn, Zabezpieczenia, Konfiguracja HADR, Zbieranie linii bazowej.

Lista kontrolna

Zapoznaj się z poniższą listą kontrolną, aby zapoznać się z krótkim omówieniem najlepszych rozwiązań dotyczących usługi HADR, które opisano w pozostałej części artykułu.

Funkcje wysokiej dostępności i odzyskiwania po awarii (HADR), takie jak zawsze włączona grupa dostępności i wystąpienie klastra trybu failover, opierają się na podstawowej technologii klastra trybu failover systemu Windows Server. Zapoznaj się z najlepszymi rozwiązaniami dotyczącymi modyfikowania ustawień usługi HADR, aby lepiej obsługiwać środowisko chmury.

W przypadku klastra systemu Windows należy wziąć pod uwagę następujące najlepsze rozwiązania:

  • Wdróż maszyny wirtualne programu SQL Server w wielu podsieciach, jeśli to możliwe, aby uniknąć zależności od usługi Azure Load Balancer lub rozproszonej nazwy sieci (DNN), aby kierować ruch do rozwiązania HADR.
  • Zmień klaster na mniej agresywne parametry, aby uniknąć nieoczekiwanych awarii sieci przejściowych lub konserwacji platformy Azure. Aby dowiedzieć się więcej, zobacz ustawienia pulsu i progu. W przypadku systemu Windows Server 2012 i nowszych użyj następujących zalecanych wartości:
    • SameSubnetDelay: 1 sekunda
    • SameSubnetThreshold: 40 pulsów
    • CrossSubnetDelay: 1 sekunda
    • CrossSubnetThreshold: 40 pulsów
  • Umieść maszyny wirtualne w zestawie dostępności lub w różnych strefach dostępności. Aby dowiedzieć się więcej, zobacz Ustawienia dostępności maszyn wirtualnych.
  • Użyj jednej karty sieciowej na węzeł klastra.
  • Skonfiguruj głosowanie kworum klastra, aby używać co najmniej 3 liczby głosów nieparzyszonych. Nie przypisuj głosów do regionów odzyskiwania po awarii.
  • Uważnie monitoruj limity zasobów, aby uniknąć nieoczekiwanych ponownych uruchomień lub trybu failover z powodu ograniczeń zasobów.
    • Upewnij się, że system operacyjny, sterowniki i program SQL Server są w najnowszych kompilacjach.
    • Optymalizowanie wydajności programu SQL Server na maszynach wirtualnych platformy Azure. Zapoznaj się z innymi sekcjami w tym artykule, aby dowiedzieć się więcej.
    • Zmniejsz lub rozłóż obciążenie, aby uniknąć limitów zasobów.
    • Przejdź do maszyny wirtualnej lub dysku, aby uniknąć ograniczeń.

W przypadku grupy dostępności programu SQL Server lub wystąpienia klastra trybu failover należy wziąć pod uwagę następujące najlepsze rozwiązania:

  • Jeśli występują częste nieoczekiwane błędy, postępuj zgodnie z najlepszymi rozwiązaniami dotyczącymi wydajności opisanymi w pozostałej części tego artykułu.
  • Jeśli optymalizacja wydajności maszyny wirtualnej z programem SQL Server nie rozwiąże problemów z nieoczekiwanym trybem failover, rozważ złagodzenie monitorowania dla grupy dostępności lub wystąpienia klastra trybu failover. Jednak może to nie rozwiązać problemu źródłowego źródła problemu i może maskować objawy, zmniejszając prawdopodobieństwo awarii. Nadal może być konieczne zbadanie i rozwiązanie źródłowej głównej przyczyny. W przypadku systemu Windows Server 2012 lub nowszego użyj następujących zalecanych wartości:
    • Limit czasu dzierżawy: użyj tego równania, aby obliczyć maksymalną wartość limitu czasu dzierżawy:
      Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
      Zacznij od 40 sekund. Jeśli używasz wcześniej zalecanych wartości i nie SameSubnetThresholdSameSubnetDelay przekraczasz 80 sekund dla wartości limitu czasu dzierżawy.
    • Maksymalna liczba niepowodzeń w określonym przedziale czasu: ustaw tę wartość na 6.
  • W przypadku używania nazwy sieci wirtualnej (VNN) i usługi Azure Load Balancer do łączenia się z rozwiązaniem HADR określ MultiSubnetFailover = true w parametry połączenia, nawet jeśli klaster obejmuje tylko jedną podsieć.
    • Jeśli klient nie obsługuje MultiSubnetFailover = True , może być konieczne ustawienie RegisterAllProvidersIP = 0 i HostRecordTTL = 300 buforowanie poświadczeń klienta przez krótszy czas. Jednak może to spowodować dodatkowe zapytania do serwera DNS.
  • Aby nawiązać połączenie z rozwiązaniem HADR przy użyciu nazwy sieci rozproszonej (DNN), rozważ następujące kwestie:
    • Należy użyć sterownika klienta obsługującego MultiSubnetFailover = Trueparametr , a ten parametr musi znajdować się w parametry połączenia.
    • Użyj unikatowego portu nazwy sieci rozproszonej w parametry połączenia podczas nawiązywania połączenia z odbiornikiem sieci rozproszonej dla grupy dostępności.
  • Użyj dublowania bazy danych parametry połączenia dla podstawowej grupy dostępności, aby pominąć potrzebę modułu równoważenia obciążenia lub nazwy sieci rozproszonej.
  • Przed wdrożeniem rozwiązania o wysokiej dostępności zweryfikuj rozmiar sektora dysków VHD, aby uniknąć nieprawidłowego dopasowywania operacji we/wy. Aby dowiedzieć się więcej, zobacz KB3009974 .
  • Jeśli aparat bazy danych programu SQL Server, odbiornik zawsze włączonej grupy dostępności lub sonda kondycji wystąpienia klastra trybu failover są skonfigurowane do używania portu z zakresu od 49 152 do 65 536 ( domyślny zakres portów dynamicznych dla protokołu TCP/IP), dodaj wykluczenie dla każdego portu. Dzięki temu inne systemy nie będą dynamicznie przypisywane tego samego portu. Poniższy przykład tworzy wykluczenie dla portu 59999:
    netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent

Aby porównać listę kontrolną usługi HADR z innymi najlepszymi rozwiązaniami, zobacz kompleksową listę kontrolną najlepszych rozwiązań dotyczących wydajności.

Ustawienia dostępności maszyny wirtualnej

Aby zmniejszyć efekt przestoju, rozważ następujące ustawienia dostępności maszyn wirtualnych:

  • Używaj grup umieszczania w pobliżu wraz z przyspieszoną siecią w celu uzyskania najmniejszego opóźnienia.
  • Umieść węzły klastra maszyn wirtualnych w oddzielnych strefach dostępności, aby chronić przed awariami na poziomie centrum danych lub w jednym zestawie dostępności w celu zapewnienia nadmiarowości o małych opóźnieniach w tym samym centrum danych.
  • W zestawie dostępności użyj dysków systemu operacyjnego i danych zarządzanych w warstwie Premium dla maszyn wirtualnych.
  • Skonfiguruj każdą warstwę aplikacji na oddzielne zestawy dostępności.

Kworum

Mimo że funkcje klastra z dwoma węzłami bez zasobu kworum, klienci są ściśle zobowiązani do korzystania z zasobu kworum do obsługi produkcyjnej. Walidacja klastra nie przekazuje żadnego klastra bez zasobu kworum.

Technicznie klaster z trzema węzłami może przetrwać utratę jednego węzła (w dół do dwóch węzłów) bez zasobu kworum, ale po wystąpieniu klastra do dwóch węzłów, jeśli wystąpi inna utrata węzła lub awaria komunikacji, istnieje ryzyko, że zasoby klastrowane przejdą w tryb offline, aby zapobiec scenariuszowi podziału mózgu. Skonfigurowanie zasobu kworum umożliwia klastrowi kontynuowanie pracy 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
  • 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 używasz rozwiązania klastra magazynu współużytkowanego.
  • Monitor dysku jest najbardziej odporną opcją kworum i jest preferowany dla każdego klastra korzystającego 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.
  • Monitor udziału plików jest odpowiedni, gdy monitor dysku i monitor w chmurze są niedostępne.

Aby rozpocząć, zobacz Konfigurowanie kworum klastra.

Głosowanie kworum

Istnieje możliwość zmiany głosowania kworum węzła uczestniczącego w klastrze trybu failover systemu Windows Server.

Podczas modyfikowania ustawień głosowania węzła postępuj zgodnie z następującymi wytycznymi:

Wytyczne dotyczące głosowania kworum
Rozpocznij od każdego węzła bez głosowania domyślnie. Każdy węzeł powinien mieć tylko głos z wyraźnym uzasadnieniem.
Włącz głosy dla węzłów klastra hostujących replikę podstawową grupy dostępności lub preferowanych właścicieli wystąpienia klastra trybu failover.
Włącz głosy dla właścicieli automatycznego trybu failover. Każdy węzeł, który może hostować replikę podstawową lub wystąpienie klastra trybu failover w wyniku automatycznego przejścia w tryb failover, powinien mieć głos.
Jeśli grupa dostępności ma więcej niż jedną replikę pomocniczą, włącz tylko głosy dla replik z automatycznym trybem failover.
Wyłącz głosy dla węzłów znajdujących się w dodatkowych lokacjach odzyskiwania po awarii. Węzły w lokacjach dodatkowych nie powinny współtworzyć decyzji o przełączeniu klastra w tryb offline, jeśli nie ma nic złego w lokacji głównej.
Mają nieparzystą liczbę głosów, z trzema głosami kworum minimum. Dodaj monitor kworum do dodatkowego głosowania, jeśli jest to konieczne w klastrze z dwoma węzłami.
Ponowne oceny przydziałów głosowania po przejściu w tryb failover. Nie chcesz przechodzić w tryb failover do konfiguracji klastra, która nie obsługuje kworum w dobrej kondycji.

Łączność

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 lub nazwy sieci rozproszonej w celu kierowania ruchu do odbiornika.

Aby uprościć rozwiązanie HADR, wdróż maszyny wirtualne z programem SQL Server w wielu podsieciach, jeśli to możliwe. Aby dowiedzieć się więcej, zobacz Grupy dostępności z wieloma podsieciami i Wystąpienie klastra trybu failover z wieloma podsieciami.

Jeśli maszyny wirtualne programu SQL Server znajdują się w jednej podsieci, można skonfigurować nazwę sieci wirtualnej (VNN) i usługę Azure Load Balancer lub nazwę sieci rozproszonej (DNN) dla wystąpień klastra trybu failover i odbiorników grup dostępności.

Nazwa sieci rozproszonej jest zalecaną opcją łączności, jeśli jest dostępna:

  • 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.

Rozważ następujące ograniczenia:

Aby dowiedzieć się więcej, zobacz Omówienie klastra trybu failover systemu Windows Server.

Aby skonfigurować łączność, zobacz następujące artykuły:

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. 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.

Napiwek

Ustaw parametr MultiSubnetFailover = true w parametry połączenia nawet w przypadku rozwiązań HADR obejmujących jedną podsieć, aby obsługiwać przyszłe łączenie podsieci bez konieczności aktualizowania parametry połączenia.

Puls i próg

Zmień ustawienia pulsu i progu klastra, aby złagodzone ustawienia. Domyślne ustawienia pulsu i klastra progowego są przeznaczone dla wysoce dostrojonych sieci lokalnych i nie uwzględniają możliwości zwiększonego opóźnienia w środowisku chmury. Sieć pulsu jest utrzymywana przy użyciu protokołu UDP 3343, który jest tradycyjnie znacznie mniej niezawodny niż TCP i bardziej podatny na niekompletne konwersacje.

W związku z tym podczas uruchamiania węzłów klastra dla programu SQL Server na maszynie wirtualnej platformy Azure wysokiej dostępności zmień ustawienia klastra na bardziej zrelaksowany stan monitorowania, aby uniknąć przejściowych awarii z powodu zwiększonego opóźnienia sieci lub awarii, konserwacji platformy Azure lub osiągnięcia wąskich gardeł zasobów.

Ustawienia opóźnienia i progu mają skumulowany wpływ na całkowite wykrywanie kondycji. Na przykład ustawienie parametru CrossSubnetDelay w celu wysyłania pulsu co 2 sekundy i ustawienie wartości CrossSubnetThreshold na 10 nieodebranych pulsów przed podjęciem odzyskiwania oznacza, że klaster może mieć całkowitą tolerancję sieci wynoszącą 20 sekund przed podjęciem akcji odzyskiwania. Ogólnie rzecz biorąc, nadal wysyłać częste pulsy, ale preferowane są większe progi.

Aby zapewnić odzyskiwanie podczas uzasadnionych awarii przy jednoczesnym zapewnieniu większej tolerancji dla przejściowych problemów, zrelaksuj ustawienia opóźnień i progów do zalecanych wartości opisanych w poniższej tabeli:

Ustawienie Windows Server 2012 lub nowszym Windows Server 2008 R2
SameSubnetDelay 1 sekunda 2 sekundy
SameSubnetThreshold 40 pulsów 10 pulsów (maks.)
CrossSubnetDelay 1 sekunda 2 sekundy
CrossSubnetThreshold 40 pulsów 20 pulsów (maks.)

Użyj programu PowerShell, aby zmienić parametry klastra:

(get-cluster).SameSubnetThreshold = 40
(get-cluster).CrossSubnetThreshold = 40

Użyj programu PowerShell, aby zweryfikować zmiany:

get-cluster | fl *subnet*

Zaleca się uwzględnić następujące elementy:

  • Ta zmiana jest natychmiastowa, ponowne uruchomienie klastra lub żadnych zasobów nie jest wymagane.
  • Te same wartości podsieci nie powinny być większe niż wartości między podsieciami.
  • SameSubnetThreshold <= CrossSubnetThreshold
  • SameSubnetDelay = CrossSubnetDelay <

Wybierz złagodzone wartości w zależności od tego, ile czasu pracy można tolerować i jak długo przed podjęciem akcji naprawczej powinno nastąpić w zależności od aplikacji, potrzeb biznesowych i środowiska. Jeśli nie możesz przekroczyć domyślnych wartości systemu Windows Server 2019, spróbuj je dopasować, jeśli to możliwe:

Na potrzeby dokumentacji w poniższej tabeli przedstawiono wartości domyślne:

Ustawienie Windows Server 2019 System Windows Server 2016 Windows Server 2008 – 2012 R2
SameSubnetDelay 1 sekunda 1 sekunda 1 sekunda
SameSubnetThreshold 20 pulsów 10 pulsów 5 pulsów
CrossSubnetDelay 1 sekunda 1 sekunda 1 sekunda
CrossSubnetThreshold 20 pulsów 10 pulsów 5 pulsów

Aby dowiedzieć się więcej, zobacz Dostrajanie progów sieci klastra trybu failover.

Złagodzone monitorowanie

Jeśli dostrajanie ustawień pulsu i progu klastra zgodnie z zaleceniami jest niewystarczająca tolerancja i nadal występują przejścia w tryb failover z powodu przejściowych problemów, a nie rzeczywistych awarii, możesz skonfigurować monitorowanie grupy dostępności lub klastra trybu failover, aby było bardziej złagodzone. W niektórych scenariuszach korzystne może być tymczasowe złagodzenie monitorowania przez pewien czas, biorąc pod uwagę poziom aktywności. Na przykład możesz zrelaksować monitorowanie podczas wykonywania intensywnych obciążeń operacji we/wy, takich jak kopie zapasowe bazy danych, konserwacja indeksu, DBCC CHECKDB itp. Po zakończeniu działania ustaw monitorowanie na mniej zrelaksowane wartości.

Ostrzeżenie

Zmiana tych ustawień może maskować podstawowy problem i powinna być używana jako tymczasowe rozwiązanie w celu zmniejszenia, a nie wyeliminowania prawdopodobieństwa awarii. Podstawowe problemy należy nadal badać i rozwiązywać.

Zacznij od zwiększenia następujących parametrów z domyślnych wartości w celu złagodzenia monitorowania i dostosuj je w razie potrzeby:

Parametr Domyślna wartość Wartość zrelaksowana opis
Limit czasu kontroli kondycji 30000 60000 Określa kondycję repliki podstawowej lub węzła. Biblioteka DLL sp_server_diagnostics zasobu klastra zwraca wyniki w interwale równym 1/3 progu limitu czasu sprawdzania kondycji. Jeśli sp_server_diagnostics jest powolne lub nie zwraca informacji, biblioteka DLL zasobu czeka na pełny interwał progu limitu czasu sprawdzania kondycji przed ustaleniem, że zasób nie odpowiada i inicjuje automatyczne przejście w tryb failover, jeśli zostało to skonfigurowane.
Poziom warunku awarii 3 2 Warunki wyzwalające automatyczne przejście w tryb failover. Istnieją pięć poziomów warunków awarii, które wahają się od najmniej restrykcyjnych (poziom jeden) do najbardziej restrykcyjnych (poziom pięć)

Użyj języka Transact-SQL (T-SQL), aby zmodyfikować warunki sprawdzania kondycji i niepowodzenia zarówno dla grup AG, jak i wystąpień klastra trybu failover.

W przypadku grup dostępności:

ALTER AVAILABILITY GROUP AG1 SET (HEALTH_CHECK_TIMEOUT =60000);
ALTER AVAILABILITY GROUP AG1 SET (FAILURE_CONDITION_LEVEL = 2);

W przypadku wystąpień klastra trybu failover:

ALTER SERVER CONFIGURATION SET FAILOVER CLUSTER PROPERTY HealthCheckTimeout = 60000;
ALTER SERVER CONFIGURATION SET FAILOVER CLUSTER PROPERTY FailureConditionLevel = 2;

Specyficzne dla grup dostępności, zacznij od następujących zalecanych parametrów i dostosuj je w razie potrzeby:

Parametr Domyślna wartość Wartość zrelaksowana opis
Limit czasu dzierżawy 20000 40000 Zapobiega podziałowi mózgu.
Limit czasu sesji 10 000 20000 Sprawdza problemy z komunikacją między replikami. Okres limitu czasu sesji to właściwość repliki, która kontroluje, jak długo (w sekundach) replika dostępności czeka na odpowiedź ping z połączonej repliki przed rozważeniem niepowodzenia połączenia. Domyślnie replika czeka 10 sekund na odpowiedź ping. Ta właściwość repliki ma zastosowanie tylko do połączenia między daną repliką pomocniczą a repliką podstawową grupy dostępności.
Maksymalna liczba niepowodzeń w określonym przedziale czasu 2 6 Służy do unikania nieokreślonego przenoszenia zasobu klastrowanego w ramach wielu awarii węzłów. Zbyt mała wartość może prowadzić do tego, że grupa dostępności jest w stanie niepowodzenia. Zwiększ wartość, aby zapobiec krótkim przerwom w działaniu problemów z wydajnością, ponieważ zbyt niska wartość może prowadzić do tego, że grupa dostępności jest w stanie niepowodzenia.

Przed wprowadzeniem jakichkolwiek zmian należy wziąć pod uwagę następujące kwestie:

  • Nie obniżaj wartości limitu czasu poniżej wartości domyślnych.
  • Użyj tego równania, aby obliczyć maksymalną wartość limitu czasu dzierżawy: Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
    Zacznij od 40 sekund. Jeśli używasz wcześniej zalecanych wartości i nie SameSubnetThresholdSameSubnetDelay przekraczasz 80 sekund dla wartości limitu czasu dzierżawy.
  • W przypadku replik zatwierdzania synchronicznego zmiana limitu czasu sesji na wysoką wartość może zwiększyć HADR_sync_commit oczekiwania.

Limit czasu dzierżawy

Użyj Menedżera klastra trybu failover, aby zmodyfikować ustawienia limitu czasu dzierżawy dla grupy dostępności. Szczegółowe kroki można znaleźć w dokumentacji sprawdzania kondycji dzierżawy grupy dostępności programu SQL Server.

Limit czasu sesji

Użyj języka Transact-SQL (T-SQL), aby zmodyfikować limit czasu sesji dla grupy dostępności:

ALTER AVAILABILITY GROUP AG1
MODIFY REPLICA ON 'INSTANCE01' WITH (SESSION_TIMEOUT = 20);

Maksymalna liczba niepowodzeń w określonym przedziale czasu

Użyj Menedżera klastra trybu failover, aby zmodyfikować wartość Maksymalne błędy w określonym przedziale czasu :

  1. Wybierz pozycję Role w okienku nawigacji.
  2. W obszarze Role kliknij prawym przyciskiem myszy zasób klastrowany i wybierz polecenie Właściwości.
  3. Wybierz kartę Tryb failover i zwiększ maksymalną liczbę niepowodzeń w określonym przedziale czasu zgodnie z potrzebami.

Limity zasobów

Limity maszyn wirtualnych lub dysków mogą spowodować wąskie gardło zasobów, które wpływa na kondycję klastra i utrudnia sprawdzanie kondycji. Jeśli występują problemy z limitami zasobów, rozważ następujące kwestie:

  • Upewnij się, że system operacyjny, sterowniki i program SQL Server są w najnowszych kompilacjach.
  • Optymalizowanie programu SQL Server w środowisku maszyny wirtualnej platformy Azure zgodnie z opisem w wytycznych dotyczących wydajności programu SQL Server na maszynach wirtualnych platformy Azure
  • Zmniejsz lub rozłóż obciążenie, aby zmniejszyć wykorzystanie bez przekraczania limitów zasobów
  • Dostrajanie obciążenia programu SQL Server, jeśli istnieje jakiekolwiek możliwości, takie jak
    • Dodawanie/optymalizowanie indeksów
    • Aktualizowanie statystyk w razie potrzeby i, jeśli to możliwe, przy użyciu pełnego skanowania
    • Użyj funkcji, takich jak zarządca zasobów (począwszy od programu SQL Server 2014, tylko dla przedsiębiorstw), aby ograniczyć wykorzystanie zasobów podczas określonych obciążeń, takich jak tworzenie kopii zapasowych lub konserwacja indeksu.
  • Przejdź do maszyny wirtualnej lub dysku, który ma wyższe limity, aby spełnić lub przekroczyć wymagania obciążenia.

Sieć

Wdróż maszyny wirtualne programu SQL Server w wielu podsieciach, jeśli to możliwe, aby uniknąć zależności od usługi Azure Load Balancer lub rozproszonej nazwy sieci (DNN), aby kierować ruch do rozwiązania HADR.

Użyj pojedynczej karty sieciowej na serwer (węzeł klastra). Sieć platformy Azure ma nadmiarowość fizyczną, co sprawia, że dodatkowe karty sieciowe są niepotrzebne w klastrze gościa maszyny wirtualnej platformy Azure. Raport weryfikacji klastra ostrzega, że węzły są dostępne tylko w jednej sieci. To ostrzeżenie można zignorować w klastrach trybu failover gościa maszyny wirtualnej platformy Azure.

Limity przepustowości dla określonej maszyny wirtualnej są współużytkowane przez karty sieciowe i dodanie dodatkowej karty sieciowej nie zwiększa wydajności grupy dostępności dla programu SQL Server na maszynach wirtualnych platformy Azure. W związku z tym nie ma potrzeby dodawania drugiej karty sieciowej.

Niezgodna z RFC usługa DHCP na platformie Azure może spowodować niepowodzenie tworzenia niektórych konfiguracji klastra trybu failover. Ten błąd występuje, ponieważ nazwa sieci klastra jest przypisana zduplikowany adres IP, taki jak ten sam adres IP co jeden z węzłów klastra. Jest to problem podczas korzystania z grup dostępności, które zależą od funkcji klastra trybu failover systemu Windows.

Rozważmy scenariusz utworzenia klastra z dwoma węzłami i włączenia go do trybu online:

  1. Klaster jest w trybie online, a następnie węzeł NODE1 żąda dynamicznie przypisanego adresu IP dla nazwy sieci klastra.
  2. Usługa DHCP nie podaje żadnego adresu IP innego niż własny adres IP węzła1, ponieważ usługa DHCP rozpoznaje, że żądanie pochodzi z samego węzła NODE1.
  3. System Windows wykrywa, że zduplikowany adres jest przypisany zarówno do węzła NODE1, jak i do nazwy sieciowej klastra trybu failover, a domyślna grupa klastra nie może przejść do trybu online.
  4. Domyślna grupa klastrów zostanie przeniesiona do węzła NODE2. Węzeł NODE2 traktuje adres IP węzła1 jako adres IP klastra i przenosi domyślną grupę klastra do trybu online.
  5. Gdy węzeł NODE2 próbuje nawiązać łączność z węzłem NODE1, pakiety kierowane do węzła NODE1 nigdy nie opuszczają środowiska NODE2, ponieważ rozpoznaje on sam adres IP węzła1. Węzeł NODE2 nie może nawiązać łączności z węzłem NODE1, a następnie traci kworum i zamyka klaster.
  6. Węzeł NODE1 może wysyłać pakiety do węzła NODE2, ale węzeł NODE2 nie może odpowiedzieć. Węzeł NODE1 traci kworum i zamyka klaster.

Ten scenariusz można uniknąć, przypisując nieużywany statyczny adres IP do nazwy sieciowej klastra w celu przełączenia nazwy sieciowej klastra do trybu online i dodania adresu IP do usługi Azure Load Balancer.

Jeśli aparat bazy danych programu SQL Server, odbiornik zawsze włączonej grupy dostępności, sonda kondycji wystąpienia klastra trybu failover, punkt końcowy dublowania bazy danych, zasób podstawowego adresu IP klastra lub dowolny inny zasób SQL jest skonfigurowany do używania portu z zakresu od 49 152 do 65 536 ( domyślny zakres portów dynamicznych dla protokołu TCP/IP), dodaj wykluczenie dla każdego portu. Zapobiega to dynamicznemu przypisywaniu tego samego portu przez inne procesy systemowe. Poniższy przykład tworzy wykluczenie dla portu 59999:

netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent

Ważne jest skonfigurowanie wykluczenia portów, gdy port nie jest używany, w przeciwnym razie polecenie kończy się niepowodzeniem z komunikatem, na przykład "Proces nie może uzyskać dostępu do pliku, ponieważ jest używany przez inny proces".

Aby upewnić się, że wykluczenia zostały poprawnie skonfigurowane, użyj następującego polecenia: netsh int ipv4 show excludedportrange tcp.

Ustawienie tego wykluczenia dla portu sondy IP roli grupy dostępności powinno uniemożliwić zdarzenia, takie jak identyfikator zdarzenia: 1069 ze stanem 10048. To zdarzenie można zobaczyć w zdarzeniach klastra trybu failover systemu Windows z następującym komunikatem:

Cluster resource '<IP name in AG role>' of type 'IP Address' in cluster role '<AG Name>' failed.
An Event ID: 1069 with status 10048 can be identified from cluster logs with events like:
Resource IP Address 10.0.1.0 called SetResourceStatusEx: checkpoint 5. Old state OnlinePending, new state OnlinePending, AppSpErrorCode 0, Flags 0, nores=false
IP Address <IP Address 10.0.1.0>: IpaOnlineThread: **Listening on probe port 59999** failed with status **10048**
Status [**10048**](/windows/win32/winsock/windows-sockets-error-codes-2) refers to: **This error occurs** if an application attempts to bind a socket to an **IP address/port that has already been used** for an existing socket.

Może to być spowodowane przez proces wewnętrzny, który przyjmuje ten sam port zdefiniowany jako port sondy. Pamiętaj, że port sondy służy do sprawdzania stanu wystąpienia puli zaplecza z usługi Azure Load Balancer.
Jeśli sonda kondycji nie otrzyma odpowiedzi z wystąpienia zaplecza, żadne nowe połączenia nie zostaną wysłane do tego wystąpienia zaplecza, dopóki sonda kondycji nie powiedzie się ponownie.

Znane problemy

Zapoznaj się z rozwiązaniami niektórych często znanych problemów i błędów.

Rywalizacja o zasoby (w szczególności we/wy) powoduje przejście w tryb failover

Wyczerpanie pojemności operacji we/wy lub procesora CPU dla maszyny wirtualnej może spowodować przełączenie grupy dostępności w tryb failover. Identyfikowanie rywalizacji, która odbywa się bezpośrednio przed przejściem w tryb failover, jest najbardziej niezawodnym sposobem identyfikowania przyczyn automatycznego przejścia w tryb failover. Monitorowanie maszyn wirtualnych platformy Azure w celu zapoznania się z metrykami użycia operacji we/wy magazynu w celu zrozumienia opóźnienia maszyny wirtualnej lub poziomu dysku.

Wykonaj następujące kroki, aby przejrzeć ogólne zdarzenie wyczerpania operacji we/wy maszyny wirtualnej platformy Azure:

  1. Przejdź do maszyny wirtualnej w witrynie Azure Portal — a nie do maszyn wirtualnych SQL.

  2. Wybierz pozycję Metryki w obszarze Monitorowanie , aby otworzyć stronę Metryki .

  3. Wybierz pozycję Czas lokalny, aby określić interesujący Cię zakres czasu oraz strefę czasową lokalną dla maszyny wirtualnej lub UTC/GMT.

    Screenshot of the Metrics page in the Azure portal, selecting changing the time frame of the graph.

  4. Wybierz pozycję Dodaj metrykę , aby dodać następujące dwie metryki, aby wyświetlić wykres:

    • Procent użycia przepustowości pamięci podręcznej maszyny wirtualnej
    • Procent zużycia niebuforowanej przepustowości przez maszynę wirtualną

Screenshot of the Metrics page in the Azure portal.

Usługa HostEvents maszyny wirtualnej platformy Azure powoduje przejście w tryb failover

Możliwe, że element HostEvent maszyny wirtualnej platformy Azure powoduje przełączenie grupy dostępności w tryb failover. Jeśli uważasz, że zdarzenie HostEvent maszyny wirtualnej platformy Azure spowodowało przejście w tryb failover, możesz sprawdzić dziennik aktywności usługi Azure Monitor i omówienie usługi Azure VM Resource Health.

Dziennik aktywności usługi Azure Monitor to dziennik platformy na platformie Azure, który zapewnia wgląd w zdarzenia na poziomie subskrypcji. Dziennik aktywności zawiera informacje, takie jak czas modyfikacji zasobu lub uruchomienie maszyny wirtualnej. Dziennik aktywności można wyświetlić w witrynie Azure Portal lub pobrać wpisy za pomocą programu PowerShell i interfejsu wiersza polecenia platformy Azure.

Aby sprawdzić dziennik aktywności usługi Azure Monitor, wykonaj następujące kroki:

  1. Przejdź do maszyny wirtualnej w witrynie Azure Portal

  2. Wybierz pozycję Dziennik aktywności w okienku Maszyna wirtualna

  3. Wybierz pozycję Przedział czasu , a następnie wybierz przedział czasu po przejściu grupy dostępności w tryb failover. Wybierz Zastosuj.

    Screenshot of the Azure portal, showing the Activity log.

Jeśli platforma Azure zawiera dalsze informacje o głównej przyczynie niedostępności zainicjowanej przez platformę, informacje te mogą być publikowane na stronie przeglądu usługi Azure VM — Resource Health do 72 godzin po początkowej niedostępności. Te informacje są obecnie dostępne tylko dla maszyn wirtualnych.

  1. Przejdź do maszyny wirtualnej w witrynie Azure Portal
  2. Wybierz pozycję Resource Health w okienku Kondycja.

Screenshot of the Resource Health page in the Azure portal.

Możesz również skonfigurować alerty na podstawie zdarzeń kondycji z tej strony.

Węzeł klastra został usunięty z członkostwa

Jeśli ustawienia pulsu i progu klastra systemu Windows są zbyt agresywne dla danego środowiska, często w dzienniku zdarzeń systemu może zostać wyświetlony następujący komunikat.

Error 1135
Cluster node 'Node1' was removed from the active failover cluster membership.
The Cluster service on this node may have stopped. This could also be due to the node having
lost communication with other active nodes in the failover cluster. Run the Validate a
Configuration Wizard to check your network configuration. If the condition persists, check
for hardware or software errors related to the network adapters on this node. Also check for
failures in any other network components to which the node is connected such as hubs, switches, or bridges.

Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z klastrem o identyfikatorze zdarzenia 1135.

Dzierżawa wygasła/ Dzierżawa nie jest już prawidłowa

Jeśli monitorowanie jest zbyt agresywne w danym środowisku, często mogą pojawić się ponowne uruchomienia grupy dostępności lub wystąpienia klastra trybu failover, awarie lub tryb failover. Ponadto w przypadku grup dostępności w dzienniku błędów programu SQL Server mogą zostać wyświetlone następujące komunikaty:

Error 19407: The lease between availability group 'PRODAG' and the Windows Server Failover Cluster has expired.
A connectivity issue occurred between the instance of SQL Server and the Windows Server Failover Cluster.
To determine whether the availability group is failing over correctly, check the corresponding availability group
resource in the Windows Server Failover Cluster

Error 19419: The renewal of the lease between availability group '%.*ls' and the Windows Server Failover Cluster
failed because the existing lease is no longer valid.

Przekroczenie limitu czasu połączenia

Jeśli limit czasu sesji jest zbyt agresywny dla środowiska grupy dostępności, mogą być często wyświetlane następujące komunikaty:

Error 35201: A connection timeout has occurred while attempting to establish a connection to availability
replica 'replicaname' with ID [availability_group_id]. Either a networking or firewall issue exists,
or the endpoint address provided for the replica is not the database mirroring endpoint of the host server instance.

Error 35206
A connection timeout has occurred on a previously established connection to availability
replica 'replicaname' with ID [availability_group_id]. Either a networking or a firewall issue
exists, or the availability replica has transitioned to the resolving role.

Grupa nie jest przełączeniem w tryb failover

Jeśli wartość Maksymalna liczba niepowodzeń w określonym okresie jest zbyt niska i występują sporadyczne błędy z powodu przejściowych problemów, grupa dostępności może zakończyć się niepowodzeniem. Zwiększ tę wartość, aby tolerować więcej błędów przejściowych.

Not failing over group <Resource name>, failoverCount 3, failoverThresholdSetting <Number>, computedFailoverThreshold 2.

Zdarzenie 1196 — Rejestracja skojarzonej nazwy DNS zasobu nazwy sieciowej nie powiodła się

  • Sprawdź ustawienia karty sieciowej dla wszystkich węzłów klastra i upewnij się, że nie ma żadnych zewnętrznych rekordów DNS
  • Upewnij się, że na wewnętrznych serwerach DNS istnieje rekord A dla klastra. Jeśli tak nie jest, utwórz ręcznie nowy rekord A na serwerze DNS dla obiektu kontroli dostępu do klastra i zaznacz ustawienie Zezwalaj wszystkim uwierzytelnionym użytkownikom na aktualizowanie rekordów DNS z tą samą nazwą właściciela.
  • Przełącz zasób „Nazwa klastra” z zasobem adresu IP do trybu offline i napraw go.

Zdarzenie 157 — dysk został usunięty z zaskoczeniem.

Może się tak zdarzyć, jeśli właściwość miejsc do magazynowania AutomaticClusteringEnabled ma wartość True dla środowiska grupy dostępności. Zmień ją na False. Zdarzenie zresetowania dysku lub nieoczekiwanego usunięcia może być spowodowane także przez uruchomienie raportu walidacji z opcją magazynu. Przyczyną zdarzenia nieoczekiwanego usunięcia dysku może być także ograniczanie przepustowości w systemie magazynu.

Zdarzenie 1206 — nie można przywrócić zasobu nazwy sieciowej klastra w trybie online.

Nie można zaktualizować obiektu komputera skojarzonego z zasobem w domenie. Upewnij się, że masz odpowiednie uprawnienia do domeny

Błędy klastrowania systemu Windows

Podczas konfigurowania klastra trybu failover systemu Windows lub jego łączności mogą wystąpić problemy, jeśli nie masz otwartych portów usługi klastra na potrzeby komunikacji.

Jeśli korzystasz z systemu Windows Server 2019 i nie widzisz adresu IP klastra systemu Windows, skonfigurowano nazwę sieci rozproszonej, która jest obsługiwana tylko w programie SQL Server 2019. Jeśli masz starszą wersję programu SQL Server, możesz usunąć klaster i utworzyć go ponownie przy użyciu nazwy sieciowej.

Przejrzyj inne błędy zdarzeń klastra trybu failover systemu Windows i ich rozwiązania tutaj

Następne kroki

Aby dowiedzieć się więcej, zobacz: