Wanneer servers niet beschikbaar zijn, kan dit leiden tot onderbrekingen van uw bedrijfsdoelstellingen en tot inkomstenderving. Een luchtvaartmaatschappij kan bijvoorbeeld geen vluchten voor klanten boeken als instanties en databases niet beschikbaar zijn. Systemen kunnen om verschillende redenen falen, zoals brand, menselijke fouten, computerstoringen, schijfstoringen en programmeerfouten.
Om verstoringen te voorkomen en ervoor te zorgen dat er continuïteit is in de zakelijke dienstverlening, is het uiterst belangrijk om te beschikken over strategieën voor hoge beschikbaarheid (HA) en noodherstel (DR). HA en DR worden vaak samen besproken. HA houdt zich bezig met het zoveel mogelijk beperken van de downtime van de server, maar omdat geen enkel systeem perfect is, richt DR zich op het proces waarbij de back-upmedia worden gebruikt om verloren gegevens te herstellen in het geval dat het databasesysteem uitvalt.
AlwaysOn is een merk-/marketingterm die sinds SQL Server 2012 wordt gebruikt om de verbeterde HADR-functies van Microsoft te beschrijven. Vóór AlwaysOn ondersteunde de database-engine andere, ingebouwde eigen oplossingen, zoals database-mirroring, failover-cluster en verzending van logbestanden. Elk van deze technieken had echter voordelen en beperkingen. Vaak moest een organisatie, afhankelijk van haar doelen, meerdere methoden combineren om tot een gewenste HADR-strategie te komen.
AlwaysOn-functies zijn geïntroduceerd, zodat u geen extra tijd en middelen hoeft te gebruiken om complexiteit in de implementatie te implementeren en te introduceren om rekening te houden met zowel server- als databaseredundantie, problemen ondervindt met schalen of stand-by-hardware hebt die niet efficiënt wordt gebruikt. Deze functies combineren handig veel van de oude praktijken met elkaar en verbeteren gebieden waar ze tekortschoten. Om de waarde van AlwaysOn-aanbiedingen echt te begrijpen, is het belangrijk om de oorspronkelijke basisconcepten van hoe de database-engine in het verleden voor systeem-HADR zorgde, opnieuw te bekijken.
Database spiegelen
Databaseredundantie kan worden bereikt door middel van spiegeling. U kunt bijvoorbeeld een inkomstengenererende front-end client-app hebben waarmee studenten online studieboeken kunnen bestellen. Een klant selecteert zijn aankoop en verzoeken worden gedaan aan de hand van de PsychologyBooks-database aan de achterkant. In het geval van een calamiteit waardoor de database van PsychologyBooks niet beschikbaar is, kan de student zijn bestelling niet voltooien.
Om deze verstoring te voorkomen, kunt u een principal instance in productie laten implementeren die de PsychologyBooks-database bevat en een extra exemplaar van die PsychologyBooks-database op een gespiegelde server stand-by hebben. Client-apps kunnen opnieuw verbinding maken met de gespiegelde kopie in plaats van onderbrekingen te ervaren en te moeten wachten tot het herstel is voltooid op de primaire. De kopie houdt gelijke tred met de wijzigingen die op het origineel zijn aangebracht door transactielogboeken te ontvangen en vervolgens die geregistreerde wijzigingen opnieuw uit te voeren.
Mirroring-sessies kunnen in verschillende modi werken, afhankelijk van de prestaties of hoge veiligheidsredenen. Handig is dat automatische failover wordt ondersteund wanneer de mirroring-sessie wordt uitgevoerd in een zeer veilige synchrone modus en quorumconsensus wordt bereikt met de aanwezigheid van een optionele getuigenserver.
Ondanks de voordelen van mirroring schiet het tekort omdat het alleen databaseredundantie biedt, geen serverredundantie. Dat betekent dat als de primaire serverinstantie uitvalt, beide instanties uitvallen en dat het niet uitmaakt dat er een reservekopie van de gegevens op databaseniveau is. De stand-by ondersteunt geen gebruikersbewerkingen en er zijn momentopnamen nodig om een alleen-lezen kopie van de gegevens op de gespiegelde instantie te krijgen. De database is beveiligd, maar de objecten op serverniveau, zoals lidmaatschap van de serverrol, aanmeldingsgegevens en agenttaken, zijn dat niet.
Als er bijvoorbeeld een groot marketingteam was en elk lid zijn eigen login had, zouden ze het proces van het opnieuw aanmaken van logins voor elke persoon opnieuw moeten doorlopen. Wanneer failover optreedt, is dit op een onafhankelijke databasebasis en niet als een groep.
Failover-clustering
Failoverclustering biedt redundantie op instantieniveau en biedt bescherming tegen hardware- en besturingssysteemstoringen. Stel bijvoorbeeld dat een knooppunt in Queen Anne in brand vliegt en een apparatuurstoring veroorzaakt. De hele instantie, inclusief objecten op instantieniveau, zoals aanmeldingen of specifieke taken die zijn gemaakt om specifieke taken uit te voeren, wordt beschermd en kan automatisch opnieuw worden gestart op een ander knooppunt dat bij het cluster hoort. Client-apps en -services blijven beschikbaar voor klanten.
Het bovenstaande scenario werkt omdat opslag wordt gedeeld tussen redundante fysieke servers in een Windows Server Failover Cluster-groep (WSFC). Zowel het besturingssysteem als de SQL Server werken samen, zodat slechts één knoop punt tegelijk eigenaar is van de WSFC-resourcegroep.
Helaas biedt deze oplossing met een gemeenschappelijke opslag niet de databaseredundantie die de eerdere spiegelstrategie bood. Het hebben van een gedeelde opslag brengt risico's met zich mee omdat het resulteert in een single point of failure. De externe schijven kunnen bijvoorbeeld het enige exemplaar van de belangrijke PsychologyBooks-database bevatten en ondanks dat de instance met succes is overgezet naar de Ballard-node, zou er nog steeds een onderbreking zijn in de zakelijke doelen als de enige opslagcomponent zou worden gecompromitteerd. Failoverclustering stelt ook beperkingen in termen van schaalbaarheid voor, omdat client-apps niet in staat zijn om een groeiende hoeveelheid werk aan te kunnen dat verder reikt dan het cluster.
Log verzending
Een andere methode om databaseredundantie te bereiken, is door het verzenden van logbestanden. Van transactielogboeken wordt een back-up gemaakt op de primaire server en naar een of meerdere secundaire servers gestuurd om te worden hersteld. In tegenstelling tot mirroring kunnen de secundaire database(s) in aanmerking komen voor alleen-lezen-activiteit en kan de verzendfrequentie van het log worden geconfigureerd voor verschillende intervallen. Er is een prestatievoordeel in scenario's waarin secundaire databases niet noodzakelijk in realtime synchroon hoeven te lopen met de primaire database.
Als u bijvoorbeeld aan het eind van de nacht een statistisch overzichtsrapport maakt om te zien welke psychologieboeken er gedurende de dag worden verkocht, hoeft de kopie-database niet exact synchroon te lopen met de primaire database. Leesintensieve activiteit plaatst vergrendelingen op database-objecten en kan wachttijden opdrijven. Daarom zou het uitvoeren van rapportage op een secundaire server de werkbelasting op de primaire inkomstengenererende server verlichten.
Het nadeel is dat logboekverzending geen automatische failover ondersteunt. Als de bronserver uitvalt, moet de database daarom handmatig worden hersteld. Net als mirroring biedt logverzending geen serverredundantie en is het een oplossing op databaseniveau.
AlwaysOn begrijpen
Oude technologieën hebben elk hun voordelen en nadelen. Maar het implementeren van een op maat gemaakte HADR-oplossing kan snel ingewikkeld worden en meer beheer vereisen, aangezien deze verschillende strategieën willekeurig worden gemengd en op elkaar afgestemd om aan de zakelijke behoeften te voldoen. Daarom zijn de AlwaysOn-functies geïntroduceerd en bieden ze een verbeterde, al gecombineerde versie van eerdere strategieën.
SQL Server biedt twee functies:AlwaysOn Availability Groups (AG) en AlwaysOn Failover Cluster Instances (FCI). Voor beide is implementatie van Windows Server Failover Clustering (WSFC) vereist.
Een AG is een groep databases die samen een failover zullen uitvoeren. U hebt meerdere redundante fysieke knooppunten nodig met een SQL Server-instantie die op elk van de knooppunten is geïnstalleerd om de beschikbaarheidsreplica's te hosten. Elke replica moet zich op een ander knooppunt van dezelfde WSFC bevinden. In het bovenstaande schema wordt de primaire replica gehost op knooppunt 01 en komen alle andere secundaire replica's in aanmerking voor failover wanneer WSFC detecteert dat er een probleem is.
De manier waarop de secundaire replica's synchroon blijven met de primaire, is door transactielogboeken te verzenden en de wijzigingen opnieuw uit te voeren. AG ondersteunt zowel asynchrone als synchrone commit-modus. De primaire replica komt in aanmerking voor lezen en schrijven, terwijl de secundaire replica's in aanmerking komen voor alleen-lezen. Back-ups kunnen worden uitgevoerd op de secundaire locatie.
Er zijn onmiddellijk voordelen met AlwaysOn AG. Bedenk van eerder dat enkele van de tekortkomingen van database-mirroring zijn dat een database slechts naar één secundaire server kan worden gespiegeld en dat wanneer een failover optreedt, elke database onafhankelijk wordt gespiegeld. Met AG worden databases op veel plaatsen redundant gemaakt, zoals Node 02, Node 03, Node 04 en Node 05 in het bovenstaande voorbeeld. Ondersteuning voor databasebeschikbaarheid maakt maximaal negen beschikbaarheidsreplica's mogelijk.
Bovendien zou log verzending nodig zijn om alleen-lezen gegevens op de secundaire server te verkrijgen. Maar met AG wordt al rekening gehouden met alleen-lezen gegevens. Leesintensieve activiteiten zoals rapportage kunnen worden uitgevoerd op een van de secundaire replica's. Houd er ook rekening mee dat er geen beperking voor gedeelde opslag is.
AG kan echter worden gecombineerd met AlwaysOn FCI om serverredundantie mogelijk te maken. Een FCI-instantie kan worden gebruikt om de beschikbaarheidsreplica's te hosten, zodat objecten op serverniveau, zoals aanmeldingen en agenttaken, ook kunnen worden beschermd. Voor deze aanpak is gedeelde opslag vereist. Ongemakken zoals het moeten uitvoeren van herconfiguraties voor de client-apps worden echter geëlimineerd.