Комментарии 23
А почему оператор один? Как я понимаю, rook-operator это мастер для ceph, и по идее их тоже надо три для кворума.
да их должно быть нечетное количество для кворума
позвольте поинтересоваться — Вы это откуда взяли?
В доке про обязательное нечетное количество ничего не написано. Можно и 2, и 4, и 6 мониторов...
Ceph monitors are light-weight processes that maintain a master copy of the cluster map. You can run a cluster with 1 monitor. We recommend at least 3 monitors for a production cluster. Ceph monitors use a variation of the Paxos protocol to establish consensus about maps and other critical information across the cluster. Due to the nature of Paxos, Ceph requires a majority of monitors running to establish a quorum (thus establishing consensus).
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. Summarizing, Ceph needs a majority of monitors to be running (and able to communicate with each other), but that majority can be achieved using a single monitor, or 2 out of 2 monitors, 2 out of 3, 3 out of 4, etc.
Т.е. попросту в четном количестве смысла нет, т.к. можно добавить +1 мон и получить устойчивость к отказу еще одного.
Похоже на героические попытки нажить себе проблем, а потом так же георически их решать. Ну, молодцы, что починили и поделились опытом. Пускай все знают насколько это тонкая материя.
С другой стороны — это прекрасная иллюстрация того, что Rook ПРЕКРАСНО ЗАХОДИТ в тестовые среды. Вообще отлично. При этом умолчим о критерии идентичности прода и стейджа. А вот в продакшен среды… Как-то опасливо такое ставить. Тем более, что все эти новомодные операторы явно, что пишут не сеньоры и не покрывают все ситуации тестами.
Ждем статей:
- не тащите любые операторы в свой кластер (это примерно как правила гигиены — не устанавливать любой софт на рабочую машину)
- как определить — плохой или хороший оператор (в ключе нормально ли написан или нет, а не по принципу "выбираем по звездам на гитхабе")
- как сделать оператора секурным (установка операторов в защищенные кластеры — очень сложная и нетривиальная тема).
Я верю в вас — вы можете )))
+1 вопрос:
как считаете — чем хуже отдельный кластер цеф с выделенными нодами? Т.к. типичная ошибка проектантов — в случае с руком — нет выделенной сетки под сторедж, в результате весь трафик летит на общих основаниях. А если цеф-рук на мастерах, то при большой нагрузке смешно (на самом деле — нет) начинают моргать etcd.
Из-за загруженности сети и сервера. Мастера и етсд переставали видеть друг друга, нарушалась синхронизация.
Вам для чего? Деталей не помню. Помню, что был кластер ранчера (задеплоили как было), в него закинули рук, несколько сетевух в бонде. Решили не рисковать в будущем.
Коллеги выше очень верно говорят, что рук добавляет сложности к обслуживанию, т.к. засунуть в него кастомные параметры надо еще умудрится. А цеф такая штука… которая на автопилоте не работает.
ну, тогда лучше в профильном телеграм чатике спрашивать ) не думаю, что там аудитория меньше, чем тут. Речь про https://t.me/kubernetes_ru так-то
Да, трафик синка osd и доступа к rbd-образам от клиентов летит по одной сети, но, как правило, это не приводит к каким-либо глобальным проблемам.
Стоит отметить, что в данном случае речь не идет об инсталляциях ceph на сотни и тысячи машин, как оно бывает в действительно крупных кластерах чистого ceph. Именно поэтому разделение сетей тут не принесет особого эффекта, но, при этом, значительно усложнит настройку, обслуживание и диагностику.
Именно поэтому разделение сетей тут не принесет особого эффекта, но, при этом, значительно усложнит настройку, обслуживание и диагностику.
То же самое можно сказать и про rook, и про кубернетес, и, в целом, использование не подходящих инструментов для решения задач.
Да, трафик синка osd и доступа к rbd-образам от клиентов летит по одной сети, но, как правило, это не приводит к каким-либо глобальным проблемам.
Ага. В частности, в кейсе, когда у Вас одновременно отказала одна нода ceph'а и параллельно активно деплоят в кластер большие образы (у нас разработчики-затейники и иногда попадаются образа по 100ГиБ — это все-таки bad practice, но кластер кубернетес точно не является дуракоустойчивой штукой и не вижу причин добавлять точек отказа).
Реально sysrq или пешком в ЦОД?
А reboot -f? Чем он отличается от sysrq в данном случае?
Наши руки не для скуки: восстановление кластера Rook в K8s