Comments 38
Главное, чтобы количество оных было нечетным, дабы избежать ситуаций раздвоения сознания (split-brain).
Да, ну? Не спец по цеф, но всякие кластерные решения прекрасно работают с четным количеством. Другой вопрос, что смысла в этом мало, т.к. отказоустойчивости это не добавляет относительно варианта с N-1 нодами. Проще уж добавить ещё 1 и стать устойчивым к отказу ещё одного узла
Про важность ntp тема нераскрыта. Недостаточно просто установить ntp-клиент, но и надо его настроить правильно.
Так же не очень понял почему выбран дебиан дистрибутив
По поводу четности нод. Вы же сами написали что какой в этом смысл? Что бы просто иметь еще один демон монитора? При количестве мониторов равных 2 отказоустойчивости нет плюс ко всему можно нарватся на split-brain. При количестве мониторов 4 имеем отказоустойчивость точно такую же как и при 3-х и тд.
Вы просто пишете, что оно в принципе не будет работать при нечетном количестве нод, но это неверное утверждение.
При количестве мониторов равных 2 отказоустойчивости нет плюс ко всему можно нарватся на split-brain
Are you sure? Или при развале кластера он просто заблокируется в режиме "только чтение"?
Лично я никогда не нарывался на split-brain (у меня в проде больше мониторов чем 2), но я допускаю что такое может случится, например когда один из мониторов на какое то недолгое время выйдет из строя (по любой причине) а потом поднимется.
Так сплит Брейн или Рид онли для обеспечения консистентности?
Вы уж извините, но либо крестик снимите, либо трусы оденьте.
Рид онли для меня это рано тому, что кластер не работает, мне нужно как читать так и писать информацию.
Для обеспечение консистенции не имеет смысла иметь четное количество нод.
Мне кажется и я и другие участники уже все выше написали.
Честно говоря вести дальше обсуждение в тоне крестиков и трусов не вижу смысла.
Спасибо за внимание.
Для обеспечение консистенции не имеет смысла иметь четное количество нод.
Нет, это не так. Просто отказоустойчивость не будет больше, чем в случае нечётного на единицу меньше количества нод. А не то, что такая конфигурация в принципе "плохая" или "невозможная".
Причем я об этом достаточно внятно написал в первом комментарии. )
A majority of monitors in your cluster must be able to reach each other in order to establish a quorum.
Все просто, при четном количестве мониторов кворум так же потеряется как и при количестве равном n-1.
Например 3 монитора и 4 могут пережить падение только одного. Потеря двух ломает кворум, потому что в первом случае остается <50% живых, а во втором 50%, что не тянет на кворум.
Аналогично 5 и 6. Потерять 2? — пожалуйста, потерять 3, уже все.
Никто не говорит, что не будет работать на четном количестве. Но зачем платить больше? Или, наоборот, иногда лучше доплатить, чтобы получить кворум большего размера и выдержать больше падений.
Когда улетает один монитор и формируется кворум, я часто наблюдаю, как в этом процессе улетает и второй, не на долго, но система успевает об этом сообщить. Поэтому 5 штук, я думаю наименьшее из более-менее надежных решений, а при 4х тут могло бы быть и неприятно.
Это все понятно, просто у автора изначально в статье было некорректное утверждение.
Либо давайте сойдёмся на том, что в настоящей статье этот момент описан очень двусмысленно и из него можно сделать неверные выводы.
Сейчас в ней такое:
Кластер может прожить на одном мониторе, но рекомендуется делать 3 или 5 мониторов, во избежание падения всей системы по причине падения единственного монитора. Главное, чтобы количество оных было нечетным, дабы избежать ситуаций раздвоения сознания (split-brain). Мониторы работают в кворуме, поэтому если упадет больше половины мониторов, кластер заблокируется для предотвращения рассогласованности данных.
Честно говоря, я не представляю, что нужно сделать с цефом, чтобы он ушел в сплит брейн. Чай не drdb 8-й версии. А внутри там, насколько, я помню алгоритм рафт, который и гарантирует невозможность ситуации сплит Брейна. Т.е. либо цеф работает, либо он переходит в заблокированное состояние. Третьего не должно быть.
И скорее это будет не сплитбрейн, а потеря кворума два двух половин. Без кворума и то и это встанет колом, пока не соберется в кучу обратно.
Большим количеством объектов, от нескольких миллионов?
Я пока что боюсь, причем даже не настолько самого Rook, а того что в случае каких либо проблем траблшутить будет достаточно проблемно.
Но не пробовал, вот думал, что может тут найдется кто-то, у кого он в проде работает и расскажет о проблемах.
Так-то для BM кластеров и выбора особо нет. Rook, Longhorn и еще пара вариантов. Либо настраивай все ручками.
Ну вроде как от работает поверх CEPH, т.е. если оно работает там, то и здесь должно.
не понял. Rook поверх ceph — это совсем не то же самое, что и ceph отдельно. Мы пробовали, но делать из кластера что-то типа HCI — гиблая идея. Неудобно. Нестабильно. И вообще непонятно как менеджить, если нужные какие-то уникальные настройки. Идеальный сценарий — когда ceph рядом с кластером, на отдельных нодах.
Можете вкратце рассказать на каких нагрузках, под что (бд, просто файлы, шаринг) и на каких объемах? И в чем проявилась нестабильность.
Я бы отослал к статье https://habr.com/ru/post/452174/
Свои замечания: как правило rook означает, что кластер собран в каком-нибудь хетцнере без какого-либо планирования сети (отдельно публичная, отдельно storage сеть). Если класть rook на мастера кубернетеса и давать нагрузку — оно начинает смешно флапать. БД класть на ceph… Ну, такое себе. У него же производительность не очень высокая. Можно уйти в сеть и… не вернуться. БД — только на локальные хранилища, желательна репликация внутри самой БД. Или вообще внешние инстансы — получается что-то типа managed DB.
Просто файл, шаринг и прочее — прекрасно работают, но задумайтесь о том, может стоит переписать свои приложеньки и переделать на объектное хранилище? S3 поверх ceph (rook) прекрасно работает, но там как бы хайлоада и нет.
Что ещё добавить. rbd не умеют в RWX, что иногда бывает нужно некоторым приложениям. Решение? Ну, можно поднять в отдельном поде nfs, который будет маунтить rbd'ху, но это костыль.
Но если Вам нужен RWX, то вероятно опять в архитектуре приложения что-то не так.
Ещё ceph не умеет ресайзить вольюмы. Только через пересоздание...
Про ресайз коллеги подсказывают, что если заменить controller-manager на hyperkube или использовать CSI (container storage interface) то ресайз возможен, НО потребуется рестарт пода.
Я лично не проверял, но как раз на днях хочу проверить на тестовом кластере.
В общем-то, сейчас именно такое понимание и есть. БД в hostPath, от k8s там по сути ничего нет, просто удобнее управлять версией и настройками. Остальное стараюсь переводить на stateless модель, используя внешнее S3. Просто это не всегда удобно, вот и смотрю на разные варианты для хранилища файлов до 1Тб.
Коллеги подсказывают, что HostPath несекурно и не очень… Безопасно.
Рекомендуется данные бд тогда в persistent local volume класть
https://kubernetes.io/blog/2019/04/04/kubernetes-1.14-local-persistent-volumes-ga/
Насчёт версии и настроек — сами знаете насчёт того как работают кластеризованные бд в кубере, можно ловить спецэффекты
Насчёт версии и настроек — не знаю. У меня не было проблем. Раньше в докер-сварм, потом то же самое переехало в k8s. Все работает, все классно.
— hostpath тяжело использовать с чартами helm которые требуют указать storageclass
— hostpath не работают с StatefulSets
— cоздание LocalStorage можно хоть как то автоматизировать, например чем то типа такого
— LocalStorage можно использовать в StatefulSet как volumeClaimTemplate
Дополню. Скажем, под переедет на другую ноду. Что произойдет с hostpath? Да ничего — данные останутся на старой ноде. А на новой тот же постгрес может создать пустую базу. В случае продакшена — все начнется с чистого листа, приложение возможно начнет лить данные в новую базу. Спецэффекты. Катастрофа.
В случае с вольюмами — у вас под останется на той же ноде. И это плюс.
Насчёт безопасности все просто — как только есть hostpath — можно с кластером из непривилегировпнного творить что угодно. Недавно была отличная статья от "Южного Моста" как строить безопасность кластера
В общем то в случае с localstorage так и происходит через механизм nodeAffinity. Но опять же это дополнительная работа.
Но на сколько мне известно, statefull обычно прибивают к конкретным нодам. Ну если у вас только не облачное решение, где диски монтируются как угодно.
Вы статью по ссылке моей читали?
The biggest difference is that the Kubernetes scheduler understands which node a Local Persistent Volume belongs to. With HostPath volumes, a pod referencing a HostPath volume may be moved by the scheduler to a different node resulting in data loss. But with Local Persistent Volumes, the Kubernetes scheduler ensures that a pod using a Local Persistent Volume is always scheduled to the same node.
Давно хотел повторить тоже самое, но хочу использовать openshift, я так понимаю вы делали это на proxmox?
Подскажите, пожалуйста, плейбуки из репозитория https://github.com/ceph/ceph-ansible/blob/master/README.rst рассматривали ?
Разворачиваем распределенное хранилище CEPH и подключаем его к Kubernetes