Grupy dostępności dla SQL Server on Linux

Applies to:SQL Server w systemie Linux

W tym artykule opisano charakterystykę grup dostępności w ramach instalacji SQL Server opartych na systemie Linux. Obejmuje również różnice między grupami dostępności (AGs) opartymi na klastrach przełączania awaryjnego (WSFC) w systemach Linux i Windows Server. Zobacz Co to jest zawsze włączona grupa dostępności? dla podstaw grup dostępności AG, gdyż działają one tak samo na systemach Windows i Linux, z wyjątkiem różnic związanych z WSFC.

Z punktu widzenia wysokiego poziomu grupy dostępności w ramach SQL Server on Linux są takie same jak w implementacjach opartych na WSFC. Oznacza to, że wszystkie ograniczenia i funkcje są takie same, z pewnymi wyjątkami. Główne różnice obejmują:

• usługa Microsoft Distributed Transaction Coordinator (DTC) jest obsługiwana w systemie Linux, począwszy od wersji SQL Server 2017 CU 16. Jednak usługa DTC nie jest jeszcze obsługiwana w grupach dostępności w systemie Linux. Jeśli aplikacje wymagają użycia transakcji rozproszonych i potrzebują grupy dostępności, wdróż SQL Server na systemie Windows.
• Wdrożenia oparte na systemie Linux, które wymagają wysokiej dostępności, używają narzędzia Pacemaker do klastrowania zamiast WSFC.
• W przeciwieństwie do większości konfiguracji dla grup dostępności (AG) na Windows, z wyjątkiem scenariusza klastra z grupą roboczą, program Pacemaker nigdy nie wymaga Active Directory Domain Services (AD DS).
• Sposób niepowodzenia grupy dostępności z jednego węzła do innego różni się między systemem Linux i Windows.
• Niektóre ustawienia, takie jak required_synchronized_secondaries_to_commit, można zmienić tylko za pośrednictwem programu Pacemaker w systemie Linux, podczas gdy instalacja oparta na programie WSFC używa Transact-SQL.

Liczba replik i węzłów klastra

Grupa dostępności w edycji SQL Server Standard może mieć dwie repliki w sumie: jedną jako replikę podstawową i jedną jako replikę pomocniczą, która może służyć wyłącznie do zapewnienia dostępności. Nie można jej używać w przypadku żadnych innych elementów, takich jak zapytania czytelne. Grupa dostępności w edycji SQL Server Enterprise może mieć maksymalnie dziewięć replik łącznie: jedną podstawową i maksymalnie osiem pomocniczych, z czego do trzech (łącznie z podstawową) mogą być synchroniczne. W przypadku korzystania z klastra bazowego może istnieć maksymalnie 16 węzłów, gdy jest zaangażowany program Corosync. Grupa dostępności może obejmować co najwyżej dziewięć z 16 węzłów z wersją SQL Server Enterprise i dwie z wersją SQL Server Standard.

Konfiguracja z dwiema replikami, która wymaga automatycznego przełączania się do innej repliki, wymaga użycia repliki tylko do konfiguracji, zgodnie z opisem w sekcji Configuration-only replica and quorum (Replika tylko do konfiguracji i kworum). Repliki przeznaczone wyłącznie do konfiguracji zostały wprowadzone w SQL Server 2017 (14.x) w zbiorczej aktualizacji 1 (CU 1), która powinna być minimalną wdrożoną wersją dla tej konfiguracji.

Jeśli program Pacemaker jest używany, musi być prawidłowo skonfigurowany, aby pozostał uruchomiony. Oznacza to, że kworum i ogrodzenie węzła, które zakończyło się niepowodzeniem, musi być prawidłowo zaimplementowane z perspektywy programu Pacemaker, oprócz wszelkich wymagań SQL Server, takich jak replika tylko do konfiguracji.

Repliki pomocnicze z możliwością odczytu są obsługiwane tylko w wersji SQL Server Enterprise.

Typ klastra i tryb failover

