Oprogramowanie Pacemaker dla grup dostępności i wystąpień klastra trybu przełączenia awaryjnego w systemie Linux

Applies to:SQL Server w systemie Linux

Począwszy od wersji SQL Server 2017 (14.x), SQL Server jest obsługiwana zarówno w systemie Linux, jak i Windows. Podobnie jak w przypadku wdrożeń SQL Server opartych na systemie Windows, bazy danych i instancje SQL Server muszą być wysoce dostępne w systemie Linux. W tym artykule opisano podstawowe informacje dotyczące programu Pacemaker z aplikacją Corosync oraz sposób planowania i wdrażania go na potrzeby konfiguracji SQL Server.

Podstawowe informacje o dodatku lub rozszerzeniu dotyczące wysokiej dostępności

Wszystkie obecnie obsługiwane dystrybucje dostarczają dodatek/rozszerzenie o wysokiej dostępności oparte na stosie klastrowania Pacemaker. Ten zestaw zawiera dwa kluczowe składniki: Pacemaker i Corosync. Wszystkie składniki stosu to:

• Rozrusznik serca. Podstawowy składnik klastrowania, który koordynuje elementy na maszynach klastrowanych.
• Corosync. Struktura i zestaw interfejsów API, które udostępniają takie elementy jak kworum, możliwość ponownego uruchamiania procesów, które zakończyły się niepowodzeniem itd.
• libQB. Udostępnia takie elementy jak rejestrowanie.
• Agent zasobów. Udostępniono określone funkcje, dzięki czemu aplikacja może integrować się z programem Pacemaker.
• Agent ogrodzenia. Skrypty/funkcje, które ułatwiają izolowanie węzłów i radzenie sobie z nimi, jeśli występują problemy.

To rozwiązanie jest podobne do niektórych sposobów, ale na wiele sposobów różni się od wdrażania konfiguracji klastrowanych przy użyciu Windows. W Windows forma dostępności klastrowania, nazywana klastrem trybu failover Windows Server (WSFC), jest wbudowana w system operacyjny, a funkcja, która umożliwia tworzenie klastra WSFC, trybu failover, jest domyślnie wyłączona. W systemie Windows grupy dostępności (AGs) i instancje klastrowane trybu awaryjnego (FCIs) są oparte na WSFC i są ściśle zintegrowane dzięki specyficznej bibliotece DLL zasobów dostarczanej przez SQL Server. To ściśle powiązane rozwiązanie jest możliwe w dużej mierze, ponieważ wszystko pochodzi od jednego dostawcy.

W systemie Linux, podczas gdy każda obsługiwana dystrybucja ma dostępny program Pacemaker, każda dystrybucja może dostosowywać i mieć nieco inne implementacje i wersje. Niektóre różnice zostaną odzwierciedlone w instrukcjach w tym artykule. Warstwa klastrowania jest open source, więc mimo że jest dostarczana z dystrybucjami, nie jest ściśle zintegrowana tak, jak WSFC działa w systemie Windows. Dlatego Microsoft zapewnia mssql-server-ha, dzięki czemu SQL Server i stos Pacemaker mogą zapewnić blisko, ale nie dokładnie takie samo środowisko dla grup AG i fcI, jak w Windows.

Aby uzyskać pełną dokumentację Pacemaker, zawierającą szczegółowe wyjaśnienie oraz pełne informacje referencyjne dla RHEL i SLES:

• RHEL
• SLES
• Ubuntu

Aby uzyskać więcej informacji na temat całego stosu, zobacz również oficjalną stronę dokumentacji programu Pacemaker w witrynie ClusterLabs.

Pojęcia i terminologia programu Pacemaker

W tej sekcji opisano typowe pojęcia i terminologię dotyczącą implementacji programu Pacemaker.

Node

Węzeł jest serwerem uczestniczącym w klastrze. Klaster Pacemaker natywnie obsługuje maksymalnie 16 węzłów. Tę liczbę można przekroczyć, jeśli aplikacja Corosync nie jest uruchomiona w dodatkowych węzłach, ale do SQL Server jest wymagana funkcja Corosync. W związku z tym maksymalna liczba węzłów, które klaster może mieć dla dowolnej konfiguracji opartej na SQL Server, wynosi 16. Jest to limit programu Pacemaker i nie ma nic wspólnego z maksymalnymi ograniczeniami dla Grup Dostępności lub wystąpień FCI, które narzuca SQL Server.

