Устранение проблем с доступностью в учетных записях хранения 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 операций timeout" от операций хранения.

Примечание.

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

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

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

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

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

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

См. также

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

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