Delen via

Hoge beschikbaarheid voor Azure SQL Managed Instance

  • Artikel

Van toepassing op: Azure SQL Managed Instance

In dit artikel wordt hoge beschikbaarheid in Azure SQL Managed Instance beschreven.

Belangrijk

Zone-redundante configuratie is in openbare preview voor de servicelaag Algemeen gebruik en algemeen beschikbaar voor de servicelaag Bedrijfskritiek.

Overzicht

Het doel van de architectuur met hoge beschikbaarheid in Azure SQL Managed Instance is het minimaliseren van de impact op klantworkloads van door de klant geïnitieerde beheerbewerkingen die resulteren in een korte downtime, serviceonderhoudsbewerkingen en ongeplande storingen. Raadpleeg Azure SQL Managed Instance voor meer informatie over specifieke SLA's voor verschillende servicelagen. Hoge beschikbaarheid is het concept dat u beschermt tegen impact die is gericht op de

  • beschikbaarheidszone die het datacenter vormt (in het geval van regio met meerdere zones),
  • rack waarin knooppunten die uw service aandrijven, worden uitgevoerd,
  • knooppunt zelf,
  • toepassingslaag.

Om de impact in het geval van regionale of grotere storingen te minimaliseren, kunt u een van de beschikbare technieken gebruiken die worden behandeld in ons overzicht van bedrijfscontinuïteit.

SQL Managed Instance wordt uitgevoerd op de nieuwste stabiele versie van de SQL Server Database Engine op het Windows-besturingssysteem met alle toepasselijke patches. SQL Managed Instance verwerkt automatisch kritieke onderhoudstaken, zoals patching, back-ups, Windows- en SQL-engine-upgrades en niet-geplande gebeurtenissen, zoals onderliggende hardware, software of netwerkfouten. Wanneer een exemplaar wordt gepatcht of een failover-overschakeling uitvoert, is de downtime niet van invloed als u logica voor opnieuw proberen in uw app gebruikt. SQL Managed Instance kan snel worden hersteld, zelfs in de meest kritieke omstandigheden, zodat uw gegevens altijd beschikbaar zijn. De meeste gebruikers merken niet dat upgrades continu worden uitgevoerd.

De oplossing voor hoge beschikbaarheid is ontworpen om ervoor te zorgen dat vastgelegde gegevens nooit verloren gaan als gevolg van storingen, dat onderhoudsbewerkingen geen invloed hebben op uw workload en dat het exemplaar geen single point of failure is in uw softwarearchitectuur.

Er zijn twee verschillende architectuurmodellen voor hoge beschikbaarheid op basis van de servicelaag:

  • Het externe opslagmodel is gebaseerd op een scheiding van rekenkracht en opslag in de servicelaag Algemeen gebruik die afhankelijk is van de hoge beschikbaarheid en betrouwbaarheid van de externe opslag en de hoge beschikbaarheid van rekenclusters die worden beheerd door Azure Service Fabric. Dit model voor hoge beschikbaarheid is gericht op budgetgerichte zakelijke toepassingen die prestatievermindering kunnen verdragen tijdens onderhoudsactiviteiten.
  • Het lokale opslagmodel is gebaseerd op een cluster van database-engineprocessen die afhankelijk zijn van een quorum van beschikbare database-engineknooppunten in de servicelaag Bedrijfskritiek die lokale opslag hebben. Dit lokale opslagmodel is gericht op bedrijfskritieke toepassingen die een hoge transactiesnelheid hebben en hoge I/O-prestaties vereisen. De architectuur met hoge beschikbaarheid garandeert minimale prestatie-impact op uw workload tijdens onderhoudsactiviteiten.

Lokaal redundante beschikbaarheid

Lokaal redundante beschikbaarheid is gebaseerd op het opslaan van uw rekenknooppunten en gegevens in één datacenter in de primaire regio en beveiligt uw gegevens in het geval van lokale storingen, zoals een klein netwerk of stroomstoring. Als een grootschalige ramp, zoals brand of overstromingen, zich in een regio voordoet, kunnen alle replica's van een opslagaccount of gegevens op de rekenknooppunten verloren gaan of onherstelbaar zijn. Als zodanig kunt u uw gegevens verder beveiligen wanneer u de optie voor lokaal redundante beschikbaarheid gebruikt, overwegen om een tolerantere opslagoptie te gebruiken voor uw databaseback-ups.

Servicelaag voor Algemeen gebruik

De servicelaag Algemeen gebruik maakt gebruik van de architectuur voor beschikbaarheid van externe opslag. In de volgende afbeelding ziet u vier verschillende knooppunten met de gescheiden lagen voor berekening en opslag.

Diagram showing separation of compute and storage.

