Поделиться через

Контрольный список для обеспечения устойчивости конкретных служб Azure

  • Статья

Устойчивость представляет собой возможность восстановления системы после сбоев и продолжения работы. Каждая технология имеет собственные режимы сбоев, которые необходимо учитывать при разработке и реализации приложения. Используйте этот контрольный список для проверки факторов устойчивости конкретных служб Azure. Дополнительные сведения о проектировании устойчивых приложений см. в разделе Разработка надежных приложений Azure.

Служба приложений

Используйте уровень "Стандарт" или "Премиум". Эти уровни поддерживают промежуточные слоты и автоматическое резервное копирование. Дополнительные сведения см. в статье Подробный обзор планов службы приложений Azure.

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

Сохраняйте конфигурацию в виде настроек приложений. Используйте настройки приложения, чтобы сохранить параметры конфигурации в качестве настроек приложения. Определите параметры в шаблонах Resource Manager или с помощью PowerShell, чтобы применить их в процессе автоматического развертывания или обновления. Этот подход надежнее. Дополнительные сведения см. в статье Настройка веб-приложений в службе приложений Azure.

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

Отделите веб-приложения от веб-API. Если в решении есть как веб-интерфейс, так и веб-API, рассмотрите возможность их разбивки на отдельные приложения Службы приложений. Такой подход помогает распределять решения по рабочим нагрузкам. Вы можете запускать веб-приложение и API в отдельных планах службы приложений, чтобы они могли масштабироваться независимо друг от друга. Если изначально этот уровень масштабируемости не требуется, можно развертывать приложения в одном плане и позже переместить их в отдельные планы (при необходимости).

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

Избегайте использования функции резервного копирования службы приложений для резервного копирования баз данных Azure SQL. Вместо этого используйте автоматическое резервное копирование базы данных SQL. При резервном копировании службы приложений база данных экспортируется в BACPAC-файл SQL, что требует DTU.

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

Предназначенный для хранения последнего развертывания, признанного корректным (LKG), создайте специальный слот развертывания. При развертывании обновления в рабочей среде переместите предыдущее рабочее развертывание в слот LKG. Это упрощает откат неудачного развертывания. Если в дальнейшем обнаруживается проблема, можно быстро вернуться к версии LKG. Дополнительные сведения см. в статье Basic web application (Базовое веб-приложение).

Включите ведение журнала диагностики, в частности для приложения и веб-сервера. Ведение журнала важно для мониторинга и диагностики. Ознакомьтесь со статьей Включение ведения журнала диагностики для веб-приложений в службе приложений Azure.

Записывайте в хранилище BLOB-объектов. Это упрощает сбор и анализ данных.

Создайте отдельную учетную запись хранения для журналов. Не используйте одну учетную запись хранения для журналов и данных приложения. Это помогает предотвратить снижение производительности приложения из-за ведения журнала.

Отслеживайте производительность. Используйте службу мониторинга производительности, например New Relic или Application Insights, чтобы контролировать производительность и поведение загруженных приложений. Мониторинг производительности дает вам представление о приложении в режиме реального времени. Он позволяет диагностировать проблемы и выполнять анализ первопричин сбоев.

Azure Load Balancer

Выберите стандартный SKU. Балансировщик нагрузки уровня "Стандарт" обеспечивает уровень надежности, который недоступен в базовом варианте — это поддержка зон доступности и устойчивости зон. Это означает, что при отключении одной зоны зонально-избыточный стандартный балансировщик нагрузки не будет затронут. Это обеспечивает, что ваши развертывания могут быть устойчивыми к сбоям зон в пределах региона. Кроме того, Standard Load Balancer поддерживает глобальную балансировку нагрузки, гарантируя, что ваше приложение не пострадает из-за сбоев в различных регионах.

Подготовьте по крайней мере два экземпляра. Разверните Azure Load Balancer по крайней мере с двумя экземплярами в серверной части. Один случай может привести к возникновению одной точки отказа. Чтобы обеспечить масштабируемость, следует использовать балансировщик нагрузки вместе с наборами масштабируемых виртуальных машин.

Используйте правила для исходящих операций. Правила исходящих подключений гарантируют, что вы не столкнетесь с ошибками подключения в результате исчерпания портов SNAT (преобразования сетевых адресов источника). Дополнительные сведения об исходящем подключении. Хотя правила исходящего трафика помогут улучшить решение для небольших и средних развертываний, для производственных нагрузок рекомендуется использовать Standard Load Balancer или любое развертывание подсети с преобразованием сетевых адресов виртуальной сети (VNet NAT).

