Übersicht über Pools für elastische Hyperscale-Datenbanken in Azure SQL-Datenbank

  • Artikel

Gilt für:Azure SQL-Datenbank

Dieser Artikel bietet eine Übersicht über Pools für elastische Hyperscale-Datenbanken in Azure SQL-Datenbank.

Mit einem Pool für elastische Datenbanken in Azure SQL-Datenbank kann bei der SaaS-Entwicklung (Software-as-a-Service) das Preis-Leistungs-Verhältnis für eine Gruppe von Datenbanken im Rahmen eines vorgegebenen Budgets optimiert und gleichzeitig eine flexible Leistung für jede Datenbank sichergestellt werden. Pools für elastische Datenbanken von Azure SQL-Datenbank auf der Dienstebene „Hyperscale“ bieten ein neues Ressourcenmodell für Hyperscale-Datenbanken.

Beispiele zum Erstellen, Skalieren oder Verschieben von Datenbanken in einen Pool für elastische Hyperscale-Datenbanken mithilfe der Azure CLI oder von PowerShell finden Sie unter Arbeiten mit Pools für elastische Hyperscale-Datenbanken mithilfe von Befehlszeilentools.

Hinweis

Pools für elastische Hyperscale-Datenbanken befinden sich derzeit in der Vorschauphase.

Übersicht

Stellen Sie Ihre Hyperscale-Datenbank in einem Pool für elastische Datenbanken bereit, um Ressourcen zwischen Datenbanken innerhalb des Pools gemeinsam zu nutzen und die Kosten für mehrere Datenbanken mit unterschiedlichen Nutzungsmustern zu optimieren.

Szenarien für die Verwendung eines Pools für elastische Datenbanken mit Ihren Hyperscale-Datenbanken:

  • Die Computeressourcen, die dem Pool für elastische Datenbanken zugeordnet sind, müssen unabhängig von der Menge des zugeordneten Speichers in einem vorhersehbaren Zeitraum hoch- oder herunterskaliert werden.
  • Die Computeressourcen, die dem Pool für elastische Datenbanken zugeordnet sind, sollen durch Hinzufügen eines oder mehrerer Leseskalierungsreplikate aufskaliert werden.
  • Sie möchten auch bei geringeren Computeressourcen einen hohen Transaktionsprotokolldurchsatz für schreibintensive Workloads verwenden.

Durch die Migration von Nicht-Hyperscale-Datenbanken zu einem Pool für elastische Hyperscale-Datenbanken werden die Datenbanken auf die Hyperscale-Dienstebene aktualisiert.

Aufbau

Traditionell besteht die Architektur einer eigenständigen Hyperscale-Datenbank im Wesentlichen aus drei unabhängigen Komponenten: Compute, Speicher („Seitenserver“) und Protokoll („Protokolldienst“). Wenn Sie einen Pool für elastische Datenbanken für Ihre Hyperscale-Datenbanken erstellen, werden Compute- und Protokollressourcen von den Datenbanken innerhalb des Pools gemeinsam genutzt. Wenn Sie sich zudem für die Konfiguration von Hochverfügbarkeit entscheiden, wird jeder Hochverfügbarkeitspool mit einem gleichwertigen und unabhängigen Satz von Compute- und Protokollressourcen erstellt.

