А вот вы говорите Ceph… а так ли он хорош?


    Я люблю Ceph. Я работаю с ним уже 4 года (0.80.x — 12.2.6, 12.2.5). Порой я так увлечен им, что провожу вечера и ночи в его компании, а не со своей девушкой.
 Я сталкивался с различными проблемами в этом продукте, а с некоторыми продолжаю жить и по сей день. Порой я радовался легким решениям, а иногда мечтал о встрече с разработчиками, чтобы выразить свое негодование. Но Ceph по-прежнему используется в нашем проекте и не исключено, что будет использоваться в новых задачах, по крайней мере мной. В этом рассказе я поделюсь нашим опытом эксплуатации Ceph, в некотором роде выскажусь на тему того, что мне не нравится в этом решении и может быть помогу тем, кто только присматривается к нему. К написанию этой статьи меня подтолкнули события, которые начались примерно год назад, когда в наш проект завезли Dell EMC ScaleIO, ныне известный как Dell EMC VxFlex OS.


    Это ни в коем случае не реклама Dell EMC или их продукта! Лично я не очень хорошо отношусь к большим корпорациям, и черным ящикам вроде VxFlex OS. Но как известно, всë в мире относительно и на примере VxFlex OS очень удобно показать каков Ceph с точки зрения эксплуатации, и я попробую это сделать.


    Параметры. Речь идет о 4-значных числах!


    Сервисы Ceph такие как MON, OSD и т.д. имеют различные параметры для настройки всяческих подсистем. Параметры задаются в конфигурационном файле, демоны считывают их в момент запуска. Некоторые значения можно удобно изменять налету с помощью механизма "инжекта", о котором чуть ниже. Все почти супер, если опустить тот момент, что параметров сотни:

    Hammer:


    > ceph daemon mon.a config show | wc -l
    863

    Luminous:


    > ceph daemon mon.a config show | wc -l
    1401

    Получается ~500 новых параметров за два года. В целом параметризация — это круто, не круто то, что есть трудности с пониманием 80% из этого списка. В документации описано по моим прикидкам ~20% и местами неоднозначно. Понимание смысла большинства параметров приходится искать в github'е проекта или в листах рассылки, но и это не всегда помогает.


    Вот пример нескольких параметров, которые мне были интересны буквально недавно, я нашел их в блоге одного Ceph-овода:


    throttler_perf_counter = false  // enable/disable throttler perf counter
    osd_enable_op_tracker = false   // enable/disable OSD op tracking

    Комменты в коде в духе лучших практик. Как бы, слова я понимаю и даже примерно о чём они, но что мне это даст — нет.


    Или вот: osd_op_threads в Luminous не стало и только исходники помогли найти новое название: osd_peering_wq threads


    Ещё мне нравится, что есть особенно холиварные параметры. Тут чувак показывает, что увеличение rgw_num _rados_handles это благо:


    а другой чувак считает, что > 1 делать нельзя и даже опасно.


    И самое мое любимое — это когда начинающие специалисты приводят в своих блог-постах примеры конфига, где все параметры бездумно (мне так кажется) скопированы с другого такого же блога, и так куча параметров, о которых никто не знает кроме автора кода — кочует из конфига в конфиг.


    Еще я просто дико горю с того, что они сделали в Luminous. Есть суперкрутая фича — изменение параметров на лету, без перезапуска процессов. Можно, например, изменить параметр конкретного OSD:


    > ceph tell osd.12 injectargs '--filestore_fd_cache_size=512'

    или поставить '*' вместо 12 и значение будет изменено на всех OSD. Это оч круто, правда. Но, как и многое в Ceph, это сделано левой ногой. Бай дизайн не все значения параметров можно менять на лету. Точнее, их можно сетить и они появятся в выводе измененными, но по факту, перечитываются и пере-применяются лишь некоторые. Например, нельзя изменить размер тред-пула без рестарта процесса. Чтобы исполнитель команды понимал, что параметр бесполезно менять таким способом — решили печатать сообщение. Здраво.


    Например:


    > ceph tell mon.* injectargs '--mon_allow_pool_delete=true'
    mon.c: injectargs:mon_allow_pool_delete = 'true' (not observed, change may require restart)
    mon.a: injectargs:mon_allow_pool_delete = 'true' (not observed, change may require restart)
    mon.b: injectargs:mon_allow_pool_delete = 'true' (not observed, change may require restart)

    Неоднозначно. По факту удаление пулов становится возможным после инжекта. То есть этот warning не актуален для этого параметра. Ок, но есть еще сотни параметров, в том числе и очень полезные, у которых тоже warning и проверить их фактическую применимость нет возможности. На текущий момент я не могу понять даже по коду, какие параметры применяются после инжекта, а какие нет. Для надежности приходится рестартить сервисы и это, знаете ли, бесит. Бесит потому что я знаю, что есть механизм инжекта.


    Как с этим у VxFlex OS? У аналогичных процессов типа MON (в VxFlex это MDM), OSD (SDS в VxFlex) тоже есть конфигурационные файлы, в которых на всех с десяток параметров. Правда их названия тоже ни о чем не говорят, но радует то, что мы к ним никогда не прибегали, чтобы так гореть как с Ceph.


    Технический долг


    Когда вы начинаете свое знакомство с Ceph с самой актуальной на сегодня версии, то все кажется прекрасным, так и хочется написать позитивную статью. Но когда ты живешь с ним в проде с версии 0.80, то все выглядит не так радужно.


    До Jewel, процессы Ceph работали от root'а. В Jewel было решено, что они должны работать от пользователя 'ceph' и это требовало смены владельца у всех каталогов, которые используются сервисами Ceph.
Казалось бы, что такого? Представьте себе OSD, которая обслуживает магнитный SATA-диск емкостью 2 TB, заполненный на 70%. Так вот, chown такого диска, в параллель (на разные подкаталоги) при полной утилизации диска занимает 3-4 часа. Представьте, что у вас, например, 3 сотни таких дисков. Даже если обновлять нодами (chown'ить сразу 8-12 дисков) получается довольно долгое обновление, при котором в кластере будут OSD разных версий и на одну реплику данных меньше в момент вывода сервера на обновление. В общем мы посчитали, что это абсурд, пересобрали пакеты Ceph и оставили работать OSD под root'ом. Решили, что по мере ввода или замены OSD будем переводить их на нового пользователя. Сейчас мы меняем 2-3 диска в месяц и добавляем 1-2, думаю к 2022 году справимся).


    CRUSH Tunables


    CRUSH — сердце Ceph, всё вертится вокруг него. Это алгоритм, с помощью которого, псевдослучайным образом выбирается место размещения данных и благодаря которому клиенты, работающие с RADOS-кластером узнают на каких OSD хранятся нужные им данные (объекты). Ключевая фишка CRUSH в том, что нет необходимости в каких-то серверах метаданных, как например в Lustre или IBM GPFS (ныне Spectrum Scale). CRUSH позволяет клиентам и OSD взаимодействовать друг с другом напрямую. Хотя, конечно, сложно сравнивать примитивное объектное хранилище RADOS и файловые системы, что я привёл в качестве примера, но думаю мысль понятна.


    В свою очередь, CRUSH tunables — это набор параметров/флагов, которые влияют на работу CRUSH, делают его более эффективным по крайней мере в теории.


    Так вот, при обновлении с Hammer на Jewel (тестовом естественно) появился warning, мол tunables профиль имеет не оптимальные для текущей версии (Jewel) параметры и рекомендуется переключить профиль на оптимальный. В целом все понятно. В доке сказано, что это очень важно и это верный путь, но также сказано, что после переключения данных будет ребеланс 10% данных. 10% — звучит не страшно, но мы решили протестировать. Для кластера, примерно в 10 раз меньше того, что на проде, с таким же числом PG на одну OSD, заполненном тестовыми данными мы получили ребеланс 60%! Представляете, например, при 100TB данных, 60TB начинают перемещаться между OSD и это при постоянно идущей клиентской нагрузке требовательной к latency! Если я еще не сказал, мы предоставляем s3 и у нас даже ночью не особо снижается нагрузка на rgw, которых сейчас 8 и ещё 4 под статические сайты (static websites). В общем мы решили, что это не наш путь тем более, что делать такой ребеланс на новой версии, с которой мы еще не работали в проде — как минимум слишком оптимистично. К тому же у нас были большие бакет-индексы, которые очень плохо переживают ребеланс и это тоже было причиной отсрочки переключения профиля. Об индексах будет отдельно чуть ниже. В итоге мы просто убрали warning и решили вернуться к этому позже.


    А еще при переключении профиля в тестинге у нас отвалились cephfs-клиенты, которые в ядрах CentOS 7.2, так как они не могли работать с более новым алгоритмом хеширования пришедшего с новым профилем. Мы не используем cephfs в проде, но, если бы использовали, то это было бы ещё одной причиной не переключать профиль.


    Кстати, в доке сказано, что если то, что будет происходить во время ребеланса вас не устраивает, то можно откатить профиль обратно. В действительности, после чистой установки версии Hammer и обновления на Jewel профиль выглядит так:


    > ceph osd crush show-tunables
    {
        ...
        "straw_calc_version": 1,
        "allowed_bucket_algs": 22,
        "profile": "unknown",
        "optimal_tunables": 0,
        ...
    }

    Тут важно, что он "unknown" и, если попытаться остановить ребеланс переключением его на "legacy" (как сказано в доке) или даже на "hammer", то ребеланс не прекратится, он просто продолжится в соответствии с другими tunables, а не "оптимальными". В общем всё нужно досконально проверять и перепроверять, ceph доверия нет.


    CRUSH trade-of


    Как известно, всё в этом мире сбалансированно и ко всем преимуществам прилагаются недостатки. Недостаток CRUSH в том, что PG размазываются по разным OSD неравномерно даже при одинаковом весе последних. Плюс к этому, ничего не мешает разным PG расти с разной скоростью, тут как хеш-функция ляжет. Конкретно у нас разброс утилизации OSD 48-84% при том, что они имеют один и тот же размер и, соответственно, вес. Даже серверы мы стараемся делать равными по весу, но это так, просто наш перфекционизм, не более.
