• Artikel

Connect(); Besondere Problem 2018

Band 33, Nummer 13

Azure SQL-Datenbank – Einführung in hochgradig skalierbaren Azure SQL-Datenbank

Durch Kevin Farlee; Besondere Problem 2018

Auf der Ignite-Konferenz haben wir angekündigt, die öffentliche Vorschau von Azure SQL-Datenbank hochgradig skalierbaren, eine neue Speicherarchitektur, die Bereitstellung eine SQL-basierte und hochgradig skalierbare Dienstebene für Datenbanken, die bei Bedarf an Ihrer Workload Anforderungen anpasst. Mit Azure SQL-Datenbank, hochgradig skalierbaren, können Datenbanken schnell automatische Skalierung bis zu 100TB, und Sie müssen vorab bereitstellen Storage-Ressourcen, und das Potenzial für das Wachstum der app erheblich zu erweitern, ohne darauf beschränkt, durch die Speicherplatzgröße.

Hochgradig skalierbaren Azure SQL-Datenbank ist im Vergleich zu aktuellen Azure SQL-Datenbank-Dienstebenen, bietet die folgenden zusätzlichen Funktionen:

  • Unterstützung für 100 TB + Größe der Datenbank
  • Schnelle Skalierung nach oben/unten und Point-in-Time-Wiederherstellung, unabhängig von der Datenbankgröße
  • Weniger Größe-von-Data-Vorgänge
  • Einen höheren Log Durchsatz als aktuelle Dienstebenen
  • Horizontales Skalieren schreibgeschützte Workload mit schreibgeschützten Replikaten ohne Kopieren von Daten

Neue Architektur

Azure SQL-Datenbank hochgradig skalierbaren ist eine grundlegende Neuentwurf der Speicher-Engine in der SQL-Datenbank, die ausgeführt wurde, ohne Änderungen in der Abfrage-Engine, die Abfragen verarbeitet werden und das Verhalten bestimmt. Daher haben wir wichtige neue Funktionen hinzugefügt, ohne alle Kompatibilitätsproblemen.

Die Azure SQL-Datenbank hochgradig skalierbaren Architektur teilt monolithische SQL-Engine in mehreren Microservices, die für die Cloudumgebung entwickelt; Diese Dienste Compute "," Log "und" Speicher zu entkoppeln.

Siehe Abbildung1, Azure SQL-Datenbank hochgradig skalierbaren Modells besteht aus drei Hauptkomponenten:

  • Compute- ist die Abfrage-Engine von SQL Server, der Teil der Datenbank-Engine, die die Abfragelogik ausführt und Kompatibilität mit anderen SQL-Implementierungen als auch Verhalten bestimmt, wenn die Abfrage ausgewertet wird.
  • Seite Server ist eine neue Architektur für horizontales Skalieren zum Speichern der Daten, die von der herkömmlichen Speicher-Engine-Komponente verwendet und teilt den Vorgang in einen Satz horizontaler Dienste, jeweils einen definierten Satz von Datenseiten (nominell insgesamt Datenseiten von 1 TB) verwalten.
  • Melden Sie sich Service ist eine neue Protokollierung-Architektur, die den Datenfluss für Protokolldaten, die sicherstellen, dass die protokollierten Updates der Daten an alle Replikate einer geänderten Seite weitergegeben zu erhalten, und für zukünftige Anforderungen dauerhaft beibehalten verwaltet.

Die neue Azure SQL-Datenbank hochgradig skalierbaren Architektur
Abbildung 1: die neue Azure SQL-Datenbank hochgradig skalierbaren Architektur

Compute-Knoten

Die Compute-Knoten suchen, wie eine herkömmliche SQL Server, jedoch ohne lokale Datendateien oder Protokolldateien. Compute-Knoten sind die "Server", den Anwendungen und Benutzer interagieren mit dem Sie, ob das Aktualisieren der Daten (über den primären Compute-Knoten) oder streng schreibgeschützte Transaktionen über eine der dem lesbaren sekundären Replikat compute-Knoten.