Общедоступные IP-адреса Azure

Выберите стандартный SKU. Общедоступные IP-адреса уровня "Стандартный" обеспечивают зоны доступности и устойчивость зоны в отличие от общедоступных IP-адресов уровня "Базовый". Если вы используете службу, требующую общедоступного IP-адреса, выберите зонально избыточный общедоступный IP-адрес. Для существующих IP-адресов обновите их с уровня "Базовый" до "Стандартный", чтобы воспользоваться преимуществами зональной избыточности по умолчанию.

Шлюз приложений

Подготовьте по крайней мере два случая. Разверните шлюз приложений как минимум с двумя экземплярами. Один экземпляр является единственной точкой отказа. Используйте два или более экземпляров для обеспечения избыточности и масштабируемости. Чтобы претендовать на соглашение об уровне обслуживания (SLA), необходимо подготовить два или более средних или более крупных экземпляра.

Azure Cosmos DB

Настройте резервирование зоны. При использовании резервирования по зонам Azure Cosmos DB синхронно реплицирует все записи в зонах доступности. Он автоматически переключается в случае сбоя в зоне. Дополнительные сведения см. в статье "Обеспечение высокого уровня доступности с помощью Azure Cosmos DB".

Реплицируйте базу данных по регионам. Azure Cosmos DB позволяет связать любое количество регионов Azure с учетной записью базы данных Azure Cosmos DB. База данных Azure Cosmos DB может иметь один регион записи и несколько регионов чтения. В случае сбоя в области записи можно считать данные из другой реплики. Клиентский пакет SDK обрабатывает это автоматически. Кроме того, можно переключить основной регион на другой регион. Дополнительные сведения см. в статье Как работает глобальное распределение данных в Azure с помощью Cosmos DB.

Event Hubs

Использование контрольных точек. Потребитель события должен записывать свою текущую позицию в постоянное хранилище с предопределенным интервалом. Таким образом, если у потребителя происходит сбой (например, сбой потребителя или хоста), новый экземпляр может возобновить чтение потока с последней записанной позиции. См. дополнительные сведения о потребителях событий.

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

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

Использование очереди недоставленных сообщений. Если обработка сообщения приводит к временному сбою, поместите сообщение в очередь недоставленных сообщений, чтобы отслеживать состояние. В зависимости от сценария можно повторно отправить сообщение позже, применить компенсирующую транзакцию или предпринять другое действие. Обратите внимание, что в Центрах событий нет встроенной функции очереди недоставленных сообщений. Вы можете использовать хранилище очередей Azure или Azure Service Bus для реализации очереди мертвых писем, или использовать Azure Functions или какой-либо другой механизм обработки событий.

Настройте избыточность зоны. Если избыточность зоны включена в пространстве имен, центры событий автоматически реплицируют изменения между несколькими зонами доступности. Если одна зона доступности выходит из строя, отработка отказа происходит автоматически. Для получения дополнительной информации см. Зоны доступности.

Реализуйте аварийное восстановление (DR), переключившись на вторичное пространство имен Центров событий. Дополнительные сведения см. в статье Географическое аварийное восстановление в Центрах событий Azure.

Кэш Azure для Redis

Настройте зональную избыточность. Если в вашем кэше включена избыточность зоны, Кэш Azure для Redis распределяет хостирующие кэш виртуальные машины по нескольким зонам доступности. Избыточность зоны обеспечивает высокий уровень доступности и отказоустойчивость в случае сбоя центра обработки данных. Дополнительные сведения см. в разделе Включение избыточности зоны для Azure Cache для Redis.

Настройка георепликации. Георепликация предоставляет механизм для связывания двух экземпляров Кэша Azure для Redis уровня "Премиум". Данные, записанные в основном кэше, реплицируются во вторичный кэш только для чтения. Дополнительные сведения см. в разделе Настройка георепликации для Кэша Azure для Redis.

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

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

Подготовьте несколько реплик. Используйте как минимум две реплики, чтобы обеспечить высокую доступность операций чтения, или три, чтобы обеспечить высокую доступность операций чтения и записи.

Используйте избыточность зон. Реплики Когнитивного поиска можно развертывать в нескольких зонах доступности. Такой подход помогает вашей службе оставаться в эксплуатации даже при сбоях центра обработки данных. Дополнительную информацию см. в разделе «Надежность в Azure Cognitive Search»

