При работе с распределённым хранилищем Ceph рано или поздно возникает необходимость вывести узел из кластера — для обслуживания, замены оборудования или оптимизации инфраструктуры.
Неправильный вывод узла может привести к потере данных или длительному простою. Разбираем, как планировать и выполнять эту операцию безопасно.
Когда требуется вывод узла
Типовые ситуации:
Обслуживание оборудования:
- Замена неисправных дисков или серверов
- Модернизация (больше RAM, CPU, дисков)
- Плановое техническое обслуживание
Оптимизация инфраструктуры:
- Балансировка нагрузки между узлами
- Вывод устаревших серверов малой ёмкости
- Перераспределение ролей между узлами
Масштабирование:
- Добавление новых узлов взамен старых
- Переход на более производительное оборудование
Роли узлов в Ceph
В Ceph узлы могут исполнять несколько ролей одновременно.
Основные роли:
| Роль | Назначение | Критичность |
|---|---|---|
| MON (Monitor) | Отслеживает состояние кластера, поддерживает кворум | Высокая |
| MGR (Manager) | Управление кластером, мониторинг, API | Средняя |
| MDS (Metadata Server) | Метаданные для CephFS (только если используется) | Средняя |
| OSD (Object Storage) | Хранение данных | Очень высокая |
MON — самая критичная роль:
- Мониторы поддерживают кворум кластера
- Минимум 3 монитора для отказоустойчивости
- Нельзя выводить больше половины мониторов одновременно
MGR — менее критична:
- Один активный, остальные в режиме standby
- Переключение происходит автоматически
MDS — только для CephFS:
- Если не используете файловое хранилище — роль не нужна
- Один активный, остальные standby
OSD — хранилище данных:
- На каждом узле обычно несколько OSD (по диску на каждый)
- Вывод OSD запускает ребалансинг данных
Порядок вывода узла из кластера
Последовательность критически важна.
Этапы вывода:
| Этап | Что делается | Время | Риск |
|---|---|---|---|
| Перенос MON | Удаление монитора из кворума | 1-2 минуты | Низкий |
| Перенос MGR | Переключение активного менеджера | 1-2 минуты | Низкий |
| Перенос MDS | Переключение активного MDS (если используется CephFS) | 1-2 минуты | Низкий |
| Reweight OSD | Запуск миграции данных с OSD | 10-30 секунд | Средний |
| Ожидание ребалансинга | Перемещение данных на другие узлы | Часы-дни | Высокий |
| Удаление OSD | Вывод OSD из кластера | 5-10 минут | Низкий |
| Очистка узла | Удаление данных и сервисов | 10-20 минут | Низкий |
Критический этап — ребалансинг данных.
Этап 1-3: Перенос служебных ролей
Задача: перенести активные роли (MON, MGR, MDS) на другие узлы.
Что происходит:
- Монитор удаляется из кворума
- Активный менеджер переключается на standby-узел
- Активный MDS переключается на standby-узел
Требования:
- Наличие других узлов с этими ролями в режиме standby
- Минимум 3 монитора должны остаться в кворуме
Время: 3-5 минут на все роли. Риски: минимальные при наличии standby-узлов.
Этап 4-5: Reweight и ребалансинг OSD
Самый длительный и критичный этап.
Что происходит:
Reweight OSD:
- Вес удаляемых OSD устанавливается в 0
- Ceph начинает перемещать данные на другие OSD
- Процесс идёт постепенно, чтобы не перегружать кластер
Ребалансинс:
- Данные копируются на другие узлы
- Сохраняется количество реплик
- Продолжается до полного освобождения удаляемых OSD
Время выполнения зависит от:
- Объёма данных на узле (терабайты требуют часов/дней)
- Скорости сети (10 Гбит/с vs 1 Гбит/с)
- Загрузки кластера (production нагрузка замедляет процесс)
- Свободного места на других узлах
Пример времени:
| Объём данных | Сеть 10 Гбит/с | Сеть 1 Гбит/с |
|---|---|---|
| 500 ГБ | 1-2 часа | 8-12 часов |
| 2 ТБ | 4-6 часов | 1-2 дня |
| 10 ТБ | 1-2 дня | 7-10 дней |
Этап 6-7: Удаление OSD и очистка
После завершения ребалансинга:
- OSD помечаются как безопасные для удаления
- Удаляются из кластера
- Очищаются диски на узле
Время: 15-30 минут.
Риски при выводе узла
Потеря данных:
| Причина | Как избежать |
|---|---|
| Удаление OSD до завершения ребалансинга | Дождаться статуса HEALTH_OK |
| Недостаточно узлов для реплик | Проверить, что узлов >= количества реплик |
| Одновременный вывод нескольких узлов | Выводить по одному |
Перегрузка кластера:
| Проблема | Решение |
|---|---|
| Массовый ребалансинс нагружает оставшиеся OSD | Выводить узлы последовательно |
| Недостаточно свободного места | Проверить свободное место перед началом |
| Падение производительности production | Выполнять в непиковые часы |
Длительное восстановление:
| Фактор | Влияние |
|---|---|
| Объём данных | Терабайты требуют дней |
| Скорость сети | 1 Гбит/с в 10 раз медленнее 10 Гбит/с |
| Production нагрузка | Замедляет ребалансинс в 2-3 раза |
Планирование вывода узла
Предварительная проверка:
| Что проверить | Критерий |
|---|---|
| Статус кластера | HEALTH_OK |
| Количество мониторов | Минимум 4 (останется 3) |
| Наличие standby MGR/MDS | Есть standby на других узлах |
| Свободное место | >30% свободно на других узлах |
| Количество реплик | size >= 3 |
Расчёт времени:
| Компонент | Оценка |
|---|---|
| Перенос ролей (MON/MGR/MDS) | 5-10 минут |
| Ребалансинг данных | Объём (ТБ) × 4-6 часов (при 10 Гбит/с) |
| Удаление OSD и очистка | 30 минут |
| Итого | От нескольких часов до нескольких дней |
Окно обслуживания:
Для узла с 2 ТБ данных:
- Оптимистично: 6-8 часов
- Реалистично: 12-16 часов
- Пессимистично: 24-48 часов (если production нагрузка высокая)
Рекомендации:
- Планировать на выходные или непиковое время
- Закладывать 2× времени от оптимистичной оценки
- Иметь план отката (отменить reweight, если что-то пошло не так)
Мониторинг процесса
Ключевые метрики:
| Метрика | Нормальное значение | Тревога |
|---|---|---|
| Health status | HEALTH_OK или HEALTH_WARN (только degraded) | HEALTH_ERR |
| PG состояние | active+clean | inactive, incomplete |
| Recovery скорость | >50 МБ/с | <10 МБ/с длительно |
| Использование OSD | <80% | >90% |
Что мониторить:
- Статус кластера (должен оставаться HEALTH_OK или HEALTH_WARN с degraded)
- Прогресс ребалансинга (сколько объектов перемещено)
- Нагрузку на сеть и диски оставшихся узлов
- Свободное место на целевых OSD
Типичные проблемы:
| Проблема | Причина | Решение |
|---|---|---|
| Кластер в HEALTH_ERR | Недостаточно места или узлов | Добавить узлы или отменить вывод |
| Медленный ребалансинс | Production нагрузка | Выполнять ночью или снизить нагрузку |
| Зависание на 99% | Проблемы с конкретными OSD | Проверить логи, возможно перезапустить OSD |
Альтернативный подход — временный вывод
Если нужно обслуживание без удаления узла из кластера:
Временный вывод (без ребалансинга):
| Действие | Время | Данные |
|---|---|---|
| Остановить OSD на узле | 1-2 минуты | Остаются на месте |
| Выполнить обслуживание | По ситуации | — |
| Запустить OSD обратно | 1-2 минуты | Recovery только изменений |
Когда применимо:
- Быстрое обслуживание (до 30 минут)
- Замена компонентов без переустановки ОС
- Обновление firmware
Преимущества:
- Не запускается полный ребалансинс
- Экономия времени (минуты вместо часов)
- Меньшая нагрузка на кластер
Ограничения:
- OSD должны вернуться в течение разумного времени
- Кластер работает в degraded состоянии
- Не подходит для замены дисков или вывода узла навсегда
Вывод узла из Ceph — плановая операция, требующая:
- Правильной последовательности (роли → OSD → очистка)
- Терпения (ребалансинс может занять дни)
- Мониторинга на каждом этапе
- Достаточного резерва ресурсов в кластере
Ключевые правила: Проверить наличие standby-ролей перед началом • Убедиться в наличии свободного места (>30%) • Дождаться завершения ребалансинга (HEALTH_OK) • Выводить узлы по одному
При правильном планировании операция безопасна и предсказуема.
Частые вопросы
Сколько времени занимает вывод узла из Ceph?
Зависит от объёма данных и скорости сети. Перенос ролей (MON/MGR/MDS) — 5-10 минут. Ребалансинг данных — главный фактор: 500 ГБ за 1-2 часа при 10 Гбит/с, 2 ТБ за 4-6 часов, 10 ТБ за 1-2 дня. Production нагрузка замедляет процесс в 2-3 раза. Планируйте окно обслуживания с запасом 2× от оптимистичной оценки.
Можно ли выводить несколько узлов одновременно?
Нельзя. Одновременный вывод нескольких узлов перегружает кластер и повышает риск потери данных. Если на двух узлах хранились реплики одних данных — одновременный вывод приведёт к потере доступности. Правило: выводить узлы последовательно, дожидаясь HEALTH_OK после каждого. Для кластера из 5+ узлов допустимо выводить следующий узел, когда предыдущий прошёл reweight (без ожидания полного ребалансинса), но это рискованно.
Что делать, если ребалансинс застрял?
Проверьте: (1) достаточно ли свободного места на оставшихся узлах, (2) все ли OSD работают, (3) нет ли проблем с сетью между узлами. Если всё в порядке, но прогресс остановился — проверьте логи Ceph. Иногда помогает перезапуск проблемных OSD. В крайнем случае можно отменить вывод (вернуть weight обратно), устранить проблему и начать заново.