Verstehen, wie Anforderungen durch Azure Resource Manager gedrosselt werden

  • Artikel

In diesem Artikel wird beschrieben, wie Anforderungen durch Azure Resource Manager gedrosselt werden. Sie erfahren, wie Sie die Anzahl der verbleibenden Anforderungen vor Erreichen des Grenzwerts nachverfolgen und bei Erreichen des Grenzwerts reagieren können.

Die Drosselung erfolgt auf zwei Ebenen. Azure Resource Manager drosselt Anforderungen für das Abonnement und den Mandanten. Wenn die Anforderung unterhalb der Drosselungsgrenzwerte für das Abonnement und den Mandanten liegt, leitet Resource Manager die Anforderung an den Ressourcenanbieter weiter. Der Ressourcenanbieter wendet Drosselungsgrenzwerte an, die auf seinen Betrieb zugeschnitten sind.

Die folgende Abbildung zeigt, wie die Drosselung beim Weiterleiten einer Anforderung vom Benutzer an Azure Resource Manager und den Ressourcenanbieter angewendet wird. Die Abbildung zeigt, dass die Drosselung von Anforderungen zunächst nach Prinzipal-ID und Azure Resource Manager-Instanz in der Region des Benutzers erfolgt, der die Anforderung sendet. Die Anforderungen werden pro Stunde gedrosselt. Wenn die Anforderung an den Ressourcenanbieter weitergeleitet wird, werden die Anforderungen pro Region der Ressource gedrosselt und nicht mehr pro Azure Resource Manager-Instanz in der Region des Benutzers. Die Anforderungen des Ressourcenanbieters werden außerdem nach Benutzer-ID des Prinzipals und pro Stunde gedrosselt.

Diagramm: Anwendung der Drosselung auf dem Weg einer Anforderung vom Benutzer bzw. der Benutzerin zu Azure Resource Manager und weiter zum Ressourcenanbieter

Abonnement- und Mandantengrenzwerte

Alle Vorgänge auf Abonnement- und Mandantenebene unterliegen Drosselungsgrenzwerten. Bei Abonnementanforderungen wird Ihre Abonnement-ID übergeben, z. B. beim Abrufen der Ressourcengruppen in Ihrem Abonnement. Das Senden einer Anforderung an https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups?api-version=2022-01-01 ist beispielsweise ein Vorgang auf Abonnementebene. In Mandantenanforderungen ist Ihre Abonnement-ID nicht enthalten (etwa beim Abrufen gültiger Azure-Standorte). Das Senden einer Anforderung an https://management.azure.com/tenants?api-version=2022-01-01 ist beispielsweise ein Vorgang auf Mandantenebene.

In der folgenden Tabelle sind die Standardgrenzwerte für die Drosselung pro Stunde aufgeführt.

`Scope` Operationen (Operations) Begrenzung
Subscription Lesevorgänge 12000
Subscription Löschvorgänge 15000
Subscription Schreibvorgänge 1200
Tenant Lesevorgänge 12000
Tenant Schreibvorgänge 1200

Diese Grenzwerte gelten für den Sicherheitsprinzipal (Benutzer oder Anwendung), von dem die Anforderungen stammen, sowie für die Abonnement-ID bzw. die Mandanten-ID. Falls Ihre Anforderungen von mehreren Sicherheitsprinzipalen stammen, liegen die Grenzwerte für das Abonnement oder den Mandanten über 12.000 bzw. 1.200 Anforderungen pro Stunde.

Diese Grenzwerte gelten für jede Azure Resource Manager-Instanz. In jeder Azure-Region sind mehrere Instanzen vorhanden, und Azure Resource Manager wird in allen Azure-Regionen bereitgestellt. In der Praxis sind die Grenzwerte also höher als diese Grenzwerte. Die Anforderungen von einem Benutzer werden in der Regel von unterschiedlichen Azure Resource Manager-Instanzen verarbeitet.

