В связи с набирающей популярностью Rook хочется поговорить о его подводных камнях и проблемах, которые ждут вас на пути.
О себе: Опыт администрирования ceph с версии hammer, основатель комьюнити t.me/ceph_ru в телеграм.
Дабы не быть голословным я буду ссылаться на принятые хабром (судя по рейтингу) посты о проблемах с ceph. С бОльшей частью проблем в этих постах я тоже столкнулся. Ссылки на использованный материал в конце поста.
В посте про Rook мы упоминаем ceph не просто так — Rook по сути ceph завернутый в kubernetes, а значит наследует все его проблемы. С проблем ceph и начнем.
Одним из преимуществ Rook является удобство управление ceph через kuberentes.
Однако ceph содержит более 1000 параметров для настройки, в тоже время через rook мы можем править лишь меньшую часть из них.
С установкой ceph без Rook нет никаких проблем — ansible playbook пишется за 30 минут, а вот с обновлением проблем масса.
Цитата из поста Крок
Пример: Обновление 12.2.6 приводящее кластер в состояние health err и условно битым PG
ceph.com/releases/v12-2-8-released
Не обновляться, ждать и тестировать? Но мы вроде используем Rook ради удобства обновлений в том числе.
Пример: OSD падает сыпя ошибками себе под ноги. Вы подозреваете, что проблема в одном из параметров в конфиге, хотите поменять конфиг для конкретного демона, но не можете, потому что у вас kubernetes и DaemonSet.
Альтернативы нет. ceph tell osd.Num injectargs не работает — OSD же лежит.
Для некоторых настроек и тестов производительности необходимо подключаться непосредственно к сокету osd демона. В случае Rook необходимо для начала найти нужный контейнер, после этого зайти в него, обнаружить отсутствующий для debug тулинг и очень расстроиться.
Пример: OSD падает по ООМ, начинается ребаланс, после этого падают следующие.
Решение: Поднимать OSD по одной, дожидаться её полного включения в кластер и поднимать следующие. (Подробнее в докладе Ceph. Анатомия катастрофы).
В случае baremetal установки это делается просто руками, в случае Rook и одной OSD на ноду проблем особо нет, проблемы с поочередным поднятием возникнут если OSD > 1 на ноду.
Конечно, они решаемы, но мы же несем Rook для упрощения, а получаем усложнение.
Для baremetal инсталяции ceph достаточно легко подсчитать необходимые ресурсы на кластер — формулы есть и исследования есть. При использовании слабых CPU вам всё равно придется провести ряд тестов производительности, узнать что такое Numa, но это всё равно более просто, чем в Rook.
В случае Rook вам помимо лимитов памяти, которые можно посчитать возникает вопрос задания лимита CPU.
И тут вам придется попотеть с тестами производительности. В случае занижения лимитов вы получите медленный кластер, в случае выставления unlim вы получите активное использование CPU при ребалансе, что будет плохо влиять на ваши приложения в kubernetes.
Для ceph рекомендуется использовать 2х10гб сеть. Одну для клиентского трафика, другую для служебных нужд ceph (ребаланс). Если вы живёте с ceph на baremetal, то это разделение легко настраивается, если вы живете с Rook, то с разделением по сетям вызовет у вас проблемы, в связи с тем, что далеко не каждый конфиг кластера позволяет подать в pod две разных сети.
Если вы откажетесь разделять сети, то при ребалансе трафик ceph забьет весь канал и ваши приложения в kubernetes будут тормозить или упадут. Можно уменьшить скорость ребаланса ceph, но тогда за счёт долгого ребаланса вы получаете повышенный риск выпадения второй ноды из кластера по дискам или ООМ, а там уже гарантированный read only на кластер.
Цитата из поста Ceph. Анатомия катастрофы.
ceph бывает нужен специфический тюнинг хоста.
Пример: настройки sysctl и тот же JumboFrame, некоторые из этих настроек могут негативно влиять на ваш payload.
Если вы в облаке у вас есть хранилище от вашего облачного провайдера, что намного удобнее.
Если вы на своих серверах, то управление ceph будет удобнее без kubernetes.
Вы арендуете сервера в каком-нибудь low cost хостинге? Тогда вас ждёт много веселого с сетью, её задержками и пропускной способностью, что явно негативно влияет на ceph.
Итого: Внедрение kuberentes и внедрение хранилища — разные задачи с разными вводными и разными вариантами решений — смешивать их, значит делать возможно опасный trade-off в угоду тому или иному. Cовместить эти решения будет очень сложно даже на этапе проектирования, а есть еще период эксплуатации.
Список использованной литературы:
Пост #1 А вот вы говорите Ceph… а так ли он хорош?
Пост #2 Ceph. Анатомия катастрофы
О себе: Опыт администрирования ceph с версии hammer, основатель комьюнити t.me/ceph_ru в телеграм.
Дабы не быть голословным я буду ссылаться на принятые хабром (судя по рейтингу) посты о проблемах с ceph. С бОльшей частью проблем в этих постах я тоже столкнулся. Ссылки на использованный материал в конце поста.
В посте про Rook мы упоминаем ceph не просто так — Rook по сути ceph завернутый в kubernetes, а значит наследует все его проблемы. С проблем ceph и начнем.
Упрощение управления кластером
Одним из преимуществ Rook является удобство управление ceph через kuberentes.
Однако ceph содержит более 1000 параметров для настройки, в тоже время через rook мы можем править лишь меньшую часть из них.
Пример на LuminousRook позиционируется как удобный способ устанавливать и обновлять ceph
> ceph daemon mon.a config show | wc -l
1401
С установкой ceph без Rook нет никаких проблем — ansible playbook пишется за 30 минут, а вот с обновлением проблем масса.
Цитата из поста Крок
Пример: некорректная работа crush tunables после обновления с hummer на jewelНо даже в рамках минорных версий бывают проблемы.
> ceph osd crush show-tunables
{
…
«straw_calc_version»: 1,
«allowed_bucket_algs»: 22,
«profile»: «unknown»,
«optimal_tunables»: 0,
…
}
Пример: Обновление 12.2.6 приводящее кластер в состояние health err и условно битым PG
ceph.com/releases/v12-2-8-released
Не обновляться, ждать и тестировать? Но мы вроде используем Rook ради удобства обновлений в том числе.
Сложность disaster recovery кластера в Rook
Пример: OSD падает сыпя ошибками себе под ноги. Вы подозреваете, что проблема в одном из параметров в конфиге, хотите поменять конфиг для конкретного демона, но не можете, потому что у вас kubernetes и DaemonSet.
Альтернативы нет. ceph tell osd.Num injectargs не работает — OSD же лежит.
Сложность debug
Для некоторых настроек и тестов производительности необходимо подключаться непосредственно к сокету osd демона. В случае Rook необходимо для начала найти нужный контейнер, после этого зайти в него, обнаружить отсутствующий для debug тулинг и очень расстроиться.
Сложность последовательного поднятия OSD
Пример: OSD падает по ООМ, начинается ребаланс, после этого падают следующие.
Решение: Поднимать OSD по одной, дожидаться её полного включения в кластер и поднимать следующие. (Подробнее в докладе Ceph. Анатомия катастрофы).
В случае baremetal установки это делается просто руками, в случае Rook и одной OSD на ноду проблем особо нет, проблемы с поочередным поднятием возникнут если OSD > 1 на ноду.
Конечно, они решаемы, но мы же несем Rook для упрощения, а получаем усложнение.
Сложность подбора лимитов для ceph демонов
Для baremetal инсталяции ceph достаточно легко подсчитать необходимые ресурсы на кластер — формулы есть и исследования есть. При использовании слабых CPU вам всё равно придется провести ряд тестов производительности, узнать что такое Numa, но это всё равно более просто, чем в Rook.
В случае Rook вам помимо лимитов памяти, которые можно посчитать возникает вопрос задания лимита CPU.
И тут вам придется попотеть с тестами производительности. В случае занижения лимитов вы получите медленный кластер, в случае выставления unlim вы получите активное использование CPU при ребалансе, что будет плохо влиять на ваши приложения в kubernetes.
Проблемы с сетевым взаимодействием v1
Для ceph рекомендуется использовать 2х10гб сеть. Одну для клиентского трафика, другую для служебных нужд ceph (ребаланс). Если вы живёте с ceph на baremetal, то это разделение легко настраивается, если вы живете с Rook, то с разделением по сетям вызовет у вас проблемы, в связи с тем, что далеко не каждый конфиг кластера позволяет подать в pod две разных сети.
Проблемы с сетевым взаимодействием v2
Если вы откажетесь разделять сети, то при ребалансе трафик ceph забьет весь канал и ваши приложения в kubernetes будут тормозить или упадут. Можно уменьшить скорость ребаланса ceph, но тогда за счёт долгого ребаланса вы получаете повышенный риск выпадения второй ноды из кластера по дискам или ООМ, а там уже гарантированный read only на кластер.
Долгий ребаланс — долгие тормоза приложений
Цитата из поста Ceph. Анатомия катастрофы.
Производительность тестового кластера:Получается, что скорость ребаланса критически важна для корректной работы кластера.
Операция записи размером 4 Кбайта занимает 1 мс, производительность 1000 операций/секунду в 1 поток.
Операция размером 4 Мбайта (размером объекта) занимает 22 мс, производительность 45 операций/секунду.
Следовательно, когда отказывает один домен из трех, кластер некоторое время находится в деградировавшем состоянии, и половина горячих объектов распространится по разным версиям, то половина операций записей будет начинаться с принудительного восстановления.
Время принудительного восстановления рассчитываем примерно — операции записи в деградировавший объект.
Сначала мы читаем 4 Мбайта за 22 мс, пишем 22 мс, и затем 1 мс мы пишем 4 Кб собственно данных. Итого суммарно 45 мс на одну операцию записи в деградировавший объект на SSD, когда штатная производительность у нас была 1 мс — падение производительности в 45 раз.
Чем больше у нас процент деградировавших объектов, тем все становится страшнее.
Специфичные настройки серверов для ceph
ceph бывает нужен специфический тюнинг хоста.
Пример: настройки sysctl и тот же JumboFrame, некоторые из этих настроек могут негативно влиять на ваш payload.
Реальная необходимость Rook остается под вопросом
Если вы в облаке у вас есть хранилище от вашего облачного провайдера, что намного удобнее.
Если вы на своих серверах, то управление ceph будет удобнее без kubernetes.
Вы арендуете сервера в каком-нибудь low cost хостинге? Тогда вас ждёт много веселого с сетью, её задержками и пропускной способностью, что явно негативно влияет на ceph.
Итого: Внедрение kuberentes и внедрение хранилища — разные задачи с разными вводными и разными вариантами решений — смешивать их, значит делать возможно опасный trade-off в угоду тому или иному. Cовместить эти решения будет очень сложно даже на этапе проектирования, а есть еще период эксплуатации.
Список использованной литературы:
Пост #1 А вот вы говорите Ceph… а так ли он хорош?
Пост #2 Ceph. Анатомия катастрофы
Комментарии (17)
ultral
16.05.2019 19:00Ведал ceph 0.87 — 12.2 версий. в сумме порядка 10PB со всех кластеров. Подписываюсь под всеми словами что ceph это сложная штука и без понимания как оно там внутри будет сложно, без адекватных инженеров для его поддержания тяжело будет.
Идея выглядит интересно, но какие-то практические кейсы для применения внутри k8s/openshift придумать сложно окромя:
— CI/CD для ceph
— k8s/openshift без персистентного стораджа
artzcom
16.05.2019 19:45Пример: OSD падает сыпя ошибками себе под ноги. Вы подозреваете, что проблема в одном из параметров в конфиге, хотите поменять конфиг для конкретного демона, но не можете, потому что у вас kubernetes и DaemonSet.
Сложность последовательного поднятия OSD
Так давно переделали на statefulset. Для каждой OSD есть свой configmap и никто не мешает поправить какие то параметры конкретно для той самой OSD. Скейл в ноль любую osd и восстанавливай в ручном режиме.
Однако ceph содержит более 1000 параметров для настройки, в тоже время через rook мы можем править лишь меньшую часть из них.
Любые параметры в rook можно задать через configmap.
И тут вам придется попотеть с тестами производительности. В случае занижения лимитов вы получите медленный кластер, в случае выставления unlim вы получите активное использование CPU при ребалансе, что будет плохо влиять на ваши приложения в kubernetes.
А если не использовать rook, ceph у вас на тех же железках, что и kubernetes? Если да, то скорее всего вы имеете те же проблемы. В плане подбора ресурсов в kubernetes, можно и нужно использовать VPA.
Проблемы с сетевым взаимодействием v1
Не совсем понятно, почему для кластера ceph и rook по умолчанию рассматриваете разную конфигурацию серверов. Это не проблема rook!
PS: В целом, вы описываете проблемы, которые преследуют rook точно так же как и ceph.
Так же, есть ощущение, что рассматривается одна из старых версий rook.
PPS: С одной стороны, rook упрощает работу с ceph, с другой стороны усложняет. Да, ceph сам по себе не прост в эксплуатации, но если мы (все мы, сообщество) не будем пользоваться подобными инструментами, они не будут развиваться. Возможно, сейчас для многих, rook будет сильно избыточен. Но вы попробуйте поддерживать 3-4 десятка небольших ceph кластеров… (тут я умышленно не заканчиваю предложение)ultral
16.05.2019 20:01ceph & k8s две сложные системы. когда мы их скрещиваем сложность возрастает катастрофически
* пусть у ceph X параметров, каждый параметр принимает N значений, т.е. кол-во конфигураций X^N
* пусть у k8s Y параметров, у каждого M значения, т.е. кол-во конфигураций Y^M
если это две параллельные системы, то X^N * Y^M
если это одно встроено в другую, то (Y*X^N)^M. т.е. сложность конфигурирования системы будет расти по экспоненете(если точнее то X^M)
SinTeZoiD Автор
17.05.2019 12:12Любые параметры в 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 демонов при проблемах.artzcom
17.05.2019 16:42-1Ок, допустим мы можем править конфиг каждой OSD, но тогда мы всё равно лишаемся удобства Rook.
Согласен, но теперь вся конфигурация лежит под гитом в yaml файлах. Да, я понимаю, что у вас скорее всего так же, только с использованием ansible(?). Я своим сообщением хотел донести, что конфигурировать можно и это не проблема.
VPA по сути костыль. Концепт «давайте больше ресурсов поду, пока он не начнет влезать» — по сути ничем не отличается от безлимитного пода.
Про VPA спорный вопрос. Если у вас выделенный кластер под ceph, то вы вероятно его не ограничиваете. Если кластер для ceph и приложений общий, то VPA и POD PRIORITY могут с играть решающую роль в работе всего кластера.
Допустим у вас одинаковая конфигурация серверов под ceph и под kubernetes + Rook
Обязательно напишем статью, в ближайшее время, на тему возможностей конфигурирования rook.
У Rook есть и свои проблемы, как например сложности дебага ceph демонов при проблемах.
Да, я немного слукавил, когда сказал, что разницы нет. Конечно же она есть и она не маленькая. В случае с rook, нужно понимать как работает OS и CEPH так в нагрузку еще и Kubernetes + ROOK. Я ни в коем случае не пропогандирую отказ от класического ceph'а и переход на rook. Я говорю, что в ряде случаев, есть смысл его использовать. Да, в первое время может быть больно, просто нужно отдавать отчет в своих действиях.SinTeZoiD Автор
17.05.2019 18:02Согласен, но теперь вся конфигурация лежит под гитом в yaml файлах. Да, я понимаю, что у вас скорее всего так же, только с использованием ansible(?). Я своим сообщением хотел донести, что конфигурировать можно и это не проблема.
Без разницы какой системой управления конфигурации я раскатываю ceph — в любом случае это гибче и надежнее, чем Rook.
Про VPA спорный вопрос. Если у вас выделенный кластер под ceph, то вы вероятно его не ограничиваете. Если кластер для ceph и приложений общий, то VPA и POD PRIORITY могут с играть решающую роль в работе всего кластера.
VPA и ограничение кластера по ресурсам в зависимости от политики или вынесет вам payload из кластера kubernetes или зарежет ceph, что приведет к его ООМ и опять таки выносу или тормозам вашего payload в кластере kuberentes. Но опять таки это вопрос сложности capacity planing.
Обязательно напишем статью, в ближайшее время, на тему возможностей конфигурирования rook.
Я с удовольствием почитаю, только пожалуйста не забудьте рассказать о сетевом взаимодействии и разделением по линкам.
Да, в первое время может быть больно, просто нужно отдавать отчет в своих действиях.
Пока я вижу только боль, повышенные риски и никих преимуществ перед классическим ceph.artzcom
17.05.2019 18:06+1Предлагаю поставить точку на этом моменте и продолжить спор под следующей статьей )
artzcom
16.05.2019 19:48И да, ceph >= 13 уже более грамотно подходит к ребалансу. Он начал различать запросы на чтение/запись от ребаланса и приоретизировать их.
ustas33
16.05.2019 20:44+1Интересно, что скажут ребята из Nutanix?
awsswa59
17.05.2019 11:09+1пока ребята чисто ржут.
и удивляются что кто то такое тащит в серьезный продакшин.
romxx
17.05.2019 11:55А почему вас интересует их мнение? Да и что тут можно сказать еще, сверх многократно сказанного, что ceph — сырой и непригоден в продакшн, и долго еще не будет, не рассчитывайте на бесплатное, дороже выйдет, используйте нормально работающие решения с поддержкой.
ultral
17.05.2019 12:19если ceph приготовить, то он он вполне готов к проду.
romxx
17.05.2019 13:09Возможно. Не встречал таких. Вероятно это история про «сферического коня», про которого многие слышали, но никто не видел. Знаю только, что стоить это будет дорого. Возможно дороже, чем готовое, работающее коммерческое решение, которое можно купить сегодня, а завтра запустить в прод.
Но тогда зачем такой ceph?
prudnitskiy
Наконец-то кто-то оформил в виде текста мысли, которые я пытаюсь высказать пользователям rook!