Ressourcenverwaltung in dicht belegten elastischen Pools

Gilt für::Azure SQL-Datenbank

Pools für elastische Azure SQL-Datenbanken sind eine kostengünstige Lösung zum Verwalten einer großen Zahl von Datenbanken mit variierender Ressourcenauslastung. Für alle Datenbanken eines Pools für elastische Datenbanken wird die gleiche Zuordnung von Ressourcen verwendet, z. B. CPU, Arbeitsspeicher, Workerthreads, Speicherplatz und tempdb. Dies erfolgt aufgrund der Annahme, dass Computeressourcen jeweils nur von einer Teilmenge der Datenbanken im Pool genutzt werden. Diese Annahme ermöglicht für Pools für elastische Datenbanken die Erzielung von Kosteneffizienz. Anstatt für alle Ressourcen zu bezahlen, die von jeder einzelnen Datenbank unter Umständen benötigt werden, zahlen Kunden für einen deutlich kleineren Ressourcensatz, der für alle Datenbanken des Pools genutzt wird.

Ressourcenverwaltung

Bei der Ressourcenfreigabe muss das System die Ressourcenauslastung sorgfältig kontrollieren, um den „Noisy Neighbor“-Effekt (lauter Nachbar) zu verringern, bei dem eine Datenbank mit hohem Ressourcenverbrauch andere Datenbanken in demselben Pool für elastische Datenbanken beeinträchtigt. Azure SQL-Datenbank erreicht diese Ziele durch Implementierung von Ressourcengovernance. Außerdem muss das System genügend Ressourcen für Features bereitstellen, z. B. Hochverfügbarkeit und Notfallwiederherstellung, Sicherung und Wiederherstellung, Überwachung, Abfragespeicher, automatische Optimierung usw., um zuverlässig zu funktionieren.

Das vorrangige Entwurfsziel von elastischen Pools ist Kosteneffizienz. Aus diesem Grund ermöglicht das System Kunden absichtlich, dichte Pools zu erstellen, d. h. Pools, bei denen sich die Anzahl der Datenbanken dem zulässigen Maximum nähert oder es erreicht, jedoch mit einer moderaten Zuweisung von Rechenressourcen. Aus demselben Grund reserviert das System nicht alle potenziell benötigten Ressourcen für seine internen Prozesse, sondern ermöglicht die gemeinsame Nutzung von Ressourcen zwischen internen Prozessen und Benutzer-Workloads.

Dieser Ansatz ermöglicht es Kunden, dicht belegte elastische Pools zu nutzen, um eine angemessene Leistung und erhebliche Kosteneinsparungen zu erzielen. Wenn jedoch die Auslastung vieler Datenbanken in einem hoch ausgelasteten Pool ausreichend intensiv ist, kommt es zu erheblicher Ressourcenkonkurrenz. Ressourcenkonflikte verringern die Leistung von Benutzerworkloads und können interne Prozesse negativ beeinträchtigen.

Falls es in einem dicht gepackten Pool zu Ressourcenkonflikten kommt, können Kunden eine oder mehrere der folgenden Aktionen auswählen, um diese zu beheben:

• Optimieren Sie die Abfrageworkload, um den Ressourcenverbrauch zu reduzieren oder diesen mit der Zeit auf mehrere Datenbanken zu verteilen.
• Reduzieren der Pooldichte, indem einige Datenbanken in einen anderen Pool verschoben oder zu eigenständigen Datenbanken gemacht werden
• Hochskalieren des Pools zum Abrufen von weiteren Ressourcen

Vorschläge zur Implementierung der letzten beiden Aktionen finden Sie unter Empfehlungen zum Betrieb weiter unten in diesem Artikel. Die Reduzierung von Ressourcenkonflikten wirkt sich sowohl auf Benutzer als auch auf interne Prozesse positiv aus und ermöglicht es dem System, den erwarteten Servicelevel aufrechtzuerhalten.

Überwachen des Ressourcenverbrauchs

