POSIX действительно не подходит для объектных хранилищ? – CodesCode

Mожет ли POSIX действительно быть непригодным для объектных хранилищ? Окунитесь в анализ данных MinIO, s3fs-fuse и JuiceFS, чтобы узнать.

Автор этого поста ставит под сомнение точку зрения, выдвинутую в статье MinIO, в которой утверждается, что POSIX не подходит для объектных хранилищ. Он провел обширное тестирование, включающее MinIO s3fs-fuse и JuiceFS. Результаты показывают, что MinIO и JuiceFS демонстрируют отличную производительность, в то время как s3fs-fuse отстает. В случае перезаписи небольших файлов, JuiceFS FUSE-POSIX показывает лучшую производительность по сравнению со всеми остальными решениями.

Недавно я наткнулся на статью на блоге MinIO под названием “Поместить файловую систему над хранилищем объектов – это плохая идея. Вот почему.” Автор использовал s3fs-fuse в качестве примера, чтобы продемонстрировать проблемы с производительностью, с которыми сталкиваются при доступе к данным MinIO с использованием методов Portable Operating System Interface (POSIX), подчеркивая, что производительность значительно уступает прямому доступу к MinIO. Автор связывает эти проблемы производительности с врожденными недостатками POSIX. Тем не менее, наш опыт несколько отличается от данного вывода.

POSIX является полезным и широко применяемым стандартом. Разработка программного обеспечения в соответствии с POSIX гарантирует совместимость и переносимость на различные операционные системы. Большинство приложений в различных отраслях придерживаются стандарта POSIX. С развитием облачных вычислений, больших данных и технологий искусственного интеллекта, а также увеличением объема хранимых данных, возникает возросшая потребность в эластичных хранилищах, таких как объектные хранилища. Хотя объектные хранилища, такие как MinIO, предоставляют SDK на различных языках программирования, многие традиционные приложения испытывают трудности в адаптации своего кода для использования интерфейсов хранилища объектов. Это привело к тому, что различные продукты хранения реализовали интерфейсы POSIX над объектными хранилищами для удовлетворения этого неизменного спроса.

Многие продукты в этой отрасли, такие как Ceph, JuiceFS и Weka, успешно реализовали интерфейсы POSIX над объектными хранилищами. У этих решений есть большие пользовательские базы и множество примеров успеха, и они хорошо справляются с производительностью.

Хотя факт о том, что POSIX имеет значительную сложность, неоспорим, связанные с ним проблемы не являются непреодолимыми. С уважением и желанием проверить эти утверждения, я создал тестовую среду, использовал те же выборки данных и методы тестирования, что и в статье MinIO, и провел проверку.

Сравнение продуктов и цели тестирования

Чтобы предоставить всестороннюю оценку, я включил в сравнение JuiceFS.

JuiceFS – это распределенная файловая система, построенная на облачной основе. Она использует объектное хранилище в качестве слоя хранения данных и полагается на отдельную базу данных для хранения метаданных. Она предлагает различные способы доступа, включая API POSIX, API S3, драйвер CSI, API HDFS и WebDAV, а также уникальные механизмы фрагментации, кэширования и одновременного чтения/записи данных. JuiceFS – это файловая система, фундаментально отличная от инструментов, таких как s3fs-fuse, которые просто преобразуют хранилище объектов в протоколы POSIX.

Включив JuiceFS в сравнение, я стремился объективно оценить преимущества и недостатки реализации протоколов, таких как POSIX, над объектными хранилищами.

Я провел следующие два теста на MinIO, JuiceFS и s3fs-fuse:

Запись файла размером 10 ГБ
Перезапись небольших файлов с помощью Pandas

Все три решения использовали экземпляр MinIO, развернутый на отдельных серверах, в качестве базового хранилища. В качестве образцов для тестирования использовался файл размером 10 ГБ, который является тем же самым CSV-файлом, упомянутым в статье MinIO.