Die verbleibenden Anforderungen werden in den Werten im Antwortheader zurückgegeben.

Migrieren zum regionalen Drosselungs- und Tokenbucketalgorithmus

Ab 2024 migriert Microsoft Azure-Abonnements zu einer neuen Drosselungsarchitektur. Bei dieser Änderung gibt es neue Drosselungsgrenzwerte. Die neuen Drosselungsgrenzwerte werden pro Region und nicht pro Instanz von Azure Resource Manager angewendet. Die neue Architektur verwendet einen Tokenbucketalgorithmus zum Verwalten der API-Drosselung.

Der Tokenbucket stellt die maximale Anzahl von Anforderungen dar, die Sie pro Sekunde senden können. Wenn Sie die maximale Anzahl von Anforderungen erreichen, bestimmt die Auffüllrate, wie schnell Token im Bucket verfügbar werden.

Diese aktualisierten Grenzwerte erleichtern es Ihnen, Ihr Kontingent zu aktualisieren und zu verwalten.

Die neuen Grenzwerte sind:

`Scope` Operationen (Operations) Bucketgröße Auffüllrate pro Sek.
Abonnement Lesevorgänge 250 25
Abonnement deletes 200 10
Abonnement Schreibvorgänge 200 10
Mandant Lesevorgänge 250 25
Mandant deletes 200 10
Mandant Schreibvorgänge 200 10

Die Abonnementgrenzwerte gelten pro Abonnement, pro Dienstprinzipal und pro Vorgangstyp. Es gibt auch globale Abonnementgrenzwerte, die für jeden Vorgangstyp dem 15-fachen der individuellen Dienstprinzipalgrenzwerte entsprechen. Die globalen Grenzwerte gelten für alle Dienstprinzipale. Anforderungen werden gedrosselt, wenn die globalen, dienstprinzipal- oder mandantenspezifischen Grenzwerte überschritten werden.

Die Grenzwerte können für Gratis- oder Testkunden kleiner sein.

Angenommen, Sie haben eine Bucketgröße von 250 Token für Leseanforderungen und eine Auffüllrate von 25 Token pro Sekunde. Wenn Sie 250 Leseanforderungen in einer Sekunde senden, ist der Bucket leer, und Ihre Anforderungen werden gedrosselt. Jede Sekunde werden 25 Token verfügbar, bis der Bucket seine maximale Kapazität von 250 Token erreicht. Sie können Token verwenden, sobald sie verfügbar sind.

Wie kann ich feststellen, ob mein Abonnement die neue Drosselungsumgebung verwendet?

Nachdem Ihr Abonnement zur neuen Drosselungsoberfläche migriert wurde, zeigt der Antwortheader die verbleibenden Anforderungen pro Minute statt pro Stunde an. Außerdem zeigt ihr Retry-After-Wert eine Minute oder weniger anstelle von fünf Minuten an. Weitere Informationen finden Sie unter Fehlercode.

Warum ändert sich die Drosselung auf „pro Region“ und nicht auf „pro Instanz“?

Da verschiedene Regionen über eine unterschiedliche Anzahl von Ressourcen-Manager-Instanzen verfügen, führt die Drosselung pro Instanz zu einer inkonsistenten Drosselungsleistung. Die Drosselung pro Region macht eine Drosselung konsistent und vorhersehbar.

Wie wirkt sich die neue Drosselungserfahrung auf meine Grenzwerte aus?

Sie können mehr Anforderungen senden. Schreibanforderungen werden um das 30-fache erhöht. Löschanforderungen werden um das 2,4-fache erhöht. Leseanforderungen werden um das 7,5-fache erhöht.

Kann ich verhindern, dass mein Abonnement zur neuen Drosselungsumgebung migriert wird?

Nein, alle Abonnements werden früher oder später migriert.

Grenzwerte der Ressourcenanbieter

