Megosztás a következőn keresztül:

Hyperscale rugalmas készletek áttekintése az Azure SQL Database-ben

A következőkre vonatkozik:Azure SQL Database

Ez a cikk áttekintést nyújt az Azure SQL Database Hyperscale rugalmas készleteiről.

Az Azure SQL Database rugalmas készlete lehetővé teszi a szolgáltatott szoftverek (SaaS) fejlesztői számára, hogy optimalizálják az adatbáziscsoportok ár-teljesítmény arányát az előírt költségvetésen belül, miközben teljesítményrugalmasságot biztosítanak az egyes adatbázisokhoz. Az Azure SQL Database Hyperscale rugalmas készletei megosztott erőforrásmodellt vezetnek be a Hyperscale adatbázisokhoz.

Ha például az Azure CLI vagy a PowerShell használatával szeretne adatbázisokat létrehozni, skálázni vagy áthelyezni egy rugalmas skálázású készletbe, tekintse át a rugalmas skálázású rugalmas készletek parancssori eszközökkel történő használatát ismertető cikket.

A rugalmas készletek rugalmas skálázáshoz való általános elérhetőségéről további információt a Rugalmas skálázású rugalmas készletek általánosan elérhető blogban talál.

Áttekintés

Helyezze üzembe a rugalmas skálázású adatbázist egy rugalmas készletben , hogy erőforrásokat osztjon meg a készleten belüli adatbázisok között, és optimalizálja a különböző használati mintákkal rendelkező adatbázisok létrehozásának költségeit.

Rugalmas készlet rugalmas skálázású adatbázisokkal való használatának forgatókönyvei:

  • Ha a rugalmas készlethez lefoglalt számítási erőforrásokat kiszámítható időn belül felfelé vagy lefelé kell skáláznia, a lefoglalt tárterület mennyiségétől függetlenül.
  • Ha egy vagy több olvasásra optimalizált replikát szeretne hozzáadni a rugalmas készlethez lefoglalt számítási erőforrások bővítéséhez.
  • Ha nagy tranzakciónapló-átviteli sebességet szeretne használni az írásigényes számítási feladatokhoz, még alacsonyabb számítási erőforrások esetén is.

Ha nem Hyperscale adatbázisokat ad egy Hyperscale rugalmas készlethez, az adatbázisokat a Hyperscale szolgáltatási szintre konvertálja.

Építészet

A különálló rugalmas skálázású adatbázisok architektúrája hagyományosan három fő független összetevőből áll: Compute, Storage ("Page Servers"), valamint a naplóból ("Log Service"). Amikor rugalmas készletet hoz létre a rugalmas skálázású adatbázisokhoz, a készleten belüli adatbázisok számítási és naplóerőforrásokat osztanak meg. Emellett, ha a magas rendelkezésre állás konfigurálása mellett dönt, minden magas rendelkezésre állású készlet egyenértékű és független számítási és naplóerőforrás-készlettel jön létre.

Az alábbiak egy rugalmas készlet architektúráját ismertetik rugalmas skálázású adatbázisokhoz:

  • A Hiperskálázású rugalmas készlet egy elsődleges készletből áll, amely elsődleges hiperskálázású adatbázisokat tartalmaz, és ha konfigurálva van, legfeljebb négy további magas rendelkezésre állású készletet foglal magában.
  • Az elsődleges rugalmas készletben üzemeltetett elsődleges Hyperscale adatbázisok osztoznak az SQL Server-adatbázismotor (sqlservr.exe) számítási folyamatán, a virtuális magokon, a memórián és az SSD-gyorsítótáron.
  • Az elsődleges készlet magas rendelkezésre állásának konfigurálása további magas rendelkezésre állású készleteket hoz létre, amelyek írásvédett adatbázisreplikákat tartalmaznak az elsődleges készlet adatbázisaihoz. Minden elsődleges készlet legfeljebb négy magas rendelkezésre állású replikakészletet tartalmazhat. Minden magas rendelkezésre állású csoport számítási, SSD-gyorsítótár és memóriaerőforrásokat oszt meg a csoport összes másodlagos írásvédett adatbázisával.
  • Az elsődleges rugalmas készletben található hiperskálázási adatbázisok mind ugyanazt a naplószolgáltatást használják. Mivel a magas rendelkezésre állású készletek adatbázisai nem rendelkeznek írási számítási feladattal, nem használják a naplószolgáltatást.
  • Minden rugalmas skálázású adatbázis saját lapkiszolgálókkal rendelkezik, és ezek a lapkiszolgálók meg vannak osztva az elsődleges készlet elsődleges adatbázisa és a magas rendelkezésre állású készlet összes másodlagos replikaadatbázisa között.
  • Hiperméretű georeplikált másodlagos adatbázisok elhelyezhetők egy másik rugalmas készletbe.
  • ApplicationIntent=ReadOnly megadása az adatbázis kapcsolati sztringjében egy írásvédett replikaadatbázisba irányít a magas rendelkezésre állású készletek egyikében.

