Hyperscale-Architektur mit verteilten Funktionen
Gilt für: 
Azure SQL-Datenbank
Die Hyperscale-Dienstebene nutzt eine Architektur mit hoch skalierbaren und separaten Speicher- und Berechnungsebenen. In diesem Artikel werden die Komponenten beschrieben, die es Kunden ermöglichen, Hyperscale-Datenbanken schnell zu skalieren und dabei von nahezu sofortigen Sicherungen und hochgradig skalierbarer Transaktionsprotokollierung zu profitieren.
Tipp
Vereinfachte Preise für SQL-Datenbank Hyperscale ab Dezember 2023. Ausführlichere Informationen dazu finden Sie im Hyperscale-Preisblog.
Hyperscale-Architektur: Übersicht
Herkömmliche Datenbank-Engines zentralisieren Datenverwaltungsfunktionen in einem einzigen Prozess: Auch sogenannte verteilte Datenbanken in der Produktion verfügen heute über mehrere Kopien eines monolithischen Datenmoduls.
Hyperscale-Datenbanken verfolgen einen anderen Ansatz. Hyperscale trennt die Abfrageverarbeitungs-Engine, in der die Semantik der verschiedenen Datenmodulen divergiert, von den Komponenten, die für die langfristige Speicherung und Dauerhaftigkeit der Daten sorgen. Auf diese Weise kann die Speicherkapazität nahtlos nach Bedarf horizontal hochskaliert werden. Der anfänglich unterstützte Speichergrenzwert beträgt 100 TB.
Die gesamte Netzwerkkommunikation zwischen Hyperscale-Komponenten verwendet die Azure-Netzwerkinfrastruktur mit integrierter Redundanz.
Sekundäre Hochverfügbarkeitsreplikate und benannte Replikate sind optionale Serverknoten, die bei Bedarf hinzugefügt werden können. Beide nutzen dieselben Speicherkomponenten gemeinsam, daher ist keine Datenkopie erforderlich, um ein neues Replikat zu starten. Ein sekundäres Georeplikat kann bei Bedarf in derselben oder einer anderen Azure-Region hinzugefügt werden. Aus Gründen des Datenschutzes und der Redundanz verfügen sekundäre Georeplikate über Speicherkomponenten, die von denen getrennt sind, die vom primären Replikat verwendet werden.
Die folgende Abbildung veranschaulicht die funktionale Hyperscale-Architektur:
Eine Hyperscale-Datenbank enthält die folgenden Komponententypen: Computeknoten, Seitenserver, Protokolldienst und Azure-Speicher.
Compute
Die relationale Engine befindet sich auf dem Computeknoten. Im Computeknoten erfolgt die Sprach-, Abfrage- und Transaktionsverarbeitung. Alle Benutzerinteraktionen mit einer Hyperscale-Datenbank erfolgen über Computeknoten. Serverknoten können entweder für die Verwendung von serverlosem oder bereitgestelltem Computing konfiguriert werden.
Serverknoten verfügen über lokale SSD-basierte Caches, die als Resilient Buffer Pool Extension (RBPEX-Datencache) bezeichnet werden. Der RBPEX-Datencache ist ein intelligenter Datencache mit geringer Latenz, der die Notwendigkeit minimiert, Daten von Remoteseitenservern abzurufen.
Hyperscale-Datenbanken verfügen über einen primären Computeknoten, auf dem die Lese-/Schreibworkload und Transaktionen verarbeitet werden. Bei Bedarf können bis zu vier sekundäre Hochverfügbarkeits-Serverknoten hinzugefügt werden. Sie fungieren als Hot Standby-Knoten für Failover-Zwecke und können als schreibgeschützte Serverknoten dienen, um Lese-Workloads bei Bedarf auszulagern. Bei benannten Replikaten handelt es sich um sekundäre Serverknoten, die für eine Reihe zusätzlicher OLTP-Szenarien mit Leseskalierung und zur besseren Unterstützung von HTAP-Workloads (Hybrid Transactional and Analytical Processing) entwickelt wurden. Ein geo-sekundärer Serverknoten kann für Notfallwiederherstellungszwecke und als schreibgeschützter Serverknoten zum Auslagern von Leseworkloads in eine andere Azure-Region hinzugefügt werden.
Bei serverlosen Konfigurationen werden das primäre Replikat und alle Hochverfügbarkeitsreplikate oder benannten Replikate je nach Nutzung unabhängig voneinander skaliert. Der Umfang für die automatische Computeskalierung für das primäre Replikat und die benannten Replikate werden unabhängig voneinander konfiguriert. Der Umfang für die automatische Skalierung von Hochverfügbarkeitsreplikaten wird von der Konfiguration für die automatischen Skalierung geerbt, die durch das zugeordnete primäre Replikat oder das benannte Replikat angegeben wird.
Die Datenbank-Engine, die auf Hyperscale-Computeknoten ausgeführt wird, ist die gleiche wie bei anderen Azure SQL-Datenbank-Dienstebenen. Wenn Benutzer mit der Datenbank-Engine auf Hyperscale-Computeknoten interagieren, sind unterstützte Oberfläche und Engine-Verhalten identisch mit denen in anderen Dienstebenen mit Ausnahme von bekannten Einschränkungen.
Seitenserver
Seitenserver sind Systeme, die eine horizontale hochskalierte Speicher-Engine darstellen. Jeder Seitenserver ist für eine Teilmenge der Seiten in der Datenbank zuständig. Jeder Seitenserver verfügt auch über ein Replikat, das für Redundanz und Verfügbarkeit bereitgestellt wird.
Die Aufgabe eines Seitenservers besteht darin, Datenbankseiten nach Bedarf für die Computeknoten bereitzustellen und die Seiten auf dem neuesten Stand zu halten, wenn die Daten in Transaktionen aktualisiert werden. Seitenserver werden durch die Wiedergabe von Transaktionsprotokoll-Datensätzen aus dem Protokolldienst auf dem aktuellen Stand gehalten.
Außerdem verwalten Seitenserver abdeckende SSD-basierte Caches zum Verbessern der Leistung. Eine langfristige Speicherung von Datenseiten erfolgt in Azure Storage, um Dauerhaftigkeit zu gewährleisten.
Protokolldienst
Der Protokolldienst akzeptiert Transaktionsprotokolldatensätze, die Datenänderungen aus dem primären Computereplikat entsprechen. Seitenserver erhalten dann die Protokolldatensätze vom Protokolldienst und wenden die Änderungen auf ihre jeweiligen Datenslices an. Darüber hinaus erhalten sekundäre Computereplikate Protokolldatensätze vom Protokolldienst und geben nur die Änderungen für Seiten wieder, die bereits im Pufferpool oder im lokalen RBPEX-Cache vorhanden sind. Alle Datenänderungen werden vom primären Computereplikat über den Protokolldienst an alle sekundären Computereplikate und Seitenserver weitergegeben.
Schließlich werden die Transaktionsprotokoll-Datensätze per Push in den langfristigen Speicher in Azure Storage übertragen. Hierbei handelt es sich um ein praktisch unbegrenztes Speicherrepository. Durch diesen Mechanismus entfällt die Notwendigkeit einer häufigen Protokollkürzung. Die häufigsten Gründe für das Protokollwachstum wie verpasste Protokollsicherungen oder langsame Datenreplikation auf sekundäre Replikate gelten nicht für Hyperscale. Der Protokolldienst weist lokale Arbeitsspeicher- und SSD-Caches auf, um den Zugriff auf Protokolldatensätze zu beschleunigen.
Azure Storage
Azure Storage enthält alle Datendateien in einer Datenbank. Seitenserver halten Datendateien in Azure Storage auf dem neuesten Stand. Dieser Speicher wird auch für Sicherungszwecke verwendet und kann basierend auf der Auswahl der Speicherredundanz zwischen Regionen repliziert werden.
Sicherungen werden mithilfe von Speichermomentaufnahmen von Datendateien implementiert. Wiederherstellungsvorgänge mithilfe von Momentaufnahmen sind unabhängig von der Datengröße schnell. Eine Datenbank kann an jedem beliebigen Zeitpunkt innerhalb des Aufbewahrungszeitraums der Sicherung wiederhergestellt werden.
Hyperscale unterstützt das Konfigurieren der Speicherredundanz. Beim Erstellen einer Hyperscale-Datenbank können Sie aus den folgenden Typen von Azure Storage Standard wählen:
- Lokal redundanter Speicher (LRS)
- Zonenredundanter Speicher (ZRS)
- Georedundanter Speicher mit Lesezugriff (RA-GRS)
- Geozonenredundanter Speicher mit Lesezugriff (RA-GZRS)
Zonenredundante Speicheroptionen sind in Azure-Regionen mit Verfügbarkeitszonen verfügbar.
Die ausgewählte Speicherredundanzoption wird während der gesamten Lebensdauer der Datenbank sowohl für die Datenspeicherredundanz als auch für die Sicherungsspeicherredundanz verwendet.