Pacemaker för tillgänglighetsgrupper och redundansklusterinstanser i Linux

gäller för:SQL Server – Linux

Från och med SQL Server 2017 (14.x) stöds SQL Server på både Linux och Windows. Precis som Windows-baserade SQL Server-distributioner måste SQL Server-databaser och instanser ha hög tillgänglighet under Linux. Den här artikeln beskriver grundläggande information för att förstå Pacemaker med Corosync och hur du planerar och distribuerar den för SQL Server-konfigurationer.

Grundläggande om HA-tillägg och extensioner

Alla distributioner som stöds för närvarande skickar ett tillägg/tillägg med hög tillgänglighet, som baseras på Pacemaker-klustringsstacken. Den här stacken innehåller två viktiga komponenter: Pacemaker och Corosync. Alla komponenter i stacken är:

• Pacemaker. Den kärnklusterkomponent som samordnar saker över de klustrade datorerna.
• Corosync. Ett ramverk och en uppsättning API:er som tillhandahåller saker som kvorum, möjligheten att starta om misslyckade processer och så vidare.
• libQB. Tillhandahåller saker som loggning.
• Resursagent. Specifika funktioner som tillhandahålls så att ett program kan integreras med Pacemaker.
• Hälaragent. Skript/funktioner som hjälper till med att isolera noder och hantera dem om de har problem.

Den här lösningen liknar på vissa sätt, men skiljer sig på många andra sätt från att distribuera klustrade konfigurationer med Windows. I Windows är tillgänglighetsformen för klustring, som kallas ett Windows Server-redundanskluster (WSFC), inbyggd i operativsystemet, och funktionen som gör det möjligt att skapa en WSFC, redundanskluster, inaktiveras som standard. I Windows byggs AG:er och FCI:er ovanpå en WSFC och delar nära integrering på grund av den specifika resurs-DLL som tillhandahålls av SQL Server. Den här nära kopplade lösningen är möjlig i stort eftersom allt kommer från en leverantör.

I Linux, medan varje distribution som stöds har Pacemaker tillgänglig, kan varje distribution anpassa och ha lite olika implementeringar och versioner. Några av skillnaderna återspeglas i anvisningarna i den här artikeln. Klustringsskiktet är öppen källkod, så även om det levereras med distributionerna är det inte nära integrerat på samma sätt som en WSFC är under Windows. Därför tillhandahåller Microsoft mssql-server-ha, så att SQL Server och Pacemaker-stacken kan ge nära, men inte exakt samma, upplevelse för AG:er och FCI:er som under Windows.

Fullständig dokumentation om Pacemaker, inklusive en mer ingående förklaring av vad allt är med fullständig referensinformation, för RHEL och SLES:

• RHEL
• SLES
• Ubuntu

Mer information om hela stacken finns också på den officiella dokumentationssidan för Pacemaker på ClusterLabs-webbplatsen.

Pacemakerbegrepp och terminologi

I det här avsnittet beskrivs vanliga begrepp och terminologi för en Pacemaker-implementering.

Nod

En nod är en server som deltar i klustret. Ett Pacemaker-kluster har inbyggt stöd för upp till 16 noder. Det här antalet kan överskridas om Corosync inte körs på ytterligare noder, men Corosync krävs för SQL Server. Därför är det maximala antalet noder som ett kluster kan ha för valfri SQL Server-baserad konfiguration 16. Det här är pacemakergränsen och har inget att göra med maximala begränsningar för AG:er eller FCI:er som införts av SQL Server.

Resurs

Både ett WSFC- och pacemakerkluster har begreppet resurs. En resurs är specifika funktioner som körs i kontexten för klustret, till exempel en disk eller en IP-adress. Under Pacemaker kan till exempel både FCI- och AG-resurser skapas. Detta skiljer sig inte från vad som görs i en WSFC, där du ser en resurs för SQL Server för antingen en FCI- eller en resurs för AG när du konfigurerar en tillgänglighetsgrupp, men det är inte exakt samma sak på grund av de underliggande skillnaderna i hur SQL Server integreras med Pacemaker.

Pacemaker har standard- och klonresurser. Klonade resurser är de som körs samtidigt på alla noder. Ett exempel är en IP-adress som körs på flera noder i belastningsutjämningssyfte. Alla resurser som skapas för FCIs använder en standardresurs, eftersom endast en nod kan vara värd för en FCI vid en viss tidpunkt.

