Opties voor hoge beschikbaarheid en herstel na noodgevallen verkennen
Als u een oplossing voor virtuele machines (VM's) wilt inrichten, moet u eerst de beschikbaarheidsopties voor implementaties op basis van IaaS begrijpen.
Infrastructure-as-a-Service versus Platform-as-a-Service
Als het gaat om beschikbaarheid, maakt de keuze van IaaS of PaaS een verschil. Met IaaS hebt u een virtuele machine, wat betekent dat er een besturingssysteem is met een installatie van SQL Server. De beheerder of groep die verantwoordelijk is voor SQL Server heeft een keuze uit HADR-oplossingen (hoge beschikbaarheid en herstel na noodgevallen) en een groot deel van de controle over hoe die oplossing is geconfigureerd.
Met paaS-implementaties zoals Azure SQL Database zijn de HADR-oplossingen ingebouwd in de functie en moeten ze vaak alleen worden ingeschakeld. Er zijn minimale opties die kunnen worden geconfigureerd.
Vanwege deze verschillen kan de keuze van IaaS of PaaS invloed hebben op het uiteindelijke ontwerp van uw HADR-oplossing.
SQL Server HADR-functies voor virtuele Azure-machine
Wanneer u IaaS gebruikt, kunt u de functies van SQL Server gebruiken om de beschikbaarheid te verhogen. In sommige gevallen kunnen ze worden gecombineerd met functies op Azure-niveau om de beschikbaarheid nog verder te vergroten.
De functies die beschikbaar zijn in SQL Server, worden weergegeven in de onderstaande tabel
| Functienaam | Beschermt |
|---|---|
| AlwaysOn Failover Cluster Instance (FCI) | Exemplaar |
| AlwaysOn-beschikbaarheidsgroep (AG) | Database |
| Back-upfunctie voor logboekbestanden | Database |
Een exemplaar van SQL Server is de volledige installatie van SQL Server (binaire bestanden, alle objecten in het exemplaar, inclusief zaken als aanmeldingen, SQL Server Agent-taken en databases). Beveiliging op exemplaarniveau betekent dat het hele exemplaar wordt verantwoordelijk voor de beschikbaarheidsfunctie.
Een database in SQL Server bevat de gegevens die eindgebruikers en toepassingen gebruiken. Er zijn systeemdatabases waarop SQL Server afhankelijk is, evenals databases die zijn gemaakt voor gebruik door eindgebruikers en toepassingen. Een exemplaar van SQL Server heeft altijd zijn eigen systeemdatabases. Beveiliging op databaseniveau betekent dat alles wat zich in de database bevindt of wordt vastgelegd in het transactielogboek voor een gebruiker of toepassingsdatabase, wordt verwerkt als onderdeel van de beschikbaarheidsfunctie. Alles dat zich buiten de database bevindt of die niet wordt vastgelegd als onderdeel van het transactielogboek, zoals SQL Server Agent-taken en gekoppelde servers, moet handmatig worden afgehandeld om ervoor te zorgen dat de doelserver kan functioneren als de primaire als er een geplande of ongeplande failovergebeurtenis is.
Zowel CCI's als AG's vereisen een onderliggend clustermechanisme. Voor SQL Server-implementaties die worden uitgevoerd op Windows Server, is het een Windows Server-failovercluster (WSFC) en voor Linux is dit Pacemaker.
AlwaysOn-failoverclusterexemplaren
Er wordt een FCI geconfigureerd wanneer SQL Server is geïnstalleerd. Een zelfstandig exemplaar van SQL Server kan niet worden geconverteerd naar een FCI. De FCI krijgt een unieke naam en een IP-adres dat verschilt van de onderliggende servers of knooppunten die deelnemen aan het cluster. De naam en het IP-adres moeten ook afwijken van het onderliggende clustermechanisme. Toepassingen en eindgebruikers gebruiken de unieke naam van de FCI voor toegang. Met deze abstractie hoeven toepassingen niet te weten waar het exemplaar wordt uitgevoerd. Een belangrijk verschil tussen op Azure gebaseerde GBA's versus on-premises FCI's is dat voor Azure een interne load balancer (ILB) vereist is. De ILB wordt gebruikt om ervoor te zorgen dat toepassingen en eindgebruikers verbinding kunnen maken met de unieke naam van de FCI.
Wanneer een FCI een failover naar een ander knooppunt van een cluster uitvoert, of dit nu handmatig wordt gestart of als gevolg van een probleem, wordt het hele exemplaar opnieuw opgestart op een ander knooppunt. Dit betekent dat het failoverproces een volledige stop en het starten van SQL Server is. Toepassingen of eindgebruikers die zijn verbonden met de FCI, worden verbroken tijdens een failover en alleen toepassingen die deze onderbreking kunnen verwerken en herstellen, kunnen automatisch opnieuw verbinding maken.
Bij het opstarten op het andere knooppunt doorloopt het exemplaar het herstelproces. De FCI zal consistent zijn met het storingspunt, dus technisch gezien zullen er geen gegevensverlies zijn, maar alle transacties die moeten worden teruggedraaid, doen dit als onderdeel van herstel. Zoals hierboven vermeld, omdat dit beveiliging op exemplaarniveau is, is alles wat nodig is (aanmeldingen, SQL Server Agent-taken, enzovoort) al aanwezig, zodat het bedrijf gewoon kan doorgaan zodra de databases gereed zijn.
FCI's vereisen één kopie van een database, maar dat is ook het single point of failure. Om ervoor te zorgen dat een ander knooppunt toegang heeft tot de database, hebben CCI's een vorm van gedeelde opslag nodig. Voor Windows Server-architecturen kan dit worden bereikt via een Azure Premium-bestandsshare, iSCSI, Azure Shared Disk, Opslagruimten Direct (S2D) of een ondersteunde oplossing van derden, zoals SIOS DataKeeper. FCI's met de Standard Edition van SQL Server kunnen maximaal twee knooppunten hebben. Voor FCI's is ook het gebruik van Active Directory-domein Services (AD DS) en Domain Name Services (DNS) vereist, zodat AD DS en DNS ergens in Azure moeten worden geïmplementeerd om een FCI te laten werken.
Met Windows Server 2016 of hoger kunnen FCI's opslagreplica gebruiken om een systeemeigen oplossing voor herstel na noodgevallen te maken voor FCI's zonder dat u een andere functie hoeft te gebruiken, zoals logboekverzending of AG's.
AlwaysOn-beschikbaarheidsgroepen
AG's zijn geïntroduceerd in SQL Server 2012 Enterprise Edition en vanaf SQL Server 2016 zijn ook beschikbaar in Standard Edition. In Standard Edition kan een AG één database bevatten, terwijl een AG in Enterprise Edition meer dan één database kan hebben. Hoewel AG's een aantal overeenkomsten met FCI's delen, zijn ze op de meeste manieren anders.
Het grootste verschil tussen een FCI en een AG is dat AG's bescherming op databaseniveau bieden. De primaire replica is het exemplaar dat deelneemt aan een beschikbaarheidsgroep die de lees-/schrijfdatabases bevat. Een secundaire replica is de plaats waar de primaire transacties via het logboektransport verzendt om deze gesynchroniseerd te houden. Gegevensverplaatsing tussen een primaire replica kan synchroon of asynchroon zijn. De databases op een secundaire replica hebben een laadstatus, wat betekent dat ze transacties kunnen ontvangen, maar geen volledig schrijfbare kopie kunnen zijn totdat die replica de primaire replica wordt. Een AG in Standard Edition kan maximaal twee replica's (één primaire, één secundaire) hebben, terwijl Enterprise Edition maximaal negen (één primaire, acht secundaire) ondersteunt. Een secundaire replica wordt geïnitialiseerd vanuit een back-up van de database of vanaf SQL Server 2016 kunt u een functie met de naam 'automatische seeding' gebruiken. Automatische seeding maakt gebruik van het logboekstroomtransport om de back-up naar de secundaire replica te streamen voor elke database van de beschikbaarheidsgroep met behulp van de geconfigureerde eindpunten.
Een AG biedt abstractie met de listener. De listener werkt zoals de unieke naam die is toegewezen aan een FCI en heeft een eigen naam en IP-adres dat verschilt van iets anders (WSFC, knooppunt, enzovoort). De listener vereist ook een ILB en doorloopt een stop en start. Toepassingen en eindgebruikers kunnen de listener gebruiken om verbinding te maken, maar in tegenstelling tot een FCI hoeft de listener, indien gewenst, niet te worden gebruikt. Verbinding maken ies rechtstreeks naar het exemplaar kunnen optreden. Met Enterprise Edition kunnen secundaire replica's in Enterprise Edition desgewenst ook worden geconfigureerd voor alleen-lezentoegang en kunnen ze worden gebruikt voor andere functionaliteit, zoals databaseconsistentiecontroles (DBC's) en back-ups.
AG's kunnen een snellere failovertijd hebben in vergelijking met een FCI, wat een van de redenen is waarom ze aantrekkelijk zijn. Hoewel AG's geen gedeelde opslag nodig hebben, heeft elke replica een kopie van de gegevens, waardoor het totale aantal exemplaren van de database en de totale opslagkosten toeneemt. De opslag is lokaal voor elke replica. Als de gegevensvoetafdruk van de databases op de primaire replica bijvoorbeeld 1 TB is, heeft elke replica ook hetzelfde. Als er vijf replica's zijn, betekent dit dat u 5 TB ruimte nodig hebt.
Houd er rekening mee dat elk object dat zich buiten de database bevindt of die niet is vastgelegd in het transactielogboek van de database, handmatig moet worden gemaakt en moet worden verwerkt op een ander SQL Server-exemplaar als dat exemplaar de nieuwe primaire replica moet worden. Voorbeelden van objecten waarvoor u verantwoordelijk bent, zijn onder andere SQL Server Agent-taken, aanmeldingen op exemplaarniveau en gekoppelde servers. Als u Windows-verificatie kunt gebruiken of ingesloten databases met AG's kunt gebruiken, wordt de toegang vereenvoudigd.
Veel organisaties kunnen uitdagingen ondervinden bij het implementeren van maximaal beschikbare architecturen en hebben mogelijk alleen de hoge beschikbaarheid van het Azure-platform nodig of het gebruik van een PaaS-oplossing zoals Azure SQL Managed Instance. Voordat we naar Azure-platformoplossingen kijken, is er een andere SQL Server-functie die u moet weten over: verzending van logboeken.
Back-upfunctie voor logboekbestanden
Logboekverzending bestaat al sinds de vroege dagen van SQL Server. De functie is gebaseerd op back-up, kopiëren en herstellen en is een van de eenvoudigste methoden voor het bereiken van HADR voor SQL Server. Logboekverzending wordt voornamelijk gebruikt voor herstel na noodgevallen, maar kan ook worden gebruikt om de lokale beschikbaarheid te verbeteren.
Logboekverzending, zoals AG's, biedt beveiliging op databaseniveau, wat betekent dat u nog steeds rekening moet houden met SQL Server Agent-taken, gekoppelde servers, aanmeldingen op exemplaarniveau, enzovoort. Er is geen abstractie die systeemeigen wordt geleverd door logboekverzending, dus een switch naar een andere server die deelneemt aan logboekverzending, moet een naamwijziging kunnen tolereren. Als dat niet mogelijk is, zijn er methoden zoals een DNS-alias, die kunnen worden geconfigureerd op de netwerklaag om de problemen met naamwijziging te verhelpen.
Het mechanisme voor logboekverzending is eenvoudig: maak eerst een volledige back-up van de brondatabase op de primaire server, herstel deze in een laadstatus (STAND-BY of NORECOVERY) op een ander exemplaar dat bekend staat als een secundaire server of warme stand-by. Deze nieuwe kopie van de database wordt een secundaire database genoemd. Een geautomatiseerd proces dat is ingebouwd in SQL Server, zal vervolgens automatisch een back-up maken van het transactielogboek van de primaire database, de back-up naar de stand-byserver kopiëren en ten slotte de back-up herstellen naar de stand-by.
De SQL Server HADR-functies zijn niet de enige opties om de beschikbaarheid van IaaS te verbeteren. Er zijn enkele functies in Azure die ook moeten worden overwogen.