В связи с набирающей популярностью Rook хочется поговорить о его подводных камнях и проблемах, которые ждут вас на пути.
О себе: Опыт администрирования ceph с версии hammer, основатель комьюнити в телеграм.
Дабы не быть голословным я буду ссылаться на принятые хабром (судя по рейтингу) посты о проблемах с ceph. С бОльшей частью проблем в этих постах я тоже столкнулся. Ссылки на использованный материал в конце поста.
В посте про Rook мы упоминаем ceph не просто так — Rook по сути ceph завернутый в kubernetes, а значит наследует все его проблемы. С проблем ceph и начнем.
Упрощение управления кластером
Одним из преимуществ Rook является удобство управление ceph через kuberentes.
Однако ceph содержит более 1000 параметров для настройки, в тоже время через rook мы можем править лишь меньшую часть из них.
Пример на Luminous
> ceph daemon mon.a config show | wc -l
1401
Rook позиционируется как удобный способ устанавливать и обновлять ceph
С установкой 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
Не обновляться, ждать и тестировать? Но мы вроде используем 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овместить эти решения будет очень сложно даже на этапе проектирования, а есть еще период эксплуатации.
Список использованной литературы:
А вот вы говорите Ceph… а так ли он хорош?
Ceph. Анатомия катастрофы
Источник: habr.com