Настройте индексаторы для развертываний в нескольких регионах. Если имеется развертывание в нескольких регионах, рассмотрите варианты непрерывности индексирования.

  • Если источник данных геореплицирован, обычно следует указать каждый индексатор каждой региональной службы Azure Cognitive Search на локальную реплику источника данных. Однако мы не рекомендуем использовать этот подход для больших наборов данных, хранящихся в Базе данных SQL Azure. Причина заключается в том, что Когнитивный поиск Azure не может выполнять добавочное индексирование из вторичных реплик базы данных SQL, только из первичных реплик. Направьте все индексаторы на первичную реплику вместо этого. После отработки отказа направьте индексаторы Azure Cognitive Search на новую первичную реплику.

  • Если источник данных не является геореплицированным, настройте несколько индексаторов на одном источнике данных, чтобы службы Когнитивного поиска Azure в нескольких регионах непрерывно и независимо индексировали данные из этого источника. Дополнительные сведения см. в статье Рекомендации по производительности и оптимизации Поиска Azure.

Service Bus

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

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

Обработка исключений. API обмена сообщениями генерирует исключения, когда возникает ошибка пользователя, настройки или другая ошибка. Код клиента (отправителя и получателя) должен обрабатывать эти исключения в своем коде. Это особенно важно в пакетной обработке, где обработка исключений может использоваться для избежания потери всей партии сообщений. Дополнительные сведения см. в разделе Исключения обмена сообщениями служебной шины.

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

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

Используйте избыточность зоны. Если в пространстве имен включена избыточность зоны, Service Bus автоматически реплицирует изменения между несколькими зонами доступности. Если одна зона доступности выходит из строя, переключение происходит автоматически. Дополнительные сведения см. в статье Рекомендации по изолированию приложений от простоев и аварий служебной шины.

Используйте географическое аварийное восстановление. Географическое аварийное восстановление гарантирует, что обработка данных будет продолжать работать в другом регионе или центре обработки данных, если весь регион или центр данных Azure станет недоступным из-за стихийного бедствия. Дополнительные сведения см. в разделе Географическое аварийное восстановление в служебной шине Azure.

Хранилище

Используйте зонально-избыточное хранилище (ZRS). Межзонное избыточное хранилище (ZRS) синхронно копирует ваши данные в трех зонах доступности Azure в основном регионе. Если в зоне доступности происходит сбой, служба хранилища Azure автоматически переключается на альтернативную зону. Дополнительные сведения см. в статье Репликация службы хранилища Azure.

При использовании геоизбыточности настройте доступ на чтение. Если вы используете архитектуру с несколькими регионами, используйте подходящий уровень хранилища для глобальной избыточности. При использовании гео-избыточного хранилища с доступом только для чтения (RA-GRS) или гео-зонально-избыточного хранилища с доступом только для чтения (RA-GZRS) ваши данные реплицируются во вторичный регион. RA-GRS использует локально резервируемое хранилище (LRS) в основном регионе, а RA-GZRS использует хранилище с резервированием по зонам (ZRS) в основном регионе. Обе конфигурации предоставляют доступ только для чтения к данным во вторичном регионе. Если в основном регионе произошел сбой хранилища, приложение может считывать данные из дополнительного региона, если это возможно. Дополнительные сведения см. в статье Репликация службы хранилища Azure.

Для дисков виртуальных машин используйте управляемые диски.Управляемые диски обеспечивают лучшую надежность для виртуальных машин в группе доступности, так как диски достаточно изолированы друг от друга, чтобы избежать отдельных точек сбоя. Кроме того, управляемые диски не подвержены ограничениям на количество операций ввода-вывода в секунду (IOPS) для виртуальных жестких дисков (VHD), созданных в учетной записи хранения. Дополнительные сведения см. в статье Управление доступностью виртуальных машин Windows в Azure.

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

База данных SQL

Используйте стандартный или премиум-тариф. Эти уровни обеспечивают более длительный период восстановления на определенный момент времени (35 дней). Дополнительные сведения см. в статье Параметры и производительность базы данных SQL.

Включите аудит базы данных SQL. Аудит может использоваться для диагностики вредоносных атак или ошибки из-за человеческого фактора. Дополнительные сведения см. в статье Приступая к работе с аудитом базы данных SQL.

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

Используйте сегментирование. Рассмотрите возможность использования сегментирования для горизонтального секционирования базы данных. Шардинг может обеспечить изоляцию от сбоев. Дополнительные сведения см. в статье Развертывание с помощью Базы данных SQL Azure.

Используйте восстановление до точки во времени для устранения последствий человеческой ошибки. При восстановлении до точки во времени база данных возвращается к более раннему моменту. Дополнительные сведения см. в статье Восстановление базы данных Azure SQL с помощью создаваемых автоматически резервных копий.