Ressourcenanbieter wenden ihre eigenen Drosselungsgrenzwerte an. Innerhalb jedes Abonnements führt der Ressourcenanbieter die Drosselung pro Region der Ressource in der Anforderung aus. Da Resource Manager eine Drosselung nach Ressource Manager-Instanz vornimmt und es in jeder Region mehrere Resource Manager-Instanzen gibt, kann es sein, dass der Ressourcenanbieter mehr Anforderungen empfängt als die im vorhergehenden Abschnitt genannten Standardgrenzwerte.

In diesem Abschnitt werden die Drosselungsgrenzwerte einiger häufig genutzter Ressourcenanbieter erläutert.

Speicherdrosselung

Die folgenden Limits gelten nur, wenn Sie Verwaltungsvorgänge mithilfe von Azure Resource Manager mit Azure Storage ausführen. Die Grenzwerte gelten pro Region der Ressource in der Anforderung.

Resource Begrenzung
Storage-Kontoverwaltungsvorgänge (Lesen) 800 pro 5 Minuten
Storage-Kontoverwaltungsvorgänge (Schreiben) 10 pro Sekunde/1.200 pro Stunde
Storage-Kontoverwaltungsvorgänge (Liste) 100 pro 5 Minuten

Netzwerkdrosselung

Der Ressourcenanbieter Microsoft.Network wendet die folgenden Drosselungsgrenzwerte an:

Vorgang Begrenzung
Schreib-/Löschvorgänge (PUT) 1000 pro 5 Minuten
Lesevorgänge (GET) 10000 pro 5 Minuten

Zusätzlich zu diesen allgemeinen Grenzwerten gelten die folgenden Grenzwerte für DNS-Vorgänge:

DNS-Zonenvorgang Grenzwert (pro Zone)
Erstellen oder Aktualisieren 40 pro Minute
Delete 40 pro Minute
Abrufen 1.000 pro Minute
Liste 60 pro Minute
Nach Ressourcengruppe gruppieren 60 pro Minute
Aktualisieren 40 pro Minute
DNS-Eintragsmengenvorgang Grenzwert (pro Zone)
Erstellen oder Aktualisieren 200 pro Minute
Delete 200 pro Minute
Abrufen 2000 pro Minute
Auflisten nach DNS-Zone 60 pro Minute
Auflisten nach Typ 60 pro Minute
Aktualisieren 200 pro Minute

Computedrosselung

Informationen zu Drosselungsgrenzwerten für Computevorgänge finden Sie unter Behandeln von API-Drosselungsfehlern – Compute.

Verwenden Sie zum Überprüfen von VM-Instanzen innerhalb einer VM-Skalierungsgruppe den Artikel zu den Vorgängen für VM-Skalierungsgruppen. Verwenden Sie beispielsweise die List-Abfrage für VM-Skalierungsgruppen mit Parametern zum Überprüfen des Betriebszustands von VM-Instanzen. Diese API reduziert die Anzahl der Anforderungen.

Azure Resource Graph-Drosselung

Azure Resource Graph begrenzt die Anzahl der Anforderungen nach seinen Vorgängen. Die Schritte in diesem Artikel zum Bestimmen der verbleibenden Anforderungen und zum Reagieren bei Erreichen des Grenzwerts gelten auch für Resource Graph. Resource Graph legt jedoch einen eigenen Grenzwert und eine eigene Rücksetzrate fest. Weitere Informationen finden Sie unter Resource Graph-Drosselungsheader.

Andere Ressourcenanbieter

Informationen zur Drosselung bei anderen Ressourcenanbietern finden Sie hier:

Fehlercode

Wenn Sie den Grenzwert erreichen, erhalten Sie den HTTP-Statuscode 429 Zu viele Anforderungen. Die Antwort enthält einen Retry-After-Wert, der die Anzahl von Sekunden angibt, die Ihre Anwendung warten muss (oder im Ruhezustand verbleibt), bevor die nächste Anforderung gesendet wird. Wenn Sie eine Anforderung senden, bevor der Retry-Wert verstrichen ist, wird Ihre Anforderung nicht verarbeitet, und es wird ein neuer Retry-Wert zurückgegeben.