Im Folgenden wird die Architektur eines Pools für elastische Hyperscale-Datenbanken beschrieben:

  • Ein Pool für elastische Hyperscale-Datenbanken besteht aus einem primären Pool, in dem die primären Hyperscale-Datenbanken gehostet werden, und, falls konfiguriert, bis zu vier zusätzlichen Hochverfügbarkeitspools.
  • Primäre Hyperscale-Datenbanken, die im primären Pool für elastische Datenbanken gehostet werden, nutzen den Computeprozess der SQL Server-Datenbank-Engine (sqlservr.exe), virtuelle Kerne, Arbeitsspeicher und SSD-Cache gemeinsam.
  • Durch das Konfigurieren von Hochverfügbarkeit für den primären Pool werden zusätzliche Hochverfügbarkeitspools erstellt, die schreibgeschützte Datenbankreplikate für die Datenbanken im primären Pool enthalten. Jeder primäre Pool kann über maximal vier Pools mit Hochverfügbarkeitsreplikaten verfügen. In jedem Hochverfügbarkeitspool werden Compute-, SSD-Cache- und Arbeitsspeicherressourcen für alle sekundären schreibgeschützten Datenbanken im Pool gemeinsam verwendet.
  • Hyperscale-Datenbanken im primären Pool für elastische Datenbanken nutzen alle denselben Protokolldienst. Da für Datenbanken in den Hochverfügbarkeitspools keine Schreibworkload vorliegt, verwenden sie den Protokolldienst nicht.
  • Jede Hyperscale-Datenbank verfügt über eine eigene Menge an Seitenservern, und diese Seitenserver werden von der primären Datenbank im primären Pool und allen sekundären Replikatdatenbanken im Hochverfügbarkeitspool gemeinsam genutzt.
  • Georeplizierte sekundäre Hyperscale-Datenbanken können in einen anderen Pool für elastische Datenbanken platziert werden.
  • Wenn Sie in Ihrer Datenbankverbindungszeichenfolge ApplicationIntent=ReadOnly angeben, werden Sie an eine schreibgeschützte Replikatdatenbank in einem der Hochverfügbarkeitspools weitergeleitet.

Das folgende Diagramm zeigt die Architektur eines Pools für elastische Hyperscale-Datenbanken:

Diagramm: Architektur von Pools für elastische Hyperscale-Datenbanken

Verwalten von Datenbanken in einem Pool für elastische Hyperscale-Datenbanken

Sie können zum Verwalten von Hyperscale-Datenbanken in einem Pool dieselben Befehle verwenden wie für in einem Pool befindliche Datenbanken der anderen Dienstebenen. Stellen Sie sicher, dass Sie Hyperscale als Edition angeben, wenn Sie Ihren Pool für elastische Hyperscale-Datenbanken erstellen.

Der einzige Unterschied besteht in der Möglichkeit, die Anzahl von Hochverfügbarkeitsreplikaten in einem vorhandenen Pool für elastische Hyperscale-Datenbanken zu ändern. Gehen Sie folgendermaßen vor:

Mithilfe der folgenden Clienttools können Sie Ihre Hyperscale-Datenbanken in einem Pool für elastische Datenbanken verwalten:

Migrieren von Nicht-Hyperscale-Datenbanken zu elastischen Hyperscale-Pools

Beim Migrieren einer Datenbank zu Hyperscale können Sie die Datenbank zu einem vorhandenen elastischen Hyperscale-Pool hinzufügen. Bei diesen Migrationen muss der elastische Hyperscale-Pool auf demselben logischen Server wie die Quelldatenbank vorhanden sein.

Beachten Sie bei der Migration von Datenbanken zu elastischen Hyperscale-Pools die maximale Anzahl von Datenbanken pro elastischem Hyperscale-Pool.

Migrieren von Nicht-Hyperscale-Datenbanken zu elastischen Hyperscale-Pools mit T-SQL

Sie können T-SQL-Befehle verwenden, um mehrere Allgemeine Datenbanken zu migrieren und sie einem vorhandenen elastischen Hyperscale-Pool mit dem Namen 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 diesem Beispiel fordern Sie implizit eine Migration von General Purpose zu Hyperscale an, indem Sie angeben, dass es sich bei dem Ziel SERVICE_OBJECTIVE um einen elastischen Hyperscale-Pool handelt. Jeder der oben genannten Befehle beginnt mit der Migration der jeweiligen Datenbank für allgemeine Zwecke zu Hyperscale. Diese ALTER DATABASE-Befehle kehren schnell zurück und warten nicht, bis die Migration abgeschlossen ist. Im gezeigten Beispiel würden Sie vier solche Migrationen von General Purpose zu Hyperscale parallel ausführen.

