Delen via

Pacemaker voor beschikbaarheidsgroepen en failoverclusterexemplaren in Linux

Van toepassing op:SQL Server op Linux

Vanaf SQL Server 2017 (14.x) wordt SQL Server ondersteund in zowel Linux als Windows. Net als windows sql Server-implementaties moeten SQL Server-databases en -exemplaren maximaal beschikbaar zijn onder Linux. In dit artikel vindt u informatie over pacemaker met Corosync en hoe u deze kunt plannen en implementeren voor SQL Server-configuraties.

Basisbeginselen van invoegtoepassingen/extensies voor hoge beschikbaarheid

Alle momenteel ondersteunde distributies verzenden een uitbreiding met hoge beschikbaarheid, die is gebaseerd op de Pacemaker-clusteringstack. Deze stack bevat twee belangrijke onderdelen: Pacemaker en Corosync. Alle onderdelen van de stack zijn:

  • Pacemaker. Het kernclusteronderdeel dat dingen coördineert op de geclusterde machines.
  • Corosync. Een framework en een set API's die bijvoorbeeld quorum biedt, de mogelijkheid om mislukte processen opnieuw op te starten, enzovoort.
  • libQB. Biedt zaken zoals logboekregistratie.
  • Resourceagent. Specifieke functionaliteit die wordt geboden zodat een toepassing kan worden geïntegreerd met Pacemaker.
  • Heler. Scripts/functionaliteit die helpen bij het isoleren van knooppunten en ermee omgaan als ze problemen ondervinden.

Opmerking

De clusterstack wordt meestal Pacemaker genoemd in de Linux-wereld.

Deze oplossing is op sommige manieren vergelijkbaar met, maar op veel manieren anders dan het implementeren van geclusterde configuraties met Windows. In Windows is de beschikbaarheidsvorm van clustering, een Windows Server-failovercluster (WSFC), ingebouwd in het besturingssysteem en de functie waarmee een WSFC, failoverclustering, kan worden gemaakt, is standaard uitgeschakeld. In Windows zijn AG's en FCI's gebouwd op een WSFC en hebben ze een strakke integratie door het specifieke resource-DLL dat wordt geleverd door SQL Server. Deze nauw gekoppelde oplossing is mogelijk in grote lijnen omdat het allemaal van één leverancier is.

Diagram van basisbeginselen van hoge beschikbaarheid.

In Linux, terwijl elke ondersteunde distributie Pacemaker beschikbaar heeft, kan elke distributie worden aangepast en enigszins verschillende implementaties en versies hebben. Enkele van de verschillen zullen te zien zijn in de instructies in dit artikel. De clusteringlaag is open source, dus hoewel deze wordt geleverd met de distributies, is deze niet nauw geïntegreerd op dezelfde manier als een WSFC zich onder Windows bevindt. Daarom biedt Microsoft mssql-server-ha, zodat SQL Server en de Pacemaker-stack dicht bij, maar niet precies hetzelfde, ervaring voor AG's en FCI's kunnen bieden als onder Windows.

Voor volledige documentatie over Pacemaker, inclusief een uitgebreidere uitleg over wat alles is met volledige referentie-informatie, voor RHEL en SLES:

Opmerking

Vanaf SQL Server 2025 (17.x) wordt SUSE Linux Enterprise Server (SLES) niet ondersteund.

Zie ook de officiële Pacemaker-documentatiepagina op de ClusterLabs-site voor meer informatie over de hele stack.

Pacemaker-concepten en -terminologie

In deze sectie worden de algemene concepten en terminologie voor een Pacemaker-implementatie beschreven.

Knooppunt

