Konfigurieren Sie die SQL-Datenbank für den Modus mit Zonenredundanz.

Wenn Sie die Nerdio Manager Anwendung aus dem Azure Marketplace installieren, verwenden der SQL Server und die SQL-Datenbank den S1-Tarif im DTU-basierten Kaufmodell.

Standardmäßig erreicht Azure SQL-Datenbank die Verfügbarkeit durch lokale Redundanz. Die lokal redundante Verfügbarkeit basiert auf der Speicherung Ihrer Datenbank in lokal redundanter Speicher (LRS), der Daten dreimal innerhalb eines einzelnen Rechenzentrums in der primären Region kopiert und Ihre Daten im Falle eines lokalen Fehlers, wie z. B. eines kleineren Netzwerk- oder Stromfehlers, schützt. LRS ist die kostengünstigste Redundanzoption und bietet im Vergleich zu anderen Optionen die geringste Dauerhaftigkeit. Wenn eine großflächige Katastrophe wie ein Feuer oder eine Überschwemmung innerhalb einer Region auftritt, könnten alle Replikate eines Storage-Kontos, das LRS verwendet, verloren gehen oder nicht wiederherstellbar sein. Die standardmäßige Verfügbarkeitslösung wurde entwickelt, um sicherzustellen, dass zugesicherte Daten niemals aufgrund von Fehlern verloren gehen, dass Wartungsvorgänge nur minimale Auswirkungen auf Ihre Workload haben und dass die Datenbank keinen Single Point of Failure in Ihrer Softwarearchitektur darstellt. Um jedoch die Auswirkungen auf Ihre Daten im Falle eines Ausfalls einer gesamten Zone zu minimieren, können Sie durch die Aktivierung der Zonenredundanz eine hohe Verfügbarkeit erreichen. Ohne Zonenredundanz erfolgen Failover lokal innerhalb desselben Rechenzentrums, was dazu führen kann, dass Ihre Datenbank nicht verfügbar ist, bis der Ausfall behoben ist.

Die zonenredundante Verfügbarkeit stellt sicher, dass Ihre Daten über drei Azure-Verfügbarkeitszonen in der primären Region verteilt sind. Jede Verfügbarkeitszone ist ein separater physischer Standort mit unabhängiger Stromversorgung, Kühlung und Netzwerkmanagement.

Die zonenredundante Verfügbarkeit steht für Datenbanken in den Dienstebenen „Unternehmenskritisch“, „Universell“ und „Hyperscale“ des vCore-basierten Kaufmodells sowie nur für die Dienstebene „Premium“ des DTU-basierten Kaufmodells zur Verfügung – die Dienstebenen „Basic“ und „Standard“ unterstützen keine Zonenredundanz. Während jede Dienstebene die Zonenredundanz unterschiedlich implementiert, gewährleisten alle Implementierungen ein Recovery Point Objective (RPO) mit null Verlust zugesicherter Daten bei einem Failover. Die folgende Tabelle zeigt die Verfügbarkeitsoptionen basierend auf den Dienstebenen:

Wenn die Zonenredundanz für die Premium- oder Business Critical-Dienstebene aktiviert ist, werden Replikate in verschiedenen Verfügbarkeitszonen innerhalb derselben Region platziert. Um einen Single Point of Failure zu eliminieren, wird der Steuerungsring ebenfalls über mehrere Zonen hinweg als drei Gateway-Ringe (GW) dupliziert. Das Routing zu einem bestimmten Gateway-Ring wird durch Azure Traffic Manager gesteuert. Da die zonenredundante Konfiguration in den Premium- oder Business Critical-Dienstebenen ihre vorhandenen Replikate für die Platzierung in verschiedenen Verfügbarkeitszonen verwendet, können Sie sie ohne zusätzliche Kosten aktivieren. Durch die Auswahl einer zonenredundanten Konfiguration können Sie Ihre Premium- oder Business Critical-Datenbanken und elastischen Pools widerstandsfähiger gegen ein breiteres Spektrum von Fehlern machen – einschließlich katastrophaler Rechenzentrumsausfälle – ohne dass Änderungen an der Anwendungslogik erforderlich sind. Sie können auch bestehende Premium- oder Business Critical-Datenbanken oder elastische Pools in eine zonenredundante Konfiguration konvertieren.

Die zonenredundante Version der Hochverfügbarkeitsarchitektur wird im folgenden Diagramm veranschaulicht:

Beachten Sie bei der Konfiguration Ihrer Premium- oder Business Critical-Datenbanken mit Zonenredundanz Folgendes:

In Azure SQL-Datenbank ist ein Server ein logisches Konstrukt, das als zentraler Verwaltungspunkt für eine Sammlung von Datenbanken fungiert. Auf Serverebene können Sie Logins, Authentifizierungsmethoden, Firewallregeln, Audit-Regeln, Richtlinien zur Bedrohungserkennung und Failovergruppen verwalten. Daten zu einigen dieser Features, wie z. B. Logins und Firewallregeln, werden in der Master-Datenbank gespeichert. Ebenso werden Daten für einige DMVs, zum Beispiel sys.resource_stats, ebenfalls in der Masterdatenbank gespeichert.

Wenn eine Datenbank mit einer zonenredundanten Konfiguration auf einem logischen Server erstellt wird, wird die mit dem Server verknüpfte Master-Datenbank automatisch ebenfalls zonenredundant gemacht. Dies stellt sicher, dass Anwendungen, die die Datenbank verwenden, bei einem zonalen Ausfall nicht beeinträchtigt werden, da Funktionen, die von der Master-Datenbank abhängen – wie Logins und Firewallregeln – weiterhin verfügbar sind. Das zonenredundante Einrichten der Master-Datenbank ist ein asynchroner Prozess und wird im Hintergrund einige Zeit in Anspruch nehmen.

Wenn keine der Datenbanken auf einem Server zonenredundant ist oder wenn Sie einen leeren Server erstellen, ist die mit dem Server verknüpfte Master-Datenbank nicht zonenredundant.

Sie können Azure PowerShell, die Azure CLI oder die REST-API verwenden, um die Eigenschaft ZoneRedundant für die Master-Datenbank zu überprüfen:

Verwenden Sie den folgenden Beispielbefehl, um den Wert der Eigenschaft ZoneRedundant für die Master-Datenbank zu überprüfen.

Get-AzSqlDatabase -ResourceGroupName \"myResourceGroup\" -ServerName \"myServerName\" -DatabaseName \"master\"

In diesem Beispiel skalieren wir die standardmäßige Nerdio Manager Azure SQL-Datenbank von S1 auf Premium und aktivieren dann die Zonenredundanz. Weitere Informationen zum Skalieren der Datenbank finden Sie unter Skalieren von Einzeldatenbankressourcen in Azure SQL-Datenbank.

So skalieren Sie die SQL-Datenbank auf Premium hoch: