Freigeben über

Pools für elastische Datenbanken als Hilfe beim Verwalten und Skalieren vieler Datenbanken in Azure SQL-Datenbank

Gilt für::Azure SQL-Datenbank

Pools für elastische Azure SQL-Datenbank-Instanzen sind eine einfache, kostengünstige Lösung zum Verwalten und Skalieren einer großen Zahl von Datenbanken mit variierenden und unvorhersehbaren Nutzungsanforderungen. Die Datenbanken in einem Pool für elastische Datenbanken befinden sich auf einem einzelnen Server und nutzen gemeinsam eine festgelegte Anzahl von Ressourcen zu einem festen Preis. Mithilfe von Pools für elastische Datenbanken in SQL-Datenbank kann bei der SaaS-Entwicklung (Software-as-a-Service) das Preis-Leistungs-Verhältnis für eine Gruppe von Datenbanken im Rahmen eines vorgegebenen Budgets optimiert und gleichzeitig eine flexible Leistung für jede Datenbank sichergestellt werden.

Was sind Pools für elastische SQL-Datenbanken?

SaaS-Entwickler erstellen Anwendungen, die auf umfassenden Datenschichten mit mehreren Datenbanken basieren. Ein typisches Anwendungsmuster ist die Bereitstellung einer einzigen Datenbank für jeden Kunden. Verschiedene Kunden haben jedoch häufig unterschiedliche und unvorhersehbare Nutzungsmuster, und es ist schwierig, den Ressourcenbedarf jedes Datenbankbenutzers vorherzusagen. Bisher hatten Sie zwei Optionen:

  • Überprovisionierung von Ressourcen auf der Grundlage von Nutzungsspitzen und Überbezahlung.
  • Unterdimensionierte Bereitstellung zum Einsparen von Kosten, zu Lasten von Leistung und Kundenzufriedenheit während der Spitzenzeiten.

Pools für elastische Datenbanken lösen dieses Problem, indem sie sicherstellen, dass die Datenbanken die Leistungsressourcen erhalten, die sie benötigen, und zwar genau zu dem Zeitpunkt, zu dem sie sie benötigen. Sie stellen einen einfachen Ressourcenzuordnungsmechanismus innerhalb eines vorhersagbaren Budgets bereit. Weitere Informationen zu Entwurfsmustern für SaaS-Anwendungen mit elastischen Pools finden Sie unter Mandantenmuster für Mehrmandanten-SaaS-Datenbanken.

Wichtig

Bei Pools für elastische Datenbanken erfolgt keine Abrechnung pro Datenbank. Die Abrechnung erfolgt pro Stunde, die ein Pool mit dem höchsten eDTU- oder vCore-Wert vorhanden ist, unabhängig von der Nutzung oder davon, ob der Pool für weniger als eine Stunde aktiv war.

Mit Pools für elastische Datenbanken können Sie Ressourcen für einen Pool erwerben, der von mehreren Datenbanken gemeinsam genutzt wird, um unvorhersehbare Auslastungsspitzen einzelner Datenbanken abzufedern. Sie können Ressourcen für den Pool entweder basierend auf dem DTU-basierten Kaufmodell oder dem vCore-basierten Kaufmodell konfigurieren. Die Ressourcenanforderungen eines Pools werden anhand der aggregierten Nutzung der hierin befindlichen Datenbanken ermittelt.

Ihr Budget steuert die ressourcen, die für den Pool verfügbar sind. Sie müssen lediglich folgende Aufgaben ausführen:

  • Fügen Sie dem Pool Datenbanken hinzu.
  • Legen Sie optional die minimalen und maximalen Ressourcen für die Datenbanken fest, entweder im DTU- oder vCore-Kaufmodell.
  • Legen Sie die Ressourcen des Pools basierend auf Ihrem Budget fest.

Sie können Pools nutzen, um Ihren Dienst nahtlos von einem kleinen Startup zu einem etablierten Unternehmen mit immer größerem Umfang auszubauen.

