Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 22
А как построена кластерная сеть между ЦОД?
А сеть мне отдавали сетевики :)
Т.к. я не большой спец в ip-сетях, попробую объяснить.
Я так понимаю, что vlan растянут по ЦОДам, поэтому у меня вообще не было проблем. Для меня это просто одноранговая сеть.
Но в принципе — это не имеет значения. Главное чтобы были маршруты и описание в hosts. Dhcp тоже не плохо.
Т.к. я не большой спец в ip-сетях, попробую объяснить.
Я так понимаю, что vlan растянут по ЦОДам, поэтому у меня вообще не было проблем. Для меня это просто одноранговая сеть.
Но в принципе — это не имеет значения. Главное чтобы были маршруты и описание в hosts. Dhcp тоже не плохо.
То есть вы хотите сказать, что и OSD и MON все в одну сеть?
Тогда при отключении одного из ЦОД могут возникнуть трудности.
Канал будет забит, мониторы не смогу общаться, PG будут «стакаться» и будет не очень весело.
Тогда при отключении одного из ЦОД могут возникнуть трудности.
Канал будет забит, мониторы не смогу общаться, PG будут «стакаться» и будет не очень весело.
Может я на эти грабли не вставал еще?
Или у меня данных на нем просто мало лежит.
Я гасил половину кластера и через 4 часа поднимал. Сеть на 15% только прогрузилась. Ну это из мониторинга нод кластера. Повторю эксперименты и подключу к ним сетевиков. Поизучаю поведение всесторонне :)
Или у меня данных на нем просто мало лежит.
Я гасил половину кластера и через 4 часа поднимал. Сеть на 15% только прогрузилась. Ну это из мониторинга нод кластера. Повторю эксперименты и подключу к ним сетевиков. Поизучаю поведение всесторонне :)
Лучше разделить. Правила хорошего тона.
Recovery и blackfilling будут обрабатываться по кластерной сети без опасений потерять MON.
Ну и в целом сами OSD будут между собой по ней работать.
На практике могу сказать, что при нормальной работе где-то 150-200 Mbps.
При ночных бэкапах на виртуалках + (deep) scrubbing где-то до 500-700 Mbps прыгает. RBD, 17 Tb, all flash.
Recovery и blackfilling будут обрабатываться по кластерной сети без опасений потерять MON.
Ну и в целом сами OSD будут между собой по ней работать.
На практике могу сказать, что при нормальной работе где-то 150-200 Mbps.
При ночных бэкапах на виртуалках + (deep) scrubbing где-то до 500-700 Mbps прыгает. RBD, 17 Tb, all flash.
Как поведет себя Ceph, когда один ЦОД будет изолирован от других?
Я на практике это не делал, кстати, спасибо за совет, в ближайшие недели попробую.
Документация же говорила о том, что для этого нам и нужно кворумное большинство. При сплите кворумное меньшинство должно прибивать службы на тех osd нодах, до которых может дотянуться.
Большинство, понятно, выживает. Какие-то объекты нужно будет перезаписать. Но это уже вопрос приклада.
Документация же говорила о том, что для этого нам и нужно кворумное большинство. При сплите кворумное меньшинство должно прибивать службы на тех osd нодах, до которых может дотянуться.
Большинство, понятно, выживает. Какие-то объекты нужно будет перезаписать. Но это уже вопрос приклада.
Ходили слухи, что перебалансировка при длительном выводе из строя некоторого количества OSD убивает сеть напрочь (собственно это одна из причин почему они рекомендуют делить control и data сети). Не знаете, починили?
Перевели гайд с сайта и выложили на хабр? Отличный уровень!
По существу:
Ужасно! Как уже было сказано выше сети при балансировке будет плохо.
Но и это не самое печально. Самое печальное, что вы даже не загуглили как делать RGW multi dc
Механизм уже встроен в RGW и называется federation. И не надо таскать низкоуровневые данные через узкий канал между датацентрами.
Для тех, у кого есть вопросы по ceph его настройке, проектированию кластеров и прочему — проходите в наш телеграм канал t.me/ceph_ru нас уже почти 500 человек.
По существу:
А как же нам обеспечить отказоустойчивость по ЦОД'ам?
Как оказалось в Ceph есть очень сильный инструмент — работа с crushmap
Ужасно! Как уже было сказано выше сети при балансировке будет плохо.
Но и это не самое печально. Самое печальное, что вы даже не загуглили как делать RGW multi dc
Механизм уже встроен в RGW и называется federation. И не надо таскать низкоуровневые данные через узкий канал между датацентрами.
Для тех, у кого есть вопросы по ceph его настройке, проектированию кластеров и прочему — проходите в наш телеграм канал t.me/ceph_ru нас уже почти 500 человек.
Сказать то что хотели?
Или так, попиариться
Или так, попиариться
Сказать, что Ваше решение имеет недостатки как минимум по нагрузке на сеть, что надо гуглить best prictice перед тем как внедрять решения, что корявые внедрения отбрасывают тень на технологию, которая и так не идеальна. А пиар телеграм канала возможно убережет от ошибок следующих за вами «первопроходцев».
Простите, конечно, но Ваши рассуждения так «по-нашему» бескомпромиссные. Не разобравшись в проблеме, надо сказать, что все не так.
Мне это анекдот напомнило:
49% несчастных случаев начинаются со слов «смотри, как умею»
51% — со слов «смотри как надо»
Я неплохо умею читать документацию, тем более «гуглить». И я ни в коем случае не собираюсь «отбрасывать тень» на технологию и тем более считать себя «первопроходцем». Многие полезные советы я учту и опробую. Тем более, что это, пока, далеко не продакшн.
Проблема в том, что у меня нет DR ЦОДа, они active-active. И как именно мне поможет federation при работе кластера в active-active? Я ответа не нашел, подскажите?
Что касается репликации 2 — я много читал, что не делайте так, но есть нюанс. Данные критичны с точки зрения законов РФ по хранению, при этом SLA исчисляется сутками. Мне говорят (и при том обоснованно) на тебе ленты, поднимемся из бэкапа. Кстати еще одна проблема в отсутствии federation.
При этом сейчас софт работает с блочными distributed томами — вот это дорого.
Загрузка в сутки порядка 200 файлов по 5-10Мб. Не ахти как.
Касаемо сети, мне никто не даст ее «положить». Есть, по крайней мере, rate limit для моего vlan. «Моргнуть» может по разному, и вот если будет ложиться FC, из-за initial copy, вот тут прям не знаю даже что лучше будет.
Вообще в любой книжке по архитектуре написано так: «вот так вот нужно, но вы, это, смотрите по обстоятельствам. Как бы чего не сломать.» :)
Мне это анекдот напомнило:
49% несчастных случаев начинаются со слов «смотри, как умею»
51% — со слов «смотри как надо»
Я неплохо умею читать документацию, тем более «гуглить». И я ни в коем случае не собираюсь «отбрасывать тень» на технологию и тем более считать себя «первопроходцем». Многие полезные советы я учту и опробую. Тем более, что это, пока, далеко не продакшн.
Проблема в том, что у меня нет DR ЦОДа, они active-active. И как именно мне поможет federation при работе кластера в active-active? Я ответа не нашел, подскажите?
Что касается репликации 2 — я много читал, что не делайте так, но есть нюанс. Данные критичны с точки зрения законов РФ по хранению, при этом SLA исчисляется сутками. Мне говорят (и при том обоснованно) на тебе ленты, поднимемся из бэкапа. Кстати еще одна проблема в отсутствии federation.
При этом сейчас софт работает с блочными distributed томами — вот это дорого.
Загрузка в сутки порядка 200 файлов по 5-10Мб. Не ахти как.
Касаемо сети, мне никто не даст ее «положить». Есть, по крайней мере, rate limit для моего vlan. «Моргнуть» может по разному, и вот если будет ложиться FC, из-за initial copy, вот тут прям не знаю даже что лучше будет.
Вообще в любой книжке по архитектуре написано так: «вот так вот нужно, но вы, это, смотрите по обстоятельствам. Как бы чего не сломать.» :)
Не разобравшись в проблеме, надо сказать, что все не так.
Ваш гайд подталкивает к неправильной архитектуре — значит это плохой гайд. Если у вас есть нюансы, которые привели вас к такой архитектуре, то необходимо их указать, что сделано не было. Например зачем active-active между ЦОД? Как настроена балансировка RGW? Round-robin?
Загрузка в сутки порядка 200 файлов по 5-10Мб.
У меня есть подозрение, что можно было обойтись и без CEPH.
Да, об указании на нюансы, впредь буду больше внимания обращать.
Что касается active-active между ЦОД. Это не я решал. Более того, это было уже до меня. Так построено приложение, что работают ноды кластера в режиме active-active. В общем — это еще один де-факто.
Нет, как я понял, round-robin используется для поочередного доступа к ceph через развернутые RadosGW.
В моем случае работа узла кластера должна быть локализована в рамках ЦОД но с общим хранилищем. В каждом ЦОД свой RGW. Потом должен появиться резерв по доступу, соответственно по 2 RGW ноды на ЦОД с попарной балансировкой round-robin.
Касаемо количества файлов. Читаются они чаще, чем пишутся. Соответственно и SLA не нужно путать с QoS системы. Конечно же это не значит, что при нормальной работе все готовы ждать сутками. Тогда можно носить все дискетками и вообще не заморачиваться.
Конечно можно обойтись без ceph. Можно много без чего обходиться. Можно было поднять nfs-шару, можно две и их синкать, можно и не nfs. В общем костыли на любой вкус. :)
Что касается active-active между ЦОД. Это не я решал. Более того, это было уже до меня. Так построено приложение, что работают ноды кластера в режиме active-active. В общем — это еще один де-факто.
Нет, как я понял, round-robin используется для поочередного доступа к ceph через развернутые RadosGW.
В моем случае работа узла кластера должна быть локализована в рамках ЦОД но с общим хранилищем. В каждом ЦОД свой RGW. Потом должен появиться резерв по доступу, соответственно по 2 RGW ноды на ЦОД с попарной балансировкой round-robin.
Касаемо количества файлов. Читаются они чаще, чем пишутся. Соответственно и SLA не нужно путать с QoS системы. Конечно же это не значит, что при нормальной работе все готовы ждать сутками. Тогда можно носить все дискетками и вообще не заморачиваться.
Конечно можно обойтись без ceph. Можно много без чего обходиться. Можно было поднять nfs-шару, можно две и их синкать, можно и не nfs. В общем костыли на любой вкус. :)
Зря вы взяли связку centos + jewel.
В centos достаточно старое ядро, и когда вы заходите создать rbd то кроме feature layering использовать не сможете, rbd не замаппится, а в логах увидете что то вроде unsupported feature 0x09. Потом когда вы заходите выкинуть rbd по iSCSI то вы можете получить подвисший модуль lio в ядре и полудохлую ноду. А если захотите ещё и связать это с вин кластером, да еще чтобы и таргеты дублировались, с mpio, то вам ещё понадобятся и блокировки через rbd, а это ещё и ядро суси с патчами и прикладом тянуть. То ещё веселье.
Плюс с цефом в общем то рекомендуется (http://docs.ceph.com/docs/master/start/os-recommendations/) использовать более свежее ядро если вы используете rbd или cephfs (да, конкретно сейчас это не ваш случай, но тем не менее), там цефовские модули посвежее, и со iscsi проблем меньше, и в сетевом стеке изменения, и т.д.
По поводу luminous — у вас не было бы проблем с udev, selinux, не нужно было бы прописывать guid'ы и chown'ить блочные устройства. Деплой легче, автоматическая разбивка на device classes, создать раздельные пулы на разных типах устройств в разы проще. Допилили bluestore, скорость выше. Облегчили процесс замены дисков (ceph osd destroy/purge). Сделали overwrites для erasure coded пулов через реплицируемые пулы. Ввели прозрачную компрессию. Ввели простенький, но всё же мониторинг, встроили плагины для zabbix, prometheus, etc. Cephfs наконец то поддерживает одновременную работу нескольких сервисом метадаты. По сравнению с jewel более быстрый детект неработоспособности osd (введено в релизе kraken). То есть если вы намеренно погасили ноду, то osd сразу входят в состояние down, и ваше IO не прерывается, а в случае если вы его выключили по кнопке, или упала сеть, у вас IO полностью прерывается на срок от 20 секунд и до n минут, что уже вполне хватает чтобы ваши виртуалки упали, а клиенты получили подвисший fd (в случае с rbd). В релизах kraken (11) и выше с этим дела обстоят намного лучше. Ну и других приятных и полезных изменений там хватает. Так же стоит добавить что luminous это тоже lts, что обновление с jewel (и kraken) будет не таким простым (из-за blue store в частности), и что по части багов jewel вряд ли будет сильно лучше luminous.
Ещё вам к раздумьям: цеф отвратительно балансит данные. Существует далеко не нулевая вероятность, что один диск в пуле у вас заполнен на 70% а другой на 95% и цеф вешает флаг full на кластер из-за этого, и у вас всё встаёт колом. Собственно по этому в церне написали свои хелперы на питоне, в частности для ребаланса по крону. Правда для 12 версии пришлось переписывать немного, для поддержки device class. Собственно ссылки по теме:
indico.cern.ch/event/567516/contributions/2293565/attachments/1331568/2001323/050916-cephupdate.pdf
github.com/cernceph/ceph-scripts
И по статье промелькнуло ssd, но нет конкретики какие вы диски используете и в каком кейсе. С cache tiering'ом тоже ведь есть свои нюансы. Не описано какую сеть вы используете (1g/10g/что-то серьезнее?), а ведь сеть для цефа критична, проблемы с ней выльются в подвисших с stuck_unclean pg, в подвисших запросах (blocked requests) и тд. Как ceph себя показывает в вашем случае двух цодов?
В centos достаточно старое ядро, и когда вы заходите создать rbd то кроме feature layering использовать не сможете, rbd не замаппится, а в логах увидете что то вроде unsupported feature 0x09. Потом когда вы заходите выкинуть rbd по iSCSI то вы можете получить подвисший модуль lio в ядре и полудохлую ноду. А если захотите ещё и связать это с вин кластером, да еще чтобы и таргеты дублировались, с mpio, то вам ещё понадобятся и блокировки через rbd, а это ещё и ядро суси с патчами и прикладом тянуть. То ещё веселье.
Плюс с цефом в общем то рекомендуется (http://docs.ceph.com/docs/master/start/os-recommendations/) использовать более свежее ядро если вы используете rbd или cephfs (да, конкретно сейчас это не ваш случай, но тем не менее), там цефовские модули посвежее, и со iscsi проблем меньше, и в сетевом стеке изменения, и т.д.
По поводу luminous — у вас не было бы проблем с udev, selinux, не нужно было бы прописывать guid'ы и chown'ить блочные устройства. Деплой легче, автоматическая разбивка на device classes, создать раздельные пулы на разных типах устройств в разы проще. Допилили bluestore, скорость выше. Облегчили процесс замены дисков (ceph osd destroy/purge). Сделали overwrites для erasure coded пулов через реплицируемые пулы. Ввели прозрачную компрессию. Ввели простенький, но всё же мониторинг, встроили плагины для zabbix, prometheus, etc. Cephfs наконец то поддерживает одновременную работу нескольких сервисом метадаты. По сравнению с jewel более быстрый детект неработоспособности osd (введено в релизе kraken). То есть если вы намеренно погасили ноду, то osd сразу входят в состояние down, и ваше IO не прерывается, а в случае если вы его выключили по кнопке, или упала сеть, у вас IO полностью прерывается на срок от 20 секунд и до n минут, что уже вполне хватает чтобы ваши виртуалки упали, а клиенты получили подвисший fd (в случае с rbd). В релизах kraken (11) и выше с этим дела обстоят намного лучше. Ну и других приятных и полезных изменений там хватает. Так же стоит добавить что luminous это тоже lts, что обновление с jewel (и kraken) будет не таким простым (из-за blue store в частности), и что по части багов jewel вряд ли будет сильно лучше luminous.
Ещё вам к раздумьям: цеф отвратительно балансит данные. Существует далеко не нулевая вероятность, что один диск в пуле у вас заполнен на 70% а другой на 95% и цеф вешает флаг full на кластер из-за этого, и у вас всё встаёт колом. Собственно по этому в церне написали свои хелперы на питоне, в частности для ребаланса по крону. Правда для 12 версии пришлось переписывать немного, для поддержки device class. Собственно ссылки по теме:
indico.cern.ch/event/567516/contributions/2293565/attachments/1331568/2001323/050916-cephupdate.pdf
github.com/cernceph/ceph-scripts
И по статье промелькнуло ssd, но нет конкретики какие вы диски используете и в каком кейсе. С cache tiering'ом тоже ведь есть свои нюансы. Не описано какую сеть вы используете (1g/10g/что-то серьезнее?), а ведь сеть для цефа критична, проблемы с ней выльются в подвисших с stuck_unclean pg, в подвисших запросах (blocked requests) и тд. Как ceph себя показывает в вашем случае двух цодов?
Плюнуть на blue store который привносит нормальное журналирование+хеширование блоков(при том что порча блока на primary OSD равносильна порче всех реплик) не говоря об удалении лишнего оверхеда на OSD потому-что «мы серьезная компания» — это сильно.
PS: цеф не умеет не iscsi не fc, это умеет LiO, который в ближайшем будущем так-же избавится от лишнего оверхеда смены контекста, а так-же научится нормальному MPIO с VAAI для ceph с.м. tcmu-runner 1.3 находящийся в стадии RC
PS: цеф не умеет не iscsi не fc, это умеет LiO, который в ближайшем будущем так-же избавится от лишнего оверхеда смены контекста, а так-же научится нормальному MPIO с VAAI для ceph с.м. tcmu-runner 1.3 находящийся в стадии RC
потому-что «мы серьезная компания», так, минутка юмора. Не более.
Lio пока не умеет делать fc-target из RBD. Это плохо.
Lio пока не умеет делать fc-target из RBD. Это плохо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Выбор и настройка SDS Ceph