Он вам не дRook

в 13:52, , рубрики: ceph, devops, kubernetes, Rook, системное администрирование, хранение данных

В связи с набирающей популярностью Rook хочется поговорить о его подводных камнях и проблемах, которые ждут вас на пути.

О себе: Опыт администрирования ceph с версии hammer, основатель комьюнити t.me/ceph_ru в телеграм.

Дабы не быть голословным я буду ссылаться на принятые хабром (судя по рейтингу) посты о проблемах с 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
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. Анатомия катастрофы

Автор: SinTeZoiD

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js