Сообщение mon no data available указывает на то, что один из MON-демонов Ceph не может прочитать собственное хранилище состояния. Обычно это связано с повреждением директории /var/lib/ceph/mon/*, отсутствием ключей или неправильными правами доступа. Проблема проявляется в виде отсутствующей карты кластера, сбоя в инициализации MON или невозможности согласовать текущее состояние кворума.
Для диагностирования сбоя требуется проверить журналы ceph-mon, убедиться в доступности каталога с данными, сверить владельца и права файлов, а также уточнить корректность keyring. Если MON не может получить доступ к собственному хранилищу, он не вступает в кворум и формирует упомянутое сообщение. От этого зависит стабильность всего кластера, так как MON управляет метаданными и картами служб.
При обнаружении расхождений в структуре каталога, ошибок чтения или повреждённых файлов может потребоваться восстановление экземпляра MON из резервной копии или из корректно работающей ноды. В некоторых случаях помогает пересоздание MON с последующим подключением к существующей карте кластера. Такие действия позволяют вернуть корректное состояние кворума и исключить дальнейшие сбои.
Mon no data available в Ceph: что делать
Ниже приведена таблица, которая помогает быстро установить причину отказа и подобрать корректное действие:
Симптом
Описание
Решение
Мон не создаёт карту кластера
Недоступен каталог с внутренним хранилищем
Проверить файловую систему, восстановить доступность директории
Ошибки «failed to load monmap»
Нарушена структура мон-каталога или отсутствует monmap
Перекопировать monmap с рабочей ноды или восстановить из резервной копии
Журналы фиксируют отказ keyring
Повреждён либо перепутан файл ключа
Скопировать корректный keyring и выдать нужные права
MON отклонён от кворума
Системное время отличается от остальных узлов
Синхронизировать время через NTP и перезапустить MON
Если структура каталога нарушена полностью и восстановление невозможно, применяется пересоздание MON с помощью ceph-mon —mkfs и загрузкой актуальной карты. Этот шаг возвращает узел в кластер без повреждения остальных служб.
Проверка статуса MON через ceph -s и расшифровка сообщения no data available
Команда ceph -s показывает текущее состояние кластера и позволяет быстро определить, что один из MON не может загрузить собственное хранилище. При появлении строки mon: no data available система указывает на отсутствие доступа к каталогу с внутренними данными мон-демона или на некорректное состояние файлов, необходимых для запуска.
Стандартные признаки, которые подтверждают проблему: отсутствие мон-каталога, ошибки чтения store.db, сообщения о недоступном keyring или невозможности загрузить monmap. Эти признаки помогают определить, требуется ли восстановление каталога, корректировка прав доступа или пересоздание MON.
Анализ логов ceph-mon для поиска первопричины отсутствия данных
Журналы ceph-mon позволяют определить, на каком этапе демон теряет доступ к своему хранилищу. Логи обычно располагаются в /var/log/ceph/ и содержат сообщения о загрузке store.db, инициализации мон-каталога, проверке keyring и чтении monmap. Ошибки вида failed to mount store, db is not readable или unable to load monmap указывают на повреждение внутренних данных.
Если в логе появляется запись о несоответствии владельца или режиме доступа, MON не сможет открыть нужные файлы. Сообщения permission denied и wrong key permissions подсказывают, что каталог или ключ были изменены вручную. Исправление прав через chown и chmod в таких случаях решает проблему без восстановления структуры.
Отдельное внимание заслуживают ошибки синхронизации времени. Записи о расхождении между узлами или отказе от присоединения к кворуму показывают, что MON отклонён из-за несогласованного таймстемпа. В таких ситуациях достаточно выровнять время через NTP и перезапустить демон.
Если логи фиксируют повреждение файлов store.db или отсутствие ключевых структур, потребуется восстановление каталога из резервной копии либо копирование данных с рабочей ноды. Такие сообщения дают точное указание на то, что проблема не связана с правами, а вызвана неполнотой или разрушением внутреннего хранилища.
Проверка прав доступа и корректности расположения keyring для MON
Keyring отвечает за авторизацию MON и должен находиться в каталоге /var/lib/ceph/mon/—/. Смещение файла, неверные права или смена владельца приводят к тому, что демон не может прочитать ключ и завершает инициализацию с ошибкой.
Для проверки используется стандартный набор действий:
Убедиться, что файл называется keyring и расположен в каталоге мон-демона.
Проверить владельца: должен быть ceph:ceph.
Проверить режим доступа: обычно 600 или 640, чтобы исключить блокировку чтения.
Сравнить содержимое файла с keyring на рабочей ноде, если есть подозрение на повреждение.
Если файл отсутствует или не читается, его можно восстановить с помощью копирования с исправного MON:
Скопировать keyring на проблемный узел.
Назначить владельца и права: chown ceph:ceph keyring, chmod 600 keyring.
Убедиться, что путь соответствует структуре каталога мон-демона, иначе MON не обнаружит ключ.
После корректировки прав и расположения keyring демон запускается без ошибок доступа и получает возможность прочитать собственное хранилище.
Диагностика повреждения или недоступности каталога /var/lib/ceph/mon
Каталог /var/lib/ceph/mon/ содержит внутренние файлы MON, включая store.db, monmap и keyring. Его повреждение или недоступность приводит к появлению ошибки mon no data available и блокировке узла в кворуме.
Для диагностики следует выполнить следующие шаги:
Проверить существование каталога: ls -l /var/lib/ceph/mon/. Отсутствие подкаталогов указывает на удаление или некорректное создание MON.
Проверить права и владельца: stat /var/lib/ceph/mon/*. Все файлы должны принадлежать пользователю ceph и группе ceph, режим доступа не выше 700.
Проанализировать журнал ошибок: journalctl -u ceph-mon@<имя_узла> или /var/log/ceph/ceph-mon.<имя_узла>.log. Сообщения о недоступности каталога или отказе чтения store.db указывают на повреждение.
Проверить файловую систему на ошибки: fsck или xfs_repair для XFS, чтобы исключить физические повреждения.
Если каталог повреждён и восстановление из логов невозможно, применяют копирование каталога с рабочего MON или пересоздание узла через ceph-mon —mkfs с последующей загрузкой актуальной карты кластера. Это возвращает MON в рабочее состояние без потери согласованности кворума.
Проверка синхронизации времени и состояния системных служб MON
MON-демоны Ceph зависят от точного времени для согласования кворума. Несовпадение таймстемпов между узлами приводит к отказу в загрузке карты кластера и формированию ошибки mon no data available.
Для проверки синхронизации времени выполните:
Проверка текущего времени на всех MON: date. Разница более нескольких секунд требует коррекции.
Проверка состояния NTP или chrony: timedatectl status, systemctl status chronyd или ntpd. Служба должна быть активной и синхронизированной.
При необходимости выполнить синхронизацию: ntpdate -u <сервер_NTP> или через chrony: chronyc makestep.
После выравнивания времени проверяют состояние MON-демонов: systemctl status ceph-mon@<имя_узла>. Демон должен быть активен, без ошибок чтения каталога или keyring. Если после синхронизации времени узел всё ещё не входит в кворум, проверяют журналы /var/log/ceph/ceph-mon.<имя_узла>.log для выявления дополнительных проблем.
Восстановление структуры MON из резервной копии или healthy-нод
Если MON не может прочитать свои данные и формирует сообщение mon no data available, восстановление из резервной копии или копирование с рабочей ноды позволяет вернуть узел в кластер без потери кворума.
Для восстановления используются следующие действия:
Действие
Описание
Команда / примечание
Определение источника восстановления
Выбор healthy-узла или резервной копии для копирования данных MON
rsync или scp с рабочей ноды
Копирование каталога мон-демона
Перенос полного каталога /var/lib/ceph/mon/—/ на проблемный узел
rsync -avz /var/lib/ceph/mon/@:/var/lib/ceph/mon/
Проверка прав и владельца
Все файлы должны принадлежать пользователю ceph:ceph, режим доступа 700-600
Запуск демона после восстановления каталога для подключения к кворуму
systemctl restart ceph-mon@
Проверка состояния
Подтверждение успешного присоединения к кворуму и корректного чтения карты кластера
ceph -s; journalctl -u ceph-mon@
Восстановление с рабочей ноды гарантирует, что структура каталога, ключи и monmap будут актуальными. Это позволяет вернуть MON в работу без нарушения согласованности всего кластера.
Пересоздание MON-инстанса при потере данных и повторный bootstrap
Если каталог MON полностью потерян и восстановление из резервной копии невозможно, узел требуется пересоздать с повторным bootstrap. Это позволяет вернуть его в кластер без нарушений кворума.
Алгоритм действий:
Остановить текущий MON, если он запущен: systemctl stop ceph-mon@<имя_узла>.
Назначить права и владельца для нового каталога: chown -R ceph:ceph /var/lib/ceph/mon/—, chmod -R 700 /var/lib/ceph/mon/—.
Запустить MON: systemctl start ceph-mon@<имя_узла> и проверить подключение к кворуму через ceph -s.
Если узел не входит в кворум, проверить журналы /var/log/ceph/ceph-mon.<имя_узла>.log для выявления ошибок ключей или несоответствия мон-карты.
Этот процесс гарантирует восстановление структуры MON, корректную инициализацию каталога и повторное подключение к кластеру, исключая необходимость ручной правки файлов и минимизируя риск рассинхронизации.
Проверка карты кластера после восстановления MON и устранение расхождений
После восстановления MON необходимо убедиться, что его карта кластера синхронизирована с остальными узлами. Несовпадение мон-карт приводит к отказу в кворуме и ошибкам доступа к объектам.
Для проверки применяются следующие шаги:
Проверить текущий статус кластера: ceph -s. Все MON должны быть в состоянии up и in.
Сравнить monmap проблемного узла с рабочими: ceph mon getmap -i /var/lib/ceph/mon/<имя_узла>/monmap. Проверить идентификаторы узлов и версии карты.
При расхождениях выполнить обновление карты: ceph mon add для повторного включения узла или ceph mon remove и добавление заново, если карта повреждена.
Проверить журнал MON на предмет ошибок: /var/log/ceph/ceph-mon.<имя_узла>.log. Сообщения о несоответствии monmap или отказе присоединения к кворуму указывают на необходимость пересоздания карты.
После устранения расхождений повторно выполнить ceph -s для подтверждения, что узел входит в кворум и доступен для операций чтения и записи.
Точное соответствие карты кластера гарантирует стабильную работу MON и предотвращает повторное появление сообщения no data available.
Вопрос-ответ:
Что означает сообщение «mon no data available» в Ceph и почему оно появляется?
Сообщение «mon no data available» указывает, что MON-демон не может прочитать своё локальное хранилище, включая файлы monmap, store.db и keyring. Причины могут быть связаны с повреждением каталога /var/lib/ceph/mon/, неправильными правами доступа, отсутствием ключа или рассинхронизацией времени между узлами. Без доступа к этим данным MON не может войти в кворум и участвовать в управлении картой кластера.
Какие шаги нужно выполнить для проверки состояния MON при появлении этой ошибки?
Первым шагом необходимо выполнить ceph -s для проверки статуса кластера и увидеть, какие MON активны. Далее стоит проверить журналы /var/log/ceph/ceph-mon.<имя_узла>.log на ошибки загрузки store.db и keyring. Затем проверить существование каталога мон-демона, права доступа (ceph:ceph), режим файлов (600–700) и корректность keyring. Также важно убедиться, что системное время синхронизировано через NTP или chrony.
Как восстановить MON, если каталог с данными повреждён или отсутствует?
Если каталог /var/lib/ceph/mon/—/ повреждён, можно восстановить данные с резервной копии или скопировать каталог с работающего узла. После копирования необходимо назначить владельца и права: chown -R ceph:ceph и chmod -R 700. Затем перезапустить демон через systemctl start ceph-mon@<имя_узла> и проверить подключение к кворуму командой ceph -s.
Когда требуется пересоздание MON-инстанса и как выполнить повторный bootstrap?
Пересоздание MON требуется, если каталог полностью потерян и восстановить его невозможно. Для этого останавливают демон (systemctl stop ceph-mon@<имя_узла>), удаляют старый каталог, выполняют ceph-mon —mkfs -i <имя_узла> —monmap /путь/к/monmap —keyring /путь/к/keyring, устанавливают права доступа, затем запускают MON и проверяют подключение к кворуму. Это позволяет вернуть узел в кластер без нарушений согласованности карты.
Загрузка...