Nowością SQL Server 2017 (14.x) jest wprowadzenie typu klastra dla grup AG. W przypadku systemu Linux istnieją dwie prawidłowe wartości: External i None. Typ klastra Zewnętrzny oznacza, że program Pacemaker jest używany w połączeniu z grupą dostępności. Używanie Zewnętrznego dla typu klastra wiąże się z koniecznością ustawienia trybu failover na Zewnętrzny (również nowym w SQL Server 2017 (14.x)). Automatyczne przełączanie w tryb failover jest obsługiwane, ale w przeciwieństwie do usługi WSFC tryb failover jest ustawiony na wartość Zewnętrzna, a nie automatyczna, gdy jest używany program Pacemaker. W przeciwieństwie do WSFC część pacemaker grupy dostępności jest tworzona po skonfigurowaniu grupy dostępności.

Typ klastra None oznacza, że nie ma potrzeby korzystania z Pacemaker, ani Pacemaker nie jest używany przez grupę dostępności (AG). Nawet na serwerach ze skonfigurowanym programem Pacemaker, jeśli grupa dostępności jest skonfigurowana z typem klastra None, program Pacemaker nie widzi tej grupy dostępności ani nie zarządza nią. Typ klastra None obsługuje tylko ręczne przełączenie awaryjne z repliki podstawowej do repliki drugorzędnej. Grupa dostępności utworzona z funkcją None jest przeznaczona głównie dla uaktualnień i skalowania odczytu w poziomie. Chociaż może działać w scenariuszach, takich jak odzyskiwanie po awarii lub dostępność lokalna, jeśli nie jest konieczne automatyczne przejście w tryb failover, nie jest zalecane. Historia nasłuchującego jest również bardziej złożona bez Pacemaker.

Typ klastra jest przechowywany w widoku zarządzania dynamicznego (DMV) SQL Server sys.availability_groups w kolumnach cluster_type i cluster_type_desc.

wymagane_zsynchronizowane_sekundarne_do_zatwierdzenia

W SQL Server 2017 (14.x) wprowadzono nowe ustawienie używane przez grupy dostępności (AG) o nazwie required_synchronized_secondaries_to_commit. Określa grupie dostępności liczbę replik pomocniczych, które muszą być zsynchronizowane z podstawowym. Umożliwia to takie funkcje jak automatyczne przełączanie w tryb failover (tylko w przypadku integracji z programem Pacemaker z typem klastra Zewnętrzne) i kontroluje zachowanie takich elementów, jak dostępność serwera podstawowego, gdy prawidłowa liczba replik zapasowych jest online lub offline. Aby dowiedzieć się więcej o tym, jak to działa, zobacz Wysoka dostępność i ochrona danych dla konfiguracji grup dostępności. Wartość required_synchronized_secondaries_to_commit jest domyślnie ustawiana i utrzymywana przez program Pacemaker/ SQL Server. Tę wartość można zastąpić ręcznie.

Kombinacja required_synchronized_secondaries_to_commit i nowego numeru sekwencji (który jest przechowywany w sys.availability_groups) informuje Pacemaker i SQL Server, że na przykład automatyczne przełączenie awaryjne może nastąpić. W takim przypadku replika pomocnicza będzie mieć ten sam numer sekwencji co podstawowa, co oznacza, że jest aktualna ze wszystkimi najnowszymi informacjami o konfiguracji.

Istnieją trzy wartości, które można ustawić dla required_synchronized_secondaries_to_commit: 0, 1 lub 2. Kontrolują zachowanie tego, co się stanie, gdy replika stanie się niedostępna. Liczby odpowiadają liczbie replik pomocniczych, które muszą być zsynchronizowane z podstawową. Zachowanie jest następujące w systemie Linux:

required_synchronized_secondaries_to_commit reguluje nie tylko działanie trybu failover w przypadku replik synchronicznych, ale także utratę danych. W przypadku wartości 1 lub 2 replika pomocnicza musi być zawsze zsynchronizowana, aby zapewnić nadmiarowość danych. Oznacza to brak utraty danych.

