Klastrowanie wielu podsieci programu SQL Server

Dotyczy:SQL Server

Klaster trybu failover z wieloma podsieciami programu SQL Server to konfiguracja, w której każdy węzeł klastra trybu failover jest połączony z inną podsiecią lub innym zestawem podsieci. Te podsieci mogą znajdować się w tej samej lokalizacji lub w rozproszonych geograficznie lokacjach. Klastry w rozproszonych geograficznie lokacjach są czasami nazywane klastrami rozproszonymi. Ponieważ nie ma udostępnionego magazynu, do którego mogą uzyskiwać dostęp wszystkie węzły, dane powinny być replikowane między magazynem danych w wielu podsieciach. Podczas replikacji danych jest dostępnych więcej niż jedna kopia danych. W związku z tym wielopodsieciowy klaster pracy awaryjnej zapewnia rozwiązanie do odzyskiwania po awarii, oprócz zapewnienia wysokiej dostępności.

Wielopodsieciowy klaster pracy awaryjnej SQL Server (dwa węzły, dwie podsieci)

Poniższa ilustracja przedstawia wystąpienie klastra trybu failover z dwiema podsieciami w programie SQL Server.

Diagram przedstawiający architekturę z wieloma podsieciami z usługą MultiSubnetFailover.

Konfiguracje wystąpień klastrów przełączania awaryjnego w konfiguracji wielopodsieciowej

Poniżej przedstawiono kilka przykładów wystąpień klastra trybu failover (FCI) programu SQL Server, które używają wielu podsieci:

  • Program SQL Server FCI SQLCLUST1 obejmuje węzły Node1 i Node2. Node1 jest połączony z podsiecią Subnet1. Node2 jest połączony z podsiecią Subnet2. Instalator SQL Server traktuje tę konfigurację jako klaster z wieloma podsieciami i ustawia zależność zasobu adresu IP na OR.

  • Usługa SQL Server FCI SQLCLUST2 obejmuje węzły Node1, Node2 i Node3. Węzły Node1 i Node2 są połączone z podsiecią Subnet1. Węzeł 3 jest połączony z podsiecią Subnet2. Instalator SQL Server traktuje tę konfigurację jako klaster z wieloma podsieciami i ustawia zależność zasobu adresu IP na OR. Ponieważ węzły Node1 i Node2 znajdują się w tej samej podsieci, ta konfiguracja zapewnia dodatkową lokalną wysoką dostępność.

  • Program SQL Server FCI SQLCLUST3 obejmuje węzły Node1 i Node2. Węzeł Node1 znajduje się w podsieci Subnet1. Węzeł Node2 znajduje się w podsieciach Subnet1 i Subnet2. Instalator SQL Server traktuje tę konfigurację jako klaster wielopodsieciowy i ustawia zależność zasobu adresu IP na wartość OR.

  • Wystąpienie klastra trybu failover programu SQL Server SQLCLUST4 obejmuje węzły Node1 i Node2. Węzeł Node1 jest połączony z podsieciami Subnet1 i Subnet2. Node2 jest również połączony z Subnet1 i Subnet2. Instalator programu SQL Server ustawia zależność zasobu adresu IP na AND.

    Uwaga / Notatka

    Ta konfiguracja nie jest uznawana za konfigurację klastra pracy awaryjnej z wieloma podsieciami, ponieważ węzły klastra należą do tego samego zestawu podsieci.

Zagadnienia dotyczące zasobów adresu IP

W konfiguracji klastra trybu failover z wieloma podsieciami adresy IP nie są własnością wszystkich węzłów w klastrze trybu failover i mogą nie być w trybie online podczas uruchamiania programu SQL Server. Począwszy od wersji SQL Server 2012 (11.x) można ustawić zależność zasobu adresu IP na wartość OR. Dzięki temu program SQL Server może być w trybie online, gdy istnieje co najmniej jeden prawidłowy adres IP, z który może być powiązany.

Uwaga / Notatka

W wersjach programu SQL Server starszych niż SQL Server 2012 (11.x) technologia rozproszonej sieci V-LAN była używana w konfiguracjach klastra z wieloma lokacjami w celu uwidocznienia pojedynczego adresu IP na potrzeby trybu failover między lokacjami. Teraz, gdy program SQL Server może klastrować węzły w różnych podsieciach, możesz skonfigurować klastry trybu failover programu SQL Server w wielu lokacjach bez implementowania technologii rozproszonej sieci V-LAN.

