Delen via

Overzicht van elastische Hyperscale-pools in Azure SQL Database

Van toepassing op:Azure SQL Database

Dit artikel bevat een overzicht van elastische Hyperscale-pools in Azure SQL Database.

Met een elastische Pool van Azure SQL Database kunnen SaaS-ontwikkelaars (Software-as-a-Service) de prijs-prestatieverhouding voor een groep databases binnen een voorgeschreven budget optimaliseren en tegelijkertijd prestatie-elasticiteit bieden voor elke database. Elastische pools van Azure SQL Database Hyperscale introduceert een gedeeld resourcemodel voor Hyperscale-databases.

Voor voorbeelden voor het maken, schalen of verplaatsen van databases naar een elastische Hyperscale-pool met behulp van de Azure CLI of PowerShell, raadpleegt u Werken met elastische Hyperscale-pools met opdrachtregelprogramma's

Voor meer informatie over de algemene beschikbaarheid van elastische pools voor Hyperscale raadpleegt u Blog: Elastische Hyperscale-pools algemeen beschikbaar.

Overzicht

Implementeer uw Hyperscale-database in een elastische pool om resources te delen tussen databases binnen de pool en optimaliseer de kosten voor het gebruik van meerdere databases met verschillende gebruikspatronen.

Scenario's voor het gebruik van een elastische pool met uw Hyperscale-databases:

  • Wanneer u de rekenresources die aan de elastische pool zijn toegewezen in een voorspelbare hoeveelheid tijd omhoog of omlaag moet schalen, onafhankelijk van de hoeveelheid toegewezen opslag.
  • Wanneer u de rekenresources wilt uitschalen die zijn toegewezen aan de elastische pool door een of meer replica's op leesschaal toe te voegen.
  • Als u een hoge doorvoer van transactielogboeken wilt gebruiken voor schrijfintensieve workloads, zelfs met lagere rekenresources.

Als u niet-Hyperscale-databases toevoegt aan een elastische Hyperscale-pool, worden de databases geconverteerd naar de Hyperscale-servicelaag.

Architectuur

Traditioneel bestaat de architectuur van een zelfstandige Hyperscale-database uit drie belangrijke onafhankelijke onderdelen: Compute, Storage ('Paginaservers') en het logboek ('Log Service'). Wanneer u een elastische pool maakt voor uw Hyperscale-databases, delen de databases in de pool reken- en logboekresources. Als u ervoor kiest om hoge beschikbaarheid te configureren, wordt elke pool met hoge beschikbaarheid gemaakt met een equivalente en onafhankelijke set reken- en logboekresources.

Hieronder wordt de architectuur van een elastische pool voor Hyperscale-databases beschreven:

  • Een elastische Hyperscale-pool bestaat uit een primaire pool die als host fungeert voor primaire Hyperscale-databases en, indien geconfigureerd, tot vier extra pools met hoge beschikbaarheid.
  • Primaire Hyperscale-databases die worden gehost in de primaire elastische pool, delen de SQL Server-database-engine (sqlservr.exe) rekenproces, vCores, geheugen en SSD-cache.
  • Als u hoge beschikbaarheid configureert voor de primaire pool, worden er extra hoge beschikbaarheidspools gecreëerd die readonly-databasereplica’s bevatten voor de databases in de primaire pool. Elke primaire pool kan maximaal vier replica pools met hoge beschikbaarheid hebben. Elke pool met hoge beschikbaarheid deelt rekenkracht, SSD-cache en geheugenresources voor alle secundaire alleen-lezen databases in de pool.
  • Hyperscale-databases in de primaire elastische pool delen allemaal dezelfde logboekservice. Omdat databases in de pools met hoge beschikbaarheid geen schrijfworkload hebben, maken ze geen gebruik van de logboekservice.
  • Elke Hyperscale-database heeft een eigen set paginaservers en deze paginaservers worden gedeeld tussen de primaire database in de primaire pool en alle secundaire replicadatabases in de pool met hoge beschikbaarheid.
  • Secundaire Hyperscale-databases met geo-replicatie kunnen in een andere elastische pool worden geplaatst.
  • Als u ApplicationIntent=ReadOnly in de databaseverbindingsreeks opgeeft, wordt u doorgestuurd naar een alleen-lezen replicadatabase in een van de high-availability pools.

In het volgende diagram ziet u de architectuur van een elastische pool voor Hyperscale-databases:

Diagram met de architectuur van de elastische Hyperscale-pool.

Databases voor elastische Hyperscale-pools beheren

U kunt dezelfde opdrachten gebruiken om uw gegroepeerde Hyperscale-databases te beheren als pooldatabases in de andere servicelagen. Zorg ervoor dat u de editie opgeeft Hyperscale bij het maken van uw elastische Hyperscale-pool.