Используйте геовосстановление для восстановления после сбоя службы. При геовосстановлении база данных восстанавливается из геоизбыточной резервной копии. Дополнительные сведения см. в статье Восстановление базы данных Azure SQL с помощью создаваемых автоматически резервных копий.

Azure Synapse Analytics

Не отключайте глобальное резервное копирование. По умолчанию Azure Synapse Analytics выполняет полную резервную копию данных в выделенном пуле SQL каждые 24 часа для аварийного восстановления. Не рекомендуется отключать эту функцию. Дополнительные сведения см. в георезервных копиях.

SQL Server на виртуальной машине

Архивируйте базу данных. Если вы уже используете службу Azure Backup для архивации виртуальных машин, рассмотрите возможность ее использования для рабочих нагрузок SQL Server с помощью DPM. Благодаря этому подходу существует одна роль администратора резервного копирования для организации и единая процедура восстановления для виртуальных машин и SQL Server. В противном случае используйте управляемое резервное копирование SQL Server в Microsoft Azure.

Диспетчер трафика

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

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

Виртуальные машины

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

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

Поместите каждый уровень приложения в отдельных группах доступности. В n-уровневом приложении не следует размещать виртуальные машины из разных уровней в одной группе доступности. Виртуальные машины в группе доступности распределяются в доменах сбоя и доменах обновления. Тем не менее, чтобы получить преимущества избыточности FDs и UDs, каждая виртуальная машина в группе доступности должна иметь возможность обрабатывать одни и те же клиентские запросы.

Реплицируйте виртуальные машины с помощью Azure Site Recovery. При репликации виртуальных машин Azure с помощью Site Recovery все диски виртуальных машин непрерывно и асинхронно реплицируются в целевой регион. Точки восстановления создаются каждые несколько минут. Это обеспечивает целевую точку восстановления (RPO) в пределах нескольких минут. Можно выполнять аварийное восстановление столько раз, сколько требуется. Это не повлияет на рабочее приложение или текущую репликацию. Дополнительные сведения см. в разделе проведение теста аварийного восстановления в Azure.

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

Используйте управляемые диски для виртуальных жестких дисков.Управляемые диски обеспечивают лучшую надежность для виртуальных машин в группе доступности, так как диски достаточно изолированы друг от друга, чтобы избежать отдельных точек сбоя. Кроме того, управляемые диски не подпадают под ограничения IOPS (операций ввода-вывода в секунду) для виртуальных жестких дисков (VHD), созданных в хранилище. Дополнительные сведения см. в статье Управление доступностью виртуальных машин Windows в Azure.

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

Используйте службу Azure Backup для архивации виртуальных машин. Резервные копии позволяют обеспечить защиту от случайной потери данных. Дополнительные сведения см. в статье Защита виртуальных машин Azure в хранилище служб восстановления.

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

Настройте Azure Monitor. Сбор и анализ данных мониторинга с виртуальных машин Azure, включая гостевую операционную систему, и рабочие нагрузки, которые выполняются на ней, см. в статье Azure Monitor и Краткое руководство: Azure Monitor.

Виртуальная сеть

Чтобы разрешать или блокировать общедоступные IP-адреса, добавьте в подсеть группу безопасности сети. Блокируйте доступ злоумышленников или разрешите доступ только для пользователей с привилегиями для доступа к приложению.

Создайте пользовательскую проверку работоспособности. Для проверки работоспособности балансировщика нагрузки могут использоваться HTTP или TCP. Если виртуальная машина работает на HTTP-сервере, проверка HTTP поможет лучше определить состояние работоспособности, чем проверка TCP. Для проверки HTTP используйте настраиваемую конечную точку, которая сообщает об общей работоспособности приложения, включая все критические зависимости. Дополнительные сведения см. в разделе Обзор Azure Load Balancer.

Не блокируйте проверку работоспособности. Проверка работоспособности Load Balancer отправляется с известного IP-адреса — 168.63.129.16. Не блокируйте входящий и исходящий трафик для этого IP-адреса в политиках брандмауэра или правилах группы безопасности сети. При блокировании проверки работоспособности подсистема балансировки нагрузки удаляет виртуальную машину из ротации.

Включите ведение журнала для Load Balancer. В журналах показано, сколько виртуальных машин на серверной стороне не получают сетевой трафик из-за неудачных ответов на проверки. Дополнительные сведения см. в статье Анализ журналов для Azure Load Balancer.