Zagadnienia dotyczące zasobów adresów IP lub zależności

Jeśli ustawisz zależność zasobu adresu IP na OR, warto rozważyć następujące zachowanie podczas przełączania awaryjnego:

  • Jeśli wystąpi awaria jednego z adresów IP w węźle, do którego obecnie należy grupa zasobów klastra SQL Server, przełączenie awaryjne nie zostanie wywołane automatycznie, dopóki nie ulegną awarii wszystkie adresy IP skonfigurowane dla tego węzła.

  • Gdy nastąpi przełączenie awaryjne, SQL Server zostanie uruchomiony, jeśli może powiązać się z co najmniej jednym adresem IP prawidłowym dla bieżącego węzła. Adresy IP, które nie zostały powiązane z programem SQL Server podczas uruchamiania, zostaną wyświetlone w dzienniku błędów.

Jeśli wystąpienie klastra trybu failover (FCI) programu SQL Server jest instalowane obok wystąpienia autonomicznego aparatu bazy danych programu SQL Server, należy zachować ostrożność, aby uniknąć konfliktów numerów portów TCP na adresach IP. Konflikty zwykle występują, gdy dwie instancje Mechanizmu bazy danych skonfigurowano tak, aby używały domyślnego portu TCP (1433). Aby uniknąć konfliktów, skonfiguruj jedno wystąpienie tak, aby używało niezdefaultowego portu stałego. Skonfigurowanie stałego portu jest zwykle łatwiejsze w przypadku samodzielnej instancji. Skonfigurowanie aparatu bazy danych w celu używania różnych portów uniemożliwia nieoczekiwany konflikt adresu IP/portu TCP, który blokuje uruchamianie wystąpienia, gdy wystąpienie klastra trybu failover programu SQL Server kończy się niepowodzeniem w węźle rezerwowym.

Opóźnienie odzyskiwania po stronie klienta podczas przełączania awaryjnego

Domyślnie interfejs FCI z wieloma podsieciami włącza zasób klastra RegisterAllProvidersIP dla swojej nazwy sieciowej. W konfiguracji z wieloma podsieciami adresy IP online i offline nazwy sieci są zarejestrowane na serwerze DNS. Następnie aplikacja kliencka pobiera wszystkie zarejestrowane adresy IP z serwera DNS i próbuje nawiązać połączenie z adresami w kolejności lub równolegle. Oznacza to, że czas odzyskiwania klienta w trybie failover z wieloma podsieciami nie zależy już od opóźnień aktualizacji DNS. Domyślnie klient próbuje kolejnych adresów IP po kolei. Gdy klient używa opcjonalnego MultiSubnetFailover=True parametru w parametrach połączenia, zamiast tego próbuje jednocześnie adresy IP i nawiązuje połączenie z pierwszym serwerem, który odpowiada. Ta konfiguracja może pomóc zminimalizować opóźnienie odzyskiwania klienta w przypadku przejścia w tryb failover. Aby uzyskać więcej informacji, zobacz Łączność klienta Always On (SQL Server) i Tworzenie lub konfigurowanie odbiornika grupy dostępności (SQL Server).

W przypadku starszych bibliotek klienckich lub dostawców danych innych niż Microsoft nie można użyć parametru MultiSubnetFailover w parametrach połączenia. Aby upewnić się, że aplikacja kliencka działa optymalnie w przypadku wystąpienia klastra trybu failover z wieloma podsieciami w programie SQL Server, spróbuj dostosować limit czasu połączenia w parametrach połączenia klienta przez 21 sekund dla każdego dodatkowego adresu IP. Ta konfiguracja zapewnia, że próba ponownego nawiązania połączenia przez klienta nie przekroczy limitu czasu, zanim zdoła przejść przez wszystkie adresy IP w wielopodsieciowym wystąpieniu klastra trybu failover (FCI).

Domyślny limit czasu połączenia klienta dla programu SQL Server Management Studio i sqlcmd wynosi 15 sekund.

Uwaga / Notatka

Jeśli używasz wielu podsieci i masz statyczny system DNS, musisz przeprowadzić proces aktualizacji rekordu DNS skojarzonego z odbiornikiem przed przejściem w tryb failover. W przeciwnym razie nazwa sieci nie stanie się dostępna.

Treści powiązane

  • Last updated on