Спасибо за подсказки. Я прочитал несколько других обсуждений, которые много мне дали, но не привели к решению. Я пробовал разные вещи, включая использование команды `repair pg`, но это не помогло. Я нашел OSD, отвечающие за PG, помеченные как +remapped, и отключил и вынул их, а затем вернул в состояние up/in, но это не изменило ситуацию. Всё это время Ceph сообщает о здоровом кластере.

В этой ситуации я начал с одного реплицированного rbd пула с использованием crush map, который пишет исключительно на SSD-диски. В таком состоянии Ceph сообщил, что все PG активны и чисты. Затем я добавил erasure coded pool K=2/m=1 с профилем EC для использования HDD-дисков. Именно в этот момент Ceph начал сообщать о 3 PG с статусом +remapped, как я уже сообщал в предыдущем сообщении.

Это состояние сохраняется, и я не могу полностью изменить статус PG на активный и чистый. Я решил полностью удалить EC pool и его профиль. У меня были дополнительные HDD, которые я добавил к одному из узлов, у которого было меньше HDD, чем у двух других, чтобы создать другую ситуацию. Я добавил этот новый диск в качестве OSD и создал новый erasure coded pool и профиль. Теперь Ceph сообщает, что кластер здоров, но статус PG: 64 PG активны и чисты, и 1 PG активен и чист + remapped. То есть, в целом получается похожий результат, и я не могу понять, как это повлиять.

Если кто-то сможет помочь, буду очень признателен. Как есть, Ceph-кластер не содержит данных, и я не готов использовать его для чего-либо еще, пока не смогу разобраться и решить эту проблему.

Сообщите, если я могу предоставить какую-либо дополнительную информацию для устранения неполадок.

Это тоже может пригодиться, это дамп PG, показывающий PG со странным статусом. Список неполный, он ограничен только теми PG, которые связаны с пулом #8 (пул EC). Также прикладываю вывод PG, выделенных для Ceph_RBD_EC_Pool (пул #8). Смотрите вложение 84180.

Спасибо за советы и за то, что потратили время, чтобы рассмотреть мой пост. Я начну более тщательно изучать документацию, чтобы разобраться. Непонятно, почему одна группа размещения не может разрешиться в активную + чистую в этой ситуации, когда текущий спрос на хранилище равен нулю. Буду благодарен за любые мысли.

Кодирование стирания не применимо в таких маленьких кластерах. Чтобы это имело какой-то смысл, тебе нужно минимум 10 нод с достаточным количеством OSD.