Комментарии 28
Мы продолжаем развивать своё хранилище, и в планах много интересных оптимизаций и новых фич,
А где посмотреть ? :)
Во времена до своего решения случайно не пробовали seaweedfs использовать ?
Пока только в нашей внутренней джире :)
С SeaweedFS не было опыта работы, но навскидку показалось что это недостаточно крупный и развитый проект, как например тот же Ceph RGW, есть много мелких проблем. А ещё это проект одного человека, что на наших масштабах выглядит как большой риск. Но тем не менее, возможно это хорошая альтернатива MinIO, выглядит перспективно
Спасибо за статью. Не так давно читал тут про реализацию s3 хранилища у яндекс. И тут возник вопрос: в не смотрели в сторону партнерство с ними в этой части? Или может быть совместной разработки и опенсорса/продажи решения? С моей колокольни это могло бы дать положительный эффект для всех
У яндекса это коммерческое решение, которое они предоставляют в рамках облака, так что, боюсь, тут сложно будет :)
У нас были размышления про опенсорс, но тут тоже всё не так просто, нужна заинтересованность со стороны бизнеса выделять на это ресурсы, да и понимание, что вокруг этого продукта можно построить комьюнити, то есть нужна целевая аудитория крупных компаний, которые уже переросли открытые решения, но ещё не имеют своё. Так что вопросов много. Но со стороны инженера, конечно, было бы круто вынести такой продукт в опенсорс, я тут полностью согласен)
А почему MinIO не подходит для этой задачи? Почему его ограничили десятками ТБ и сотнями RPS?
MinIO дисковую подсистему сильно грузит, даже мы с этим столкнулись, так у нас масштабы совсем не те.
Сильно -- это насколько? При каких соотношениях диски/сервера?
Мы несколько кластеров эксплуатируем. Самый большой на 5Пб. Показывает себя в нагрузке лучше цефов.
В силу специфики задач и ПО необходимо пару раз в месяц уметь быстро заливать порядка 2миллионов мелких файлов (10-100кб). У нескольких клиентов столкнулись с существенным провалом по производительности после определённого количества файлов. Поиск по интернетам показал, что не мы одни такие. Тредов обсуждения на гитхабе, медиуме и прочих реддитах попадается довольно много.
в 21 году разработчики minIO даже оптимизировали ряд моментов.
Характеристики железа сейчас уже не подскажу, т.к. зоопарк железа у клиентов очень разнообразный. Размер кластеров от 100Гб до 2Пб.
Приведу сравнения нагрузочного тестирования между minio и seaweedfs. Тесты проводились с помощью бенча от minIO на одних и тех же машинах.
Всё что нашлось
HDD minio, 8 потоков, файлы 0-10 мб
Mixed operations.
Operation: DELETE, 10%, Concurrency: 8, Ran 9m59s.
Throughput:17.30 obj/s
Operation: GET, 45%, Concurrency: 8, Ran 9m59s.
Throughput:138.40 MiB/s, 77.86 obj/s
Operation: PUT, 15%, Concurrency: 8, Ran 9m59s.
Throughput:46.42 MiB/s, 25.97 obj/s
Operation: STAT, 30%, Concurrency: 8, Ran 9m59s.
Throughput:51.93 obj/s
Cluster Total: 184.63 MiB/s, 172.90 obj/s over 10m0s.
HDD seaweedfs, 8 потоков, файлы 0-10 мб
Mixed operations.
Operation: DELETE, 10%, Concurrency: 8, Ran 9m59s.
Throughput:31.44 obj/s
Operation: GET, 45%, Concurrency: 8, Ran 9m59s.
Throughput:259.61 MiB/s, 141.50 obj/s
Operation: PUT, 15%, Concurrency: 8, Ran 9m59s.
Throughput:85.16 MiB/s, 47.16 obj/s
Operation: STAT, 30%, Concurrency: 8, Ran 9m59s.
Throughput:94.34 obj/s
Cluster Total: 344.75 MiB/s, 314.41 obj/s over 10m0s.
SSD seaweedfs, 8 потоков, файлы 0-10 мб
Cluster Total: 685.71 MiB/s, 636.67 obj/s over 10m0s.
SSD minio, 8 потоков, файлы 0-10 мб
Cluster Total: 264.93 MiB/s, 249.82 obj/s over 10m0s.
Где то еще есть метрики из прометеуса, но нужно искать.
Т.е. при прочих равных разница по скорости между решениями в 2-3 раза
Ну тут есть еще часть: так исторически сложилось. Хорошо, что современный MinIO умеет в ребалансировку (честно сказать, не проверял на больших объемах), но когда начинали строить архитектуру достаточно быстро оказались в ситуации, когда MinIO размножался добавлением маленьких MinIO, что было фатально несовместимо с построением централизованной инфраструктуры управления кластером. А такая задача по сути и решалась. Решал эту задачу вполне только Ceph. По ходу дела выяснилось, что если его научиться готовить, то он закрывает более-менее все вопросы:
горизонтальное масштабирование
равномерное распределение нагрузки
(почти)все требуемые домены отказа
а еще имеет ветку развития - блочка (RBD)
Из вопросов к нему было слабое observabiltiy в смысле работы с S3, но с этим и у MinIO было никак.
Для чего вам нужен протокол S3? Почему не монтируете ceph напрямую? Рассматривали ли вариант GlusterFS или аналогов?
Ceph напрямую это как, Librados? Если вы работаете не в CERN, которые вроде как справлялись с этим, и у вас задачи мира бизнеса, работать в терминах нетипизированных объектов небольшого размера будет затруднительно.
В смысле? Просто монтируете как файловую систему со всеми POSIX плюшками: атомными операциями, локами, правами и пр. Зачем для доступа к неструктурированным данным городить S3? Тем более это - нестандартный протокол и вне контекста AWS малополезен.
Даже если вы свою файловую систему написали, то всё равно разумнее к ней fuse драйвер сделать, чем вкорячивать непонятный API.
Вполне допускаю, что вам зачем-то необходимо S3 хранилще. Но из данной статьи совершенно непонятно - зачем.
То есть сама идея обращаться к собственному хранилищу через S3 вызывает вопросы.
Отдельно порадовала невозможно сделать листинг из 25.000.000 объектов. Ну попробуйте хотя бы в RamFS такой фокус провернуть. Если у вас часто возникает необходимость делать листинг по всему хранилищу, то что-то у вас не так с алгоритмами.
Про гластер так ничего и не написали.
Кажется, у вас изначально неверные представления о Ceph: Ceph - это архитектурно совсем не CephFS, это RADOS:
RADOS как объектный протокол, конечно, крут и решает очень много задачек для распределенных систем (атомарность, защита от перезаписи, ...) но как стандарт он примерно никем не поддерживается, поэтому надо че-то изобретать поверх.
Дальше вы можете его использовать как CephFS (определенно не самое производительное решение уже на сотнях тысяч объектов), или использовать какие-то решения поверх LibRADOS (или идущие из коробки демоны, или что-то свое), эти решения существенно производительнее для большого числа объектов, ну или для объектов большого размера, типа каких-нибудь бекапов.
Делать свою файловую систему даже и не пытались, и для наших задач POSIX совместимая файловая система явно бессмысленный оверхед. При этом S3 хранилище является сейчас стандартом для большей части как коммерческих, так и OpenSource решений (PostgreSQL, Clickhouse, Prometheus, Gitlab, Allure TestOps, ...), что позволяет строить систему хранения компании на единой платформе, а кроме того эффективно контролировать по стандартным дашбордам профили нагрузки на хранилище.
Ну и раз уж мы используем единую платформу хранения, то начиная с определенных масштабов начинаем сталкиваться с тем, что некоторые системы (Prometheus для семплирования данных, Allure или Gitlab для фоновых индексаций или очистки артефактов) дают нагрузку, которую не переварит никакой FUSE, и даже с трудом переваривает RGW шлюз к Ceph, хотя в версии Reef они провели много крутых оптимизаций, и там, кажется, есть шансы все-таки продержаться на нативном решении.
Ну и отвечая на вопрос - GlusterFS, SeaweedFS и прочие не смотрели, по ряду причин: на больших масштабах смущает уровень зрелости и поддержки проектов относительно Ceph, необходимость перевода всей инфраструктуры на новые рельсы и т.д.
Да, вы правы. Под Ceph я подразумевал CephFS.
Делать свою файловую систему даже и не пытались, и для наших задач POSIX совместимая файловая система явно бессмысленный оверхед
Это вы опрос среди разработчиков провели: что им нужно, а что нет?
По своему опыту с дата процессингом могу сказать: атомные операции и локи - это необходимость, симлинки и хардлинки - весьма желательно, листинг 25 миллионов объектов - никому не нужная блажь.
При этом S3 хранилище является сейчас стандартом для большей части как коммерческих, так и OpenSource решений (PostgreSQL, Clickhouse, Prometheus, Gitlab, Allure TestOps, ...)
С какой это поры S3 хранилище стало стандартом для PostgeSQL?? Про остальные вышеупомянутые системы - тоже весьма сомнительное утверждение.
строить систему хранения компании на единой платформе
Как можно построить систему хранения на платформе, которая не является универсальной? Вы же не будете базы данных в S3 хранить?
Ну и отвечая на вопрос - GlusterFS, SeaweedFS и прочие не смотрели, по ряду причин: на больших масштабах смущает уровень зрелости
Вы серьёзно считаете, что ваше самописное решение более зрелым чем GlusterFS, существующий уже много лет?
Не вы первые и не вы последние сталкиваетесь с хранением больших объёмов данных.
Условный Lustre вполне успешно используется в суперкомпьютерах, а вам почему-то не хватает производительности.
Хотелось бы для возврата в конструктивное обсуждение уточнить, читали ли вы статью. Потому что она описывает не вопрос выбора между распределенной файловой системой и объектным хранилищем, а повышение производительности уже развитого, масштабного и нагруженного S3 совместимого объектного хранилища.
Для всех задач свои инструменты и та же hdfs у нас успешно параллельно используется.
Это вы опрос среди разработчиков провели: что им нужно, а что нет?
листинг 25 миллионов объектов - никому не нужная блажь.
К счастью все гораздо проще, у нас есть метрики по использованию объектного хранилища в компании за несколько лет, и мы вполне понимаем, какие задачи актуальны, где можно попросить разработчиков не делать глупостей, а где действительно проблемы из реального мира, или особенности работы софта от внешних вендоров.
Не совсем технический вопрос, но не пробовали ли вы решать эту проблему с точки зрения улучшения BlueStore? Если у Ceph действительно есть перфоманс проблемы с BlueStore/rocksdb, то по идее мейнтейнер (Red Hat?) будет заинтересован их решить. Возможно можно было законтрибьютить новый сторедж бекенд вместо rocksdb туда, или описать проблему и попросить помощи у мейнтейнера. Просто сейчас у вас появилось несколько новых сервисов, и сцилла. Не звучит, как бесплатное решение для поддержки.
Так у Ceph фактически все хорошо: они отлично работают с embedded базой для хранения индекса, после того, как добавили функционал шардирования жизнь уж точно заиграла новыми красками, а в Reef они применили какую-то черную магию и еще больше производительность индекса подтянули. Так что как коробочное решение - близко к идеальному. Проблема тут в том, что embeded это ограничение на уровне архитектуры: не можем сами оптимально настроить хранилище, какой бы уровень экспертизы у команды эксплуатации ни был.
Привет! Спасибо за статью, читал с удовольствием)
Пара вопросов:
Можете поделиться подробностями выбора ScyllaDB? Критерии и требования
Как бэкапите базу индекса?
Используются ли распределенные транзакции в ScyllaDB?
Привет! рад, что понравилось)
Пожалуй основной критерий был возможность лёгкого масштабирования/шардирования. Мы подумали, что для нашей довольно таки простой предметной области не обязательны гарантии, которые предоставляют РСУБД, такие как PostgreSQL, поэтому смотрели и в сторону NoSQL. Ретроспективно, нам бы возможно подошёл какой-нибудь CockroachDB, по крайней мере из того поверхностного, что я читал, но ScyllaDB нам полностью подошла. Ещё и это был некий вектор для компании - у нас с тех пор в озоне появилась ScyllaDB платформа и всё больше сервисов начинают её использовать, то есть растёт экспертиза в компании в целом
Бэкапы мы делаем через стандартный ScyllaDB Manager. Бэкап происходит понодно и складывается тоже в S3, но в другой :)
Ты про Lightweight Transactions (LWT) или про транзакции через какой-то сторонний сервис? (в сцилле только LWT) но ответ - нет, мы строили архитектуру так, чтобы не пользоваться транзакциями, т.к опасались за производительность. Спорные ситуации разруливаются с помощью механизма Timestamp (время применения операции в сцилле), и статусные модели для объектов + фоновые джобы, которые могут чистить мусор
А ещё можно поставить внутри компании, если офисная сетка достаточно большая, Datananny, там есть API и в скором релизе запланирован апдейт до s3 совместимости
А вы тут специально написали, чтоб поисковиками проиндексировалась ?
Погуглил значит я про решение и ничего толкового не нашел, сплошная вода, нашел только, что вы являетесь генеральным директором этого "Datananny" и еще пары уважаемых стартапов, а еще вы, наставник, коуч, эксперт рынка и цифровой информации, участник всевозможных инициатив, партнёр Сколково, амбассадор, и тд и тп. Поэтому, наверное, нет оснований вам не верить.....
А еще нашел занятные статьи, где, как я понял, говориться о том, что нужно больше контроля за интернетом и ваше решение отлично для этого подойдёт можно неплохо так монетизировать.
При чтении, как минимум в паре мест словил ощущение, что человек, который это писал, вообще-то слегка «плавает» в том, как работает Ceph. Вот одно из таких мест, к примеру:
У Ceph есть такая особенность, что все операции — и запись и чтение — проходят через primary-зону.
Во-первых, какая-такая к чёрту «primary-зона»? "Primary" там бывает OSD (у "Acting Set" ~ «активного набора»), в чём легко убедиться хотя бы немножечко загуглив.
Во-вторых, что даже существенно важнее, Primary далеко не всегда является единственным источником данных, через который «проходят все операции» — достаточно вспомнить тот самый, упомянутый в статье EC (Erasure Coding), который, кстати говоря, довольно часто выбирают для S3 нагрузки из-за более низкого overhead'а по дисковому пространству. К слову сказать, для RBD (это уже «другое кино», но всё же к слову), load-balance по репликам доступен, начиная с какой-то уже довольно древней версии Ceph.
Ну и был ещё какой-то подобный странный момент.
Всё это естественно вызывает законное подозрение, сами понимаете какое(?).
вообще странный на вид наброс, честно сказать вызывает подозрение, сами понимаете какое(?)
primary зона ок, какой-то самоизобретенный термин, но для реплицированного (не EC) кластера ситуация описана валидно: S3 как не работало с репликами, так и не работает, думаю, тут вопрос же в гарантиях консистентности (если кинешь опровергающую информацию - с интересом почитаю)
про EC как решение без оверхеда по диску, которое часто выбирают: тут точно не хватает длинного пояснения про скорость чтения, про расход на CPU и прочие причины, почему можно не выбирать EC для S3
ну и как SO пост про RBD связан со статьей про объектные интерфейсы вообще неясно
а кроме того, статья же явно не про настройку Ceph, а про проектирование системы, своего решения, для которого Ceph используется чисто как blob storage
У вас в алгоритме GC есть проблема конкурентности. Проверка статуса и пометка/удаление происходит неатомарно так что можно потерять данные. Например кто-то вставляет чанк параллельно удалению такого же чанка, случай редкий но на вашем масштабе возможен.
GC посмотрел время последнего статуса, посмотрел что ссылок нет, далее параллельно идёт вставка новой ссылки на чанк, статус и его время меняется, gc делает удаление так как он не видел новую ссылку, данные потеряны. Тут надо атомарно проверять статус и удалить типа delete if version == vOld.
Привет! мы такой кейс рассматривали, чтобы такого не случилось была добавлена статусная модель и обязательное время нахождения в статусе. То есть из твоего примера будет так
rados object не имеет ссылок, его пометили к удалению
кто-то другой конкурентно с пометкой к удалению стал использовать этот rados object, ссылаться на него
новые объекты не могут ссылаться на этот rados object, потому что он уже помечен к удалению
GC фазы удаления проходит по объектам, помеченным к удалению. Проверяет, что прошло X времени с момента изменения статуса. И видит, что помеченный к удалению объект кем-то используется. И меняет статус обратно на ОК, не удаляя его
Мы как раз хотели избежать блокировок и таких атомарных изменений, потому что у нас eventual consistency база данных, сделать какую-то сложную логику атомарно бывает либо проблемно, либо плохо по производительности
Спасибо за статью! Я правильно понял, что пока нет планов по публикации Lusca в открытом доступе?
Ещё я слышал об Apache Ozone, но опыта с ним не было. Вы его рассматривали? Интересно, какие у него минусы.
Спасибо за статью! А вы не рассматривали делать свое собственное хранилище метаданных поверх RADOS omap'ов, вместо стандартного s3 от ceph?
Пробовали ли вы играть с настройками RocksDB чтобы стандартное решение от ceph работало лучше? Если пробовали, можете рассказать какие именно настройки крутили и что получалось? Очень интересно, потому что у нас написано собственное хранилище метаданных поверх omap'ов, наблюдаем похожие проблемы, сейчас как раз работаем над оптимизацией
привет, интересная история, сразу тут встречный вопрос: а в каком смысле поверх OMAP? Вы двигали значение osd_max_object_size или хватает дефолта 128Mb? Листинг реализован как листинг всех объектов пула и внешние индексы вообще не используются?
на счет того, какие настройки и как крутить, чтобы Ceph вывозил большие нагрузки на родном индексе, боюсь, так в комментарии не ответить - тянет на отдельную захватывающую историю от команды его эксплуатации. Часть более-менее понятных пунктов типа шардирования-решардирования есть в статье, ну и плюс - очень много делают разработчики Ceph в новых версиях в плане оптимизации.
Свой S3-server: что делать, если ваши десятки петабайт уже не лезут в коробочные объектные хранилища