С оглед на нарастващата популярност на Rook, е време да обсъдим неговите недостатъци и проблемите, с които можете да се сблъскате по пътя.
За мен: Опит в администрирането на ceph от версия hammer, основател на общността в Telegram.
За да не бъда голословен, ще се позовавам на признати публикации в хабра (със съответния рейтинг) относно проблемите с ceph. С много от тези проблеми също съм се сблъсквал. Линкове към използвания материал в края на публикацията.
В публикацията за Rook обсъждаме ceph не без причина — Rook по същество е ceph, опакован в Kubernetes, което означава, че наследява всички негови проблеми. Нека започнем с проблемите на ceph.
Оптимизирано управление на клъстера
Едно от предимствата на Rook е лесното управление на ceph чрез Kubernetes.
Въпреки това 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 е неработоспособен.
Сложност на дебъгинга
За някои настройки и тестове на производителността е необходимо директно свързване със сокета на osd демона. В случая с Rook, първо трябва да намерите нужния контейнер, след това да влезете в него, да откриете липсващите инструменти за дебъгинг и да бъдете много разочаровани.
Сложност на последователното активиране на OSD
Пример: OSD пада поради OOM, започва ребаланс, след което падат нови.
Решение: Поднимайте OSD по одной, дожидаясь её полного включения в кластер, и затем поднимайте следующие. (Повече в доклада Ceph. Анатомия катастрофи).
В случай на baremetal инсталация, това става лесно ръчно, в случай на Rook и една OSD на нода, няма особени проблеми. Проблемите с последователното повдигане ще се появят, ако OSD > 1 на нода.
Разбира се, те са разрешими, но ние нали не въвеждаме Rook за опростяване, а получаваме усложнение.
Сложността при подбора на лимити за ceph демони.
За baremetal инсталиране на ceph е достатъчно лесно да се изчислят необходимите ресурси за кластера — формули и изследвания съществуват. При използването на слаби CPU, все пак ще трябва да проведете серия от тестове за производителност, да разберете какво е Numa, но това все пак е по-просто отколкото в Rook.
В случай на Rook, освен лимитите на паметта, които могат да се изчислят, възниква въпросът за установяване на лимита на CPU.
И тук ще трябва да се потрудите с тестове за производителност. При занижаване на лимитите, ще получите бавен кластер, а при определяне на unlim, ще получите активно използване на CPU при ребалансиране, което ще повлияе негативно на вашите приложения в kubernetes.
Проблеми с мрежовото взаимодействие v1.
За ceph се препоръчва да се използва 2x10gb мрежа. Едната за клиентски трафик, другата за служебни нужди на ceph (ребаланс). Ако работите с ceph на baremetal, това разделение лесно се конфигурира, но ако работите с Rook, разделянето по мрежи ще ви създаде проблеми, тъй като далеч не всеки конфигурационен файл на кластера позволява да се предоставят на pod две различни мрежи.
Проблеми с мрежовото взаимодействие v2.
Ако откажете да разделяте мрежите, то при ребаланс трафикът на ceph ще запълни целия канал и вашите приложения в kubernetes ще забавят или ще паднат. Може да намалите скоростта на ребаланс на ceph, но тогава за сметка на дългия ребаланс получавате повишен риск от отпадане на втори нод от кластера по дискове или ООМ, а там вече е гарантирано read only за кластера.
Дълъг ребаланс — дълги забавяния на приложенията.
Цитата от поста Ceph. Анатомия на катастрофата.
Производителността на тестовия кластер:
Записната операция с размер 4 Kбайта отнема 1 ms, производителността е 1000 операции/секунда в 1 поток.
Операция с размер 4 Мбайта (размер на обекта) отнема 22 ms, производителността е 45 операции/секунда.
Следствие е, че когато един от трите домена се провали, клъстерът за известно време е в деградирало състояние, и половината от горещите обекти се разпределят по различни версии, то половината записващи операции ще започнат с принудително възстановяване.
Времето за принудително възстановяване се изчислява приблизително — записващи операции в деградиран обект.
Първо четем 4 Мбайта за 22 мс, записваме 22 мс, и след това за 1 мс записваме 4 Кб от самите данни. Общо взето, 45 мс за една записваща операция в деградиран обект на SSD, когато нормалната производителност е била 1 мс — падение на производителността в 45 пъти.
Колкото по-висок е процентът на деградиралите обекти, толкова по-сериозно става положението.
И така, скоростта на ребалансиране е критично важна за правилната работа на клъстера.
Специфични настройки на сървърите за ceph
ceph понякога изисква специфично настройване на хоста.
Пример: настройки sysctl и JumboFrame, част от тези настройки могат негативно да влияят на вашия payload.
Реалната необходимост от Rook остава под въпрос.
Ако сте в облака, имате хранилище от вашия облачен доставчик, което е много по-удобно.
Ако сте на собствените си сървъри, управлението на ceph ще бъде по-удобно без Kubernetes.
Наемате ли сървъри в някакъв low cost хостинг? Тогава ви очаква много забавление с мрежата, нейните закъснения и пропускна способност, което явно ще повлияе негативно на ceph.
Общо: Внедряването на Kubernetes и внедряването на хранилище са различни задачи с различни условия и различни варианти на решения - смесването им е възможно опасен компромис в полза на едното или другото. Съчетаването на тези решения ще бъде много трудно дори на етапа на проектиране, а има и период на експлоатация.
Списък на използваната литература:
А вие казвате Ceph… наистина ли е толкова добър?
Ceph. Анатомия на катастрофата
Източник: habr.com
