Проблемы с DNS-сервисом 6 и 7 апреля 2020 года

Резюме по инцидентамРезюме по инцидентам

6 апреля с 16:51 до 17:40 (в зоне доступности ru-central1-c), 7 апреля с 13:41 до 14:32 (в зоне доступности ru-central1-b) и с 21:03 до 21:29 (в зоне доступности ru-central1-a) по Москве некоторые пользователи Яндекс.Облака сталкивались с недоступностью работы сети на своих ВМ. Во время сбоя резолвинг доменных имён из виртуальных машин, расположенных в соответствующих зонах, работал с перебоями, в ответ на часть запросов DNS-сервера Облака возвращали ответ SERVFAIL или REFUSED. Мы приносим свои извинения всем пользователям, кого затронул данный инцидент, и хотим рассказать подробнее о случившемся и мерах предотвращения повторения подобной ситуации в будущем.

Что произошло?Что произошло?

DNS-сервис Облака состоит из двух частей. Мы называем их Data plane и Control plane. Data plane отвечает непосредственно за резолвинг доменных имён — он получает DNS-запросы от пользователей и возвращает им ответы. Control plane следит за информацией об облаках пользователей (например, о создаваемых и удаляемых виртуальных машинах) и соответствующим образом меняет конфигурацию сервиса Data plane. Сервис Data plane самостоятельно резолвит внутренние адреса облака (например, адреса виртуальных машин и баз данных), остальные запросы рекурсивно отправляет на вышестоящие DNS-сервера Яндекса. Произошедший сбой в зоне ru-central1-c был вызван выходом из строя Control plane.

ПричиныПричины

На каждой машине в кластере DNS-серверов подняты оба сервиса — и Control plane, и Data plane. Работа серверов практически никак не связана друг с другом, выход строя одного или даже нескольких из них не влияет на работу DNS-резолвинга в Облаке. Сервис Control plane независимо от «соседей» генерирует конфигурацию для своего, локального, сервиса Data plane.

6 апреля в 16:47:05 сервис Control plane на одном из серверов аварийно завершился и перезапустился. В момент запуска сервис Control plane очищает конфигурацию для Data plane, после чего генерирует её с нуля. Это занимает от 5 до 10 минут. После перезапуска он загрузил всю необходимую информацию в себя и приступил к генерации конфигурационных файлов для сервиса Data plane.

В 16:51:05 и 16:51:15 аналогично упали и перезапустились сервисы Control plane ещё на двух серверах. В этот момент дежурные начали разбираться с тем, почему падают сервисы Control plane. К сожалению, падения продолжались — сервисы упали и перезапустились на всех DNS-серверах в зоне ru-central1-c, и продолжали перезапускаться примерно раз в минуту.

Падение одного сервиса вызвало массовое переподключение виртуальных роутеров к копии сервиса на другом сервере, что также приводило к его падению. Таким образом образовалась цепочка циклических падений и рестартов сервисов Control plane на всех серверах. Сервисы Data plane при этом продолжали работать, но так как Control plane очистили при своих рестартах конфигурацию, то в реальности Data plane не выполнял свою работу и отвечал на запросы пользователей кодом REFUSED. К 17:04 дежурным удалось остановить каскад падений сервисов и запустить сервис сначала на одном из них, а к 17:07 — на всех остальных.

Следующие десять минут вновь поднятые сервисы Control plane собирали нужную информацию о сетях и виртуальных машинах и готовили конфигурационные файлы для Data plane. В 17:16 сервисы Data plane начали корректно отвечать на часть DNS-запросов. Постепенно всё большее количество запросов обрабатывались корректно, однако полная работоспособность DNS в ru-central1-c восстановилась только в 17:40. Мы разбираемся, почему этот процесс занял ещё 24 минуты.

О проблеме в сервисе Control plane, которая приводит в падениям, нам было известно уже некоторое время до этого, мы подготовили релиз для его исправления. Релиз, содержащий увеличение этого лимита в 10 раз, выехал в зону ru-central1-a 6 апреля — всё прошло гладко. Через несколько часов мы заметили очередное приближение к лимиту, но только на одном из серверов в этой зоне, остальные показывали запас минимум в 100 раз. Мы решили не блокировать выкладку релиза в другие зоны доступности, а разобраться с этой аномалией позже. Нагрузка на все сервера в кластере идёт одинаковая, и тот факт, что на одном из них вдруг стало использоваться в сто раз больше обработчиков запросов, скорее указывало на проблемы в сервере, чем на проблему в релизе.

7 апреля этот релиз выехал в зону ru-central1-b. Через несколько часов работы, в 13:09, проблема воспроизвелась на одном из серверов и в этой зоне — дежурные начали внимательно изучать, что именно отличает сервера с проблемой от аналогичных серверов без них. Через полчаса, в 13:41, наши мониторинги сообщили, что теперь на всех серверах лимит (увеличенный с релизом в 10 раз) исчерпался. Это было странно, первым делом мы заподозрили, что появилась аномальная нагрузка на наши DNS-серверы. Дежурные начали искать подтверждения этой гипотезе, но ничего не нашли — аномальной нагрузки не было, и тем не менее DNS-сервера рапортовали об исчерпании лимита на обработчики запросов.

В 13:55 дежурные запустили откат релиза на одном сервере в зоне ru-central1-b. Это помогло, и откат запустили на остальных серверах. После стабилизации ситуации в ru-central1-b мы откатили релиз и в ru-central1-a, однако не рестартовали сервисы Data plane — предположили, что из-за меньшей нагрузки в этой зоне и работы в этой зоне в течение суток проблем быть не должно. К сожалению, это предположение было ошибкой.

В 21:03 мониторинги в зоне ru-central1-a аналогично отрапортовали о превышении лимита на всех серверах в этой зоне, что приводило к отбрасыванию части запросов и возвращению кода SERVFAIL. Дежурные постепенно рестартовали сервисы на всех серверах, и ситуация нормализовалась к 21:29. Примерно столько времени занимает плановый рестарт всех DNS-серверов в кластере одной зоны доступности. Как выяснилось позже, причиной проблемы с лимитами стала несогласованность параметров Data plane. Увеличив количество обработчиков рекурсивных запросов, мы оставили прежним количество потоков, в которых они запущены, что и привело к проблемам.

Меры для предотвращения повторения подобной ситуации в будущем:Меры для предотвращения повторения подобной ситуации в будущем:

1. Мы предотвратили возможное повторение сбоя — ограничили подключения от виртуальных роутеров до сервисов Control plane и откатили проблемный релиз для Data plane.
2. Мы обновили версию Data plane, которая не очищает конфигурацию в случае падения и перезапуска Control plane. Это позволит сохранять работоспособность Data plane даже при полном отказе Control plane.
3. В ближайшее время мы обновим версию Data plane, которая при перезапуске попытается сразу начинать работать с конфигурацией, оставшейся до падения. Уже после запуска Control plane поправит конфигурацию в тех местах, где во время недоступности Data plane что-то поменялось.
   Будем работать над уменьшением времени возвращения связки Control plane + Data plane к полностью рабочему состоянию после падения любого из сервисов.