Een knooppunt is een server die deelneemt aan het cluster. Een Pacemaker-cluster ondersteunt standaard maximaal 16 knooppunten. Dit aantal kan worden overschreden als Corosync niet wordt uitgevoerd op extra knooppunten, maar Corosync is vereist voor SQL Server. Daarom is het maximum aantal knooppunten dat een cluster kan hebben voor elke SQL Server-configuratie 16; dit is de Pacemaker-limiet en heeft niets te maken met maximale beperkingen voor AG's of FCI's die worden opgelegd door SQL Server.

Hulpbron

Zowel een WSFC als een Pacemaker-cluster hebben het concept van een resource. Een resource is specifieke functionaliteit die wordt uitgevoerd in de context van het cluster, zoals een schijf of een IP-adres. Zo kunnen onder Pacemaker zowel FCI- als AG-resources worden gemaakt. Dit is niet hetzelfde als wat er in een WSFC wordt gedaan, waarbij u een SQL Server-resource ziet voor een FCI- of een AG-resource bij het configureren van een AG, maar niet precies hetzelfde is vanwege de onderliggende verschillen in de manier waarop SQL Server is geïntegreerd met Pacemaker.

Pacemaker heeft standaard- en kloonbronnen. Kloonresources zijn resources die tegelijkertijd op alle knooppunten worden uitgevoerd. Een voorbeeld hiervan is een IP-adres dat wordt uitgevoerd op meerdere knooppunten voor taakverdelingsdoeleinden. Elke resource die wordt gemaakt voor FCI's maakt gebruik van een standaardresource, omdat slechts één knooppunt op elk gewenst moment een FCI kan hosten.

Opmerking

Dit artikel bevat verwijzingen naar de term slave, een term die Microsoft niet meer gebruikt. Wanneer de term uit de software wordt verwijderd, wordt deze uit dit artikel verwijderd.

Wanneer een AG wordt gemaakt, is een gespecialiseerde vorm van een kloonresource vereist die een resource met meerdere statussen wordt genoemd. Hoewel een AG slechts één primaire replica heeft, draait de beschikbaarheidsgroep zelf op alle knooppunten waarop deze is geconfigureerd en kan het mogelijk functies zoals alleen-lezentoegang toestaan. Omdat dit een 'live' gebruik van het knooppunt is, hebben de resources het concept van twee statussen: Gepromoveerd (voorheen Master) en Niet-uitgepromoteerd (voorheen Slave). Zie Resources met meerdere statussen voor meer informatie: Resources met meerdere modi.

Resourcegroepen/bronnensets

Net als bij rollen in een WSFC heeft een Pacemaker-cluster het concept van een resourcegroep. Een resourcegroep (een set genoemd in SLES) is een verzameling resources die samenwerken en een failover van het ene knooppunt naar een andere kan uitvoeren als één eenheid. Resourcegroepen kunnen geen resources bevatten die zijn geconfigureerd als Gepromoveerd of Niet-gepromoveerd; Ze kunnen dus niet worden gebruikt voor AG's. Hoewel een resourcegroep kan worden gebruikt voor CCI's, is dit doorgaans geen aanbevolen configuratie.

Beperkingen

WSFCs hebben verschillende parameters voor bronnen en zaken zoals afhankelijkheden, die duiden op een ouder-kindrelatie tussen twee verschillende bronnen. Een afhankelijkheid is slechts een regel die de WSFC vertelt welke resource eerst online moet zijn.

Een Pacemaker-cluster heeft niet het concept van afhankelijkheden, maar er zijn beperkingen. Er zijn drie soorten beperkingen: colocatie, locatie en volgorde.

  • Een samenplaatsingsbeperking bepaalt of twee resources al dan niet op hetzelfde knooppunt moeten worden uitgevoerd.
  • Een locatiebeperking geeft aan waar een resource in het Pacemaker-cluster kan of niet kan worden uitgevoerd.
  • Een volgordebeperking geeft het Pacemaker-cluster de volgorde aan waarin de resources moeten worden gestart.

Opmerking

Colocatiebeperkingen zijn niet vereist voor resources in een resourcegroep, omdat ze allemaal als één eenheid worden gezien.