Het beschikbaarheidsmodel voor externe opslag bevat twee lagen:

  • Een staatloze rekenlaag die het database-engineproces uitvoert en alleen tijdelijke en in de cache opgeslagen gegevens bevat, zoals de tempdb en model databases op de gekoppelde SSD, en plan cache, buffergroep en columnstore-pool in het geheugen. Dit staatloze knooppunt wordt beheerd door Azure Service Fabric waarmee de database-engine wordt geïnitialiseerd, de status van het knooppunt wordt beheerd en indien nodig een failover naar een ander knooppunt wordt uitgevoerd.
  • Een stateful gegevenslaag met de databasebestanden (.mdf en .ldf) die zijn opgeslagen in Azure Blob Storage. Azure Blob Storage heeft ingebouwde functies voor gegevensbeschikbaarheid en redundantie. Lokaal redundante beschikbaarheid is gebaseerd op het opslaan van uw gegevens op lokaal redundante opslag (LRS), waarmee uw gegevens drie keer worden gekopieerd binnen één datacenter in de primaire regio. Het garandeert dat elke record in het logboekbestand of de pagina in het gegevensbestand behouden blijft, zelfs als het proces van de database-engine vastloopt.

Wanneer de database-engine of het besturingssysteem wordt bijgewerkt of er een fout wordt gedetecteerd, verplaatst Azure Service Fabric het stateless database-engineproces naar een ander staatloos rekenknooppunt met voldoende vrije capaciteit. Gegevens in Azure Blob Storage worden niet beïnvloed door de verplaatsing en de gegevens/logboekbestanden worden gekoppeld aan het zojuist geïnitialiseerde database-engineproces. Dit proces garandeert hoge beschikbaarheid, maar een zware workload kan tijdens de overgang enige prestatievermindering ervaren omdat het nieuwe database-engineproces begint met koude cache.

Servicelaag Bedrijfskritiek

De servicelaag Bedrijfskritiek maakt gebruik van het lokale opslagbeschikbaarheidsmodel, dat rekenresources (database-engineproces) en opslag (lokaal gekoppelde SSD) op één knooppunt integreert. Hoge beschikbaarheid wordt bereikt door zowel rekenkracht als opslag te repliceren naar extra knooppunten.

Diagram of a cluster of database engine nodes.

De onderliggende databasebestanden (.mdf/.ldf) worden op gekoppelde SSD-opslag geplaatst om io met een zeer lage latentie voor uw workload te bieden. Hoge beschikbaarheid wordt geïmplementeerd met behulp van een technologie die vergelijkbaar is met SQL Server AlwaysOn-beschikbaarheidsgroepen. Het cluster bevat één primaire replica die toegankelijk is voor workloads van lezen/schrijven van klanten en maximaal drie secundaire replica's (compute en opslag) die kopieën van gegevens bevatten. De primaire replica pusht voortdurend wijzigingen in de secundaire replica's sequentieel om ervoor te zorgen dat gegevens op een voldoende aantal secundaire replica's worden bewaard voordat elke transactie wordt doorgevoerd. Dit proces garandeert dat, als de primaire replica of een leesbare secundaire replica om welke reden dan ook niet beschikbaar is, een volledig gesynchroniseerde replica altijd beschikbaar is om een failover naar uit te voeren. Failover wordt gestart door Azure Service Fabric. Zodra een secundaire replica de nieuwe primaire replica wordt, wordt er een andere secundaire replica gemaakt om ervoor te zorgen dat het cluster voldoende replica's heeft om quorum te behouden. Zodra de failover is voltooid, worden Azure SQL-verbindingen automatisch omgeleid naar de nieuwe primaire replica (of leesbare secundaire replica op basis van de verbindingsreeks).

Als extra voordeel biedt het lokale opslagbeschikbaarheidsmodel de mogelijkheid om alleen-lezen Azure SQL-verbindingen om te leiden naar een van de secundaire replica's. Deze functie heet Uitschalen voor lezen. Het biedt 100% extra rekencapaciteit zonder extra kosten voor off-load alleen-lezen bewerkingen, zoals analytische workloads, van de primaire replica.

Zone-redundante beschikbaarheid

Zone-redundante beschikbaarheid is gebaseerd op het plaatsen van rekenknooppunten en opslagreplica's in drie Azure-beschikbaarheidszones in de primaire regio. Elke beschikbaarheidszone is een afzonderlijke fysieke locatie met onafhankelijke voeding, koeling en netwerken.

Standaard wordt het cluster met knooppunten voor het lokale opslag beschikbaarheidsmodel gemaakt in hetzelfde datacenter. Met de introductie van Azure Beschikbaarheidszones kan SQL Managed Instance verschillende replica's van een Bedrijfskritiek-exemplaar in verschillende beschikbaarheidszones in dezelfde regio plaatsen. Op dezelfde manier worden de stateless rekenknooppunten van een servicelaag algemeen gebruik in een andere beschikbaarheidszone geplaatst, terwijl stateful opslag gebruikmaakt van ZRS-configuratie (zone-redundante opslag).