Aby zmienić wartość required_synchronized_secondaries_to_commit, użyj następującej składni:

Red Hat Enterprise Linux (RHEL) i Ubuntu

sudo pcs resource update <AGResourceName> required_synchronized_secondaries_to_commit=<value>

SUSE Linux Enterprise Server (SLES)

sudo crm resource param ms-<AGResourceName> set required_synchronized_secondaries_to_commit <value>

W tym przykładzie <AGResourceName> jest nazwą zasobu skonfigurowanego dla grupy dostępności i <value> ma wartość 0, 1 lub 2. Aby przywrócić Pacemaker do zarządzania parametrem, wykonaj tę samą instrukcję bez wartości.

Automatyczne przełączanie na grupę dostępności (AG) jest możliwe po spełnieniu następujących warunków:

• Replika podstawowa i replika wtórna są ustawione na synchroniczne przenoszenie danych.
• Pomocnicza ma stan zsynchronizowany (nie w trakcie synchronizacji), co oznacza, że obie są w tym samym punkcie danych.
• Typ klastra jest ustawiony na Wartość Zewnętrzna. Automatyczne przełączanie w tryb failover nie jest możliwe z typem klastra None.
• Replika pomocnicza sequence_number, która stanie się repliką podstawową, ma najwyższy numer sekwencji — innymi słowy, replika pomocnicza sequence_number jest zgodna z oryginalną repliką podstawową.

Jeśli te warunki zostaną spełnione, a serwer hostujący replikę podstawową ulegnie awarii, własność grupy dostępności przejdzie na replikę synchroniczną. Zachowanie synchronicznych replik (z których łącznie mogą być trzy: jedna replika podstawowa i dwie repliki drugorzędne) mogą być dodatkowo kontrolowane przez required_synchronized_secondaries_to_commit. Działa to z grupami AG zarówno w Windows, jak i w systemie Linux, ale jest konfigurowane inaczej. W systemie Linux wartość jest konfigurowana automatycznie przez klaster w samym zasobie grupy dostępności.

Replika konfiguracyjna i kworum

Wprowadzono replikę skonfigurowaną tylko do celu obsługi, aby rozwiązać problemy z ograniczeniami obsługi kworum w narzędziu Pacemaker, zwłaszcza w przypadku odłączania węzła, który uległ awarii. Konfiguracja z tylko dwoma węzłami nie jest funkcjonalna w przypadku grupy dostępności (AG). W przypadku FCI mechanizmy kworum udostępniane przez Pacemaker mogą być w porządku, ponieważ cały arbitraż przełączania awaryjnego odbywa się na warstwie klastra. W przypadku grupy dostępności (AG) arbitraż w systemie Linux odbywa się na SQL Server, gdzie przechowywane są wszystkie metadane. Jest to moment, w którym replika przeznaczona wyłącznie do konfiguracji wchodzi do gry.

Bez niczego innego wymagany byłby trzeci węzeł i co najmniej jedna zsynchronizowana replika. Replika tylko do celów konfiguracyjnych przechowuje konfigurację grupy dostępności w master bazie danych, w tej samej jak inne repliki w konfiguracji grupy dostępności. Replika tylko do konfiguracji nie ma baz danych użytkowników uczestniczących w ag. Dane konfiguracji są wysyłane synchronicznie z serwera podstawowego. Te dane konfiguracji są następnie używane podczas przełączania awaryjnego, zarówno przy automatycznym, jak i ręcznym.

Aby grupa dostępności utrzymywała kworum i umożliwiała automatyczne przełączanie awaryjne z typem klastra „zewnętrzny”, musi spełniać jeden z poniższych warunków:

• Mają trzy synchroniczne repliki (tylko wersja SQL Server Enterprise) lub
• Miej dwie repliki (podstawową i pomocniczą) oraz replikę tylko do konfiguracji.