Innerhalb des Pools haben einzelne Datenbanken die Flexibilität, Ressourcen innerhalb von festgelegten Parametern zu verwenden. Bei hoher Auslastung kann eine Datenbank mehr Ressourcen nutzen, um die Anforderungen zu erfüllen. Datenbanken verbrauchen bei geringerer Auslastung weniger Ressourcen und ohne Auslastung gar keine Ressourcen. Durch die Bereitstellung von Ressourcen für den gesamten Pool und nicht nur für einzelne Datenbanken vereinfachen Sie Ihre Verwaltungsaufgaben. Außerdem verfügen Sie über ein vorhersagbares Budget für den Pool.

Einem vorhandenen Pool können – mit minimaler Downtime – zusätzliche Ressourcen hinzugefügt werden. Falls die zusätzlichen Ressourcen nicht mehr benötigt werden, können sie jederzeit aus einem vorhandenen Pool entfernt werden. Darüber hinaus können Sie Datenbanken zum Pool hinzufügen oder daraus entfernen. Wenn absehbar ist, dass eine Datenbank zu wenig Ressourcen beansprucht, können Sie sie auslagern.

Hinweis

Beim Verschieben von Datenbanken in oder aus einem elastischen Pool gibt es keine Ausfallzeiten, abgesehen von einem kurzen Zeitraum (in der Größenordnung von Sekunden), wenn schließlich die Datenbankverbindungen getrennt werden.

Wann sollte ein Pool für elastische SQL-Datenbank-Instanzen in Betracht gezogen werden?

Pools eignen sich hervorragend für eine große Anzahl an Datenbanken mit bestimmten Nutzungsmustern. Für eine einzelne Datenbank ist dieses Muster durch eine niedrige durchschnittliche Nutzung mit seltenen Nutzungsspitzen gekennzeichnet. Im Gegensatz dazu sollten mehrere Datenbanken mit dauerhafter mittlerer Auslastung nicht demselben Pool für elastische Datenbanken hinzugefügt werden.

Je mehr Datenbanken Sie einem Pool hinzufügen können, desto mehr sparen Sie. Abhängig vom Auslastungsmuster Ihrer Anwendung können Sie bereits mit nur zwei S3-Datenbanken Ersparnisse erzielen.

Die folgenden Abschnitte helfen Ihnen einzuschätzen, ob Ihre Datenbanksammlung von einem Pool profitieren kann. In den Beispielen werden Pools der Dienstebene „Standard“ verwendet, es gelten jedoch dieselben Prinzipien auch für elastische Pools in anderen Dienstebenen.

Bewertung von Datenbanknutzungsmustern

Die folgende Abbildung zeigt ein Beispiel für eine Datenbank, die sich zwar die meiste Zeit im Leerlauf befindet, aber auch regelmäßig Aktivitätsspitzen aufweist. Dieses Auslastungsmuster eignet sich für einen Pool.

Diagramm: Eine einzelne, für einen Pool geeignete Datenbank.

Das Diagramm veranschaulicht die DTU-Nutzung über einen Zeitraum von einer Stunde zwischen 12:00 und 13:00 Uhr, wobei jeder Datenpunkt eine Granularität von einer Minute aufweist. DB1 erreicht um 12:10 Uhr den Spitzenwert von 90 DTUs, die mittlere Auslastung liegt jedoch bei unter fünf DTUs. Zum Ausführen dieser Workload in einer einzelnen Datenbank wird die Computegröße S3 benötigt. Allerdings führt diese Größe dazu, dass die meisten Ressourcen in Zeiten geringer Aktivität nicht genutzt werden.

Mit einem Pool können diese nicht verwendeten DTUs für mehrere Datenbanken freigegeben werden. Ein Pool verringert die benötigten DTUs und senkt die Gesamtkosten.