Zasób

Zarówno klaster WSFC, jak i klaster Pacemaker posiadają koncepcję zasobu. Zasób jest specyficzną funkcją, która działa w kontekście klastra, na przykład dysku lub adresu IP. Na przykład, w systemie Pacemaker można utworzyć zasoby FCI i AG. Nie jest to zasadniczo różne od tego, co wykonuje się w WSFC, gdzie widoczny jest zasób SQL Server dla zasobu FCI lub zasobu AG podczas konfigurowania grupy dostępności, ale nie jest to dokładnie to samo z powodu podstawowych różnic w sposobie, w jaki SQL Server integruje się z Pacemakerem.

Program Pacemaker ma standardowe i klonowane zasoby. Zasoby klonowane to te, które działają jednocześnie na wszystkich węzłach. Przykładem może być adres IP, który działa na wielu węzłach na potrzeby równoważenia obciążenia. Każdy zasób tworzony dla wystąpień klastra trybu failover używa zasobu standardowego, ponieważ w danym momencie tylko jeden węzeł może hostować wystąpienie klastra trybu failover.

Gdy tworzona jest AG, wymaga wyspecjalizowanej formy zasobu klonowego, zwanego zasobem wielostanowym. Mimo że Grupa dostępności ma tylko jedną replikę podstawową, sama Grupa dostępności działa na wszystkich węzłach, na których została skonfigurowana, i może potencjalnie umożliwiać dostęp tylko do odczytu. Ponieważ jest to "aktywne" użycie węzła, zasoby mają pojęcie dwóch stanów: Promowane (wcześniej Master) i Niepromowane (wcześniej Slave). Aby uzyskać więcej informacji, zobacz Zasoby wielostanowe: zasoby, które mają wiele trybów.

Grupy zasobów/zestawy

Podobnie jak role w usłudze WSFC, klaster Pacemaker ma koncepcję grupy zasobów. Grupa zasobów (nazywana zestawem w systemie SLES) jest kolekcją zasobów, które działają razem i mogą przełączać się w tryb failover z jednego węzła do drugiego jako pojedyncza jednostka. pl-PL: Grupy zasobów nie mogą zawierać zasobów skonfigurowanych jako promowane lub niepromowane; w związku z tym nie można ich używać w przypadku grup dostępności. Grupy zasobów można używać w przypadku wystąpień klastra trybu failover, ale zazwyczaj nie jest to zalecana konfiguracja.

Ograniczenia

WSFCs mają różnorodne parametry dotyczące zasobów, takie jak zależności, które informują usługę WSFC o relacji nadrzędnej/podrzędnej między dwoma różnymi zasobami. Zależność to tylko reguła, która mówi WSFC, który zasób musi być najpierw dostępny online.

Klaster Pacemaker nie ma pojęcia zależności, ale istnieją ograniczenia. Istnieją trzy rodzaje ograniczeń: kolokacja, lokalizacja i kolejność.

• Ograniczenie kolokacji wymusza, czy w tym samym węźle powinny być uruchomione dwa zasoby.
• Ograniczenie lokalizacji definiuje, gdzie w klastrze Pacemaker można (lub nie) uruchomić zasób.
• Reguła kolejności informuje klaster Pacemaker o kolejności uruchamiania zasobów.

Kworum, agenci ogrodzenia i STONITH

Kworum w ramach Pacemakera jest koncepcyjnie podobne do WSFC. Cały cel mechanizmu kworum klastra jest zapewnienie, że klaster pozostaje uruchomiony i działa. Zarówno dodatek WSFC, jak i dodatek HA dla dystrybucji systemu Linux mają koncepcję głosowania, gdzie każdy węzeł wnosi wkład do kworum. Chcesz, aby większość głosów była za, jeśli nie, w najgorszym scenariuszu klaster zostanie zamknięty.

W przeciwieństwie do WSFC, nie ma zasobu świadka do współpracy z kworum. Podobnie jak w WSFC, celem jest utrzymanie liczby głosujących na poziomie nieparzystym. Konfiguracja kworum wymaga innych uwzględnień dla grup dostępności niż dla wystąpień klastrów przy pracy awaryjnej.

