Перейти к содержанию
Скачать

Отказы и восстановление

Страница нужна инженеру эксплуатации при отказе диска, узла хранения, площадки или сети. Для каждого вида отказа указано, что видит клиент, что кластер делает сам и что остаётся администратору. Как данные защищены от каждого отказа, объясняет страница Избыточность и домены отказа.

Отказ узла при нескольких площадках

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

Сводка

Отказ Что видит клиент при чтении Что кластер делает сам Что делает администратор
Диск ничего, пока группа размещения потеряла не больше m участников вычисляет недостающие фрагменты при чтении; участников на диске не заменяет, пока диск не признан вышедшим из строя признаёт диск вышедшим из строя либо переформатирует его на новый накопитель
Узел хранения ничего: фрагменты читаются с оставшихся участников или с другой площадки удерживает участников на дисках узла; после возвращения узла перестраивает пропущенные фрагменты если узел не вернётся — исключает его инстанс из кластера и заменяет узел
Площадка объекты, копия которых на другой площадке уже создана, читаются; остальные недоступны читает содержимое с другой площадки процедура в руководстве не описана
Сетевой сбой временные ответы 503 после восстановления связи перестраивает и досылает пропущенное ничего; проверяет, что очереди опустели

Чтение и запись

Таблица говорит о чтении. Для записи действует кворум записи: группе нужно больше доступных участников, чем для чтения. Группа, которая после отказа ещё читается, может уже не принимать запись. Тогда запись идёт в другую группу той же площадки, а если такой нет, клиент получает ответ 503 (см. Ответы клиенту).

Отказ диска

Диск не становится вышедшим из строя сам

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

Что видит клиент.

  • Чтение. Группа размещения, потерявшая не более m участников, продолжает обслуживать чтение: недостающие фрагменты вычисляются во время чтения.
  • Запись. Запись в группу продолжается, пока в ней остаётся не менее k + m − write_tolerance доступных участников и не менее k.

Что кластер делает сам. После того как диск признан вышедшим из строя, владелец каждой группы заменяет участника на этом диске так же, как при выводе диска (см. Замена исправного диска). Группа получает новую эпоху, и владелец перестраивает на новом участнике те фрагменты, которых там нет.

Владелец не заменяет участника, если участников, чей диск не удалён, не вышел из строя и не переформатирован, в группе меньше k.

Что делает администратор. Выбор зависит от того, заменён ли накопитель.

Накопитель ещё не заменён:

  1. Признайте диск вышедшим из строя: кнопка «Признать вышедшим из строя» на странице «Кластер» консоли или запрос POST /v2/disks/{disk_id}/failed. Владельцы групп заменят его участников другими дисками.
  2. Когда накопитель заменён, переформатируйте диск, чтобы вернуть его ёмкость (POST /v2/disks/{disk_id}/reformat).

Неисправный накопитель уже заменён новым: переформатируйте диск. Группы сохраняют его участником на прежнем месте и перестраивают его содержимое.

Условия и параметры обоих действий — на странице Действия с дисками.

Как понять, что восстановление завершено. Метрика s3r_pg_lost показывает группы, в которых сохранившихся участников меньше k. Группа остаётся в ней, пока это так, в том числе пока участники, поставленные на замену, ждут ресинхронизации. Состояние групп и очереди ресинхронизации показывает GET /v2/repair (см. Состояние по областям).

Отказ узла хранения

Несколько площадок

Если узел не вернётся, копия его объектов на этой площадке утрачена и не восстанавливается (см. Отказ узла при нескольких площадках). Прежде чем исключать инстанс из кластера, убедитесь, что узел действительно нельзя вернуть.

Что видит клиент. Зависит от раскладки группы.

Раскладка Что происходит с группой Чтение
spread группа теряет не более m участников фрагменты остаются доступными
instance группа на площадке своего узла недоступна целиком чтение обращается к копии объекта на другой площадке

Запись: группа с участником на недоступном узле принимает записи, пока не заполнит уже занятые экстенты. Затем она приостанавливается, и её владелец получает новую группу.

Что кластер делает сам.

  • Пока узел недоступен, его диски вышедшими из строя не считаются, участники удерживаются: остаются в своих группах, кластер ждёт возвращения узла.
  • Вернувшийся участник сначала начинает отклонять записи с эпохой ниже текущей, затем сверяется с владельцем. Только после этого группа снова пишет на него фрагменты.
  • При обычном перезапуске хранилище фрагментов восстанавливает индекс из снимка и журнала на диске. Фрагменты, пропущенные за время отключения, владелец группы перестраивает по строкам очереди ресинхронизации (процесс resync_queue).
  • Инстанс, исключённый из кластера, к обмену фрагментами не допускается.

Что делает администратор.

Отказ площадки

Копии между площадками создаются асинхронно

Объект читается с другой площадки только после того, как запись этой площадки в placements (карта размещения объекта) перешла в состояние live. Если копия на другую площадку ещё находилась в состоянии pending, потеря единственной площадки с данными делает содержимое объекта недоступным.

Что видит клиент. Объекты, копия которых на уцелевшей площадке находится в состоянии live, читаются. Содержимое остальных недоступно.

От чего зависит доступность метаданных.

Что делает администратор. Отдельной процедуры восстановления площадки руководство не описывает. Сколько объектов ждёт копии на другой площадке, показывает очередь s3r_t<N>_siterepl (см. Наблюдение за репликацией между площадками).

Сетевой сбой

Что видит клиент. Пока связи нет, запросы, для которых не хватает доступных участников группы, получают ответ 503 (см. Ответы клиенту).

Что кластер делает сам. После восстановления связности:

  • фрагменты, не принятые в момент записи, записаны в очередь ресинхронизации; их перестраивает владелец группы (процесс resync_queue);
  • объекты, ещё не переданные на другую площадку, перечислены в s3r_t<N>_siterepl; их досылает процесс siterepl.

Что делает администратор. Отдельных действий не требуется. Чтобы убедиться, что работа завершена, выполните запросы для каждого тенанта (в примере — тенант 0); все три должны вернуть 0:

SELECT count(*) FROM s3r_t0_damage;   -- 0: повреждённых полос нет
SELECT count(*) FROM s3r_t0_siterepl; -- 0: у тенанта 0 нет ожидающих копий
SELECT count(*) FROM s3r_t0_resync;   -- 0: у тенанта 0 нет недостающих фрагментов

Ответы клиенту

Какие ответы получает клиент при отказе хранилища, как читать сообщение об ошибке и что из этого повторять, описано на странице Ошибки и повторные запросы.