Pull to refresh

Comments 23

А почему оператор один? Как я понимаю, rook-operator это мастер для ceph, и по идее их тоже надо три для кворума.

Нет, что за мастер для ceph? Суть оператора это управлять сущностями в виде mon,osd,csi плагинами и discovery
rook-operator — это сущность для кубера, которая провижинит вам ceph кластер в нем, а у цефв, то что вы назвали мастерами, является mon, да их должно быть нечетное количество для кворума
да их должно быть нечетное количество для кворума

позвольте поинтересоваться — Вы это откуда взяли?
В доке про обязательное нечетное количество ничего не написано. Можно и 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 мон и получить устойчивость к отказу еще одного.

В документации для более старых версий (0.8 0.9 версий) они писали про нечетное колличество mon как рекомендация.

Похоже на героические попытки нажить себе проблем, а потом так же георически их решать. Ну, молодцы, что починили и поделились опытом. Пускай все знают насколько это тонкая материя.
С другой стороны — это прекрасная иллюстрация того, что Rook ПРЕКРАСНО ЗАХОДИТ в тестовые среды. Вообще отлично. При этом умолчим о критерии идентичности прода и стейджа. А вот в продакшен среды… Как-то опасливо такое ставить. Тем более, что все эти новомодные операторы явно, что пишут не сеньоры и не покрывают все ситуации тестами.

Во, как раз скоро будет у нас другая статья про один такой оператор (печальные последствия его использования) ;-)

Ждем статей:


  • не тащите любые операторы в свой кластер (это примерно как правила гигиены — не устанавливать любой софт на рабочую машину)
  • как определить — плохой или хороший оператор (в ключе нормально ли написан или нет, а не по принципу "выбираем по звездам на гитхабе")
  • как сделать оператора секурным (установка операторов в защищенные кластеры — очень сложная и нетривиальная тема).

Я верю в вас — вы можете )))

+1 вопрос:
как считаете — чем хуже отдельный кластер цеф с выделенными нодами? Т.к. типичная ошибка проектантов — в случае с руком — нет выделенной сетки под сторедж, в результате весь трафик летит на общих основаниях. А если цеф-рук на мастерах, то при большой нагрузке смешно (на самом деле — нет) начинают моргать etcd.

Что есть моргать? из-за загруженности сети? или из-за исчерпания ресурсов нод?

Из-за загруженности сети и сервера. Мастера и етсд переставали видеть друг друга, нарушалась синхронизация.

Если не сложно можно чуть больше информации о вашем кейсе? etcd в докере или systemd? есть ли резервация ресурсов для etcd и kubelet ресурсов, какая скорость сети? сколько нод в кластере? и в какой момент началось такое поведение, был какой то сбой или вывалились osd?

Вам для чего? Деталей не помню. Помню, что был кластер ранчера (задеплоили как было), в него закинули рук, несколько сетевух в бонде. Решили не рисковать в будущем.
Коллеги выше очень верно говорят, что рук добавляет сложности к обслуживанию, т.к. засунуть в него кастомные параметры надо еще умудрится. А цеф такая штука… которая на автопилоте не работает.

предстоит эксплуатация, вот собираю чужие грабли

ну, тогда лучше в профильном телеграм чатике спрашивать ) не думаю, что там аудитория меньше, чем тут. Речь про https://t.me/kubernetes_ru так-то

Как показывает практика, *далеко не всегда необходимо* разделять cluster_network и public_network, да и даже не всегда для этого есть возможности.

Да, трафик синка osd и доступа к rbd-образам от клиентов летит по одной сети, но, как правило, это не приводит к каким-либо глобальным проблемам.

Стоит отметить, что в данном случае речь не идет об инсталляциях ceph на сотни и тысячи машин, как оно бывает в действительно крупных кластерах чистого ceph. Именно поэтому разделение сетей тут не принесет особого эффекта, но, при этом, значительно усложнит настройку, обслуживание и диагностику.
Именно поэтому разделение сетей тут не принесет особого эффекта, но, при этом, значительно усложнит настройку, обслуживание и диагностику.

То же самое можно сказать и про rook, и про кубернетес, и, в целом, использование не подходящих инструментов для решения задач.


Да, трафик синка osd и доступа к rbd-образам от клиентов летит по одной сети, но, как правило, это не приводит к каким-либо глобальным проблемам.

Ага. В частности, в кейсе, когда у Вас одновременно отказала одна нода ceph'а и параллельно активно деплоят в кластер большие образы (у нас разработчики-затейники и иногда попадаются образа по 100ГиБ — это все-таки bad practice, но кластер кубернетес точно не является дуракоустойчивой штукой и не вижу причин добавлять точек отказа).

Реальный случай, причем старались его воспроизвести, но не получилось, а это совсем грустно.
P.S. Версия была v1.0.4.
т.е получается rook-operator без перезапуска и прочего, решил задеплоить новый кластер?
Все конечно хорошо, но описание причины того, что rook-operator решил задеплоить новый кластер, ибо это выходит как, лечение симптоматики до следующего такого редеплоя

Реально sysrq или пешком в ЦОД?
А reboot -f? Чем он отличается от sysrq в данном случае?

Only those users with full accounts are able to leave comments. Log in, please.