Verstehen, wie Anforderungen durch Azure Resource Manager gedrosselt werden

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.

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.

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:

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.

Netzwerkdrosselung

Der Ressourcenanbieter Microsoft.Network wendet die folgenden Drosselungsgrenzwerte an:

Zusätzlich zu diesen allgemeinen Grenzwerten gelten noch die Nutzungsgrenzwerte für Azure DNS.

Computedrosselung

Microsoft Compute implementiert die Drosselung, um Benutzern virtueller Computer und von VM-Skalierungsgruppen ein optimales Erlebnis zu bieten. Grenzwerte für die Computedrosselung bietet umfassende Informationen zu Drosselungsrichtlinien und -grenzwerten für virtuelle Computer, VM-Skalierungsgruppen und Skalierungsgruppen-VMs.

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:

• Anleitung zur Drosselung von Azure Key Vault
• AKS-Problembehandlung
• Verwaltete Identitäten

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:

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

• Weitere Informationen zu Grenzwerten und Kontingenten finden Sie unter Einschränkungen für Azure-Abonnements und Dienste, Kontingente und Einschränkungen.
• Informationen zum Arbeiten mit asynchronen REST-Anforderungen finden Sie unter Nachverfolgen asynchroner Vorgänge in Azure.