Wenn Sie ein Azure SDK verwenden, verfügt das SDK möglicherweise über eine Konfiguration für die automatische Wiederholung. Weitere Informationen finden Sie unter Wiederholungsanleitung für Azure-Dienste.

Einige Ressourcenanbieter geben 429 zurück, um ein temporäres Problem zu melden. Das Problem kann eine Überlastbedingung sein, die nicht direkt durch Ihre Anforderung verursacht wird. Es kann sich aber auch um einen vorübergehenden Fehler in Bezug auf den Status der Zielressource oder der abhängigen Ressource handeln. Der Netzwerkressourcenanbieter gibt z.B. 429 mit dem Fehlercode RetryableErrorDueToAnotherOperation zurück, wenn die Zielressource durch einen anderen Vorgang gesperrt ist. Um festzustellen, ob der Fehler durch die Drosselung oder eine vorübergehende Bedingung entsteht, sehen Sie sich die Fehlerdetails in der Antwort an.

Verbleibende Anforderungen

Sie können die Anzahl der verbleibenden Anforderungen durch Untersuchen der Antwortheader bestimmen. Leseanforderungen geben im Header einen Wert für die Anzahl der verbleibenden Leseanforderungen zurück. Schreibanforderungen enthalten einen Wert für die Anzahl der verbleibenden Schreibanforderungen. Die folgende Tabelle beschreibt die Antwortheader, die Sie auf diese Werte untersuchen können:

Antwortheader BESCHREIBUNG
x-ms-ratelimit-remaining-subscription-deletes Verbleibende abonnementbezogene Löschvorgänge. Dieser Wert wird für Löschvorgänge zurückgegeben.
x-ms-ratelimit-remaining-subscription-reads Verbleibende abonnementbezogene Lesevorgänge. Dieser Wert wird für Lesevorgänge zurückgegeben.
x-ms-ratelimit-remaining-subscription-writes Verbleibende abonnementbezogene Schreibvorgänge. Dieser Wert wird für Schreibvorgänge zurückgegeben.
x-ms-ratelimit-remaining-tenant-reads Verbleibende mandantenbezogene Lesevorgänge
x-ms-ratelimit-remaining-tenant-writes Verbleibende mandantenbezogene Schreibvorgänge
x-ms-ratelimit-remaining-subscription-resource-requests Verbleibende abonnementbezogene Ressourcenanforderungen.

Dieser Headerwert wird nur zurückgegeben, wenn ein Dienst den standardmäßigen Grenzwert außer Kraft gesetzt hat. Resource Manager fügt diesen Wert anstelle der Lese- oder Schreibvorgänge des Abonnements hinzu.
x-ms-ratelimit-remaining-subscription-resource-entities-read Verbleibende abonnementbezogene Ressourcensammlungsanforderungen.

Dieser Headerwert wird nur zurückgegeben, wenn ein Dienst den standardmäßigen Grenzwert außer Kraft gesetzt hat. Dieser Wert gibt die Anzahl der verbleibenden Sammlungsanforderungen an (Auflisten von Ressourcen).
x-ms-ratelimit-remaining-tenant-resource-requests Verbleibende mandantenbezogene Ressourcenanforderungen.

Dieser Header wird nur für Anforderungen auf Mandantenebene hinzugefügt, und nur dann, wenn ein Dienst den standardmäßigen Grenzwert außer Kraft gesetzt hat. Resource Manager fügt diesen Wert anstelle der Lese- oder Schreibvorgänge des Mandanten hinzu.
x-ms-ratelimit-remaining-tenant-resource-entities-read Verbleibende mandantenbezogene Ressourcensammlungsanforderungen.

