Ismerje meg, hogyan szabályozza az Azure Resource Manager a kéréseket

  • Cikk

Ez a cikk azt ismerteti, hogyan szabályozza az Azure Resource Manager a kéréseket. Bemutatja, hogyan követheti nyomon a korlát elérése előtt maradó kérések számát, és hogyan válaszolhat a korlát elérésekor.

A szabályozás két szinten történik. Az Azure Resource Manager az előfizetésre és a bérlőre vonatkozóan szabályozza a kéréseket. Ha a kérés az előfizetésre és a bérlőre vonatkozó szabályozási korlátok alatt marad, a Resource Manager az erőforrás-szolgáltatóhoz irányítja a kérést. Az erőforrás-szolgáltató a műveleteihez igazított szabályozási korlátokat alkalmaz.

Az alábbi képen látható, hogy a rendszer hogyan alkalmazza a szabályozást, amikor egy kérés a felhasználótól az Azure Resource Managerhez és az erőforrás-szolgáltatóhoz kerül. A képen látható, hogy a kérések kezdetben szabályozva vannak az egyszerű azonosítónként és az Azure Resource Manager-példányonként a kérést küldő felhasználó régiójában. A kérések óránként vannak szabályozva. Amikor a kérést az erőforrás-szolgáltatónak továbbítja, a kérések szabályozása az erőforrás régiója szerint történik, nem pedig a felhasználó régiójában lévő Azure Resource Manager-példányonként. Az erőforrás-szolgáltatói kérelmeket az egyszerű felhasználói azonosítók és óránként is szabályozza a rendszer.

Az a diagram, amely bemutatja, hogy a rendszer hogyan alkalmazza a szabályozást a kérések során, a felhasználótól az Azure Resource Managerhez és az erőforrás-szolgáltatóhoz kerül.

Előfizetési és bérlői korlátok

Minden előfizetési és bérlői szintű műveletre szabályozási korlátozások vonatkoznak. Az előfizetési kérelmek olyan kérések, amelyek magukban foglalják az előfizetés azonosítójának átadását, például az előfizetésben lévő erőforráscsoportok lekérését. A kérés https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups?api-version=2022-01-01 küldése például előfizetési szintű művelet. A bérlői kérelmek nem tartalmazzák az előfizetés azonosítóját, például az érvényes Azure-helyek lekérését. A kérések https://management.azure.com/tenants?api-version=2022-01-01 elküldése például bérlőszintű művelet.

Az alapértelmezett óránkénti szabályozási korlátok az alábbi táblázatban vannak feltüntetve.

Hatókör Üzemeltetés Korlát
Előfizetés olvasások 12000
Előfizetés törlések 15 000
Előfizetés írások 1200
Bérlő olvasások 12000
Bérlő írások 1200

Ezeknek a korlátoknak a hatóköre a kéréseket intéző rendszerbiztonsági tag (felhasználó vagy alkalmazás) és az előfizetés azonosítója vagy a bérlő azonosítója. Ha a kérések több rendszerbiztonsági tagból érkeznek, akkor az előfizetésben vagy a bérlőben a korlát nagyobb, mint óránként 12 000 olvasás és 1200 írás.

Ezek a korlátozások minden Azure Resource Manager-példányra vonatkoznak. Minden Azure-régióban több példány van, és az Azure Resource Manager minden Azure-régióban üzembe van helyezve. A gyakorlatban tehát a korlátok magasabbak, mint ezek a korlátok. A felhasználó kéréseit általában az Azure Resource Manager különböző példányai kezelik.

A fennmaradó kéréseket a rendszer a válaszfejléc értékeiben adja vissza.

Migrálás regionális szabályozásra és tokengyűjtő algoritmusra

A Microsoft 2024-től kezdve egy új szabályozási architektúrába migrálja az Azure-előfizetéseket. Ezzel a módosítással új szabályozási korlátokat tapasztalhat. Az új szabályozási korlátokat régiónként alkalmazza a rendszer az Azure Resource Manager-példányok helyett. Az új architektúra jogkivonat-gyűjtő algoritmussal kezeli az API-szabályozást.

