SQL Server AlwaysOn-beschikbaarheidsgroepen is de nieuwste technologie van Microsoft om te voorzien in de behoeften op het gebied van hoge beschikbaarheid en noodherstel van organisaties die SQL Server gebruiken. Een groot voordeel van AlwaysOn is de mogelijkheid om zowel HA als DR in één implementatie aan te pakken. De belangrijkste voordelen van AlwaysOn die we hebben ervaren zijn de volgende:
We kunnen gerelateerde databases groeperen als onderdeel van een enkele beschikbaarheidsgroep en ze samen laten failoveren in het geval van een dergelijke behoefte. Dit is vooral handig voor toepassingen die afhankelijk zijn van meer dan één database, zoals Microsoft Office SharePoint, Microsoft Lync of Sage.
In vergelijking met SQL Server Failover Cluster Instances, stellen we vast dat opslag als single point of failure is geëlimineerd, aangezien aan elke instance die een replica vormt, zijn eigen opslag is toegewezen.
Met AlwaysOn is het mogelijk om HA en DR tegelijk te configureren. Dit wordt bereikt door Multi-Site Windows Failover Clusters te creëren als basis van uw AlwaysOn-configuratie. Het uitvoeren van een rolwisseling bij het gebruik van AlwaysOn is aanzienlijk eenvoudiger dan bij het gebruik van Transactielogboekverzending.
De WSFC-afhankelijkheid
Als u SQL Server AlwaysOn AG gebruikt voor hoge beschikbaarheid en noodherstel, moet u eerst een Windows-failovercluster configureren. AlwaysOn AG's zijn afhankelijk van WFCS om AlwaysOn AG te beheren als een rol die is samengesteld uit clusterbronnen zoals de naam van de beschikbaarheidsgroep, de naam van de bestandsshare, de naam van de luisteraar en een IP-adres.
Afb. 1 AlwaysOn AG als clusterhulpmiddel
Quorum
Quorum is het minimumaantal stemmen dat vereist is voor een meerderheid in een failovercluster. Quorum bepaalt hoeveel node-storingen het cluster kan doorstaan. Via het privénetwerk op poort 3343 communiceren alle clusterknooppunten de gezondheidsstatus en informatie over resourcebewaking. In geval van mislukking, laten de stemmen zien welke nodes de status "Up" hebben en op welke node-bronnen online moeten worden gebracht.
Sinds Windows Server 2012 is het maximum aantal ondersteunde clusterknooppunten zestien. In de meeste omgevingen die ik ken, zijn clusters met twee knooppunten echter gebruikelijk. Een cluster met twee knooppunten vormt een klein probleem bij het bereiken van het quorum, aangezien elk knooppunt één stem heeft en als er een probleem is met de communicatie tussen de twee, kan elk knooppunt ervan uitgaan dat de ander niet in orde is. Dit wordt een split-brain-scenario genoemd. Scenario's met een gesplitst brein zijn de reden voor het configureren van een tiebreaker, zoals een schijf- of bestandsshare.
Als je een oneven aantal nodes hebt, is het niet nodig om een tiebreaker te configureren. Dynamic Quorum Configuration en Dynamic Witness zijn respectievelijk geïntroduceerd in Windows Server 2012 en Windows Server 2012 R2. Met behulp van deze technologieën herverdeelt Windows automatisch de stemmen in een cluster, zodat het aantal nodes in een cluster er niet toe doet bij het vaststellen van een Quorum. De stem van een clusterknooppunt wordt verwijderd door de clustereigenschap "NodeWeight" in te stellen op 0. Deze functies zijn standaard ingeschakeld.
Afb. 2 Alle clustereigenschappen verkrijgen met PowerShell
Afb. 3 toegewezen stemmen in een cluster met twee knooppunten
PowerShell gebruiken
Het PowerShell Command Get-Cluster kan worden gebruikt om de Quorum-configuratie op een Windows-cluster te controleren. Fig. 4 laat zien hoe u alle Cluster-eigenschappen met betrekking tot Quorum op een cluster kunt controleren en Fig. 5 toont de eigenschappen van de File Share Witness. Er zijn veel andere PowerShell-opdrachten om Windows-clusters te controleren en te beheren.
Get-Cluster | Format-List –Property *Quorum*
Afb. 4 PowerShell-opdracht om quorumgerelateerde eigenschappen te controleren
Get-ClusterResource
Get-ClusterResource -Name "File Share Witness" | Get-ClusterParameter
Afb. 5 PowerShell-opdracht om details van eigenschappen van File Share Witness te controleren
Quorum-modi
Windows Server Failover Cluster maakt het configureren van maximaal vier modi mogelijk. Quorummodi zijn in wezen opties die u kiest om te bepalen hoe het cluster knooppuntstoringen zal afhandelen.
1. Knooppunt Meerderheid
Deze Quorum-modus kan storingen van maximaal (n/2)-1 knooppunten aan. Het wordt aanbevolen voor clusters met een oneven aantal knooppunten. In een cluster met vijf knooppunten zou er bijvoorbeeld een storing van twee knooppunten nodig zijn om een clusterstoring te veroorzaken.
2. Knooppunt- en schijfmeerderheid
Kan storingen tot de helft van het aantal clusterknooppunten aan, zolang de schijfgetuige (ook wel de quorumschijf genoemd) online blijft.
3. Knooppunt en bestandsshare meerderheid
Deze Quorum-modus kan storingen tot de helft van het aantal clusterknooppunten aan, zolang de bestandsshare toegankelijk blijft. Vanaf Windows Server 2012 R2 raadt Microsoft aan dat er altijd eenwitness (schijf of bestandsshare) moet worden geconfigureerd bij het bouwen van een cluster.
4. Geen meerderheid
Dit is een modus voor alleen schijf. Deze modus kan storingen van alle knooppunten op één na, zolang de schijf online is. Deze modus wordt niet aanbevolen omdat de schijf een single point of failure wordt.
Tips voor het configureren van de meerderheid van de node en bestandsshare
AlwaysOn-beschikbaarheidsgroepen ondersteunen slechts twee van die Quorum-modi:Node Majority en Node and File Share Majority. Bij het bouwen van een SQL Server AlwaysOn Availability Group-cluster zijn er een paar punten die de DBA in gedachten moet houden:
1. Fysieke servers gebruiken
Bij het configureren van een cluster met twee knooppunten voor AlwaysOn, moeten uw knooppunten zich in verschillende fysieke racks bevinden. De server die uw bestandsshare host, moet in een derde rack staan.
2. Virtuele servers gebruiken
Bij het configureren van een cluster met twee knooppunten voor AlwaysOn, moeten uw virtuele machines zich op afzonderlijke hosts bevinden. De virtuele machine die uw bestandsshare host, moet zich op een derde host bevinden.
3. Multi-site clustering
Bij het configureren van een cluster met meerdere knooppunten voor AlwaysOn in datacenters, moet in een ideaal scenario de bestandsserver die uw bestandsshare host, zich in een derde datacenter bevinden.
4. Machtigingen voor het delen van bestanden
Het clusternaamobject moet machtigingen hebben voor de bestandsshare die als Quorum Witness wordt gebruikt. Zonder dit zou u doorgaans fouten ervaren bij het configureren van de Quorum Witness.
Afb. 6 machtigingen voor het delen van bestanden
5. Online configuratie
Quorum-modi kunnen worden geconfigureerd terwijl het cluster online is. Dus als de fileshare-server uitvalt of opnieuw moet worden geconfigureerd, zorg er dan voor dat u deze snel opnieuw configureert om te garanderen dat er geen onverwachte storingen optreden, vooral op een cluster met twee knooppunten.
Een real-live use-case
Het diagram in Fig. 7 toont een echt Multi-Site AlwaysOn AG-cluster. Het is een cluster met vier knooppunten met twee knooppunten op één site en twee andere op een externe DR-site. De bestandsserver waarop de bestandsshare wordt gehost en die als tie-breaker wordt gebruikt, wordt gehost in een derde datacenter. In het onderhavige geval bevindt de bestandsserver zich in dezelfde stad als het primaire datacentrum, maar als u het zich kunt veroorloven, zou het ideaal zijn om de bestandsserver in een andere stad te hebben. De communicatie tussen de drie partijen moet van goede kwaliteit zijn om valse positieven te voorkomen.
Bij onze eerste implementatie van dit cluster gebruikten we bijvoorbeeld 'Synchrone replicatie met automatische failover' op de Live- en DR-sites. Meer dan eens hebben we een communicatiestoring ervaren die een automatische failover naar de DR-site veroorzaakte en een fout in onze configuratie aan het licht bracht. Hierdoor werd de naam van de luisteraar omgezet naar de bijbehorende IP-adressen op de DR-site en konden clients geen verbinding meer maken omdat de communicatie met dit nieuwe IP-adres niet was toegestaan op de netwerkfirewalls. We zijn eenvoudigweg niet teruggegaan naar de primaire site om het probleem te verhelpen en hebben de configuratie gewijzigd in "Asynchrone replicatie met handmatige failover" voor knooppunten die zich in datacenters bevinden. We zijn van plan om het aspect van de naamresolutie te behandelen in ons volgende "AlwaysOn"-artikel.
Afb. 7 Een real-live use-case
Conclusie
De functieAlwaysOn-beschikbaarheidsgroepen is geïntroduceerd in SQL Server 2012 en is de nieuwste technologie van Microsoft om te voorzien in behoeften op het gebied van zowel hoge beschikbaarheid als noodherstel. Het configureren van AlwaysOn-beschikbaarheidsgroepen is sterk afhankelijk van de Windows Failover Cluster Service. Failoverclusters zijn op hun beurt sterk afhankelijk van de juiste quorumconfiguratie. Bij het bouwen van AlwaysOn op Multi-Site Clusters is de latentie tussen uw knooppunten in de verschillende sites en de bestandsshare die als arbiter wordt gebruikt, echt van belang. Zorg ervoor dat uw quorumconfiguratie altijd in topvorm is om onverwacht gedrag met de Beschikbaarheidsgroepen te voorkomen.
Referenties
Overzicht van AlwaysOn-beschikbaarheidsgroepen
Windows Failover Clustering met SQL Server
PowerShell-documentatie
Inzicht in het Windows Server Failover Cluster Quorum