В связи с набирающей популярностью 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 операций/секунду.
Prandaj, kur një domen nuk funksionon nga tre, klasteri është për një kohë në një gjendje të degraduar, dhe gjysma e objekteve të nxehta do të shpërndahet në versione të ndryshme, atëherë gjysma e operacioneve të shkrimit do të fillojnë me rikuperim të detyruar.
Koha e rikuperimit të detyruar llogaritet përafërsisht - operacionet e shkrimit në një objekt të degraduar.
Së pari ne lexojmë 4 MB për 22 ms, shkruajmë 22 ms, dhe pastaj 1 ms shkruajmë 4 KB të dhënave të vetë. Gjithsej 45 ms për një operacion shkrimi në një objekt të degraduar në SSD, kur përformanca standarde ishte 1 ms - rënë në 45 herë përformanca.
Sa më i madh të jetë përqindja e objekteve të degraduara, aq më keq bëhet gjithçka.
Kështu, shpejtësia e ribalancit është kritikisht e rëndësishme për funksionimin e saktë të klasterit.
Parametrat e veçantë të serverëve për ceph
ceph shpesh kërkon një tuning specifik të hostit.
Shembuj: konfigurimet e sysctl dhe po ashtu JumboFrame, disa nga këto konfigurime mund të kenë një ndikim negativ në payload-in tuaj.
Nevojshmëria reale për Rook mbetet nën pyetje
Nëse jeni në cloud, keni një depo nga ofruesi juaj i cloud-it, që është shumë më e përshtatshme.
Nëse jeni në serverat tuaj, menaxhimi i ceph do të jetë më i lehtë pa kubernetes.
A keni marrë servera në ndonjë hostim me kosto të ulët? Atëherë ju pret shumë argëtim me rrjetin, vonesat dhe kapacitetin, që e ndikon ndjeshëm në ceph.
Në përmbledhje: Zbatimi i kubernetes dhe zbatimi i depozitës janë detyra të ndryshme me hyrje të ndryshme dhe zgjidhje të ndryshme - përzierja e tyre do të thotë të bëni një trade-off të rrezikshëm në favor të njëra-tjetrës. Të kombinosh këto zgjidhje do të jetë shumë e vështirë edhe në fazën e projektimit, dhe ka gjithashtu periudhën e eksploatimit.
Lista e literaturës së përdorur:
Por ju thoni Ceph... a është ai kaq i mirë?
Ceph. Anatomia e katastrofës
Burimi: habr.com
