Simple Storage Service или S3 — сервис (и одновременно протокол) для хранения данных большого объёма. Для работы использует API поверх HTTP, который позволяет загружать или получать объекты из хранилища.
В проектах с приватной инфраструктурой часто возникает потребность в организации on-premise S3-хранилища. Популярное решение в таком случае это MinIO — удобная и довольно простая в использовании реализация сервиса S3. Когда нам в RUTUBE потребовалось S3, мы не стали долго думать и взяли MinIO, потому что он стильный, модный, молодежный хорошо себя зарекомендовал на рынке, хорошо документирован и прост в первоначальной настройке и эксплуатации.
В этой статье поделюсь своим опытом использования MinIO, сделав акцент на отказоустойчивости и сохранности данных в случае инцидентов разной степени — от выпадения диска до пожара в цоде.
На создание этого материала меня подтолкнуло то, что в русскоязычном сегменте интернета почти нет информации по тонкой настройке и организации избыточности данных в MinIO. В статье рассмотрю некоторые ситуации из разряда траблшутинга, чтобы наглядно показать, где и какие проблемы могут возникнуть, а также как с ними бороться. Отмечу также, что мы в RUTUBE используем MinIO не для видеохранилища — там у нас сейчас собственная альтернативная реализация, о которой можно прочитать в отдельной статье. Поэтому вопрос хранения огромных объемов данных остаётся за рамками этой статьи.
Я опущу типовую настройку деплоймента MinIO, ожидая, что читатели уже знакомы с продуктом в базовом сценарии конфигурирования. Тем не менее, ознакомиться с инструкцией по развертыванию деплоймента MinIO можно в официальной документации.
Как MinIO хранит данные
На верхнем уровне абстракции MinIO — черный ящик с дисками, на которых хранятся наши данные. Сервис дробит загруженный в него файл на множество маленьких кусочков определенного размера и складывает их на свои эндпоинты (которые являются смонтированными в системе дисками). Но там, где есть физические диски, рано или поздно случаются и отказы этих самых дисков, угрожающие сохранности наших данных.
Давайте рассмотрим тестовый стенд minio-test-a, который состоит из 4 нод по 8 дисков (для удобства далее я буду использовать запись вида 4x8). По информации из официальной документации продукта не рекомендуется использовать какой-нибудь overlay при разметке дисков, например lvm, поэтому я использовал parted и размечал всё доступное на дисках место в единственную партицию.
Итоговая разметка выглядела примерно так:
В распоряжении сервиса находится 32 диска. В первую очередь MinIO формирует такую абстракцию как erasure set — это набор дисков в количестве от 4 до 16, на которых будут располагаться сами данные. Размер erasure set выбирается сервисом автоматически и стремится занять как можно больше дисков (до 16, далее N).
Диски в erasure set делятся на 2 типа: диски данных (data drives) и диски четности (parity drives, далее M). Это очень похоже на RAID, по своей сути оно и есть, с той лишь разницей, что количество дисков четности мы можем выбирать сами, вместо того чтобы выбирать конкретную модель RAID. Также стоит отметить, что дисков четности не может быть больше половины размера erasure set.
После того, как erasure set'ы выбраны (их может быть более одного, если дисков в кластере больше 16), MinIO линкует их в так называемый server pool и переходит к определению storage class, задающих избыточность хранения данные. Их всего два: STANDARD и REDUCED_REDUNDANCY. Для каждого storage class выбирается своё соотношение data и parity drives, с условием того, что количество parity drive для reduced_redundancy должно быть не выше, чем для standard. Стратегия reduced_redundancy подходит, когда мы храним менее важные файлы — то есть закладываем меньше избыточности и соответственно экономим место в хранилище. Количество дисков четности для обоих классов можно задать вручную, например через переменные окружения, либо MinIO сделает это сам, автоматически.
MINIO_STORAGE_CLASS_STANDARD=EC:4
MINIO_STORAGE_CLASS_RRS=EC:2Здесь EC: — это зарезервированный префикс, а 4 и 2 — это количество parity-дисков для соответствующего storage class.
Для работы с кластером я буду использовать утилиту mc. Добавим алиас и посмотрим состояние нашего стенда.
mc alias set minio-test-a http://localhost:9000 minio minio123 # url, access_key и secret_key выставлены для примера, у вас будут свои значения:mc admin info minio-test-
Мы видим сводную информацию по нодам, общее количество дисков в деплойменте, server pool с количеством и размером erasure set, статистику используемого места и настройки стандартного storage class (EC:4 – то есть 4 диска четности на erasure set).
Мы можем получить более подробную информацию, к какому erasure set прилинкован каждый диск. Например, так:
mc admin info minio-test-a --json | jq '[.info.servers|.[].drives[]|{endpoint,set_index}]'
[
{
"endpoint": "https://minio-test-801:9000/data/storage1",
"set_index": 0
},
{
"endpoint": "https://minio-test-801:9000/data/storage2",
"set_index": 0
},
{
"endpoint": "https://minio-test-801:9000/data/storage3",
"set_index": 0
},
{
"endpoint": "https://minio-test-801:9000/data/storage4",
"set_index": 0
},
{
"endpoint": "https://minio-test-801:9000/data/storage5",
"set_index": 1
},
{
"endpoint": "https://minio-test-801:9000/data/storage6",
"set_index": 1
},
{
"endpoint": "https://minio-test-801:9000/data/storage7",
"set_index": 1
},
{
"endpoint": "https://minio-test-801:9000/data/storage8",
"set_index": 1
}
]Я ограничил вывод до эндпоинтов одной ноды, т.к. весь список у меня будет довольно большим, но обратите внимание на то, как диски распределяются по erasure set'ам в разрезе нод. В моём стенде у каждой ноды первые 4 диска прилинкованы к erasure set 0, остальные — к erasure set 1. Таким образом, если у нас более одного erasure set, то мы можем утверждать, что на каждой ноде будут диски из каждого erasure set. Чтобы убедиться в верности своих утверждений, я тестировал конфигурацию 4х5, и итоговый server pool выглядел так:
И на каждой ноде каждый диск был прилинкован к разным erasure set. Стандартный storage class в таком кейсе может иметь не больше двух дисков четности ( M <= N/2 ).
Вернёмся к нашему стенду. Используемая конфигурация (4х8, M = 4) позволяет нам потерять в моменте 4 диска из erasure set, или одну ноду целиком (исходя из информации, которую мы получили в предыдущем абзаце), и сервис продолжит функционировать в полном объёме. Так как каждый объект в хранилище хранится только в рамках одного erasure set, то выход из строя хотя бы одного дополнительного диска приведёт к недоступности всех объектов, хранящихся в пределах задетого erasures set. Существует способ защититься от этого риска, но об этом чуть позже, когда будем говорить про репликацию данных между деплойментами.
Замена неисправных дисков
Бывает, что по каким-нибудь причинам сервер (или отдельный диск) становится безвозвратно недоступен. Ничего страшного, ведь MinIO позаботился об этом и позволяет нам потерять M дисков из erasure set. Но что происходит при замене неисправного диска на новый, в какой момент деплоймент вернётся в состояние консистентной системы? Сервис отслеживает состояние объектов на своих эндпоинтах и при обнаружении разницы запускает процедуру heal. Таким образом, если мы просто удалим каталог с данными на одном из дисков erasure set, то данные будут восстановлены благодаря наличию дисков четности и процедуре heal.
Во время тестов я обнаружил, что в некоторых случаях heal запускается не сразу, а только через какое-то произвольное время. В такой ситуации приходилось запускать его вручную с помощью команды: mc admin heal -r minio-test-a.
Использование класса REDUCED_REDUNDANCY (rrs)
Как я упоминал ранее, класс REDUCED_REDUNDANCY используется для хранения данных, для которых нет жестких требований к сохранности, и позволяет экономить место.
На тестовом стенде я создал бакет test и загрузил в него пару файлов, чтобы наглядно продемонстрировать работу с этим классом.
mc cp /tmp/ubuntu.iso minio-test-a/test/ubuntu-rrs.iso –storage-class REDUCED_REDUNDANCY
mc cp /tmp/ubuntu.iso minio-test-a/test/ubuntu-rrs-2.iso –storage-class REDUCED_REDUNDANCY
mc ls minio-test-a/test
Для класса rrs выбрано M = 2.
mc admin config get minio-test-a storage_class
Если erasure set, в котором хранится этот объект, потеряет данные с более чем двух дисков, то мы потеряем все объекты, использующие этот класс. Чтобы продемонстрировать это, я удалю каталоги с данными на трёх дисках соответствующего erasure set. К сожалению, мне не удалось найти в API возможности узнать, в каком erasure set хранится объект. Поэтому я вручную найду папку с файлом, просматривая по одному эндпоинту каждого erasure set на одной из нод MinIO.
Я нашел файлы по пути /data/storage5/test/.
root@minio-test-801:~# ls -lah /data/storage5/test/
total 0
drwxr-xr-x 8 minio-user minio-user 128 Nov 30 17:02 .
drwxr-xr-x 4 minio-user minio-user 36 Nov 30 16:24 ..
drwxr-xr-x 3 minio-user minio-user 65 Nov 30 16:26 ubuntu3.iso
drwxr-xr-x 3 minio-user minio-user 65 Nov 30 16:26 ubuntu4.iso
drwxr-xr-x 3 minio-user minio-user 65 Nov 30 16:28 ubuntu5.iso
drwxr-xr-x 3 minio-user minio-user 65 Nov 30 16:29 ubuntu8.iso
drwxr-xr-x 3 minio-user minio-user 65 Nov 30 17:02 ubuntu-rrs-2.iso
drwxr-xr-x 3 minio-user minio-user 65 Nov 30 16:50 ubuntu-rrs.isoКонкретный эндпоинт в моём стенде имеет set_index = 1, значит, нужные мне файлы находятся в erasure set 1. Теперь я удалю данные с нескольких эндпоинтов:
rm -rf /data/storage{5..7}/testПосле завершения процедуры heal (mc admin heal minio-test-a не показывает активных процессов) и восстановления консистентности, файлы c классом rrs пропали, в то время, как файлы со стандартным storage class остались на месте.
Будьте осторожней при использовании этого storage class. Однако при использовании двухсторонней репликации, даже утерянные данные класса rrs можно восстановить.
Доступность объектов в разных erasure set
Эндпоинт является атомарным элементом в структуре MinIO и указывает на конкретный каталог конкретной ноды. Допустимое количество недоступных эндпоинтов равно количеству дисков четности в erasure set. Предположим, у нас стало недоступно M+1 эндпоинтов в erasure set 0. На своём стенде я просто отмонтирую необходимые каталоги и попробую скачать через mc некоторые файлы.
Узнаю, какие файлы находятся в erasure set 0 (какие эндпоинты к нему прилинкованы я узнал ранее):
root@minio-test-801:~# ls -lah /data/storage3/test/
total 0
drwxr-xr-x 9 minio-user minio-user 139 Nov 30 12:20 .
drwxr-xr-x 4 minio-user minio-user 36 Nov 26 11:57 ..
drwxr-xr-x 3 minio-user minio-user 65 Nov 30 12:20 ubuntu10.iso
drwxr-xr-x 3 minio-user minio-user 65 Nov 26 11:59 ubuntu1.iso
drwxr-xr-x 3 minio-user minio-user 65 Nov 26 11:59 ubuntu2.iso
drwxr-xr-x 3 minio-user minio-user 65 Nov 26 11:59 ubuntu6.iso
drwxr-xr-x 3 minio-user minio-user 65 Nov 26 12:00 ubuntu7.iso
drwxr-xr-x 3 minio-user minio-user 65 Nov 26 12:00 ubuntu9.iso
drwxr-xr-x 3 minio-user minio-user 65 Nov 30 12:17 ubuntu.isoПробую скопировать себе эти файлы:
mc cp minio-test-a/test/ubuntu1.iso .
mc: <ERROR> Unable to prepare URL for copying. Unable to guess the type of copy operation.
mc cp minio-test-a/test/ubuntu2.iso .
mc: <ERROR> Unable to prepare URL for copying. Unable to guess the type of copy operation.
mc cp minio-test-a/test/ubuntu6.iso .
mc: <ERROR> Unable to prepare URL for copying. Unable to guess the type of copy operation.Файлы, хранимые в erasure set 0 с недоступными каталогами, недоступны для чтения. Так как сетов всего 2, то файлы, которые отсутствуют в этом каталоге, находятся в каталогах другого erasure set. Попробуем скопировать:
mc cp minio-test-a/test/ubuntu3.iso .
mc cp minio-test-a/test/ubuntu4.iso .
Загрузка пошла, ошибок нет. Erasure set 1 в бою.
Лично я сделал вывод, что не хочу иметь более 1 erasure set в server pool, потому что неопределённость пугает — какой файл при массовом отказе дисков останется доступен, а какой нет?
Таким образом, считаю конфигурацию 4x4 оптимальной в рамках одного server pool.
Масштабирование деплоймента MinIO
Разработчики продукта рекомендуют так называемый cloud-like метод расширения деплоймента. То есть мы не добавляем диски в сервера существующих server pool'ов, а добавляем сами server pool'ы. Стоит отметить, что я тестировал расширение существующих дисков в server pool, и MinIO увидел новые значения capacity дисков даже без перезапуска сервиса. Поэтому этот вариант стоит взять на вооружение при некоторых обстоятельствах, например, если нет возможности добавить новый server pool. Единственный нюанс состоит в том, что после расширения, все диски должны быть одинакового размера, т.к. MinIO «размазывает» все чанки хранимых объектов, по всем дискам erasure set, а значит, может возникнуть проблемная ситуация, когда на одном из дисков (который окажется меньшего размера) закончится место.
Добавление нового server pool, помимо подготовки самой группы серверов для этого пула, заключается в редактировании конфигурационного файла minio (у меня он находится по пути /etc/default/minio) в контексте переменной окружения MINIO_VOLUMES.
Пример конфигурации до:
MINIO_VOLUMES="https://minio-test-{1...4}:9000/data/storage{1...8}"Пример конфигурации после:
MINIO_VOLUMES="https://minio-test-{1...4}:9000/data/storage{1...8} https://minio-test-{5...8}:9000/data/storage{1...4}"Конфигурация «после» иллюстрирует 2 пула, которые будут работать в рамках одного деплоймента MinIO. Применив изменения в конфигурации на всех инстансах, нужно перезапустить/запустить сервис одновременно на всех нодах деплоймента.
Добавим ещё один server pool в конфигурации 4x4 в наш тестовый стенд.
Итого мы получили деплоймент с двумя server pool в различной конфигурации. Важной особенностью является то, что добавляемый server pool должен соответствовать настройкам storage class, т.к. они глобальные в рамках деплоймента. Например, если бы я попытался добавить пул в конфигурации 4 ноды по 1 диску, то сервис бы не запустился, т.к. erasure set в новом пуле был бы всего из 4 дисков, а количество дисков четности для деплоймента равно 4, что не удовлетворяет условию M <= N/2. В этом случае потребовалось бы уменьшение дисков четности до 2 – EC:2.
Обратите внимание, что объекты, существующие в деплойменте на момент добавления нового server pool, по-умолчанию остаются в своих erasure set. Перераспределение объектов возможно через ручной запуск процедуры rebalance. Это довольно тяжелая и долгая процедура, которая линейно зависит от того, сколько данных хранится в деплойменте. MinIO выбирает, в какой пул разместить объект, опираясь на свободное место в рамках каждого server pool. Давайте попробуем этот процесс на нашем стенде:
mc admin rebalance start minio-test-a
mc admin rebalance status minio-test-a
Ничего не произошло. Дело как раз в том, что в пуле 1 больше свободного места, чем в пуле 2, поэтому MinIO принял решение оставить всё как есть.
Репликация данных
Для сохранности данных на случай более серьезных отказов, есть возможность реплицировать отдельные бакеты в другие деплойменты MinIO. Разработчики продукта предоставили три возможные конфигурации:
ACTIVE-PASSIVE — репликация объектов (или некоторых отдельных операций над объектами) из одного деплоймента в другой, в одну сторону;
ACTIVE-ACTIVE — репликация объектов (или некоторых отдельных операций над объектами) из одного деплоймента в другой, в обе стороны;
Multi-site ACTIVE-ACTIVE — репликация объектов (или некоторых отдельных операций над объектами) из одного деплоймента в более чем один другой деплоймент, в обе стороны.
Тут, кажется, что всё просто и понятно. Подробней можно ознакомиться в официальной документации.
Для демонстрации мне понадобится ещё один стенд minio-test-b в конфигурации 4x4, а также я буду использовать ACTIVE-ACTIVE конфигурацию для репликации.
mc admin info minio-test-b
Вкратце опишу процесс настройки.
Создаём в каждом деплойменте бакет (с версионированием) для синхронизации. В minio-test-a существует бакет test и в нём уже есть некоторые файлы, поэтому я создам бакет только в minio-test-b:
mc admin info minio-test-b.Создаём в каждом деплойменте политику для репликации между нашими бакетами. Она может выглядеть примерно так.
ReplicationRemoteUserPolicy.json:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetReplicationConfiguration",
"s3:ListBucket",
"s3:ListBucketMultipartUploads",
"s3:GetBucketLocation",
"s3:GetBucketVersioning",
"s3:GetBucketObjectLockConfiguration",
"s3:GetEncryptionConfiguration"
],
"Resource": [
"arn:aws:s3:::*"
],
"Sid": "EnableReplicationOnBucket"
},
{
"Effect": "Allow",
"Action": [
"s3:GetReplicationConfiguration",
"s3:ReplicateTags",
"s3:AbortMultipartUpload",
"s3:GetObject",
"s3:GetObjectVersion",
"s3:GetObjectVersionTagging",
"s3:PutObject",
"s3:PutObjectRetention",
"s3:PutBucketObjectLockConfiguration",
"s3:PutObjectLegalHold",
"s3:DeleteObject",
"s3:ReplicateObject",
"s3:ReplicateDelete"
],
"Resource": [
"arn:aws:s3:::*"
],
"Sid": "EnableReplicatingDataIntoBucket"
}
]
}При необходимости можем ограничить политику конкретным бакетом, отредактировав поле Resource.
mc admin policy create minio-test-a ReplicationRemoteUserPolicy ReplicationRemoteUserPolicy.json
mc admin policy create minio-test-b ReplicationRemoteUserPolicy ReplicationRemoteUserPolicy.jsonСоздадим пользователей для репликации:
mc admin user add minio-test-a ReplicationRemoteUser <user_1_password>
mc admin user add minio-test-b ReplicationRemoteUser <user_2_password>Теперь линкуем пользователей с ранее созданными политиками:
mc admin policy attach minio-test-a ReplicationRemoteUserPolicy --user=ReplicationRemoteUser
mc admin policy attach minio-test-b ReplicationRemoteUserPolicy --user=ReplicationRemoteUserВключаем непосредственно саму репликацию между бакетами:
mc replicate add minio-test-a/test \
--remote-bucket 'https://ReplicationRemoteUser:<user_2_password>@<minio-test-b_url>/test' \
--replicate "delete,delete-marker,existing-objects"
mc replicate add minio-test-b/test \
--remote-bucket 'https://ReplicationRemoteUser:<user_1_password>@<minio-test-a_url>/test' \
--replicate "delete,delete-marker,existing-objects" Через флаг --replicate мы выбрали некоторые параметры, которые указывают, какие объекты и операции реплицировать. Более подробно с этими параметрами можно ознакомиться в документации.
По умолчанию репликация работает в ассинхронном режиме, т.е. объект сперва загружается в оригинальный бакет и только потом реплицируется. Соответственно, указав флаг --sync enable при настройке, мы переключим режим в синхронный.
Посмотреть статус репликации можно следующими командами:
mc replicate status minio-test-a/test
mc replicate status minio-test-b/testДожидаемся, когда все файлы из minio-test-a/test скопируются в minio-test-b/test, и посмотрим состояние бакетов.
mc ls minio-test-a/test
mc ls minio-test-b/test
Как мы видим, объекты полностью идентичные, вплоть до атрибутов.
В дополнение ко всему, хочется отметить очень полезную фишку репликации в MinIO — это проксирование запросов при обращении к недоступному в хранилище объекту.
Предположим, что у нас два деплоймента MinIO, между которыми настроена ACTIVE-ACTIVE репликация, и система находится в состоянии покоя (т.е. никаких фоновых процессов репликации файлов не происходит). Теперь искуственно сделаем один из деплойментов недоступным для чтения – отключим как минимум M+1 дисков. Я отмонтировал 8 дисков из erasure set 0 в первом server pool minio-test-a, то есть половину дисков при M=4.
sdb 8:16 0 20G 0 disk
└─sdb1 8:17 0 20G 0 part
sdc 8:32 0 20G 0 disk
└─sdc1 8:33 0 20G 0 part
sdd 8:48 0 20G 0 disk
└─sdd1 8:49 0 20G 0 part /data/storage3
sde 8:64 0 20G 0 disk
└─sde1 8:65 0 20G 0 part /data/storage4
sdf 8:80 0 20G 0 disk
└─sdf1 8:81 0 20G 0 part /data/storage5
sdg 8:96 0 20G 0 disk
└─sdg1 8:97 0 20G 0 part /data/storage6
sdh 8:112 0 20G 0 disk
└─sdh1 8:113 0 20G 0 part /data/storage7
sdi 8:128 0 20G 0 disk
└─sdi1 8:129 0 20G 0 part /data/storage8Посмотрим, какие файлы находятся в /data/storage3 (этот эндпоинт так же прилинкован к erasure set 0):
root@minio-test-801:~# ls -lah /data/storage3/test/
total 0
drwxr-xr-x 9 minio-user minio-user 139 Nov 30 12:20 .
drwxr-xr-x 4 minio-user minio-user 36 Nov 26 11:57 ..
drwxr-xr-x 3 minio-user minio-user 65 Dec 3 16:05 ubuntu10.iso
drwxr-xr-x 3 minio-user minio-user 65 Dec 3 16:06 ubuntu1.iso
drwxr-xr-x 3 minio-user minio-user 65 Dec 3 16:10 ubuntu2.iso
drwxr-xr-x 3 minio-user minio-user 65 Dec 3 16:12 ubuntu6.iso
drwxr-xr-x 3 minio-user minio-user 65 Dec 3 16:12 ubuntu7.iso
drwxr-xr-x 3 minio-user minio-user 65 Dec 3 16:12 ubuntu9.iso
drwxr-xr-x 3 minio-user minio-user 65 Dec 3 16:05 ubuntu.isoПробуем скачать:
Файлы скачиваются, хотя не должны. Для чистоты эксперимента остановим проксирование и попробуем скачать снова.
mc replicate update --state disable minio-test-a/test --id $(mc replicate ls minio-test-a/test --json | jq -r '.rule.ID')
Файлы недоступны. Наглядная польза проксирования! Но для записи мы всё-таки должны восстановить деплоймент.
Далее хотелось бы вернуться к rrs storage-классу. Как я писал ранее, мы можем потерять данные, хранимые с использованием этого класса. Если это случилось, а утерянные файлы нам очень нужны, то репликация поможет нам справиться с последствиями. Чтобы восстановить файлы в исходном бакете, мы просто запустим операцию resync и через некоторое время данные восстановятся. Команда может выглядеть примерно так:
mc replicate resync start minio-test-a/test --remote-bucket $(mc replicate ls minio-test-a/test --json | jq -r '.rule.Destination.Bucket')
mc replicate resync status minio-test-a/test --remote-bucket $(mc replicate ls minio-test-a/test --json | jq -r '.rule.Destination.Bucket')Итого
MinIO — простой и удобный инструмент, который в условиях актуального на сегодняшний день технологического стека найдет применение практически в любой инфраструктуре. Надеюсь, этот материал будет вам полезен, если вы планируете организовать S3 в своей инфраструктуре.
От себя выделю несколько моментов настройки:
Уделите особое внимание выбору количества дисков четности — parity drives. Это поможет найти оптимальное соотношение отказоустойчивости и доступного места.
Не используйте конфигурации, создающие более одного erasure set в server pool. Как такового риска этот критерий не создает, но добавляет неопределенности в том, какие данные в момент аварии останутся доступны, а какие нет. Мне видится оптимальным вариант 4х4.
Если позволяют ресурсы, планируйте два деплоймента MinIO, объединенных в ACTIVE-ACTIVE репликацию. Отказы случаются внезапно, и наличие такого рода резервирования избавит от паники.
Этим и другими материалами о том, как устроена разработка в RUTUBE и кто создаёт крупнейший видеохостинг, делимся в телеграм-канале Смотри за IT — присоединяйтесь.