Dela via

Översikt över elastiska pooler i Hyperskala i Azure SQL Database

  • Artikel

gäller för:Azure SQL Database

Den här artikeln innehåller en översikt över elastiska Hyperskala-pooler i Azure SQL Database.

En Azure SQL Database-elastisk pool gör det möjligt för SaaS-utvecklare (programvara som en tjänst) att optimera förhållandet mellan pris och prestanda för en grupp databaser inom en föreskriven budget samtidigt som prestandaelasticiteten för varje databas levereras. Elastiska Azure SQL Database-pooler med hyperskala introducerar en delad resursmodell för Hyperskala-databaser.

Exempel för att skapa, skala eller flytta databaser till en elastisk Hyperskala-pool med hjälp av Azure CLI eller PowerShell finns i Arbeta med elastiska hyperskalapooler med hjälp av kommandoradsverktyg

Mer information om den allmänna tillgängligheten för elastiska pooler för Hyperskala finns i Blogg: Elastiska hyperskalapooler som är allmänt tillgängliga.

Överblick

Distribuera hyperskala-databasen till en elastisk pool för att dela resurser mellan databaser i poolen och optimera kostnaden för att ha flera databaser med olika användningsmönster.

Scenarier för att använda en elastisk pool med dina Hyperskala-databaser:

  • När du behöver skala upp eller ned de beräkningsresurser som allokerats till den elastiska poolen på ett förutsägbart sätt, oberoende av mängden allokerad lagring.
  • När du vill skala ut de beräkningsresurser som allokerats till den elastiska poolen genom att lägga till en eller flera skrivbara repliker.
  • Om du vill använda högt transaktionsloggflöde för skrivintensiva arbetsbelastningar, även med lägre beräkningsresurser.

Om du lägger till icke-Hyperskala-databaser i en elastisk hyperskala-pool konverteras databaserna till tjänstnivån Hyperskala.

Arkitektur

Traditionellt består den arkitekturen för en fristående Hyperskala-databas av tre huvudsakliga oberoende komponenter: Compute, Storage ("Page Servers") och loggen ("Log Service"). När du skapar en elastisk pool för dina Hyperskala-databaser delar databaserna i poolen beräknings- och loggresurser. Om du väljer att konfigurera hög tillgänglighet skapas dessutom varje pool med hög tillgänglighet med en motsvarande och oberoende uppsättning beräknings- och loggresurser.

Följande beskriver arkitekturen för en elastisk pool för Hyperskala-databaser:

  • En elastisk hyperskalapool består av en primär pool som är värd för primära Hyperskala-databaser och, om den konfigureras, upp till fyra ytterligare pooler med hög tillgänglighet.
  • Primära Hyperskala-databaser som finns i den primära elastiska poolen delar SQL Server-databasmotorn (sqlservr.exe) beräkningsprocessen, virtuella kärnor, minne och SSD-cache.
  • Om du konfigurerar hög tillgänglighet för den primära poolen skapas ytterligare pooler med hög tillgänglighet som innehåller skrivskyddade databasrepliker för databaserna i den primära poolen. Varje primär pool kan ha högst fyra replikpooler med hög tillgänglighet. Varje pool med hög tillgänglighet delar beräknings-, SSD-cache- och minnesresurser för alla sekundära skrivskyddade databaser i poolen.
  • Hyperskala-databaser i den primära elastiska poolen delar alla samma loggtjänst. Eftersom databaser i poolerna med hög tillgänglighet inte har någon skrivarbetsbelastning använder de inte loggtjänsten.
  • Varje Hyperskala-databas har en egen uppsättning sidservrar och dessa sidservrar delas mellan den primära databasen i den primära poolen och alla sekundära replikdatabaser i poolen med hög tillgänglighet.
  • Geo-replikerade sekundära Hyperskala-databaser kan placeras i en annan elastisk pool.
  • Om du anger ApplicationIntent=ReadOnly i databasanslutningssträngen dirigeras du till en skrivskyddad replikdatabas i en av poolerna med hög tillgänglighet.

Följande diagram visar arkitekturen för en elastisk pool för Hyperskala-databaser:

diagram som visar arkitekturen för elastisk hyperskalapool.

Hantera elastiska pooldatabaser i Hyperskala

Du kan använda samma kommandon för att hantera dina pooldatabaser i Hyperskala som pooldatabaser på de andra tjänstnivåerna. Se bara till att ange Hyperscale för utgåvan när du skapar din elastiska Hyperskala-pool.

Den enda skillnaden är möjligheten att ändra antalet repliker för hög tillgänglighet (H/A) för en befintlig Hyperskala-elastisk pool. Så här gör du:

Du kan använda följande klientverktyg för att hantera dina Hyperskala-databaser i en elastisk pool:

Konvertera icke-Hyperskala-databaser till elastiska hyperskalapooler

När du konverterar en databas till Hyperskala kan du lägga till databasen i en befintlig elastisk Hyperskala-pool. För dessa konverteringar måste den elastiska hyperskalapoolen finnas på samma logiska server som källdatabasen.

När du konverterar databaser till elastiska Hyperskala-pooler bör du vara medveten om maximalt antal databaser per elastisk Hyperskala-pool.

Konvertera icke-Hyperskala-databaser till elastiska hyperskalapooler med T-SQL

Du kan använda T-SQL-kommandon för att konvertera flera databaser för generell användning och lägga till dem i en befintlig elastisk hyperskala-pool med namnet 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]))

I det här exemplet begär du implicit en konvertering från Generell användning till Hyperskala genom att ange att målet SERVICE_OBJECTIVE är en elastisk hyperskalapool. Vart och ett av ovanstående kommandon börjar konvertera respektive databas för generell användning till Hyperskala. Dessa ALTER DATABASE kommandon returnerar snabbt och väntar inte på att konverteringen ska slutföras. I exemplet som visas skulle du ha fyra sådana konverteringar från Generell användning till Hyperskala som körs parallellt.

