Bedrijfskritiek-laag - Azure SQL Database en Azure SQL Managed Instance

VAN TOEPASSING OP: Azure SQL Database Azure SQL Managed Instance

Notitie

Bedrijfskritiek laag wordt Premium genoemd in het DTU-aankoopmodel. Zie aankoopmodellen en resources voor een vergelijking van het aankoopmodel op basis van vCore met het aankoopmodel op basis van DTU Azure SQL Database aankoopmodellen en -resources.

Azure SQL Database en Azure SQL Managed Instance zijn beide gebaseerd op de SQL Server-database-enginearchitectuur die is aangepast voor de cloudomgeving om een beschikbaarheid van 99,99% te garanderen, zelfs in het geval van fouten in de infrastructuur. Er worden drie architectuurmodellen gebruikt:

  • Algemeen/Standard
  • Bedrijfskritiek/Premium
  • Hyperscale

Premium/Bedrijfskritiek servicelaagmodel is gebaseerd op een cluster van database-engineprocessen. Dit architectuurmodel is afhankelijk van een feit dat er altijd een quorum van beschikbare database-engineknooppunten is en minimale invloed heeft op de prestaties van uw workload, zelfs tijdens onderhoudsactiviteiten. De hyperscale-servicelaag is momenteel alleen beschikbaar voor Azure SQL Database (niet SQL Managed Instance) en is een uiterst schaalbare opslag- en rekenprestatielaag die gebruik maakt van de Azure-architectuur om de opslag- en rekenresources voor een database in Azure SQL Database aanzienlijk uit te schalen buiten de limieten die beschikbaar zijn voor de Algemeen- en Bedrijfskritiek-servicelagen.

Azure upgradet en patcht het onderliggende besturingssysteem, stuurprogramma's en SQL Server database-engine transparant met de minimale down time voor eindgebruikers.

Premium beschikbaarheid is ingeschakeld in Premium- en Bedrijfskritiek-servicelagen en is ontworpen voor intensieve workloads die geen prestatie-impact als gevolg van de lopende onderhoudsbewerkingen kunnen tolereren.

Compute en opslag zijn geïntegreerd op één knooppunt in het Premium-model. Hoge beschikbaarheid in dit architectuurmodel wordt bereikt door replicatie van rekenproces (SQL Server database-engineproces) en opslag (lokaal gekoppelde SSD) geïmplementeerd naar een cluster met vier knooppunt, met behulp van technologie die vergelijkbaar is met SQL Server Always On-beschikbaarheidsgroepen.

Cluster van database-engine-knooppunten

Zowel het SQL Server database-engineproces als de onderliggende .mdf/.ldf-bestanden worden op hetzelfde knooppunt geplaatst met lokaal gekoppelde SSD-opslag met lage latentie voor uw workload. Hoge beschikbaarheid wordt geïmplementeerd met behulp van technologie die vergelijkbaar is met SQL Server Always On-beschikbaarheidsgroepen. Elke database is een cluster met databaseknooppunten met één primaire database die toegankelijk is voor workloads van klanten en drie secundaire processen met kopieën van gegevens. Het primaire knooppunt pusht voortdurend wijzigingen naar de secundaire knooppunten om ervoor te zorgen dat de gegevens beschikbaar zijn op secundaire replica's als het primaire knooppunt om een of andere reden uitvalt. Failover wordt afgehandeld door de SQL Server-database-engine: één secundaire replica wordt het primaire knooppunt en er wordt een nieuwe secundaire replica gemaakt om ervoor te zorgen dat het cluster voldoende knooppunten bevat. De workload wordt automatisch omgeleid naar het nieuwe primaire knooppunt.

Daarnaast heeft Bedrijfskritiek-cluster ingebouwde uitschaalfunctie voor lezen die gratis ingebouwd alleen-lezenknooppunt biedt dat kan worden gebruikt om alleen-lezenquery's (bijvoorbeeld rapporten) uit te voeren die geen invloed mogen hebben op de prestaties van uw primaire workload.

Wanneer u deze servicelaag kiest

Bedrijfskritiek-servicelaag is ontworpen voor toepassingen waarvoor reacties met lage latentie van de onderliggende SSD-opslag zijn vereist (gemiddeld 1-2 ms), snel herstel als de onderliggende infrastructuur uitvalt of rapporten, analyses en alleen-lezen query's moet laden naar de gratis leesbare secundaire replica van de primaire database.

De belangrijkste redenen waarom u moet kiezen Bedrijfskritiek servicelaag in plaats van Algemeen laag zijn:

  • Lage I/O-latentievereisten: workloads die snel moeten reageren vanuit de opslaglaag (gemiddeld 1-2 milliseconden) moeten gebruikmaken van Bedrijfskritiek laag.
  • Regelmatige communicatie tussen toepassing en database. Toepassingen die geen gebruik kunnen maken van caching op toepassingslagen of het aanvragen van batching en veel SQL-query's moeten verzenden die snel moeten worden verwerkt, zijn goede kandidaten voor de Bedrijfskritiek-laag.
  • Groot aantal updates: invoeg-, update- en verwijderbewerkingen wijzigen de gegevenspagina's in het geheugen (vervuilde pagina' s) die met bewerking moeten worden opgeslagen in CHECKPOINT gegevensbestanden. Een mogelijke crash van het database-engineproces of een failover van de database met een groot aantal vervuilde pagina's kan de hersteltijd in de Algemeen verhogen. Gebruik Bedrijfskritiek laag als u een workload hebt die veel wijzigingen in het geheugen veroorzaakt.
  • Langdurige transacties die gegevens wijzigen. Transacties die langer worden geopend, verhinderen afroepen van logboekbestanden, waardoor de logboekgrootte en het aantal virtuele logboekbestanden (VLF) kunnen toenemen. Een groot aantal VLF's kan het herstel van de database na een failover vertragen.
  • Workload met rapportage- en analysequery's die kunnen worden omgeleid naar de gratis secundaire alleen-lezen replica.
  • Hogere tolerantie en sneller herstel na fouten. In het geval van een systeemfout wordt de database op het primaire exemplaar uitgeschakeld en wordt een van de secundaire replica's onmiddellijk de nieuwe primaire database voor lezen/schrijven die gereed is om query's te verwerken. De database-engine hoeft geen transacties uit het logboekbestand te analyseren en opnieuw uit te proberen en alle gegevens in de geheugenbuffer te laden.
  • Advanced Data Corruption Protection. Bedrijfskritiek-laag maakt gebruik van databasereplica's achter de schermen voor bedrijfscontinuïteit. De service maakt dus ook gebruik van automatische paginaherstel. Dit is dezelfde technologie die wordt gebruikt voor SQL Server-databasespiegeling en beschikbaarheidsgroepen. In het geval dat een replica een pagina niet kan lezen vanwege een probleem met de gegevensintegriteit, wordt een nieuwe kopie van de pagina opgehaald uit een andere replica, zodat de onleesbare pagina zonder gegevensverlies of downtime van de klant wordt vervangen. Deze functionaliteit is van toepassing in Algemeen laag als de database geo-secundaire replica heeft.
  • Hogere beschikbaarheid: Bedrijfskritiek laag in multi-AZ-configuratie garandeert een beschikbaarheid van 99,995%, vergeleken met 99,99% van Algemeen laag.
  • Snel geo-herstel: Bedrijfskritiek-laag die is geconfigureerd met geo-replicatie heeft een gegarandeerde RPO (Recovery Point Objective) van 5 sec en een RTO (Recovery Time Objective) van 30 sec voor 100% van de geïmplementeerde uren.

Volgende stappen