Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Применимо к: ✔️ виртуальные машины Linux ✔️ виртуальные машины Windows ✔️ гибкие наборы масштабирования ✔️ унифицированные наборы масштабирования
Microsoft Compute реализует механизм регулирования для обеспечения общей производительности службы и обеспечения согласованного взаимодействия с клиентами. Запросы API, превышающие максимальные допустимые ограничения, ограничиваются, и пользователи получают ошибку HTTP 429. Все политики ограничения вычислительных ресурсов реализуются в каждом отдельном регионе.
Как работают политики регулирования?
Microsoft Compute реализует политики регулирования, ограничивающие количество запросов API, сделанных на ресурс и на подписку в каждом регионе в минуту. Если количество запросов API превышает эти ограничения, запросы ограничиваются. Вот как работают следующие ограничения:
Ограничение для каждого ресурса — каждый ресурс, например виртуальная машина, имеет определенный лимит на запросы API. Например, предположим, что пользователь создает 10 виртуальных машин в подписке. Пользователь может вызывать до 12 запросов на обновление каждой виртуальной машины за одну минуту. Если пользователь превышает лимит для виртуальной машины, запросы API ограничиваются. Это ограничение гарантирует, что некоторые ресурсы не исчерпывают лимиты уровня подписки и не ограничивают доступность других ресурсов.
Ограничение подписки . Помимо ограничений ресурсов, существует избыточное ограничение на количество запросов API для всех ресурсов в подписке. Все запросы API, превышающие это ограничение, регулируются независимо от того, достигнуто ли ограничение для отдельного ресурса. Например, предположим, что у пользователя есть 200 виртуальных машин в подписке. Несмотря на то, что пользователь имеет право инициировать до 12 запросов на обновление виртуальной машины для каждой виртуальной машины, агрегированное ограничение для запросов API обновления виртуальных машин ограничено на 1500 в минуту. Запросы API обновления виртуальных машин, количество которых превышает 1500 для подписки, ограничиваются.
Как Microsoft Compute определяет ограничения пропускной способности?
Чтобы определить ограничения для каждого ресурса и подписки, microsoft Compute использует алгоритм контейнера маркеров. Этот алгоритм создает контейнеры для каждого ограничения и содержит определенное количество маркеров в каждом контейнере. Количество токенов в контейнере определяет лимит дросселирования в любую минуту.
В начале периода регулирования при создании ресурса контейнер заполняется максимальной емкостью. Каждый запрос API, инициированный пользователем, использует один маркер. Когда количество токенов уменьшается до нуля, последующие запросы API ограничиваются. Контейнер (ведро) пополняется новыми токенами каждую минуту с постоянной частотой, называемой Частота пополнения ведра, для ресурса и подписки.
Например: Давайте рассмотрим "политику регулирования для API обновления виртуальной машины", которая предусматривает частоту пополнения контейнера в четыре токена в минуту и максимальную емкость контейнера — 12 токенов. Пользователь делает запрос к API обновления виртуальной машины в соответствии со следующей таблицей. Изначально контейнер заполняется 12 маркерами в начале окна регулирования. К четвертой минуте пользователь использует все 12 маркеров, оставляя контейнер пустым. В пятой минуте контейнер пополнен четырьмя новыми токенами в соответствии со скоростью повторного заполнения контейнера. Таким образом, четыре запроса API могут выполняться в пятой минуте, когда Microsoft Compute регулирует один запрос API из-за недостатка токенов.
| (мин) | первый | Второй | Третий | 4-е | 5-й | 6-е |
|---|---|---|---|---|---|---|
| Число токенов в начале (A) | 12 | 12 | 8 | 12 | 4 | 4 |
| Запросы в минуту (B) | 0 | 8 | 0 | 13 (тринадцать) | 5 | 0 |
| Ограниченные запросы (C) | 0 | 0 | 0 | 1 | 1 | 0 |
| Оставшиеся маркеры в конце периода D = Max(A-B, 0) |
12 | 4 | 8 | 0 | 0 | 4 |
Аналогичный процесс следует за определением ограничений регулирования на уровне подписки. В следующих разделах подробно описаны скорость наполнения ведра и максимальная емкость ведра, которые используются для определения ограничений пропускной способности для Виртуальных машин, Масштабируемых наборов виртуальных машин и Виртуальных Машин в масштабируемых наборах.
Ограничения регулирования для Виртуальные машины
Запросы API для Виртуальные машины классифицируются по семи отдельным политикам. Каждая политика имеет собственные ограничения в зависимости от того, насколько ресурсоемкие запросы API в этой политике. В следующей таблице содержится полный список этих политик, соответствующих интерфейсов REST API и их ограничений скорости.
| Категория политики | REST API-интерфейсы | уровень ресурса. | уровень ресурса. | Уровень подписки | Уровень подписки |
|---|---|---|---|---|---|
| Частота повторного заполнения контейнера (за мин) | Максимальная емкость контейнера (за минуту) |
Частота повторного заполнения контейнера (за минуту) |
Максимальная емкость контейнера (за минуту) |
||
| Размещение виртуальной машины (Создание новых виртуальных машин) |
Создать | 4 | 12 | 500 | 1,500 |
| Обновление виртуальной машины (Обновление существующих виртуальных машин) |
Обновлять Повторное применениеПерезагрузка Выключение Начало Обобщение Преобразование в управляемые диски Повторное развертывание Выполнить обслуживание Запись Команда "Выполнить" Создание или обновление Расширения — обновление Расширения — удаление reimage Обновлять Выполнение команд — обновление Выполнение команд — удаление Команды запуска — создание или обновление |
4 | 12 | 500 | 1,500 |
| Удаление виртуальной машины (Удаление виртуальных машин) |
Удалить Имитация вытеснения Освободить |
4 | 12 | 500 | 1,500 |
| Низкая стоимость получения виртуальной машины (Получение сведений об одной виртуальной машине) |
Получить Представление экземпляра Расширения — Получение Список доступных размеров Получение данных диагностики загрузки Выполнение команд - Получение через виртуальную машину Команды запуска — список по виртуальным машинам |
12 | 36 | 8000 | 24,000 |
| Высокая стоимость получения виртуальной машины1 (Получение сведений о нескольких виртуальных машинах) |
Список Список всех Список по расположению |
NA | NA | 300 | 900 |
| Операция Get (Получение сведений об асинхронных операциях виртуальной машины) |
Состояние асинхронных операций | 15 | 45 | 5 000 | 15 000 |
| Операции по исправлению гостевых систем виртуальной машины (Оценка и установка гостевых исправлений) |
Оценка исправлений Установка исправлений |
2 | 6 | 200 | 600 |
1 Применимы только политики уровня подписки.
Ограничения на ограничение скорости для масштабируемых наборов виртуальных машин
Запросы API для масштабируемого набора виртуальных машин (унифицированные и гибкие) классифицируются по 5 отдельным политикам. Каждая политика имеет собственные ограничения в зависимости от того, насколько ресурсоемкие запросы API в этой политике. Эти политики применимы как к режимам оркестрации Flex, так и к режиму оркестрации Uniform. В следующей таблице приведён полный список этих политик, соответствующих интерфейсов REST API и их соответствующих ограничений частоты запросов:
| Категория политики | REST API-интерфейсы | уровень ресурса. | уровень ресурса. | Уровень подписки | Уровень подписки |
|---|---|---|---|---|---|
| Частота повторного заполнения контейнера (за минуту) |
Максимальная емкость контейнера (за минуту) |
Частота повторного заполнения контейнера (за мин) | Максимальная емкость контейнера (за мин) |
||
| Поместить (Создание нового масштабируемого набора) |
Создать | 4 | 12 | 125 | 375 |
| Обновление (Обновление существующего масштабируемого набора) |
Обновлять Начало2 Перезапуск2 Повторное развертывание2 Выполнение обслуживания2 Reimage2 Reimage All2 Создание или обновление Пошаговые обновления — отмена Расширения — создание Расширения — обновление Расширения — удаление Принудительный проход обновления домена платформы Service Fabric Преобразование в единую группу размещения Установить состояние службы оркестрации |
4 | 12 | 500 | 1,500 |
| Удалить (Удаление набора масштабирования) |
Удалить Power Off2 Освободить |
4 | 12 | 175 | 525 |
| Низкая стоимость приобретения Получение сведений о наборе параметров масштабирования |
Получить Список Артикулов Последовательное обновление — получение последних версий Получение журнала обновления ОС |
12 | 36 | 800 | 2,400 |
| Высокая стоимость (Получение сведений о ресурсоемких ресурсах) |
Получение представления экземпляра Список2 Список всех2 Список по расположению2 |
10 | 30 | 360 | 1,080 |
2 Применимы только политики уровня подписки.
Ограничения регулирования для масштабируемого набора виртуальных машин
Запросы к API для набора масштабируемых виртуальных машин классифицируются по 3 различным политикам. Каждая политика имеет собственные ограничения в зависимости от того, насколько ресурсоемкие запросы API в этой политике. В следующей таблице приведён полный список этих политик, соответствующих интерфейсов REST API и их соответствующих ограничений частоты запросов:
| Категория политики | REST API-интерфейсы | уровень ресурса. | уровень ресурса. | Уровень подписки | Уровень подписки |
|---|---|---|---|---|---|
| Частота повторного заполнения контейнера (в минуту) |
Максимальная емкость контейнера (за минуту) |
Частота повторного заполнения контейнера (за мин) |
Максимальная емкость контейнера (за минуту) |
||
| Обновление набора виртуальных машин для масштабирования (Обновление существующих виртуальных машин в масштабируемом наборе) |
Начало перезапуск reimage ReimageAll Обновлять Имитация выселения Расширения— создание или обновление RunCommands — создание или обновление RunCommands — обновление |
4 | 12 | 500 | 1,500 |
| Удалите виртуальные машины масштабируемого набора (Удаление виртуальных машин масштабируемого набора) |
Удалить PowerOff Освободить Расширения— удаление RunCommands — Delete |
4 | 12 | 500 | 1,500 |
| Получить виртуальные машины в рамках набора для масштабируемости (Получение сведений о виртуальных машинах масштабируемого набора) |
Получить Представление GetInstance Расширения— Загрузка RunCommands — Get Получение данных диагностикиBoot |
12 | 36 | 2 000 | 6000 |
Рекомендации по устранению неполадок
Если пользователи по-прежнему сталкиваются с проблемами из-за регулирования вычислений, обратитесь к статье об устранении неполадок регулирования в Azure — Виртуальные машины. В ней содержатся сведения о том, как устранять проблемы, связанные с ограничением производительности, а также рекомендации по предотвращению таких ограничений.
Вопросы и ответы
Требуется ли какое-либо действие от пользователей?
Пользователям не нужно ничего изменять в конфигурации или рабочих нагрузках. Все существующие API продолжают работать так же.
Какие преимущества предоставляют политики ограничения пропускной способности?
Политики ограничения пропускной способности предлагают несколько преимуществ:
Все вычислительные ресурсы имеют единое окно в 1 минуту. Пользователи могут успешно делать вызовы API через 1 минуту после ограничения доступа.
Ни один ресурс не может использовать все ограничения в подписке, так как ограничения определяются на уровне ресурсов.
Microsoft Compute вводит новый алгоритм, алгоритм маркерного ведра, для определения ограничений. Алгоритм предоставляет дополнительный буфер клиентам, делая большое количество запросов API.
Получает ли клиент оповещение, когда они собираются достичь своих ограничений пропускной способности?
В рамках каждого ответа Microsoft Compute возвращает x-ms-ratelimit-remaining-resource, который можно использовать для определения пределов пропускной способности в соответствии с политиками. Список применимых политик регулирования возвращается в виде ответа на заголовки с информацией о скорости вызова.