Ausgehend vom vorherigen Beispiel nehmen wir an, dass weitere Datenbanken ein ähnliches Nutzungsmuster wie DB1 haben. In den beiden folgenden Abbildungen wird die Auslastung von 4 und von weiteren 20 Datenbanken überlagert in einem Diagramm dargestellt. Damit wird veranschaulicht, dass es bei Verwendung des DTU-basierten Kaufmodells im Lauf der Zeit keine Überschneidungen hinsichtlich ihrer Nutzung gibt:

Diagramm: Vier Datenbanken mit einem für einen Pool geeigneten Auslastungsmuster.

Diagramm: 20 Datenbanken mit einem für einen Pool geeigneten Auslastungsmuster.

Die schwarze Linie im vorstehenden Diagramm stellt die aggregierte DTU-Nutzung aller 20 Datenbanken dar. Sie zeigt, dass die aggregierte DTU-Nutzung niemals 100 DTUs übersteigt und dass sich die 20 Datenbanken in diesem Zeitraum 100 eDTUs teilen können. Das Ergebnis ist eine 20-fache Verringerung der DTUs und eine 13-fache Preisreduzierung im Vergleich zur Bereitstellung jeder Datenbank in S3-Computegröße für einzelne Datenbanken.

Dieses Beispiel ist aus folgenden Gründen ideal geeignet:

  • Es gibt große Unterschiede zwischen der Spitzenauslastung und der mittleren Auslastung pro Datenbank.
  • Die Spitzenauslastung jeder Datenbank ergibt sich zu jeweils unterschiedlichen Zeitpunkten.
  • eDTUs werden von mehreren Datenbanken gemeinsam genutzt.

Im DTU-Kaufmodell hängt der Preis eines Pools von den Pool-eDTUs ab. Der eDTU-Einheitspreis für einen Pool ist zwar 1,5-mal höher als der DTU-Einheitspreis für eine einzelne Datenbank, aber die eDTUs eines Pools können von vielen Datenbanken gemeinsam genutzt werden, sodass insgesamt weniger eDTUs benötigt werden. Die Unterschiede bei der Preisgestaltung und die gemeinsame Nutzung von eDTUs sind die Basis des Einsparungspotenzials, das von Pools geboten wird.

Beim vCore-basierten Kaufmodell ist der vCore-Einheitspreis für elastische Pools der gleiche wie für Einzel-Datenbanken.

Wie wähle ich die richtige Poolgröße?

Die optimale Größe eines Pools hängt von den zusammengefassten Ressourcen ab, die für alle Datenbanken im Pool benötigt werden. Sie müssen Folgendes festlegen:

  • Maximale Computeressourcen, die von allen Datenbanken im Pool verwendet werden. Die Rechenressourcen werden abhängig vom Kaufmodell entweder durch eDTUs oder vCores indiziert.
  • Maximale Speicherbytes, die von allen Datenbanken im Pool verwendet werden.

Weitere Informationen zu den Dienstebenen und Ressourcengrenzwerten für jedes Kaufmodell finden Sie unter DTU-basiertes Kaufmodell bzw. vCore-basiertes Kaufmodell.

Die folgenden Schritte können Ihnen dabei helfen, einzuschätzen, ob ein Pool kostengünstiger als einzelne Datenbanken ist:

  1. Schätzen Sie die für den Pool benötigte Anzahl von eDTUs oder virtuellen Kernen:

    1. Für das DTU-basierte Kaufmodell:
      1. MAX(<<Gesamtanzahl von Datenbanken × durchschnittliche DTU-Auslastung pro Datenbank>, < × DTU-Spitzenauslastung pro Datenbank>>)
    2. Für das auf virtuellen Kernen basierende Kaufmodell:
      1. MAX(<<Gesamtanzahl von Datenbanken × durchschnittliche vCore-Auslastung pro Datenbank>, < × vCore-Spitzenauslastung pro Datenbank>>)

  2. Schätzen Sie den für den Pool benötigten Gesamtspeicherplatz, indem Sie das erforderliche Datenvolumen für alle Datenbanken im Pool addieren. Ermitteln Sie für das DTU-basierte Kaufmodell die eDTU-Poolgröße, die diese Menge an Speicher bietet.

  3. Verwenden Sie für das DTU-basierte Kaufmodell die größere der eDTU-Schätzungen aus Schritt 1 und Schritt 2.

    1. Verwenden Sie für das vCore-basierte Kaufmodell die vCore-Schätzung aus Schritt 1.

  4. Informationen finden Sie auf der Preisseite für SQL-Datenbank.

    1. Suchen Sie die kleinste Poolgröße, die größer ist als die Schätzung aus Schritt 3.

  5. Vergleichen Sie den in Schritt 4 angegebenen Poolpreis mit dem Preis der passenden Computegrößen für einzelne Datenbanken.

