Согласен, но теперь вся конфигурация лежит под гитом в yaml файлах. Да, я понимаю, что у вас скорее всего так же, только с использованием ansible(?). Я своим сообщением хотел донести, что конфигурировать можно и это не проблема.
Без разницы какой системой управления конфигурации я раскатываю ceph — в любом случае это гибче и надежнее, чем Rook.
Про VPA спорный вопрос. Если у вас выделенный кластер под ceph, то вы вероятно его не ограничиваете. Если кластер для ceph и приложений общий, то VPA и POD PRIORITY могут с играть решающую роль в работе всего кластера.
VPA и ограничение кластера по ресурсам в зависимости от политики или вынесет вам payload из кластера kubernetes или зарежет ceph, что приведет к его ООМ и опять таки выносу или тормозам вашего payload в кластере kuberentes. Но опять таки это вопрос сложности capacity planing.
Обязательно напишем статью, в ближайшее время, на тему возможностей конфигурирования rook.
Я с удовольствием почитаю, только пожалуйста не забудьте рассказать о сетевом взаимодействии и разделением по линкам.
Да, в первое время может быть больно, просто нужно отдавать отчет в своих действиях.
Пока я вижу только боль, повышенные риски и никих преимуществ перед классическим ceph.
Любые параметры в rook можно задать через configmap.
Ок, допустим мы можем править конфиг каждой OSD, но тогда мы всё равно лишаемся удобства Rook.
А если не использовать rook, ceph у вас на тех же железках, что и kubernetes? Если да, то скорее всего вы имеете те же проблемы. В плане подбора ресурсов в kubernetes, можно и нужно использовать VPA.
Если у вас выделенные железки под ceph, то перед их покупкой вы обычно считаете capacity кластера и подбираете железо под нагрузку.
VPA по сути костыль. Концепт «давайте больше ресурсов поду, пока он не начнет влезать» — по сути ничем не отличается от безлимитного пода.
Не совсем понятно, почему для кластера ceph и rook по умолчанию рассматриваете разную конфигурацию серверов. Это не проблема rook!
Допустим у вас одинаковая конфигурация серверов под ceph и под kubernetes + Rook
2х10гб. В случае ceph я просто в конфиге прописываю через какой линк ходит служебный трафик, а через какой клиентский.
А теперь расскажите мне пожалуйста как вы проделаете этот фокус с распределением линков в Rook?
PS: В целом, вы описываете проблемы, которые преследуют rook точно так же как и ceph.
Так же, есть ощущение, что рассматривается одна из старых версий rook.
У Rook есть и свои проблемы, как например сложности дебага ceph демонов при проблемах.
Пункты 1-3: Можно например почитать официальную документацию по установке кластера ceph. В котором все нормально расписано.
6)Что бы можно было ходить к подам снаружи можно взять другой сетевой плагин, например calico.
Отдельно стоит отметить, что kube-adm решение не для production.
p.s. Самую активную помощь по продуктам описанным в статье можно получить в каналах телеграм. t.me/kubernetes_ru t.me/ceph_ru
А может не надо?
Концепция хорошая, но учитывая своеобразность ceph мне страшно тащить rook даже в лабу.
Ну и как всегда порекомендую наше сообщество в телеграм t.me/ceph_ru нас уже больше 600. Заходите, будем рады!
Не разобравшись в проблеме, надо сказать, что все не так.
Ваш гайд подталкивает к неправильной архитектуре — значит это плохой гайд. Если у вас есть нюансы, которые привели вас к такой архитектуре, то необходимо их указать, что сделано не было. Например зачем active-active между ЦОД? Как настроена балансировка RGW? Round-robin?
Загрузка в сутки порядка 200 файлов по 5-10Мб.
У меня есть подозрение, что можно было обойтись и без CEPH.
Сказать, что Ваше решение имеет недостатки как минимум по нагрузке на сеть, что надо гуглить best prictice перед тем как внедрять решения, что корявые внедрения отбрасывают тень на технологию, которая и так не идеальна. А пиар телеграм канала возможно убережет от ошибок следующих за вами «первопроходцев».
Перевели гайд с сайта и выложили на хабр? Отличный уровень!
По существу:
А как же нам обеспечить отказоустойчивость по ЦОД'ам?
Как оказалось в Ceph есть очень сильный инструмент — работа с crushmap
Ужасно! Как уже было сказано выше сети при балансировке будет плохо.
Но и это не самое печально. Самое печальное, что вы даже не загуглили как делать RGW multi dc
Механизм уже встроен в RGW и называется federation. И не надо таскать низкоуровневые данные через узкий канал между датацентрами.
Для тех, у кого есть вопросы по ceph его настройке, проектированию кластеров и прочему — проходите в наш телеграм канал t.me/ceph_ru нас уже почти 500 человек.
Главный миф, который стоит развеить после умирания cloudmouse это стабильность CEPH и его готовность к production. И я буду крайне рад, если мне его будут помогать развеивать. Вы же своим желанием сделать кластер «с малым количеством репликаций» лишь увеличиваете шансы пойти путём cloudmouse. К сожалению у CEPH есть нижнее ограничение по объему и количеству серверов. Этого нигде не пишут, но это выходит логически. И в некоторых случаях уж лучше взять старый добрый drbd со всеми его проблемами.
10Gb, значение filestore max sync interval по умолчанию подходит в 99.9% случаях.
Только вот по умолчанию значение журнала 5Gb + в оф доке есть формула для расчёта размера журнала. Зачем тогда оно надо, если всем подходит?
Если понимать с вопроса «развернуть новый кластер?»
Не рассказывайте пожалуйста про rbd-mirror никому, т.к для прода он не готов и между разными версиями кластеров, в данный момент, в принципе не работает.
Если понимать с вопроса «развернуть новый пул?»
Риски от этого не изменяться, т.к. сервера с MON нужно обновлять до OSD. Отсюда следует, что изменение CRUSH-карты и распределение пула по определенным OSD нодам, ни чего полезного не даст.
А что, разве есть что-то лучше, чем синхронизировать пулы и переключить клиентов?
Нет, есть второй вариант выдать блочники клиентам из нового кластера и попросить их самих смигрировать в новый кластер, но если у вас публичное облако, то «ой».
МММ? ;)
Что вас смущает? Нет это не один такой сервер, если вы про общий конфиг.
C 30 дисками и 40Гбит/сек будет недостаточно, если использовать значения по умолчанию.
Совет про 10Гбит/сек был про то, что это надо минимум, а не вообще.
С использованием cfq scheduler на хостах с OSD.
Чем вызван выбор именно этого планировщика?
Уверен на 146%, что не переживете, если бы вы хорошо протестировали, вы бы это поняли.
переживете с помощью:
«osd_recovery_delay_start»: ">0",
«osd_max_backfills»: «1»,
«osd_recovery_threads»: «1»,
«osd_recovery_max_active»: «1»
Ок, на кластере у нас это есть но в посте нет. Косяк.
Из своего опыта могу смело сказать, что лучше анализировать через сокеты, более подробно: ceph --admin-daemon /var/run/ceph/ceph-osd.N.asok perf dump
Лучше, чем что? чем вывод ceph osd perf может быть, однако тем же ceph_exporter к prometheus это банально удобнее.
Говорит правду, просто нужно учитывать что на клиенте по умолчанию: rbd_cache = true
Здравствуйте.
Хотел объеденить в одном месте основные вопросы по приготовлению CEPH. Как показала практика не все готовы читать maillist, а вопросы возникающие в статье возникают довольно часто.
Если Вам есть что рассказать, то присоединяйтесь к нашей группе в телеграм по ссылке https://t.me/ceph_ru, будем рады.
Грустно, но такая плата за сохранность данных. Хотя допустим под бекапы можно использовать erasure-coding пулы, они дают больше места и нормально подходят для линейной записи.
Зависит от заполненности пула, количества ОСД и соотношения звезд. Если у вас кластер из 2х нод и 4х осд и size =2 забит на 80%, то да, при выпадении двух дисков вы скорее всего потеряете данные.
Фактор репликации 3, это при 90тб объема хранилища полезного у вас будет 30тб.
Всегда актуальный список каналов находится на гитхаб github.com/goq/telegram-list
Без разницы какой системой управления конфигурации я раскатываю ceph — в любом случае это гибче и надежнее, чем Rook.
VPA и ограничение кластера по ресурсам в зависимости от политики или вынесет вам payload из кластера kubernetes или зарежет ceph, что приведет к его ООМ и опять таки выносу или тормозам вашего payload в кластере kuberentes. Но опять таки это вопрос сложности capacity planing.
Я с удовольствием почитаю, только пожалуйста не забудьте рассказать о сетевом взаимодействии и разделением по линкам.
Пока я вижу только боль, повышенные риски и никих преимуществ перед классическим ceph.
Ок, допустим мы можем править конфиг каждой OSD, но тогда мы всё равно лишаемся удобства Rook.
Если у вас выделенные железки под ceph, то перед их покупкой вы обычно считаете capacity кластера и подбираете железо под нагрузку.
VPA по сути костыль. Концепт «давайте больше ресурсов поду, пока он не начнет влезать» — по сути ничем не отличается от безлимитного пода.
Допустим у вас одинаковая конфигурация серверов под ceph и под kubernetes + Rook
2х10гб. В случае ceph я просто в конфиге прописываю через какой линк ходит служебный трафик, а через какой клиентский.
А теперь расскажите мне пожалуйста как вы проделаете этот фокус с распределением линков в Rook?
У Rook есть и свои проблемы, как например сложности дебага ceph демонов при проблемах.
6)Что бы можно было ходить к подам снаружи можно взять другой сетевой плагин, например calico.
Отдельно стоит отметить, что kube-adm решение не для production.
p.s. Самую активную помощь по продуктам описанным в статье можно получить в каналах телеграм.
t.me/kubernetes_ru
t.me/ceph_ru
Концепция хорошая, но учитывая своеобразность ceph мне страшно тащить rook даже в лабу.
Ну и как всегда порекомендую наше сообщество в телеграм t.me/ceph_ru нас уже больше 600. Заходите, будем рады!
Ваш гайд подталкивает к неправильной архитектуре — значит это плохой гайд. Если у вас есть нюансы, которые привели вас к такой архитектуре, то необходимо их указать, что сделано не было. Например зачем active-active между ЦОД? Как настроена балансировка RGW? Round-robin?
У меня есть подозрение, что можно было обойтись и без CEPH.
По существу:
Ужасно! Как уже было сказано выше сети при балансировке будет плохо.
Но и это не самое печально. Самое печальное, что вы даже не загуглили как делать RGW multi dc
Механизм уже встроен в RGW и называется federation. И не надо таскать низкоуровневые данные через узкий канал между датацентрами.
Для тех, у кого есть вопросы по ceph его настройке, проектированию кластеров и прочему — проходите в наш телеграм канал t.me/ceph_ru нас уже почти 500 человек.
Только вот по умолчанию значение журнала 5Gb + в оф доке есть формула для расчёта размера журнала. Зачем тогда оно надо, если всем подходит?
А что, разве есть что-то лучше, чем синхронизировать пулы и переключить клиентов?
Нет, есть второй вариант выдать блочники клиентам из нового кластера и попросить их самих смигрировать в новый кластер, но если у вас публичное облако, то «ой».
Что вас смущает? Нет это не один такой сервер, если вы про общий конфиг.
Совет про 10Гбит/сек был про то, что это надо минимум, а не вообще.
Чем вызван выбор именно этого планировщика?
Ок, на кластере у нас это есть но в посте нет. Косяк.
Лучше, чем что? чем вывод ceph osd perf может быть, однако тем же ceph_exporter к prometheus это банально удобнее.
Интересное заявление, хотелось бы пруфов.
Хотел объеденить в одном месте основные вопросы по приготовлению CEPH. Как показала практика не все готовы читать maillist, а вопросы возникающие в статье возникают довольно часто.
Если Вам есть что рассказать, то присоединяйтесь к нашей группе в телеграм по ссылке https://t.me/ceph_ru, будем рады.
Фактор репликации 3, это при 90тб объема хранилища полезного у вас будет 30тб.