Freigeben über

Dynamische Skalierung von Datenbankressourcen mit minimaler Ausfallzeit - Azure SQL-Datenbank und Azure SQL Managed Instance

  • Artikel

Gilt für: Azure SQL Database Azure SQL Managed Instance

Mit Azure SQL-Datenbank und SQL Managed Instance können Sie mit minimaler Downtime zusätzliche Ressourcen dynamisch zu Ihrer Datenbank hinzufügen. Allerdings wird die Verbindung mit der Datenbank während einer Umschaltzeit kurzzeitig unterbrochen, was jedoch durch Wiederholungslogik abgeschwächt werden kann.

Übersicht

Wenn die Nachfrage nach Ihrer App von einigen wenigen Geräten und Kunden bis in den Millionenbereich zunimmt, können Azure SQL-Datenbank und SQL Managed Instance im laufenden Betrieb mit minimaler Downtime skaliert werden. Die Skalierbarkeit ist eines der wichtigsten Merkmale von PaaS (Platform-as-a-Service), mit dem Sie Ihrem Dienst bei Bedarf dynamisch weitere Ressourcen hinzufügen können. Mit Azure SQL-Datenbank können Sie Ressourcen (CPU-Leistung, Arbeitsspeicher, E/A-Durchsatz und Speicher), die Ihren Datenbanken zugeordnet sind, leicht ändern.

Sie können Leistungsprobleme beheben, die aufgrund der vermehrten Nutzung Ihrer Anwendung auftreten und sich per Indizierung oder mit Methoden zum Umschreiben von Abfragen nicht beseitigen lassen. Durch das Hinzufügen von weiteren Ressourcen können Sie schnell reagieren, wenn Ihre Datenbank die derzeitigen Ressourcenlimits erreicht und eine höhere Leistung benötigt, um die eingehende Workload verarbeiten zu können. Mit Azure SQL-Datenbank können Sie die Ressourcen auch zentral herunterskalieren, wenn sie nicht benötigt werden, um die Kosten zu senken.

Sie müssen sich nicht mit dem Kaufen von Hardware und Ändern der zugrunde liegenden Infrastruktur befassen. Sie können eine Datenbank einfach im Azure-Portal über einen Schieberegler skalieren.

Skalieren der Datenbankleistung

Azure SQL-Datenbank bietet das DTU-basierte Kaufmodell und das vCore-basierte Kaufmodell, während Azure SQL Managed Instance nur das vCore-basierte Kaufmodell bietet.

  • Das DTU-basierte Kaufmodell bietet zur Unterstützung von einfachen bis hin zu komplexen Datenbankworkloads eine Mischung aus Compute-, Arbeitsspeicher- und E/A-Ressourcen auf drei Dienstebenen: Basic, Standard und Premium. Leistungsstufen auf den einzelnen Ebenen bieten unterschiedliche Ressourcenzusammenstellungen, durch zusätzliche Speicherressourcen ergänzt werden können.
  • Beim vCore-basierten Kaufmodell können Sie die Anzahl virtueller Kerne, die Arbeitsspeichermenge sowie Menge und Geschwindigkeit des Speichers auswählen. Dieses Kaufmodell bietet drei Dienstebenen: „Universell“, „Unternehmenskritisch“ und „Hyperscale“.

Die Grenzwerte für Dienstebene, Computeebene und Ressourcen für eine Datenbank, einen Pool für elastische Datenbanken oder eine verwaltete Instanz können jederzeit geändert werden. Sie können beispielsweise Ihre erste App in einer Einzeldatenbank erstellen und dazu die serverlose Computeebene verwenden, und dann manuell oder programmgesteuert jederzeit die Dienstebene (Tarif) in die bereitgestellte Computeebene ändern, um die Anforderungen Ihrer Lösung zu erfüllen.

Hinweis

Es gibt jedoch auch wichtige Ausnahmen, bei denen Sie die Dienstebene einer Datenbank nicht ändern können:

  • Datenbanken, die Features verwenden, die nur in den Dienstebenen „Unternehmenskritisch/Premium“ verfügbar sind, können nicht geändert werden, um die Dienstebene „Universell/Standard“ zu verwenden. Derzeit ist In-Memory-OLTP das einzige Feature dieser Art.
  • Datenbanken, die ursprünglich in der Dienstebene „Hyperscale“ erstellt wurden, können nicht zu anderen Dienstebenen migriert werden. Wenn Sie eine vorhandene Datenbank in Azure SQL-Datenbank zur Hyperscale-Dienstebene migrieren, können Sie innerhalb von 45 Tagen nach der ursprünglichen Migration zu Hyperscale eine umgekehrte Migration in die Universell-Dienstebene durchführen. Wenn Sie die Datenbank zu einer anderen Dienstebene migrieren möchten, z. B. Unternehmenskritisch, migrieren Sie zuerst zur Universell-Dienstebene zurück, und führen Sie dann eine weitere Migration aus. Weitere Informationen finden Sie unter Umkehren der Migration von Hyperscale.