Het enige verschil is de mogelijkheid om het aantal replica's voor hoge beschikbaarheid (H/A) in een bestaande Hyperscale-elastische pool aan te passen. Hiervoor doet u het volgende:

U kunt de volgende clienthulpprogramma's gebruiken om uw Hyperscale-databases in een elastische pool te beheren:

Niet-Hyperscale-databases converteren naar elastische Hyperscale-pools

Wanneer u een database converteert naar Hyperscale, kunt u de database toevoegen aan een bestaande elastische Hyperscale-pool. Voor deze conversies moet de elastische Hyperscale-pool bestaan op dezelfde logische server als de brondatabase.

Wanneer u databases converteert naar elastische Hyperscale-pools, moet u rekening houden met het maximum aantal databases per elastische Hyperscale-pool.

Niet-Hyperscale-databases converteren naar elastische Hyperscale-pools met behulp van T-SQL

U kunt T-SQL-opdrachten gebruiken om meerdere algemene databases te converteren en deze toe te voegen aan een bestaande elastische Hyperscale-pool met de naam hsep1:

ALTER DATABASE gpepdb1 MODIFY (SERVICE_OBJECTIVE = ELASTIC_POOL(NAME = [hsep1]))
ALTER DATABASE gpepdb2 MODIFY (SERVICE_OBJECTIVE = ELASTIC_POOL(NAME = [hsep1]))
ALTER DATABASE gpepdb3 MODIFY (SERVICE_OBJECTIVE = ELASTIC_POOL(NAME = [hsep1]))
ALTER DATABASE gpepdb4 MODIFY (SERVICE_OBJECTIVE = ELASTIC_POOL(NAME = [hsep1]))

In dit voorbeeld vraagt u impliciet om een conversie van Algemeen gebruik naar Hyperscale door op te geven dat het doel SERVICE_OBJECTIVE een elastische Hyperscale-pool is. Met elk van de bovenstaande opdrachten wordt de respectieve database voor algemeen gebruik geconverteerd naar Hyperscale. Deze ALTER DATABASE opdrachten worden snel geretourneerd en wachten niet tot de conversie is voltooid. In het voorbeeld dat wordt weergegeven, hebt u vier dergelijke conversies van Algemeen gebruik naar Hyperscale die parallel worden uitgevoerd.

U kunt een query uitvoeren op de sys.dm_operation_status dynamische beheerweergave om de status van deze bewerkingen voor achtergrondconversie te controleren.

Niet-Hyperscale-databases converteren naar elastische Hyperscale-pools met behulp van PowerShell

U kunt PowerShell-opdrachten gebruiken om meerdere algemene databases te converteren en toe te voegen aan een bestaande elastische Hyperscale-pool met de naam hsep1. Met het volgende voorbeeldscript worden bijvoorbeeld de volgende stappen uitgevoerd:

  1. Gebruik de cmdlet Get-AzSqlElasticPoolDatabase om alle databases in de General Purpose elastische pool met de naam gpep1 weer te geven.
  2. De Where-Object cmdlet filtert de lijst alleen op die databasenamen die beginnen met gpepdb.
  3. Voor elke database start de Set-AzSqlDatabase-cmdlet een conversie. In dit geval vraagt u impliciet een conversie aan naar de Hyperscale-servicelaag door de elastische doelpool van Hyperscale op te geven met de naam hsep1.
    • Met de -AsJob parameter kan elke Set-AzSqlDatabase aanvraag parallel worden uitgevoerd. Als u liever de conversies één voor één uitvoert, kunt u de -AsJob parameter verwijderen.
$dbs = Get-AzSqlElasticPoolDatabase -ResourceGroupName "myResourceGroup" -ServerName "mylogicalserver" -ElasticPoolName "gpep1"
$dbs | Where-Object { $_.DatabaseName -like "gpepdb*" } | % { Set-AzSqlDatabase -ResourceGroupName "myResourceGroup" -ServerName "mylogicalserver" -DatabaseName ($_.DatabaseName) -ElasticPoolName "hsep1" -AsJob }

Naast de sys.dm_operation_status dynamische beheerweergave kunt u de PowerShell-cmdlet Get-AzSqlDatabaseActivity gebruiken om de status van deze achtergrondconversiebewerkingen te controleren.

Beperkingen van bronnen

Zie de resourcelimieten van elastische Hyperscale-pools voor geoptimaliseerd geheugen uit de standard-serie, premium-serie en premium-serie.

Beperkingen

Houd rekening met de volgende beperkingen:

  • Het wijzigen van een bestaande niet-Hyperscale elastische pool in de Hyperscale-editie wordt niet ondersteund. De sectie conversie biedt enkele alternatieven die u kunt gebruiken.
  • Het wijzigen van de editie van een Hyperscale-elastische pool naar een niet-Hyperscale-editie wordt niet ondersteund.
  • Als u een in aanmerking komende database wilt reverse migreren, die zich in een Hyperscale elastische pool bevindt, moet deze eerst worden verwijderd uit de elastische pool. De zelfstandige Hyperscale-database kan vervolgens worden 'omgekeerd gemigreerd' naar een zelfstandige database voor algemeen gebruik.
  • Voor de Hyperscale-servicelaag kan zoneredundantie alleen worden opgegeven tijdens het maken van de database of elastische pool en kan deze niet worden gewijzigd zodra de resource is ingericht. Zie Azure SQL Database migreren naar ondersteuning voor beschikbaarheidszones voor meer informatie.
  • Het toevoegen van een benoemde replica aan een elastische Hyperscale-pool wordt niet ondersteund. Als u een benoemde replica van een Hyperscale-database probeert toe te voegen aan een elastische Hyperscale-pool, treedt er een UnsupportedReplicationOperation fout op. Maak in plaats daarvan de benoemde replica als één Hyperscale-database.

Overwegingen voor zoneredundante elastische pools

Hier volgen enkele overwegingen voor zoneredundante elastische Hyperscale-pools:

  • Alleen databases met zone-redundante opslagredundantie (ZRS of GZRS) kunnen worden toegevoegd aan elastische Hyperscale-pools met zoneredundantie.
  • Een zelfstandige Hyperscale-database moet worden gemaakt met zoneredundantie en zone-redundante back-upopslag (ZRS of GZRS) om deze toe te voegen aan een zone-redundante Hyperscale elastic pool. Voor Hyperscale-databases zonder zoneredundantie voert u een gegevensoverdracht uit naar een nieuwe Hyperscale-database met de optie zoneredundantie ingeschakeld. Er moet een kloon worden gemaakt met behulp van databasekopie, herstel naar een bepaald tijdstip of geo-replica. Zie Opnieuw implementeren (Hyperscale) voor meer informatie.
  • Als u een Hyperscale-database van de ene elastische pool naar een andere wilt verplaatsen, moeten de zoneredundantie en zone-redundante back-upopslaginstellingen overeenkomen.
  • Een database converteren van een andere servicelaag dan Hyperscale naar een elastische Hyperscale-pool met zoneredundantie:
    • Schakel eerst via Azure Portal zowel zoneredundantie als zone-redundante back-upopslag (ZRS) in. Vervolgens kunt u de database toevoegen aan de zoneredundante elastische Hyperscale-pool.
    • Schakel eerst zoneredundantie in via PowerShell. Zorg er vervolgens met Set-AzSqlDatabase voor dat de -BackupStorageRedundancy parameter wordt gebruikt om zone-redundante back-upopslag (ZRS of GZRS) op te geven.

Bekende problemen

Probleem Aanbeveling
Het toevoegen van een database vanuit een elastische Hyperscale-pool met zone-redundantie aan een failovergroep met een elastische Hyperscale-pool zonder zone-redundantie in een andere regio zal intern mislukken, maar de bewerking kan doorgaan zonder vooruitgang te boeken. U kunt de geo-secundaire database zien wanneer u hulpprogramma's zoals SSMS gebruikt, maar u kunt geen verbinding maken met en de geo-secundaire database gebruiken. De failovergroep kan de status Seeding 0%weergeven voor de geo-secundaire database. Dit probleem treedt niet op als de tweede elastische Hyperscale-pool zone-redundant is. U kunt dit probleem omzeilen door geo-replicatie buiten de failovergroep in te stellen met behulp van Azure PowerShell, waarbij expliciet niet-zoneredundant wordt opgegeven in de opdrachtregel New-AzSqlDatabaseSecondary -ResourceGroupName "primary-rg" -ServerName "primary-server" -DatabaseName "hsdb1" -PartnerResourceGroupName "secondary-rg" -PartnerServerName "secondary-server" -AllowConnections "All" -SecondaryElasticPoolName "secondary-nonzr-pool" -BackupStorageRedundancy Local -ZoneRedundant:$false. Vervolgens kunt u de database toevoegen aan de failovergroep.
In zeldzame gevallen krijgt u mogelijk de fout 45122 - This Hyperscale database cannot be added into an elastic pool at this time. In case of any questions, please contact Microsoft support, bij het verplaatsen/herstellen/kopiëren van een Hyperscale-database naar een elastische pool. Deze beperking wordt veroorzaakt door implementatiespecifieke details. Als deze fout u blokkeert, dient u een ondersteuningsincident in en vraagt u om hulp.

Verwante inhoud