Delen via

Beschikbaarheid via lokale en zoneredundantie - Azure SQL Managed Instance

  • Artikel

van toepassing op:Azure SQL Managed Instance

In dit artikel wordt de architectuur van Azure SQL Managed Instance beschreven die beschikbaarheid bereikt via lokale redundantie en hoge beschikbaarheid via zoneredundantie.

Belangrijk

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

Overzicht

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-database-engineupgrades en niet-geplande gebeurtenissen, zoals onderliggende hardware, software of netwerkfouten. Wanneer een exemplaar wordt gepatcht of een failover uitvoert, is de downtime niet storend als u opnieuw probeerlogica in uw app opneemt. 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.

Azure SQL Managed Instance bereikt standaard beschikbaarheid via lokale redundantie, waardoor uw exemplaar beschikbaar is tijdens:

  • Door de klant geïnitieerde beheerbewerkingen die tot een korte downtime leiden
  • Serviceonderhoudsbewerkingen
  • Problemen en storingen bij het datacenter met de:
    • Rack waar de machines die uw dienst aandrijven draaien.
    • Fysieke machine die als host fungeert voor de VIRTUELE machine waarop de SQL-database-engine wordt uitgevoerd.
    • Virtuele machine waarop de SQL-database-engine wordt uitgevoerd
  • Andere problemen met de SQL-database-engine
  • Andere potentiële niet-geplande lokale storingen

De standaardbeschikbaarheidsoplossing 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.

Als u echter de impact op uw gegevens wilt minimaliseren in het geval van een storing in een hele zone, kunt u hoge beschikbaarheid bereiken door zoneredundantie in te schakelen. Zonder zoneredundantie worden failovers lokaal uitgevoerd binnen hetzelfde datacenter, wat ertoe kan leiden dat uw exemplaar niet beschikbaar is totdat de storing is opgelost. De enige manier om te herstellen is via een oplossing voor herstel na noodgevallen, zoals via een failovergroep, of een geo-herstel van een geografisch redundante back-up. Raadpleeg het overzicht van bedrijfscontinuïteitvoor meer informatie.

Hoge beschikbaarheid verhoogt de betrouwbaarheid van uw service door u te beschermen tegen de volgende gevolgen:

  • Beschikbaarheidszone die het datacenter vormt

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

  • Het externe opslagmodel is gebaseerd op een scheiding van reken- en opslag in de Algemeen gebruik en Next-gen Algemeen gebruik servicelagen die afhankelijk zijn van de beschikbaarheid en betrouwbaarheid van de externe opslag en de beschikbaarheid van rekenclusters die worden beheerd door Azure Service Fabric-. Dit beschikbaarheidsmodel is gericht op budgetgerichte zakelijke toepassingen die prestatievermindering kunnen verdragen tijdens onderhoudsactiviteiten.
  • Het lokaal opslagmodel is gebaseerd op een cluster van database-engineprocessen die afhankelijk zijn van een quorum van beschikbare database-engineknooppunten in de bedrijfskritieke servicelaag 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.

Raadpleeg SLA voor Azure SQL Managed Instancevoor meer informatie over specifieke SLA's voor verschillende servicelagen.

Beschikbaarheid via lokale redundantie

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 lokaal redundante beschikbaarheidsoptie gebruikt, kunt u overwegen om een tolerantere opslagoptie te gebruiken voor uw databaseback-ups.

Algemeen gebruik servicelaag

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 reken- en opslaglagen.

diagram met scheiding van rekenkracht en opslag.

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 waarbij de databasebestanden (.mdf en .ldf) 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.

Volgende generatie algemene servicelaag

Notitie

De upgrade van de servicelaag Voor algemeen gebruik van de volgende generatie is momenteel beschikbaar als preview-versie.

Next-gen Algemeen gebruik is een architectuurupgrade naar de bestaande servicelaag Algemeen gebruik die gebruikmaakt van een bijgewerkte externe opslaglaag waarin exemplaargegevens en logboekbestanden op beheerde schijven worden opgeslagen in plaats van pagina-blobs en lokaal worden onderhouden.

Bedrijfskritieke servicelaag

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 van een cluster met database-engineknooppunten.

De onderliggende databasebestanden (.mdf/.ldf) worden op gekoppelde SSD-opslag geplaatst om zeer lage latentie IO 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 een extra voordeel biedt het model voor lokale opslag-beschikbaarheid de mogelijkheid om read-only Azure SQL-verbindingen om te leiden naar een van de secundaire replica's. Deze functie wordt uitschalenlezen genoemd. Het biedt 100% extra rekencapaciteit zonder extra kosten voor off-load alleen-lezen bewerkingen, zoals analytische workloads, van de primaire replica.