Az alábbi ábra a rugalmas skálázású adatbázisok rugalmas készletének architektúráját mutatja be:

Diagram, amely bemutatja a Hyperscale rugalmas készlet architektúráját.

Rugalmas skálázású rugalmas készletadatbázisok kezelése

Ugyanezekkel a parancsokkal kezelheti a készletezett rugalmas skálázású adatbázisokat, mint a többi szolgáltatási szint készletezett adatbázisait. Hyperscale rugalmas készlet létrehozásakor mindenképpen adja meg a kiadást Hyperscale.

Az egyetlen különbség a meglévő Hyperscale rugalmas erőforráskészlet magas rendelkezésre állású (H/A) replikáinak számának módosíthatósága. Ehhez tegye a következőt:

A Hyperscale adatbázisok kezeléséhez egy rugalmas készletben az alábbi ügyfélalkalmazásokat használhatja:

Nem-Hyperscale adatbázisok átalakítása Hyperscale rugalmas készletekké

Ha az adatbázist Hyperscale formátumúvá konvertálja, hozzáadhatja az adatbázist egy meglévő rugalmas skálázású készlethez. Az ilyen konvertálásokhoz a Hyperscale rugalmas készletnek ugyanazon a logikai kiszolgálón kell lennie, mint a forrásadatbázisnak.

Az adatbázisok rugalmas skálázású rugalmas készletekké alakításakor vegye figyelembe a rugalmas skálázású rugalmas készletenkénti adatbázisok maximális számát.

Nem rugalmas skálázású adatbázisok konvertálása rugalmas skálázású rugalmas készletekké a T-SQL használatával

T-SQL parancsokkal több általános célú adatbázist alakíthat át, és hozzáadhatja őket egy meglévő Hyperscale rugalmas skálázási készlethez 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]))

Ebben a példában implicit módon kéri az általános célból a Hyperscale rugalmas készletre történő átalakítást, megadva, hogy a cél SERVICE_OBJECTIVE egy Hyperscale rugalmas készlet. A fenti parancsok mindegyike elkezdi konvertálni a megfelelő általános célú adatbázist rugalmas skálázásra. Ezek a ALTER DATABASE parancsok gyorsan visszatérnek, és nem várják meg, amíg az átalakítás befejeződik. A bemutatott példában négy ilyen átalakítás futna párhuzamosan az Általános célúról a Hyperscale-ra.

A háttérkonvertálási műveletek állapotának figyeléséhez lekérdezheti a sys.dm_operation_status dinamikus felügyeleti nézetet.

Nem-Hyperscale adatbázisok átalakítása Hyperscale rugalmas készletekké a PowerShell használatával

PowerShell-parancsokkal több általános célú adatbázist konvertálhat, és hozzáadhatja azokat egy meglévő Hyperscale rugalmas készlethez hsep1. A következő példaszkript például a következő lépéseket hajtja végre:

  1. A Get-AzSqlElasticPoolDatabase parancsmaggal listázhatja az Általános célú rugalmas készletben lévő összes adatbázist gpep1.
  2. A Where-Object parancsmag a listát azoknak az adatbázisneveknek a szűrésére használja, amelyek gpepdb-tel kezdődnek.
  3. Minden adatbázis esetében a Set-AzSqlDatabase parancsmag konverziót indít el. Ebben az esetben hallgatólagosan kéri az átalakítást a Hyperscale szolgáltatási szintre azzal, hogy megadja a cél Hyperscale rugalmas készletet hsep1.
    • A -AsJob paraméter lehetővé teszi, hogy az Set-AzSqlDatabase egyes kérések párhuzamosan fussanak. Ha egyenként szeretné futtatni a konverziókat, eltávolíthatja a paramétert -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 }

A sys.dm_operation_status dinamikus felügyeleti nézet mellett a Get-AzSqlDatabaseActivity PowerShell-parancsmaggal monitorozhatja ezeknek a háttérkonvertálási műveleteknek az állapotát.

Erőforráskorlátok

Tekintse meg a Hyperscale rugalmas készletek erőforráskorlátait standard sorozatú, prémium sorozatú és prémium sorozatú memóriaoptimalizált.

Korlátozások

