Как настроить мультикластер Ceph?

Question

[Xyp]

Есть три сервера Centos 7 с 10 дисками на каждом и ceph luminous. В данный момент настроен кластер ceph. Стоит задача настроить мультикластер, мультикластер это как бы два кластера ceph на одном устройсве (железе). В папке /etc/ceph/ лежит два {cluster-name}.conf файла, которые отвечают за настройку кластеров. Это в теории, а кто на практике делал?

Answer 1

[Алексей Черемисин]

Ой, нет, такого не делал. Но теоретически я бы развернул или в виртуалках KVM или в контейнерах LXC. В виртуалках точно развернется. Делаете для каждого кластера по выделенному VLAN, и нужные виртуалки туда и подключаете. К виртуалкам подключаете диски/ Также можно попробовать и в LXC сделать.
А собственно, разве правами доступа нельзя разрулить один кластер? Делаете нужное количество пулов, и на каждый пул - свои права доступа клиентам.

Comments

[Xyp]

Проблем настроить в обычном режиме нет, но в том варианте что я написал появляется такая прикольная фича как rbd mirror. Вот хочу ее потестить.

[Алексей Черемисин]

Xyp, Э?! Ух! Не знал... Ну, если на попробовать, то виртуалками. А так, в рамках одного и того же железа держать два кластера? Для того чтобы дополнительно миррорить? Ведь есть же количество реплик на пул!

[Xyp]

Алексей Черемисин, в итоге настроил, но настраивается немного не так как представлял. OSD мониторы должны быть на разных устройствах, пробовал на одних и тех же, но нормально это работать не хочет, так как мониторы подымаются на порту 6789, можно изменить порт, но все равно там появляются другие проблемы и не работает. В итоге мы должны настроить так - два кластера ceph с разными именами. Потом берем по одному серверу из каждого кластера и на них настраиваем мультикластер, то есть в папке /etc/ceph/ должен находиться конфиг и ключи не только основного кластера но и дполнительного. На эти сервера ставиться демон rbd-mirror и настраивается зеркалирование пулов. Проблем было много, все и не перечесть, чего стоит только то что ceph-deploy 2.01 не хотел разворачивать кластер с нестандартным именем, пришлось откатиться на 1.5.38.

[Алексей Черемисин]

Xyp, Ох. подозреваю, что Вы что-то совсем не то творите. Как бы у вас кластер не развалился во время работы! Я уже один раз собирал данные по кусочкам скриптом на питоне, три дня собиралось, больше не хочу.
Не нужно на одном истансе заводить два разных ceph, очень нехорошо это!

[Xyp]

Алексей Черемисин, эот тестовая среда. Такая схема наоборот повышает надежнось/отказоустойчивость. Два кластера ceph с двумя идентичными копиями. Если один кластер падает, то второй тут же готов к работе. Первый если подымается, восстанавливает копию из первого. Профит!

[Алексей Черемисин]

Xyp, вот я совсем не совсем понимаю, как эта схема может повысить надежность.
1) ceph и так делает дублирование данных в зависимости от фактора репликации пула.
2) если два кластера сидят на одном и том же железе, пусть и разнесенном, то какая вообще здесь надежность?
3) мы в таком случае просто уменьшаем производительность и увеличиваем объем занятых ресурсов, не легче ли тогда просто увеличить фактор репликации?
4) даже в тестах, нужно создавать два НЕЗАВИСИМЫХ кластера, а не городить все на одних и тех же инстансах.
5) как я почитал, мирроринг RBD именно подразумевает использование второго, удаленного кластера и предназначен для прозрачного переезда виртуалок из одного географического района в другой.

Для тестов, что бы Вас не взять и не сделать два пула виртуалок, для одного и второго кластеров cehp? Разделить их независимыми сетями и нормально потестировать?

Ну и да, как раз пришли вчера три сервера, вот попробую тоже развернуть новый ceph, будем на него переезжать. Мне там важно, что сделали iSCSI более удобное и вебморду в комплекте (хотя мы и без нее уже 5 лет живем)

[Валентин]

Xyp, какой кейс вы видите, чтобы на одном и том же железе софтово кластер умер, и при этом умер так, чтобы и его не поднять было, но копия - была и поднялась? От смерти железа ведь CEPH сам по себе защищен (ну в тех пределах, в каких сам настроишь), а софтовые проблемы бывают нарочные (залил кривой конфиг, или допустим обновился, не протестировав заранее) и случайные (баг всплыл), от первых защищает тестовая среда, а от второго защиты нет.

[Алексей Черемисин]

Валентин, поддержу, причем, и на первом и на втором кластере ошибка может проявиться одновременно.

[Xyp]

Алексей Черемисин, Не о каком одном железе уже речи не идет, это можно сделать, но не нужно. Я же написал в третьем своем сообщении, что все обстоит иначе чем я изначально представлял, цитата из моего сообщения - "OSD мониторы должны быть на разных устройствах". Так же написал "Потом берем по одному серверу из каждого кластера и на них настраиваем мультикластер'. Под мультикластером я понимаю два конф файла в папке /etc/ceph. Это нужно для работы демона rbd-mirror. В итоге мы имеем два кластера ceph, и только на одном сервере из каждого кластере работает демон rbd-mirror.
И по поводу " переезда из одного географического района в другой", rbd-mirror может работать только в l2 сети. Цель мирроринга не переехать куда то, а дать отказоустойчивость.

[Алексей Черемисин]

Xyp, Ну, дело ваше. И да, мирроринг нормально работает не только в L2.

[Xyp]

Алексей Черемисин, А вы проверяли?

[Алексей Черемисин]

Xyp, нет, еще не успел, пока новый мимик на тестовых серверах разворачиваем. Но здесь Себасьтьян пишет, что достаточно роутинга, в комментариях после статьи https://www.sebastien-han.fr/blog/2016/03/28/ceph-...

[Валентин]

может работать только в l2 сети.

туннели не вчера изобрели, L2 можно поверх чего угодно сделать, так что это не преграда.

а дать отказоустойчивость.

Её дает CEPH сам по себе, своей архитектурой. Наворачивать что-то еще над ним - только добавит проблем в случае аварии, следовательно - вы потратите время на то, чтобы сделать себе будущему хуже.