Zawsze włączona grupa dostępności w programie SQL Server na maszynach wirtualnych platformy Azure

  • Artykuł

Dotyczy:SQL Server na maszynie wirtualnej platformy Azure

W tym artykule przedstawiono zawsze włączone grupy dostępności dla programu SQL Server na maszynach wirtualnych platformy Azure.

Aby rozpocząć pracę, zobacz samouczek dotyczący grupy dostępności.

Omówienie

Zawsze włączone grupy dostępności na maszynach wirtualnych platformy Azure są podobne do zawsze włączonych grup dostępności lokalnych i korzystają z bazowego klastra trybu failover systemu Windows Server. Jednak ponieważ maszyny wirtualne są hostowane na platformie Azure, istnieje kilka dodatkowych zagadnień, takich jak nadmiarowość maszyn wirtualnych i routing ruchu w sieci platformy Azure.

Na poniższym diagramie przedstawiono grupę dostępności programu SQL Server na maszynach wirtualnych platformy Azure:

Availability Group

Uwaga

Teraz można podnieść i przenieść rozwiązanie grupy dostępności do programu SQL Server na maszynach wirtualnych platformy Azure przy użyciu usługi Azure Migrate. Aby dowiedzieć się więcej, zobacz Migrowanie grupy dostępności.

Nadmiarowość maszyny wirtualnej

Aby zwiększyć nadmiarowość i wysoką dostępność, maszyny wirtualne programu SQL Server powinny znajdować się w tym samym zestawie dostępności lub w różnych strefach dostępności.

Umieszczenie zestawu maszyn wirtualnych w tym samym zestawie dostępności chroni przed awariami w centrum danych spowodowanym awarią sprzętu (maszyny wirtualne w zestawie dostępności nie współużytkują zasobów) lub aktualizacje (maszyny wirtualne w zestawie dostępności nie są aktualizowane w tym samym czasie).

Strefy dostępności chronią przed awarią całego centrum danych, a każda strefa reprezentuje zestaw centrów danych w obrębie regionu. Dzięki zapewnieniu, że zasoby są umieszczane w różnych strefach dostępności, awaria na poziomie centrum danych może przejąć wszystkie maszyny wirtualne w tryb offline.

Podczas tworzenia maszyn wirtualnych platformy Azure należy wybrać między konfigurowaniem zestawów dostępności a strefami dostępności. Maszyna wirtualna platformy Azure nie może uczestniczyć w obu tych elementach.

Chociaż strefy dostępności mogą zapewnić lepszą dostępność niż zestawy dostępności (99,99% a 99,95%), należy również rozważyć wydajność. Maszyny wirtualne w zestawie dostępności można umieścić w grupie umieszczania w pobliżu, co gwarantuje, że znajdują się blisko siebie, minimalizując opóźnienie sieci między nimi. Maszyny wirtualne znajdujące się w różnych strefach dostępności mają większe opóźnienie sieci między nimi, co może wydłużyć czas synchronizacji danych między replikami podstawowymi i pomocniczymi. Może to spowodować opóźnienia repliki podstawowej, a także zwiększyć prawdopodobieństwo utraty danych w przypadku nieplanowanego przejścia w tryb failover. Ważne jest przetestowanie proponowanego rozwiązania pod obciążeniem i upewnienie się, że spełnia ona umowy SLA zarówno pod kątem wydajności, jak i dostępności.

Łączność

Aby dopasować środowisko lokalne do nawiązywania połączenia z odbiornikiem grupy dostępności, 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 rozproszonej nazwy sieci (DNN) w celu kierowania ruchu do odbiornika.

W przypadku wdrażania maszyn wirtualnych programu SQL Server w jednej podsieci można skonfigurować nazwę sieci wirtualnej (VNN) i usługę Azure Load Balancer lub nazwę sieci rozproszonej (DNN) w celu kierowania ruchu do odbiornika grupy dostępności. Przejrzyj różnice między nimi, a następnie wdróż nazwę sieci rozproszonej (DNN) lub nazwę sieci wirtualnej (VNN) dla grupy dostępności.

Większość funkcji programu SQL Server działa w sposób niewidoczny dla grup dostępności podczas korzystania z nazwy sieci rozproszonej, ale istnieją pewne funkcje, które mogą wymagać szczególnej uwagi. Aby dowiedzieć się więcej, zobacz współdziałanie grupy dostępności i nazwy sieci rozproszonej.