När en tillgänglighetsgrupp skapas krävs en specialiserad form av en klonresurs som kallas för en resurs med flera tillstånd. Även om en tillgänglighetsgrupp bara har en primär replik körs tillgänglighetsgruppen på alla noder som den är konfigurerad för att fungera på och kan eventuellt tillåta saker som skrivskyddad åtkomst. Eftersom detta är en "live" användning av noden har resurserna begreppet två tillstånd: Upphöjd (tidigare Master) och Nedgraderad (tidigare Slav). Mer information finns i Resurser med flera tillstånd: Resurser som har flera lägen.

Resursgrupper/resursuppsättningar

På samma sätt som roller i en WSFC har ett Pacemaker-kluster begreppet resursgrupp. En resursgrupp (kallas en uppsättning i SLES) är en samling resurser som fungerar tillsammans och kan övergå från en nod till en annan som en enda enhet. Resursgrupper får inte innehålla resurser som har konfigurerats som upphöjda eller opromoterade. Därför kan de inte användas för AG:er. Även om en resursgrupp kan användas för FCI:er är det vanligtvis inte en rekommenderad konfiguration.

Begränsningar

WSFCs har olika parametrar för resurser och sådant som beroenden, som anger för WSFC en överordnad/underordnad relation mellan två olika resurser. Ett beroende är bara en regel som talar om för WSFC vilken resurs som måste vara online först.

Ett Pacemaker-kluster har inte begreppet beroenden, men det finns begränsningar. Det finns tre typer av begränsningar: samlokalisering, plats och ordning.

• En samlokaliseringsbegränsning framtvingar om två resurser ska köras på samma nod eller inte.
• En platsbegränsning anger för Pacemaker-klustret var en resurs kan (eller inte kan) köras.
• En ordningsbegränsning anger för Pacemaker-klustret i vilken ordning resurserna ska starta.

Kvorum, stängselagenter och STONITH

Kvorum under Pacemaker liknar en WSFC i begrepp. Hela syftet med ett klusters kvorummekanism är att säkerställa att klustret fortsätter att vara igång. Både ett WSFC- och HA-tillägg för Linux-distributionerna har begreppet röstning, där varje nod räknas mot kvorum. Du vill ha en majoritet av rösterna, annars stängs klustret i värsta fall av.

Till skillnad från en WSFC finns det ingen vittnesresurs som kan användas med kvorum. Liksom en WSFC är målet att hålla antalet väljare udda. Kvorumkonfigurationen har olika överväganden för AG:er än FCI:er.

WSFCs övervakar statusen för de noder som deltar och hanterar dem när ett problem uppstår. Senare versioner av WSFCs erbjuder funktioner som isolering av en nod som är felaktig eller oåtkomlig (noden är inte på, nätverkskommunikationen fungerar inte osv.). På Linux-sidan tillhandahålls den här typen av funktioner av en stängselagent. Begreppet kallas ibland fäktning. Dessa stängselagenter är dock specifika för distributionen och tillhandahålls ofta av maskinvaruleverantörer och vissa programvaruleverantörer, till exempel de som tillhandahåller hypervisor-program. VMware tillhandahåller till exempel en stängselagent som kan användas för virtuella Linux-datorer som virtualiseras med hjälp av vSphere.

Kvorum och säkerhetsåtgärder kopplas till ett annat begrepp som kallas STONITH, eller Shoot the Other Node in the Head. STONITH måste ha ett Pacemaker-kluster som stöds på alla Linux-distributioner. Mer information finns i Fäktning i ett Red Hat High Availability Cluster (RHEL).

corosync.conf

Filen corosync.conf innehåller konfigurationen av klustret. Den finns i /etc/corosync. Under normala dagliga åtgärder bör den här filen aldrig behöva redigeras om klustret har konfigurerats korrekt.

Plats för klusterlogg

Loggplatserna för Pacemaker-kluster varierar beroende på fördelningen.

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

Om du vill ändra standardloggningsplatsen ändrar du corosync.conf.

Planera Pacemaker-kluster för SQL Server

I det här avsnittet beskrivs viktiga planeringspunkter för ett Pacemaker-kluster.

Virtualisera Linux-baserade Pacemaker-kluster för SQL Server

Användning av virtuella datorer för att distribuera Linux-baserade SQL Server-distributioner för AG:er och FCI:er omfattas av samma regler som för deras Windows-baserade motsvarigheter. Det finns en grundläggande uppsättning regler för support för virtualiserade SQL Server-distributioner som tillhandahålls av Microsoft i supportprincip för Microsoft SQL Server-produkter som körs i en maskinvaruvirtualiseringsmiljö. Olika hypervisor-program som Microsofts Hyper-V och VMwares ESXi kan ha olika varianser utöver detta, på grund av skillnader i själva plattformarna.

