Устранение неполадок доступности в учетных записях хранения Azure

  • Статья

В этой статье описаны изменения доступности (например, количество неудачных запросов). Эти изменения в доступности часто можно определить, отслеживая метрики хранилища в Azure Monitor. Общие сведения об использовании метрик и журналов в Azure Monitor см. в следующих статьях:

Отслеживание доступности

Для мониторинга доступности служб хранилища в учетной записи хранения отслеживайте значение метрики Доступность. Метрика доступности содержит процентное значение. Он вычисляется, принимая общее значение оплачиваемых запросов и разделяя его на количество применимых запросов, включая те запросы, которые вызвали непредвиденные ошибки.

Если значение меньше 100 %, это означает, что некоторые запросы к хранилищу не были выполнены. Вы можете увидеть, почему они завершаются ошибкой, проверив измерение ResponseType для типов ошибок, таких как ServerTimeoutError. Вы должны ожидать , что доступность падает временно ниже 100 % по таким причинам, как временные время ожидания сервера, в то время как служба перемещает секции для повышения балансировки нагрузки, а логика повторных попыток в клиентском приложении должна обрабатывать такие временные условия. Метрика доступности будет доступна только в течение временных периодов, когда транзакции также происходят в учетной записи.

Вы можете использовать функции в Azure Monitor для оповещения о том, что величина Доступности службы опустилась ниже указанного порогового значения.

Метрики показывают увеличение числа ошибок регулирования

Ошибки регулирования происходят при превышении целевых показателей масштабируемости для службы хранилища. Регулирование службы хранилища происходит для того, чтобы ни один из клиентов не мог использовать службу хранилища в ущерб другим. Дополнительные сведения о целевых показателях масштабируемости для учетных записей хранилища и целевых показателях производительности для секций внутри учетных записей хранения см. в разделе Целевые показатели производительности и масштабируемости для стандартных учетных записей хранения.

Если значение ClientThrottlingError или ServerBusyError измерения ResponseType показывает увеличение процента запросов, при выполнении которых возникли ошибки регулирования, необходимо проверить два сценария:

  • Временное увеличение значения PercentThrottlingError
  • Постоянное увеличение значения PercentThrottlingError

Увеличение ошибок регулирования часто происходит одновременно с увеличением количества запросов на хранение или при первоначальном нагрузочном тестировании приложения. Это также может проявляться в получении сообщений о состоянии HTTP 503 "Сервер занят" или 500 "Время ожидания операции истекло" в клиенте при операциях с хранилищем.

Временное увеличение числа ошибок регулирования

Если вы видите пики в ошибках регулирования, которые совпадают с периодами высокой активности для приложения, вы реализуете экспоненциальную стратегию отката (а не линейной) для повторных попыток в клиенте. Обратные повторные попытки снижают немедленную нагрузку на секцию и помогают приложению сглаживать пики трафика. Дополнительные сведения о том, как реализовать политики повтора с помощью клиентской библиотеки хранилища, см. в описании свойства RetryOptions.MaxRetries.

Примечание.

Вы также можете увидеть пики в ошибках регулирования, которые не совпадают с периодами высокой активности для приложения. Скорее всего, служба хранилища перемещает секции для улучшения балансировки нагрузки.

Постоянное увеличение числа ошибок регулирования

Если вы видите согласованное значение для регулирования ошибок после постоянного увеличения объема транзакций или при выполнении первоначальных нагрузочных тестов в приложении, необходимо оценить, как приложение использует секции хранилища и подходит ли оно к целевым объектам масштабируемости для учетной записи хранения. Например, если вы видите ошибки регулирования в очереди (которая считается одной секцией), рекомендуется использовать дополнительные очереди для распределения транзакций по нескольким секциям. Если в таблице возникают ошибки регулирования, рекомендуется использовать другую схему секционирования для распределения транзакций по нескольким секциям с помощью более широкого диапазона значений ключа секции. Одной из распространенных причин этой проблемы является предустановка или добавление антишаблоны, где вы выбираете дату в качестве ключа секции, а затем все данные в определенный день записываются в одну секцию (при загрузке это может привести к узким местам записи). Рассмотрим другую структуру секционирования или оцените, может ли использовать хранилище BLOB-объектов лучшее решение. Кроме того, проверьте, происходит ли регулирование из-за пиков трафика и изучите способы сглаживания шаблона запросов.