Quorum, beveiligingsagenten en STONITH

Quorum onder Pacemaker is vergelijkbaar met een WSFC qua concept. Het hele doel van het quorummechanisme van een cluster is ervoor te zorgen dat het cluster actief blijft. Zowel een WSFC als de HA-invoegtoepassingen voor de Linux-distributies hebben het concept van stemmen, waarbij elk knooppunt telt voor quorum. U wilt een meerderheid van de stemmen omhoog, anders wordt het cluster in het slechtste geval uitgeschakeld.

In tegenstelling tot een WSFC is er geen witness-resource om met het quorum te werken. Net als een WSFC is het doel om het aantal kiezers oneven te houden. Quorumconfiguratie heeft andere overwegingen voor AG's dan voor FCI's.

WSFCs controleren de status van de deelnemende knooppunten en verwerken deze wanneer er een probleem optreedt. Latere versies van WSFCs bieden functies zoals het in quarantaine plaatsen van een knooppunt dat niet goed werkt of niet beschikbaar is (knooppunt is niet ingeschakeld, netwerkcommunicatie is offline, enzovoort). Aan de Linux-zijde wordt dit type functionaliteit geleverd door een omheiningsagent. Het concept wordt soms ook wel fencing genoemd. Deze omheiningsagents zijn echter specifiek voor de implementatie en worden vaak geleverd door hardwareleveranciers en sommige softwareleveranciers, zoals degenen die hypervisors leveren. VMware biedt bijvoorbeeld een omheiningsagent die kan worden gebruikt voor virtuele Linux-machines die met vSphere worden gevirtualiseerd.

Quorum en fencing zijn gekoppeld aan een ander concept genaamd STONITH, oftewel "Shoot the Other Node in the Head". STONITH is vereist voor een ondersteund Pacemaker-cluster op alle Linux-distributies. Zie Fencing in een Red Hat High Availability Cluster (RHEL) voor meer informatie.

corosync.conf

Het corosync.conf bestand bevat de configuratie van het cluster. Het bevindt zich in /etc/corosync. In de loop van normale dagelijkse bewerkingen moet dit bestand nooit worden bewerkt als het cluster juist is ingesteld.

Locatie van clusterlogboek

Logboeklocaties voor Pacemaker-clusters verschillen, afhankelijk van de distributie.

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

Als u de standaardlocatie voor logboekregistratie wilt wijzigen, wijzigt u corosync.conf.

Pacemaker-clusters plannen voor SQL Server

In deze sectie worden de belangrijke planningspunten voor een Pacemaker-cluster besproken.

Pacemaker-clusters op basis van Linux virtualiseren voor SQL Server

Het gebruik van virtuele machines voor het implementeren van SQL Server-implementaties op basis van Linux voor AG's en FCI's wordt gedekt door dezelfde regels als voor hun Windows-tegenhangers. Er is een basisset regels voor ondersteuning van gevirtualiseerde SQL Server-implementaties die worden geleverd door Microsoft in ondersteuningsbeleid voor Microsoft SQL Server-producten die worden uitgevoerd in een hardwarevirtualisatieomgeving. Verschillende hypervisors, zoals de Hyper-V van Microsoft en de ESXi van VMware, kunnen bovendien verschillende afwijkingen hebben, vanwege verschillen in de platforms zelf.

Als het gaat om AG's en FCI's onder virtualisatie, moet u ervoor zorgen dat antiaffiniteit is ingesteld voor de knooppunten van een bepaald Pacemaker-cluster. Wanneer deze is geconfigureerd voor hoge beschikbaarheid in een AG- of FCI-configuratie, mogen de VM's waarop SQL Server wordt gehost nooit worden uitgevoerd op dezelfde hypervisorhost. Als er bijvoorbeeld een FCI met twee knooppunten is geïmplementeerd, moet er ten minste drie hypervisorhosts zijn, zodat een van de VM's die als host fungeren, ergens aanwezig is als er een hostfout optreedt, met name als u functies zoals livemigratie of vMotion gebruikt.