WSFCs monitorują stan uczestniczących węzłów i obsługują je w przypadku wystąpienia problemu. Nowsze wersje platformy WSFCs oferują takie funkcje jak kwarantowanie węzła, który działa nieprawidłowo lub jest niedostępny (węzeł nie jest włączony, komunikacja sieciowa nie działa itp.). Po stronie systemu Linux ten typ funkcjonalności jest dostarczany przez agenta ogrodzenia. Koncepcja ta jest czasami określana jako fechtowanie. Jednak te mechanizmy zabezpieczające są specyficzne dla wdrożenia i często są udostępniane przez dostawców sprzętu i niektórych dostawców oprogramowania, takich jak ci, którzy oferują hypervisory. Na przykład program VMware udostępnia agenta ogrodzenia, który może być używany dla maszyn wirtualnych z systemem Linux zwirtualizowanych przy użyciu programu vSphere.

Kworum i mechanizm odizolowania są powiązane z inną koncepcją zwaną STONITH, czyli Strzel w Głowę Drugi Węzeł. StoNITH jest wymagany do posiadania obsługiwanego klastra Pacemaker we wszystkich dystrybucjach systemu Linux. Aby uzyskać więcej informacji, zobacz Fencing in a Red Hat High Availability Cluster (RHEL).

corosync.conf

Plik corosync.conf zawiera konfigurację klastra. Znajduje się on w lokalizacji /etc/corosync. W trakcie normalnych codziennych operacji ten plik nigdy nie powinien być edytowany, jeśli klaster jest prawidłowo skonfigurowany.

Lokalizacja dziennika klastra

Miejsca przechowywania dzienników klastrów Pacemaker różnią się w zależności od dystrybucji.

• RHEL i SLES: /var/log/cluster/corosync.log
• Ubuntu: /var/log/corosync/corosync.log

Aby zmienić domyślną lokalizację rejestrowania, zmodyfikuj element corosync.conf.

Planowanie klastrów Pacemaker dla SQL Server

W tej sekcji omówiono ważne punkty planowania klastra Pacemaker.

Wirtualizacja klastrów Pacemaker opartych na systemie Linux dla SQL Server

Używanie maszyn wirtualnych do wdrażania SQL Server opartych na systemie Linux dla grupy dostępności (AG) i instancji klastra trybu failover (FCI) jest objęte tymi samymi regułami, co w przypadku ich odpowiedników opartych na Windows. Istnieje podstawowy zestaw reguł dotyczących wsparcia zwirtualizowanych wdrożeń SQL Server, udostępniany przez Microsoft w zasady wsparcia dla produktów Microsoft SQL Server działających w środowisku wirtualizacji sprzętu. Różne hypervisory, takie jak Hyper-V od Microsoft i VMware ESXi, mogą mieć różnice w związku z tym, ze względu na różnice w samych platformach.

Jeśli chodzi o grupy wysokiej dostępności i instancje klastra przełączania awaryjnego, upewnij się, że dla węzłów danego klastra Pacemaker ustawiono anty-koligację. Jeśli skonfigurowano wysoką dostępność w konfiguracji grupy dostępności lub konfiguracji wystąpienia klastra przełączania awaryjnego, maszyny wirtualne hostujące SQL Server nigdy nie powinny być uruchomione na tym samym hoście hyperwizora. Na przykład, jeśli wdrażany jest dwuwęzłowy FCI, muszą istnieć co najmniej trzy hosty hypervisora, aby było miejsce dla maszyny wirtualnej hostującej węzeł, aby mogła się przenieść w przypadku awarii hosta, zwłaszcza jeśli używane są funkcje takie jak Migracja na żywo lub vMotion.

Aby uzyskać dokumentację Hyper-V, zobacz Użycie klastra gościa w celu zapewnienia wysokiej dostępności

Sieć

W przeciwieństwie do usługi WSFC program Pacemaker nie wymaga dedykowanej nazwy ani co najmniej jednego dedykowanego adresu IP dla samego klastra Pacemaker. Grupy dostępności i instancje klastrów trybu failover będą wymagać adresów IP (sprawdź dokumentację dla każdego z nich, aby uzyskać więcej informacji), ale nie nazw, ponieważ nie ma zasobu nazwy sieciowej. Usługa SLES zezwala na konfigurację adresu IP do celów administracyjnych, ale nie jest wymagana, jak widać w temacie Tworzenie klastra Pacemaker.