Ponadto istnieją pewne różnice w zachowaniu między funkcjonalnością odbiornika sieci VNN i odbiornika sieci rozproszonej, które należy pamiętać:

  • Czas pracy w trybie failover: czas pracy w trybie failover jest krótszy w przypadku korzystania z odbiornika sieci rozproszonej, ponieważ nie trzeba czekać na moduł równoważenia obciążenia sieciowego w celu wykrycia zdarzenia awarii i zmiany routingu.
  • Istniejące połączenia: połączenia z określoną bazą danych w grupie dostępności przełączonej w tryb failover zostaną zamknięte, ale inne połączenia z repliką podstawową pozostaną otwarte, ponieważ nazwa sieci rozproszonej pozostaje w trybie online podczas procesu pracy w trybie failover. Różni się to od tradycyjnego środowiska sieci VNN, w którym wszystkie połączenia z repliką podstawową zwykle zamykają się, gdy grupa dostępności przechodzi w tryb failover, odbiornik przechodzi w tryb offline, a replika podstawowa przechodzi do roli pomocniczej. W przypadku korzystania z odbiornika sieci rozproszonej może być konieczne dostosowanie parametrów połączenia aplikacji, aby upewnić się, że połączenia są przekierowywane do nowej repliki podstawowej po przejściu w tryb failover.
  • Otwarte transakcje: Otwieranie transakcji względem bazy danych w grupie dostępności w trybie failover spowoduje zamknięcie i wycofanie i ręczne ponowne nawiązanie połączenia. Na przykład w programie SQL Server Management Studio zamknij okno zapytania i otwórz nowe.

Skonfigurowanie odbiornika sieci wirtualnej na platformie Azure wymaga modułu równoważenia obciążenia. Istnieją dwie główne opcje modułów równoważenia obciążenia na platformie Azure: zewnętrzne (publiczne) lub wewnętrzne. Zewnętrzny (publiczny) moduł równoważenia obciążenia jest połączony z Internetem i jest skojarzony z publicznym wirtualnym adresem IP dostępnym przez Internet. Wewnętrzny moduł równoważenia obciążenia obsługuje tylko klientów w tej samej sieci wirtualnej. W przypadku dowolnego typu modułu równoważenia obciążenia należy włączyć bezpośredni zwrot serwera.

Nadal można połączyć się z każdą repliką dostępności oddzielnie, łącząc się bezpośrednio z wystąpieniem usługi. Ponadto, ponieważ grupy dostępności są zgodne z poprzednimi wersjami z klientami dublowania bazy danych, można połączyć się z replikami dostępności, takimi jak partnerzy dublowania baz danych, o ile repliki są skonfigurowane podobnie do dublowania bazy danych:

  • Istnieje jedna replika podstawowa i jedna replika pomocnicza.
  • Replika pomocnicza jest skonfigurowana jako nieczytelna (opcja Pomocnicza do odczytu ustawiona na Nie).

Poniżej przedstawiono przykładowe parametry połączenia klienta, które odpowiadają tej konfiguracji podobnej do dublowania bazy danych przy użyciu ADO.NET lub klienta natywnego programu SQL Server:

Data Source=ReplicaServer1;Failover Partner=ReplicaServer2;Initial Catalog=AvailabilityDatabase;

Aby uzyskać więcej informacji na temat łączności klienta, zobacz:

Pojedyncza podsieć wymaga modułu równoważenia obciążenia

Podczas tworzenia odbiornika grupy dostępności w tradycyjnym lokalnym klastrze trybu failover systemu Windows Server (WSFC) rekord DNS jest tworzony dla odbiornika z podanym adresem IP, a ten adres IP jest mapowy na adres MAC bieżącej repliki podstawowej w tabelach ARP przełączników i routerów w sieci lokalnej. Klaster wykonuje to przy użyciu funkcji ARP (GARP), gdzie emituje najnowsze mapowanie adresów IP-MAC do sieci przy każdym wybraniu nowego podstawowego adresu po przejściu w tryb failover. W takim przypadku adres IP jest przeznaczony dla odbiornika, a adres MAC jest bieżącą repliką podstawową. GarP wymusza aktualizację wpisów tabeli ARP dla przełączników i routerów, a wszyscy użytkownicy łączący się z adresem IP odbiornika są bezproblemowo kierowane do bieżącej repliki podstawowej.