Ręczny failover może wystąpić, niezależnie od tego, czy w konfiguracjach grup dostępności używane są typy klastrów zewnętrznych, czy też nie. Chociaż replikę wyłącznie do konfiguracji można skonfigurować z grupą dostępności, która ma typ klastra „None”, nie jest to zalecane, ponieważ komplikuje wdrożenie. W przypadku tych konfiguracji ręcznie zmodyfikuj required_synchronized_secondaries_to_commit wartość co najmniej 1, aby była co najmniej jedna zsynchronizowana replika.

Replika tylko do konfiguracji może być hostowana w dowolnej wersji SQL Server, w tym SQL Server Express. Minimalizuje to koszty licencjonowania i zapewnia, że współpracuje z grupami zabezpieczeń w wersji SQL Server Standard. Oznacza to, że trzeci wymagany serwer musi spełniać minimalne wymagania dla SQL Server, ponieważ nie odbiera ruchu transakcji użytkownika dla grupy dostępności (AG).

Gdy używana jest replika tylko do konfiguracji, ma następujące zachowanie:

• Domyślnie required_synchronized_secondaries_to_commit jest ustawiona wartość 0. W razie potrzeby można to zmodyfikować ręcznie do 1.

• W przypadku awarii podstawowego urządzenia i wartości required_synchronized_secondaries_to_commit równej 0, replika pomocnicza stanie się nową repliką główną i będzie dostępna zarówno do odczytu, jak i do zapisu. Jeśli wartość to 1, następuje automatyczne przełączenie awaryjne, ale system nie będzie przyjmować nowych transakcji, dopóki druga replika nie zostanie połączona.

• Jeśli replika pomocnicza ulegnie awarii i required_synchronized_secondaries_to_commit ma wartość 0, replika podstawowa nadal akceptuje transakcje, ale jeśli w tym momencie podstawowa nie powiedzie się, nie ma ochrony danych ani możliwości przejścia w tryb failover (ręcznego lub automatycznego), ponieważ replika pomocnicza nie jest dostępna.

• Jeśli konfiguracyjna replika zakończy się niepowodzeniem, grupa dostępności (AG) działa normalnie, ale nie można przejść w tryb automatycznego failover.

• Jeśli zarówno replika wtórna synchroniczna, jak i replika tylko z konfiguracją zawiodą, replika podstawowa nie może akceptować transakcji i nie ma systemu, do którego mogłaby przełączyć się w trybie awaryjnym.

Wiele grup dostępności

Można utworzyć więcej niż jedną grupę dostępności dla klastra Pacemaker lub zestawu serwerów. Jedynym ograniczeniem jest zasoby systemowe. Własność grupy dostępności (AG) jest wyświetlana przez obiekt nadrzędny. Różne grupy dostępności mogą być własnością różnych węzłów; nie wszystkie muszą działać na tym samym węźle.

Lokalizacja dysku i folderu dla baz danych

Podobnie jak na AG opartych na Windows, struktura dysków i folderów dla baz danych użytkowników biorących udział w AG powinna być identyczna. Jeśli na przykład bazy danych użytkowników znajdują się w /var/opt/mssql/userdata na serwerze A, ten sam folder powinien istnieć na serwerze B. Jedynym wyjątkiem od tego jest sekcja Współdziałanie z grupami dostępności i replikami opartymi na Windows.

Nasłuchiwacz w systemie Linux

Słuchacz jest opcjonalną funkcjonalnością grupy dostępności. Zapewnia pojedynczy punkt wejścia dla wszystkich połączeń (odczyt/zapis do repliki podstawowej i/lub tylko do odczytu do replik pomocniczych), dzięki czemu aplikacje i użytkownicy końcowi nie muszą wiedzieć, który serwer hostuje dane. W usłudze WSFC jest to kombinacja zasobu nazwy sieciowej i zasobu IP, który jest następnie zarejestrowany w usługach AD DS (w razie potrzeby) i DNS. W połączeniu z zasobem AG zapewnia tę abstrakcję. Aby uzyskać więcej informacji na temat odbiornika, zobacz Connect to an Always On availability group listener (Nawiązywanie połączenia z odbiornikiem zawsze włączonej grupy dostępności).