Sie können die Ihrer Datenbank zugeordneten Ressourcen anpassen, indem Sie das Dienstziel ändern oder skalieren, um Workloadanforderungen zu erfüllen. Durch diese Möglichkeit brauchen Sie nur die Ressourcen zu bezahlen, die Sie benötigen, und wenn Sie sie benötigen. Beachten Sie den Hinweis zu den potenziellen Auswirkungen, die ein Skalierungsvorgang auf eine Anwendung haben kann.

Azure SQL-Datenbank ermöglicht ein dynamisches Skalieren Ihrer Datenbanken:

  • In einer Einzeldatenbank können Sie entweder DTU- oder V-Kern-Modelle nutzen, um die maximale Menge von Ressourcen zu definieren, die den einzelnen Datenbanken zugewiesen werden.
  • Bei Pools für elastische Datenbanken können Sie das maximale Ressourcenlimit pro Datenbankgruppe im Pool definieren.

In Azure SQL Managed Instance ist ebenfalls ein Skalieren möglich:

  • SQL Managed Instance verwendet den Modus Virtuelle Kerne und ermöglicht Ihnen das Definieren der maximalen Anzahl von CPU-Kernen und des maximalen Speichers für Ihre Instanz. Alle Datenbanken innerhalb der verwalteten Instanz nutzen die der Instanz zugeordneten Ressourcen gemeinsam.

Tipp

Mit der dynamischen Skalierung können Kund*innen die Ressourcenzuordnung manuell oder programmgesteuert ändern. Die dynamische Skalierungsfunktion ist für alle Azure SQL Datenbank- und Azure SQL Managed Instance-Ressourcen verfügbar.

Zusätzlich zur Unterstützung der dynamischen Skalierung unterstützt die serverlose Ebene in Azure SQL-Datenbank die automatische Skalierung. Datenbanken in der serverlosen Ebene skalieren Ressourcen automatisch basierend auf der Workloadanforderung innerhalb eines von Kund*innen angegebenen Bereichs. Zum Skalieren der Datenbank ist keine Kundenaktion erforderlich.

Auswirkungen von Skalierungsvorgängen (Hoch- bzw. Herunterskalieren)

Wenn Sie bei einer der vorgenannten Varianten eine Aktion zum Hoch- oder Herunterskalieren initiieren, wird der Datenbank-Engine-Prozess neu gestartet und bei Bedarf auf einen anderen virtuellen Computer verschoben. Das Verschieben des Datenbank-Engine-Prozesses auf einen neuen virtuellen Computer ist ein Onlineprozess, während dem Sie den vorhandenen Azure SQL-Datenbankdienst weiterhin verwenden können. Sobald die Zieldatenbank-Engine für die Verarbeitung von Abfragen bereit ist, werden geöffnete Verbindungen zur aktuellen Datenbank-Engine beendet, und für Transaktionen ohne ausgeführten Commit erfolgt ein Rollback. Es werden neue Verbindungen zur Zieldatenbank-Engine hergestellt.

Hinweis

Es wird davon abgeraten, dass Sie Ihre verwaltete Instanz skalieren, wenn eine Transaktion mit langer Laufzeit – z. B. ein Datenimport, Datenverarbeitungsaufträge, eine Indexneuerstellung usw. – ausgeführt wird oder wenn es eine aktive Verbindung mit der Instanz gibt. Wenn Sie verhindern möchten, dass die Skalierung länger als üblich dauert, sollten Sie die Instanz nach Abschluss aller Vorgänge mit langer Laufzeit skalieren.

Hinweis

Sie müssen mit einer kurzen Unterbrechung der Verbindung rechnen, wenn das Hoch-/Herunterskalieren abgeschlossen ist. Wenn Sie Wiederholungslogik bei vorübergehenden Standardfehlern implementiert haben, bemerken Sie den Failover nicht.

Alternative Skalierungsmethoden

Die Skalierung von Ressourcen ist die einfachste und effektivste Möglichkeit, die Leistung Ihrer Datenbank zu verbessern, ohne die Datenbank oder den Anwendungscode zu ändern. Manchmal kann es vorkommen, dass auch die höchsten Dienstebenen, Computegrößen und Leistungsoptimierungen nicht zu einer erfolgreichen und kostengünstigen Verarbeitung Ihrer Workload führen. In diesen Fällen haben Sie weitere Möglichkeiten zum Skalieren Ihrer Datenbank:

  • Die horizontale Leseskalierung ist ein verfügbares Feature, bei dem Sie ein schreibgeschütztes Replikat Ihrer Daten erhalten, über das Sie anspruchsvolle schreibgeschützte Abfragen (z. B. Berichte) ausführen können. Mit einem schreibgeschützten Replikat wird Ihre schreibgeschützte Workload verarbeitet, ohne dass sich Auswirkungen auf die Ressourcenverwendung in Ihrer primären Datenbank ergeben.
  • Das Datenbank-Sharding umfasst eine Reihe von Verfahren, mit denen Sie Ihre Daten in mehrere Datenbanken aufteilen und unabhängig voneinander skalieren können.

Nächste Schritte