¿Es realmente inadecuado POSIX para los almacenes de objetos? Una respuesta respaldada por datos

El autor de este post cuestiona la perspectiva presentada en un artículo de MinIO, que sugiere que POSIX no es una opción adecuada para almacenes de objetos. Realizó pruebas exhaustivas que involucraron a MinIO s3fs-fuse y JuiceFS. Los resultados indican que MinIO y JuiceFS ofrecen un excelente rendimiento, mientras que s3fs-fuse se queda atrás. En escenarios de sobrescritura de archivos pequeños, JuiceFS FUSE-POSIX supera a otras soluciones.

Recientemente, encontré un artículo en el blog de MinIO titulado “Poner un sistema de archivos encima de un almacén de objetos es una mala idea. Aquí está el porqué.” El autor utilizó s3fs-fuse como ejemplo para ilustrar los desafíos de rendimiento encontrados al acceder a los datos de MinIO utilizando métodos de la Interfaz de Sistemas Operativos Portátiles (POSIX), destacando que el rendimiento se quedó significativamente atrás en comparación con el acceso directo a MinIO. El autor atribuyó estos problemas de rendimiento a defectos inherentes en POSIX. Sin embargo, nuestra experiencia difiere un poco de esta conclusión.

POSIX es una norma útil y ampliamente adoptada. Desarrollar software siguiendo POSIX garantiza compatibilidad y portabilidad entre diferentes sistemas operativos. La mayoría de las aplicaciones en varios sectores se adhieren a la norma POSIX. Con el avance de la computación en la nube, big data y tecnologías de inteligencia artificial, así como el aumento del volumen de datos almacenados, existe una creciente demanda de soluciones de almacenamiento elástico como los almacenes de objetos. Aunque los almacenes de objetos como MinIO proporcionan SDK en múltiples lenguajes, muchas aplicaciones tradicionales luchan por adaptar su código para usar las API de almacenamiento de objetos. Esto ha llevado a varios productos de almacenamiento a implementar interfaces POSIX sobre los almacenes de objetos para satisfacer esta demanda inflexible.

Muchos productos en la industria, como Ceph, JuiceFS y Weka, han implementado con éxito interfaces POSIX sobre almacenes de objetos. Estas soluciones tienen bases de usuarios grandes y numerosos casos de éxito, y funcionan bien en términos de rendimiento.

Si bien es cierto que POSIX tiene una complejidad significativa, los problemas asociados no son insuperables. Con respeto y un deseo de verificar estas afirmaciones, configuré un entorno de prueba, empleé los mismos datos de muestra y métodos de prueba que en el artículo de MinIO, y llevé a cabo una validación.

Productos Comparados y Objetivos de la Prueba

Para proporcionar una evaluación integral, introduje JuiceFS en la comparación.

JuiceFS es un sistema de archivos distribuido de código abierto y nativo de la nube. Utiliza el almacenamiento de objetos como capa de almacenamiento de datos y depende de una base de datos separada para almacenar metadatos. Ofrece varios métodos de acceso, incluyendo API POSIX, API S3, Controlador CSI, API HDFS y WebDAV, junto con mecanismos únicos de particionamiento de datos, almacenamiento en caché y lectura/escritura concurrente. JuiceFS es un sistema de archivos, fundamentalmente diferente de herramientas como s3fs-fuse, que simplemente convierten desde el almacenamiento de objetos a protocolos POSIX.

Al introducir JuiceFS en la comparación, mi objetivo fue evaluar objetivamente las ventajas y desventajas de implementar protocolos como POSIX sobre almacenamiento de objetos.

I conducted the following two tests on MinIO, JuiceFS, and s3fs-fuse:

• Escribir un archivo de 10 GB
• Sobreescribir archivos pequeños con Pandas

Las tres soluciones utilizaron una instancia de MinIO desplegada en servidores separados como almacenamiento subyacente. Para las muestras de prueba, se utilizó un archivo de 10 GB, que era el mismo archivo CSV mencionado en el artículo de MinIO.

Todas las configuraciones de entorno, software, scripts y datos de muestra en este artículo vienen con código completo e instrucciones para garantizar que puedas reproducir el entorno y los resultados de la prueba.

Configuración del servidor y entorno de prueba

Dos servidores de la nube configurados de manera idéntica:

• Sistema: Ubuntu 22.04 x64
• CPU: 8 núcleos
• RAM: 16 GB
• SSD: 500 GB
• Red: VPC

La información de cada servidor:

Preparación del Servidor A

1. Implementé MinIO en el Servidor A utilizando Docker con los siguientes comandos:

# Crear un directorio dedicado y navegar a él.
mkdir minio && cd minio

# Crear un archivo de configuración.
mkdir config
touch config/minio

2. Escribí la siguiente información en el archivo config/minio:

MINIO_ROOT_USER=admin
MINIO_ROOT_PASSWORD=abc123abc
MINIO_VOLUMES="/mnt/data"

3. Creé el contenedor de 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 a menos que se detenga \
  minio/minio server --console-address ":9090"

4. En la Consola Web de MinIO, precreé tres buckets:

Preparación del Servidor B

1. Descargué el archivo de muestra de prueba de 10 GB.

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

2. Instalé el cliente mc.

mc es un administrador de archivos de línea de comandos desarrollado por el proyecto MinIO. Permite operaciones de lectura y escritura tanto en almacenamiento de objetos compatible con S3 como en el almacenamiento local en la línea de comandos de Linux. El comando mc cp proporciona actualizaciones en tiempo real de progreso y velocidad durante la copia de datos, lo que facilita la observación de varios tests.

Nota: Para mantener la equidad de la prueba, los tres enfoques utilizaron mc para las pruebas de escritura de archivos.

# Descargar mc.
wget https://dl.min.io/client/mc/release/linux-amd64/mc

# Verificar la versión de mc.
mc -v
mc version RELEASE.2023-09-20T15-22-31Z (commit-id=38b8665e9e8649f98e6162bdb5163172e6ecc187)
Runtime: go1.21.1 linux/amd64

# Instalar mc.
sudo install mc /usr/bin

# Establecer un alias para MinIO.
mc alias set my http://172.16.254.18:9000 admin abc123abc

3. Descargué s3fs-fuse.

sudo apt install s3fs

# Verificar la versión.
s3fs --version
Amazon Simple Storage Service File System V1.93 (commit:unknown) with OpenSSL

# Establecer la clave de acceso de almacenamiento de objetos.
echo admin:abc123abc >  ~/.passwd-s3fs

# Modificar los permisos del archivo clave.
chmod 600  ~/.passwd-s3fs

# Crear el directorio de montaje.
mkdir mnt-s3fs

# Montar el almacenamiento de objetos.
s3fs test-s3fs:/ /root/mnt-s3fs -o url=http://172.16.254.18:9000 -o use_path_request_style

4. Instalé JuiceFS.

I used the official script to install the latest JuiceFS Community Edition.

# Script de instalación de un solo clic
curl -sSL https://d.juicefs.com/install | sh -

# Verificar la versión.
juicefs version
juicefs version 1.1.0+2023-09-04.08c4ae6

5. Creé un sistema de archivos. JuiceFS es un sistema de archivos que debe ser creado antes de su uso. Además de almacenamiento de objetos, requiere una base de datos como motor de metadatos. Es compatible con diversas bases de datos. Aquí, utilicé Redis, comúnmente utilizado, como motor de metadatos.

Nota: He instalado Redis en el Servidor A, accesible a través de 172.16.254.18:6379 sin contraseña. El proceso de instalación se omite aquí. Puedes referirte a la documentación de Redis para detalles.

# Crear el sistema de archivos.
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. Accedí a JuiceFS utilizando los métodos más comunes de API POSIX y S3 y probé su rendimiento.

# Crear directorios de montaje.
mkdir ~/mnt-juicefs

# Montar el sistema de archivos en modo POSIX.
juicefs mount redis://172.16.254.18/1 /root/mnt-juicefs

# Acceder al sistema de archivos utilizando el método de API S3.
export MINIO_ROOT_USER=admin
export MINIO_ROOT_PASSWORD=abc123abc
juicefs gateway redis://172.16.254.18/1 0.0.0.0:9000

# Establecer un alias para la API S3 de JuiceFS en mc.
mc alias set juicefs http://172.16.254.18:9000 admin abc123abc

Nota: El Gateway de JuiceFS también puede ser desplegado en el Servidor A o en cualquier otro servidor accesible por internet ya que expone una API S3 basada en red.

Pruebas y Resultados

Aquí hay un resumen rápido de mis pruebas y resultados:

Prueba 1: Escribir un archivo de 10 GB

Esta prueba fue diseñada para evaluar el rendimiento de escribir archivos grandes. Cuanto menor sea el tiempo tomado, mejor será el rendimiento. Utilicé el comando time para medir la duración de las operaciones de escritura, proporcionando tres métricas:

• real: El tiempo real desde el inicio hasta el final del comando. Incluye todos los tiempos de espera, como la espera para que se completen operaciones de E/S, la espera para cambios de proceso y la espera de recursos.
• user: El tiempo ejecutado en modo usuario, que indica el tiempo de CPU utilizado para ejecutar código de usuario. Generalmente representa la carga de trabajo computacional del comando.
• sys: El tiempo ejecutado en modo kernel, que indica el tiempo de CPU utilizado para ejecutar código de kernel. Generalmente representa la carga de trabajo relacionada con las llamadas al sistema, como E/S de archivos y gestión de procesos.