Podobnie jak WSFC, Pacemaker preferuje nadmiarową sieć, co oznacza, że różne karty sieciowe (NIC lub pNIC dla fizycznych interfejsów) mają indywidualne adresy IP. Jeśli chodzi o konfigurację klastra, każdy adres IP będzie miał to, co jest znane jako własny pierścień. Jednak podobnie jak w przypadku usług WSFCs obecnie wiele implementacji jest zwirtualizowanych lub w chmurze publicznej, w której istnieje tylko jedna zwirtualizowana karta sieciowa (vNIC) przedstawiona serwerowi. Jeśli wszystkie pNIC i vNIC są połączone z tym samym przełącznikiem fizycznym lub wirtualnym, nie ma prawdziwej nadmiarowości w warstwie sieciowej, dlatego skonfigurowanie wielu kart sieciowych jest tylko pozorna dla maszyny wirtualnej. Redundancja sieci jest zwykle wbudowana w hypervisor dla wdrożeń zwirtualizowanych i zdecydowanie w chmurze publicznej.

Jedną z różnic między wieloma kartami sieciowymi a Pacemakerem w porównaniu z WSFC jest to, że Pacemaker pozwala na wiele adresów IP w tej samej podsieci, podczas gdy WSFC nie. Aby uzyskać więcej informacji na temat wielu podsieci i klastrów systemu Linux, zobacz artykuł Configure multiple-subnet Always On availability groups and failover cluster instances (Konfigurowanie zawsze włączonych grup dostępności i wystąpień klastra trybu failover).

Kworum i STONITH

Konfiguracja kworum i wymagania dotyczą wdrożeń SQL Server specyficznych dla grupy dostępności (AG) lub klastrowania trybu failover (FCI).

StoNITH jest wymagany dla obsługiwanego klastra Pacemaker. Skorzystaj z dokumentacji z dystrybucji, aby skonfigurować STONITH. Przykładem jest ogrodzenie oparte na magazynie dla SLES. Istnieje również agent STONITH dla oprogramowania VMware vCenter dla rozwiązań opartych na technologii ESXI. Aby uzyskać więcej informacji, zobacz Stonith Plugin Agent for VMware VM VCenter SOAP Fencing (Nieoficjalne).

Współdziałanie

W tej sekcji opisano, jak klaster oparty na systemie Linux może wchodzić w interakcje z usługą WSFC lub z innymi dystrybucjami systemu Linux.

WSFC

Obecnie nie ma bezpośredniego sposobu współpracy klastra WSFC i Pacemaker. Oznacza to, że nie ma możliwości utworzenia AG lub klastra przełączania awaryjnego działającego w ramach usług WSFC i Pacemaker. Istnieją jednak dwa rozwiązania współdziałania, z których oba są przeznaczone dla grup zabezpieczeń. Jedynym sposobem, w jaki zgrupowanie instancji klastra trybu awaryjnego może uczestniczyć w konfiguracji międzyplatformowej, jest udział jako instancja w jednym z tych dwóch scenariuszy:

• Grupa dostępności z typem klastra None. Aby uzyskać więcej informacji, zobacz dokumentację Windows dotyczącą grup dostępności.
• Rozproszona grupa dostępności, która jest specjalnym typem grupy dostępności, umożliwiająca skonfigurowanie dwóch różnych grup dostępności jako indywidualnych grup dostępności. Aby uzyskać więcej informacji na temat rozproszonych grup dostępności, zobacz dokumentację Rozproszone grupy dostępności.

Inne dystrybucje systemu Linux

W systemie Linux wszystkie węzły klastra Pacemaker muszą znajdować się w tej samej dystrybucji. Oznacza to na przykład, że węzeł RHEL nie może być częścią klastra Pacemaker, który ma węzeł SLES. Główną przyczyną tego stanu była wcześniej określona: dystrybucje mogą mieć różne wersje i funkcje, więc elementy nie mogły działać prawidłowo. Dystrybucje łączenia mają taką samą historię jak łączenie klastrów WSFC i Linuksa: użyj opcji brak lub rozproszone grupy dostępności.

Treści powiązane

• Wdrażanie klastra Pacemaker dla SQL Server na Linuxie
• Konfiguruj klaster Pacemaker dla grup dostępności SQL Server