Комментарии 28
А про кластер минио будет?
вы столкнётесь с существеннными проблемами
Какими именно? Деградация производительности или что-то другое?
на «обычной» ФС
Что такое обычная ФС?
«Обычная» — любая ФС, которая не использует динамическое выделение inode и использует стандартную стратегию выделения. Если вы сделаете, допустим, раздел с ext4 на диске 4ТБ, то скорее всего вы не сможете разместить там 1млрд файлов, а так как minio хранит объекты как отдельные файлы (ещё и не по одному), то не сможете и 200млн.
Поэтому minio хорошо подходит как хранилище для каких-нибудь образов виртуалок и совершенно не подходит для работы в качестве «замены S3» общего назначения.
Обычно, объектные хранилища не используют примитивы файловой системы для хранения индивидуальных объектов. Amazon S3 использует подлежащую БД (Dynamo), Azure/GCP — собственные БД, и Яндекс.Облако использует YDB, ну и нельзя не вспомнить про MongoDB GridFS. Создатели minio решили на этом сэкономить, вполне понятное желание, но один из сценариев использования, который был например очень интересен нам, для minio совершенно недоступен.
Если хочется сразу из коробки получить правильный ответ, где за нас уже всё решили и подумали, а пользователю надо только нажать большую красную кнопку «Сделать всё по красоте», для этого уже давно придуманы целые платформы типа ECS, Unity и прочих StorageGrid.
Minio себя с самого начала позиционировала как объектное хранилище, а не «метод хранения объектов поверх ФС» (вероятно вы имели в виду поддержку удалённого доступа поверх ФС, ну тут можно вспомнить про NFS). Если они не в состоянии дифференцировать термины «объектное хранилище» и «файловая система», то жаль что они вводят в заблуждение своих пользователей.
Зашёл к ним на страницу, и их самопозиционирование не только не стало скромнее, теперь там на главной написано что это «Kubernetes Native, High Performance Object Storage». Там ничего не сказано про то что это «сетевая ФС» или «распределённая ФС». Это «объектное хранилище с S3 интерфейсом».
Итого — minio это не объектное хранилище в современном понимании этого слова, это скорее аналог glusterfs, у которого лучше организована часть с erasure coding.
Ну или нужно к каждому слову писать слишком много звёздочек: Высокопроизводительное* распределённое** объектное хранилище***
* — пока ФС справляется с организацией древовидной структуры
** — пока система синхронной репликации не зависнет из-за проблем сети
*** — файловая система с удалённым доступом
Я уже сталкивался с некоторыми «системными интеграторами», которые нам продавали «S3-совместимое хранилище», которое через месяц эксплуатации безбожно тормозило, потому что они не предусмотрели сценарий, что для управления, допустим, временем жизни, в бакете где есть 700млн объектов, нужен подход отличный от «давайте положим всё файлами а потом будем запускать скрипт на Python».
В итоге объектов стало 50+ млн и растет. На десяток бакетов.
И все и пипец, сколько там файлов — неизвестно. Листинг? я тя умоляю.
И вопросы в стиле: а что оно теперь в 10 раз медленнее работает, чем раньше?
То есть тот факт что под MySQL, PosgresSQL или не приведи хосподть Oracle надо тюрить ОС и по хорошему подбирать ФС — вас не смущает. А вот minio мы этого не простим, да
Я предполагаю, что даже если настроить ФС так, чтобы в неё влезло нужное количество файлов, то это будет работать чудовищно медленно. Экспериментов не проводил, но эксплуатирую хранилище с 1 млрд объектов и чуть больше 100ТБ полезных (в смысле без учёта репликации) данных.
Кхм. Есть взять микроскоп и начать им забивать гвозди, то он очень быстро сломается. Так мне ваши жалобы напоминают претензии о том, что дескать у микроскопа хрупкая конструкция, подножка легкая и гнется, и вообще он не подходит к забиванию гвоздей. Так вся штука в том, что никто и не обещал что minio в один бинарь заменит весь амазон с его s3. у minio своя ниша, на мой взгляд отличная, и в своей нише он работает замечательно. Зачем вы пытаетесь натянуть сову на глобус?
Да не вопрос, у меня претензии, если вы заметили, в первую очередь к позиционированию, а не к функциональности. Я уже писал об этом здесь комментариях, почитайте. Они заявляют что они “Kubernetes Native, High Performance Object Storage”, а по факту это скорее glusterfs с другим API.
Я ничего не пытаюсь натянуть или забить, я в своё время протестировал minio и убедился что для решения моей задачи, для которой подходят другие объектные хранилища он не подходит, следовательно называть его объектным хранилищем можно лишь с некоторыми весьма важными утончениями, которые как минимум на момент проведения мною тестов в документации и аннотации отсутствовали.
Итого — люди сделали одно, а рекламируют как другое. Значит ли это что это плохой продукт? Не знаю, в моём случае значит, а в вашем вероятно нет.
Мне вообще непонятно почему то что я поделился своим отрицательным опытом вызовет такое негодование. Что, у любимого вами продукта не может быть недостатков? Или про то что такой недостаток есть может было узнать заранее из документации? Или если кто-то протестировал продукт и нашёл ограничения должен молчать что ли?
С моей точки зрения ответ на все три вопроса — «нет».
И да, про «один бинарь» — решение, которое сейчас используется у нас и не имеет таких ограничений (разумеется оно имеет другие ограничения) тоже представлено в виде одного статически слинкованного файла, так что аргументация такого рода мне кажется неуместной.
Я ничего не пытаюсь натянуть или забить, я в своё время протестировал minio и убедился что для решения моей задачи, для которой подходят другие объектные хранилища он не подходит, следовательно называть его объектным хранилищем можно лишь с некоторыми весьма важными утончениями, которые как минимум на момент проведения мною тестов в документации и аннотации отсутствовали.
Л — логика
А если вы попытаетесь писать на php драйвера и не сможете — php не будет языком программирования?
Они заявляют что они “Kubernetes Native, High Performance Object Storage”
- Minio разработан как cloud native application? Разработан
- Работает быстро? Да, быстро
- Оно работает с S3? Работает
- Где-нибудь заявлено, что они могут переварить терабайты данных? Нет
Они не соврали ни в чем. То, что вы взяли не подходящую fs под ваши задачи, и запихали в нее огромное количество файлов на один сервер и ждете скорости как от кластера — ну это ваша личная проблема, а не как ни продукта.
php не будет языком программирования?
В случае minio я сказал что «он не годится для организации хранилища большого количества объектов», в случае с PHP скажу что он «не подходит для написания драйверов» — всё честно, не больше и не меньше. Думаю человек, плохо знакомый с PHP будет благодарен за совет не писать на нём драйверы, не считаете?
У меня складывается ощущение, что вам кажется, как будто я (несправедливо) поливаю minio фекалиями, потому что он меня где-то подвёл, потому что я был недостаточно сообразителен чтобы им воспользоваться без проверки. Ситуация полностью обратная — я рассматривал его как один из вариантов организации хранилища и убедился в процессе тестирования и аудита архитектуры что он нам не подходит, о чём и не преминул сообщить (выше даже был человек, который тоже столкнулся с такими проблемами).
Работает быстро?
В случае с средним объёмом файлов с одинаковым префиксом — нет (см. issues ниже).
Где-нибудь заявлено, что они могут переварить терабайты данных?
Да: docs.minio.io/docs/minio-server-limits-per-tenant.html
Maximum number of objects per bucket: no-limit
Только не надо съезжать на «вы не понимаете, это другое» =) Попросили указать на лимиты — получите, заявлено что их нет, при этом docs.minio.io не содержит никаких гайдлайнов по настройке ФС или описания этих лимитов.
Зато потом появляются вот такие вот issue: github.com/minio/minio/issues/10733, github.com/minio/minio/issues/10268 и т.д. (и автор не я, если что).
ну вот как раз с lifecycle policy у NetApp StorageGRID очень хорошо. Очень гибко настраиваются политки.
Я имел в виду object lifecycle management, например PutBucketLifecycleConfiguration.
Не вижу ничего такого в документации на StorageGRID, ни в Operations on buckets, ни в Custom operations on buckets.
MinIo для самых маленьких