Wichtig

Wenn sich die Anzahl von Datenbanken in einem Pool dem unterstützten Maximalwert nähert, sollten Sie die Ressourcenverwaltung in dichten elastischen Pools berücksichtigen.

Datenbankspezifische Eigenschaften

Legen Sie optional Eigenschaften pro Datenbank fest, um Ressourcenverbrauchsmuster in Pools für elastische Datenbanken zu ändern. Weitere Informationen finden Sie in der Dokumentation zu Ressourcenlimits für DTU und vCore in elastischen Datenbankpools.

Verwenden Sie andere SQL-Datenbankfunktionen mit elastischen Pools

Sie können andere SQL-Datenbankfunktionen mit elastischen Pools verwenden.

Elastische Aufträge und elastische Pools

Mit einem Pool werden die Verwaltungsaufgaben vereinfacht, indem Skripts in elastischen Aufträgen ausgeführt werden. Ein elastischer Job beseitigt den Großteil der mit einer großen Anzahl von Datenbanken verbundenen Mühsal.

Weitere Informationen zu anderen Datenbanktools zum Arbeiten mit mehreren Datenbanken finden Sie unter Skalieren mit Azure SQL-Datenbank.

Elastische Hyperscale-Pools

Die Übersicht über hyperskalenlastische Pools in der Azure SQL-Datenbank ist allgemein verfügbar.

Schreibgeschützte Instanzen mit horizontaler Skalierung

Sie können keine schreibgeschützten Instanzen mit horizontaler Skalierung von Azure SQL-Datenbank mit elastischer Abfrage verwenden.

Geschäftskontinuitätsoptionen für Datenbanken in einem elastischen Pool

Pooldatenbanken unterstützen in der Regel die gleichen Geschäftskontinuitätsfeatures, die auch für Einzeldatenbanken zur Verfügung stehen:

  • Point-in-Time-Wiederherstellung: Bei der Point-in-Time-Wiederherstellung werden automatische Datenbanksicherungen verwendet, um den Status einer Datenbank in einem Pool zu einem bestimmten Zeitpunkt wiederherzustellen. Siehe Point-in-Time-Wiederherstellung.
  • Geografische Wiederherstellung: Die geografische Wiederherstellung ist die Standardoption für die Wiederherstellung, wenn eine Datenbank aufgrund eines Vorfalls in der Region, in der die Datenbank gehostet wird, nicht verfügbar ist. Siehe Geowiederherstellung.
  • Aktive Georeplikation: Für Anwendungen mit höheren Wiederherstellungsanforderungen, die mit der Geowiederherstellung nicht erfüllt werden können, konfigurieren Sie die aktive Georeplikation oder eine Failovergruppe.

Weitere Informationen zu den oben genannten Strategien finden Sie in den Richtlinien zur Notfallwiederherstellung – Azure SQL-Datenbank.

Erstellen eines neuen Pools für elastische SQL-Datenbank-Instanzen über das Azure-Portal

Es gibt im Azure-Portal zwei Möglichkeiten, einen Pool für elastische Datenbanken zu erstellen:

  • Erstellen eines Pools für elastische Datenbanken und Auswählen eines vorhandenen oder neuen Servers.
  • Erstellen eines elastischen Pools von einem vorhandenen Server.