Der primäre Serverknoten Transaktionsprotokoll-Datensätze in der Landungszone, von der Log-Dienst schreibt und Datenseiten von Servern für Seite abgerufen werden, wenn sie in der lokalen Datencache oder einer robusten Buffer Pool Extension (RBPEX) nicht gefunden werden. Dies ist, in dem alle die Ausführungslogik für die Abfrage befindet und dass Logik nicht von anderen SQL-Bereitstellungsmodi ist. Durch Beibehalten dieses obersten Ebene der SQL-Engine größtenteils unverändert, können Sie die vollständige Kompatibilität mit anderen Bereitstellungsmodi SQL warten, und gleichzeitig die revolutionären neuen Funktionen, die die separaten Speicherkomponenten bieten. Da wir die Compute-Knoten, die mit der Abfrage-Engine aus dem Speicher getrennt habe, sind sie effektiv statusfrei sein, was bedeutet, dass Sie einen Compute-Knoten verlieren können, ohne blockiert überhaupt keine Daten. Dies bedeutet auch, dass Sie die computeressourcen hochskalieren zentral können oder nach unten ohne Verschieben von Daten, bietet eine beispiellose Flexibilität für die Skalierung der Ressourcen nach oben oder unten an werden.

Weitere Features für hohe Verfügbarkeit (HA) werde ich später eingehen.

Log-Dienst

Der Ereignisprotokolldienst externalisiert Transaktionsprotokolls einer hochgradig skalierbaren-Datenbank. Die primäre Serverinstanz schreibt die Protokolldatensätze direkt in Azure Premium-Speicher, die von der Log-Dienst verwaltet wird (die "Landing Zone" in Abbildung1). Der Ereignisprotokolldienst ruft Datensätze aus der landungszone und Seite-Server und bei sekundärem computevorgang verfügbar gemacht. Der Ereignisprotokolldienst überträgt auch Protokolldatensätze auf einem kostengünstigeren langfristige Speicherung auf Point-in-Time-Wiederherstellung zu ermöglichen.

Da der landungszone Azure Storage Premium die resilienz und HOCHVERFÜGBARKEIT eingebaut wurde ist, werden Protokolldatensätze dauerhaften und sicheren, sobald sie auf der landungszone geschrieben werden. Mit der vergleichbaren AlwaysOn Availability Gruppen HA-Architektur für lokale SQL Server ein Commit der Transaktion, die an ein Quorum von sekundären Replikaten via-Netzwerkprotokoll gesendet werden muss, und eine Bestätigung empfangen wird, erneut aus, wenn das Quorum der Replikate, bevor die Transaktion abgeschlossen sein, angesehen werden kann, und der Erfolg an die aufrufende Anwendung zurückgegeben. Dies kann zu einen deutlich längeren Zeitraum als mit der hochgradig skalierbaren Architektur dauern. Sie können vollständige HA verwenden, ohne zu warten, für den sekundären Knoten, um den Empfang der Protokolldatensätze zu bestätigen. Dies bedeutet, dass selbst bei vollständigen hohe Verfügbarkeit, End-to-End-Log-Wartezeiten in den 2 ms Bereich. Wenn der Azure-Ultra-SSD-Storage-Technologie verfügbar ist, wird diese Wartezeit von 2.5ms, um 0.4ms remote, voll beständigen und flexiblen datenspeicherung verkleinert.

Abschließend Protokolldatensätze in Azure-Standardspeicher für die langfristige Speicherung beibehalten werden, und der Speicherplatz in der landungszone freigegeben wird. Die Protokolldatensätze in den Azure-Speicher werden beibehalten, solange der Aufbewahrungszeitraum für Sicherungen für die Datenbank konfiguriert werden, daher keine Notwendigkeit besteht, Sicherungen des Transaktionsprotokolls führen. Sie bleiben nur die Protokolldaten online, wodurch Sie aktiv eine unendliche Transaktionsprotokoll (innerhalb der Grenzen des Benutzers konfigurierten Aufbewahrungszeitraum für Sicherungen).

Seite-Server

Die Seite Server hosten und verwalten die Datendateien. Sie nutzen die Protokolldatenstrom vom Protokolldienst und Anwenden von datenänderungen im Protokolldatenstrom auf Datendateien beschrieben. Leseanforderungen von Datenseiten, die im lokalen Datencache oder RBPEX der COMPUTE-Klausel nicht gefunden werden, werden auf der Seite Server weitergeleitet, die die relevanten Seiten besitzen. In der Seite Server werden die Datendateien in Azure Storage beibehalten werden und häufig über eigene RBPEX-SSD-basierte-Caches zwischengespeichert werden.

Jede Seitenserver verwaltet, Seiten, die CA. 1TB an Daten, damit die Seite Server horizontal in Einheiten von etwa 1 TB skaliert werden darstellt. Die Compute-Knoten/Abfrage-Engine jede Seitenserver modelliert, wie ein 1-TB-Data-Datei, dies auf die Seiten-ID (Datei-ID: Seite in der Datei), wissen Sie genau die Seitenserver die angeforderte Seite hostet.

