Расследование: почему Hitachi HCP перестал видеть свою собственную ноду (и как мы это починили)
Привет, Хабр!
В этой статье мы расскажем о заочной борьбе с разработчиками объектного хранилища Hitachi Content Platform. Сначала мы столкнулись с критическим заполнением файловых систем индексов, а в процессе лечения обнаружили вторую, гораздо более глубокую проблему — одна из нод кластера фактически выпала из схемы хранения данных, оставаясь при этом «зелёной» в консоли. Материал будет полезен инженерам, работающим с HCP и другими объектными СХД, а также всем, кто любит истории о нетривиальных расследованиях в недрах корпоративного ПО.
Наш пациент
Как же устроена СХД HCP? У одного нашего заказчика работает именно она. К нам обратились с проблемой заполненности файловых систем для индексов. Чтобы было понятно, с чем столкнулись, приобщаем к делу инфографику:
В нашем случае заполненность системы для индексов перевалила за 90%. «А что же случится, когда утилизация файловых систем дойдёт до 100%? До этого осталось месяца два», — подумали мы и взялись за дело, пока ситуация не стала критической.
Ищем решение
Документация не отвечала на наш вопрос — в ней сделан акцент на файловые системы с пользовательскими данными, которые можно легко почистить, просто удалив объекты по S3 или из консоли администратора HCP. Долгое время мы изучали нашу внутреннюю базу знаний с кейсами Hitachi Vantara. Нам удалось найти документ, где предлагалось увеличить количество регионов в системе в два раза и после этого вернуть их значение обратно.
Механизм регионов в HCP заключается в разделении БД метаданных объектов на партиции в кластере. Он способствует увеличению параллелизма работы с базой для улучшения показателей обработки S3-запросов нодами системы. Но есть и ограничения. Первое связано с количеством регионов в системе, но мы его проходили. Второе — низкая нагрузка. И в нашем случае оно было как раз основным, потому что на нашу систему нагрузка была высокой.
В любом случае проверяем найденное решение на стенде, насколько это возможно. Оно оказывается рабочим, и суммарный размер индексов заметно снижается.
Хитрый путь
Оценивая состояние нод во время изменения количества регионов, мы поняли, что индексы пересоздаются. Вспомнив все «развлечения» со своим стендовым HCP, возникло подозрение, что для пересоздания индексов нам достаточно выполнить по документации любую процедуру, в рамках которой пересоздаются метаданные. Один из таких случаев — длительное отсутствие ноды в кластере. После ее появления, даже при сохранности всех данных файловой системы, гарантировано будут пересозданы БД метаданных с индексами.
Идём на стенд, заливаем два миллиона объектов и проверяем найденное предположение, выключив ноду. Через час, подождав ребаланса метаданных, включаем ноду и ждём её полноценного возврата в кластер HCP. Способ оказался рабочим. Но на системе заказчика в 100500 раз больше объектов, БД — полтора терабайта, есть нагрузка, и простой системы недопустим.
Все кошки натренированы
Идём к заказчику и предлагаем замену ноды саму на себя: её выключение, ожидание ребалансировки метаданных после потери этой ноды, включение ноды с ожиданием её полноценно возврата в кластер HCP. Получив разрешение заказчика на радикальные меры, приступаем к первой ноде. После завершения нашего плана с ней утилизация её файловой системы с индексами снизилась с 96% до 20%. Работа со второй нодой также привела к успеху. Манипуляции с третьей закончилась ничем. Перестройка кластера HCP как после выхода ноды из кластера, так и после возврата обратно, произошла молниеносно, и заполненность файловой системы с индексами не изменилась.
Поворот не туда
Стало понятно, что мы свернули куда-то не туда, и нужно было время для выяснения причин. Изучение журналов HCP ответов на вопросы не принесло:
Почему третья нода быстро ушла и вернулась в кластер?
Почему не перестроились индексы метаданных в этой ноде?
Взглянув на нашего больного неделю спустя, мы обнаружили ещё один странный момент — заполненность файловых систем одной пары нод стала выше другой. Предположили сразу — есть ещё проблема в текущей конфигурации — Protection Sets.
Чтобы задать нужную избыточность хранения данных в кластере HCP, используется параметр DPL (Data Protection Level) — он определяет, сколько копий каждого объекта должно храниться в системе. По умолчанию для аппаратных (железных) инсталляций HCP значение DPL равно 2. Это означает следующее: когда объект поступает на запись, система сохраняет две его копии — каждая на своей ноде кластера. Таким образом обеспечивается отказоустойчивость на уровне хранения.
Важно: ноды для размещения копий выбираются не случайно. Во время инсталляции HCP система формирует так называемые Protection Sets — заранее определённые наборы нод, на которых допускается хранение данных при том или ином уровне DPL. Именно эти наборы и определяют, куда физически могут быть записаны объекты.
{153}, {152}, {151}, {150},
{150:152}, {151:153},
{151:152:153},
{150:151:152:153}
Как это работает на практике:
DPL = 1
Объект хранится в одной копии и может быть записан на любую из четырёх нод.
DPL = 2
Система создаёт две копии объекта и размещает их либо на нодах 150 и 152, либо на 151 и 153 — строго в соответствии с существующими protection set’ами.
DPL = 3
Создаются три копии объекта, которые записываются на ноды 151, 152 и 153. Обратите внимание: нода 150 в этом случае не используется, поскольку в системе нет protection set’а, включающего её при DPL = 3.
В нашем кейсе возникла нетипичная и на первый взгляд неочевидная ситуация. Одна из нод — вторая по счёту — полностью выпала из protection set’ов. При этом:
нода корректно входит в кластер;
отображается в «зелёном» состоянии;
файловые системы доступны и выглядят исправными.
нода корректно входит в кластер;
отображается в «зелёном» состоянии;
файловые системы доступны и выглядят исправными.
Однако данные на неё не записываются, потому что нода отсутствует в наборе protection set’ов:
{153}, {152}, {151},
{151:153},
{151:152:153}
Именно из-за этого, несмотря на формальную «здоровость» ноды, система HCP просто не рассматривает её как допустимое место для хранения данных. При этом причина проблемы нам была пока не ясна. Восстановить нормальное состояние ноды решили следующими шагами:
- перезагрузить “больную” ноду
- перезагрузить целиком весь кластер HCP
- перезалить ОС на “больной” ноде
- перезалить “больную” ноду целиком, удалив вообще все данные с неё.
Но эти действия к желаемому результату не привели - нода осталась «больной».
Самоустранение первой проблемы
Пока мы боролись с первым кластером, на второй системе HCP у одной из нод, файловая система для индексов неожиданно достигла 99%. И… сервисы HCP на ноде перезапустились, файловая система с индексами очистились, после чего произошло пересоздание индексов с заметным уменьшением их объёма.
Ура — мы знаем, как решается проблема с высокой заполненностью файловой системы. Надо только следить за тем, чтобы они не заполнялись на двух нодах одновременно. Такой вариант нами тоже предполагался, тем более что на стенде мы реализовывали сценарий с ручным удалением всех индексов и наблюдали их автоматическое пересоздание после перезагрузки ноды. Но предлагать такое на системе в промышленной эксплуатации мы с не рискнули.
Лечим вторую проблему
Первая проблема успешно решилась самостоятельно, но нода в Protection Sets так и не вернулась. Поиски по базе знаний и наличие доступа c правами root на ОC нод кластера HCP привели к необходимости исследовать конфигурации HCP, в которой хранятся все настройки системы. Мы обнаружили настройки Protection Sets, но нашего «пациента» там не оказалось.
Идём на стенд и пытаемся изменить переменную Protection Sets. Она прекрасно меняется — идем получать состояние больной системы в нашем стенде. После 14 дней отсутствия ноды она пропадает из Protection Sets. Мы можем её вернуть, но есть нюанс. Если не трогать Protection Sets, то нода появляется там сама после возврата в кластер HCP. Таким образом, мы что-то нашли, но это не точно.
Идём к заказчику. Нам выделяют окно для наших изысканий, и система принимает команду без ошибок, но ничего не происходит. Опять провал, и новый этап.
Собираем диагностические данные и анализируем журналы системы. На этот раз логи были «разговорчивее» — в них было указание на невозможность добавления ноды в Protection Sets из-за её отсутствия в кластере. Это сильно удивило и заставило посмотреть ещё раз на конфигурацию. Сравнение с тестовыми системами выявило несколько различий:
- первая переменная указывала на «больную» ноду как на покинувшую кластер;
- еще несколько переменных указывали на тома этой «больной» ноды как на отсутствующие.
Идём на наш стенд и начинаем экспериментировать. Выключаем одну из нод, и через некоторое время в конфигурации создаются переменные для отсутствующей ноды и её файловых систем. Но после возврата той ноды в кластер эти переменные пропадают. Берём часть работы кластера HCP в свои руки, и в конфигурации после выключения ноды создаём необходимые записи об её отсутствии.
Черные начали вторыми, но выиграли
Наступает час Х, мы запускаем выключенную ноду, и к нашей радости, получаем состояние проблемного кластера. «Болеющая» нода в консоли HCP, как и весь HCP, зелёные, но в Protection Sets этой ноды нет и она туда не добавляется из-за её отсутствия в кластере. Отрабатываем способ восстановления путём удаления из конфигурации всех лишних переменных.
Дождавшись от заказчика окна для работ, идём по проверенному пути. Держим в уме — случиться может всё что угодно. Несколько команд в консоли одной из нод HCP — и происходит чудесное исцеление «больной» ноды и всего кластера HCP. Он теперь зелёный не только снаружи, но и внутри.
Заключение
Что мы вынесли из этой истории?
Зелёный статус ноды — не гарантия её участия в работе. Всегда проверяйте актуальность Protection Sets, если замечаете дисбаланс заполнения.
Внутренняя конфигурация HCP хранит «фантомные» записи. При высокой нагрузке они могут не очищаться автоматически. Полезно знать, где искать и как править эти данные.
Оглядываясь назад, мы понимаем: решение кажется простым, когда оно уже найдено. Но дорога к нему заняла не один день экспериментов, анализа логов и смелых гипотез. Надеемся, наш опыт поможет коллегам быстрее справляться с похожими ситуациями.