Если транзакции распределяются между несколькими разделами, следует тем не менее учитывать предельные значения масштабируемости, установленные для учетной записи хранения. Например, если вы использовали 10 очередей, каждая обработка не более 2000 1 КБ сообщений в секунду, вы будете иметь общий предел в 20 000 сообщений в секунду для учетной записи хранения. Если необходимо обработать более 20 000 сущностей в секунду, рассмотрите возможность использования нескольких учетных записей хранения. Также следует помнить, что размер ваших запросов и сущностей влияет на то, что служба хранения регулирует клиентов. Если у вас есть более крупные запросы и сущности, вы можете регулироваться раньше.

Неэффективная структура запросов также может привести к достижению предельных значений масштабируемости для разделов таблицы. Например, запросу с фильтром, выбирающим только один процент объектов в разделе, но сканирующим все объекты, потребуется обращаться к каждому объекту. Каждое чтение сущности будет учитывать общее количество транзакций в этой секции. Таким образом, можно легко достичь целевых показателей масштабируемости.

Примечание.

Неэффективная структура запросов должна выявляться при тестировании производительности приложения.

Метрики показывают увеличение числа ошибок с превышением времени ожидания

Ошибки времени ожидания возникают, когда измерение ResponseType равно ServerTimeoutError или ClientTimeout.

Ваши метрики показывают увеличение числа ошибок времени ожидания для одной из служб хранилища. В то же время клиент может получать большое число сообщений о состоянии HTTP 500 "Время ожидания операции истекло" при операциях с хранилищем.

Примечание.

Ошибки времени ожидания могут возникать временно, когда служба хранилища выполняет балансировку нагрузки запросов, перемещая раздел на новый сервер.

Ошибки времени ожидания сервера (ServerTimeOutError) вызваны ошибкой на сервере. Время ожидания клиента (ClientTimeout) происходит, так как операция на сервере превысила время ожидания, указанное клиентом. Например, клиент с помощью клиентской библиотеки хранилища может задать время ожидания для операции.

Ошибки времени ожидания сервера указывают на проблему со службой хранилища, которая требует дальнейшего изучения. Вы можете использовать метрики, чтобы узнать, достигается ли ограничение масштабируемости для службы и определить пики трафика, которые могут вызвать эту проблему. Если проблема возникает периодически, она может быть вызвана балансировкой нагрузки в службе. Если проблема постоянна и не вызвана ограничением масштабируемости службы, следует вызвать проблему поддержки. Для времени ожидания клиента необходимо определить, задано ли время ожидания соответствующим значением в клиенте, а также изменить значение времени ожидания, заданное в клиенте, или изучить, как повысить производительность операций в службе хранилища, например, оптимизируя запросы таблиц или уменьшая размер сообщений.

Метрики показывают увеличение числа ошибок сети

Ошибки сети возникают, когда измерение ResponseType равно NetworkError. Это происходит, когда служба хранилища обнаруживает ошибку сети при выполнении клиентом запроса к хранилищу.

Наиболее распространенной причиной этой ошибки является отключение клиента, прежде чем в службе хранилища истекает время ожидания. Изучите код клиента, чтобы понять, когда и почему клиент отключается от службы хранилища. Вы также можете использовать сторонние инструменты анализа сети для изучения проблем с сетевым подключением на клиенте.

См. также

Свяжитесь с нами для получения помощи

Если у вас есть вопросы или помощь, создайте запрос на поддержку или попросите сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.