Als u een single point of failure wilt voorkomen, wordt de besturingsring ook gedupliceerd in meerdere zones als drie gateway-ringen (GW). De routering naar een specifieke gatewayring wordt beheerd door Azure Traffic Manager (ATM). Door een zone-redundante configuratie te selecteren, kunt u ervoor zorgen dat uw Bedrijfskritiek- of algemeen gebruik-exemplaren bestand zijn tegen een veel grotere set fouten, waaronder catastrofale storingen in datacentrums, zonder dat er wijzigingen in de toepassingslogica zijn. U kunt ook bestaande exemplaren van Bedrijfskritiek of Algemeen gebruik converteren naar zone-redundante configuratie.

Omdat zone-redundante exemplaren replica's hebben in verschillende datacenters met enige afstand ertussen, kan de verhoogde netwerklatentie de doorvoertijd van de transactie verhogen en dus van invloed zijn op de prestaties van sommige OLTP-workloads. U kunt altijd terugkeren naar de configuratie met één zone door de instelling zoneredundantie uit te schakelen. Dit proces is een onlinebewerking die vergelijkbaar is met de reguliere servicelaagdoelstellingupgrade. Aan het einde van het proces wordt het exemplaar gemigreerd van een zoneredundante ring naar een ring met één zone of omgekeerd.

De zone-redundante versie van de architectuur voor hoge beschikbaarheid wordt geïllustreerd door het volgende diagram:

Diagram of the zone-redundant high availability architecture.

Houd rekening met het volgende bij het gebruik van zoneredundantie:

Ondersteunde regio's voor Bedrijfskritiek exemplaren

Zoneredundantie voor Bedrijfskritiek SQL Managed Instance wordt ondersteund in de volgende regio's:

Noord- en Zuid-Amerika Europa Midden-Oosten Afrika Azië en Stille Oceaan
Brazilië - zuid Frankrijk - centraal Qatar - centraal Zuid-Afrika - noord Australië - oost
Canada - midden Italië - noord Israël - centraal India - centraal
Central US Duitsland - west-centraal Japan - oost
VS - oost Noorwegen - oost Korea - centraal
VS - oost 2 Europa - noord Azië - zuidoost
VS - zuid-centraal VK - zuid Azië - oost
VS - west 2 Zweden - centraal
US - west 3 Zwitserland - noord
Polen - centraal

Ondersteunde regio's voor exemplaren voor algemeen gebruik

Notitie

Zone-redundante configuratie is in openbare preview voor de servicelaag Algemeen gebruik.

Noord- en Zuid-Amerika Europa Midden-Oosten Afrika Azië en Stille Oceaan
Brazilië - zuid Frankrijk - centraal Qatar - centraal Zuid-Afrika - noord Australië - oost
VS - oost Italië - noord Israël - centraal India - centraal
VS - oost 2 Duitsland - west-centraal Japan - oost
VS - zuid-centraal Noorwegen - oost Korea - centraal
VS - west 2 Europa - noord Azië - zuidoost
US - west 3 VK - zuid Azië - oost
Zweden - centraal
Zwitserland - noord
Polen - centraal

Fouttolerantie van toepassing testen

Hoge beschikbaarheid is een fundamenteel onderdeel van het SQL Managed Instance-platform dat transparant werkt voor uw databasetoepassing. We erkennen echter dat u mogelijk wilt testen hoe de automatische failoverbewerkingen die zijn gestart tijdens geplande of ongeplande gebeurtenissen van invloed zijn op een toepassing voordat u deze implementeert in productie. U kunt een failover handmatig activeren door een speciale API aan te roepen om een beheerd exemplaar opnieuw te starten. In het geval van een zone-redundant exemplaar zou de API-aanroep ertoe leiden dat clientverbindingen naar de nieuwe primaire in een beschikbaarheidszone anders worden omgeleid dan de beschikbaarheidszone van de oude primaire. Naast het testen van hoe failover van invloed is op bestaande databasesessies, kunt u ook controleren of de end-to-end-prestaties worden gewijzigd vanwege wijzigingen in de netwerklatentie. Omdat de herstartbewerking intrusief is en een groot aantal ervan het platform kan belasten, wordt er elke 15 minuten slechts één failover-aanroep toegestaan voor elk beheerd exemplaar.

Een failover kan worden gestart met behulp van PowerShell, REST API of Azure CLI:

PowerShell REST-API Azure CLI
Invoke-AzSqlInstanceFailover SQL Managed Instance - Failover az sql mi failover kan worden gebruikt om een REST API-aanroep vanuit Azure CLI aan te roepen

Conclusie

Azure SQL Managed Instance biedt een ingebouwde oplossing voor hoge beschikbaarheid die diep is geïntegreerd met het Azure-platform. De service is afhankelijk van Service Fabric om fouten te detecteren en te herstellen, Azure Blob Storage om gegevens te beveiligen en op Beschikbaarheidszones voor een hogere fouttolerantie. En voor de servicelaag Bedrijfskritiek maakt SQL Managed Instance gebruik van sql Server AlwaysOn-beschikbaarheidsgroeptechnologie voor databasereplicatie en failover. Dankzij de combinatie van deze technologieën kunnen toepassingen de voordelen van een gemengd opslagmodel volledig realiseren en de meest veeleisende SLA's ondersteunen.

Volgende stappen