SQL Server AlwaysOn Availability Groups är Microsofts senaste teknik för att tillgodose behoven med hög tillgänglighet och katastrofåterställning hos organisationer som använder SQL Server. En stor fördel med AlwaysOn är möjligheten att adressera både HA och DR i en implementering. De viktigaste fördelarna med AlwaysOn som vi har upplevt är följande:
Vi kan gruppera relaterade databaser som en del av en enda Tillgänglighetsgrupp och ha dem failover tillsammans vid ett sådant behov. Detta är särskilt användbart för applikationer som är beroende av mer än en databas som Microsoft Office SharePoint, Microsoft Lync eller Sage.
Jämfört med SQL Server Failover Cluster Instances, finner vi att lagring som en enda felpunkt har eliminerats eftersom varje instans som utgör en replik har sin egen lagring tilldelad.
Med AlwaysOn är det möjligt att konfigurera HA och DR på en gång. Detta uppnås genom att skapa Multi-Site Windows Failover-kluster som grund för din AlwaysOn-konfiguration. Att utföra ett rollbyte när du använder AlwaysOn är betydligt enklare än att göra det när du använder Transaction Log Shipping.
WSFC-beroendet
När du använder SQL Server AlwaysOn AG för High Availability och Disaster Recovery, måste du först konfigurera ett Windows Failover-kluster. AlwaysOn AG:er är beroende av WFCS för att hantera AlwaysOn AG som en roll som består av sådana klusterresurser som tillgänglighetsgruppens namn, filresursnamnet, lyssnarens namn och en IP-adress.
Fig. 1 AlwaysOn AG som en klusterresurs
Quorum
Quorum är det minsta antal röster som krävs för en majoritet i ett failover-kluster. Kvorum bestämmer hur många nodfel klustret kan tåla. Genom det privata nätverket på port 3343 kommunicerar alla klusternoder hälsostatus och resursövervakningsinformation. Vid misslyckande visar rösterna vilka noder som har "Upp"-status och på vilka nodresurser som måste kopplas online.
Sedan Windows Server 2012 är det maximala antalet klusternoder som stöds sexton. Men i de flesta miljöer jag känner till är kluster med två noder vanliga. Ett kluster med två noder utgör ett litet problem när det gäller att uppnå beslutförhet eftersom varje nod har en röst och om det finns ett problem med kommunikationen mellan de två kan var och en anta att den andra inte är frisk. Detta kallas ett scenario med split-brain. Scenarier med delad hjärna är anledningen till att konfigurera en tiebreaker som en disk eller fildelning.
Om du har ett udda antal noder är det inte nödvändigt att konfigurera en tiebreaker. Dynamic Quorum Configuration och Dynamic Witness introducerades i Windows Server 2012 respektive Windows Server 2012 R2. Med hjälp av dessa teknologier omfördelar Windows automatiskt rösterna i ett kluster så att antalet noder i ett kluster inte spelar någon roll vid upprättandet av ett kvorum. En klusternods röst tas bort genom att sätta klusteregenskapen "NodeWeight" till 0. Dessa funktioner är aktiverade som standard.
Fig. 2 Få alla klusteregenskaper med PowerShell
Fig. 3 tilldelade röster i ett kluster med två noder
Använda PowerShell
PowerShell Command Get-Cluster kan användas för att kontrollera kvorumkonfigurationen på ett Windows-kluster. Fig. 4 visar hur man kontrollerar alla klusteregenskaper relaterade till Quorum på ett kluster och Fig. 5 visar egenskaperna för fildelningsvittnet. Det finns många andra PowerShell-kommandon för att kontrollera och hantera Windows-kluster.
Get-Cluster | Format-List –Property *Quorum*
Fig. 4 PowerShell-kommando för att kontrollera kvorumrelaterade egenskaper
Get-ClusterResource
Get-ClusterResource -Name "File Share Witness" | Get-ClusterParameter
Fig. 5 PowerShell-kommando för att kontrollera detaljer om fildelningsvittnesegenskaper
Kvorumlägen
Windows Server Failover Cluster tillåter konfigurering av upp till fyra lägen. Kvorumlägen är i huvudsak alternativ du väljer för att avgöra hur klustret ska hantera nodfel.
1. Nodmajoritet
Detta kvorumläge kan upprätthålla fel på upp till (n/2)-1 noder. Det rekommenderas för kluster med ett udda antal noder. Till exempel, i ett kluster med fem noder, skulle det krävas ett fel på två noder för att orsaka ett klusterfel.
2. Nod- och diskmajoritet
Kan upprätthålla fel på upp till hälften av antalet klusternoder så länge diskvittnet (även kallat kvorumdisken) är online.
3. Nod- och fildelningsmajoritet
Detta kvorumläge kan upprätthålla fel på upp till hälften av antalet klusternoder så länge som filresursen förblir tillgänglig. Från och med Windows Server 2012 R2 rekommenderar Microsoft att ett vittne (Disk eller File Share) alltid ska konfigureras när man bygger ett kluster.
4. Ingen majoritet
Detta är ett endast diskläge. Detta läge kan upprätthålla fel på alla noder utom en så länge som disken är online. Det här läget rekommenderas inte eftersom disken blir en enda felpunkt.
Tips om att konfigurera nod och fildelningsmajoritet
AlwaysOn-tillgänglighetsgrupper stöder endast två av dessa kvorumlägen:Nodmajoritet och Nod- och fildelningsmajoritet. När du bygger ett SQL Server AlwaysOn Availability Group-kluster finns det några punkter som DBA bör tänka på:
1. Använda fysiska servrar
När du konfigurerar ett kluster med två noder för AlwaysOn måste dina noder finnas i olika fysiska rack. Servern som är värd för din filresurs måste finnas i ett tredje rack.
2. Använda virtuella servrar
När du konfigurerar ett kluster med två noder för AlwaysOn måste dina virtuella maskiner finnas på separata värdar. Den virtuella maskinen som är värd för din filresurs måste finnas på en tredje värd.
3. Multi-Site Clustering
När du konfigurerar ett multinodkluster för AlwaysOn över datacenter, i ett idealiskt scenario måste filservern som är värd för din filresurs finnas i ett tredje datacenter.
4. Fildelningsbehörigheter
Klusternamnsobjektet bör ha behörigheter för den filresurs som används som kvorumvittne. Utan detta skulle du vanligtvis uppleva fel när du försöker konfigurera kvorumvittnet.
Fig. 6 behörigheter för fildelning
5. Onlinekonfiguration
Kvorumlägen kan konfigureras medan klustret är online. Så om fildelningsservern misslyckas eller behöver konfigureras om, se till att du snabbt konfigurerar om för att garantera att det inte finns några oväntade fel, särskilt på ett kluster med två noder.
A real-live use case
Diagrammet i Fig. 7 visar ett riktigt Multi-Site AlwaysOn AG-kluster. Det är ett kluster med fyra noder med två noder på en plats och två andra på en avlägsen DR-plats. Filservern som är värd för fildelningen som används som tie-breaker är värd i ett tredje datacenter. I det aktuella fallet finns filservern i samma stad som det primära datacentret, men om du har råd skulle det vara idealiskt att ha filservern i en annan stad. Kommunikationen mellan de tre sidorna måste vara av god kvalitet för att undvika falska positiva resultat.
Till exempel, i vår första implementering av det här klustret använde vi "Synchronous Repplication with Automatic Failover" på Live- och DR-webbplatserna. Vid mer än ett tillfälle upplevde vi ett kommunikationsfel som utlöste en automatisk failover till DR-webbplatsen och avslöjade ett fel i vår konfiguration. Detta gjorde att lyssnarnamnet löstes till de associerade IP-adresserna på DR-webbplatsen och klienterna kunde inte längre ansluta eftersom kommunikationen med denna nya IP-adress inte var tillåten på nätverkets brandväggar. Vi misslyckades helt enkelt tillbaka till den primära platsen för att mildra problemet och ändrade konfigurationen till "Asynkron replikering med manuell övergång" för noder som finns över datacenter. Vi planerar att täcka namnupplösningsaspekten i vår nästa "AlwaysOn"-artikel.
Fig. 7 Ett verkligt användningsfall
Slutsats
Funktionen AlwaysOn Availability Groups introducerades i SQL Server 2012 och är Microsofts senaste teknik för att tillgodose behoven för både hög tillgänglighet och katastrofåterställning. Konfigurering av AlwaysOn-tillgänglighetsgrupper är starkt beroende av Windows Failover Cluster Service. Failover-kluster beror i sin tur mycket på korrekt kvorumkonfiguration. När du bygger AlwaysOn på Multi-Site Clusters spelar latensen mellan dina noder på de olika platserna och fildelningen som används som en medlare verkligen roll. Se till att din kvorumkonfiguration alltid är i toppform för att undvika oväntade beteenden med tillgänglighetsgrupperna.
Referenser
Översikt över AlwaysOn-tillgänglighetsgrupper
Windows-failover-klustring med SQL Server
PowerShell-dokumentation
Förstå Windows Server Failover Cluster Quorum