Architectuur van gedistribueerde Hyperscale-functies

Van toepassing op: Azure SQL Database

De Hyperscale-servicelaag maakt gebruik van een architectuur met zeer schaalbare en afzonderlijke opslag- en rekenlagen. In dit artikel worden de onderdelen beschreven waarmee klanten snel Hyperscale-databases kunnen schalen terwijl ze profiteren van bijna onmiddellijke back-ups en zeer schaalbare transactielogboekregistratie.

Tip

Vereenvoudigde prijzen voor SQL Database Hyperscale binnenkort beschikbaar. Raadpleeg de blog over prijzen van Hyperscale voor meer informatie.

Overzicht van Hyperscale-architectuur

Traditionele database-engines centraliseren gegevensbeheerfuncties in één proces: zelfs gedistribueerde databases in productie hebben tegenwoordig meerdere kopieën van een monolithische gegevensengine.

Hyperscale-databases volgen een andere benadering. Hyperscale scheidt de queryverwerkingsengine, waarbij de semantiek van verschillende gegevensengines afwijkt van de onderdelen die langetermijnopslag en duurzaamheid voor de gegevens bieden. Op deze manier kan de opslagcapaciteit zo ver mogelijk worden uitgeschaald. De aanvankelijk ondersteunde opslaglimiet is 100 TB.

Alle netwerkcommunicatie tussen Hyperscale-onderdelen maakt gebruik van de Azure-netwerkinfrastructuur met ingebouwde redundantie.

Secundaire replica's met hoge beschikbaarheid en benoemde replica's zijn optionele rekenknooppunten die op aanvraag kunnen worden toegevoegd. Beide delen dezelfde opslagonderdelen, dus er is geen gegevenskopie nodig om een nieuwe replica te maken. Een geo-secundaire replica kan op aanvraag worden toegevoegd in dezelfde of een andere Azure-regio. Voor gegevensbeveiliging en redundantie hebben geo-secundaire replica's opslagonderdelen die gescheiden zijn van de replica's die worden gebruikt door de primaire replica.

In het volgende diagram ziet u de functionele Hyperscale-architectuur:

Diagram waarin wordt weergegeven dat de rekenlaag van Hyperscale bestaat uit een primaire rekennotitie en secundaire rekenknooppunten, elk met RBPEX-gegevenscache. De logboekservice communiceert zowel met rekennotities als paginaservers. Paginaservers bestaan in hun eigen laag en hebben ook RBPEX-gegevenscache.

Een Hyperscale-database bevat de volgende typen onderdelen: rekenknooppunten, paginaservers, de logboekservice en Azure Storage.

Compute

Het rekenknooppunt bevindt zich op de plaats waar de relationele engine zich bevindt. Het rekenknooppunt is de plaats waar de taal, query en transactieverwerking plaatsvinden. Alle gebruikersinteracties met een Hyperscale-database vinden plaats via rekenknooppunten. Rekenknooppunten kunnen worden geconfigureerd voor het gebruik van serverloze of ingerichte berekeningen.

Rekenknooppunten hebben lokale op SSD gebaseerde caches met de naam Resilient Buffer Pool Extension (RBPEX Data Cache). RBPEX Data Cache is een intelligente gegevenscache met lage latentie waarmee de noodzaak om gegevens op te halen van externe paginaservers wordt geminimaliseerd.

Hyperscale-databases hebben één primair rekenknooppunt waarin de workload lezen/schrijven en transacties worden verwerkt. Er kunnen maximaal vier secundaire rekenknooppunten met hoge beschikbaarheid op aanvraag worden toegevoegd. Ze fungeren als hot standby-knooppunten voor failoverdoeleinden en kunnen fungeren als alleen-lezen rekenknooppunten om leesworkloads naar wens uit te voeren. Benoemde replica's zijn secundaire rekenknooppunten die zijn ontworpen om verschillende aanvullende OLTP-scenario's voor uitschalen uit te voeren en om HTAP-workloads (Hybrid Transactional and Analytical Processing) beter te ondersteunen. Een geografisch secundair rekenknooppunt kan worden toegevoegd voor herstel na noodgevallen en als een alleen-lezen rekenknooppunt fungeren om leesworkloads in een andere Azure-regio te offloaden.