Sie können die dynamische Verwaltungsansicht sys.dm_operation_status abfragen, um den Status dieser Hintergrundmigrationsvorgänge zu überwachen.

Migrieren von Nicht-Hyperscale-Datenbanken zu elastischen Hyperscale-Pools mithilfe von PowerShell

Sie können PowerShell-Befehle verwenden, um mehrere Datenbanken mit allgemeinem Zweck zu migrieren und sie einem vorhandenen elastischen Hyperscale-Pool mit dem Namen hsep1hinzuzufügen. Das Beispielskript führt folgende Schritte aus:

  1. Verwenden Sie das Cmdlet Get-AzSqlElasticPoolDatabase, um alle Datenbanken im elastischen Pool „General Purpose“ gpep1 aufzulisten.
  2. Das Cmdlet Where-Object filtert die Liste nur auf diese Datenbanknamen, beginnend mit gpepdb.
  3. Für jede Datenbank startet das Cmdlet Set-AzSqlDatabase eine Migration. In diesem Fall fordern Sie implizit eine Migration zur Hyperscale-Dienstebene an, indem Sie den elastischen Hyperscale-Zielpool mit dem Namen hsep1 angeben.
    • Mit dem Parameter -AsJob können alle Anforderungen Set-AzSqlDatabase parallel ausgeführt werden. Wenn Sie die Migrationen lieber einzeln ausführen möchten, können Sie den Parameter -AsJob entfernen.
$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 }

Zusätzlich zur dynamischen Verwaltungsansicht sys.dm_operation_status können Sie das PowerShell-Cmdlet Get-AzSqlDatabaseActivity verwenden, um den Status dieser Hintergrundmigrationsvorgänge zu überwachen.

Ressourceneinschränkungen

Im Folgenden werden die unterstützten Grenzwerte für die Arbeit mit Hyperscale-Datenbanken in Pools für elastische Datenbanken aufgeführt:

  • Unterstützte Hardware-Generierung: Standardserien (Gen5), Premium-Serie und optimierter Speicher der Premium-Serie.
  • Maximum an virtuellen Kernen pro Pool: 80 oder 128 virtuelle Kerne, je nach Service-Level-Ziel.
  • Maximal unterstützte Datenmenge pro Datenbank: 100 TB.
  • Maximal unterstützte Gesamtdatenmenge für alle Datenbanken im Pool: 100 TB.
  • Maximal unterstützter Transaktionsprotokolldurchsatz pro Datenbank: 100 MB.
  • Maximal unterstützter Transaktionsprotokolldurchsatz insgesamt für alle Datenbanken im Pool: 131,25 MB/Sekunde.
  • Jeder Pool für elastische Hyperscale-Datenbanken bis zu 25 Datenbanken enthalten.

Ausführlichere Informationen finden Sie in den Ressourcengrenzwerten für hyperskalige Pools Pool für elastische Datenbanken fürStandard-Serien, Premium-Serien und speicheroptimiert Premium-Serien.

Hinweis

Leistungsprofile, unterstützte Funktionen und veröffentlichte Grenzwerte können sich während der Vorschauphase des Features ändern. Daher ist es am besten, Ihren Anwendungsfall durch regelmäßige Funktions-, Leistungs- und Skalierungstests von Workloads zu überprüfen.

Begrenzungen