Dieser Header wird nur für Anforderungen auf Mandantenebene hinzugefügt, und nur dann, wenn ein Dienst den standardmäßigen Grenzwert außer Kraft gesetzt hat.

Der Ressourcenanbieter kann auch Antwortheader mit Informationen zu verbleibenden Anforderungen zurückgeben. Informationen zu Antwortheadern, die vom Computeressourcenanbieter zurückgegeben werden, finden Sie unter Aufrufrate für Informationsantwortkopfzeilen.

Abrufen der Headerwerte

Das Abrufen dieser Headerwerte in Ihrem Code oder Skript unterscheidet sich nicht vom Abrufen anderer Headerwerte.

Beispiel: In C# rufen Sie den Headerwert aus einem HttpWebResponse-Objekt mit dem Namen response mit dem folgenden Code ab:

response.Headers.GetValues("x-ms-ratelimit-remaining-subscription-reads").GetValue(0)

In PowerShell rufen Sie den Headerwert aus einem Invoke-WebRequest-Vorgang ab.

$r = Invoke-WebRequest -Uri https://management.azure.com/subscriptions/{guid}/resourcegroups?api-version=2016-09-01 -Method GET -Headers $authHeaders
$r.Headers["x-ms-ratelimit-remaining-subscription-reads"]

Ein vollständiges PowerShell-Beispiel finden Sie unter Check ARM Limits for a Given Subscription (Überprüfen der ARM-Grenzwerte für ein bestimmtes Abonnement).

Wenn Sie zum Debuggen die übrigen Anforderungen anzeigen möchten, können Sie in Ihrem PowerShell-Cmdlet den Parameter -Debug angeben.

Get-AzResourceGroup -Debug

So wird eine Vielzahl von Werten zurückgegeben, einschließlich des folgenden Antwortwerts:

DEBUG: ============================ HTTP RESPONSE ============================

Status Code:
OK

Headers:
Pragma                        : no-cache
x-ms-ratelimit-remaining-subscription-reads: 11999

Um den Schreibgrenzwert abzurufen, verwenden Sie einen Schreibvorgang:

New-AzResourceGroup -Name myresourcegroup -Location westus -Debug

So wird eine Vielzahl von Werten zurückgegeben, einschließlich der folgenden Werte:

DEBUG: ============================ HTTP RESPONSE ============================

Status Code:
Created

Headers:
Pragma                        : no-cache
x-ms-ratelimit-remaining-subscription-writes: 1199

In der Azure-CLI rufen Sie den Headerwert mithilfe der ausführlicheren Option ab.

az group list --verbose --debug

So wird eine Vielzahl von Werten zurückgegeben, einschließlich der folgenden Werte:

msrest.http_logger : Response status: 200
msrest.http_logger : Response headers:
msrest.http_logger :     'Cache-Control': 'no-cache'
msrest.http_logger :     'Pragma': 'no-cache'
msrest.http_logger :     'Content-Type': 'application/json; charset=utf-8'
msrest.http_logger :     'Content-Encoding': 'gzip'
msrest.http_logger :     'Expires': '-1'
msrest.http_logger :     'Vary': 'Accept-Encoding'
msrest.http_logger :     'x-ms-ratelimit-remaining-subscription-reads': '11998'

Um den Schreibgrenzwert abzurufen, verwenden Sie einen Schreibvorgang:

az group create -n myresourcegroup --location westus --verbose --debug

So wird eine Vielzahl von Werten zurückgegeben, einschließlich der folgenden Werte:

msrest.http_logger : Response status: 201
msrest.http_logger : Response headers:
msrest.http_logger :     'Cache-Control': 'no-cache'
msrest.http_logger :     'Pragma': 'no-cache'
msrest.http_logger :     'Content-Length': '163'
msrest.http_logger :     'Content-Type': 'application/json; charset=utf-8'
msrest.http_logger :     'Expires': '-1'
msrest.http_logger :     'x-ms-ratelimit-remaining-subscription-writes': '1199'

Nächste Schritte