Все окружения, программное обеспечение, скрипты и образцы данных в этой статье поставляются с полным кодом и инструкциями, чтобы вы могли воспроизвести окружение и результаты тестирования.

Настройка сервера и тестового окружения

Два идентично настроенных облачных сервера:

Система: Ubuntu 22.04 x64
ЦПУ: 8 ядер
ОЗУ: 16 ГБ
SSD: 500 ГБ
Сеть: VPC

Информация о каждом сервере:

Сервер	IP-адрес	Назначение
Сервер А	172.16.254.18	Развертывание экземпляра MinIO
Сервер B	172.16.254.19	В качестве тестового окружения

Подготовка сервера А

1. Я развернул MinIO на сервере А с использованием Docker с помощью следующих команд:

# Создаем отдельный каталог и переходим в него.mkdir minio && cd minio# Создаем файл конфигурации.mkdir configtouch config/minio

2. Я записал следующую информацию в файл config/minio:

MINIO_ROOT_USER=adminMINIO_ROOT_PASSWORD=abc123abcMINIO_VOLUMES="/mnt/data"

3. Я создал контейнер MinIO:

sudo docker run -d --name minio \  -p 9000:9000 \  -p 9090:9090 \  -v /mnt/minio-data:/mnt/data \  -v ./config/minio:/etc/config.env \  -e "MINIO_CONFIG_ENV_FILE=/etc/config.env" \  --restart unless-stopped \  minio/minio server --console-address ":9090"

4. На веб-консоли MinIO я предварительно создал три бакета:

Имя бакета	Назначение
test-minio	Для тестирования MinIO
test-juicefs	Для тестирования JuiceFS
test-s3fs	Для тестирования `s3fs-fuse`

Подготовка сервера Б

1. Я загрузил файл тестового образца размером 10 ГБ.

curl -LO https://data.cityofnewyork.us/api/views/t29m-gskq/rows.csv?accessType=DOWNLOAD

2. Я установил клиент mc.

mc – это командный файловый менеджер, разработанный проектом MinIO. Он позволяет выполнять операции чтения и записи как на локальном, так и на совместимом с S3 хранилище объектов в командной строке Linux. Команда mc cp предоставляет информацию о прогрессе и скорости копирования данных в режиме реального времени, что облегчает наблюдение за различными тестами.

Примечание: Чтобы обеспечить честность тестирования, все три подхода используют mc для тестирования записи файлов.

# Загрузка mc.wget https://dl.min.io/client/mc/release/linux-amd64/mc# Проверка версии mc.mc -vmc version RELEASE.2023-09-20T15-22-31Z (commit-id=38b8665e9e8649f98e6162bdb5163172e6ecc187)Runtime: go1.21.1 linux/amd64# Установка mc.sudo install mc /usr/bin# Задание псевдонима для MinIO.mc alias set my http://172.16.254.18:9000 admin abc123abc

3. Я загрузил s3fs-fuse.

sudo apt install s3fs# Проверка версии.s3fs --versionAmazon Simple Storage Service File System V1.93 (commit:unknown) with OpenSSL# Задание ключа доступа к хранилищу объектов.echo admin:abc123abc >  ~/.passwd-s3fs# Изменение разрешений для ключевого файла.chmod 600  ~/.passwd-s3fs# Создание точки монтирования.mkdir mnt-s3fs# Монтирование хранилища объектов.s3fs test-s3fs:/ /root/mnt-s3fs -o url=http://172.16.254.18:9000 -o use_path_request_style

4. Я установил JuiceFS.

Я использовал официальный скрипт для установки последней версии JuiceFS Community Edition.

# Скрипт однократной установкиcurl -sSL https://d.juicefs.com/install | sh -# Проверка версии.juicefs versionjuicefs version 1.1.0+2023-09-04.08c4ae6