So erstellen Sie einen Pool für elastische Datenbanken und wählen einen vorhandenen oder neuen Server aus:

  1. Wechseln Sie zum Azure SQL-Hub bei aka.ms/azuresqlhub.

  2. Erweitern Sie im Ressourcenmenü Azure SQL-Datenbank , und wählen Sie "Flexible Pools" aus.

  3. Wählen Sie auf der Symbolleiste +Erstellen aus.

    Screenshot des Azure-Portals mit dem Menü

  4. Wählen Sie ein Abonnement, eine Ressourcengruppe, einen Elastic Pool-Namen und einen logischen Hostserver aus, der ein vorhandener oder neuer Server sein kann.

  5. Zum Konfigurieren der Ressourcen und des Preismodells für den Pool klicken Sie auf Pool konfigurieren. Wählen Sie dann eine Servicestufe aus, fügen Sie dem Pool Datenbanken hinzu und konfigurieren Sie die Ressourceneinschränkungen für den Pool und dessen Datenbanken.

  6. Nachdem Sie den Pool konfiguriert haben, wählen Sie Übernehmen aus, benennen Sie den Pool, und wählen Sie OK aus, um den Pool zu erstellen.

  7. Verwalten Sie dann Ihren elastischen Pool über das Azure-Portal, PowerShell, Azure CLI, REST-API oder T-SQL.

Erstellen Sie einen elastischen Pool auf einem vorhandenen Server:

  1. Navigieren Sie zu einem vorhandenen Server, und wählen Sie Neuer Pool aus, um einen Pool direkt auf diesem Server zu erstellen.

    Hinweis

    Auf einem Server können mehrere Pools erstellt werden, es ist jedoch nicht möglich, Datenbanken von verschiedenen Servern im gleichen Pool zusammenzufassen.

    Die Dienststufe des Pools bestimmt die verfügbaren Features für die elastischen Datenbanken im Pool sowie die maximale Ressourcenmenge, die für jede Datenbank verfügbar ist. Weitere Informationen finden Sie in den Ressourceneinschränkungen für Pools für elastische Datenbanken im DTU-Modell. Informationen zu V-Kern-basierte Ressourceneinschränkungen für Pools für elastische Datenbanken finden Sie unter V-Kern-basierte Ressourceneinschränkungen – Pools für elastische Datenbanken.

  2. Zum Konfigurieren der Ressourcen und des Preismodells für den Pool klicken Sie auf Pool konfigurieren. Wählen Sie dann eine Diensteebene aus, fügen Sie dem Pool Datenbanken hinzu und konfigurieren Sie die Ressourcengrenzen für den Pool und seine Datenbanken.

  3. Nachdem Sie den Pool konfiguriert haben, wählen Sie Übernehmen, benennen Sie den Pool und klicken auf OK, um ihn zu erstellen.

  4. Verwalten Sie dann Ihren Pool für elastische Datenbanken über das Azure-Portal, PowerShell, Azure CLI, REST API oder T-SQL.

Überwachen eines elastischen Pools und seiner Datenbanken

Im Azure-Portal können Sie die Verwendung eines Pools für elastische Datenbanken sowie der darin enthaltenen Datenbanken überwachen. Außerdem können Sie eine Reihe von Änderungen an Ihrem elastischen Pool vornehmen und alle Änderungen gleichzeitig übermitteln. So können Sie etwa Datenbanken hinzufügen oder entfernen, die Einstellungen des Pools für elastische Datenbanken ändern oder Ihre Datenbankeinstellungen anpassen.

Sie können die integrierte Leistungsüberwachung und die Warnungstools in Kombination mit den Leistungsbewertungen verwenden. Darüber hinaus kann SQL-Datenbank zur einfacheren Überwachung Metriken und Ressourcenprotokolle ausgeben.

Zugehöriger Inhalt

  • Last updated on