Hyperscale-Dienstebene

Gilt für: Azure SQL-Datenbank

Azure SQL-Datenbank basiert auf der an die Cloudumgebung angepasste Architektur der SQL Server-Datenbank-Engine, um Hochverfügbarkeit selbst bei Infrastrukturausfällen sicherzustellen. Im vCore-Kaufmodell für Azure SQL-Datenbank gibt es drei Optionen für die Dienstebene:

• Allgemeiner Zweck‭
• Unternehmenskritisch
• Hyperscale

Die Dienstebene „Hyperscale“ ist für alle Workloadtypen geeignet. Die cloudnative Architektur bietet unabhängig skalierbare Compute- und Speicherressourcen, um die verschiedensten traditionellen und modernen Anwendungen zu unterstützen. Auf der Dienstebene „Hyperscale“ sind mehr Compute- und Speicherressourcen als auf den Dienstebenen „Universell“ oder „Unternehmenskritisch“ verfügbar.

Ausführliche Informationen zu den Dienstebenen „Universell“ und „Unternehmenskritisch“ im vCore-basierten Kaufmodell finden Sie in den Dienstebenen Universell und Unternehmenskritisch. Einen Vergleich zwischen vCore-basiertem Kaufmodell und DTU-basiertem Kaufmodell finden Sie unter Vergleich der vCore- und DTU-basierten Kaufmodelle – Azure SQL-Datenbank.

Die Hyperscale-Dienstebene ist derzeit nur für Azure SQL-Datenbank und nicht für Azure SQL Managed Instance verfügbar.

Welche Funktionen bietet Hyperscale?

Die Dienstebene „Hyperscale“ in Azure SQL-Datenbank bietet folgende zusätzliche Funktionen:

• Schnelle Hochskalierung: Sie können Ihre Computeressourcen in konstanter Zeit hochskalieren, um hohe Workloads nach Bedarf zu bewältigen, und anschließend wieder herunterskalieren, sobald sie nicht mehr benötigt werden.
• Schnelle Aufskalierung: Sie können ein oder mehrere schreibgeschützte Replikate zum Abladen Ihrer Leseworkload und zur Verwendung als unmittelbar betriebsbereite Standbyserver bereitstellen.
• Automatisches Hochskalieren, Herunterskalieren und automatische Abrechnung für Compute basierend auf der Nutzung mit serverlosem Compute.
• Optimiertes Preis-Leistungs-Verhältnis für eine Gruppe von Hyperscale-Datenbanken mit unterschiedlichen Ressourcenanforderungen mit Pools für elastische Datenbanken.
• Automatischer Speicher mit Unterstützung für eine Datenbank mit bis zu 128 TB oder 100 TB flexible Poolgröße.
• Höhere Gesamtleistung aufgrund eines höheren Transaktionsprotokolldurchsatzes und schnellerer Transaktionscommits unabhängig von Datenmengen.
• Schnelle Datenbanksicherungen (basierend auf Dateimomentaufnahmen) unabhängig von der Größe und ohne E/A-Auswirkung auf Compute-Ressourcen.
• Schnelle Datenbankwiederherstellungen oder -kopien (basierend auf Dateimomentaufnahmen) in Minuten statt Stunden oder Tagen

Die Dienstebene „Hyperscale“ beseitigt viele praktische Einschränkungen, die normalerweise für Clouddatenbanken gelten. Während die meisten anderen Datenbanken durch die auf einem einzelnen Knoten verfügbaren Ressourcen eingeschränkt werden, gelten in der Dienstebene „Hyperscale“ keine solchen Limits. Aufgrund der flexiblen Speicherarchitektur wächst der Speicher nach Bedarf. Hyperscale-Datenbanken werden ohne Definition einer maximalen Größe erstellt. Eine Hyperscale-Datenbank wächst nach Bedarf – und Ihnen wird nur die tatsächlich verwendete Speicherkapazität in Rechnung gestellt. Für leseintensive Workloads bietet die Dienstebene „Hyperscale“ eine schnelle horizontale Skalierung, indem nach Bedarf zusätzliche Replikate zur Abladung von Leseworkloads bereitgestellt werden.