5. Я создал файловую систему. JuiceFS – это файловая система, которую необходимо создать перед использованием. Кроме хранилища объектов, она требует базу данных в качестве движка метаданных. Она поддерживает различные базы данных. Здесь я использовал распространенную Redis в качестве движка метаданных.

Примечание: Я установил Redis на сервере А, доступном по адресу 172.16.254.18:6379 без пароля. Процесс установки опущен здесь. Вы можете обратиться к документации Redis для получения подробной информации.

# Создание файловой системы.juicefs format --storage minio \--bucket http://172.16.254.18:9000/test-juicefs \--access-key admin \--secret-key abc123abc \--trash-days 0 \redis://172.16.254.18/1 \myjfs

6. Я получил доступ к JuiceFS, используя более распространенные методы API POSIX и S3 и протестировал их производительность.

# Создание каталогов для монтирования.mkdir ~/mnt-juicefs# Монтирование файловой системы в режиме POSIX.juicefs mount redis://172.16.254.18/1 /root/mnt-juicefs# Доступ к файловой системе с использованием метода API S3.export MINIO_ROOT_USER=adminexport MINIO_ROOT_PASSWORD=abc123abcjuicefs gateway redis://172.16.254.18/1 0.0.0.0:9000# Установка псевдонима для JuiceFS S3 API в mc.mc alias set juicefs http://172.16.254.18:9000 admin abc123abc

Примечание: Шлюз JuiceFS также может быть развернут на Сервере А или любом другом сервере с доступом в Интернет, так как он предоставляет сетевой S3 API.

Тесты и результаты

Вот краткое изложение моих тестов и результатов:

Тест	MinIO	S3FS-FUSE	JuiceFS(FUSE)	JuiceFS(S3 шлюз)
Запись файла размером 10 ГБ	0м27.651с	3м6.380с	0м28.107с	0м28.091с
Перезапись небольших файлов с использованием Pandas	0.83с	0.78с	0.46с	0.96с

Тест 1: Запись файла размером 10 ГБ

Этот тест был разработан для оценки производительности записи больших файлов. Чем меньше занимает время, тем лучше производительность. Я использовал команду time для измерения длительности операций записи, предоставляя три метрики:

real: Фактическое время от начала до конца выполнения команды. Включает все время ожидания, такие как ожидание завершения операций ввода-вывода, ожидание переключения процессов и ожидание ресурсов.
user: Время выполнения в пользовательском режиме, указывающее время ЦП, используемое для выполнения пользовательского кода. Обычно представляет вычислительную нагрузку команды.
sys: Время выполнения в режиме ядра, указывающее время ЦП, используемое для выполнения кода ядра. Обычно представляет рабочую нагрузку, связанную с системными вызовами, такими как ввод-вывод файлов и управление процессами.

MinIO

Я выполнил следующую команду для выполнения теста копирования:

time mc cp ./2018_Yellow_Taxi_Trip_Data.csv  my/test-minio/

Результаты записи файла размером 10 ГБ напрямую в MinIO:

real    0м27.651сuser    0м10.767сsys 0м5.439с

s3fs-fuse

Я выполнил следующую команду для выполнения теста копирования:

time mc cp ./2018_Yellow_Taxi_Trip_Data.csv /root/mnt-s3fs/

Результаты записи файла размером 10 ГБ напрямую в s3fs-fuse:

real 3м6.380сuser 0м0.012сsys 0м5.459с

Примечание: Хотя время записи составило 3 минуты и 6 секунд для s3fs-fuse, не было отказов при записи, как описано в статье MinIO.

JuiceFS

Я протестировал производительность JuiceFS для записи больших файлов с использованием методов API POSIX и S3:

# Тест записи POSIXtime mc cp ./2018_Yellow_Taxi_Trip_Data.csv /root/mnt-juicefs/# Тест записи S3 APItime mc cp ./2018_Yellow_Taxi_Trip_Data.csv  juicefs/myjfs/

Результаты для JuiceFS при записи файла размером 10 ГБ в режиме POSIX:

real    0м28.107сuser    0м0.292сsys 0м6.930с

Результаты для записи 10-гигабайтного файла через API JuiceFS S3:

реальное время 0м28.091с, пользовательское время 0м13.643с, системное время 0м4.142с

Сводка результатов записи больших файлов

На следующей схеме показаны результаты теста:

Результаты записи больших файлов (чем ниже, тем лучше)

Результаты теста показывают, что как прямая запись в MinIO, так и JuiceFS показывают сопоставимую производительность, выполняя задачу примерно за 30 секунд. В отличие от этого, s3fs-fuse потребовало более 3 минут для записи 10-гигабайтного файла, что примерно в 6 раз медленнее, чем первые два варианта.

При записи больших файлов mc использует метод Multipart API для загрузки файлов пакетами в интерфейс S3. В свою очередь, s3fs-fuse может записывать только в POSIX в однопотоковом режиме. JuiceFS также автоматически разбивает большие файлы на фрагменты и одновременно записывает их в MinIO во время последовательной записи, обеспечивая производительность, сравнимую с прямой записью в MinIO. S3FS, с другой стороны, сначала записывает в кэширующий диск в одном потоке, а затем загружает файл пакетами в MinIO, что приводит к более длительному времени записи.

Исходя из расчета, что на запись 10-гигабайтного файла потребовалось 30 секунд, средняя скорость составляла 333 МБ/с. Это ограничено пропускной способностью SSD-дисков облачных серверов. Эти результаты тестов указывают на то, что как MinIO, так и JuiceFS могут максимально использовать пропускную способность локальных SSD, и их производительность улучшится с улучшением облачных дисков серверов и пропускной способности сети.

Тест 2: Перезапись маленьких файлов с помощью Pandas

Этот тест оценивал производительность систем хранения объектов в сценариях перезаписи маленьких файлов. Скрипты тестов для каждого программного обеспечения немного отличались. Вы можете найти весь код скрипта здесь.

MinIO

Я получил тестовый скрипт и запустил тест:

# Получить тестовый скрипт.curl -LO https://gist.githubusercontent.com/yuhr123/7acb7e6bb42fb0ff12f3ba64d2cdd7da/raw/30c748e20b56dec642a58f9cccd7ea6e213dab3c/pandas-minio.py# Выполнить тест.python3 pandas-minio.py

Результат был следующим:

Время выполнения: 0.83 секунды

s3fs-fuse

Я получил тестовый скрипт и запустил тест:

# Получить тестовый скрипт.curl -LO gist.githubusercontent.com/yuhr123/7acb7e6bb42fb0ff12f3ba64d2cdd7da/raw/30c748e20b56dec642a58f9cccd7ea6e213dab3c/pandas-s3fs.py# Выполнить тест.python3 pandas-s3fs.py

Результат теста был следующим:

Время выполнения: 0.78 секунды

JuiceFS POSIX

Я получил тестовый скрипт и запустил тест:

# Получить тестовый скрипт.curl -LO gist.githubusercontent.com/yuhr123/7acb7e6bb42fb0ff12f3ba64d2cdd7da/raw/30c748e20b56dec642a58f9cccd7ea6e213dab3c/pandas-juicefs-posix.py# Выполнить тест.python3 pandas-juicefs-posix.py

Результат теста был следующим:

Время выполнения: 0.43 секунды

JuiceFS S3 API

Я получил тестовый скрипт и запустил тест:

# Получить тестовый скрипт.curl -LO https://gist.githubusercontent.com/yuhr123/7acb7e6bb42fb0ff12f3ba64d2cdd7da/raw/30c748e20b56dec642a58f9cccd7ea6e213dab3c/pandas-juicefs-s3api.py# Выполнить тест.python3 pandas-juicefs-s3api.py

Результат теста был следующим:

Время выполнения: 0.86 секунды

Сводка по перезаписи малых файлов в Pandas

