> Основной задачей было обеспечение надёжности без применения CRUSH Map.

Расскажите пожалуйста как Ceph может работать без CRUSH map. Этот алгоритм лежит в центре его вселенной распределения данных.
Кстати, вы там команды ниже выдаёте из раздела http://docs.ceph.com/docs/mimic/rados/operations/crush-map/ - адрес его нам как бы намекает.
Или я чего-то глубоко не знаю? Тогда хочу пруфлинк на ознакомление.

> Ceph: Версия не важно но

Очень смелое заявление, особенно для человека который опирается на обработку выхлопа утилит. Который например очень сильно поменялся от jewel к luminous.

> то есть 1 SSD на 6 HDD дисков

Тоже так себе решение. Официально рекомендовано не более 4х на 1 диск. Иначе, можно запросто получить ужасающую производительность, настолько, что проще жить без SSD сделав журнал на тех же дисках что и данные.

И второе - вы же понимаете что в случае отказа 1 SSD из имеющихся 4х вы получаете превращение в тыкву четверти дисков с данными? Т.е. нужен экстренный recovery дающий высокий I/O (настроек обрезающих его я не заметил) на оставшихся живых дисках с парной машины, что с высокой вероятностью может привести к выводу из строя их и как результат (при вашей архитектуре) - полной потере половины данных. Если пользовательские данные хранились через RBD, то фактически это будет эквивалентно потере *всех* данных. Т.к. данные каждого RBD будут +/- равномерно распределены по всем osd, следовательно каждая RBD у вас будет на 50% потеряна. На практике это обозначает его полную потерю, потому что при попытке чтения смещения указывающего на недоступную PG вы получите D статус процесса.

Есть ещё ряд причин по которым делать избыточность = 2 строго не рекомендовано, это ещё сам производитель начиная с jewel версии говорит. В общем, "подумайте о детях" как говорится.

> напомню, что проблема с правкой крушмапа осталась в версии до 12.x.x.

Напомните пожалуйста что за проблема конкретно. На паре кластеров что я разворачивал и поддерживал никаких проблем не было.

> /usr/bin/ceph health detail | grep active+clean+inconsistent | awk '{ print $2 }' | while read a; do /usr/bin/ceph pg repair $a ; done

Вот за это... Ну ничего хорошего я не сказал бы ни вам, ни кому быт то ни было ещё. И нет, дело тут не только в безумной цепочке конвейеров, или даже в том что вывод от версии к версии таки может поменяться (используйте API если хотите делать нормально, зачем стыдобищу выкладывать?).

Бездумный repair раз в 10 минут на умирающие PG приведёт вас к тому что рано или поздно они перестанут восстанавливаться и ваш кластер превратится в тыкву по сценарию описанному выше.

Сами по себе PG не вываливаются, чаще всего (исключив неадекватов в серверной) это симптом проблемного диска. Т.е. надо смотреть после каждого такого развала в smart и как минимум фиксировать его состояние (если не можете сразу менять диски с reallocated и прочим странным), что бы сравнивать с последующим случаем выпадения PG.