Как у нас сломался Ceph

Дело в том, что именно такой подход и помог вспомнить. Конечно, пытались сначала проверить, что изменялось за последние N дней. И логи паппета смотрели, и dpkg.log, syslog и так далее. Что ставилась неправильная версия ceph, знал лишь один человек, который в этой ситуации не связал это падение с тем случаем и вспомнил, когда ему задали конкретный вопрос.

Документировать все работы, наверное, возможно только если вы либо очень маленькая компания или очень большая, в которой это просто жизненная необходимость. В моем идеальном мире все документируется и каждый чих где-то записывается, но не мной :) Но вряд ли этот идеальный мир когда-то настанет

Блин, круто) Мне не приходилось работать с таким количестовм osd, максимум имел дело с около 100. Сейчас уже почти с ceph не работаю, но воспоминания еще достаточно свежи, что это чудо нужно постоянно дебажить и изучать, почему все идет не так, как надо. Я тогда работал с самым новым Jewel, и в кластере периодически происходило так, что osd выключались рандомно и перезапукались systemd. Чего только с ceph не происходило, я ловил множество непонятных ситуаций, когда приходилось придумывать какие-то воркэраунды или мириться с таким поведением и придумывать хитрости. Расскажу про пару вещей:
— Стораджи с 20 osd на борту. Сервер завис, нужно рестартить. После рестарта поднимается лишь часть osd. Остальные юниты failed в systemd. Ну, наверное, что-то при загрузке не так пошло. Потом нужно по какой-то причине проверить, как рестартятся osd. Делаешь systemctl restart ceph-osd.target. Все osd выключаются, стартуют все, а в CRUSH показаны многие osd на ноде как down, хотя процессы запущены. Что за чудеса? В итоге выяснили экспериментальным путем, что при одновременном старте osd у этих самых osd начинается что-то типа race condition за то, чтобы занять порты из выделенных им диапазона, и дальше что-то идет не так, и некоторые osd некорректно регистрируются в кластере. Пришлось писать обвязку, которая стартовала osd с задержкой (sleep) на определенное количество времени в зависимости от их id.
— Другой случай вообще классический. Я частично описал его в статье. В кластере появились slow requests. Анализируешь ситуацию, видишь, что все реквесты на одной osd. Смотришь ceph osd tree, все osd UP и IN. Идешь на ноду к этой osd, а она не запущена! Понятно, почему slow requests копятся. И непонятно, почему все osd рядом, которые должны ее пинговать, не зарепортили монитору, что она down, и он ее не пометил должным образом?
— У ceph есть официальный ansible-playbook для создания кластера, деплоя мониторов, osd и т.д. Мы им пользовались для начальной наливки кластера и потом временами, когда надо было диск заменить в сервере и засетапить нового демона osd. Но было замечено, что часто, но не всегда, в кластере после прохождения по нему плейбуком образовывалось слишком много degraded и misplaced объектов, больше, чем нужно. Жить особо не мешало, просто увеличивало время recovery. Но периодичеcки появлялись slow requests, и это стало затрагивать прод. Оказалось, что этот плейбук проходился по папкам /var/lib/ceph/*, выуживал оттуда id osd и считал, что именно они и должны быть запущены на данной ноде. Но ведь, когда диск вылетает (или вылетело два диска на разных нодах), ты наливаешь osd на новый диск и он получает минимально возможный номер в кластере, т.е. вылетевший osd.17 на z ноде, может быть потом налит на x ноде, а на z ноде останется пустая папка под 17 osd, в которую раньше монтировался диск. Поэтому ceph наливал на неиспользованном диске osd (если мог) и запускал 17й osd снова на z ноде, из-за этого менялась crush map, на x ноде валидный osd.17 делал out из кластера, потому что новая регистрация пришла с z ноды и оверрайтнула предыдущую карту. Пришлось писать мониторинг пустых папок в этой директории и оперативно их удалять :) И хорошо, если диск нормальный, а если диск битый или готовый развалиться, а его не успели еще поменять. Вот тогда будет много слоу реквестов.
В общем, приходилось много не спать, читать мануалы и немногочисленные, к сожалению, форумы и почтовую рассылку. Даже в багтрекер Ceph тикет когда-о создавал.
Так что, на моей памяти ceph — отличный продукт и клевой идеей и реализацией, но очень нестабильный. Возможно, были еще какие-то факторы, влияющие на стабильность кластеров, или это просто моя корма и везение, кто знает)

8 мониторов — так исторически сложилось, что мониторами являются несколько compute нод опенстека и несколько стораджей. Когда-то так сделали, ну и ладно с ним.
Реплика 2 для dev окружения… что вам не нравится? Enterprise SSD диски с тройной репликой да не на проде — это больно уж круто. Диски надежные, пашут исправно, вылетают очень редко, а в подобной ситуации так я вообще не уверен, что реплика 3 вас спасла бы

4 года назад пытался запустить cephFS.

Да он до сих пор не имеет статус production, хотя и stable :). Для CephFS узким местом в первую очередь является MDS.

Спасибо за совет, да, я видел эти рекомендации. Сейчас мониторов 5, но есть у меня предположение, что при числе мониторов, стремящихся от 0 к бесконечности, нечетность их количества не играет особой сути, и эта дока имеет ввиду: «Чуваки, не делайте 2 монитора, потому что это сплит брейн. 3 хорошо.»

It is advisable to run an odd-number of monitors but not mandatory. An odd-number of monitors has a higher resiliency to failures than an even-number of monitors. For instance, on a 2 monitor deployment, no failures can be tolerated in order to maintain a quorum; with 3 monitors, one failure can be tolerated; in a 4 monitor deployment, one failure can be tolerated; with 5 monitors, two failures can be tolerated. This is why an odd-number is advisable.

То есть в случае с 8 мониторами, 8й монитор ни к селу, ни к городу, так как не увеличивает resiliency кластера) Но это не критично