Он вам не дRook +37



В связи с набирающей популярностью 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. Анатомия катастрофы

Вы можете помочь и перевести немного средств на развитие сайта

Теги:



Комментарии (17):

  1. prudnitskiy
    /#20162564 / +2

    Наконец-то кто-то оформил в виде текста мысли, которые я пытаюсь высказать пользователям rook!

  2. ultral
    /#20162716

    Ведал ceph 0.87 — 12.2 версий. в сумме порядка 10PB со всех кластеров. Подписываюсь под всеми словами что ceph это сложная штука и без понимания как оно там внутри будет сложно, без адекватных инженеров для его поддержания тяжело будет.

    Идея выглядит интересно, но какие-то практические кейсы для применения внутри k8s/openshift придумать сложно окромя:
    — CI/CD для ceph
    — k8s/openshift без персистентного стораджа

  3. artzcom
    /#20162952

    Пример: OSD падает сыпя ошибками себе под ноги. Вы подозреваете, что проблема в одном из параметров в конфиге, хотите поменять конфиг для конкретного демона, но не можете, потому что у вас kubernetes и DaemonSet.

    Сложность последовательного поднятия OSD


    Так давно переделали на statefulset. Для каждой OSD есть свой configmap и никто не мешает поправить какие то параметры конкретно для той самой OSD. Скейл в ноль любую osd и восстанавливай в ручном режиме.

    Однако ceph содержит более 1000 параметров для настройки, в тоже время через rook мы можем править лишь меньшую часть из них.

    Любые параметры в rook можно задать через configmap.

    И тут вам придется попотеть с тестами производительности. В случае занижения лимитов вы получите медленный кластер, в случае выставления unlim вы получите активное использование CPU при ребалансе, что будет плохо влиять на ваши приложения в kubernetes.

    А если не использовать rook, ceph у вас на тех же железках, что и kubernetes? Если да, то скорее всего вы имеете те же проблемы. В плане подбора ресурсов в kubernetes, можно и нужно использовать VPA.

    Проблемы с сетевым взаимодействием v1

    Не совсем понятно, почему для кластера ceph и rook по умолчанию рассматриваете разную конфигурацию серверов. Это не проблема rook!

    PS: В целом, вы описываете проблемы, которые преследуют rook точно так же как и ceph.
    Так же, есть ощущение, что рассматривается одна из старых версий rook.

    PPS: С одной стороны, rook упрощает работу с ceph, с другой стороны усложняет. Да, ceph сам по себе не прост в эксплуатации, но если мы (все мы, сообщество) не будем пользоваться подобными инструментами, они не будут развиваться. Возможно, сейчас для многих, rook будет сильно избыточен. Но вы попробуйте поддерживать 3-4 десятка небольших ceph кластеров… (тут я умышленно не заканчиваю предложение)

    • ultral
      /#20163012

      ceph & k8s две сложные системы. когда мы их скрещиваем сложность возрастает катастрофически

      * пусть у ceph X параметров, каждый параметр принимает N значений, т.е. кол-во конфигураций X^N
      * пусть у k8s Y параметров, у каждого M значения, т.е. кол-во конфигураций Y^M

      если это две параллельные системы, то X^N * Y^M
      если это одно встроено в другую, то (Y*X^N)^M. т.е. сложность конфигурирования системы будет расти по экспоненете(если точнее то X^M)

      • artzcom
        /#20163048

        Волков бояться — в лес не ходить.

        • ultral
          /#20163098

          весомый аргумент, сложно парировать.

          как писал выше это интересное решение, но в прод не рискну с ним ну или мб кейсов не вижу для него.

    • SinTeZoiD
      /#20165528

      Любые параметры в rook можно задать через configmap.

      Ок, допустим мы можем править конфиг каждой OSD, но тогда мы всё равно лишаемся удобства Rook.
      А если не использовать rook, ceph у вас на тех же железках, что и kubernetes? Если да, то скорее всего вы имеете те же проблемы. В плане подбора ресурсов в kubernetes, можно и нужно использовать VPA.

      Если у вас выделенные железки под ceph, то перед их покупкой вы обычно считаете capacity кластера и подбираете железо под нагрузку.
      VPA по сути костыль. Концепт «давайте больше ресурсов поду, пока он не начнет влезать» — по сути ничем не отличается от безлимитного пода.
      Не совсем понятно, почему для кластера ceph и rook по умолчанию рассматриваете разную конфигурацию серверов. Это не проблема rook!

      Допустим у вас одинаковая конфигурация серверов под ceph и под kubernetes + Rook
      2х10гб. В случае ceph я просто в конфиге прописываю через какой линк ходит служебный трафик, а через какой клиентский.
      А теперь расскажите мне пожалуйста как вы проделаете этот фокус с распределением линков в Rook?
      PS: В целом, вы описываете проблемы, которые преследуют rook точно так же как и ceph.
      Так же, есть ощущение, что рассматривается одна из старых версий rook.

      У Rook есть и свои проблемы, как например сложности дебага ceph демонов при проблемах.

      • artzcom
        /#20167040 / -1

        Ок, допустим мы можем править конфиг каждой OSD, но тогда мы всё равно лишаемся удобства Rook.

        Согласен, но теперь вся конфигурация лежит под гитом в yaml файлах. Да, я понимаю, что у вас скорее всего так же, только с использованием ansible(?). Я своим сообщением хотел донести, что конфигурировать можно и это не проблема.

        VPA по сути костыль. Концепт «давайте больше ресурсов поду, пока он не начнет влезать» — по сути ничем не отличается от безлимитного пода.

        Про VPA спорный вопрос. Если у вас выделенный кластер под ceph, то вы вероятно его не ограничиваете. Если кластер для ceph и приложений общий, то VPA и POD PRIORITY могут с играть решающую роль в работе всего кластера.

        Допустим у вас одинаковая конфигурация серверов под ceph и под kubernetes + Rook

        Обязательно напишем статью, в ближайшее время, на тему возможностей конфигурирования rook.

        У Rook есть и свои проблемы, как например сложности дебага ceph демонов при проблемах.

        Да, я немного слукавил, когда сказал, что разницы нет. Конечно же она есть и она не маленькая. В случае с rook, нужно понимать как работает OS и CEPH так в нагрузку еще и Kubernetes + ROOK. Я ни в коем случае не пропогандирую отказ от класического ceph'а и переход на rook. Я говорю, что в ряде случаев, есть смысл его использовать. Да, в первое время может быть больно, просто нужно отдавать отчет в своих действиях.

        • SinTeZoiD
          /#20167506

          Согласен, но теперь вся конфигурация лежит под гитом в yaml файлах. Да, я понимаю, что у вас скорее всего так же, только с использованием ansible(?). Я своим сообщением хотел донести, что конфигурировать можно и это не проблема.

          Без разницы какой системой управления конфигурации я раскатываю ceph — в любом случае это гибче и надежнее, чем Rook.
          Про VPA спорный вопрос. Если у вас выделенный кластер под ceph, то вы вероятно его не ограничиваете. Если кластер для ceph и приложений общий, то VPA и POD PRIORITY могут с играть решающую роль в работе всего кластера.

          VPA и ограничение кластера по ресурсам в зависимости от политики или вынесет вам payload из кластера kubernetes или зарежет ceph, что приведет к его ООМ и опять таки выносу или тормозам вашего payload в кластере kuberentes. Но опять таки это вопрос сложности capacity planing.
          Обязательно напишем статью, в ближайшее время, на тему возможностей конфигурирования rook.

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

          Пока я вижу только боль, повышенные риски и никих преимуществ перед классическим ceph.

          • artzcom
            /#20167528 / +1

            Предлагаю поставить точку на этом моменте и продолжить спор под следующей статьей )

  4. artzcom
    /#20162962

    И да, ceph >= 13 уже более грамотно подходит к ребалансу. Он начал различать запросы на чтение/запись от ребаланса и приоретизировать их.

  5. ustas33
    /#20163172 / +1

    Интересно, что скажут ребята из Nutanix?

    • awsswa59
      /#20165138 / +1

      пока ребята чисто ржут.
      и удивляются что кто то такое тащит в серьезный продакшин.

    • romxx
      /#20165430

      А почему вас интересует их мнение? Да и что тут можно сказать еще, сверх многократно сказанного, что ceph — сырой и непригоден в продакшн, и долго еще не будет, не рассчитывайте на бесплатное, дороже выйдет, используйте нормально работающие решения с поддержкой.

      • ultral
        /#20165584

        если ceph приготовить, то он он вполне готов к проду.

        • romxx
          /#20165892

          Возможно. Не встречал таких. Вероятно это история про «сферического коня», про которого многие слышали, но никто не видел. Знаю только, что стоить это будет дорого. Возможно дороже, чем готовое, работающее коммерческое решение, которое можно купить сегодня, а завтра запустить в прод.
          Но тогда зачем такой ceph?

    • P6i
      /#20167228

      Будут рассказывать о простреленом колене в лесной местности