Ze względów bezpieczeństwa emisja w dowolnej chmurze publicznej (Azure, Google, AWS) nie jest dozwolona, więc korzystanie z usług ARPs i GARPs na platformie Azure nie jest obsługiwane. Aby przezwyciężyć tę różnicę w środowiskach sieciowych, maszyny wirtualne programu SQL Server w jednej grupie dostępności podsieci polegają na modułach równoważenia obciążenia w celu kierowania ruchu do odpowiednich adresów IP. Moduły równoważenia obciążenia są konfigurowane przy użyciu adresu IP frontonu odpowiadającego odbiornikowi, a port sondy jest przypisywany tak, aby usługa Azure Load Balancer okresowo sonduje stan replik w grupie dostępności. Ponieważ tylko podstawowa replika maszyny wirtualnej programu SQL Server odpowiada na sondę TCP, ruch przychodzący jest następnie kierowany do maszyny wirtualnej, która pomyślnie odpowiada na sondę. Ponadto odpowiedni port sondy jest skonfigurowany jako adres IP klastra WSFC, zapewniając, że replika podstawowa odpowiada na sondę TCP.

Grupy dostępności skonfigurowane w jednej podsieci muszą używać modułu równoważenia obciążenia lub rozproszonej nazwy sieci (DNN) do kierowania ruchu do odpowiedniej repliki. Aby uniknąć tych zależności, skonfiguruj grupę dostępności w wielu podsieciach, aby odbiornik grupy dostępności był skonfigurowany przy użyciu adresu IP repliki w każdej podsieci i może odpowiednio kierować ruch.

Jeśli grupa dostępności została już utworzona w jednej podsieci, możesz ją zmigrować do środowiska z wieloma podsieciami.

Mechanizm dzierżawy

W przypadku programu SQL Server biblioteka DLL zasobów grupy dostępności określa kondycję grupy dostępności na podstawie mechanizmu dzierżawy grupy dostępności i wykrywania kondycji Zawsze włączone. Biblioteka DLL zasobu grupy dostępności uwidacznia kondycję zasobów za pośrednictwem operacji IsAlive . Monitor zasobów sonduje isAlive w interwale pulsu klastra, który jest ustawiany przez wartości CrossSubnetDelay i SameSubnetDelay w całym klastrze. W węźle podstawowym usługa klastra inicjuje tryb failover za każdym razem, gdy wywołanie isAlive do biblioteki DLL zasobu zwraca, że grupa dostępności nie jest w dobrej kondycji.

Biblioteka DLL zasobu grupy dostępności monitoruje stan wewnętrznych składników programu SQL Server. Sp_server_diagnostics raportuje kondycję tych składników do programu SQL Server w interwale kontrolowanym przez healthCheckTimeout.

W przeciwieństwie do innych mechanizmów trybu failover wystąpienie programu SQL Server odgrywa aktywną rolę w mechanizmie dzierżawy. Mechanizm dzierżawy jest używany jako weryfikacja wygląda na żywo między hostem zasobów klastra a procesem programu SQL Server. Mechanizm służy do zapewnienia, że obie strony (usługa klastrowania i program SQL Server) są często kontaktowane, sprawdzając stan siebie i ostatecznie uniemożliwiając scenariusz podziału mózgu.

Podczas konfigurowania grupy dostępności na maszynach wirtualnych platformy Azure często trzeba skonfigurować te progi inaczej niż w środowisku lokalnym. Aby skonfigurować ustawienia progu zgodnie z najlepszymi rozwiązaniami dotyczącymi maszyn wirtualnych platformy Azure, zobacz najlepsze rozwiązania dotyczące klastra.

Konfiguracja sieci

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 sieciowej (DNN) w celu kierowania ruchu do odbiornika grupy dostępności.

W klastrze trybu failover maszyny wirtualnej platformy Azure zalecamy użycie pojedynczej karty sieciowej na serwer (węzeł klastra). Sieć platformy Azure ma nadmiarowość fizyczną, co sprawia, że dodatkowe karty sieciowe są niepotrzebne w klastrze trybu failover maszyny wirtualnej platformy Azure. Mimo że raport weryfikacji klastra zgłasza ostrzeżenie, że węzły są dostępne tylko w jednej sieci, to ostrzeżenie można bezpiecznie zignorować w klastrach trybu failover maszyn wirtualnych platformy Azure.

