Объектное хранилище — название отражает принцип работы, хранение данных в виде объектов с уникальным индексом.
Хочу расcказать о своем опыте работы с одним из них.Меня заинтересовал один конкретный продукт — MinIO, из‑за достаточно простой установки, настройки и не плохого функционала. Есть несколько вариантов инсталляции MinIO:
Single‑Node Single‑Drive
Single‑Node Multi‑Drive
Multi‑Node Multi‑Drive
Далее кратко о первых двух и подробно о последнем варианте.
Single-Node Single-Drive
Развертывание в такого варианта подразумевает один сервер, один диск. Удобно для первого знакомства с MinIO, изучения функционала и хранения каких‑либо данных, потеря которых не критична. В такой схеме нет резервирования данных, но в остальном полноценное объектное хранилище.
Single-Node Multi-Drive
Это уже вариант поинтересней сервер по прежнему один, но дисков уже несколько, кстати диски могут быть не только физическими, но и к примеру логическими томами. Физические диски с XFS оптимальный вариант, использование SAN/NAS, ext4, RAID, LVM снизит производительность и надежность. В такой реализации можно потерять до половины количества дисков и есть требования к их количеству, а именно минимальное количество 4, про максимальное ограничение упоминаний не нашел, должно быть зависит от моего желания и возможности сервера, второе ограничение жестче. Диски по объему должны быть равны иначе объем всех дисков будет приравнен наименьшему из них.
Multi-Node Multi-Drive
На этом вариант развертывания MinIO остановлюсь подробнее. И так Multi‑Node Multi‑Drive обладает достоинствами выше перечисленных вариантов плюс состоит из нескольких серверов, на каждом из которых от четырех дисков. Требования к дискам те же что и во втором варианте. Потерять также можно до половины от количества дисков или серверов целиком.
Резервирование данных обеспечивает функция Erasure Coding в основе которой используется код Рида — Сололмона. Функцию Erasure Coding поддерживают только Single‑Node Multi‑Drive и Multi‑Node Multi‑Drive. Объекты в MinIO делятся на блоки данных и блоки четности. Напоминает raid 6, но может быть надежней так как позволяет потерять до половины дисков, в зависимости от ваших настроек. Еще одним преимуществом является возможность задать количество блоков данных и четности, таким образом найдя для себя оптимальное соотношение между надежностью и емкостью хранилища. При потере заданного количества дисков данные доступны для записи и чтения кроме варианта когда число дисков под блоки четности равно числу дисков с блоками данных в этом случае при потере половины дисков доступно только чтение, для записи нужен еще хотя бы один диск.
Для экономии вычислительных ресурсов после восстановления всех дисков не происходит равномерное распределение по всем дискам (пулам) новые данные пишутся в тот пул где больше места. Стремление разработчиков MinIO к экономии вычислительных ресурсов ради производительности прослеживается и в других функциях хранилища. К примеру при версионировании не производится какихто вычислений между между версиями объекта, а просто записывается измененный объект. Этот факт так же стоит учесть при расчете емкости будущего хранилища.
MinIO предоставляет удобный калькулятор для расчета оптимального для вас соотношения блоков четности к числу блоков данных. Erasure Coding работает с наборами блоков от 4 до 16.
Установка и базовая настройка довольно хорошо описана в официальной документации, поэтому оставлю ссылку и расскажу подробней о тех моментах что заставили меня потратить на них больше времени.
Для тестирования Multi‑Node Multi‑Drive стенд собрал на четырех ВМ, на каждой ВМ для эмуляции жестких дисков под хранилище нарезал по восемь логических томов LVM одинакового размера на всех серверах. Напомню что рекомендуется использовать чистые диски с XFS. Erasure Code Stripe Size определяется алгоритмом автоматически. Для рассматриваемого тестового стенда общее количество свободных дисков будет 32, в этом случае Erasure Code Stripe Size будет равно 16 так как это наибольший общий делитель из допустимого диапазона от 4 до 16. Получилось два набора по 12 блоков данных + 4 блока четности, емкость хранилища 75% от суммы емкости всех дисков, допустимые потери 8 дисков или один сервер целиком. Для такого развертывания MinIO важна гомогенность узлов. Количество блоков четности, в моем случае
MINIO_STORAGE_CLASS_STANDARD=EC:4
и остальные переменные необходимые для работы MinIO задаются в /etc/default/minio и выглядит как то так:
MINIO_VOLUMES="https://minio-test{1...4}.ru:9000/mnt/disk1{1...8}"
MINIO_OPTS="--address :9000 --console-address :9001"
MINIO_ROOT_USER=your-admin
MINIO_ROOT_PASSWORD=pass-for-admin
MINIO_SERVER_URL="https://minio-test.ru:9000"
MINIO_STORAGE_CLASS_STANDARD=EC:4
Все лаконично и просто — не так ли. Если заметили в переменных перечислено 5 серверов вместо 4-х ранее заявленных, пятый MINIO_SERVER_URL="https://minio-test.ru:9000" - балансировщик. MinIO рекомендует в качестве балансировщика использовать NGINX или HAProxy, я остановил свой выбор на NGINX. В моем развертывании балансировщик вынесен на отдельный сервер, но можно и на одном из узлов хранилища поднять. На этом этапе у нас есть работающее объектное хранилище. Узлы работают во внутренней сети и для тестов безопасности этого достаточно, но можно сделать еще безопасней - шифрование. Процесс генерации сертификатов описывать не буду, это не раз было сделано до меня, сертификат поместил в ~/.minio/certs/ и перезапустил службу MinIO, операцию повторил на каждом узле. Если вам лень на каждом узле в ручную менять настройки Ansible ваш выбор.
И вот оно работает, можно создавать пользователей, корзины, проводить разные тесты, но как то маловато информации о кластере в разделе меню мониторинг. По умолчанию получаем минимальный набор данных, но MinIO намекает ссылкой — хочешь больше ставь Prometheus и после установки в /etc/default/minio добавил еще пару строк:
MINIO_PROMETHEUS_URL="http://192.168.3.172:9090"
MINIO_PROMETHEUS_JOB_ID="minio-job"
Наслаждаемся графиками, диаграммами и количественными данными. Кстати в библиотеке дашбордов Grafana есть хороший для MinIO на случай если будет мало того что в веб интерфейсе MinIO.
Так как мы в нашей инфраструктуре придерживаемся принципов IaaC, объектное хранилище должно стать ее частью, а значит надо автоматизировать создание корзин, пользователей и политик. Для примера есть задача создавать служебных пользователей с корзиной определенного размера, важное условие пользователи не должны видеть корзины других пользователей. Операции по созданию и удалению должны выполняться через gitlab и отдельный веб интерфейс. Думал что с этим поможет API MinIO, но к сожалению функционал его не позволил мне это реализовать. Решением стала MinIO Console, для веб интерфейса пришлось сделать небольшой backend на flask.
