Проблемы при работе с дисками 19 июня 2020 года

Резюме по инциденту
В пятницу 19 июня некоторым клиентам были частично или полностью недоступны сервисы Compute Cloud, Managed Service for ClickHouse, Managed Service for Kubernetes, Managed Service for MongoDB, Managed Service for MySQL, Managed Service for PostgreSQL, Managed Service for Redis в зоне ru-central-b Яндекс.Облака. Проблема была локализована в 10:15, после чего наша команда точечно помогала пользователям устранять последствия инцидента.

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

Что произошло?
В Яндекс.Облаке данные хранятся в распределенной сетевой системе хранения данных собственной разработки. Сетевой диск выдерживает одновременный отказ двух серверов из своего сегмента без потери данных. Используемый в Яндекс.Облаке размер сегмента отказа — группа серверов, расположенных в разных серверных стойках. На каждом сервере для хранения данных конкретного сетевого диска используется один физический диск. В момент отказа физического диска или сервера данные начинают реплицироваться на другие серверы этого сегмента, пока коэффициент репликации каждого блока данных не будет восстановлен. 19 июня случилась маловероятная ситуация, когда произошел отказ четырех серверов, три из которых находились в одном сегменте отказа, что привело к тому, что не все данные успели реплицироваться. В результате часть данных на дисках оказалась потеряна и произошел сбой в работе перечисленных выше сервисов.

Ход событий:
8:40 — Выход из строя первого сервера, он признан невосстановимым. Ситуация штатная.
9:48 — Второй сервер того же сегмента признан невосстановимым. Сразу после этого сработала автоматика, оповещающая об угрозе потери данных. Команда сервиса сразу же приступила к поиску проблемы, поскольку это является опасной ситуацией, и потеря данных становится возможной, если в скором времени откажет третий сервер из сегмента.
10:09 — Вышел из строя третий сервер из этого же сегмента отказа. Локализовать проблему до выхода из строя третьего сервера не удалось. Сразу после этого автоматика была принудительно остановлена на всех серверах Яндекс.Облака.
10:15 — Вышел из строя сервер в другом сегменте отказа, который был упомянут в изначальном сообщении о проблеме. Но так как это был первый неработающий сервер в другом сегменте, то с данными в этом сегменте ничего не произошло. К тому же автоматика была уже остановлена и сервер был возвращен в строй.
10:15 — Мы начали оказывать помощь пострадавшим пользователям по их запросам.

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

Последствия для пользователей:

1. В Compute Cloud сбой затронул часть дисков пользователей, находящихся в зоне ru-central-b. Часть данных на этих дисках была утрачена, что привело к частичной или полной потере диска. Пострадавшим пользователям были высланы рекомендации провести аварийное восстановление диска по инструкции. Все затронутые диски были отмечены в консоли Яндекс.Облака. При этом часть дисков мы смогли восстановить самостоятельно без участия пользователей, где пострадавшей оказалась внутренняя системная часть диска. С таких дисков отметка в консоли была снята, так что если сейчас в консоли Яндекс.Облака нет отметок о возможном повреждении жестких дисков, то никаких действий со стороны пользователя не требуется.
2. Управляемые базы данных, кластера которых были развёрнуты с сетевыми дисками в нескольких зонах доступности, были недоступными на запись в течение нескольких минут. При этом потери данных не было. Такая недоступность — это внештатная ситуация, так как не была предусмотрена обработка частичной, а не полной, потери диска. Подобное поведение системы будет улучшено, переключение из-за длительных проблем с диском будет осуществляться за десятки секунд.
3. Управляемые базы данных Managed Service for PostgreSQL и Managed Service for MySQL, кластера которых были развёрнуты только в пострадавшей зоне доступности ru-central-b, были восстановлены без потери данных из последней резервной копии, но с недоступностью сервиса на время восстановления.
4. Управляемые базы данных Managed Service for ClickHouse, Managed Service for MongoDB и Managed Service for Redis, кластера которых были развёрнуты только в пострадавшей зоне доступности ru-central-b, были восстановлены из последней резервной копии с потерей данных за последний бизнес-день.
5. Инцидент затронул только нескольких пользователей Managed Service for Kubernetes, которые использовали не отказоустойчивый тип мастеров. Во время инцидента для них был недоступен control plane Kubernetes, при этом запущенные в кластерах сервисы клиентов продолжали штатно функционировать. Эти мастера были восстановлены из последней резервной копии.

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

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

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

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

1. Мы уже исправили ошибку в автоматической процедуре, которая неверно определяла уровень аппаратной проблемы.
2. Перед отправкой сервера или диска в полную перенастройку по любой причине мы добавили обязательную задержку в одни сутки. Это позволит инженерам вручную обработать эту ситуацию и вернуть физические диски в кластер без потери данных.
3. Будет добавлен дополнительный уровень проверки — теперь система хранения данных в Яндекс.Облаке будет явно подтверждать любое действие с оборудованием. Так мы сможем отложить работы с вышедшим из строя физическим диском или сервером на любой необходимый срок, пока не будем уверены в безопасности этого действия. В произошедшем инциденте это позволило бы не отправлять второй и третий серверы в перенастройку, а заморозить их до восстановления первого сервера.
4. Мы введём обязательное резервное копирование мастеров Managed Service for Kubernetes с частотой несколько раз в сутки.

Мы также рекомендуем нашим клиентам:

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