Zur Vermeidung von Leistungsbeeinträchtigungen aufgrund von Ressourcenkonflikten sollten Kunden, die umfangreiche Pools für elastische Datenbanken nutzen, den Ressourcenverbrauch proaktiv überwachen und rechtzeitig Maßnahmen ergreifen, falls sich zunehmende Ressourcenkonflikte auf die Arbeitsauslastungen auswirken. Eine fortlaufende Überwachung ist wichtig, weil sich die Ressourcenauslastung in einem Pool im Laufe der Zeit verändert, z. B. aufgrund von Änderungen der Benutzerworkloads, der Datenmenge und -verteilung, der Pooldichte und im Azure SQL-Datenbank-Dienst.

Azure SQL-Datenbank verfügt über mehrere Metriken, die für diese Art von Überwachung relevant sind. Wenn Sie den empfohlenen Durchschnittswert für jede Metrik überschreiten, wird ein Ressourcenkonflikt für den Pool angezeigt, den Sie mit einer der oben beschriebenen Maßnahmen beseitigen sollten.

Um eine Warnung zu senden, wenn die Ressourcenauslastung des Pools (CPU, Daten-E/A, Protokoll-E/A, Mitarbeiter usw.) einen Schwellenwert überschreitet, erstellen Sie Warnungen für Azure SQL-Datenbank mithilfe des Azure-Portals oder verwenden Sie das PowerShell-Cmdlet "Add-AzMetricAlertRulev2 ". Bei der Überwachung von Pools für elastische Datenbanken können Sie ggf. auch Warnungen für einzelne Datenbanken im Pool erstellen, sollte dies in Ihrem Szenario erforderlich sein.

Zusätzlich zu diesen Metriken bietet Azure SQL-Datenbank eine Ansicht, in der die tatsächlichen Grenzwerte für die Ressourcenkontrolle zurückgegeben werden. Außerdem gibt es zusätzliche Ansichten, in denen statistische Daten zur Ressourcenauslastung auf Ebene des Ressourcenpools und auf Ebene der Arbeitsauslastungsgruppe zurückgegeben werden.

Diese Ansichten können verwendet werden, um die Ressourcennutzung zu überwachen und Probleme aufgrund von Ressourcenkonflikten nahezu in Echtzeit zu behandeln. Die Benutzerarbeitsauslastung auf den primären und lesbaren sekundären Replikaten, einschließlich Georeplikaten, wird als Ressourcenpool SloSharedPool1 und Arbeitsauslastungsgruppe UserPrimaryGroup.DBId[N] klassifiziert, wobei N für den Datenbank-ID-Wert steht.

Zusätzlich zur Überwachung der aktuellen Ressourcennutzung können Kunden, die umfangreiche Pools nutzen, Verlaufsdaten zur Ressourcennutzung in einem separaten Datenspeicher aufbewahren. Diese Daten können für Vorhersageanalysen verwendet werden, um die Ressourcennutzung basierend auf verlaufsabhängigen und saisonalen Trends proaktiv zu verwalten.

Empfehlungen für den Betrieb

Ausreichend Ressourcenreserven einplanen. Wenn Ressourcenkonflikte und Leistungsbeeinträchtigungen auftreten, kann die Abhilfe das Verschieben einiger Datenbanken aus dem betroffenen elastischen Pool oder das Skalieren des Pools umfassen, wie bereits erwähnt. Für diese Aktionen sind aber zusätzliche Computeressourcen erforderlich. Insbesondere erfordern diese Aktionen bei Premium- und Business Critical-Pools die Übertragung aller Daten der zu verschiebenden Datenbanken bzw. aller Daten aller Datenbanken im Pool für elastische Datenbanken, wenn der Pool hochskaliert wird. Die Datenübertragung ist ein zeit- und ressourcenintensiver Vorgang. Wenn die Ressourcenauslastung im Pool bereits hoch ist, wird die Leistung durch die Behebungsmaßnahmen noch weiter beeinträchtigt. In extremen Fällen ist es möglicherweise nicht möglich, ressourcenverknügung durch Datenbankverschiebung oder Poolskalierung zu lösen, da die erforderlichen Ressourcen nicht verfügbar sind. In diesem Fall kann die vorübergehende Verringerung der Abfrageworkloads für den betroffenen elastischen Pool die einzige Lösung sein.

