Тестовый кластер Ceph из трёх мониторовдемон, который хранит карту кластера и участвует в выборах лидера был собран вручную, без cephadm. После обновления до tentacle 20.2.0 попытка добавить третью ноду на Ubuntu 24.04 со сборкой из репозитория проекта привела к потере кворумаминимальное число голосов мониторов, при котором кластер продолжает работать, уходу ноды в аутсостояние, когда узел перестаёт отвечать и выпадает из работы кластера по CPU и памяти, приходу OOM-killerмеханизм ядра, который принудительно завершает процессы при нехватке памяти и зависанию, при котором подключиться не удавалось даже по консоли. Автор кейса пришёл к выводу, что дело не в конфигурации и не в расхождении часов, а в конкретной сборке под конкретную ОС.
Что именно изменилось
Изначально мониторы стояли на Ubuntu 22.04 (squid) и AlmaLinux 9 (squid). Затем Ceph был обновлён до tentacle 20.2.0 из репозиториев, которые предоставляет сам Ceph. Обновление прошло гладко на Ubuntu 22.04 (jammy) и AlmaLinux 9. Для Ubuntu 24.04 (noble) сборки tentacle раньше не было ни в репозитории Ceph, ни в родном репозитории Ubuntu; в репозитории Ceph она появилась позже, а в родном репозитории Ubuntu — только в 26.04.
Подключение репозитория Ceph для tentacle в примере из статьи выглядит так:
deb https://download.ceph.com/debian-tentacle/ jammy mainЗдесь jammy — кодовое имя выпуска Ubuntu. Официальная документация Ceph описывает тот же шаблон с подстановкой кодового имени нужного дистрибутива, а также вариант записи в sources.list с автоматическим определением кодового имени командой lsb_release -sc. Общий шаблон URL репозитория — https://download.ceph.com/debian-{release-name}, то есть debian-tentacle — это конкретизация release-name = tentacle. Репозиторий для AlmaLinux и последующие действия автор брал из официальной документации Ceph.
Как добавляли монитор вручную
Новую ноду готовили без cephadm. Конфигурационный файл ceph.conf и keyring переносили через scp, затем монитор инициализировали командой ceph-mon с флагами --mkfs, --monmap и --keyring. Флаг --mkfs создаёт файловую систему монитора, --monmap передаёт ей карту мониторов кластера, а --keyring — ключ доступа; такой порядок нужен, чтобы монитор при первом запуске уже знал состав кластера и мог к нему присоединиться.
Порядок подготовки такой: сначала получают keyringфайл с ключом доступа, по которому монитор аутентифицируется в кластере командой ceph auth get mon. -o {tmp}/{key-filename} — отдельный ключ нужен монитору, чтобы подтверждать свою подлинность при обмене с другими мониторами, — затем получают monmapкарта мониторов кластера, которая описывает их состав и адреса командой ceph mon getmap -o {tmp}/{map-filename}, после чего создают файловую систему монитора:
sudo ceph-mon -i {mon-id} --mkfs --monmap {tmp}/{map-filename} --keyring {tmp}/{key-filename}Запущенный монитор должен автоматически присоединиться к кластеру; адрес привязки задают опцией --public-addr {ip} или --public-network {network}.
Что происходило при запуске проблемного монитора
Новая нода не становилась частью кластера — третий монитор даже не появлялся в его составе. Через пару секунд после запуска монитора кластер терял кворум: нода на Ubuntu уходила в аут, загруженная по CPU и памяти в потолок, затем приходил OOM-killer. Так продолжалось, пока не останавливали монитор на новой ноде; после остановки проходило 5–10 минут, нода зависала намертво, и подключиться к ней не удавалось даже по консоли.
Уцелевшая нода (peonмонитор, который не является лидером и следует за ним) при этом постоянно и в огромном количестве писала в лог сообщения о добавлении нового пира. Это продолжалось, пока проблемную ноду не остановили, и, видимо, из-за этого зависала другая нода. AlmaLinux с той же версией tentacle смогла переварить эти постоянные сообщения, в отличие от проблемной ноды.
Что ещё не работало с проблемной ноды
Попытка добавить новый OSD с этой ноды тоже не удалась. Ошибка возникала на шаге bootstrap-osd — это этап первичной регистрации нового OSD в кластере, когда узел предъявляет кластеру свои учётные данные. Кластер отвергал предъявленный секрет как недействительный, и создание нового OSD завершалось ошибкой:
Error EINVAL: invalid cephx secret. -> RuntimeError: Unable to create a new OSD idКакие гипотезы проверялись
Проверялась гипотеза о расхождении времени на нодах, так как Ceph требователен к этому. Была настроена синхронизация всех нод с одним NTP-сервером, увеличен максимально допустимый расход по времени — и так далее. Контрольный эксперимент состоял в удалении одной из действующих нод с получением кластера из одной и последующем добавлении обратно: проблемы не воспроизводились, всё работало как положено. Поскольку при таком удалении и повторном добавлении проблема не проявлялась, гипотеза о синхронизации времени была отвергнута.
Автор пришёл к выводу, что причина — не конфигурация и не часы, а конкретная сборка Ceph tentacle под конкретную ОС Ubuntu 24.04. Проблема проявилась именно после того, как он поставил сборку tentacle для Ubuntu 24.04 из репозитория Ceph, тогда как раньше такой сборки не было.
Что осталось за рамками
Автор описывает свой кейс с тестовым кластером, но не формулирует практических выводов в виде рекомендаций проверять пакеты под конкретную версию дистрибутива, собирать стенд на точной паре «версия Ceph + версия ОС» или не переносить выводы с одной ОС на другую. Источники содержат только описание ситуации.
Сборка tentacle в родном репозитории Ubuntu 26.04 упоминается, но подробности автор обещает изложить позже.