Die Daten für jede Seitenserver ist letzten Endes in Azure Standard Storage beibehalten, die vollständige Stabilität und Verfügbarkeit bietet.  Daher können Sie den Verlust eines Servers für die gesamte Seite überleben, ohne zu riskieren Daten verloren gehen, wie die Daten vollständig aus dem Azure-Speicher verfügbar sind, und Sie können die Seitenserver aus den Daten bei Bedarf vollständig neu erstellen.

Die Daten für jede Seitenserver ist vollständig in seinem eigenen lokalen SSD RBPEX-Cache zwischengespeichert, sodass in Vorgang keine datenanforderung je in Azure Storage sichern die Seitenserver weitergeleitet wird, da es immer aus dem lokalen RBPEX-Cache erfüllt werden kann.

Mehrere Seite Server werden bei einer großen Datenbank erstellt. Wenn die Datenbank wächst, und in vorhandene Seite Server verfügbaren Speicherplatzes unter einen Schwellenwert ist, wird ein neuer Seitenserver in der Datenbank automatisch hinzugefügt. Da die Seite Server unabhängig voneinander arbeiten, können Sie die Datenbank ohne Einschränkungen für die lokale Ressource wachsen.

Hohe Verfügbarkeit und Notfallwiederherstellung (DR)

Automatisches Sichern und Point-in-Time-Wiederherstellung In einer hochgradig skalierbaren-Datenbank, der Datendateien werden Momentaufnahmen von Seite-Servern, die Nutzung von Azure-Blob-Speicherfunktionen in regelmäßigen Abständen, um die traditionellen streaming zu ersetzen Sicherung. Dadurch können Sie eine sehr große Datenbank in nur wenigen Sekunden ohne Auswirkungen auf die zu bewältigende arbeitsauslastung sichern. Zusammen mit der Protokolldatensätze, die in der Log-Dienst gespeichert wird, können Sie die Datenbank zu einem beliebigen Zeitpunkt wiederherstellen, in Zeit während der Aufbewahrung – das ist sieben Tage in der öffentlichen Vorschau und ist konfigurierbar auf bis zu 35 Tage bei allgemeiner Verfügbarkeit (GA) – in kürzester Zeit , unabhängig von der Größe der Datenbank. Daten für jede Seite des Servers ist Snapshot des unabhängig voneinander mit die Momentaufnahmen zu synchronisieren, sodass diese potenzielle Quelle für das verzögerte, auch beseitigt ist nicht unbedingt erforderlich.

Hoch verfügbare Komponenten jede der Komponenten in der Azure SQL-Datenbank hochgradig skalierbaren Architektur soll hochverfügbar sein, damit keine Unterbrechungen Zugriff auf die Datenbank werden:

  • Compute-Knoten haben jeweils über mindestens ein Replikat ausgeführt wird und "Hot" zu jeder Zeit. Das Replikat wird für die primäre Rolle, die Datenbank online und zugänglich bleiben bei einem Ausfall der Compute-Knotens oder ein Failover sofort übernommen. Ein Ersatz-Replikat kann sich sehr schnell gestartet werden, und kann Aufwärmen ihren Cachespeicher als Hintergrundaufgabe ohne Beeinträchtigung der Leistung der Produktion. Andere Replikate können für Lesezwecke für horizontales Skalieren konfiguriert werden. Bei dieser Architektur sind die Serverknoten effizient zustandslos.
  • Seite Server verfügen über ein standby-Replikat online mit ihrem RBPEX-Cache vollständig gefüllt, damit sie übernehmen, für die aktive Seitenserver Ausfall verfügbar sind. Da sie außerhalb von zwischengespeicherten Daten zustandslos sind, kann ein Ersatz in diesem Fall sehr schnell, ohne das Risiko eines Datenverlusts online sein.
  • Der Ereignisprotokolldienst keine hot Standby, aber dies ist nicht notwendig, da der Ereignisprotokolldienst keine zwischengespeicherten Daten hat und kann so schnell, wie Sie ein Failover auf ein standby-Replikat können ersetzt werden. Die Daten, die von der Log-Dienst verwaltet werden befindet sich zunächst in der landungszone, durch die robuste Azure-Premium-Speicher (in Kürze Ultra-SSD-Speicher) und wird schließlich im Azure-Standardspeicher für die langfristige Aufbewahrung beibehalten.

Also, wie Sie sehen können, keine Komponente ist vorhanden, die eine einzelne Fehlerquelle darstellt. Alle Komponenten von hochgradig skalierbaren haben active standbyvorgänge, mit Ausnahme von der Log-Dienst aus, und alle Daten vom vollständig ausfallsicher Azure-Speicher gesichert.