Podstawowa grupa dostępności

Ponieważ podstawowa grupa dostępności nie zezwala na więcej niż jedną replikę pomocniczą i nie ma dostępu do odczytu do repliki pomocniczej, możesz użyć parametrów połączenia dublowania bazy danych dla podstawowych grup dostępności. Użycie parametrów połączenia eliminuje konieczność posiadania odbiorników. Usunięcie zależności odbiornika jest przydatne w przypadku grup dostępności na maszynach wirtualnych platformy Azure, ponieważ eliminuje potrzebę modułu równoważenia obciążenia lub konieczności dodawania dodatkowych adresów IP do modułu równoważenia obciążenia, gdy masz wiele odbiorników dla dodatkowych baz danych.

Aby na przykład jawnie nawiązać połączenie przy użyciu protokołu TCP/IP z bazą danych grupy dostępności AdventureWorks na Replica_A lub Replica_B podstawowej grupy dostępności (lub dowolnej grupy dostępności, która ma tylko jedną replikę pomocniczą i dostęp do odczytu nie jest dozwolony w repliki pomocniczej), aplikacja kliencka może podać następujące parametry połączenia dublowania bazy danych, aby pomyślnie nawiązać połączenie z grupą dostępności

Server=Replica_A; Failover_Partner=Replica_B; Database=AdventureWorks; Network=dbmssocn

Opcje wdrożenia

Napiwek

Wyeliminuj konieczność korzystania z usługi Azure Load Balancer lub nazwy sieci rozproszonej (DNN) dla zawsze włączonej grupy dostępności, tworząc maszyny wirtualne programu SQL Server w wielu podsieciach w tej samej sieci wirtualnej platformy Azure.

Istnieje wiele opcji wdrażania grupy dostępności w programie SQL Server na maszynach wirtualnych platformy Azure, niektóre z większą automatyzacją niż inne.

Poniższa tabela zawiera porównanie dostępnych opcji:

Witryna Azure Portal, Interfejs wiersza polecenia platformy Azure/program PowerShell Szablony szybkiego startu Ręczne (pojedyncza podsieć) Ręczne (wiele podsieci)
Wersja programu SQL Server 2016 + 2016 + 2016 + 2012 + 2012 +
Wydanie programu SQL Server Przedsiębiorstwa Przedsiębiorstwa Przedsiębiorstwa Enterprise, Standard Enterprise, Standard
Wersja systemu Windows Server 2016 + 2016 + 2016 + Wszystko Wszystko
Automatycznie tworzy klaster Tak Tak Tak Nie Nie
Automatycznie tworzy grupę dostępności i odbiornik Tak Nie Nie Nie Nie
Tworzy odbiornik i moduł równoważenia obciążenia niezależnie Nie dotyczy Nie Nie Tak Nie dotyczy
Czy można utworzyć odbiornik nazwy sieci rozproszonej przy użyciu tej metody? Nie dotyczy Nie Nie Tak Nie dotyczy
Konfiguracja kworum WSFC Monitor w chmurze Monitor w chmurze Monitor w chmurze Wszystko Wszystko
Odzyskiwanie po awarii z wieloma regionami Nie Nie Nie Tak Tak
Obsługa wielu podsieci Tak Nie Nie Nie dotyczy Tak
Obsługa istniejącej usługi AD Tak Tak Tak Tak Tak
Odzyskiwanie po awarii z wieloma strefami w tym samym regionie Tak Tak Tak Tak Tak
Rozproszona grupa dostępności bez usługi AD Nie Nie Nie Tak Tak
Rozproszona grupa dostępności bez klastra Nie Nie Nie Tak Tak
Wymaga modułu równoważenia obciążenia lub nazwy sieci rozproszonej Nie Tak Tak Tak Nie

Następne kroki

Aby rozpocząć, zapoznaj się z najlepszymi rozwiązaniami dotyczącymi usługi HADR, a następnie ręcznie wdróż grupę dostępności za pomocą samouczka grupy dostępności.

Aby dowiedzieć się więcej, zobacz: