Открыть список
Как стать автором
Обновить

Комментарии 55

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


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


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

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

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

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


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

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

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

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


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

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


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

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

Получается, что вы не бекапите данные из ceph? :(
Как трехкратная репликация и дублирование помогут от незапланированного удаления бакета например?
От удаления бакета никакая инфраструктура не спасет, вы правы. Боле того, можно придумать еще десяток ситуаций, при которых можно потерять/удалить данные. Но, повторюсь, мы не делаем резервное копирование пользовательских данных в нашем S3. Причины я описал выше. Наиболее веская из них — экономика.
Боле того, я очень сомневаюсь, что кто-либо из публичных облачных провайдеров делает резервное копирование своих объектных хранилищ. У вас есть примеры таких? Может быть AWS или GCP например?
Я не пытаюсь поставить нас в один ряд с Amazon, нет, я лишь говорю о том, что при больших объемах все работает немного иначе. Ставка делается на надежность всего и вся, на жесткие регламенты и на максимальное снижение риска потери данных. При этом сохраняется приемлемая стоимость услуг.
Спасибо за увлекательное чтиво.
До 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 был?

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

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

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

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

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

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

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

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


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

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

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

Спасибо, в принципе это я и предполагал, но думал может есть какие-либо еще другие предостережения.
Не совсем так. 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


Не сталкивался, но интересно было почитать о практике.
Является ли пост рекламой или нет 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 большое спасибо.
Я сам искал некоторые параметры о которых Вы упоминаете в тексте и как раз нашел ответы в вашем тексте без обращения к исходникам.
В вашем комментарии есть три основные мысли:
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 был нужен в этой статье как референсная система. Других к сожалению я не знаю.
И я правильно понимаю, что по части касающейся Ceph у вас не нет возражений?
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, но под свои задачи.
У меня есть возражения только относительно объективности материала, недосказанности и отсутствия объяснений, что проблемы в некоторых моментах связаны с эволюционным развитием Ceph (у каждого свои детские проблемы и у Ceph это «запись», т.к. изначально не было Bluestore, была проблема двойной записи, была XFS и нужно было делать сложную проверку для обеспечении атомарности, на 1 IO если я не ошибаюсь, вроде бы был комментарий Sage Weil, что выполняется порядка 20к строк кода, но после стабилизации Bluestore, они начали активный рефакторинг кода OSD для «облегчения и ускорения») в результате которого читатели делают вывод — Ceph это поделка (а именно так и было, когда я дал ссылку на пост людям не работающим «плотно» с Ceph и задал после вопрос, что Вы после прочтения думаете о Ceph?).
в результате которого читатели делают вывод — Ceph это поделка


Если не сложно, в чем конкретно я был не прав рассказывая про Ceph? В чем конкретно я исказил картину? Вы так пишите, как будто я наговариваю и порчу репутацию продукту.
С другой стороны, вы своей «объективностью» не заслужено повышаете хайп вокруг этого продукта. На мой взгляд лучше пусть люди готовятся к худшему чем запускают Ceph в прод в розовых очках.
Я хотел бы сказать пару слов в пользу 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 не умеет? Кофе готовить не умеет :)
Ага, может еще 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, правда. Думаю многим будет интересно на него взглянуть. Но, мое мнение не пошатнулось ни на толику.

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

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

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

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

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

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


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


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


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

Отличный комментарий, «вкусный», спасибо.
Вы упустили один момент, точнее множество моментов.
Разберем по порядку.
Продолжайте грызть кактус… Это ещё 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?

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

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

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

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


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


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


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

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

Возможно.
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 в ветку позвать, чую веселье начинается :)

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

Коммерческие 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 стоя на табуретке )

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

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

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

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

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

Извините, но «переливать из пустого в порожнее» и отвечать на субъективные рассуждения о том, что такое хорошо и плохо, я больше не буду, разговор в треде об SDS, а не о Ваших слезах и умилении.
Если есть аргументированные комментарии с предметом разговора — welcome :)
Немного не понятен ваш пафос. В этом комментарии вы ставите 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 работает уже второй год.
Можно долго еще писать о моих якобы теоретических по вашему мнению знаниях, но вернусь к началу своего комментария, я за объективность и сравнение игроков в одинаковых весовых категориях, если я Вас как-то задел, обидел или еще как-то задел — извините, это не было моей задачей.
Будьте добры, укажите цитатой, где я утверждаю, что они плохие и где Вы увидели пафос?
Вот тут я увидел пафос:
Linstor (он же часть Linbit SDS) — DRBD + ZFS/LVM + Java. Серьезный конкурент Ceph? Без шуток?
Вы сравниваете системы в контексте их ТТХ а я в контексте задач которые они могут решать. И ceph и Linstor успешно используются в связке с k8s, например и как следствие они являются конкурентами в этом поле. Есть десятки задач, где не нужно уметь много всего а нужно хорошо уметь что-то одно. Наш пример с ScaleIO снова показателен. Ну не умеет Ceph в быстрый блочный сторадж, и не помогает ему пока ничего.
Можете не сранивать, если DRBD научился Erasure Coding… но ведь он не научился?
На мой взгляд некорректно сравнивать EC и репликацию в отрыве от задачи.

Спасибо, что поделились опытом. Часто применяли в своих проектах DPDK/SPDK или RDMA?
Спасибо за комментарий, у меня не было пафоса, а это был вопрос к аудитории. Без пафоса.
Вы правильно заметили, я сравниваю 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 там, где это целесообразно и необходимо.
Отличная статья, согласен с каждым словом!

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