Erstellen Ihre eigene Datenbank hochgradig skalierbaren

Sie können eine neue Datenbank mit Hyperskalierung auf die gleiche Weise erstellen, die Sie alle anderen Azure SQL-Datenbank mit der Microsoft Azure-Portal, PowerShell oder Azure Resource Manager (ARM) erstellen.

Hier zeige ich die Methode zum Erstellen einer hochgradig skalierbaren-Datenbank mithilfe von PowerShell. Beachten Sie, dass dies nicht anders als das standard-Skript für alle Azure SQL-Datenbank mit Ausnahme der Parameters - RequestedServiceObjectiveName erstellen. Im folgenden Beispiel, verwende ich die HS_Gen5_8, die einer hochgradig skalierbaren SQL-Datenbank ist auf der Generation 5-Hardware, mit acht Kernen. Wenn Sie bereits eine Ressourcengruppe und den logischen Server verfügen, können Sie natürlich die Teile des Skripts überspringen.

Sie müssen zunächst besteht darin, Azure Cloud Shell zu starten. Cloudshell ist eine kostenlose interaktive Shell, mit denen Sie die Schritte in diesem Artikel ausführen. Allgemeine Tools vorinstalliert und für die Verwendung mit Ihrem Konto konfiguriert hat. Sie können einfach auf die Schaltfläche "Kopieren", kopieren Sie den Code, und dann fügen den Code in die Cloud Shell klicken, und drücken Sie die EINGABETASTE für die Ausführung.

Es gibt eine Reihe von Möglichkeiten, um Cloud Shell zu starten. Zwischen der einfachste beziehen sich auf beiden open Cloud Shell in Ihrem Browser auf shell.azure.com/powershell und Schaltfläche oder durch Klicken auf die Cloud Shell Schaltfläche oben rechts auf der Azure-Portal im Menü auf die Cloud Shell starten. Ich empfehle, dass Sie die zweite Methode verwenden. Melden Sie sich beim Azure-Portal auf unter "Portal.Azure.com" mit dem Konto, das Zugriff auf Ihr Azure-Abonnement verfügt. Klicken Sie dann auf den Link klicken, siehe abbildung2.

Starten Cloudshell über das Azure-Portal
Abbildung 2 Starten von Cloudshell über das Azure-Portal

Anschließend können Sie das Skript in einfügen Abbildung 3 in Cloud Shell-Fensters und ausführen, um eine Ressourcengruppe, einen logischen SQL-Server und einer Datenbank zu erstellen. Beachten Sie, dass der Name der Ressourcengruppe "MyResourceGroup"– plus eine zufällige Zahl ist, z. B. "MyResourceGroup-2088327474." festgelegt ist Andere Objekte werden auf ähnliche Weise benannt. Allerdings können Sie diese Namen anpassen, wenn es einfacher ist.

Abbildung 3: Erstellen einer Ressourcengruppe, logischen SQL-Server und Datenbank

# Set the resource group name and location for your server
$resourcegroupname = "myResourceGroup-$(Get-Random)"
$location = "westus2"
# Set an admin login and password for your server
$adminlogin = "ServerAdmin"
$password = "ChangeYourAdminPassword1"
# Set server name - the logical server name has to be unique in the system
$servername = "server-$(Get-Random)"
# The sample database name
$databasename = "mySampleDatabase"
# The IP address range that you want to allow to access your server
$startip = "0.0.0.0"
$endip = "0.0.0.0"
# Create a resource group
$resourcegroup = New-AzureRmResourceGroup -Name $resourcegroupname -Location $location
# Create a server with a system-wide unique server name
$server = New-AzureRmSqlServer -ResourceGroupName $resourcegroupname `
  -ServerName $servername `
  -Location $location `
  -SqlAdministratorCredentials $(New-Object -TypeName
    System.Management.Automation.PSCredential -ArgumentList $adminlogin,
    $(ConvertTo-SecureString -String $password -AsPlainText -Force))
# Create a server firewall rule that allows access from the specified IP range
$serverfirewallrule = New-AzureRmSqlServerFirewallRule
  -ResourceGroupName $resourcegroupname `
    -ServerName $servername `
    -FirewallRuleName "AllowedIPs" -StartIpAddress $startip -EndIpAddress $endip
# Create a blank database with the Hyperscale, Gen5, two-core performance level
$database = New-AzureRmSqlDatabase  -ResourceGroupName $resourcegroupname `
  -ServerName $servername `
  -DatabaseName $databasename `
  -RequestedServiceObjectiveName "HS_Gen5_2" `
  -SampleName "AdventureWorksLT"
Echo $servername
# Clean up deployment
# Remove-AzureRmResourceGroup -ResourceGroupName $resourcegroupname

Im Skript wird der Server in der Region WestUS2 erstellt. Zu diesem Zeitpunkt ist hochgradig skalierbaren nicht in allen Azure-Regionen verfügbar, so können Sie bewahren Sie sie an WestUS2, die aktiv ist, und versuchen Sie es einer anderen Region. Wenn Sie eine Fehlermeldung, die erhalten die "die angegebene Edition ist nicht verfügbar. Wählen Sie eine andere Edition,"bedeutet dies, dass die Region für das ausgewählte Abbild Hyperskalierung noch nicht aktiviert wurde. Sie können entweder versuchen Sie es einer anderen Region oder WestUS2 verwenden.

Ein anderes Objekt, das für Sie konfiguriert ist, ist die Firewall-Regel, die Zugriff auf Ihren Server gewährt. Das Beispielskript legt die Start-IP und End-IP auf 0.0.0.0, die Zugriff nicht zulässt. Sie können die Adresse für den bestimmten Computer hinzufügen, suchen dem neuen Server im Portal, klicken auf "Firewall-Einstellungen anzeigen", und klicken Sie dann auf "Add-Client-IP," das Hinzufügen eine Firewallregel, die Ihrem aktuellen Computer für die Verbindung mit der Datenbank ermöglicht.

Nachdem Ihre Datenbank und Server erstellt werden und die Firewall-Regeln werden angepasst, können Sie mit Ihrer Datenbank mithilfe von SQL Server Management Studio (SSMS) verbinden. Das Skript gibt den Namen, die, den Sie mit der SQL Server zugewiesen. Fügen Sie einfach ". database.windows.net" an den Servernamen, wenn Sie eine Verbindung herstellen. Der Benutzername und Kennwort sind in diesem Skript enthalten (natürlich, Sie können und in etwas, das nur Sie kennen sollten ändern). An diesem Punkt sind Sie in die neue Datenbank mit Hyperskalierung verbunden.

Andere Methoden zum Erstellen von hochgradig skalierbaren Azure SQL-Datenbanken finden Sie unter bit.ly/2QoTLbj.

Die Datenbank der nächsten Generation-Architektur

Mit diesen kurzen Überblick haben Sie gelernt, dass Azure SQL-Datenbank hochgradig skalierbaren eine revolutionäre neue Architektur mit den eindeutigen Vorteil, dass vollständige Kompatibilität mit früheren Generationen von SQL-Engines bereitstellt. Azure SQL-Datenbank hochgradig skalierbaren ist wirklich clouddaten und bietet erhebliche Vorteile in Skalierung, Leistung und verwaltbarkeit. Allgemeine Größe-von-Data-Vorgänge Gerätetreiberschnittstellen einzufügen, ist es sehr große Datenbank (VLDB)-Funktionen ohne die typische VLDB schwierigkeiten bieten können. Weitere Informationen finden Sie auf der Seite "Hyperscale Service Tier (Vorschau) für bis zu 100TB" unter bit.ly/2TTJkeK.

Kevin Farleeverfügt über mehr als 30 Jahre in der Branche, bei der sowohl die Datenbank als auch die Speicher-Management-Software. In seiner derzeitigen Rolle als den Prinzipal Programmmanager im Team von Microsoft SQL-Datenbank wird er aufgerufen, bei der Entwicklung die Hyperscale VLDB-Features von Azure SQL-Datenbank.

Unser Dank gilt den folgenden technischen Experten von Microsoft für die Durchsicht dieses Artikels: Alain Dormehl, Xiaochen Wu
Alain Dormehl ist Senior Program Manager im Azure SQL-Datenbank-Team bei Microsoft und lebt in Redmond. Er war in verschiedenen Rollen bei Microsoft und ist im Moment Feature und Produktentwicklung für Azure SQL-Datenbanken. Er verfügt über zehn Jahre Erfahrung mit SQL Server und war ein Erstanwender und Evangelist für Azure. Folgen Sie ihm auf Twitter @APSolutely

Xiaochen Wu ist senior Programmmanager für SQL-Team bei Microsoft. Er hat verschiedene Funktionen und Produkten in SQL Server und Azure SQL-Datenbanken in den vergangenen 10 Jahren gearbeitet. Folgen Sie ihm auf Twitter @allenwux

Diesen Artikel im MSDN Magazine-Forum diskutieren