SQL Server AlwaysOn Availability Groups er Microsofts nyeste teknologi til at imødekomme behovene for høj tilgængelighed og katastrofegendannelse hos organisationer, der bruger SQL Server. En stor fordel ved AlwaysOn er evnen til at adressere både HA og DR i én implementering. De vigtigste fordele ved AlwaysOn, som vi har oplevet, er som følger:
Vi kan gruppere relaterede databaser som en del af en enkelt tilgængelighedsgruppe og have dem failover sammen i tilfælde af et sådant behov. Dette er især nyttigt for programmer, der er afhængige af mere end én database, såsom Microsoft Office SharePoint, Microsoft Lync eller Sage.
Sammenlignet med SQL Server Failover Cluster Instances finder vi ud af, at lagring som et enkelt fejlpunkt er blevet elimineret, da hver forekomst, der udgør en replika, har tildelt sit eget lager.
Med AlwaysOn er det muligt at konfigurere HA og DR på én gang. Dette opnås ved at oprette Multi-Site Windows Failover Clusters som grundlag for din AlwaysOn-konfiguration. At udføre et rolleskifte, når du bruger AlwaysOn, er betydeligt enklere end at gøre det, når du bruger Transaction Log Shipping.
WSFC-afhængigheden
Når du bruger SQL Server AlwaysOn AG til High Availability og Disaster Recovery, skal du først konfigurere en Windows Failover Cluster. AlwaysOn AG'er er afhængige af WFCS til at administrere AlwaysOn AG'en som en rolle, der er sammensat af sådanne klyngresourcer som Availability Group-navnet, fildelingsnavnet, Listener-navnet og en IP-adresse.
Fig. 1 AlwaysOn AG som en klyngressource
Kvorum
Kvorum er det mindste antal stemmer, der kræves for et flertal i en failover-klynge. Kvorum bestemmer, hvor mange knudefejl klyngen kan tåle. Gennem det private netværk på port 3343 kommunikerer alle klynge noder sundhedsstatus og ressourceovervågningsoplysninger. I tilfælde af fiasko viser stemmerne, hvilke noder der har status "Op", og på hvilke noder ressourcer skal bringes online.
Siden Windows Server 2012 er det maksimale antal understøttede cluster noder seksten. Men i de fleste miljøer, jeg er bekendt med, er to-node klynger almindelige. En to-node klynge udgør et lille problem med hensyn til at opnå beslutningsdygtighed, da hver node har én stemme, og hvis der er et problem med kommunikationen mellem de to, kan hver enkelt antage, at den anden ikke er sund. Dette kaldes et split-brain-scenarie. Scenarier med split-hjerne er årsagen til at konfigurere en tiebreaker, såsom en disk eller fildeling.
Hvis du har et ulige antal noder, er det ikke nødvendigt at konfigurere en tiebreaker. Dynamic Quorum Configuration og Dynamic Witness blev introduceret i henholdsvis Windows Server 2012 og Windows Server 2012 R2. Ved hjælp af disse teknologier omfordeler Windows automatisk stemmerne i en klynge, så antallet af noder i en klynge ikke betyder noget ved etableringen af et kvorum. En klyndeknudes stemme fjernes ved at indstille klyngeegenskaben "NodeWeight" til 0. Disse funktioner er aktiveret som standard.
Fig. 2 Få alle klyngeegenskaber ved hjælp af PowerShell
Fig. 3 tildelte stemmer i en klynge med to knudepunkter
Brug af PowerShell
PowerShell Command Get-Cluster kan bruges til at kontrollere Quorum-konfigurationen på en Windows-klynge. Fig. 4 viser, hvordan man kontrollerer alle klyngeegenskaber relateret til kvorum på en klynge, og fig. 5 viser egenskaberne for fildelingsvidnet. Der er mange andre PowerShell-kommandoer til at kontrollere og administrere Windows-klynger.
Get-Cluster | Format-List –Property *Quorum*
Fig. 4 PowerShell-kommando til at kontrollere kvorumsrelaterede egenskaber
Get-ClusterResource
Get-ClusterResource -Name "File Share Witness" | Get-ClusterParameter
Fig. 5 PowerShell-kommando til at kontrollere detaljer om fildelingsvidneegenskaber
Kvorumstilstande
Windows Server Failover Cluster tillader konfiguration af op til fire tilstande. Kvorumstilstande er grundlæggende muligheder, du vælger for at bestemme, hvordan klyngen vil håndtere knudefejl.
1. Nodeflertal
Denne kvorumstilstand kan opretholde fejl på op til (n/2)-1 noder. Det anbefales til klynger med et ulige antal noder. For eksempel, i en klynge med fem knudepunkter, ville det tage en fejl på to knudepunkter for at forårsage en klyngefejl.
2. Node- og diskflertal
Kan opretholde fejl på op til halvdelen af antallet af klynge noder, så længe diskvidnet (også kaldet kvorumdisken) forbliver online.
3. Node- og fildelingsflertal
Denne kvorumstilstand kan opretholde fejl på op til halvdelen af antallet af klynge noder, så længe fildelingen forbliver tilgængelig. Fra og med Windows Server 2012 R2 anbefaler Microsoft, at et vidne (Disk eller File Share) altid skal konfigureres, når der opbygges en klynge.
4. Intet flertal
Dette er kun en disk-tilstand. Denne tilstand kan opretholde fejl i alle noder undtagen én, så længe disken er online. Denne tilstand anbefales ikke, da disken bliver et enkelt fejlpunkt.
Tips om konfiguration af node og fildelingsflertal
AlwaysOn-tilgængelighedsgrupper understøtter kun to af disse kvorumstilstande:Nodemajoritet og Node- og fildelingsmajoritet. Når du bygger en SQL Server AlwaysOn Availability Group-klynge, er der et par punkter, som DBA bør huske på:
1. Brug af fysiske servere
Når du konfigurerer en to-node-klynge til AlwaysOn, skal dine noder ligge i forskellige fysiske racks. Serveren, der hoster din fildeling, skal ligge i et tredje rack.
2. Brug af virtuelle servere
Når du konfigurerer en to-node-klynge til AlwaysOn, skal dine virtuelle maskiner ligge på separate værter. Den virtuelle maskine, der hoster din fildeling, skal ligge på en tredje vært.
3. Multi-Site Clustering
Når du konfigurerer en multi-node-klynge til AlwaysOn på tværs af datacentre, skal filserveren, der hoster din fildeling, i et ideelt scenarie ligge i et tredje datacenter.
4. Fildelingstilladelser
Klyngenavnsobjektet skal have tilladelser til den fildeling, der bruges som kvorumsvidne. Uden dette vil du typisk opleve fejl i forsøget på at konfigurere Kvorumsvidnet.
Fig. 6 tilladelser på fildeling
5. Online konfiguration
Kvorumstilstande kan konfigureres, mens klyngen er online. Så i tilfælde af at fildelingsserveren fejler eller skal omkonfigureres, skal du sørge for hurtigt at omkonfigurere for at sikre, at der ikke er uventede fejl, især på en to-node klynge.
A real-live use case
Diagrammet i fig. 7 viser en rigtig Multi-Site AlwaysOn AG-klynge. Det er en klynge med fire noder med to noder på et sted og to andre på et fjerntliggende DR-sted. Filserveren, der hoster den fildeling, der bruges som tie-breaker, hostes i et tredje datacenter. I det foreliggende tilfælde ligger filserveren i samme by som det primære datacenter, men hvis du har råd til det, ville det være ideelt at have filserveren i en anden by. Kommunikationen mellem de tre sider skal være af god kvalitet for at undgå falske positiver.
For eksempel brugte vi i vores indledende implementering af denne klynge "Synchronous Repplication with Automatic Failover" på tværs af Live- og DR-webstederne. Ved mere end én lejlighed oplevede vi en fejl i kommunikationen, som udløste en automatisk Failover til DR-siden og afslørede en fejl i vores konfiguration. Dette fik Listener-navnet til at løses til de tilknyttede IP-adresser på DR-webstedet, og klienter kunne ikke længere oprette forbindelse, fordi kommunikationen med denne nye IP-adresse ikke var tilladt på netværkets firewalls. Vi undlod simpelthen at vende tilbage til det primære websted for at afhjælpe problemet og ændrede konfigurationen til "Asynkron replikering med manuel failover" for noder, der findes på tværs af datacentre. Vi planlægger at dække navneopløsningsaspektet i vores næste "AlwaysOn"-artikel.
Fig. 7 En real-Live Use Case
Konklusion
AlwaysOn Availability Groups-funktionen blev introduceret i SQL Server 2012 og er Microsofts nyeste teknologi til at imødekomme behov for både høj tilgængelighed og nødgendannelse. Konfiguration af AlwaysOn Availability Groups afhænger i høj grad af Windows Failover Cluster Service. Failover-klynger afhænger til gengæld meget af den korrekte kvorumskonfiguration. Når du bygger AlwaysOn på Multi-Site Clusters, betyder forsinkelsen mellem dine noder på de forskellige websteder og fildelingen, der bruges som arbiter, virkelig noget. Sørg for, at din kvorumskonfiguration altid er i topform for at undgå uventet adfærd med tilgængelighedsgrupperne.
Referencer
Oversigt over AlwaysOn-tilgængelighedsgrupper
Windows Failover-klyngning med SQL Server
PowerShell-dokumentation
Forståelse af Windows Server Failover Cluster Quorum