Vegye figyelembe a következő korlátozásokat:

  • A meglévő nem hiperskálázású rugalmas készlet hiperskálázású kiadásra való módosítása nem támogatott. A konvertálási szakasz néhány használható alternatívát kínál.
  • A Hyperscale rugalmas készlet kiadásának nem Hyperscale kiadásra történő módosítása nem támogatott.
  • ** Ahhoz, hogy egy jogosult adatbázist "fordított migrálással" visszavigyünk, amely egy Hyperscale rugalmas készletben van, először el kell távolítani a Hyperscale rugalmas készletből. A különálló Hyperscale-adatbázis ezután visszamigrálható egy általános célú önálló adatbázisba.
  • A rugalmas skálázási szolgáltatási szint esetében a zónaredundancia-támogatás csak az adatbázis vagy a rugalmas készlet létrehozása során adható meg, és az erőforrás kiépítése után nem módosítható. További információért lásd: Az Azure SQL Database migrálása a rendelkezésre állási zóna támogatására.
  • Nevesített replika hozzáadása a Hyperscale rugalmas készlethez nem támogatott. Ha egy rugalmas skálázású adatbázis nevesített példányát próbálja hozzáadni egy rugalmas skálázási készlethez, az UnsupportedReplicationOperation hibát eredményez. Ehelyett hozza létre a nevesített replikát egyetlen rugalmas skálázású adatbázisként.

Zónaredundáns rugalmas készletek megfontolásai

Íme néhány szempont a zónaredundáns Hyperscale rugalmas készletek esetében:

  • Zónaredundáns tárolóredundanciával (ZRS vagy GZRS) rendelkező adatbázisok csak zónaredundáns Hyperscale rugalmas készletekhez adhatók hozzá.
  • A zónaredundáns és zónaredundáns biztonsági mentési tárolóval (ZRS vagy GZRS) rendelkező önálló Hyperscale-adatbázist kell létrehozni ahhoz, hogy hozzáadható legyen egy zónaredundáns Hyperscale rugalmas készlethez. A zónaredundancia nélküli rugalmas skálázású adatbázisok esetében végezzen adatátvitelt egy új rugalmas skálázású adatbázisba a zónaredundancia beállítás engedélyezésével. A klónt adatbázis-másolással, időponthoz kötött visszaállítással vagy georeplikával kell létrehozni. További információ: Újratelepítés (Rugalmas skálázás).
  • Hyperscale adatbázist egyik rugalmas csomagból a másikba történő áthelyezéshez meg kell egyeznie a zóna-redundancia és a zónaredundáns biztonsági mentés tárolási beállításainak.
  • Adatbázis konvertálása másik nem Hyperscale szolgáltatási szintről Hyperscale rugalmas készletté zóna redundanciával:
    • Az Azure Portalon először engedélyezze a zónaredundanciát és a zónaredundáns biztonsági mentési tárolót (ZRS). Ezután hozzáadhatja az adatbázist a zónaredundáns Hyperscale rugalmas erőforráskészlethez.
    • A PowerShell-lel először engedélyezze a zónaredundanciát. Ezután a Set-AzSqlDatabase használatával győződjön meg arról, hogy a -BackupStorageRedundancy paraméter a zónaredundáns biztonsági mentési tároló (ZRS vagy GZRS) megadására szolgál.

Ismert problémák

Probléma Ajánlás
Ha egy adatbázist egy zónaredundáns Hyperscale rugalmas készletből egy másik régióban található, nem zónaredundáns Hyperscale rugalmas készlettel rendelkező feladatátvételi csoporthoz próbál hozzáadni, a kísérlet belsőleg meghiúsulhat, bár a művelet látszólag előrehaladás nélkül folytatódhat. A geo-másodlagos adatbázis az SSMS-hez hasonló eszközök használatakor jelenik meg, de nem tud csatlakozni a geo-másodlagos adatbázishoz, és nem használhatja azt. A feladatátvételi csoport esetleg "Seeding 0%" állapotot jeleníthet meg a földrajzi másodlagos adatbázis számára. Ez a probléma nem fordul elő, ha a második rugalmas Hyperscale készlet zónaredundáns. A probléma megoldásához állítsa be a feladatátvételi csoporton kívüli georeplikálást az Azure PowerShell használatával, és explicit módon adja meg a nem zónaredundáns parancsot a parancssorban 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. Ezután hozzáadhatja az adatbázist a feladatátvételi csoporthoz.
Ritkán előfordulhat, hogy a hiba 45122 - This Hyperscale database cannot be added into an elastic pool at this time. In case of any questions, please contact Microsoft support akkor jelenik meg, amikor rugalmas készletbe próbál áthelyezni/visszaállítani/ átmásolni egy Hyperscale adatbázist. Ez a korlátozás implementációspecifikus részletekből áll. Ha ez a hiba blokkolja Önt, küldjön egy támogatási incidenst, és kérjen segítséget.

Kapcsolódó tartalom