Zie de Gebruik van gastclustering voor hoge beschikbaarheid voor documentatie van Hyper-V

Netwerk

In tegenstelling tot een WSFC vereist Pacemaker geen toegewezen naam of ten minste één toegewezen IP-adres voor het Pacemaker-cluster zelf. AG's en FCI's hebben IP-adressen nodig (zie de documentatie voor elk voor meer informatie), maar geen namen, omdat er geen netwerknaamresource is. SLES staat de configuratie van een IP-adres toe voor beheerdoeleinden, maar dit is niet vereist, zoals te zien is in het Pacemaker-cluster maken.

Net als een WSFC geeft Pacemaker voorkeur aan redundant netwerken, wat betekent dat afzonderlijke netwerkkaarten (NIC's of pNIC's voor fysieke) afzonderlijke IP-adressen hebben. In termen van de clusterconfiguratie zou elk IP-adres een eigen ring hebben. Net als bij WSFCs worden veel implementaties echter gevirtualiseerd of in de openbare cloud waar slechts één gevirtualiseerde NIC (vNIC) aan de server wordt gepresenteerd. Als alle pc's en vNIC's zijn verbonden met dezelfde fysieke of virtuele switch, is er geen echte redundantie op de netwerklaag, dus het configureren van meerdere NIC's is een beetje een illusie voor de virtuele machine. Netwerkredundantie is meestal ingebouwd in de hypervisor voor gevirtualiseerde implementaties en is zeker ingebouwd in de openbare cloud.

Een verschil met meerdere NIC's en Pacemaker versus een WSFC is dat Pacemaker meerdere IP-adressen op hetzelfde subnet toestaat, terwijl een WSFC dat niet doet. Zie het artikel AlwaysOn-beschikbaarheidsgroepen en failoverclusters configureren voor meer informatie over meerdere subnetten en Linux-clusters.

Quorum en STONITH

Quorumconfiguratie en -vereisten zijn gerelateerd aan AG- of FCI-specifieke implementaties van SQL Server.

STONITH is vereist voor een ondersteund Pacemaker-cluster. Gebruik de documentatie van de distributie om STONITH te configureren. Een voorbeeld hiervan is opslaggebaseerde afsluiting voor SLES. Er is ook een STONITH-agent voor VMware vCenter voor op ESXI gebaseerde oplossingen. Voor meer informatie, zie Stonith Plugin Agent voor VMware VM VCenter SOAP Fencing (niet-officiële).

Interoperabiliteit

In deze sectie wordt beschreven hoe een Linux-cluster kan communiceren met een WSFC of met andere distributies van Linux.

WSFC

Op dit moment is er geen directe manier om een WSFC en een Pacemaker-cluster samen te werken. Dit betekent dat er geen manier is om een AG of FCI te maken die werkt in combinatie met een WSFC en Pacemaker. Er zijn echter twee interoperabiliteitsoplossingen die beide zijn ontworpen voor AG's. De enige manier waarop een FCI kan deelnemen aan een platformoverschrijdende configuratie, is als deze deelneemt als een exemplaar in een van deze twee scenario's:

Andere Linux-distributies

In Linux moeten alle knooppunten van een Pacemaker-cluster zich op dezelfde distributie bevinden. Dit betekent bijvoorbeeld dat een RHEL-knooppunt geen deel kan uitmaken van een Pacemaker-cluster met een SLES-knooppunt. De belangrijkste reden hiervoor was eerder vermeld: de distributies kunnen verschillende versies en functionaliteit hebben, zodat dingen niet goed konden werken. Het mengen van distributies heeft hetzelfde verhaal als het mengen van WSFCs en Linux: gebruik Geen of gedistribueerde AG's.

Verwante inhoud

  • Last updated on