Odbiornik w systemie Linux jest skonfigurowany inaczej, ale jego funkcjonalność jest taka sama. Nie ma pojęcia zasobu nazwy sieciowej w narzędziu Pacemaker ani obiektu utworzonego w usługach AD DS; Istnieje tylko zasób adresu IP utworzony w narzędziu Pacemaker, który można uruchomić w dowolnym z węzłów. Należy utworzyć wpis skojarzony z zasobem IP dla odbiornika w systemie DNS z "przyjazną nazwą". Zasób adresu IP dla odbiornika jest aktywny tylko na serwerze hostującym replikę podstawową dla tej grupy dostępności.

Jeśli jest używany program Pacemaker, a tworzony jest zasób adresu IP skojarzony z odbiornikiem, występuje krótka awaria, ponieważ adres IP zatrzymuje się na jednym serwerze i uruchamia się na drugim, niezależnie od tego, czy jest to automatyczne, czy ręczne przejście w tryb failover. Chociaż zapewnia to abstrakcję za pomocą kombinacji pojedynczej nazwy i adresu IP, nie maskuje awarii. Aplikacja musi być w stanie obsłużyć rozłączenie, mając jakieś funkcje wykrywania tego i ponownego nawiązywania połączenia.

Jednak kombinacja nazwy DNS i adresu IP jest nadal niewystarczająca, aby zapewnić wszystkie funkcje, które oferuje nasłuchiwacz w klastrze WSFC, takie jak routing tylko do odczytu dla replik pomocniczych. Podczas konfigurowania AG, odbiorca nadal musi być skonfigurowany w SQL Server. Można to zobaczyć w kreatorze i składni Transact-SQL. Istnieją dwa sposoby, na które można skonfigurować funkcję tak samo jak w Windows:

• W przypadku grupy dostępności z typem klastra Zewnętrzne adres IP skojarzony z odbiornikiem utworzonym w SQL Server powinien być adresem IP zasobu utworzonego w programie Pacemaker.
• W przypadku grupy dostępności utworzonej z typem klastra None użyj adresu IP skojarzonego z repliką podstawową.

Wystąpienie skojarzone z podanym adresem IP staje się koordynatorem takich elementów jak żądania routingu tylko do odczytu z aplikacji.

Współdziałanie z grupami dostępności i replikami opartymi na systemie Windows

Grupa dostępności, która ma typ klastra External lub jest klastrem WSFC, nie może mieć replik na różnych platformach. To prawda, niezależnie od tego, czy AG to SQL Server Standard Edition, czy SQL Server Enterprise Edition. Oznacza to, że w tradycyjnej konfiguracji AG z klastrem podstawowym jedna replika nie może znajdować się na WSFC, a druga w systemie Linux z pacemakerem.

Grupa dostępności o typie klastra NONE może mieć repliki działające na różnych systemach operacyjnych, więc w tej samej Grupie Dostępności mogą istnieć repliki zarówno na systemie Linux, jak i Windows. Przykład pokazano tutaj, gdzie replika podstawowa jest oparta na Windows, podczas gdy zapasowa znajduje się na jednej z dystrybucji Linuksa.

Rozproszona grupa dostępności może również przekraczać granice systemu operacyjnego. Bazowe grupy zabezpieczeń są powiązane z regułami dotyczącymi sposobu ich konfigurowania, takich jak grupa zewnętrzna skonfigurowana tylko dla systemu Linux, ale grupa dostępności, do której jest przyłączona, może być skonfigurowana przy użyciu usługi WSFC. Rozważmy następujący przykład:

Treści powiązane

• Konfiguruj grupę dostępności SQL Server w celu zapewnienia wysokiej dostępności w systemie Linux
• Konfiguruj grupę dostępności SQL Server do skalowania odczytu w systemie Linux
• Konfiguruj klaster Pacemaker dla grup dostępności SQL Server
• Konfigurowanie zawsze włączonej grupy dostępności SQL Server w Windows i Linux (międzyplatformowe)