Hoge beschikbaarheid per servicelaag
Om inzicht te krijgen in de beschikbaarheidsopties en mogelijkheden van Azure SQL, moet u begrip hebben van servicelagen. De servicelaag die u selecteert, bepaalt de onderliggende architectuur van de database of het beheerde exemplaar dat u implementeert.
Er zijn twee aankoopmodellen die u moet overwegen: DTU en vCore. Deze les is gericht op de vCore-servicelagen en hun architectuur voor hoge beschikbaarheid. U kunt de lagen Basic en Standard in het DTU-model vergelijken met Algemeen gebruik en Premium-lagen met Bedrijfskritiek.
Algemeen gebruik
Databases en beheerde exemplaren in de servicelaag Algemeen gebruik hebben dezelfde beschikbaarheidsarchitectuur. Gebruik de volgende afbeelding als richtlijn om eerst de toepassing en besturingsring te bekijken. De toepassing maakt verbinding met de servernaam, die vervolgens verbinding maakt met een gateway (GW), die de verbinding van de toepassing naar de juiste server verwijst, die wordt uitgevoerd op een virtuele machine. Bij Algemeen gebruik maakt de primaire replica gebruik van lokaal gekoppelde SSD voor de tempdb. De gegevens en logboekbestanden worden opgeslagen in Azure Premium Storage, wat lokaal redundante opslag (meerdere kopieën in één regio) is. De back-upbestanden worden vervolgens opgeslagen in Azure Standard Storage, dat standaard RA-GRS is. RA-GRS is wereldwijd redundante opslag, met kopieën in meerdere regio's.
Zoals we in een eerdere module in dit leertraject hebben besproken, is Azure SQL volledig gebouwd op Azure Service Fabric, dat fungeert als de Azure-backbone. Als Azure Service Fabric bepaalt dat een failover moet worden uitgevoerd, is de failover vergelijkbaar met die van een failoverclusterexemplaar. De service-infrastructuur zoekt naar een knooppunt met reservecapaciteit en maakt een nieuw SQL Server-exemplaar. De databasebestanden worden vervolgens gekoppeld, herstel wordt uitgevoerd en gateways worden bijgewerkt om toepassingen naar het nieuwe knooppunt te laten verwijzen. Er zijn geen virtuele netwerken of listeners of updates vereist. Deze functie is ingebouwd.
Bedrijfskritiek
De volgende servicelaag die u moet overwegen, is Bedrijfskritiek. Deze laag biedt over het algemeen de hoogste prestaties en beschikbaarheid van alle Azure SQL-servicelagen (Algemeen gebruik, Hyperscale, Bedrijfskritiek). Bedrijfskritiek is bedoeld voor essentiële toepassingen waarvoor een lage latentie en minimale downtime vereist zijn.
Bedrijfskritiek is vergelijkbaar met het achter de schermen implementeren van een AlwaysOn-beschikbaarheidsgroep (AG). In tegenstelling tot in de laag Algemeen gebruik worden de gegevens en logboekbestanden in Bedrijfskritiek allemaal uitgevoerd op een direct gekoppelde SSD, waardoor de netwerklatentie aanzienlijk wordt verminderd. (Algemeen gebruik maakt gebruik van externe opslag.) In deze AG zijn er drie secundaire replica's. U kunt een van deze gebruiken als een alleen-lezen eindpunt (zonder extra kosten). Een transactie kan worden doorgevoerd wanneer ten minste één van de secundaire replica's de wijziging voor het transactielogboek heeft gehard.
Uitschalen van lezen met een van de secundaire replica's ondersteunt consistentie op sessieniveau. Als de sessie met het kenmerk Alleen-lezen opnieuw verbinding maakt na een verbindingsfout die wordt veroorzaakt door de niet-beschikbare replica, wordt deze mogelijk omgeleid naar een replica die niet 100% up-to-date is met de lees-/schrijfreplica. Als een toepassing gegevens schrijft met behulp van een sessie voor lezen-schrijven en de gegevens onmiddellijk leest met behulp van een sessie voor alleen-lezen, is het mogelijk dat de meest recente updates niet direct zichtbaar zijn op de replica. De latentie wordt veroorzaakt door een redo-bewerking voor het transactielogboek die asynchroon wordt uitgevoerd.
Als er een fout optreedt en de Service Fabric bepaalt dat er een failover nodig is, is een failover naar een secundaire replica snel omdat de replica al bestaat en de gegevens eraan is gekoppeld. In een failover hebt u geen listener nodig. De gateway leidt uw verbinding om naar de primaire, zelfs na een failover. Deze schakeloptie vindt snel plaats, waarna de service fabric zorgt voor het opzetten van een andere secundaire replica.
Hyperscale
De Hyperscale-servicelaag is alleen beschikbaar in Azure SQL Database. Deze servicelaag heeft een unieke architectuur omdat deze gebruikmaakt van een gelaagde laag caches en paginaservers om de mogelijkheid om snel toegang te krijgen tot databasepagina's uit te breiden zonder rechtstreeks toegang te hebben tot het gegevensbestand.
Omdat deze architectuur gebruikmaakt van gekoppelde paginaservers, kunt u horizontaal schalen om alle gegevens in cachelagen te plaatsen. Via deze nieuwe architectuur kan Hyperscale ook ondersteuning bieden voor databases tot maximaal 100 TB. Omdat gebruik wordt gemaakt van momentopnamen, kunnen databaseback-ups vrijwel onmiddellijk plaatsvinden, ongeacht de grootte. Het maken van een database duurt slechts enkele minuten in plaats van uren of dagen. U kunt ook in realtime omhoog of omlaag schalen op basis van uw workloads.
Het is interessant om te zien hoe de logboekservice is uitgebreid in deze architectuur. De logboekservice wordt gebruikt voor het doorgeven van gegevens aan de replica's en de paginaservers. Transacties kunnen worden doorgevoerd wanneer de logboekservice wordt beperkt tot de landingszone, zodat het verbruik van de wijzigingen door een secundaire rekenreplica niet vereist is voor een doorvoering. In tegenstelling tot andere servicelagen kunt u bepalen of u secundaire replica's wilt. U kunt nul tot vier secundaire replica's configureren, die u allemaal kunt gebruiken voor leesschaal.
Net als in de andere servicelagen wordt een automatische failover uitgevoerd als service fabric dit nodig heeft, maar de hersteltijd is afhankelijk van het bestaan van secundaire replica's. Als u bijvoorbeeld geen replica's hebt en er een failover wordt uitgevoerd, is het scenario vergelijkbaar met dat van de servicelaag Algemeen gebruik: de Service Fabric moet eerst reservecapaciteit vinden. Als u een of meer replica's hebt, verloopt de herstelbewerking sneller en lijkt deze meer op die van de servicelaag Bedrijfskritiek.
Bedrijfskritiek onderhoudt de hoogste prestaties en beschikbaarheid voor workloads met kleine logboekschrijfbewerkingen die lage latentie nodig hebben, maar met de Hyperscale-servicelaag kunt u een hogere logboekdoorvoer krijgen in termen van MB/seconde, de grootste databasegrootten bieden en maximaal vier secundaire replica's bieden voor hogere leesschaalniveaus. Daarom moet u rekening houden met uw workload wanneer u tussen de twee kiest.