Kunden, die umfangreiche Pools nutzen, sollten die Nutzungstrends sorgfältig überwachen (wie oben beschrieben) und Maßnahmen zur Entschärfung ergreifen, während die Metriken noch in den empfohlenen Bereichen liegen und im Pool für elastische Datenbanken noch genügend Ressourcen vorhanden sind.

Die Ressourcennutzung hängt von mehreren Faktoren ab, die sich je nach Datenbank und Pool für elastische Datenbanken im Laufe der Zeit ändern. Zur Erzielung eines optimalen Preis-Leistungs-Verhältnisses in umfangreichen Pools sind eine fortlaufende Überwachung und erneute Anpassungen erforderlich, bei denen Datenbanken aus stärker genutzten Pools in weniger stark genutzte Pools verschoben und je nach Bedarf neue Pools erstellt werden, um eine erhöhte Arbeitsauslastung abdecken zu können.

Vermeiden der Verschiebung von „heißen“ Datenbanken: Wenn der Ressourcenkonflikt auf Poolebene in erster Linie durch eine kleine Anzahl stark genutzter Datenbanken verursacht wird, kann es verlockend sein, diese Datenbanken in einen weniger genutzten Pool zu verschieben oder sie zu eigenständigen Datenbanken zu machen. Dies ist aber nicht empfehlenswert, wenn eine Datenbank längere Zeit stark ausgelastet ist, weil die Leistung durch den Verschiebungsvorgang noch mehr beeinträchtigt wird. Dies gilt sowohl für die zu verschiebende Datenbank als auch für den gesamten Pool. Warten Sie stattdessen entweder, bis die hohe Auslastung abnimmt, oder verschieben Sie weniger stark genutzte Datenbanken, um die Ressourcenauslastung auf Poolebene zu reduzieren. Das Verschieben von Datenbanken mit sehr geringer Auslastung ergibt in diesem Fall aber keinen Vorteil, da die Ressourcenauslastung auf Poolebene nicht wesentlich verringert wird.

Erstellen von neuen Datenbanken in einem „Quarantänepool“ : In Szenarien, in denen häufig neue Datenbanken erstellt werden, z. B. bei Anwendungen mit dem Modell „ein Mandant pro Datenbank“, besteht die folgende Gefahr: Eine neue Datenbank, die in einem vorhandenen Pool für elastische Datenbanken angeordnet wird, verbraucht unerwartet eine sehr große Menge an Ressourcen und beeinträchtigt andere Datenbanken und interne Prozesse im Pool. Erstellen Sie zur Verringerung dieser Gefahr einen separaten „Quarantänepool“ mit einer ausreichenden Ressourcenzuordnung. Verwenden Sie diesen Pool für neue Datenbanken, für die das Muster des Ressourcenverbrauchs noch nicht bekannt ist. Nachdem sich eine Datenbank einen Geschäftszyklus lang in diesem Pool befunden hat, z. B. eine Woche oder einen Monat, und der Ressourcenverbrauch bekannt ist, kann sie in einen Pool mit ausreichender Kapazität verschoben werden, um diese zusätzliche Ressourcennutzung abzudecken.

Überwachen Sie sowohl den verwendeten als auch den zugewiesenen Speicherplatz. Wenn der zugewiesene Speicherplatz im Pool (Gesamtgröße aller Datenbankdateien im Speicher für alle Datenbanken in einem Pool) die maximale Poolgröße erreicht hat, können Speicherplatzfehler auftreten. Wenn der zugewiesene Speicherplatz tendenziell stark ansteigt und voraussichtlich die maximale Poolgröße erreicht, stehen Ihnen folgende Optionen zur Abhilfe zur Verfügung:

• Verschieben Sie einige Datenbanken aus dem Pool, um den gesamten zugewiesenen Speicherplatz zu reduzieren.
• Verwalten Sie den Dateispeicher in Datenbanken , um den leeren zugewiesenen Speicherplatz in Dateien zu reduzieren.
• Skalieren Sie den Pool auf ein Dienstziel mit einer größeren maximalen Poolgröße.

Wenn die Trends beim genutzten Speicherplatz im Pool (Gesamtgröße der Daten in allen Datenbanken in einem Pool, ohne Leerraum in Dateien) hoch sind und demnächst die maximale Poolgröße erreicht wird, stehen Ihnen zur Entschärfung folgende Optionen zur Verfügung:

• Verschieben Sie einige Datenbanken aus dem Pool, um den gesamten verwendeten Speicherplatz zu reduzieren.
• Verschieben (Archivdaten) außerhalb der Datenbank oder Löschen nicht mehr benötigter Daten.
• Implementieren sie die Datenkomprimierung.
• Skalieren Sie den Pool auf ein Dienstziel mit einer größeren maximalen Poolgröße.

Vermeiden Sie Server mit übermäßiger Dichte. Azure SQL-Datenbank unterstützt bis zu 5000 Datenbanken pro Server. Kunden, die flexible Pools mit Tausenden von Datenbanken verwenden, können es in Betracht ziehen, mehrere elastische Pools auf einem einzelnen Server mit der Gesamtanzahl der Datenbanken bis zum unterstützten Grenzwert zu platzieren. Server mit vielen Tausenden Datenbanken sind aber mit besonderen Anforderungen an den Betrieb verbunden, die bewältigt werden müssen. Vorgänge, bei denen alle Datenbanken auf einem Server aufgelistet werden müssen, z. B. beim Anzeigen von Datenbanken im Portal, benötigen mehr Zeit. Betriebsbezogene Fehler, z. B. die fehlerhafte Änderung von Anmeldungen auf Serverebene oder von Firewallregeln, wirken sich auf eine größere Zahl von Datenbanken aus. Nach dem versehentlichen Löschen des Servers benötigen Sie Hilfe vom Microsoft-Support, um die Datenbanken auf dem gelöschten Server wiederherstellen zu lassen, und es kommt für alle betroffenen Datenbanken zu einem längeren Ausfall.

Legen Sie die Anzahl von Datenbanken pro Server auf eine niedrigere Anzahl als den maximal unterstützten Wert fest. In vielen Szenarien ist die Nutzung von maximal 1.000 - 2.000 Datenbanken pro Server optimal. Um die Wahrscheinlichkeit zu verringern, dass ein Server versehentlich gelöscht wird, sollten Sie eine Löschsperre auf dem Server oder in der zugehörigen Ressourcengruppe hinzufügen.

Beispiele

Anzeigen der Kapazitätseinstellungen für einzelne Datenbanken

Verwenden Sie die dynamische Verwaltungssicht sys.dm_user_db_resource_governance, um die tatsächlichen Konfigurations- und Kapazitätseinstellungen anzuzeigen, die von der Ressourcenverwaltung in der aktuellen Datenbank oder im aktuellen elastischen Pool verwendet werden. Weitere Informationen finden Sie unter sys.dm_user_db_resource_governance.

Führen Sie diese Abfrage in einer beliebigen Datenbank in einem Pool für elastische Datenbanken aus. Für alle Datenbanken im Pool sind die gleichen Einstellungen für Ressourcengovernance festgelegt.

SELECT * FROM sys.dm_user_db_resource_governance AS rg
WHERE database_id = DB_ID();

Überwachung des Ressourcenverbrauchs des elastischen Pools insgesamt.

Verwenden Sie die Systemkatalogsicht sys.elastic_pool_resource_stats, um den Ressourcenverbrauch des gesamten Pools zu überwachen. Weitere Informationen finden Sie unter sys.elastic_pool_resource_stats.