A jogkivonat gyűjtője az egyes másodpercenként küldhető kérelmek maximális számát jelöli. Amikor eléri a kérelmek maximális számát, az újratöltési sebesség határozza meg, hogy milyen gyorsan válnak elérhetővé a jogkivonatok a gyűjtőben.

Ezek a frissített korlátok megkönnyítik a kvóta frissítését és kezelését.

Az új korlátok a következők:

Hatókör Üzemeltetés Gyűjtő mérete Feltöltési sebesség másodpercenként
Előfizetés olvasások 250 25
Előfizetés törlések 200 10
Előfizetés írások 200 10
Bérlő olvasások 250 25
Bérlő törlések 200 10
Bérlő írások 200 10

Az előfizetési korlátok előfizetésenként, szolgáltatásnévenként és művelettípusonként érvényesek. Vannak olyan globális előfizetési korlátok is, amelyek az egyes művelettípusokhoz tartozó egyedi szolgáltatásnévkorlát 15-szörösével egyenértékűek. A globális korlátok az összes szolgáltatásnévre vonatkoznak. A kérelmek szabályozva lesznek, ha túllépik a globális, a szolgáltatásnév vagy a bérlőspecifikus korlátokat.

A korlátozások kisebbek lehetnek az ingyenes vagy próbaverziós ügyfelek számára.

Tegyük fel például, hogy 250 token méretű gyűjtővel rendelkezik az olvasási kérelmekhez, és másodpercenként 25 tokent tölt újra. Ha 250 olvasási kérést küld egy másodperc alatt, a gyűjtő üres, és a kérések szabályozva vannak. Másodpercenként 25 jogkivonat válik elérhetővé, amíg a gyűjtő el nem éri a 250 token maximális kapacitását. A jogkivonatokat az elérhetővé válásukkor használhatja.

Hogyan tudom, hogy az előfizetésem az új szabályozási felületet használja-e?

Miután az előfizetést áttelepíti az új szabályozási felületre, a válaszfejléc óránként helyett percenként jeleníti meg a fennmaradó kéréseket. Emellett az Retry-After érték öt perc helyett egy percet vagy kevesebbet jelenít meg. További információ: Hibakód.

Miért változik a szabályozás régiónként és nem példányonként?

Mivel a különböző régiókban eltérő számú Resource Manager-példány van, a példányonkénti szabályozás inkonzisztens szabályozást eredményez. A szabályozás régiónként konzisztenssé és kiszámíthatóvá teszi a szabályozást.

Hogyan befolyásolja az új szabályozási felület a korlátaimat?

További kéréseket is küldhet. Az írási kérelmek száma 30-szorosára nő. A törlési kérelmek száma 2,4-szeresére nő. Az olvasási kérelmek száma 7,5-szeresére nő.

Megakadályozhatom, hogy az előfizetésem áttelepüljön az új szabályozási felületre?

Nem, az összes előfizetés végül migrálva lesz.

Erőforrás-szolgáltatói korlátok

Az erőforrás-szolgáltatók a saját szabályozási korlátaikat alkalmazzák. Az egyes előfizetésekben az erőforrás-szolgáltató szabályozza a kérelemben szereplő erőforrás régióit. Mivel a Resource Manager a Resource Manager példánya szerint szabályoz, és az egyes régiókban több Resource Manager-példány is található, előfordulhat, hogy az erőforrás-szolgáltató több kérést kap, mint az előző szakaszban megadott alapértelmezett korlátok.

Ez a szakasz néhány széles körben használt erőforrás-szolgáltató szabályozási korlátait ismerteti.

Tárterület-szabályozás

Az alábbi korlátozások csak azokra az esetekre vonatkoznak, amikor felügyeleti műveleteket hajt végre az Azure Resource Manager és az Azure Storage használatával. A korlátok az erőforrás régióira vonatkoznak a kérelemben.

Erőforrás Korlát
Tárfiókkezelési műveletek (olvasás) 5 percenként 800
Tárfiókkezelési műveletek (írás) 10 másodpercenként / 1200 óránként
Tárfiókkezelési műveletek (listázás) 5 percenként 100

Hálózati szabályozás

A Microsoft.Network erőforrás-szolgáltató az alábbi szabályozási korlátokat alkalmazza:

Művelet Korlát
írás / törlés (PUT) 1000/5 perc
olvasás (GET) 10000/5 perc

Ezen általános korlátok mellett a DNS-műveletekre a következő korlátozások vonatkoznak:

DNS-zónaművelet Korlát (zónánként)
Létrehozás vagy frissítés 40 percenként
Törlés 40 percenként
Beolvasás 1000 percenként
Lista 60 percenként
Lista erőforráscsoport szerint 60 percenként
Frissítés 40 percenként
DNS-rekordhalmaz-művelet Korlát (zónánként)
Létrehozás vagy frissítés 200 percenként
Törlés 200 percenként
Beolvasás 2000 percenként
Listázás DNS-zóna szerint 60 percenként
Lista típus szerint 60 percenként
Frissítés 200 percenként

Számítási szabályozás

A számítási műveletek szabályozási korlátairól további információt az API szabályozási hibáinak hibaelhárítása – Számítás című témakörben talál.

A virtuálisgép-méretezési csoportban lévő virtuálisgép-példányok ellenőrzéséhez használja a virtuálisgép-méretezési csoportok műveleteit. A virtuálisgép-példányok energiaállapotának ellenőrzéséhez használja például a virtuálisgép-méretezési csoport virtuális gépeit – A paramétereket tartalmazó lista . Ez az API csökkenti a kérések számát.

Azure Resource Graph-szabályozás

Az Azure Resource Graph korlátozza a műveletekre irányuló kérések számát. A cikkben szereplő lépések a fennmaradó kérések meghatározására és a korlát elérésekor történő válaszadásra is vonatkoznak a Resource Graph-ra. A Resource Graph azonban beállítja a saját korlátját és alaphelyzetbe állítási sebességét. További információ: Resource Graph-szabályozási fejlécek.

Egyéb erőforrás-szolgáltatók

További információ a más erőforrás-szolgáltatók szabályozásáról:

Hibakód

Ha eléri a korlátot, a HTTP-állapotkód 429 Túl sok kérést kap. A válasz tartalmaz egy újrapróbálkozási értéket , amely meghatározza, hogy az alkalmazás hány másodpercet várjon (vagy aludjon) a következő kérés elküldése előtt. Ha az újrapróbálkozás értéke előtt küld egy kérést, a rendszer nem dolgozza fel a kérést, és új újrapróbálkozást ad vissza.

Ha Azure SDK-t használ, előfordulhat, hogy az SDK automatikus újrapróbálkozásos konfigurációval rendelkezik. További információ: Újrapróbálkozás az Azure-szolgáltatásokhoz.

Egyes erőforrás-szolgáltatók 429-et adnak vissza, hogy átmeneti problémát jelentsenek. A probléma lehet egy túlterhelési feltétel, amelyet nem közvetlenül a kérés okoz. Vagy a célerőforrás vagy a függő erőforrás állapotával kapcsolatos átmeneti hibát is jelenthet. A hálózati erőforrás-szolgáltató például a 429-et adja vissza a RetryableErrorDueToAnotherOperation hibakóddal, ha a célerőforrást egy másik művelet zárolja. Annak megállapításához, hogy a hiba szabályozásból vagy átmeneti állapotból származik-e, tekintse meg a hiba részleteit a válaszban.

Fennmaradó kérések

A fennmaradó kérések számát a válaszfejlécek vizsgálatával határozhatja meg. Az olvasási kérelmek a fejlécben a fennmaradó olvasási kérelmek számának értékét adja vissza. Az írási kérelmek tartalmazzák a fennmaradó írási kérelmek számának értékét. Az alábbi táblázat azokat a válaszfejléceket ismerteti, amelyeket ezekre az értékekre megvizsgálhat:

Válaszfejléc Leírás
x-ms-ratelimit-remaining-subscription-deletes Az előfizetés hatóköre a fennmaradó törléseket törli. Ez az érték a törlési műveletek során lesz visszaadva.
x-ms-ratelimit-remaining-subscription-reads Az előfizetés hatókörébe tartozó olvasások megmaradnak. Ez az érték olvasási műveletek esetén lesz visszaadva.
x-ms-ratelimit-remaining-subscription-writes Az előfizetés hatókörébe tartozó írások megmaradnak. Ez az érték írási műveletek esetén lesz visszaadva.
x-ms-ratelimit-remaining-tenant-reads A bérlő hatókörében lévő olvasási adatok megmaradnak
x-ms-ratelimit-remaining-tenant-writes A bérlő hatókörében lévő írások megmaradnak
x-ms-ratelimit-remaining-subscription-resource-requests Az előfizetés hatókörébe tartozó erőforrástípusra vonatkozó kérések továbbra is megmaradnak.

Ez a fejlécérték csak akkor lesz visszaadva, ha egy szolgáltatás felülírja az alapértelmezett korlátot. A Resource Manager ezt az értéket adja hozzá az előfizetés olvasása vagy írása helyett.
x-ms-ratelimit-remaining-subscription-resource-entities-read Az előfizetés hatókörébe tartozó erőforrástípus-gyűjtési kérelmek továbbra is megmaradnak.

Ez a fejlécérték csak akkor lesz visszaadva, ha egy szolgáltatás felülírja az alapértelmezett korlátot. Ez az érték a fennmaradó gyűjteménykérések számát adja meg (erőforrások listázása).
x-ms-ratelimit-remaining-tenant-resource-requests A bérlő hatókörébe tartozó erőforrástípusra vonatkozó kérések továbbra is megmaradnak.

Ez a fejléc csak bérlői szintű kérésekhez lesz hozzáadva, és csak akkor, ha egy szolgáltatás felülírja az alapértelmezett korlátot. A Resource Manager ezt az értéket adja hozzá a bérlő olvasása vagy írása helyett.
x-ms-ratelimit-remaining-tenant-resource-entities-read A bérlő hatókörébe tartozó erőforrástípus-gyűjtési kérelmek továbbra is megmaradnak.

Ez a fejléc csak bérlői szintű kérésekhez lesz hozzáadva, és csak akkor, ha egy szolgáltatás felülírja az alapértelmezett korlátot.

Az erőforrás-szolgáltató válaszfejléceket is visszaadhat a fennmaradó kérelmekkel kapcsolatos információkkal. A számítási erőforrás-szolgáltató által visszaadott válaszfejlécekről további információt a Hívássebesség információs válaszfejlécei című témakörben talál.

A fejlécértékek beolvasása

Ezeknek a fejlécértékeknek a beolvasása a kódban vagy a szkriptben nem különbözik a fejlécértékek beolvasásánál.

A C#-ban például lekéri a fejléc értékét egy Válasz nevű HttpWebResponse objektumból a következő kóddal:

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

A PowerShellben lekéri a fejléc értékét egy Invoke-WebRequest műveletből.

$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"]

Egy teljes PowerShell-példaért tekintse meg az előfizetés Resource Manager-korlátainak ellenőrzése című témakört.

Ha meg szeretné tekinteni a további hibakeresési kérelmeket, megadhatja a -Debug paramétert a PowerShell-parancsmagon .

Get-AzResourceGroup -Debug

Amely számos értéket ad vissza, beleértve a következő válaszértéket:

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

Status Code:
OK

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

Írási korlátok lekéréséhez használjon írási műveletet:

New-AzResourceGroup -Name myresourcegroup -Location westus -Debug

Amely számos értéket ad vissza, beleértve a következő értékeket:

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

Status Code:
Created

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

Az Azure CLI-ben a fejléc értékét a részletesebb beállítással kell lekérni.

az group list --verbose --debug

Amely számos értéket ad vissza, beleértve a következő értékeket:

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'

Írási korlátok lekéréséhez használjon írási műveletet:

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

Amely számos értéket ad vissza, beleértve a következő értékeket:

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'

Következő lépések