И фиг бы с тем, что IO по дискам распределяется неравномерно, самое страшное то, что при достижении статуса full (95%) хотя бы одной OSD в кластере, вся запись останавливается и кластер переходит в readonly. Весь кластер! И не важно, что в кластере еще полно места. Всё, конечная, выходим! Это архитектурная особенность CRUSH. Представляете, вы такие в отпуске, какая-то OSD пробила отметку в 85% (первый warning по умолчанию), и у вас есть 10% в запасе, чтобы не допустить остановки записи. А 10% при активно идущей записи — это не так уж много/долго. В идеале, с таким дизайном, для Ceph нужен дежурный, способный выполнить подготовленную инструкцию в подобных случаях.


    Так вот, решили мы значит разбалансировать данные в кластере, т.к. несколько OSD были близки к nearfull-отметке (85%).


    Есть несколько путей:


    • Добавить диски

    Проще всего, слегка расточительно и при этом не сильно эффективно, т.к. сами по себе данные могут и не переместиться с переполненных OSD или перемещение будет незначительным.


    • Менять перманентный вес OSD (WEIGHT)

    Это приводит к изменению веса всех вышестоящих бакетов (терминология CRUSH) по иерархии, OSD сервера, дата-центра и т.д. и, как следствие, к перемещению данных, в том числе не с тех OSD, с которых надо.
    Мы попробовали, снизили вес одной OSD, после ребеланса данных наполнилась другая, снизили ей, затем третья и мы поняли, что будем долго так играться.


    • Менять не-перманентный вес OSD (REWEIGHT)

    Это то, что делается при вызове 'ceph osd reweight-by-utilization'. Это приводит к смене так называемого корректировочного веса OSD и при этом не меняется вес вышестоящих бакетов. В результате данные балансируют между разными OSD одного сервера, как бы, не выходя за пределы бакета CRUSH. Нам этот подход очень понравился, мы посмотрели в dry-run'е какие будут изменения и выполнили на проде. Все было хорошо, пока процесс ребеланса не встал колом примерно на середине. Опять гугление, чтение рассылок, эксперименты с разными опциями и в конце концов выясняется, что остановка вызвана отсутствием у нас некоторых tunables в профиле о котором говорилось выше. Опять нас догнал технический долг. В итоге мы пошли по пути добавления дисков и самого неэффективного ребеланса. Благо нам все равно нужно было это делать т.к. переключение CRUSH-профиля планировалось делать с достаточным запасом по ёмкости.


    Да, мы знаем про balancer (Luminous и выше) вошедший в состав mgr, который призван решить проблему неравномерности распределения данных путем перемещения PG между OSD, например, по ночам. Но я не слышал ещё положительных отзывов о его работе даже в актуальном Mimic.


    Вы, наверное, скажете, что технический долг — это сугубо наша проблема и я, пожалуй, соглашусь. Но за четыре года с Ceph в проде у нас был зафиксирован только один downtime s3, который продлился целый 1 час. И то, проблема была не в RADOS'е, а в RGW, которые набрав свои дефолтные 100 тредов вешались намертво и у большинства пользователей не выполнялись запросы. Это было еще на Hammer. На мой взгляд, это хороший показатель и достигнут он благодаря тому, что мы не делаем резких движений и достаточно скептичны на счёт всего в Ceph.


    Дикий GC


    Как известно, удаление данных непосредственно с диска — это довольно ресурсоёмкая задача и в продвинутых системах удаление делается отложено или не делается вообще. Ceph тоже продвинутая система и в случае с RGW, при удалении s3-объекта, соответствующие RADOS-объекты не удаляются с диска сразу. RGW помечает s3-объекты как удаленные, а отдельный gc-поток занимается удалением объектов непосредственно из RADOS пулов и соответственно с дисков отложено. После обновления на Luminous поведение gc заметно поменялось, он стал работать агрессивнее, хотя параметры gc остались прежними. Под словом заметно я имею ввиду, что мы стали видеть работу gc на внешнем мониторинге сервиса по подскакивающему latency. Это сопровождалось высоким IO в пуле rgw.gc. Но проблема, с которой мы столкнулись гораздо эпичнее чем просто IO. При работе gc генерируется очень много логов вида:


    0 <cls> /builddir/build/BUILD/ceph-12.2.5/src/cls/rgw/cls_rgw.cc:3284: gc_iterate_entries end_key=1_01530264199.726582828

    Где 0 в начале — это уровень логирования, при котором печатается данное сообщение. Как бы, ниже нуля опускать логирование уже некуда. В итоге ~1 GB логов у нас генерился одной OSD за пару часов, и всё бы ничего, если бы ceph-ноды не были бы бездисковыми… Мы загружаем OS по PXE прямо в память и не используем локальные диск или NFS, NBD для системного раздела (/). Получаются stateless-серверы. После перезагрузки всё состояние накатывается автоматизацией. Как это работает я как-нибудь опишу в отдельном материале, сейчас важно то, что под "/" отведено 6 GB памяти, из которых обычно свободно ~4. Мы отправляем все логи в Graylog и используем довольно агрессивную политику ротации логов и обычно не испытываем каких-либо проблем с переполнением дисков/RAM. Но к такому мы были не готовы, при 12 OSD на сервере "/" заполнился очень быстро, дежурные вовремя не среагировали на триггер в Zabbix и OSD просто начали останавливаться из-за невозможности писать лог. В итоге мы понизили интенсивность gc, тикет не заводили т.к. таковой уже был, и добавили скрипт в cron, в котором делаем принудительный truncate логов OSD при превышении определенного объема не дожидаясь logrotate. Кстати, уровень логирования повысили.


    Placement Groups и хвалёная масштабируемость


    На мой взгляд, PG — это наиболее сложная абстракция для понимания. PG нужны для того, чтобы CRUSH был более эффективным. Основное предназначение PG — группировка объектов для снижения ресурсопотребления, повышения производительности и масштабируемости. Адресация объектов директно, по отдельности, без объединения их в PG была бы очень затратной.


    Основная проблема PG — это определение их числа для нового пула. Из блога Ceph:


    "Choosing the right number of PGs for your cluster is a bit of black art-and a usability nightmare".

    Это всегда очень специфично для конкретной инсталляции и требует длительных раздумий и подсчетов.


    Основные рекомендации:


    • Слишком много PG на OSD — плохо, будет перерасход ресурсов на их обслуживание и тормоза во время ребаланса/восстановления.
    • Мало PG на OSD — плохо, будет страдать производительность, и OSD будут заполнены неравномерно.
    • Число PG должно быть кратно степени 2. Это поможет получить "power of CRUSH".

    И вот тут у меня подгорает. PG не имеют ограничений по объему или по числу объектов. Сколько ресурсов (в реальных числах) нужно на обслуживание одной PG? Зависит ли это от ее размера? Зависит ли это от числа реплик этой PG? Стоит ли мне париться, если у меня достаточно памяти, быстрые CPU и хорошая сеть?
    И ещё нужно думать о будущем росте кластера. Число PG нельзя уменьшить — только увеличить. При этом делать это не рекомендуется, так как это повлечет, по сути, к сплиттингу части PG на новые и дикому ребелансу.


    "Increasing the PG Count of a pool is one of the most impactful events in a Ceph Cluster, and should be avoided for production clusters if possible".

    Поэтому о будущем нужно думать сразу, если это возможно.


    Реальный пример.


    Кластер из 3 серверов по 14x2 TB OSD в каждом, всего 42 OSD. Реплика 3, полезного места ~28 TB. Будет использоваться под S3, нужно рассчитать число PG для пула с данными и индексного пула. RGW использует больше пулов, но указанные два — основные.


    Заходим в калькулятор PG (есть такой калькулятор), считаем с рекомендуемыми 100 PG на OSD, получаем всего 1312 PG. Но не все так просто: у нас есть вводная — кластер в течение года точно вырастет в три раза, но железо докупят чуть позже. Увеличиваем "Target PGs per OSD" в три раза, до 300 и получаем 4480 PG.



    Устанавливаем число PG для соответствующих пулов — получаем warning: too many PG Per OSD… приехали. Получили ~300 PG на OSD при ограничении в 200 (Luminous). Раньше было 300, кстати. И самое интересное, что всем излишним PG не позволяется пириться (peering), то есть это не просто warning. В итоге считаем, что мы все делаем правильно, повышаем лимиты, отключаем предупреждение и идем дальше.


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


    S3, 152 TB полезного объема, 252 OSD по 1.81 TB, ~105 PG на OSD. Кластер рос постепенно, всё было хорошо пока с новыми законами в нашей стране не возникла потребность в росте до 1 PB, то есть + ~850 TB, и при этом нужно сохранить производительность, которая сейчас довольно хорошая для S3. Допустим мы возьмём диски по 6 (5.7 реально) TB и с учетом реплики 3 получим + 447 OSD. С учетом текущих получится 699 OSD по 37 PG на каждую, а если учитывать различный вес, то получится, что на старые OSD придётся всего десяток PG. И вот вы мне скажите, насколько сносно это будет работать? Производительность кластера с разным числом PG довольно сложно померить синтетически, но те тесты, что проводил я показывают, что для оптимальной производительности нужно от 50 PG на 2 TB OSD. А дальнейший рост? Без увеличения числа PG можно дойти до мапинга PG к OSD 1:1. Может я чего-то не понимаю?


    Да, можно создать новый пул для RGW с нужным числом PG и намапить на него отдельный S3-регион. Или и вовсе построить рядом новый кластер. Но согласитесь, что всё это костыли. И получается, что вроде как хорошо масштабируемый Ceph из-за своей концепции PG масштабируется с оговорками. Вам либо придётся жить с отключенными ворнингами готовясь к росту, либо в какой-то момент ребелансить все данные в кластере, либо забить на производительность и жить с тем, что получится. Либо пройти через всё это.


    Радует, что разработчики Ceph понимают, что PG сложная и лишняя абстракция для пользователя и ему о ней лучше не знать.


    "In Luminous we've taken major steps to finally eliminate one of the most common ways to drive your cluster into a ditch, and looking forward we aim to eventually hide PGs entirely so that they are not something most users will ever have to know or think about".

    В vxFlex нет понятия PG или каких-то аналогов. Вы просто добавляете диски в пул и всё. И так до 16 PB. Представляете, ничего не нужно рассчитывать, нет кучи статусов этих PG, диски утилизируются равномерно на всём протяжении роста. Т.к. диски отдаются в vxFlex целиком (нет файловой системы поверх них) нет возможности оценить заполненность и нет вообще такой проблемы. Я даже не знаю, как передать вам насколько это приятно.


    "Нужно ждать SP1"


    Ещё одна история "успеха". Как известно, RADOS — это примитивнейшее хранилище ключ-значение. S3, реализуемый поверх RADOS'а тоже примитивный, но все же немного более функционален. Например, в S3 можно получить список объектов по префиксу. Для того, чтобы это работало, RGW поддерживает свой собственный индекс для каждого бакета. Этот индекс — один RADOS-объект, который фактически будет обслуживаться одной OSD. С ростом числа объектов в бакете растёт объект индекса. По нашим наблюдениям, начиная от нескольких миллионов объектов в бакете начинаются заметные тормоза при записи в этот бакет. OSD обслуживающая объект индекса ест много памяти и может периодически уходить в down. Тормоза вызваны тем, что индекс блокируется на каждое изменение, дабы сохранить консистентность. Кроме этого, при операциях scrub'инга или ребеланса объект индекса также блокируется на всё время операции. Всё это периодически приводит к тому, что клиенты получают тайм-ауты и 503, производительность больших бакетов страдает в принципе.


    Bucket Index resharding — это механизм, позволяющий разделить индекс на несколько частей (RADOS-объектов) и, соответственно, разложить по разным OSD, тем самым добиться масштабируемости и снизить влияние служебных операций.


    Кстати, стоит отметить, что возможность ручного решардинга появилась только в Jewel и была бекпортирована в одну из последних багфиксных! сборок Hammer, что показывает ее высокую важность т.к. это не является баг-фиксом. Как вообще до этого работали большие бакеты?


    В Hammer у нас было несколько бакетов с 20+ млн объектов, и мы регулярно испытывали с ними проблемы, мы знали номера заветных OSD и по сообщениям из Graylog понимали, что с ними происходит. Ручной решардинг нам не подходил, т.к. требовал остановки IO для конкретного бакета. Нам нужен был Luminous, т.к. в нем решардинг стал автоматическим и прозрачным для клиентов. Мы обновились на Luminous, но решардинг не включали, тестировали. Всё выглядело нормально, и мы включили его в проде. IO ожидаемо подросло в index-пуле, бакеты начали шардироваться, я открыл бутылочку пивка и закончил рабочий день пораньше. Спустя день мы обнаружили, что IO стабильно держится на высоком уровне, при этом все проблемные бакеты расшардированы. Выяснялось, что индексы шардируются по кругу… Вскоре нашлись тикеты; раз, два:


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


    Кстати, обновление Hammer->Jewel было весёлым из-за этих жирных индексов. OSD держащая индекс пробивала все тайм-ауты на рестарте. Нам приходилось подкручивать таймауты тредов прям на проде, чтобы эти заветные OSD могли подняться и не убивали сами себя.


    История с авторешардингом — не единственный случай, когда новая фича работала так, что лучше бы она не работала вообще. В версии Hammer была такая фича s3, как версионирование объектов. Это принесло нам сильно больше вреда, чем пользы. У многих бакетов с включенным версионированием постепенно, с ростом числа объектов, начинали появляться объекты с неверным etag, с нулевым body, возникали ошибки при удалении объектов. На тот момент мы нашли несколько открытых репортов с похожими проблемами. Мы тщетно пытались воспроизвести эти проблемы, потратили много времени без результата. Suspend версионирования не решал проблему. В итоге "решением" было создание новых бакетов без версионирования и перенос объектов в них. Это довольно сильно ударило по нашей репутации и доставило неудобства нашим заказчикам, а мы потратили много ресурсов на помощь им.


    Холивары на тему числа реплик


    Как только заходят разговоры о числе реплик, так сразу реплика 2 — это идиотизм, наркомания и вообще такую конфигурацию скоро ждет участь Cloudmouse. Да, если у вас Ceph, то, возможно.


    В vxFlex OS фактор репликации 2 и это невозможно поменять. Единственное, необходимо иметь определенный объем места в резерве для восстановления данных в случае аварии. Этот объем должен быть равен дисковому объему, который может отказать единовременно. Если у вас потенциально вся стойка может быть отключена по питанию, то и резервировать вам нужно объем самой жирной стойки. Можно спорить об эффективности и надежности подобной схемы, но не зная точно, как это работает внутри, остаётся только довериться инженерам Dell EMC.


    Производительность


    Ещё одна холиварная тема. Что такое производительность распределенной системы хранения данных, да ещё и с репликацией по сети? Хороший вопрос. Понятно, что у таких систем большой оверхед. На мой взгляд, уровень производительности систем типа Ceph, vxFlex нужно измерять в отношении их показателей к показателям используемого оборудования. Важно понимать сколько производительности мы теряем из-за используемой прослойки. Эта метрика является и экономической в том числе, от нее зависит сколько нам нужно купить дисков и серверов для достижения нужных абсолютных значений.


    Письмо от 9 августа из ceph-devel рассылки: Вкратце, ребята получают утилизированные по CPU серверы (по два Xeon'а в сервере!) и смешные IOPS на All-NVMe кластере на Ceph 12.2.7 и bluestore.


    Статей, презентаций и дискуссий в листах рассылки валом, но "летит" Ceph всё ещё довольно низко. Несколько лет назад (во времена Hammer) мы тестировали различные решения для блочного стораджа и Ceph был у нас фаворитом, так как мы использовали его в качестве s3 и надеялись использовать как блочный. К сожалению, тогдашний ScaleIO растоптал Ceph RBD с поразительными результатами. Основная проблема Ceph, с которой мы столкнулись — это недоутилизированные диски и переутилизированный CPU. Я хорошо помню наши приседания с RDMA поверх InfiniBand, jemalloc и прочими оптимизациями. Да, если писать с 10-20 клиентов, то можно получить довольно приятные суммарные iops, но в отсутствии параллелизма клиентского io, Ceph совсем плох даже на быстрых дисках. vxFlex же умудряется хорошо утилизировать все диски и демонстрирует высокую производительность. Принципиально отличается ресурсопотребление — у Ceph высокий system time, у scaleio — io wait. Да, тогда не было bluestore, но судя по сообщениям в рассылке, он не серебряная пуля, и к тому же даже сейчас по числу баг-репортов, кажется, он лидер в трекере Ceph. Мы выбрали тогдашний ScaleIO не сомневаясь. Учитывая метрику, о которой говорилось в начале раздела, Ceph был бы экономически не выгоден даже с учетом стоимости лицензий Dell EMC.


    Кстати, если в кластере используются диски разной емкости, то в зависимости от их веса будут распределены PG. Это справедливое распределение с точки зрения объема (типа), но не справедливое по IO. Из-за меньшего числа PG на маленькие диски будет приходиться меньше IO, чем на большие при том, что у них обычно одинаковая производительность. Возможно, разумным будет завысить вес меньших дисков в начале и понижать его при приближении к nearfull. Так производительность кластера может быть более сбалансированной, но это не точно.


    В vxFlex нет понятия журнала или какого-то кеша или тиринга, вся запись сразу идёт на диски. Также нет процедуры предварительной настройки диска (смотрю в сторону ceph-volume), вы просто отдаёте ему блочное устройство в монопольное пользование, всё очень просто и удобно.


    Scrub


    Банально, согласен. Через это, наверное, прошел каждый кто живет с Ceph.


    Как только в вашем кластере появляется много данных и начинается активное их использование, не заметить влияние скраба довольно сложно. "Много данных" в моем понимании — это не какой-то общий объём в кластере, а заполненность используемых дисков. Например, если у вас диски по 2 TB и они заполнены на >50%, то у вас много данных в Ceph, даже если диска всего два. Мы в свое время очень настрадались от скраба и долго искали решение. Наш рецепт, который хорошо работает и по сей день.


    У vxFlex OS тоже есть такой механизм и по умолчанию он выключен, как и почти всё, что не является основной функциональностью. При включении можно задать всего один параметр — bandwidth в килобайтах. Меняется он на лету и позволяет подобрать оптимальное для вашего кластера значение. Мы оставили значение по умолчанию и пока всё хорошо, даже меняем периодически диски после сообщений об ошибках.


    Кстати, что интересно, vxFlex сам разруливает ситуации типа scrub-error. Ceph же с той же репликой 2 требует ручного вмешательства.


    Мониторинг


    Luminous — знаковый во многих смыслах релиз. В этой версии наконец появились родные средства мониторинга. С помощью встроенного MGR-плагина и официального шаблона для Zabbix можно в несколько действий получить базовый мониторинг с графиками и самыми важными алертами (3 штуки). Также есть плагины и для других систем. Это правда круто, мы пользуемся этим, но по-прежнему нужно писать свои скрипты и шаблоны для мониторинга IO по пулам, чтобы понимать когда озорничает gc, например. Отдельная тема — это мониторинг RGW инстансов.



    Без него я просто как слепой котенок. Его тоже нужно писать самому.
    А это фрагмент внешнего мониторинга S3, то как клиенты "видят" сервис:



    К самому Ceph этот мониторинг, естественно, не имеет отношения, но я очень рекомендую вам его завести, если такового ещё нет.


    Приятно отметить, что мониторы Сeph умеют в Graylog по протоколу GELF и мы этим пользуемся. Получаем алерты, например, когда OSD down, out, failed и другие. При настроенном парсинге сообщений можем анализировать логи за период времени, например, знать топ OSD по переходу в down за месяц, или строить график интенсивности скраббинга.



    Как-то было, что у нас OSD подвисали и не успевали отвечать на heartbeat и мониторы их отмечали как failed (см. скрин выше). Причина была в vm.zone_reclaim_mode=1 на двухсокетных серверах с NUMA.


    Вот вроде и похвалил Ceph. Правда c vxFlex это тоже можно. А ещё у него очень хороший дешбоард:



    Понятно какой клиент генерит нагрузку:



    Детализация IO по нодам и дискам:



    Обратите внимание как равномерно заполнены диски и как почти равномерно на них приходится IO, то чего так не хватает Ceph.


    Все крутилки под рукой:



    Про дешбоард Ceph, который подвезли в Luminous я и говорить не буду. Возможно в 2.0, что появился в Mimic будет интереснее, но я его ещё не смотрел.


    vxFlex тоже не идеален


    Когда кластер переходит в Degraded state например, когда меняется диск или перезагружается сервер нельзя создавать новые волюмы.


    Клиент vxFlex — модуль ядра и поддержка новых ядер от RH появляется с задержкой. Официальной поддержки 7.5 ещё нет, например. В Ceph клиенты для RBD и cephfs — модули апстримного ядра и с обновлением последнего они тоже обновляются.


    vxFlex беден на возможности в сравнении с Ceph. vxFlex — это только блочный сторадж, у которого нет, например, тиринга.


    Расти можно только до 16 PB, такое вот ещё ограничение есть. С Сeph бы хватило нервов до 2 PB вырасти…


    Заключение


    Часто слышу, что Ceph это академический проект с кучей нерешённых проблем, что это фреймворк без документации, что его бесплатность компенсируется его сложностью, что построить нормальный сторадж на Ceph — утопия. В целом я согласен со всем.


    Недавно на хабре была публикация о том, какой Ceph здоровский и что им может управлять "обычный админ". После этой статьи мой начальник подкалывал меня, мол "как так Саня, обычный админ может, а у тебя вечно R&D, вечно какие-то проблемы". Мне было немного обидно. Не знаю какие там у ребят "обычные админы", но Ceph постоянно нужно внимание довольно квалифицированного персонала, он как живой организм, который то и дело болеет.


    Если вы спросите меня использовать Ceph в 2k18 или нет, то я отвечу следующее. Если ваш сервис должен работать 24/7 и плановая или неплановая остановка недопустима (публичный S3, например, или EBS), а деградация в работе сервиса повлечет за собой негодование клиентов и наказание рублем, то использовать Ceph очень и очень опасно. Скорее всего, вы будете периодически страдать. А если к тому же нужна производительность — то это может быть экономически не выгодно. Если же вы строите хранилище для внутренних нужд проекта/компании и есть возможность проводить maintenance с остановкой сервиса или выкручивать на максимум backfilling на выходных, то c Ceph вы уживетесь и, возможно, он добавит некой пикантности в вашу жизнь.


    Почему же мы продолжаем использовать Ceph относясь к первой категории? Как говорится, "от ненависти до любви один шаг". Так и у меня с Ceph. Люблю потому что знаю. Слишком много пройдено с ним вместе, чтобы взять и дропнуть эти отношения и накопившуюся экспертизу, тем более сейчас, когда кажется, что все под контролем…
    Но булки расслаблять нельзя!
    Всем HEALTH_OK!

    КРОК Облачные сервисы

    160,00

    Облачная IaaS-платформа собственной разработки

    Поделиться публикацией
    Комментарии 54
      0

      Сейчас думаю о том чтобы разделить свой proxmox на ноды и как раз думаю о object storage чтобы можно было хранить там persistence volumes для k8s/docker + диски KVM и как раз хотел попробовать ceph но пока завис на локальном тесте внутри virtualbox.


      Какие есть еще s3/nfs совместимые хранилища?
      Ключевые требования


      • openSource
      • можно поднять на VPS
      • относительно надежное
      • GCE/AWS/Azure/OpenStack не предлагать =)

      Пока вот начал изучать ceph упомянули vxFlex и смотрю на Minio и StorageOS.

        0

        В своём коменте вы говорите о объектном сторе, nfs и судя по всему о блочном сторе тоже. Не совсем понятно, что именно вам нужно)?

          0

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


          Конечно можно поднять отдельно Swift и отдельно Cinder но это на крайний вариант.

            +1
            Ели нужен object store то тут не особо богатый выбор. Minio совсем примитивный, OpenStack Swift — ничего, но S3 реализованный сейчас в RGW богаче по возможностям. Плюс S3 более «стандартный» и популярный протокол чем Swift.
        0
        Да, в Ceph высокий порог вхождения по сравнению с enterprice решениями, больше параметров к настройке, меньше документации на более сложном языке. Но это же OpenSource. Проблемы разработчики потихоньку решают, хотя часто хочется плюнуть им в лицо. Мне кажется, не все так плохо, если юзать только LTS релизы и делать бэкапы :)
          0

          Ооо, вы хотите поговорить о LTS релизах)? А их больше нет. Теперь все релизы "стабильные")

            0

            Угу, особенно mimic :)
            Сидим на 12.2.4


            Я бы про бэкапы лучше поговорил)
            Интересует, как вы их реализовывали

              +1
              Я бы про бэкапы лучше поговорил)
              Интересует, как вы их реализовывали


              Это хороший и одновременно сложный вопрос. Чтобы бекапить например 500 Tb (что не так уж и много), для этого нужно иметь отдельную инфраструктуру приличных размеров. Стоимость этой инфраструктуры и ее обслуживания повлияет на стоимость конечных услуг. Помимо того, что бекапы — дорогое удовольствие, этот процесс оказывают негативное влияние на производительность сервиса. Решение на базе систем (типа Cеph) с сетевой репликацией (что само по себе дорого) — это что-то вроде серебряной пули. Предполагается, что трехкратная репликация поверх инфраструктуры, в которой все задублировано, достаточно надежное решение, чтобы не делать бекапы.
                0
                Т.е. нет никаких приложений, которые требуют своего бэкапа для сохранения некоего состояния. Например данные которые требуется хранить 2 года (ну или сколько там может потребоваться для аудита).
                  0
                  Нужно ли опять вспоминать про CloudMouse и отсутствие бекапов ceph?)
                  Бекапы нужны всегда, другой вопрос — как адекватно бекапить петабайты данных.

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

                  Получается, что вы не бекапите данные из ceph? :(
                    0
                    Как трехкратная репликация и дублирование помогут от незапланированного удаления бакета например?
                      0
                      От удаления бакета никакая инфраструктура не спасет, вы правы. Боле того, можно придумать еще десяток ситуаций, при которых можно потерять/удалить данные. Но, повторюсь, мы не делаем резервное копирование пользовательских данных в нашем S3. Причины я описал выше. Наиболее веская из них — экономика.
Боле того, я очень сомневаюсь, что кто-либо из публичных облачных провайдеров делает резервное копирование своих объектных хранилищ. У вас есть примеры таких? Может быть AWS или GCP например?
                      Я не пытаюсь поставить нас в один ряд с Amazon, нет, я лишь говорю о том, что при больших объемах все работает немного иначе. Ставка делается на надежность всего и вся, на жесткие регламенты и на максимальное снижение риска потери данных. При этом сохраняется приемлемая стоимость услуг.
              0
              Спасибо за увлекательное чтиво.
                –2
                До Jewel, процессы Ceph работали от root'а. В Jewel было решено, что они должны работать от пользователя 'ceph' и это требовало смены владельца у всех каталогов, которые используются сервисами Ceph.
Казалось бы, что такого?


                Я так понимаю это расчитано на тех, кто с Ceph не сталкивался и апгрейд не делал? Обычная структура у Ceph:
                /dev/sdh1 1.9T 1.3T 550G 71% /var/lib/ceph/osd/ceph-23

                Менял ли я права на весь диск? Нет конечно.

                Получается ~500 новых параметров за два года.


                Ну так давайте, сравните заодно что нового добавилось.
                ceph daemon mon.c01 config show | grep bluestore | wc -l
                105


                Или у вас уже в Хаммере bluestore был?

                И такое везде в статье.
                  +1
                  Прошу прощения но я не понял сути вашего вопроса?
                  +2
                  Долгих лет жизни вашему Сeph'у. (Ну и нашему).
                    0
                    Огромнейшее спасибо за статью! Давно ждал реальных отзывов, перечисления проблем от людей, использующих крупные инсталляции продолжительное время.

                    Подскажите, пожалуйста, есть ли обязательные для тюнинга параметры в Luminous, позволяющие повысить производительность так скажем «одиночных» (от одного клиента) операциях? Очень интересует Ваша практика. Столкнулись с низкой утилизацией SSD дисков обслуживающих OSD (Blustore), при том что нет никаких узких мест вроде CPU или сети. На просторах сети Интернет существует рекомендация размещать на одном диске несколько OSD, что можете сказать про данный приём?
                      0
                      Линейную (однопоточную) производительность ceph'а вы сильно не улучшите. Побенчмаркайте диски (в режиме файловой системы с fsync=1) и сравните с однопоточным бенчмарком ceph'а. Если они близки — это плохие SSD, если сильно различаются, то это либо ceph, либо сеть. С цефом фундаментально ничего не сделать, а с сетью можно попробовать cut-through свитчи.
                        0
                        Мы используем Ceph как S3 (RGW) поверх магнитных дисков. К сожалению дать совет по настройке Ceph для работы поверх SSD или NVMe не могу. Только если порекомендовать vxFlex (это юмор такой). Могу только судить о тенденции, которую я сейчас наблюдаю. Раньше запускать несколько OSD поверх одного диска категорически не рекомендовалось. Сейчас — 2-4 OSD на одном SSD встречаю часто и разработчики уже закрывают на это глаза. Это связано с тем, что за последние годы так никто и не раскусил в чем затык Ceph, а оборудование сильно шагнуло вперед. Поэтому вы можете попробовать, но думаю, что радикально ничего не поменяется.
                        +2
                        Я с интересом игрался с ceph'ом на ramdisk'ах. Надо сказать, «недоутилизация» рамдиска была потрясающая (500kIOPS с OSD до 15к), при сильной утилизации процессора.

                        Но с точки зрения планирования кластера это означает только «насыпьте нам ещё этих мягких французских ядер, да выпейте чаю».

                        То есть в качестве минуса я это могу засчитать только в вопросе добавленной latency, а в контексте планирования кластера — просто один из факторов для рассчёта стоимости.

                        Ceph будет всегда дороже, чем raw space. И если заказчик (internal или external) в этом месте возмущается, то либо надо вести разъяснительную работу, либо просто отказываться.

                        А сверху provisioned space ещё присыпается ядрами, и всех делов.

                        PS для защиты от логов лучшая мера — отдельный раздел под логи (в том же tmpfs, только ограниченный).
                          0
                          Спасибо за полезные комментарии.

                          PS для защиты от логов лучшая мера — отдельный раздел под логи (в том же tmpfs, только ограниченный).


                          Текущий "/" в tmpfs и ограничен до 6GB. Отдельный раздел в tmpfs избавит от заполнения "/" логами, но при заполнении этого выделенного раздела — OSD также будут останавливаться. Или чего-то не понял?
                          0
                          PNG размером почти 3 MB на КДПВ. Не надо так.
                            0
                            Вроде всего 1.9 )
                            Но спасибо за замечание, я учту это в следующий раз. Я не опытен в этом плане.
                            0
                            Спасибо за статью, есть теперь чем оперировать перед руководством)) Я сейчас как раз в процессе обновления с 0.94 до Luminous.

                            Не могли бы Вы только подсказать, вообще сильно ли может влиять разноразмерность дисков на хостах? Я искал бегло инфу на этот счет, но все равно однозначного негатива не находил, но и положительных отзывов с этим тоже. Мы как-то уперлись в такую ситуацию, что серверов под расширения еще нет, они ожидались из-за проблем в финансировании в течении полугода, а мы уже подходили к 80% наполнения всего массива. Из-за этого как не играй с весами, каждое утро я мог наблюдать near full разных OSD. В общем, решили добавлять диски в свободные слоты, но дисков того же объема у нас не оказалось, (тогда у нас было 9 хостов, в каждом по 14 дисков объемом в 900Гб) мы нашли у себя в запасах диски по 1.8Тб и поставили по два в каждый хост, прирост в 32Тб позволил нам дожить до поставок, но уже не рискнули их выводить. Спрашиваю я это к тому, что мне начало казаться, что массив стал более медленным, но я могу ошибаться, просто у нас как-то пока не доходит сделать нормальный мониторинг под все это дело.
                              0
                              Так на дисках 1.8ТБ вдвое больше pg хранится. А скорость у этих дисков не в два раза выше 0.9ТБ дисков. Поэтому скорость до pg, которые лежат на 1.8ТБ дисках стала меньше.
                                0
                                А не подскажите еще такой момент, общее число реплик на пул у нас стоит 3, минимально — 2. Чем будет плохо минимальное значение выставить в 1, оставив общее в 3?
                                  0

                                  Тем, что при min_size=1 операция записи "отпускается" после записи на один диск. Если в этот момент он накроется — то изменения потеряются.

                                    0
                                    Спасибо, в принципе это я и предполагал, но думал может есть какие-либо еще другие предостережения.
                                      0
                                      Не совсем так. size — это число копий, которые ceph запишет в синхронном режиме. min_size — это число копий, при котором разрешена запись и как следствие изменение primary копии. Если у вас 3,2, то ceph будет делать всегда реплику 3 в синхронном режиме. При наличие 2х копий он позволит записывать данные. При наличии только одной копии — данные перейдут в readonly пока не будет достигнут min_size.

                                      Конфигурация 3,1 опасна в таких ситуациях:

                                      epoch 10: osd.0, osd.1, osd.2
                                      epoch 11: osd.0 (1 and 2 down)
                                      epoch 12: - (osd.0 fails hard)
                                      epoch 13: osd.1 osd.2


                              0
                              Не сталкивался, но интересно было почитать о практике.
                                0
                                Является ли пост рекламой или нет EMC ScaleIO — выводы пусть сделает каждый лично, я не в праве судить автора.
                                Во времена, когда появился Linux, коммерческих *NIX было немало и они чувствовали себя не плохо. Но где они сейчас? Велика их доля рынка сейчас? Что там стоит на топ 500 кластеров? Много UNIX'ов? Так же обстоит дело и в мире SDS на данный момент, борьба.

                                По аналогии — Ceph это такой себе Linux начала 90х. Его можно критиковать, любить или не любить, но победит сильнейший, и кто сильнейший решит время.

                                По поводу работ в сторону улучшения производительности, загляните в этот документ (там как раз об этих проблемах и будущем стораджа).
                                www.openfabrics.org/images/2018workshop/presentations/206_HTang_AcceleratingCephRDMANVMe-oF.pdf

                                Преимущества Ceph на данный момент не в технической части (хотя тут можно навернуть очень не мало и не в пользу ScaleIO), а в ином, а именно:
                                ScaleIO с вашей точки зрения не плох, возможно я даже с вами соглашусь, но заглядывая в будущее долговременного хранения данных, для чего собственно SDS и используется в том числе (например для построения ScaleUP & ScaleOUT бэкап репозиториев на «десятилетия»), как мне выбрать решение EMC ScaleIO, если:
                                — Кодовая база проприетарная и контролируется одной компанией (как там дела с санкциями? а если решат нагнуть через EMC и запретить дистрибуцию ScaleIO, ведь могут? Можно сколько угодно спорить, но если будет необходимость — сделают)
                                — EMC в license agreement говорит о том, что софт поставляется AS-IS и как бы ответственности на нас (EMC) нет в случае чего, проблемы только ваши, но за деньги чем сможем, тем поможем… или не поможем… как повезет… но Вы нам все равно заплатите ;-)
                                — Данные записаные однажды — будут прочитаны всегда, Ceph на данный момент это полностью обеспечивает за счет перехода на Bluestore (были проблемы, но они общедоступные и известные, и Вы можете предлагать решения проблем, если у Вас есть компетенция). ScaleIO гарантирует это? Перед ответом, еще раз посмотрите на все пункты в EMC license agreement. Вам ничего не гарантируют.

                                Не вдаваясь в полемику и не разводя холиваров, я хотел бы услышать ответ, как мне в случае ScaleIO получить «гарантированную безопасность и сохранность данных на десятилетия»?
                                Я думаю ответ очевиден, попытки притянуть что либо за уши как аргументы, в ответе будет плохой затеей, потому что EMC license agreement сведет все аргументы на нет.

                                За текст и полезную информацию о Ceph большое спасибо.
                                Я сам искал некоторые параметры о которых Вы упоминаете в тексте и как раз нашел ответы в вашем тексте без обращения к исходникам.
                                  0
                                  В вашем комментарии есть три основные мысли:
                                  1. вам видится, что будущее за Ceph или за другими Open source решениями,
                                  2. использовать ScaleIO опасно т.к. вендор не дает никаких технических гарантий,
                                  3. использовать ScaleIO опасно по политическим причинам.

                                  1. Я тоже надеюсь, что так и будет.
                                  2. Хоть я и за Open source, но объективно Ceph тоже ничего вам не гарантирует. Даже при том, что в основе лежат математически доказанные алгоритмы — ничего не мешает потерять данные из-за банального бага. Такого как в версии 12.2.6, например. И с Open source версией, вам могут отказать в помощи даже за деньги.
                                  3. Политика. Я старался не допускать политических моментов в своей статье потому, что суть не них. Суть в том, что есть реальная система X (в данном случае ScaleIO) которая умет быть относительно быстрой, ресурсоэффективной, масштабируемой, простой и приятной в использовании. Эта система X демонстрирует нам успешное решение всех тех проблем которые перед собой ставит Ceph. Я лишь хотел показать, что хайповый Ceph не такой уж и крутой если сравнить с серьезным конкурентом. Я не хотел выделить ScaleIO на фоне Ceph. ScaleIO был нужен в этой статье как референсная система. Других к сожалению я не знаю.
                                  0
                                  И я правильно понимаю, что по части касающейся Ceph у вас не нет возражений?
                                    0
                                    1. Вы правы. Но мне видится не будущее не за конкретно Ceph, а за открытой моделью разработки — как я писал, выживет сильнейший и время покажет, кто им был рожден.
                                    2. Я не писал, что Ceph гарантирует, я написал:
                                    Ceph на данный момент это полностью обеспечивает за счет перехода на Bluestore

                                    По поводу версии 12.2.5/6 (EC баг) согласен, я как раз в этот момент наткнулся на другой баг в mimic, когда не было возможности добавить новые OSD в кластер (баг с epoch), (но тогда я нашел воркараунд, я понизил версию до Luminous, добавил все необходимое и поднял версию OSD до mimic без проблем… и пошел читать рассылку на предмет новых багов).
                                    Но заметьте, Sage Weil практически в первые сутки в рассылке признал багу и начался срочный багфикс, что заслуживает уважения в плане оперативности. Ссылка на письмо
                                    lists.ceph.com/pipermail/ceph-announce-ceph.com/2018-July/000126.html
                                    По поводу отказать в помощи — да, могут, но если Вы серьезный интегратор — то наверное у Вас должны быть в штате один или пару разработчиков, которые смогут «починить» и потом вернуть код в комьюнити. Разве не прекрасно? ScaleIO обеспечит Вам подобное? Ответ очевиден.

                                    3. Это не политика и не о ней было мной написано, это объективная реальность, хотите Вы того или нет, есть геополитика от которой может страдать бизнес (и Вы ничего не сможете сделать, пока Вы живете в «этой системе») и при выборе решения нужно об этом так же не забывать.

                                    То, что система Вам на данный период времени что-то «показывает и как Вам кажется гарантирует», не означает, что не произойдет как в Ceph версии 12.2.6, но только Вам возможно об этом просто не скажут и Вы потеряете данные. Но Вы ничего не сможете сделать, т.к. Вы подписали license agreement.

                                    По поводу ScaleIO и референсной системы, принято, если не рекламы ради, а сравнения для. Но не лукавьте, Вы знаете еще и GlusterFS (я не буду приводить ссылки на посты КРОКа и Ваш личный блог) и она в определенных моментах так же лучше Ceph, но под свои задачи.
                                      0
                                      У меня есть возражения только относительно объективности материала, недосказанности и отсутствия объяснений, что проблемы в некоторых моментах связаны с эволюционным развитием Ceph (у каждого свои детские проблемы и у Ceph это «запись», т.к. изначально не было Bluestore, была проблема двойной записи, была XFS и нужно было делать сложную проверку для обеспечении атомарности, на 1 IO если я не ошибаюсь, вроде бы был комментарий Sage Weil, что выполняется порядка 20к строк кода, но после стабилизации Bluestore, они начали активный рефакторинг кода OSD для «облегчения и ускорения») в результате которого читатели делают вывод — Ceph это поделка (а именно так и было, когда я дал ссылку на пост людям не работающим «плотно» с Ceph и задал после вопрос, что Вы после прочтения думаете о Ceph?).
                                        0
                                        в результате которого читатели делают вывод — Ceph это поделка


                                        Если не сложно, в чем конкретно я был не прав рассказывая про Ceph? В чем конкретно я исказил картину? Вы так пишите, как будто я наговариваю и порчу репутацию продукту.
                                        С другой стороны, вы своей «объективностью» не заслужено повышаете хайп вокруг этого продукта. На мой взгляд лучше пусть люди готовятся к худшему чем запускают Ceph в прод в розовых очках.
                                      0
                                      Я хотел бы сказать пару слов в пользу Ceph.
                                      На объективность не рассчитываю, это мое личное субъективное мнение (я не работал со ScaleIO кроме развернуть и поклацать, поэтому не буду о нем писать ни плохого, ни хорошего)
                                      А что умеет Ceph (может и правда поделка?):
                                      — иные архитектуры кроме x86_64? Да, умеет, у меня есть проект на ARM
                                      — умеет ли компрессию и дедупликацию? Да умеет, но не глобальную дедупликацию (есть сложности, но над этим уже «говорят»). Компрессия, компрессия есть в Ceph, а дедупликацию можно реализовать при помощи VDO на уровне OSD, кстати благодаря VDO можно и компрессию реализовать (разработка Permabit купленная RedHat)
                                      — erasure coding. Да умеет, при чем расширямость при помощи плагинов. Стандартный EC, ISA-L с оптимизацией от Intel, MSHEC от Fujitsu. Вы слышали про GPU-Offload Erasure Coding для Ceph? Если нет, почитайте вот тут cfwebprod.sandia.gov/cfdocs/CompResearch/docs/paper_ceph_gibraltar.pdf
                                      — чек суммы? Да, Bluestore для этого и создавали.
                                      — а протоколы какие умеет? S3, Swift, блочный доступ RBD, iSCSI HA (tcmu-runner), просто файловая система CephFS, NFS (Ganesha), Samba
                                      — а снапшоты, репликацию объектов? Да, для блочного RBD — это RBD mirror, S3 (начиная с mimic) — плагин для аплоада напрямую в Cloud
                                      — а RDMA? умеет async messenger (Mellanox)
                                      — замену дисков без ребилда OSD? Да. Миграция LVM, без остановки.
                                      — а тиринг? умеет при чем несколько видов.
                                      — а кэширование? Да, как через тиринг, так и на уровне OSD при помощи bcache, DM Writecache Target (Merged For Linux 4.18), LVM cache
                                      — а всякие DPDK/SPDK? Да, умеет
                                      — а авторепейр после SRUB'инга — Да, уже завезли настройки, завезут и правильную реализацию.
                                      — а сколько OSD может быть? Официльные проверенные и опубликованные тесты есть в дев рассылке Ceph — 10 000 OSD.
                                      — управление и менеджмент? Да, проект OpenATTIC стал Dashboard v2 для Ceph с mimic релиза.

                                      Это только то, что быстро пришло в голову за 15 минут написания, список можно продолжать и продолжать.

                                      А теперь задумайтесь уважаемый читатель, а что будет со всеми SDS, когда настанет момент и у Ceph появится глобальный дедуп, будет произведен рефакторинг кода OSD и будет все «быстро», появится поддержка NVMeOf с RDMA, Erasure Coding с GPU Offload?
                                      Вы думаете ждать долго и это не реально? Давайте подождем 3-4 года. Ceph молод, он еще ребенок, 10 лет всего.
                                      Как мне кажется, повторится история про UNIX'ы и Linux, но в мире SDS, выживет сильнейший, время нам даст ответы :)

                                      А что Ceph не умеет? Кофе готовить не умеет :)
                                        0
                                        Ага, может еще radosgw-admin перепишут заодно а то main на ~7k строк как то не очень выглядит: github.com/ceph/ceph/blob/81c6cac339a9783d2f5b1e6693e5c321f8a272a6/src/rgw/rgw_admin.cc

                                        Нет, ну серьезно, зачем нужны DPDK/SPDK, RDMA сейчас когда Ceph выедает два Xeon'а за милую душу в том числе и с этими примочками?

                                        Какой толк в замене диска без ребилда когда вопрос равномерности распределения данных решается присоской на python (mgr, balancer plugin) которая по ночам мигрирует PG?

                                        Это как установить спортивный обвес на жигу ничего не меняя под капотом.

                                        Спасибо большое за ваше мнение и полезнейший перечень возможностей Ceph, правда. Думаю многим будет интересно на него взглянуть. Но, мое мнение не пошатнулось ни на толику.

                                        Очень надеюсь, что все идеи и планы разработчиков постепенно будут реализованы.
                                          0
                                          Нет, ну серьезно, зачем нужны DPDK/SPDK, RDMA сейчас когда Ceph выедает два Xeon'а за милую душу в том числе и с этими примочками?

                                          Затем, чтобы не выедал, задел на будущее и это правильно. Особенно в рамках RDMA и NVMeOf
                                          Если Вы знакомы с DPDK/SPDK и понимаете, как работают данные технологии, то поймете к чему я веду.

                                          Какой тол в замене диска без ребилда когда вопрос равномерности распределения данных решается присоской на python(mgr, balancer plugin) которая по ночам мигрирует PG.

                                          Затем, что Вам гораздо быстрее будет линейно при помощи LVM перелить весь OSD без какого либа интружена в работу Ceph.
                                          Спасибо большое за ваше мнение и полезнейший перечень плюсов Ceph, правда. Думаю многим будет интересно на него взглянуть.

                                          И Вам большое спасибо за материал, я думаю, если будет у Вас желание, время и возможность, мы все таки реализуем совместно цикл объективных статей по теме Ceph.
                                        0

                                        Продолжайте грызть кактус… Это ещё TCO Ceph не сравнивали.


                                        Есть же Opensource LinStor, Libit SDS.
                                        Пишут австрийцы, там порядок и ордунг, лично знаком с парнями.
                                        Документацию правда писали пограмисты для пограмистов.
                                        Если нужны контакты, обращайтесь...


                                        Для Enterprise есть Open-E, Nexenta и много других штук.
                                        На европейских ИТ выставках сейчас куча вендоров SDS, каждый школьник пытается написать свой SDS.


                                        Пока Linux Foundation не возьмется за Ceph, и наведет порядок, возможно не смысла грызть кактус.

                                          0
                                          Отличный комментарий, «вкусный», спасибо.
                                          Вы упустили один момент, точнее множество моментов.
                                          Разберем по порядку.
                                          Продолжайте грызть кактус… Это ещё TCO Ceph не сравнивали.

                                          Про TCO Ceph, Вы производили калькуляцию или Вам «кто-то сказал»?
                                          Если считали, поделитесь пожалуйста выкладкой для объективности понимания, будет очень интересно ознакомиться, возможно я или ребята из RedHat используют неправильные формулы рассчета TCO/ROI. Подробнее можете ознакомиться по ссылке www.storagesavingscalculator.com

                                          Справделивости ради, чистый GlusterFS поверх ZFS приведденные Вами SDS поделит на ноль.
                                          Вот ролик канала "45 Drive" подверждающий мое утверждение.
                                          Есть же Opensource LinStor, Libit SDS.

                                          Для Enterprise есть Open-E, Nexenta и много других штук.
                                          На европейских ИТ выставках сейчас куча вендоров SDS, каждый школьник пытается написать свой SDS.

                                          Вам знакомо определие RAIN(redundant/reliable array of inexpensive/independent nodes)?
                                          Существуют SDS которые соответствуют определению RAIN например такие как Ceph, Gluster.
                                          А есть те SDS, которые Вы привели в пример:
                                          Nexenta это Ubuntu + ядро OpenSolaris + ZFS. Скажите, а как давно Nexenta научилась масштабироваться до n нод?
                                          Linstor (он же часть Linbit SDS) — DRBD + ZFS/LVM + Java. Серьезный конкурент Ceph? Без шуток?
                                          Про школьников Вы абсолютно правы, пытаются как писать SDS так и рассуждать о них.
                                          Пока Linux Foundation не возьмется за Ceph, и наведет порядок, возможно не смысла грызть кактус.

                                          Linux Foundation не разрабатывает Linux и не конкурирует с существующими Linux-компаниями, а способствует его развитию, концентрируя усилия в следующих областях:

                                          • Защита Linux путём поддержки его ключевых разработчиков и предоставления им юридических услуг. Linux Foundation распоряжается торговой маркой «Linux» и предоставляет разработчикам юридическую защиту интеллектуальной собственности при помощи таких проектов, как Open Source as Prior Art, Patent Commons Project, и спонсорства в Linux Legal Defense Fund.
                                          • Стандартизация Linux и улучшение его как платформы для разработчиков ПО. На это направлены проекты Linux Standard Base (LSB) и Linux Developer Network.
                                          • Предоставление нейтральной среды для сотрудничества и развития. Linux Foundation служит в качестве нейтрального представителя Linux, уполномоченного отвечать на агрессию со стороны конкурентов. Также Linux Foundation предоставляет пространство для обсуждения техническим сообществом, разработчиками приложений, промышленными заказчиками и конечными пользователями насущных вопросов, стоящих перед «экосистемой» Linux в таких областях как desktop interfaces, accessibility, printing, application packaging, и многих других.

                                          Хотелось бы понять, как по вашему мнению Linux Foundation наведет порядок в Ceph?

                                          Если Ваш комментарий был шутки ради, у Вас получилось.
                                            0
                                            Немного не понятен ваш пафос. В этом комментарии вы ставите Ceph на вершину всего просто потому, что он соответствует RAIN. Если не соответствует RAIN то и в руки брать не нужно? Я не топлю за Linbit SDS, Nexenta, я с ними не работал но допускаю, что они способны справляться с задачами которые перед собой ставят. И то, что они имеют отличную от Ceph (not RAIN) архитектуру не делает их автоматически плохим вариантом.

                                            Опять же, вы упоминаете Gluster. Если я правильно понимаю архитектуру Gluster то в случае репликейтед-волюмов — волюм будет состоят из жестко определенного набора репликейтед групп. Там есть еще нюансы но суть в том, что это такие же замкнутые в себе репликейтед группы как и несколько DRBD-групп в случае с Linbit SDS. Но тут вы топите за Gl.

                                            Ваши доводы выглядят как сугубо теоретические. Поделитесь пожалуйста своим практическим опытом эксплуатации Ceph. Какие возможности Ceph вы используете и как они вам помогают экономить деньги/снижать TCO?
                                              0

                                              "Про TCO Ceph, Вы производили калькуляцию или Вам «кто-то сказал»? "
                                              Таки що, я всё проспал? Ceph начал поддерживать Global Deduplication and Compression?
                                              Red hat теперь пытается продать VDO, опоздавший лет на 5, как magic feature?


                                              " GlusterFS поверх ZFS приведденные Вами SDS поделит на ноль."


                                              Какая будет латентность у GlusterFS поверх ZFS? В часах или в минутах?


                                              Надо Nutanix в ветку позвать, чую веселье начинается :)

                                                0
                                                Таки що, я всё проспал?

                                                Возможно.
                                                Ceph начал поддерживать Global Deduplication and Compression?

                                                Откуда дровишки? Я разве писал про Global? Если да, прошу процитировать.
                                                Red hat теперь пытается продать VDO, опоздавший лет на 5, как magic feature?

                                                Берите бесплатно, никто не продает github.com/dm-vdo
                                                Более того, если Вы на RBD натяните VDO — Вы получите глобал инлайн дедуп, правда в пределах одной ноды. Не постпроцессинг, а инлайн — это важно.
                                                Какая будет латентность у GlusterFS поверх ZFS? В часах или в минутах?

                                                В световых годах.
                                                В своем комментарии Вы привели решения на базе ZFS, я привел как пример RAIN реализацию GlusterFS + ZFS
                                                Сходите посмотрите к ребятам на 45Drive, вот тесты GlusterFS + ZFS с ответом на Ваш вопрос
                                                Надо Nutanix в ветку позвать, чую веселье начинается :)

                                                Зовите, мне было бы интересно посмотреть их паблик тесты и получение их официального согласия на тестирование и публикацию результатов на хабре.
                                                  0

                                                  Коммерческие SDS дистрибутивы уже 3-4 года как умеют Global Dedup & Compression. Только Huawei ещё не умеет...


                                                  "Более того, если Вы на RBD натяните VDO — Вы получите глобал инлайн дедуп, правда в пределах одной ноды." >

                                                  Супер актуально иметь дедуп и компрессию в пределах одной ноды )))


                                                  В TCO нужно считать расходы на красноглазиков, которые будут поддерживать Ceph.
                                                  Если предоставление ИТ услуг не профильный бизнес, возможно нет смысла разворачивать систему с десятками Urgent и High тикетов месяцами висящих в баг трекере. Забавно выглядят российские импортозаместители с 1,5-2,5 человечками в штате решившие "все баги Ceph".


                                                  Я совсем не против Ceph, но он далеко не killer всех SDS.
                                                  Пока Ceph далеко до законченного продукта. Пока палки, изолента, и г@вно, с вкраплениями печенья и шоколада.


                                                  Бизнес голосует рублем за Storage as a Service.
                                                  С умилением и слезами читал, как Asbis продал в ВТБ INFINIDAT.
                                                  CIO просто решает задачу, платит за использование дискового пространства, и не любит голову оптимизацией и вечным деплойментом Ceph.
                                                  Аплодирую сейлам INFINIDAT стоя на табуретке )

                                                    0
                                                    Коммерческие SDS дистрибутивы уже 3-4 года как умеют Global Dedup & Compression. Только Huawei ещё не умеет...

                                                    Можно пожалуйста список и чтобы это был не постпроцессинг, а инлайн как в приведенном мной примере и скорость доступа была приемлемой.
                                                    Супер актуально иметь дедуп и компрессию в пределах одной ноды )))

                                                    Мне кажется Вы не прочли фразу «правда в пределах одной ноды», я не утверждал, что это правильно, я привел пример — что это возможно.
                                                    Я совсем не против Ceph, но он далеко не killer всех SDS.

                                                    Можно пожалуйста цитату, где я утверждал, что Ceph киллер всех SDS? Ну так, чтобы Вы не казались голословным.
                                                    Пока Ceph далеко до законченного продукта. Пока палки, изолента, и г@вно, с вкраплениями печенья и шоколада.

                                                    Расскажите об этом ChineMobile, они то про печенье и шоколад не в курсе, им бы пригодилась Ваша экспертная оценка.
                                                    Я же писал следующее:
                                                    Давайте подождем 3-4 года. Ceph молод, он еще ребенок, 10 лет всего.

                                                    Извините, но «переливать из пустого в порожнее» и отвечать на субъективные рассуждения о том, что такое хорошо и плохо, я больше не буду, разговор в треде об SDS, а не о Ваших слезах и умилении.
                                                    Если есть аргументированные комментарии с предметом разговора — welcome :)
                                            0
                                            Немного не понятен ваш пафос. В этом комментарии вы ставите Ceph на вершину всего просто потому, что он соответствует RAIN. Если не соответствует RAIN то и в руки брать не нужно? Я не топлю за Linbit SDS, Nexenta, я с ними не работал но допускаю, что они способны справляться с задачами которые перед собой ставят. И то, что они имеют отличную от Ceph (not RAIN) архитектуру не делает их автоматически плохим вариантом.

                                            Будьте добры, укажите цитатой, где я утверждаю, что они плохие и где Вы увидели пафос?
                                            Меня возмутило сравнение «теплого» и «мягкого».
                                            Ceph я не ставлю на вершину, а лишь отметил абсурдность сравнения, т.к. данные решения находятся в разных «весовых категориях».
                                            Опять же, вы упоминаете Gluster. Если я правильно понимаю архитектуру Gluster то в случае репликейтед-волюмов — волюм будет состоят из жестко определенного набора репликейтед групп. Там есть еще нюансы но суть в том, что это такие же замкнутые в себе репликейтед группы как и несколько DRBD-групп в случае с Linbit SDS. Но тут вы топите за Gl.

                                            Вы все верно понимаете.
                                            Добавьте к решению которое есть в Вашем блоге (про GlusterFS и Erasure Coding) как андерлайн ФС — ZFS и сравните ROI/TCO относительно Linbit (DRBD) и Вам все станет очевидно. Можете не сранивать, если DRBD научился Erasure Coding… но ведь он не научился?
                                            Ссылка на Вашу статью про GlusterFS и Erasure Coding habr.com/company/croccloudteam/blog/417475
                                            Ваши доводы выглядят как сугубо теоретические.

                                            Каждый имеет право на выводы и доводы, но субъективная оценка не имеет ничего общего с объективностью.
                                            Какие возможности Ceph вы используете и как они вам помогают экономить деньги/снижать TCO?

                                            Продакшены (их много и не только для личного пользования, просто проекты однотипные) под проекты, Ceph 100Тб RAW + bcache (SSD) + tcmu-runner (кстати, я принимаю участие в отладке проекта, так же активным участником этого проекта является ChineMobile, т.к. у них 70% инфры (из дев рассылки узнал) под ESXi и они активные «пользователи» Ceph, если нужна будет помощь с tcmu-runner, welcome) для экспорта iSCSI в ESXi. Все OSD состоят из LVM которым обернуты HDD и SSD для возможности смены любого «слоя» на другой носитель, это очень удобно когда нужно посмотреть под живой нагрузкой поведение/производительность других HDD/SSD или их влияние в следствии «перекоса».
                                            Все это работает в ВМках, с пробросом HBA контроллеров, сеть отдается в ВМ через SR-IOV, ВМ привязаны к CPU и NUMA на которой висят HBA и Network.
                                            В «краш-тестах» на блэкаут — умерло две Intel SSD и причина была в браке, а Ceph прекрасно пережил это отребилдившись после замены.
                                            На данный момент все висит на UPS, с автоматическим выключение/выключением инфры при потере внешнего питания.
                                            Внутри сферы все балансируется через DRS (через tcmu-runner отдается порядка 8 лунов в гипервизор).
                                            Все луны благодаря tcmu-runner «делятся поровну» между iSCSI Gateway, а в случае отказа или необходимости перезагрузки GW — происходит HA переключение и другие GW забирают на себя эти луны. Еще раз повторюсь, таких проектов много, они однотипные и описывать их все не вижу смысла. ОС — CentOS, Ceph Luminous 12.2.7, tcmu-runner 1.4RC1, Kernel 4.17

                                            Бэкап — проект на SoC ARM'ах от Marvell, 48 OSD, каждая объемом 1Тб, цена одного OSD — 120$. ОС- Ubuntu, Ceph Luminous 12.2.4.

                                            Относительно того, что используем — все зависит от ворклоадов и требований, Вы ведь сами понимаете, что в семье не без греха, так и Ceph имеет функционал, который не можеть быть серебряной пулей для всех задач, поэтому решение зависит от ТЗ.
                                            Например Ceph WB Cache тиринг мало пригоден для интесив ворклоада, а вот для бэкапов или WORM сценариев — очень даже, т.к. WB тир на SSD позволяют достаточно быстро «всасывать», а в случае чтения достаточно быстро отдавать, т.к. Ceph на чтение отдает 1 в 1.
                                            Относительно TCO, например, если брать во внимание определение RAIN (дешево много, сломалось выкинули) и WORM сценарий для бэкапов, посчитайте стоимость любой ASRock Server Motherboard где есть 8 SATA и хотя бы один PCI-E для сетки, 4 плашки памяти для удовлетворения требований Ceph по RAM, HDD интересующего Вас объема. CPU с высокой частотой и не больше 8-12 ядер. HDD естественно не «Green» серии.
                                            И Вы будете приятно удивлены, у меня подобное решение на ASRock работает уже второй год.
                                            Можно долго еще писать о моих якобы теоретических по вашему мнению знаниях, но вернусь к началу своего комментария, я за объективность и сравнение игроков в одинаковых весовых категориях, если я Вас как-то задел, обидел или еще как-то задел — извините, это не было моей задачей.
                                              0
                                              Будьте добры, укажите цитатой, где я утверждаю, что они плохие и где Вы увидели пафос?
                                              Вот тут я увидел пафос:
                                              Linstor (он же часть Linbit SDS) — DRBD + ZFS/LVM + Java. Серьезный конкурент Ceph? Без шуток?
                                              Вы сравниваете системы в контексте их ТТХ а я в контексте задач которые они могут решать. И ceph и Linstor успешно используются в связке с k8s, например и как следствие они являются конкурентами в этом поле. Есть десятки задач, где не нужно уметь много всего а нужно хорошо уметь что-то одно. Наш пример с ScaleIO снова показателен. Ну не умеет Ceph в быстрый блочный сторадж, и не помогает ему пока ничего.
                                              Можете не сранивать, если DRBD научился Erasure Coding… но ведь он не научился?
                                              На мой взгляд некорректно сравнивать EC и репликацию в отрыве от задачи.

                                              Спасибо, что поделились опытом. Часто применяли в своих проектах DPDK/SPDK или RDMA?
                                                0
                                                Спасибо за комментарий, у меня не было пафоса, а это был вопрос к аудитории. Без пафоса.
                                                Вы правильно заметили, я сравниваю SDS, а Вы говорите о контексте задач, но не озвучиваете задачи (рассуждения о «масле масляном» — не работает, я везде писал, что у каждого решения свои задачи).
                                                Почитайте пост по ссылке и ответьте самому себе, в DRBD уже все хорошо с этим?https://habr.com/post/219295/
                                                Ну не умеет Ceph в быстрый блочный сторадж, и не помогает ему пока ничего.

                                                Правда? У Вас не работает или ни у кого не работет? А что такое быстро? У Вас есть ответ?
                                                Для меня например быстро это работа Intel Optane p4800x через NVMeOf over RDMA через 100G аплинк. С последних тестов этих 3х карт на удаленном хосте я снял 1,5 миллиона IO'псов, при чем на запись и уперся в CPU. (CentOS, NVMeOF, SPDK, FIO)
                                                Но скажите, Вы часто встречаете ворклоады где необходимы подобные скорости?
                                                Назовите мне 2-3 реальных ворклоада кроме требовательных процессингов типа CME GLOBEX или NYSE.
                                                Единственное где это реально сейчас нужно это постпродакшен для 4k и 8k видео, но там нужен срупут, а не IO'псы.
                                                Я Вам могу приготовить очень быстрый storage, но вот вопрос, а у Вас есть такие задачи которые смогут утилизировать этот storage или все ради «померяться попугаями» и сказать «мы смогли»?
                                                По поводу Ceph не может быть быстрым, ознакомьтесь со статьей на сайте Intel (Вы же к задаче привязываете? Давайте на задаче разбирать, как скажете...)
                                                software.intel.com/en-us/articles/using-intel-optane-technology-with-ceph-to-build-high-performance-oltp-solutions
                                                На мой взгляд некорректно сравнивать EC и репликацию в отрыве от задачи.

                                                Почему нельзя? У нас есть поставленная задача? Нет задачи, мы сравниваем возможности и функциональность SDS, и изначально, я отвечал на комментарий хабраюзера, который пришел и заявил, у Вас все плохо, я знаю как хорошо, а потом Вы ухватились за мой ответ ему и задали вопросы, будьте добры — не рвите контекст.
                                                Или этому хабраюзеру было можно сравнить «воооообщем», а ко мне возник вопрос об «отрыве от какой-то задачи»? Двойные стандарты однако :)
                                                Спасибо, что поделились опытом.

                                                Всегда пожалуйста, мне приятно, что Вы сказали спасибо :) Значит писал не зря.
                                                Часто применяли в своих проектах DPDK/SPDK или RDMA?

                                                В Ceph только для кластерной подсети и если это имеет смысл (OSD NVMe/SSD), для проектов с NVMeOf (SPDK/RDMA) постоянно.
                                                Пока не закончат рефакторинг кода OSD и не произведут оптимизации, выигрыша не много от RDMA, но в будущем — возможно будет существенный, время покажет, я думаю в течении 2х лет это будет реализовано. Был бы Вангой — сказал точнее.
                                                В рамках KVM — DPDK для Linux Guest там, где это целесообразно и необходимо.
                                              0
                                              Отличная статья, согласен с каждым словом!

                                              Хочу еще добавить, что при возникновении чрезвычайных проблем (у нас была полная остановка кластера с невозможностью запуска, все OSD умирали от OOM при старте, это при 512 ГБ памяти на каждом хосте-то), придется выложить нереальную кучу бабок Редхату. И еще ждать пока они соизволять обратить на вас внимание. В итоге оказалось, что это был баг и нужно было пофиксить всего несколько строк кода.
                                                0
                                                Будьте добры, уточните версию Ceph на которой подобное происходило?
                                                У меня лично такое было 2 раза в жизни, был действительно баг в Hammer или Jewel (не помню релиз, но пофиксили очень быстро), второй раз на Luminous, когда у меня «залипла консоль» и в конфиг добавились пару лишних символов (правил конфиг, выделение памяти для Bluestore), по итогу для Bluestore выделялось в конфиге не 1Гб, а 100Гб и естественно OOM выносил OSD, заметил я это через час после применения конфига.
                                                Вы проводили профайлинг памяти и выясняли где была утечка прежде чем обращаться к комьюнити?
                                                Подобные вещи обычно случаются когда обновляются на master ветку в надежде, что она решит их проблему, но получается наоборот и это нормально когда в мастер ветке возникают подобные вещи, т.к. это dev ветка.
                                                То что Вы описали очень похоже на историю CloudMouse :)
                                                  0
                                                  У нас был 10.2.5. На мастер не обновляли. Утечку памяти не смотрели. Проблема была в функции load_pgs() при старте OSD: при определенном стечении обстоятельств эта функция уходила в бесконечный цикл. Уже не помню подробностей, но наш кластер лежал больше месяца. Ездили в датацентр и вставляли 1.5 ТБ оперативы в хосты — не помогало.
                                                    0
                                                    Да, была такая проблема.
                                                    Я ее воспроизводил, на сколько правильно помню, возникала проблема из-за слишком большого количества PG на OSD, а когда был EC и неправильное количество OSD/PG, то вообще все очень быстро и лавинообразно «возникало», при заполнении кластера кажется при 40-50%.
                                                    А конфигурацию не помните? Типы пулов, количество PG на OSD?
                                                0
                                                • Интересно посмотреть сравнение Gluster vs Ceph. Тем более, что оба поддерживаются (*** на определенном уровне) RedHat в своих энтерпрайз решениях
                                                • Есть еще StorPool. Но… Лучше забудьте о нем.
                                                • Там еще drbd выше упоминали. Но это вообще из другой оперы и я бы не хотел тащить его как нижележащий слой относительно чего угодно большого и высоконагруженного
                                                • Nutanix — это действительно круто. Но это не про storage как таковой, а скорее про HCI

                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                Самое читаемое