Diese Beispielabfrage zum Anzeigen der letzten 10 Minuten sollte in der Datenbank master des logischen Azure SQL-Servers ausgeführt werden, der den gewünschten elastischen Pool enthält.

SELECT * FROM sys.elastic_pool_resource_stats AS rs
WHERE rs.start_time > DATEADD(mi, -10, SYSUTCDATETIME()) 
AND rs.elastic_pool_name = '<elastic pool name>';

Überwachen des Ressourcenverbrauchs einzelner Datenbanken

Verwenden Sie die dynamische Verwaltungssicht sys.dm_db_resource_stats, um den Ressourcenverbrauch einzelner Datenbanken zu überwachen. Weitere Informationen finden Sie unter sys.dm_db_resource_stats. Jede Zeile wird jeweils 15 Sekunden lang beibehalten, auch wenn keine Aktivität vorhanden ist. Historische Daten werden etwa eine Stunde lang gespeichert.

Diese Beispielabfrage zum Anzeigen von Daten der letzten zehn Minuten sollte in der gewünschten Datenbank ausgeführt werden.

SELECT * FROM sys.dm_db_resource_stats AS rs
WHERE rs.end_time > DATEADD(mi, -10, SYSUTCDATETIME());

Ziehen Sie für eine längere Aufbewahrungsdauer bei geringerer Häufigkeit die folgende Abfrage für sys.resource_stats in Betracht, die Sie in der master-Datenbank des logischen Azure SQL-Servers ausführen. Weitere Informationen finden Sie unter sys.resource_stats (Azure SQL-Datenbank). Es gibt alle fünf Minuten einen Eintrag, und historische Daten werden zwei Wochen lang gespeichert.

SELECT * FROM sys.resource_stats
WHERE [database_name] = 'sample'
ORDER BY [start_time] desc;

Überwachen der Speicherauslastung

Mit dieser Abfrage wird die Metrik oom_per_second für jeden Ressourcenpool für den aktuellen Verlauf berechnet, basierend auf der Anzahl der verfügbaren Momentaufnahmen. Mit dieser Beispielabfrage können Sie ermitteln, für wie viele Speicherzuordnungen im Pool zuletzt durchschnittlich Fehler aufgetreten sind. Diese Abfrage kann in jeder Datenbank eines Pools für elastische Datenbanken ausgeführt werden.

SELECT pool_id,
       name AS resource_pool_name,
       IIF(name LIKE 'SloSharedPool%' OR name LIKE 'UserPool%', 'user', 'system') AS resource_pool_type,
       SUM(CAST(delta_out_of_memory_count AS decimal))/(SUM(duration_ms)/1000.) AS oom_per_second
FROM sys.dm_resource_governor_resource_pools_history_ex
GROUP BY pool_id, name
ORDER BY pool_id;

Überwachung der tempdb-Protokollraumnutzung

Die Abfrage gibt den aktuellen Wert der tempdb_log_used_percent-Metrik zurück und zeigt die relative Nutzung des tempdb-Transaktionsprotokolls im Verhältnis zu seiner maximal zulässigen Größe. Diese Abfrage kann in jeder Datenbank eines Pools für elastische Datenbanken ausgeführt werden.

SELECT (lsu.used_log_space_in_bytes / df.log_max_size_bytes) * 100 AS tempdb_log_space_used_percent
FROM tempdb.sys.dm_db_log_space_usage AS lsu
CROSS JOIN (
           SELECT SUM(CAST(max_size AS bigint)) * 8 * 1024. AS log_max_size_bytes
           FROM tempdb.sys.database_files
           WHERE type_desc = N'LOG'
           ) AS df
;

Verwandte Inhalte

• Elastische Pools helfen Ihnen, mehrere Datenbanken in Azure SQL-Datenbank zu verwalten und zu skalieren
• Überwachung und Optimierung
• Überwachung und Leistungsoptimierung in Azure SQL-Datenbank und Azure SQL Managed Instance