Du kan använda sys.dm_operation_status den dynamiska hanteringsvyn för att övervaka status för dessa bakgrundskonverteringsåtgärder.

Konvertera icke-Hyperskala-databaser till elastiska Hyperskala-pooler med hjälp av PowerShell

Du kan använda PowerShell-kommandon för att konvertera flera databaser för generell användning och lägga till dem i en befintlig elastisk Hyperskala-pool med namnet hsep1. Följande exempelskript utför till exempel följande steg:

  1. Använd cmdleten Get-AzSqlElasticPoolDatabase för att lista alla databaser i den elastiska poolen Allmänt syfte med namnet gpep1.
  2. Cmdleten Where-Object filtrerar listan till endast de databasnamn som börjar med gpepdb.
  3. För varje databas startar Set-AzSqlDatabase cmdlet en konvertering. I det här fallet begär du implicit en konvertering till tjänstnivån Hyperskala genom att ange den elastiska målpoolen för Hyperskala med namnet hsep1.
    • Med parametern -AsJob kan var och en av de Set-AzSqlDatabase begäranden köras parallellt. Om du föredrar att köra konverteringarna en i taget kan du ta bort parametern -AsJob.
$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 }

Förutom vyn sys.dm_operation_status dynamisk hantering kan du använda PowerShell-cmdleten Get-AzSqlDatabaseActivity för att övervaka statusen för dessa bakgrundskonverteringsåtgärder.

Resursbegränsningar

Se resursgränserna för Hyperskala elastiska pooler för standardserie, Premium-serienoch minnesoptimerad Premium-serien.

Begränsningar

Tänk på följande begränsningar:

  • Det går inte att ändra en befintlig elastisk pool som inte är hyperskala till Hyperskala-utgåvan. Avsnittet konvertering innehåller några alternativ som du kan använda.
  • Det går inte att ändra utgåvan av en elastisk hyperskala-pool till en icke-Hyperskala-utgåva.
  • För att "omvänd migrera" en berättigad databas, som finns i en elastisk hyperskalapool, måste den först tas bort från poolen. Den fristående Hyperskala-databasen kan sedan "omvänd migreras" till en fristående databas för generell användning.
  • För tjänstnivån Hyperskala kan stöd för zonredundans endast anges när databasen eller den elastiska poolen skapas och kan inte ändras när resursen har etablerats. Mer information finns i Migrera Azure SQL Database till stöd för tillgänglighetszoner.
  • Det går inte att lägga till en replik med namnet i en hyperskale-elastisk pool. Försök att lägga till en namngiven replik av en Hyperscale-databas i en Hyperscale elastisk pool resulterar i ett fel av typen UnsupportedReplicationOperation. Skapa i stället den namngivna repliken som en enda Hyperskala-databas.

Överväganden för zonredundanta elastiska pooler

Här följer några överväganden för zonredundanta elastiska hyperskalapooler:

  • Endast databaser med zonredundant lagringsredundans (ZRS eller GZRS) kan läggas till i elastiska Hyperskala-pooler med zonredundans.
  • En fristående Hyperscale-databas måste skapas med zonredundans och zonredundant lagring av säkerhetskopiering (ZRS eller GZRS) för att kunna lägga till den i en zonredundant elastisk Hyperscale-pool. För Hyperskala-databaser utan zonredundans utför du en dataöverföring till en ny Hyperskala-databas med alternativet zonredundans aktiverat. En klon måste skapas med hjälp av databasens kopia, återställning till en viss tidpunkt eller geo-replik. Mer information finns i Omdistribution (Hyperskala).
  • Om du vill flytta en Hyperskala-databas från en elastisk pool till en annan måste zonens redundans och zonredundanta lagringsinställningar för säkerhetskopiering matcha.
  • Så här konverterar du en databas från en annan tjänstnivå än Hyperskala till en elastisk hyperskalapool med zonredundans:
    • Via Azure-portalen aktiverar du först både zonredundans och zonredundant säkerhetskopieringslagring (ZRS). Sedan kan du lägga till databasen i den zonredundanta elastiska hyperskalapoolen.
    • Aktivera zonredundans via PowerShell. Med Set-AzSqlDatabasekontrollerar du sedan att parametern -BackupStorageRedundancy används för att ange zonredundant lagring av säkerhetskopiering (ZRS eller GZRS).

Kända problem

Utfärda Rekommendation
Att lägga till en databas från en zonredundant hyperskalapool i en failover-grupp med en icke-zonredundant hyperskalapool i en annan region kommer att misslyckas internt, men åtgärden kan verka fortsätta utan framsteg. Du kan se den geo-sekundära databasen när du använder verktyg som SSMS, men du kan inte ansluta till och använda den geo-sekundära databasen. Redundansgruppen kan visa statusen "Seeding 0%" för den geo-sekundära databasen. Det här problemet uppstår inte om den andra elastiska hyperskalapoolen är zonredundant. Du kan undvika det här problemet genom att konfigurera geo-replikering utanför failover gruppen med hjälp av Azure PowerShell och uttryckligen ange icke-zonredundant på kommandoraden 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. Sedan kan du lägga till databasen i redundansgruppen.
I sällsynta fall kan du få felet 45122 - This Hyperscale database cannot be added into an elastic pool at this time. In case of any questions, please contact Microsoft supportnär du försöker flytta/återställa/kopiera en Hyperskala-databas till en elastisk pool. Den här begränsningen beror på implementeringsspecifik information. Om det här felet blockerar dig skapar du en supportincident och begär hjälp.

Relaterat innehåll