När det gäller AG:er och FCI:er under virtualisering, säkerställ att anti-affinitet har angetts för noderna i ett visst Pacemaker-kluster. När de har konfigurerats för hög tillgänglighet i en tillgänglighetsgrupp eller FCI-konfiguration bör de virtuella datorer som är värdar för SQL Server aldrig köras på samma hypervisor-värd. Om till exempel en FCI med två noder distribueras skulle det behöva finnas minst tre hypervisor-värdar så att det finns någonstans där en av de virtuella datorerna som är värd för en nod kan köras i händelse av ett värdfel, särskilt om du använder funktioner som direktmigrering eller vMotion.

Mer Hyper-V dokumentation finns i Använda gästkluster för hög tillgänglighet

Nätverk

Till skillnad från en WSFC kräver Pacemaker inte ett dedikerat namn eller minst en dedikerad IP-adress för själva Pacemaker-klustret. AG:er och FCI:er kräver IP-adresser (se dokumentationen för var och en för mer information), men inte namn, eftersom det inte finns någon nätverksnamnsresurs. SLES tillåter konfiguration av en IP-adress i administrationssyfte, men det krävs inte, vilket visas i Skapa Pacemaker-klustret.

Liksom en WSFC skulle Pacemaker föredra redundanta nätverk, det vill säga att distinkta nätverkskort (NIC eller fysiska pNIC) har enskilda IP-adresser. När det gäller klusterkonfigurationen skulle varje IP-adress ha en så kallad egen ring. Men precis som med WSFCs idag virtualiseras många implementeringar eller i det offentliga molnet där det bara finns ett enda virtualiserat nätverkskort (vNIC) som presenteras för servern. Om alla nätverkskort och virtuella nätverkskort är anslutna till samma fysiska eller virtuella växel finns det ingen riktig redundans på nätverksskiktet, så att konfigurera flera nätverkskort är lite av en illusion för den virtuella datorn. Nätverksredundans är vanligtvis inbyggt i hypervisor-programmet för virtualiserade distributioner och är definitivt inbyggt i det offentliga molnet.

En skillnad med flera nätverkskort och Pacemaker jämfört med en WSFC är att Pacemaker tillåter flera IP-adresser i samma undernät, medan en WSFC inte gör det. Mer information om flera undernät och Linux-kluster finns i artikeln Konfigurera alwayson-tillgänglighetsgrupper för flera undernät och redundansklusterinstanser.

Kvorum och STONITH

Kvorumkonfiguration och krav är relaterade till AG- eller FCI-specifika distributioner av SQL Server.

STONITH krävs för ett Pacemaker-kluster som stöds. Använd dokumentationen från distributionen för att konfigurera STONITH. Ett exempel finns på Lagringsbaserad avskärmning för SLES. Det finns också en STONITH-agent för VMware vCenter för ESXI-baserade lösningar. Mer information finns i Stonith Plugin Agent for VMware VM VCenter SOAP Fencing (Unofficial).

Samverkan

I det här avsnittet beskrivs hur ett Linux-baserat kluster kan interagera med en WSFC eller med andra distributioner av Linux.

WSFC

För närvarande finns det inget direkt sätt för ett WSFC- och pacemakerkluster att fungera tillsammans. Det innebär att det inte finns något sätt att skapa en tillgänglighetsgrupp eller FCI som kan samarbeta över en WSFC och Pacemaker. Det finns dock två samverkanslösningar, som båda är utformade för AG:er. Det enda sättet som en FCI kan delta i en plattformsoberoende konfiguration är om den deltar som en instans i något av följande två scenarier:

• En tillgänglighetsgrupp med klustertypen Ingen. Mer information finns i dokumentationen om Windows-tillgänglighetsgrupper.
• En distribuerad tillgänglighetsgrupp, som är en särskild typ av tillgänglighetsgrupp som gör att två olika AG:er kan konfigureras som sin egen tillgänglighetsgrupp. Mer information om distribuerade AG:er finns i dokumentationen distribuerade tillgänglighetsgrupper.

Andra Linux-distributioner

I Linux måste alla noder i ett Pacemaker-kluster finnas på samma distribution. Det innebär till exempel att en RHEL-nod inte kan ingå i ett Pacemaker-kluster som har en SLES-nod. Huvudorsaken till detta angavs tidigare: distributionerna kan ha olika versioner och funktioner, så det gick inte att fungera korrekt. Blandning av distributioner har samma historia som att blanda WSFCs och Linux: använd Ingen eller distribuerade AG:er.

Relaterat innehåll

• Distribuera ett Pacemaker-kluster för SQL Server i Linux
• Konfigurera ett Pacemaker-kluster för SQL Server-tillgänglighetsgrupper