MinIO

I ran the following command to perform a copy test:

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

Resultados de escribir un archivo de 10 GB directamente en MinIO:

real    0m27.651s
user    0m10.767s
sys 0m5.439s

s3fs-fuse

I ran the following command to perform a copy test:

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

Resultados de escribir un archivo de 10 GB directamente en s3fs-fuse:

real 3m6.380s
user 0m0.012s
sys 0m5.459s

Nota: Aunque el tiempo de escritura fue de 3 minutos y 6 segundos para s3fs-fuse, no hubo fallos de escritura como se describe en el artículo de MinIO.

JuiceFS

I tested the performance of JuiceFS for large file writes using both the POSIX and S3 API methods:

# Prueba de escritura POSIX
time mc cp ./2018_Yellow_Taxi_Trip_Data.csv /root/mnt-juicefs/

# Prueba de escritura API S3
time mc cp ./2018_Yellow_Taxi_Trip_Data.csv  juicefs/myjfs/

Resultados de la escritura POSIX de JuiceFS de un archivo de 10 GB:

real    0m28.107s
user    0m0.292s
sys 0m6.930s

Resultados de la escritura API S3 de JuiceFS de un archivo de 10 GB:

real    0m28.091s
user    0m13.643s
sys 0m4.142s

Resumen de los Resultados de Escritura de Archivos Grandes

La siguiente figura muestra los resultados de la prueba:

Los resultados de la prueba muestran que tanto la escritura directa a MinIO como a JuiceFS ofrecieron un rendimiento comparable, completando la tarea en aproximadamente 30 segundos. Por otro lado, s3fs-fuse tardó más de 3 minutos en escribir un archivo de 10 GB, lo que fue aproximadamente seis veces más lento que los dos primeros.

Al escribir archivos grandes, mc utiliza la API de Multipart para subir archivos en trozos a la interfaz de S3. Por el contrario, s3fs-fuse solo puede escribir en POSIX en un solo hilo. JuiceFS también divide automáticamente archivos grandes en trozos y los escribe de manera concurrente en MinIO durante escrituras secuenciales, asegurando un rendimiento comparable a las escrituras directas en MinIO. Por otro lado, S3FS primero escribe en un disco caché en un solo hilo y luego sube el archivo en trozos a MinIO, lo que resulta en tiempos de escritura más largos.

Basándose en el cálculo de que se tardaron 30 segundos en escribir un archivo de 10 GB, la velocidad promedio fue de 333 MB/s. Esto estuvo limitado por el ancho de banda de los SSD de servidor en la nube. Estos resultados de prueba indicaron que tanto MinIO como JuiceFS podrían maximizar el ancho de banda del SSD local, y su rendimiento mejoraría con mejoras en los discos de servidor en la nube y el ancho de banda de la red.

Prueba 2: Sobrescribir Archivos Pequeños Con Pandas

Esta prueba evaluó el rendimiento de los sistemas de almacenamiento de objetos en escenarios de sobrescritura de archivos pequeños. Los scripts de prueba para cada software difirieron ligeramente. Puedes encontrar todo el código del script aquí.

MinIO

I got the test script and ran the test:

# Obtener el script de prueba.
curl -LO https://gist.githubusercontent.com/yuhr123/7acb7e6bb42fb0ff12f3ba64d2cdd7da/raw/30c748e20b56dec642a58f9cccd7ea6e213dab3c/pandas-minio.py

# Ejecutar la prueba.
python3 pandas-minio.py

El resultado fue el siguiente:

Execution time: 0.83 seconds

s3fs-fuse

I got the test script and ran the test:

# Obtener el script de prueba.
curl -LO gist.githubusercontent.com/yuhr123/7acb7e6bb42fb0ff12f3ba64d2cdd7da/raw/30c748e20b56dec642a58f9cccd7ea6e213dab3c/pandas-s3fs.py

# Ejecutar la prueba.
python3 pandas-s3fs.py

El resultado de la prueba fue el siguiente:

Execution time: 0.78 seconds

JuiceFS POSIX

I got the test script and ran the test:

# Obtener el script de prueba.
curl -LO gist.githubusercontent.com/yuhr123/7acb7e6bb42fb0ff12f3ba64d2cdd7da/raw/30c748e20b56dec642a58f9cccd7ea6e213dab3c/pandas-juicefs-posix.py

# Ejecutar la prueba.
python3 pandas-juicefs-posix.py

El resultado de la prueba fue el siguiente:

Execution time: 0.43 seconds

API de JuiceFS S3

I got the test script and ran the test:

# Obtener el script de prueba.
curl -LO https://gist.githubusercontent.com/yuhr123/7acb7e6bb42fb0ff12f3ba64d2cdd7da/raw/30c748e20b56dec642a58f9cccd7ea6e213dab3c/pandas-juicefs-s3api.py