In serverloze, de primaire replica en eventuele replica's met hoge beschikbaarheid of benoemde replica's die onafhankelijk automatisch worden geschaald op basis van hun gebruik. Het bereik voor automatische schaalaanpassing van berekeningen voor de primaire replica en eventuele benoemde replica's worden onafhankelijk geconfigureerd. Het bereik voor automatische schaalaanpassing van replica's met hoge beschikbaarheid wordt overgenomen van de configuratie voor automatisch schalen die is opgegeven door de bijbehorende primaire replica of benoemde replica.

De database-engine die wordt uitgevoerd op Hyperscale-rekenknooppunten is hetzelfde als in andere Azure SQL Database-servicelagen. Wanneer gebruikers interactie hebben met de database-engine op Hyperscale-rekenknooppunten, zijn het ondersteunde surface area- en enginegedrag hetzelfde als in andere servicelagen, met uitzondering van bekende beperkingen.

Paginaserver

Paginaservers zijn systemen die een uitgeschaalde opslagengine vertegenwoordigen. Elke paginaserver is verantwoordelijk voor een subset van de pagina's in de database. Elke paginaserver heeft ook een replica die wordt bewaard voor redundantie en beschikbaarheid.

De taak van een paginaserver is om databasepagina's naar de rekenknooppunten op aanvraag te verwerken en de pagina's bijgewerkt te houden wanneer transacties gegevens bijwerken. Paginaservers worden up-to-date gehouden door transactielogboekrecords van de logboekservice opnieuw af te spelen.

Paginaservers onderhouden ook de op SSD gebaseerde caches om de prestaties te verbeteren. Langetermijnopslag van gegevenspagina's wordt bewaard in Azure Storage voor duurzaamheid.

Logboekservice

De logboekservice accepteert transactielogboekrecords die overeenkomen met gegevenswijzigingen van de primaire rekenreplica. Paginaservers ontvangen vervolgens de logboekrecords van de logboekservice en passen de wijzigingen toe op hun respectieve segmenten gegevens. Bovendien ontvangen rekenreplica's logboekrecords van de logboekservice en worden alleen de wijzigingen in pagina's die al in hun buffergroep of lokale RBPEX-cache aanwezig zijn, opnieuw afgespeeld. Alle gegevenswijzigingen van de primaire rekenreplica worden doorgegeven via de logboekservice naar alle secundaire rekenreplica's en paginaservers.

Ten slotte worden transactielogboekrecords naar langetermijnopslag in Azure Storage gepusht. Dit is een vrijwel oneindige opslagopslagplaats. Dit mechanisme verwijdert de noodzaak van regelmatige afkapping van logboeken. De veelvoorkomende redenen voor logboekgroei, zoals gemiste logboekback-ups of trage gegevensreplicatie naar secundaire replica's, zijn niet van toepassing op Hyperscale. De logboekservice heeft lokaal geheugen en SSD-caches om de toegang tot logboekrecords te versnellen.

Azure Storage

Azure Storage bevat alle gegevensbestanden in een database. Paginaservers bewaren gegevensbestanden in Azure Storage up-to-date. Deze opslag wordt ook gebruikt voor back-updoeleinden en kan worden gerepliceerd tussen regio's op basis van de keuze van opslagredundantie.

Back-ups worden geïmplementeerd met behulp van opslagmomentopnamen van gegevensbestanden. Herstelbewerkingen met behulp van momentopnamen zijn snel, ongeacht de gegevensgrootte. Een database kan worden hersteld naar elk tijdstip binnen de bewaarperiode van de back-up.

Hyperscale ondersteunt configureerbare opslagredundantie. Wanneer u een Hyperscale-database maakt, kunt u kiezen uit de volgende typen Standaardopslag van Azure:

• Lokaal redundante opslag (LRS)
• Zone-redundante opslag (ZRS)
• Geografisch redundante opslag met leestoegang (RA-GRS)
• Leestoegang tot geografische zone-redundante opslag (RA-GZRS)

Zone-redundante opslagopties zijn beschikbaar in Azure-regio's met beschikbaarheidszones.

De geselecteerde optie voor opslagredundantie wordt gebruikt voor de levensduur van de database, voor zowel redundantie van gegevensopslag als back-upopslagredundantie.

Gerelateerde inhoud

• Hyperscale-servicelaag
• Veelgestelde vragen over Azure SQL Database Hyperscale
• Quickstart: Een Hyperscale-database maken in Azure SQL Database
• Veelgestelde vragen over Azure SQL Database Hyperscale benoemde replica's