Комментарии 20
У нас подобная схема не заработала стабильно ибо:
1. Как БД использовали Precona Cluster (master-master) и он не стартовал сам в случае одновременного отключения всех нод и их последующего запуска (отказ по питанию в стойке)
2. У вас в схеме нет shared system datastore / shared file datastore — соответственно не получится загружать файлы ядер или скрипты контекстуализации. Мы делали его сначала на NFS, потом на SAMBA и он перемещался между нодами вместе с OpenNebula тут тоже возникли проблемы из-за невозможности размонтировать rbd т.к. он используется.
3. Проблемы с обновлением OpenNebula т.к. нужно обновлять все ноды.
В итоге пришли к простой схеме:
1. Всё хранится в CEPH
2. OpenNebula + MySQL для неё работают на виртуалке, которая тоже хранится в CEPH
3. На нодах лежит файл для virsh, с описанием виртуалки OpenNebula
4. corosync занимается только тем, что запускает виртуалку с OpenNebula в virsh на одной из нод и следит, чтобы она всегда работала
Как бонус — меньше кластеризованных сервисов — меньше коллизий.
1. Как БД использовали Precona Cluster (master-master) и он не стартовал сам в случае одновременного отключения всех нод и их последующего запуска (отказ по питанию в стойке)
2. У вас в схеме нет shared system datastore / shared file datastore — соответственно не получится загружать файлы ядер или скрипты контекстуализации. Мы делали его сначала на NFS, потом на SAMBA и он перемещался между нодами вместе с OpenNebula тут тоже возникли проблемы из-за невозможности размонтировать rbd т.к. он используется.
3. Проблемы с обновлением OpenNebula т.к. нужно обновлять все ноды.
В итоге пришли к простой схеме:
1. Всё хранится в CEPH
2. OpenNebula + MySQL для неё работают на виртуалке, которая тоже хранится в CEPH
3. На нодах лежит файл для virsh, с описанием виртуалки OpenNebula
4. corosync занимается только тем, что запускает виртуалку с OpenNebula в virsh на одной из нод и следит, чтобы она всегда работала
Как бонус — меньше кластеризованных сервисов — меньше коллизий.
В случае если нужен shared datastore, можно поднять Metadata Server и использовать для этого Ceph FS.
1. CephFS не production-ready
2. При падении основного Metadata сервера, все клиенты, которые работают с ней встают в deadlock на уровне ядра, после этого помогает только перезагрузка, что не есть хорошо
Хм, я так понял, что уже production-ready, про такие проблемы не знал. Еще наклевывается вариант с drbd…
Почему бы не поднять iscsi используя ceph, а в нем ocfs2 и выдать кому надо?
Как вообще CEPH по сравнению с GlusterFS?
Мы используем CEPH как block-storage, Gluster насколько я знаю это именно FileSystem, соответственно тут они не конкуренты.
Основными причинами, почему мы начали использовать Ceph были:
1. Quorum-based система выбора мастера, то есть при 2n+1 нодах split-brain мы не получаем.
2. Самолечение при сбое ( то есть если произошёл отказ ceph сам создаст умершие копии / выведет — введёт osd в кластер и всё само нормализуется через некоторое время)
3. Достаточно детальная документация и адекватная производительность (при условии следования документации — 2 разные сети, одна для виртуалок, вторая под ceph)
ИМХО: кластерная система хранения должна сама отрабатывать сбои, а не требовать вмешательства администратора, всё что я читал про Gluster говорит о том, что он так не умеет.
Основными причинами, почему мы начали использовать Ceph были:
1. Quorum-based система выбора мастера, то есть при 2n+1 нодах split-brain мы не получаем.
2. Самолечение при сбое ( то есть если произошёл отказ ceph сам создаст умершие копии / выведет — введёт osd в кластер и всё само нормализуется через некоторое время)
3. Достаточно детальная документация и адекватная производительность (при условии следования документации — 2 разные сети, одна для виртуалок, вторая под ceph)
ИМХО: кластерная система хранения должна сама отрабатывать сбои, а не требовать вмешательства администратора, всё что я читал про Gluster говорит о том, что он так не умеет.
Почему OpenNebula, а не openstack?
А сможете провести и расписать результаты тестирования? Выход из строя хранилища (одного или нескольких), вычислительных нод, падения сети? С цифрами и итогами.
Подобной конфигурации кластер поднят в продакшене, вы можете посмотреть некоторые результаты тестов здесь.
Проводить fail-тесты к сожалению сейчас нет никакой возможности, но могу сказать точно, при отказе одной ноды из трех, ceph-кластер начинает интенсивное восстановление и становится куда менее отзывчивым.
Насколько я понимаю, он расчитан на гораздо бОльшие масштабы.
Проводить fail-тесты к сожалению сейчас нет никакой возможности, но могу сказать точно, при отказе одной ноды из трех, ceph-кластер начинает интенсивное восстановление и становится куда менее отзывчивым.
Насколько я понимаю, он расчитан на гораздо бОльшие масштабы.
Используется полностью аналогичная система, я первоначально подумал что мои коллеги писали, оказывается нет.
Пара замечаний — ovs есть в репозитории RDO, собирать его не нужно.
От кэширования на ssd отказались в пользу журнала на ssd+bcache. немного в скорости выйграли.
Corosync, а точнее прибивание дохлой ноды лучше бы настроить, ловили пару раз запуск виртуалок в 2 копиях.
небулу храним внутри вм, corosync следит за ней (как и в первом комментарии)
для автоматического запуска galera кластера в случае коллапса — необходимо поднять демона который учавствует в кворуме но не хранит данные (не помню как называется)
ну и под общие файлы (/var/lib/one/datastores/ используем cephfs, с несколькими mds, проблем не встречали, единственное что — монтируем через fuse, так как ядерный модуль залипает.
Пара замечаний — ovs есть в репозитории RDO, собирать его не нужно.
От кэширования на ssd отказались в пользу журнала на ssd+bcache. немного в скорости выйграли.
Corosync, а точнее прибивание дохлой ноды лучше бы настроить, ловили пару раз запуск виртуалок в 2 копиях.
небулу храним внутри вм, corosync следит за ней (как и в первом комментарии)
для автоматического запуска galera кластера в случае коллапса — необходимо поднять демона который учавствует в кворуме но не хранит данные (не помню как называется)
ну и под общие файлы (/var/lib/one/datastores/ используем cephfs, с несколькими mds, проблем не встречали, единственное что — монтируем через fuse, так как ядерный модуль залипает.
Называется демон galera arbitrator ( galeracluster.com/documentation-webpages/arbitrator.html ), но на момент когда думал прототипировать его на бою (с полгода назад) DBA'щики настаивали что оно очень далеко до production ready.
для автоматического запуска galera кластера в случае коллапса — необходимо поднять демона который учавствует в кворуме но не хранит данные (не помню как называется)
garbd — арбитратор, как выше говорит Phoen. Но это как раз не обязательно. Это замена третьему инстансу Galera. Т.е. вы можете использовать две полноценных галеры и арбитратор, можете — три полноценных галеры, в смысле кворума эти варианты совершенно эквивалентны.
Ну и для поднятия в случае останова всех нод это тоже необязательно. На сайте галеры есть инструкции, как это делается — они работают. А если у вас кластер останавливался не полностью и хотя бы одна нода выживала, максимум, что вам придётся потом делать после запуска остальных — той, выжившей, прямо сказать, что она — в актуальном состоянии. А может и не потребоваться. Опять же, в документации написано про это. Я пока экспериментировал, несколько раз проходил через «жива одна нода» — это даже граблями назвать нельзя, совсем не больно, что-то там делать руками пришлось только однажды.
А в чем проблема с SELinux? В официальной документации компонентов тоже рекомендуют отключать или все-таки есть модули для нормальной работы?
Гайды OpenNebula рекомендуют.
Гайды Ceph тоже.
Еще до недавнего времени Galera Cluster тоже рекомендовали это, правда сейчас появился довольно подробный гайд по настройке selinux для galera.
А в этой статье написанно как настроить selinux для openvswitch.
Гайды Ceph тоже.
Еще до недавнего времени Galera Cluster тоже рекомендовали это, правда сейчас появился довольно подробный гайд по настройке selinux для galera.
А в этой статье написанно как настроить selinux для openvswitch.
Что-то подбило меня создать пользователя по имени CU (ceph user), а не ceph. А сейчас с выходом 9 версии по имени Infernalis разработчики решили сделать работу не от root, а от ceph. Если уже есть пользователь ceph, то ситуация становится сложнее.
http://ceph.com/releases/v9-2-0-infernalis-released/#more-7593
http://ceph.com/releases/v9-2-0-infernalis-released/#more-7593
Если кто в 2019 и позже вышел на эту инструкцию — не пользуйтесь ей, она сильно устарела. И MySQL-кластер не нужен, и corosync иже с ним — всё теперь встроено в opennebula.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Строим свое собственное отказоустойчивое облако на базе OpenNebula с Ceph, MariaDB Galera Cluster и OpenvSwitch