Darüber hinaus ist die Zeit, die zum Erstellen von Datenbanksicherungen oder zum Hoch- oder Herunterskalieren erforderlich ist, nicht mehr an die Menge der Daten in der Datenbank gebunden. Hyperscale-Datenbanken werden praktisch sofort gesichert. Sie können eine Datenbank auch innerhalb weniger Minuten in Schritten von jeweils 10 Terabyte auf der bereitgestellten Computeebene hoch- oder herunterskalieren oder serverlos verwenden, um Compute automatisch zu skalieren. Durch diese Funktion müssen Sie nicht befürchten, durch Ihre Auswahl bei der Anfangskonfiguration eingeschränkt zu werden.

Weitere Informationen zu den Computegrößen für die Dienstebene „Hyperscale“ finden Sie unter Merkmale der Dienstebene.

Wer sollte die Dienstebene „Hyperscale“ in Betracht ziehen?

Die Dienstebene „Hyperscale“ ist für all jene Kunden geeignet, die eine höhere Leistung und Verfügbarkeit, eine schnelle Sicherung und Wiederherstellung und/oder eine schnelle Skalierbarkeit von Speicher und Compute benötigen. Hierzu zählen Kunden, die zur Modernisierung ihrer Anwendungen in die Cloud wechseln, sowie Kunden, die bereits andere Dienstebenen in Azure SQL-Datenbank verwenden. Die Hyperscale-Dienstebene unterstützt eine breite Palette von Datenbankworkloads, von reinem OLTP bis hin zu reinen Analysen. Sie ist für OLTP- und Hybridtransaktions- und Analyseverarbeitungsworkloads (HTAP) optimiert.

Preismodell für „Hyperscale“

Die Dienstebene „Hyperscale“ ist nur im V-Kern-Modell verfügbar. In Anpassung an die neue Architektur ist das Preismodell etwas anders gestaltet als bei den Dienstebenen „Universell“ oder „Unternehmenskritisch“:

• Bereitgestelltes Computing:

  Der Preis für Compute-Einheiten bei „Hyperscale“ ist pro Replikat. Benutzer könnten die Gesamtzahl der sekundären Replikate mit hoher Verfügbarkeit von 0 bis 4 anpassen, je nach Verfügbarkeits- und Skalierbarkeitsanforderungen, und erstellen Sie bis zu 30 benannte Replikate, um eine Vielzahl von Skalierungs-Workloads zu unterstützen.

• Serverloses Computing:

  Die Abrechnung für serverloses Computing basiert auf der Nutzung. Weitere Informationen finden Sie unter Serverlose Computingebene für Azure SQL-Datenbank.

• Storage:

  Beim Konfigurieren einer Hyperscale-Datenbank müssen Sie keine maximale Datengröße angeben. Im Hyperscale-Tarif werden Gebühren für den Speicher Ihrer Datenbank basierend auf der tatsächlichen Zuordnung berechnet. Speicher wird automatisch zwischen 10 GB und 128 TB zugewiesen und erhöht sich bei Bedarf in 10-GB-Schritten.

Weitere Informationen zu den Hyperscale-Preisen finden Sie unter Preise für Azure SQL-Datenbank.

Architektur mit verteilten Funktionen

Hyperscale trennt das Abfrageverarbeitungsmodul von den Komponenten, die langfristige Speicherung und Dauerhaftigkeit für die Daten bereitstellen. Diese Architektur ermöglicht es Ihnen, die Speicherkapazität so weit wie nötig (bis zu 128 TB) problemlos zu skalieren und auch die Computeressourcen schnell zu skalieren.

Die folgende Abbildung veranschaulicht die funktionale Hyperscale-Architektur:

Erfahren Sie mehr über die Hyperscale-Architektur mit verteilten Funktionen.

Skalierungs- und Leistungsvorteile

Mit der Möglichkeit, weitere Computeknoten schnell hoch- bzw. herunterzufahren, erlaubt die Hyperscale-Architektur eine erhebliche horizontale Leseskalierung und kann außerdem den primären Computeknoten freigeben, um weitere Schreibanforderungen zu verarbeiten. Darüber hinaus können die Computeknoten aufgrund der Hyperscale-Architektur mit freigegebenem Speicher schnell zentral hoch- oder herunterskaliert werden. Schreibgeschützte Computeknoten in Hyperscale sind auch auf der Ebene für serverloses Computing verfügbar, die den Computevorgang automatisch basierend auf der Workloadanforderungen skaliert.

Hochverfügbarkeit von Datenbanken in Hyperscale

Wie bei allen anderen Dienstebenen gewährleistet Hyperscale die Dauerhaftigkeit von Daten für committete Transaktionen unabhängig von der Verfügbarkeit des Computereplikats. Das Ausmaß der Ausfallzeiten aufgrund der Nichtverfügbarkeit des primären Replikats hängt von der Art des Failovers (geplant oder ungeplant), von einer eventuellen Konfiguration der Zonenredundanz und vom Vorhandensein mindestens eines Replikats mit Hochverfügbarkeit ab. Bei einem geplanten Failover (z. B. bei einem Wartungsereignis) erstellt das System entweder das neue primäre Replikat, bevor ein Failover initiiert wird, oder es verwendet ein vorhandenes Hochverfügbarkeitsreplikat als Failoverziel. Bei einem ungeplanten Failover (z. B. bei einem Hardwarefehler auf dem primären Replikat) verwendet das System ein Hochverfügbarkeitsreplikat als Failoverziel (sofern vorhanden), oder es erstellt ein neues primäres Replikat aus dem Pool der verfügbaren Computekapazität. Im letzteren Fall ist die Dauer der Ausfallzeit länger, da zusätzliche Schritte erforderlich sind, um das neue primäre Replikat zu erstellen.

Sie können ein Wartungsfenster auswählen, mit dem Sie wirkungsvolle Wartungsereignisse vorhersehbar und weniger störend für Ihre Workload machen können.

Weitere Informationen zur Hyperscale-SLA finden Sie unter SLA für Azure SQL-Datenbank.

Pufferpool, ausfallsichere Pufferpoolerweiterung und kontinuierliche Vorbereitung

In Azure Database Hyperscale gibt es eine klare Trennung zwischen Compute und Speicher. Der Speicher enthält alle Datenbankseiten in einer Datenbank und kann auf mehreren Computern zugeordnet werden, wenn die Datenbank wächst. Der Computeknoten speichert jedoch nur zwischen, was kürzlich verwendet wurde. Die heißesten Seiten in der Berechnung werden im Arbeitsspeicher in einer Struktur namens Pufferpool (BP) verwaltet. Sie werden auch auf der lokalen SSD gespeichert, der ausfallsicheren Pufferpoolerweiterung (RBPEX), sodass Daten schneller abgerufen werden können, wenn der Computeprozess neu gestartet wird.

In einem Cloudsystem kann Compute bei Bedarf zu verschiedenen Computern wechseln. Die Computeebene kann über mehrere Replikate verfügen. Eines ist primär und empfängt alle Updates, während andere sekundäre Replikate sind. Im Falle eines primären Fehlers können sekundäre Replikate mit Hochverfügbarkeit schnell höhergestuft werden; dieser Prozess nennt sich Failover. Das sekundäre Replikat verfügt möglicherweise nicht über einen Cache im BP und RBPEX, der für die primäre Workload optimiert ist.

Die kontinuierliche Vorbereitung ist ein Prozess, der Informationen darüber sammelt, welche Seiten in allen Computereplikaten am heißesten sind. Diese Informationen werden aggregiert, und sekundäre Replikate mit Hochverfügbarkeit verwenden die Liste der heißesten Seiten, die der typischen Kundenworkload entsprechen. Auf diese Weise werden sowohl der BP als auch der RBPEX kontinuierlich mit den aktuellsten Seiten gefüllt, um mit den Änderungen der Kundenworkload Schritt zu halten.

Ohne kontinuierliche Vorbereitung werden der BP und RBPEX nicht von neuen Hochverfügbarkeitsreplikaten geerbt und nur während der Benutzerworkload wieder aufgebaut. Die kontinuierliche Vorbereitung spart Zeit und verhindert eine inkonsistente Leistung, da es keine Wartezeit gibt, bevor die Caches wieder vollständig hydriert werden. Mit der kontinuierlichen Vorbereitung beginnen neue sekundäre Replikate mit Hochverfügbarkeit sofort mit der Vorbereitung ihres BP und RBPEX. Dies trägt dazu bei, die Leistung bei Ausfällen konstant zu halten.

Die kontinuierliche Vorbereitung funktioniert in beide Richtungen: Sekundäre Hochverfügbarkeitsreplikate speichern Seiten, die im primären Replikat verwendet werden, und die primären speichern Seiten mit der Workload aus den sekundären Replikaten zwischen.

Sicherung und Wiederherstellung

Sicherungs- und Wiederherstellungsvorgänge für Hyperscale-Datenbanken basieren auf Dateimomentaufnahmen. Dadurch können diese Vorgänge nahezu sofort durchgeführt werden. Da die Hyperscale-Architektur die Speicherebene für Sicherung und Wiederherstellung nutzt, werden die Verarbeitungslast und die Auswirkungen auf die Leistung der Computereplikate verringert. Weitere Informationen finden Sie unter Hyperscale-Sicherungen und Speicherredundanz.

Notfallwiederherstellung für Hyperscale-Datenbanken

Wenn Sie im Rahmen der Wiederherstellung einer Hyperscale-Datenbank in Azure SQL-Datenbank im Notfall oder im Rahmen einer Übung, wegen eines Umzugs oder aus einem sonstigen Grund in einer anderen Region wiederherstellen müssen als der, in der sie gerade gehostet wird, besteht die primäre Methode in einer Geowiederherstellung der Datenbank. Die Geowiederherstellung ist nur verfügbar, wenn georedundanter Speicher (RA-GRS) für die Speicherredundanz ausgewählt wurde.

Weitere Informationen finden Sie unter Wiederherstellen einer Hyperscale-Datenbank in einer anderen Region.

Vergleichen von Ressourcengrenzwerten

Die auf virtuellen Kernen basierenden Dienstebenen unterscheiden sich im Hinblick auf Datenbankverfügbarkeit, Speichertyp, Leistung und maximaler Speichergröße. Die Unterschiede werden in der folgenden Tabelle beschrieben:

¹ Vereinfachte Preise für SQL-Datenbank-Hyperscale ab Dezember 2023. Ausführlichere Informationen dazu finden Sie im Hyperscale-Preisblog.

² Ab Dezember 2023 ist Azure-Hybridvorteil nicht mehr für neue Hyperscale-Datenbanken oder in Dev-/Test-Subscriptions verfügbar. Bestehende Hyperscale Single-Datenbanken mit bereitgestellter Berechnung können Azure-Hybridvorteil weiterhin nutzen, um bis Dezember 2026 Berechungskosten zu sparen. Weitere Informationen finden Sie im Blog zu den Hyperscale Preisen.

Computeressourcen

¹ In der dynamischen Verwaltungssicht sys.dm_user_db_resource_governance wird die Hardwaregeneration für Datenbanken mit Intel® SP-8160-Prozessoren (Skylake) als „Gen6“ angezeigt. Die Hardwaregeneration für Datenbanken mit Intel® 8272CL-Prozessoren (Cascade Lake) wird als „Gen7“ angezeigt. Und die Hardwaregeneration für Datenbanken mit Intel® Xeon® Platinum 8370C (Ice Lake) oder AMD® EPYC® 7763v (Milan) wird als „Gen8“ angezeigt. Bei einer bestimmten Computegröße und Hardwarekonfiguration sind die Ressourcengrenzwerte unabhängig vom CPU-Typ identisch. Informationen zu Ressourcengrenzwerten für Singletons finden Sie hier, und Informationen zu Ressourcengrenzwerten für Pools für elastische Datenbanken finden Sie hier.

Serverlos wird nur auf Hardware der Standardserie (Gen5) unterstützt.

Erstellen und Verwalten von Hyperscale-Datenbanken

Sie können Hyperscale-Datenbanken mithilfe des Azure-Portals, mit Transact-SQL, PowerShell und der Azure CLI erstellen und verwalten. Weitere Informationen finden Sie unter Schnellstart: Erstellen einer Hyperscale-Datenbank.

Verkleinern

Vorgänge zur Verkleinerung von Datenbanken und Dateien befinden sich für Azure SQL-Datenbank Hyperscale derzeit in der Vorschau. Weitere Informationen zur Vorschau finden Sie unter Verkleinern für Azure SQL-Datenbank Hyperscale.

Bekannte Einschränkungen

Hierbei handelt es sich um die aktuellen Einschränkungen der Hyperscale-Dienstebene. Wir arbeiten daran, möglichst viele dieser Einschränkungen zu beseitigen.

Zugehöriger Inhalt

• Häufig gestellte Fragen zu Hyperscale
• vCore- und DTU-basierte Kaufmodelle von Azure SQL-Datenbank im Vergleich
• Ressourcenverwaltung in Azure SQL-Datenbank
• Ressourcenlimits für Singletons mit dem auf virtuellen Kernen (V-Kernen) basierenden Kaufmodell
• Featurevergleich: Azure SQL-Datenbank und Azure SQL Managed Instance
• Hyperscale-Architektur mit verteilten Funktionen
• Verwalten einer Hyperscale-Datenbank