Первый выпуск Vitastor S3

16.03.2025

Итак, свершилось - реализация Vitastor S3 на базе Zenko CloudServer достигла состояния готовности к публикации и использованию.

Основные отличия от прототипа:

  • Реализована дефрагментация томов с данными (освобождение места);
  • Метаданные томов можно теперь хранить в MongoDB (там же, где и метаданные объектов), а не только в VitastorKV;
  • Добавлены тесты для Vitastor-бэкенда;
  • Добавлена удобная для установки Docker-сборка.

Ключевые особенности

  • Zenko CloudServer реализован на node.js.
  • Метаданные объектов хранятся в MongoDB.
  • Поставляется модифицированная версия Zenko CloudServer, отвязанная от лишних зависимостей, с оптимизированной сборкой и немного отличающаяся от оригинала.
  • Данные объектов хранятся в блочных томах Vitastor, однако информация о самих томах сохраняется не в etcd Vitastor, а тоже в БД на основе MongoDB.
  • Объекты записываются в тома последовательно друг за другом. Место выделяется с округлением до размера сектора (до 4 килобайт), поэтому каждый объект занимает как минимум 4 КБ.
  • Благодаря такой схеме записи объектов мелкие объекты не нарезаются на части и поэтому не требуют чтения с N дисков данных в EC N+K пулах Vitastor.
  • При удалении объекты помечаются удалёнными, но место освобождается не сразу, а при запускаемой асинхронно “дефрагментации”. Дефрагментация запускается автоматически в фоне при достижении заданного объёма “мусора” в томе (по умолчанию 20%), копирует актуальные объекты в новые тома, после чего очищает старый том полностью. Дефрагментацию можно настраивать в locationConfig.json.

Установка

Проследуйте по инструкции, добавленной в документацию: https://vitastor.io/docs/installation/s3.html

Планы развития

  • Хранение учётных записей в БД, а не в статическом файле (в оригинальном Zenko для этого используется отдельный закрытый сервис “Scality Vault”).
  • Более подробная документация.
  • Поддержка других (и более производительных) key-value СУБД для хранения метаданных.
  • Другие оптимизации производительности, например, в области используемой хеш-функции (хеш MD5, используемый в целях совместимости, относительно медленный).
  • Поддержка Object Lifecycle. Реализация Lifecycle для Zenko существует и называется Backbeat, но она ещё не адаптирована для Vitastor.
  • Квоты. В оригинальном Zenko для этого используется отдельный сервис “SCUBA”, однако он тоже является закрытым и недоступен для публичного использования.

Первые тесты производительности

Нижеприведённые тесты проведены на очень небольшом тестовом кластере из 4 хостов по 1 диску Samsung PM9A3 на каждом, с 1 экземпляром Zenko и 8 рабочими процессами node.js, и MongoDB с 3 репликами, установленной на системных SSD-дисках.

Для тестирования производительности применялся hsbench, запущенный с локального узла.

16 потоков, 4 КБ объекты:

./hsbench -a accessKey1 -s verySecretKey1 -u http://localhost:8000 -z 4k -t 16
... Dur(s): 60.0, Mode: PUT, Ops: 40721, MB/s: 2.65, IO/s: 678, Lat(ms): [ min: 8.9, avg: 23.6, 99%: 46.1, max: 627.1 ], Slowdowns: 0
... Dur(s): 60.3, Mode: LIST, Ops: 3939, MB/s: 0.00, IO/s: 65, Lat(ms): [ min: 92.6, avg: 244.2, 99%: 608.9, max: 919.8 ], Slowdowns: 0
... Dur(s): 60.0, Mode: GET, Ops: 163326, MB/s: 10.63, IO/s: 2722, Lat(ms): [ min: 2.4, avg: 5.8, 99%: 16.7, max: 31.4 ], Slowdowns: 0
... Dur(s): 37.6, Mode: DEL, Ops: 40721, MB/s: 4.23, IO/s: 1084, Lat(ms): [ min: 7.3, avg: 14.8, 99%: 26.9, max: 57.5 ], Slowdowns: 0

16 потоков, 4 МБ объекты:

./hsbench -a accessKey1 -s verySecretKey1 -u http://localhost:8000 -z 4M -t 16
... Dur(s): 60.1, Mode: PUT, Ops: 14879, MB/s: 990.77, IO/s: 248, Lat(ms): [ min: 22.2, avg: 64.5, 99%: 139.2, max: 641.0 ], Slowdowns: 0
... Dur(s): 60.4, Mode: LIST, Ops: 3943, MB/s: 0.00, IO/s: 65, Lat(ms): [ min: 104.2, avg: 244.1, 99%: 564.5, max: 966.1 ], Slowdowns: 0
... Dur(s): 60.2, Mode: GET, Ops: 31415, MB/s: 2087.69, IO/s: 522, Lat(ms): [ min: 5.9, avg: 28.4, 99%: 230.9, max: 682.7 ], Slowdowns: 0
... Dur(s): 14.0, Mode: DEL, Ops: 14879, MB/s: 4264.17, IO/s: 1066, Lat(ms): [ min: 7.5, avg: 15.0, 99%: 27.0, max: 49.1 ], Slowdowns: 0

1 рабочий процесс node.js, 4 потока hsbench, 4 МБ объекты:

./hsbench -a accessKey1 -s verySecretKey1 -u http://localhost:8000 -z 4M -t 4
... Dur(s): 60.0, Mode: PUT, Ops: 3699, MB/s: 246.45, IO/s: 62, Lat(ms): [ min: 35.3, avg: 64.9, 99%: 85.0, max: 192.0 ], Slowdowns: 0
... Dur(s): 60.3, Mode: LIST, Ops: 856, MB/s: 0.00, IO/s: 14, Lat(ms): [ min: 126.0, avg: 281.1, 99%: 430.6, max: 484.0 ], Slowdowns: 0
... Dur(s): 60.0, Mode: GET, Ops: 6399, MB/s: 426.43, IO/s: 107, Lat(ms): [ min: 5.8, avg: 35.7, 99%: 259.2, max: 289.3 ], Slowdowns: 0
... Dur(s): 10.9, Mode: DEL, Ops: 3699, MB/s: 1355.97, IO/s: 339, Lat(ms): [ min: 8.1, avg: 11.8, 99%: 18.2, max: 25.6 ], Slowdowns: 0

Заключение:

  • Производительность node.js хорошая. Скорость линейной записи составляет примерно ~250 МБ/с на процесс - наравне с Minio, реализованным на Go, с GOMAXPROCS=1 (т.е. с 1 потоком), запущенном на том же хосте - и органичена скорость в первую очередь вычислением MD5/SHA1 хешей.
  • Производительность с мелкими объектами, похоже, ограничена MongoDB, так что выглядит так, что MongoDB недостаточно быстра и нам нужен другой Key-Value бэкенд для метаданных объектов. Но этим мы займёмся в следующих выпусках! :)

Лицензия