С оглед на нарастващата популярност на 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 пада по ООМ, започва ребаланс, след което падат следващите.
Решение: Стартирайте 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, но тогава за сметка на дългия ребаланс получавате повишен риск от изключване на втория нод от клъстера по дискове или ООМ, и там вече е гарантиран режим на само четене на клъстера.
Дългият ребаланс — дълги забавяния на приложенията
Цитата от поста Ceph. Анкета на катастрофата.
Производителност на тестовия клъстер:
Записването на операция с размер 4 Кбайта отнема 1 мс, производителност 1000 операции/секунда в 1 поток.
Операция с размер 4 Мбайта (размер на обекта) отнема 22 мс, производителност 45 операции/секунда.
Следовательно, когато един домен от трите е неработещ, клъстерът за известно време се намира в деградирало състояние и половината от горещите обекти ще бъдат разпределени между различни версии; в такъв случай половината записи ще започнат с принудително възстановяване.
Времето за принудително възстановяване се изчислява ориентировъчно — записите в деградиралия обект.
Най-напред четем 4 МБ за 22 мс, записваме 22 мс, а след това записваме 4 КБ действителни данни за 1 мс. Общо 45 мс за една операция на запис в деградиралия обект на SSD, когато нормалната производителност е била 1 мс — спад на производителността от 45 пъти.
Колкото по-висок е процентът на деградирали обекти, толкова по-страшно става положението.
Получава се, че скоростта на ребаланс е критично важна за правилната работа на клъстера.
Специфични настройки на сървърите за ceph
ceph може да се нуждае от специфичен тюнинг на хоста.
Пример: настройки на sysctl и JumboFrame, някои от тези настройки могат негативно да повлияят на вашия payload.
Реалната необходимост от Rook остава под въпрос
Ако сте в облака, имате хранилище от вашия облачен доставчик, което е много по-удобно.
Ако сте на своите сървъри, управлението на ceph ще бъде по-удобно без kubernetes.
Наемате ли сървъри от някой low cost хостинг? Тогава ви очаква много забавление с мрежата, закъсненията и пропускната способност, което определено влияе негативно на ceph.
В обобщение: Внедряването на kubernetes и внедряването на хранилище са различни задачи с различни входни данни и различни варианти за решение — смесването им е опасен trade-off в името на това или онова. Съчетаването на тези решения ще бъде много трудно дори на етап проектиране, а има и период на експлоатация.
Списък на използваната литература:
А вие казвате Ceph… наистина ли е толкова добър?
Ceph. Анатомия на катастрофата
Източник: habr.com
