Кратко

  • По данным Azure, временное ограничение на обновления операционных систем истекло, после чего многие обновления шлюзов возобновились за короткий срок. Ранее развёрнутое изменение также увеличило время обработки операций конфигурации.
  • Совокупная нагрузка затронула операции управления несколькими сетевыми службами в разных регионах. На части шлюзов ExpressRoute обновление следующего резервного экземпляра началось до полного восстановления конфигурации и маршрутов.

Самое простое объяснение облачного сбоя звучит так: его вызвало обновление. Однако обзор Azure события 30 сентября — 1 октября показывает более важное взаимодействие. Временное ограничение приостановило обновления операционной системы для группы шлюзов. После истечения ограничения многие обновления возобновились за короткий период. В то же время ранее развёрнутое изменение увеличило время обработки операций конфигурации в общем региональном сетевом контуре управления. Запросов стало больше именно тогда, когда каждый из них стал выполняться дольше.

Это не то же самое, что приписать всё одной неисправной версии обновления. Microsoft описывает всплеск перезапусков и запросов конфигурации на фоне замедлившейся службы; существующие механизмы ограничения скорости и защиты от нагрузки не смогли достаточно защитить критическую обработку. Волна обновлений проходила по регионам последовательно, поэтому время воздействия различалось. Azure называет среди затронутых служб ExpressRoute Gateway, Application Gateway, Azure Firewall, Bastion, Virtual WAN и VPN Gateway в регионах Америки, Европы, Азиатско-Тихоокеанского региона, Африки и Ближнего Востока.

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

Проблема управления нарушила и часть подключений

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

После примерно 30 минут неудачных попыток получить конфигурацию затронутые шлюзы применяли локально сохранённую последнюю рабочую конфигурацию. Эти 30 минут — интервал повторных попыток, описанный Microsoft, а не длительность сбоя у каждого клиента. Общий инцидент начался 30 сентября в 20:30 UTC, а последняя волна воздействия была устранена 1 октября в 02:15 UTC. Azure подчёркивает, что общая продолжительность не равна длительности воздействия на каждого клиента или ресурс.

Хронология также объясняет, почему одного увеличения мощности оказалось недостаточно. Ухудшение ExpressRoute обнаружили в 20:43, более широкие проблемы контура управления — в 20:58. Остановка дальнейших обновлений в 21:45 и перенос трафика дали временное облегчение, но попытки добавить ресурсы не решили проблему. В 23:55 расследование связало увеличенное время обработки конфигураций с регрессией производительности. Откат начался в одном регионе 1 октября в 01:15; результат проверили и затем распространили на другие регионы. Воздействие завершилось в 02:15 после окончания отката в затронутых регионах.

Окно обслуживания не определяет, как будет обработана очередь

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

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

Руководство Microsoft по безопасному развёртыванию рекомендует постепенно расширять охват, проверять состояние перед каждым этапом и останавливать развёртывание при обнаружении проблем. Операционный вопрос здесь конкретнее: означает ли «исправен», что процесс перезапустился, или что конфигурация и маршруты, необходимые для обслуживания, восстановлены и проверены? Резервирование не помогает, если следующий экземпляр наследует ту же ещё не восстановленную зависимость от контура управления.

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

Источники: Разбор Azure 7Q30-010; Виртуальные сетевые шлюзы ExpressRoute; Обслуживание шлюзов под контролем клиента; Практики безопасного развёртывания. Только редакционная рамка: Heng Lu, заметка 20.