Beachten Sie die folgenden Einschränkungen:

  • Das Ändern eines vorhandenen Pools für elastische Datenbanken ohne Hyperscale in die Hyperscale-Edition wird nicht unterstützt. Der Abschnitt „Migration“ enthält einige Alternativen, die Sie verwenden können.
  • Das Ändern der Edition eines Pools für elastische Hyperscale-Datenbanken in eine Nicht-Hyperscale-Edition wird nicht unterstützt.
  • Um die Migration einer berechtigten Datenbank, die sich in einem Pool für elastische Hyperscale-Datenbanken befindet, rückgängig zu machen, muss diese zuerst aus dem Pool für elastische Hyperscale-Datenbanken entfernt werden. Die eigenständige Hyperscale-Datenbank kann dann wieder zu einer universellen eigenständigen Datenbank zurück migriert werden.
  • Für die Hyperscale-Dienstebene kann die Zonenredundanzunterstützung nur während der Datenbank- oder elastischen Poolerstellung angegeben werden und kann nicht geändert werden, nachdem die Ressource bereitgestellt wurde. Weitere Informationen finden Sie unter Migrieren von Azure SQL Database zur Unterstützung von Verfügbarkeitszonen.
  • Das Hinzufügen eines benannten Replikats in einem Hyperscale-Pool für elastische Datenbanken wird nicht unterstützt. Der Versuch, einem Pool für elastische Hyperscale-Datenbanken ein benanntes Replikat einer Hyperscale-Datenbank hinzuzufügen, führt zu einem UnsupportedReplicationOperation-Fehler. Erstellen Sie stattdessen das benannte Replikat als einzelne Hyperscale-Datenbank.

Überlegungen zu zonenredundanten Pools für elastische Datenbanken

Für zonenredundante Pools für elastische Datenbanken sollten Sie Folgendes beachten:

Hinweis

Zonenredundante Hyperscale Pools für elastische Datenbanken sind verfügbar, derzeit in der Vorschau. Weitere Informationen finden Sie im Blogbeitrag: Zonenredundante Hyperscale Pools für elastische Datenbanken.

  • Nur Datenbanken mit zonenredundanten Speicherredundanz (ZRS oder GZRS) können zonenredundanten Hyperscale Pools für elastische Datenbanken hinzugefügt werden.
  • Eine eigenständige Hyperscale-Datenbank muss mit Zonenredundanz und zonenredundantem Backup-Storage (ZRS oder GZRS) erstellt werden, um sie zu einem zonenredundanten Hyperscale Pool für elastische Datenbanken hinzuzufügen. Bei Hyperscale-Datenbanken ohne Zonenredundanz führen Sie einen Datentransfer zu einer neuen Hyperscale-Datenbank mit aktivierter Zonenredundanz-Option durch. Dabei muss ein Klon muss mit einer Datenbankkopie, einer Point-in-Time-Wiederherstellung oder einem Geo-Replikat erstellt werden. Weitere Informationen finden Sie unter Neueinteilung (Hyperscale).
  • Um eine Hyperscale-Datenbank von einem Pool für elastische Datenbanken in einen anderen zu verschieben, müssen die Einstellungen für die Zonenredundanz und den zonenredundanten Sicherungsspeicher übereinstimmen.
  • So migrieren Sie eine Datenbank von einer anderen Nicht-Hyperscale-Serviceebene in einen zonenredundanten Hyperscale Pool für elastische Datenbanken:
    • Aktivieren Sie zunächst über das Azure-Portal sowohl die Zonenredundanz als auch den zonenredundanten Backup-Speicher (Zone Redundant Backup Storage, ZRS). Dann können Sie die Datenbank zum zonenredundanten Hyperscale Pool für elastische Datenbanken hinzufügen.
    • Aktivieren Sie zunächst über die PowerShell die Zonenredundanz. Stellen Sie dann mit Set-AzSqlDatabase sicher, dass der -BackupStorageRedundancy-Parameter verwendet wird, um zonenredundanten Sicherungsspeicher (ZRS oder GZRS) anzugeben.

Bekannte Probleme

Problem Empfehlung
In seltenen Fällen erhalten Sie möglicherweise den Fehler 45122 - This Hyperscale database cannot be added into an elastic pool at this time. In case of any questions, please contact Microsoft support, wenn Sie versuchen, eine Hyperscale-Datenbank in einen Pool für elastische Datenbanken zu verschieben, wiederherzustellen oder zu kopieren. Diese Einschränkung ist auf implementierungsspezifische Details zurückzuführen. Wenn dieser Fehler Ihre Arbeit blockiert, erstellen Sie einen Supportincident aus, und fordern Sie Unterstützung an.

Zugehöriger Inhalt