На следующей фигуре показаны результаты теста:

Результаты перезаписи в Pandas (чем ниже, тем лучше)

В этом тесте JuiceFS FUSE-POSIX продемонстрировал самую быструю скорость, почти вдвое быстрее других решений. MinIO, s3fs-fuse и JuiceFS S3 Gateway обладают схожей производительностью. С точки зрения перезаписи малых файлов, интерфейс POSIX оказался более эффективным и обеспечил лучшую производительность по сравнению с интерфейсами объектного хранения.

Проблемы и анализ

Проблема 1: Почему S3FS работает так медленно?

Анализ: Из данных теста явно видно, что для записи одного и того же файла объемом 10 ГБ S3FS затратил 3 минуты, в то время как MinIO и JuiceFS выполнили задачу за примерно 30 секунд. Это значительная разница в производительности, вызванная в первую очередь различными техническими реализациями. При записи файла s3fs-fuse сначала записывает его во временный локальный файл, а затем передает его в объектное хранилище порциями. Если места на локальном диске недостаточно, происходит синхронная передача. В этом случае требуется копирование данных между локальным диском и хранилищем S3. Поэтому при записи больших файлов или большого количества файлов производительность снижается.

Кроме того, S3FS полагается на возможности управления метаданными основного объектного хранилища. При работе с большим числом файлов частые взаимодействия с объектным хранилищем для получения метаданных значительно влияют на производительность. Проще говоря, чем больше размер файла и общее количество файлов, записанных в S3FS, тем больше пропорциональные накладные расходы на производительность.

Проблема 2: Почему JuiceFS работает быстрее?

Анализ: В тесте и JuiceFS, и S3FS использовали FUSE для чтения и записи. JuiceFS полностью использует пропускную способность диска, как и MinIO, но при этом не возникает проблем с производительностью, которые есть у S3FS.

Ответ кроется в их технической архитектуре. В то время как данные обрабатываются через слой FUSE во время записи файла, JuiceFS использует высокую параллельность, кэширование и технику фрагментирования данных для снижения накладных расходов на связь между слоем FUSE и основным объектным хранилищем. Это позволяет JuiceFS обрабатывать одновременно больше запросов на чтение и запись файлов, сокращая время ожидания и задержку передачи.

Кроме того, JuiceFS использует специализированную базу данных (в данном случае Redis) для управления метаданными. При работе с особенно большим количеством файлов независимый метаданный движок эффективно снимает нагрузку и позволяет быстрее выполнить поиск файлов.

Вывод

Вышеописанные тесты показывают, что использование объектного хранилища в качестве основы и реализация интерфейса POSIX повлекло лишь незначительное снижение производительности. Независимо от того, пишете ли вы большие или малые файлы, JuiceFS обладает производительностью сравнимой с напрямую записываемыми файлами в MinIO без какого-либо снижения производительности основного объектного хранилища из-за доступа через POSIX. Более того, в случае перезаписи таблиц Pandas производительность JuiceFS FUSE-POSIX остается стабильной и превосходит MinIO почти вдвое.

Результаты теста указывают на то, что некоторое программное обеспечение, такое как s3fs-fuse, может иметь снижение производительности при конвертировании между интерфейсами S3 API и POSIX. В то время как это может быть удобным инструментом для временного доступа к S3, для стабильного и высокопроизводительного долгосрочного использования необходимо тщательное исследование и проверка для выбора более подходящих решений.

Для простого архивирования неструктурированных файлов хорошим выбором является прямое использование MinIO или облачного объектного хранилища. Однако для сценариев, которые включают хранение и обработку данных большого объема, таких как обучение моделей AI, анализ больших данных, сохранение данных в Kubernetes и другие частые операции чтения и записи, независимое управление метаданными JuiceFS, возможности параллельного чтения и записи, а также механизмы кэширования обеспечивают превосходную производительность. Это высокопроизводительное решение файловой системы, заслуживающее внимания.