Вопрос или проблема
У меня была спецификация сервиса, которая назначала все свободные SSD диски OSD:
service\_type: osd
service\_id: dashboard-tintin-7634852880
service\_name: osd.dashboard-tintin-7634852880
placement:
host\_pattern: '*'
spec:
data\_devices:
rotational: false
filter\_logic: AND
objectstore: bluestore
Я хочу больше контроля над тем, какие диски назначаются каждым сервером, поэтому я создал несколько новых спецификаций следующим образом:
service_type: osd
service_id: dashboard-tintin-1715222958508
service_name: osd.dashboard-tintin-1715222958508
placement:
host_pattern: 'host1'
spec:
data_devices:
rotational: false
filter_logic: AND
objectstore: bluestore
В Ceph Dashboard -> Сервисы я видел, что мои старые демоны OSD продолжали работать под контролем старых определений сервиса. Я удалил старое определение сервиса. Я получил предупреждение:
Если osd.dashboard-tintin-7634852880 будет удален, следующие OSD останутся, --force чтобы продолжить в любом случае ...
Как я и думал, поддержание работы демонов — это то, что мне нужно, я продолжил с --force. Теперь в Ceph Dashboard -> Сервисы списки OSD отображаются как “Неуправляемые”, и новое определение сервиса все еще не забрало их. Как я могу переместить этих демонов OSD под новую спецификацию сервиса?
Если я остановлю демоны, новые не запускаются по новому определению сервиса. Если я повторно разверну демонов, они все равно отображаются как “неуправляемые”. Единственный способ переместить их под новое определение сервиса — это остановить демон и затирать диск. Однако это не практическое решение, учитывая размер кластера.
Учитывая, что данные присутствуют и верны, я удивлен, что нет способа вернуть заблудшие демоны в норму. (Я смотрел документацию о заблудших демонах, но они упоминают только контекст обновления кластера до cephadm).
Это часть моего ceph orch ls osd --export:
service_type: osd
service_id: dashboard-tintin-1706434852880
service_name: osd.dashboard-tintin-1706434852880
unmanaged: true
spec:
filter_logic: AND
objectstore: bluestore
---
service_type: osd
service_id: dashboard-tintin-1715222958508
service_name: osd.dashboard-tintin-1715222958508
placement:
host_pattern: ceph-pn-osd1
spec:
data_devices:
rotational: false
filter_logic: AND
objectstore: bluestore
---
service_type: osd
service_id: dashboard-tintin-1712545397532
service_name: osd.dashboard-tintin-1712545397532
placement:
host_pattern: ceph-pn-osd2
spec:
data_devices:
rotational: false
filter_logic: AND
objectstore: bluestore
---
service_type: osd
service_id: dashboard-tintin-1706421419210
service_name: osd.dashboard-tintin-1706421419210
placement:
host_pattern: ceph-pn-osd3
spec:
data_devices:
rotational: false
filter_logic: AND
objectstore: bluestore
---
service_type: osd
service_id: dashboard-tintin-1706421419211
service_name: osd.dashboard-tintin-1706421419211
placement:
host_pattern: ceph-pn-osd4
spec:
data_devices:
rotational: false
filter_logic: AND
objectstore: bluestore
---
service_type: osd
service_id: dashboard-tintin-1706425693555
service_name: osd.dashboard-tintin-1706425693555
placement:
host_pattern: ceph-pn-osd5
spec:
data_devices:
rotational: false
filter_logic: AND
objectstore: bluestore
Ответ или решение
Для успешного перемещения OSD-демонов под новое определение сервиса в Ceph, необходимо учесть несколько шагов и принципов. Понимание работы системы и взаимодействия с ним поможет избежать потери данных и ограничения управляемости. Рассмотрим последовательные шаги решения вашей проблемы.
Шаг 1: Анализ текущего состояния
На данный момент вы удалили старое определение сервиса, и оставшиеся демоны OSD теперь отображаются как "Unmanaged" (некорректно управляемые). Это свидетельствует о том, что система не знает, к какому новому определению сервиса они могут быть привязаны. Следует обратить внимание на то, что каждое определение сервиса в Ceph связано с конкретными OSD-демонами по их конфигурации и метаданным.
Шаг 2: Настройка нового определения сервиса
Убедитесь, что новое определение сервиса создаёт все необходимые условия для управления OSD-демонами. В вашем случае с уже существующими OSD-дисками важно настроить соответствующие директивы для правильного применения.
Пример корректной настройки нового сервиса может выглядеть так:
service_type: osd
service_id: dashboard-tintin-1715222958508
service_name: osd.dashboard-tintin-1715222958508
placement:
host_pattern: 'host1'
spec:
data_devices:
rotational: false
filter_logic: 'AND'
objectstore: bluestoreПроверьте, чтобы host_pattern совпадал с хостами, содержащими OSD.
Шаг 3: Принудительное перенаправление
К сожалению, без остановки демонов перенаправление может не сработать. Поэтому выполните следующие действия:
-
Остановите OSD-демоны. Это нужно сделать для того, чтобы система могла пересоздать связи с новым определением. Используйте команду:
ceph orch osd stop <osd-id>Замените
<osd-id>на соответствующий идентификатор OSD. -
Переместите OSD-демоны под новое определение. После остановки осей можно продолжить с импортом или пересозданием. Обычно, при следующем использовании команды
ceph orch apply osdсистема должна корректно распределить демоны снова в соответствии с новым определением. -
Запустите OSD-демоны.
После этого можно перезапустить демоны OSD:
ceph orch osd start <osd-id> -
Проверьте состояние систем. Используйте команды, чтобы убедиться, что OSD находятся под новым контролем:
ceph orch ls
Шаг 4: Удаление ненужных OSD
При необходимости можно удалить остаточные записи о незакрепленных OSD, используя ceph orch osd rm <osd-id>, если они не нужны.
Заключение
Тщательно настройте ваши определения сервисов, чтобы минимизировать вероятность возникновения аналогичных проблем в будущем. Не забывайте, что внимательное обращение с OSD-демонами и понимание их процесса управления — это ключ к стабильности вашей Ceph-кластера. Если у вас остались вопросы или требуется дополнительная помощь, пожалуйста, не стесняйтесь их задать.