Hoge beschikbaarheid via zoneredundantie

Zone-redundante beschikbaarheid is gebaseerd op het plaatsen van replica'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-beschikbaarheidszonesplaatst SQL Managed Instance verschillende replica's in verschillende beschikbaarheidszones in dezelfde regio. Om een single point of failure te elimineren, wordt de besturingsring ook in meerdere zones gedupliceerd. Het besturingsvlakverkeer wordt vervolgens doorgestuurd naar een load balancer die ook wordt geïmplementeerd in beschikbaarheidszones. Verkeersroutering van het besturingsvlak naar de load balancer wordt beheerd door Azure Traffic Manager -.

Met behulp van een zone-redundante configuratie kunt u ervoor zorgen dat uw bedrijfskritieke of algemene instanties bestand zijn tegen een veel grotere set fouten, waaronder catastrofale datacenterstoringen, zonder wijzigingen in de toepassingslogica. U kunt bestaande bedrijfskritieke of algemene instanties converteren naar de 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.

Raadpleeg Zoneredundantie configurerenom te beginnen met zoneredundantie voor uw SQL-beheerde exemplaar.

Algemeen Doel servicelaag

In de algemene gebruiksservicelaag wordt zoneredundantie bereikt door staatloze rekenknooppunten in verschillende beschikbaarheidszones te plaatsen en vervolgens gebruik te maken van een stateful zoneredundante opslag (ZRS) die is gekoppeld aan het knooppunt dat momenteel het actieve SQL Database Engine-proces bevat. In het geval van een storing wordt het SQL Database Engine-proces actief op een van de stateloze knooppunten, en krijgt vervolgens toegang tot de gegevens in de toestandsgebonden opslag.

In het volgende diagram ziet u de architectuur voor zoneredundantie voor de servicelaag Algemeen gebruik:

diagram van de architectuur voor zoneredundantie in de servicelaag Algemeen gebruik.

Notitie

Zoneredundantie is momenteel beschikbaar als preview-versie voor de servicelaag Algemeen gebruik.

Bedrijfskritieke servicelaag

In de servicelaag Bedrijfskritiek wordt zoneredundantie bereikt door reken- en opslagreplica's in verschillende beschikbaarheidszones te plaatsen en vervolgens onderliggende AlwaysOn-beschikbaarheidsgroeptechnologie te gebruiken om gegevenswijzigingen van het primaire exemplaar te repliceren naar stand-byreplica's in andere beschikbaarheidszones. In het geval van een storing is er een automatische failover waarmee een van de stand-byreplica's naadloos primair wordt.

In het volgende diagram ziet u de zoneredundantiearchitectuur voor de servicelaag Bedrijfskritiek:

diagram van de zoneredundantiearchitectuur in de servicelaag Bedrijfskritiek.

Fouttolerantie van toepassing testen

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 op te starten. 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.

Tijdens een echte failover mislukken verbindingen met het exemplaar terwijl de SQL-service primair wordt op een ander knooppunt. Als u een failover wilt simuleren, roept u de opdracht aan waarmee het SQL-proces opnieuw wordt gestart om de service te simuleren alsof er een failover is. Verbindingen kunnen echter gedurende een langere periode mislukken tijdens een echte failover in vergelijking met een gesimuleerde failover, omdat tijdens een echte failover het SQL-proces de primaire wordt op een andere virtuele machine binnen het cluster (lokaal of in een andere zone als zoneredundantie is ingeschakeld) en tijdens een gesimuleerde failover wordt het SQL-proces opnieuw gestart op de bestaande virtuele machine.

De handmatige failoveropdracht in deze sectie gedraagt zich doorgaans op dezelfde manier in zowel lokaal redundante als zone-redundante configuraties. Het SQL-proces wordt alleen lokaal opnieuw gestart en er wordt geen failover naar een ander knooppunt gestart, hoewel enkele uitzonderingen van toepassing zijn op. Deze lokale failover wijkt af van een failover die plaatsvindt voor een failovergroep.

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

PowerShell REST API Azure CLI
Invoke-AzSqlInstanceFailover nl-NL: 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-opslag om gegevens te beveiligen en op beschikbaarheidszones voor een hogere fouttolerantie. En voor de bedrijfskritieke servicelaag 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