# Ejecutar la prueba.
python3 pandas-juicefs-s3api.py

El resultado de la prueba fue el siguiente:

Execution time: 0.86 seconds

Resumen de Sobrescribir Archivos Pequeños de Pandas

La siguiente figura muestra los resultados de la prueba:

En esta prueba, JuiceFS FUSE-POSIX demostró la velocidad más rápida, casi el doble de rápida que las otras soluciones. MinIO, s3fs-fuse, y JuiceFS S3 Gateway exhibieron un rendimiento similar. Desde la perspectiva de sobrescritura de archivos pequeños, la interfaz POSIX resultó más eficiente, ofreciendo un mejor rendimiento que las interfaces de almacenamiento de objetos.

Problemas y Análisis

Problema 1: ¿Por qué S3FS fue tan lento?

Análisis: A partir de los datos de la prueba, está claro que al escribir el mismo archivo de 10 GB, S3FS tardó 3 minutos, mientras que MinIO y JuiceFS completaron la tarea en alrededor de 30 segundos. Esta diferencia de rendimiento significativa se debió principalmente a diferentes implementaciones técnicas. Cuando s3fs-fuse escribe un archivo, primero escribe el archivo en un archivo temporal local y luego lo sube al almacenamiento de objetos en fragmentos. Si no hay suficiente espacio en el disco local, lo sube de manera sincrónica. Necesita copiar datos entre el disco local y el almacenamiento S3. Por lo tanto, archivos grandes o un gran número de archivos resultan en una degradación del rendimiento.

Además, S3FS depende de las capacidades de gestión de metadatos del almacenamiento de objetos subyacente. Al tratar con un gran número de archivos, la interacción frecuente con el almacenamiento de objetos para recuperar metadatos tiene un impacto significativo en el rendimiento. En términos sencillos, cuanto mayor sea el tamaño de los archivos y la cantidad total de archivos escritos en S3FS, mayor será la sobrecarga de rendimiento proporcional.

Problema 2: ¿Por Qué Fue Más Rápido JuiceFS?

Análisis: En la prueba, tanto JuiceFS como S3FS utilizaron FUSE para lectura y escritura. JuiceFS utilizó al máximo el ancho de banda del disco como MinIO, pero no experimentó problemas de rendimiento como los de S3FS.

La respuesta radica en sus respectivas arquitecturas técnicas. Mientras que los datos se procesan a través de la capa FUSE durante la escritura de archivos, JuiceFS emplea técnicas de alta concurrencia, caché y fragmentación de datos para reducir la sobrecarga de comunicación entre la capa FUSE y el almacenamiento de objetos subyacente. Esto permite a JuiceFS manejar más solicitudes de lectura y escritura de archivos simultáneamente, reduciendo los tiempos de espera y la latencia de transmisión.

Además, JuiceFS emplea una base de datos dedicada (en este caso, Redis) para gestionar metadatos. Al tratar con un número particularmente grande de archivos, un motor de metadatos independiente puede aliviar eficazmente la carga de trabajo, permitiendo una ubicación de archivos más rápida.

Conclusión

Los tests anteriores demuestran que utilizar el almacenamiento de objetos como base e implementar una interfaz POSIX encima de él no necesariamente causa una pérdida de rendimiento. Ya sea escribiendo archivos grandes o pequeños, JuiceFS muestra un rendimiento comparable a las escrituras directas de MinIO sin ninguna degradación en el rendimiento del almacenamiento de objetos subyacente debido al acceso POSIX. Además, en términos de sobrescrituras de tablas de Pandas, el rendimiento de JuiceFS FUSE-POSIX se mantiene consistente e incluso supera a MinIO casi al doble.

Los resultados de las pruebas indican que algunos software, como s3fs-fuse, pueden experimentar una degradación del rendimiento al convertir entre las API de S3 y las interfaces POSIX. Aunque puede ser una herramienta conveniente para el acceso temporal a S3, para un uso a largo plazo estable y de alto rendimiento, es necesario realizar una cuidadosa investigación y validación para seleccionar soluciones más adecuadas.

Para el archivado de archivos no estructurados simples, el uso directo de MinIO o el almacenamiento de objetos en la nube es una buena opción. Sin embargo, para escenarios que involucran el almacenamiento y procesamiento de datos a gran escala, como el entrenamiento de modelos de IA, el análisis de big data, la persistencia de datos de Kubernetes y otras operaciones de lectura y escritura frecuentes, la gestión independiente de metadatos de JuiceFS, las capacidades de lectura y escritura concurrentes y los mecanismos de caché proporcionan un rendimiento superior. Es una solución de sistema de archivos de alto rendimiento que vale la pena considerar.