Is POSIX Echt Ongeschikt voor Object Stores? Een Gegevensgestuurd Antwoord

De auteur van deze post stelt de visie in een artikel van MinIO ter discussie, dat suggereert dat POSIX niet een geschikte keuze is voor object stores. Hij voerde uitgebreide tests uit met betrekking tot MinIO s3fs-fuse en JuiceFS. De resultaten wijzen uit dat MinIO en JuiceFS uitstekende prestaties leveren, terwijl s3fs-fuse achterblijft. In scenario’s met het overschrijven van kleine bestanden, presteert JuiceFS FUSE-POSIX beter dan andere oplossingen.

Onlangs kwam ik een artikel tegen op de MinIO blog getiteld “Het plaatsen van een bestandssysteem bovenop een object store is een slecht idee. Hier is waarom.” De auteur gebruikte s3fs-fuse als voorbeeld om de prestatieproblemen te illustreren die optreden bij toegang tot MinIO-gegevens met behulp van Portable Operating System Interface (POSIX) methoden, waarbij hij benadrukte dat de prestaties aanzienlijk achterliepen bij directe MinIO-toegang. De auteur schreef deze prestatieproblemen toe aan inherente tekortkomingen in POSIX. Echter, onze ervaring wijkt enigszins af van deze conclusie.

POSIX is een nuttig en breed geaccepteerd standaard. Het ontwikkelen van software volgens POSIX garandeert compatibiliteit en draagbaarheid tussen verschillende besturingssystemen. De meeste applicaties in diverse industrieën houden zich aan de POSIX-standaard. Met de vooruitgang van cloud computing, big data en AI-technologieën, en de toenemende hoeveelheid gegevens die wordt opgeslagen, is er een groeiende vraag naar elastische opslagoplossingen zoals object stores. Hoewel object stores zoals MinIO SDK’s in meerdere talen aanbieden, hebben veel traditionele applicaties moeite om hun code aan te passen om object storage API’s te gebruiken. Dit heeft geleid tot verschillende opslagproducten die POSIX-interfaces bovenop object stores implementeren om deze starre vraag te voldoen.

Veel producten in de industrie, zoals Ceph, JuiceFS en Weka, hebben succesvol POSIX-interfaces op object stores geïmplementeerd. Deze oplossingen hebben grote gebruikersbases en talrijke succesverhalen, en presteren goed qua prestaties.

Hoewel het waar is dat POSIX aanzienlijke complexiteit heeft, zijn de daarmee samenhangende problemen niet onoverkomelijk. Met respect en de wens om deze beweringen te verifiëren, heb ik een testomgeving opgezet, dezelfde voorbeeldgegevens en testmethoden gebruikt als in het MinIO-artikel, en een validatie uitgevoerd.

Producten vergeleken en testdoelstellingen

Om een uitgebreid beeld te geven, heb ik JuiceFS aan de vergelijking toegevoegd.

JuiceFS is een open-source, cloud-native gedistribueerde bestandssysteem. Het maakt gebruik van objectopslag als zijn gegevensopslaglaag en vertrouwt op een afzonderlijke database voor het opslaan van metadata. Het biedt verschillende toegangsmethoden, waaronder POSIX API, S3 API, CSI Driver, HDFS API en WebDAV, samen met unieke gegevensblokken, caching en gelijktijdige lees-/schrijfmachanismen. JuiceFS is een bestandssysteem, fundamenteel anders dan tools zoals s3fs-fuse, die slechts converteren van objectopslag naar POSIX-protocollen.

Door JuiceFS in de vergelijking te introduceren, wilde ik objectief de voordelen en nadelen evalueren van het implementeren van protocollen zoals POSIX bovenop objectopslag.

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

• Het schrijven van een 10 GB bestand
• Het overschrijven van kleine bestanden met Pandas

Alle drie de oplossingen maakten gebruik van een MinIO-instantie die op afzonderlijke servers was geïmplementeerd als onderliggende opslag. Voor de testmonsters werd een 10 GB bestand gebruikt, dat hetzelfde CSV-bestand was dat in het MinIO-artikel werd genoemd.

Alle omgevingen, software, scripts en voorbeeldgegevens in dit artikel worden geleverd met volledige code en instructies om ervoor te zorgen dat u de omgeving en testresultaten kunt reproduceren.

Server en Testomgeving Setup

Twee identiek geconfigureerde cloudservers:

• Systeem: Ubuntu 22.04 x64
• CPU: 8 kernen
• RAM: 16 GB
• SSD: 500 GB
• Netwerk: VPC

De informatie voor elke server:

Server A Voorbereiding

1. Ik heb MinIO geïmplementeerd op Server A met Docker met de volgende commando’s:

# Maak een toegewezen directory aan en navigeer naar deze.
mkdir minio && cd minio

# Maak een configuratiebestand aan.
mkdir config
touch config/minio

2. Schreef ik de volgende informatie naar het config/minio bestand:

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

3. Heb ik de MinIO container gemaakt:

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. Op de Web Console van MinIO, heb ik drie buckets vooraf aangemaakt:

Server B Voorbereiding

1. Heb ik het 10 GB test monster bestand gedownload.

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

2. Heb ik de mc client geïnstalleerd.

mc is een opdrachtregel bestandsbeheerder ontwikkeld door het MinIO project. Het biedt mogelijkheden voor lees- en schrijfoperaties op zowel lokale als S3-compatibele object opslag in de Linux opdrachtregel. Het mc cp commando biedt real-time voortgangs- en snelheidsupdates tijdens gegevens kopiëren, wat het observeren van verschillende tests faciliteert.

Opmerking: Om de test eerlijk te houden, werden alle drie de benaderingen gebruikt mc voor bestands schrijf tests.

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

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

# Installeer mc.
sudo install mc /usr/bin

# Stel een alias in voor MinIO.
mc alias set my http://172.16.254.18:9000 admin abc123abc

3. Heb ik s3fs-fuse gedownload.

sudo apt install s3fs

# Check de versie.
s3fs --version
Amazon Simple Storage Service File System V1.93 (commit:unknown) with OpenSSL

# Stel object opslag toegangssleutel in.
echo admin:abc123abc >  ~/.passwd-s3fs

# Wijzig sleutelbestand machtigingen.
chmod 600  ~/.passwd-s3fs

# Maak de montage directory aan.
mkdir mnt-s3fs

# Mount de object opslag.
s3fs test-s3fs:/ /root/mnt-s3fs -o url=http://172.16.254.18:9000 -o use_path_request_style

4. Heb ik JuiceFS geïnstalleerd.

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

# Een-klik installatie script
curl -sSL https://d.juicefs.com/install | sh -

# Check de versie.
juicefs version
juicefs version 1.1.0+2023-09-04.08c4ae6

5. Ik heb een bestandssysteem aangemaakt. JuiceFS is een bestandssysteem dat moet worden aangemaakt voordat het wordt gebruikt. Naast objectopslag vereist het een database als metadata-engine. Het ondersteunt verschillende databases. Hier gebruikte ik de meest gebruikte Redis als metadata-engine.

Opmerking: Ik heb Redis geïnstalleerd op Server A, toegankelijk via 172.16.254.18:6379 zonder wachtwoord. Het installatieproces wordt hier weggelaten. U kunt de documentatie van Redis raadplegen voor details.

# Maak het bestandssysteem aan.
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. Ik heb JuiceFS geaccessed met behulp van de meer gebruikte POSIX en S3 API methoden en hun prestaties getest.

# Maak mount directories aan.
mkdir ~/mnt-juicefs

# Mount het bestandssysteem in POSIX-modus.
juicefs mount redis://172.16.254.18/1 /root/mnt-juicefs

# Access het bestandssysteem met behulp van de S3 API methode.
export MINIO_ROOT_USER=admin
export MINIO_ROOT_PASSWORD=abc123abc
juicefs gateway redis://172.16.254.18/1 0.0.0.0:9000

# Stel een alias in voor de JuiceFS S3 API in mc.
mc alias set juicefs http://172.16.254.18:9000 admin abc123abc

Opmerking: De JuiceFS Gateway kan ook op Server A of op een ander internet-toegankelijk server worden geïmplementeerd, aangezien het een netwerk-gebaseerde S3 API ontsluit.

Tests en Resultaten

Hier is een korte samenvatting van mijn tests en resultaten:

Test 1: Schrijven van een 10 GB bestand

Deze test was ontworpen om de prestaties van het schrijven van grote bestanden te evalueren. Hoe korter de tijd die nodig is, hoe beter de prestaties. Ik gebruikte de time opdracht om de duur van schrijfoperaties te meten, waarbij drie metingen worden geleverd:

• real: De werkelijke tijd vanaf het begin tot het einde van de opdracht. Dit omvat alle wachttijden, zoals wachten op het voltooien van I/O-operaties, wachten op proceswisselingen en wachten op middelen.
• user: De tijd die wordt uitgevoerd in gebruikersmodus, wat aangeeft welk CPU-tijd wordt gebruikt voor het uitvoeren van gebruikerscode. Het vertegenwoordigt meestal de rekenbelasting van de opdracht.
• sys: De tijd die wordt uitgevoerd in kernelmodus, wat aangeeft welk CPU-tijd wordt gebruikt voor het uitvoeren van kernelcode. Het vertegenwoordigt meestal de belasting die verband houdt met systeemoproepen, zoals bestand I/O en procesbeheer.

MinIO

I ran the following command to perform a copy test:

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

Resultaten voor het schrijven van een 10 GB bestand rechtstreeks naar 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/

Resultaten voor het schrijven van een 10 GB bestand rechtstreeks naar s3fs-fuse:

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

Opmerking: Hoewel de schrijftijd 3 minuten en 6 seconden was voor s3fs-fuse, waren er geen schrijffouten zoals beschreven in het artikel van MinIO.

JuiceFS

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

# POSIX schrijftest
time mc cp ./2018_Yellow_Taxi_Trip_Data.csv /root/mnt-juicefs/

# S3 API schrijftest
time mc cp ./2018_Yellow_Taxi_Trip_Data.csv  juicefs/myjfs/

Resultaten voor JuiceFS POSIX schrijven van een 10 GB bestand:

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

Resultaten voor JuiceFS S3 API schrijven van een 10 GB bestand:

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

Samenvatting van Resultaten Grote Bestand Schrijven

Het volgende figuur toont de testresultaten:

De testresultaten laten zien dat zowel direct schrijven naar MinIO als JuiceFS vergelijkbare prestaties leverden, met de taak binnen ongeveer 30 seconden voltooid. In tegenstelling tot s3fs-fuse, dat meer dan 3 minuten nodig had om een 10 GB bestand te schrijven, wat ongeveer zes keer langzamer was dan de eerste twee.

Bij het schrijven van grote bestanden, mc maakt gebruik van de Multipart API om bestanden in stukjes te uploaden naar de S3-interface. Omgekeerd kan s3fs-fuse alleen schrijven naar POSIX in één thread. JuiceFS deelt ook automatisch grote bestanden in stukjes op en schrijft deze tegelijkertijd naar MinIO tijdens opeenvolgende schrijfbewerkingen, waardoor de prestaties gelijk zijn aan directe MinIO-schrijfbewerkingen. S3FS schrijft echter eerst naar een cache-schijf in één thread en uploadt vervolgens het bestand in stukjes naar MinIO, wat resulteert in langere schrijftijden.

Op basis van de berekening dat het 30 seconden duurde om een 10 GB bestand te schrijven, was de gemiddelde snelheid 333 MB/s. Dit was beperkt door de bandbreedte van cloud server SSDs. Deze testresultaten toonden aan dat zowel MinIO als JuiceFS de lokale SSD-bandbreedte konden maximaliseren en hun prestaties zouden verbeteren met verbeteringen van servercloudschijven en netwerkbandbreedte.

Test 2: Overschrijven van kleine bestanden met Pandas

Deze test beoordeelde de prestaties van objectopslagsystemen in scenario’s van overschrijven van kleine bestanden. De testscripts voor elk software verschilden enigszins. U kunt alle scriptcode hier vinden.

MinIO

I got the test script and ran the test:

# Haal het testscript op.
curl -LO https://gist.githubusercontent.com/yuhr123/7acb7e6bb42fb0ff12f3ba64d2cdd7da/raw/30c748e20b56dec642a58f9cccd7ea6e213dab3c/pandas-minio.py

# Voer de test uit.
python3 pandas-minio.py

Het resultaat was als volgt:

Execution time: 0.83 seconds

s3fs-fuse

I got the test script and ran the test:

# Haal het testscript op.
curl -LO gist.githubusercontent.com/yuhr123/7acb7e6bb42fb0ff12f3ba64d2cdd7da/raw/30c748e20b56dec642a58f9cccd7ea6e213dab3c/pandas-s3fs.py

# Voer de test uit.
python3 pandas-s3fs.py

Het testresultaat was als volgt:

Execution time: 0.78 seconds

JuiceFS POSIX

I got the test script and ran the test:

# Haal het testscript op.
curl -LO gist.githubusercontent.com/yuhr123/7acb7e6bb42fb0ff12f3ba64d2cdd7da/raw/30c748e20b56dec642a58f9cccd7ea6e213dab3c/pandas-juicefs-posix.py

# Voer de test uit.
python3 pandas-juicefs-posix.py

Het testresultaat was als volgt:

Execution time: 0.43 seconds

JuiceFS S3 API

I got the test script and ran the test:

# Haal de testscript op.
curl -LO https://gist.githubusercontent.com/yuhr123/7acb7e6bb42fb0ff12f3ba64d2cdd7da/raw/30c748e20b56dec642a58f9cccd7ea6e213dab3c/pandas-juicefs-s3api.py

# Voer de test uit.
python3 pandas-juicefs-s3api.py

Het testresultaat was als volgt:

Execution time: 0.86 seconds

Samenvatting van Pandas Kleine Bestands Overschrijvingen

Het onderstaande figuur toont de testresultaten:

In deze test toonde JuiceFS FUSE-POSIX de snelste snelheid, bijna twee keer sneller dan de andere oplossingen. MinIO, s3fs-fuse, en JuiceFS S3 Gateway vertonen vergelijkbare prestaties. Vanuit het oogpunt van kleine bestands overschrijvingen bleek de POSIX-interface efficiënter, met betere prestaties dan object storage interfaces.

Problemen en Analyse

Probleem 1: Waarom Was S3FS Zo Traag?

Analyse: Uit de testgegevens blijkt dat bij het schrijven van hetzelfde 10 GB bestand, S3FS er 3 minuten over deed, terwijl MinIO en JuiceFS beide de taak in ongeveer 30 seconden voltooiden. Dit significante prestatieverschil was voornamelijk te wijten aan verschillende technische implementaties. Wanneer s3fs-fuse een bestand schrijft, schrijft het eerst het bestand naar een lokaal tijdelijk bestand en uploadt het vervolgens in stukjes naar object storage. Als er onvoldoende lokale schijfruimte is, gebeurt de upload synchroon. Het moet gegevens kopiëren tussen de lokale schijf en S3-opslag. Daarom leidt dit bij grote bestanden of een groot aantal bestanden tot prestatievermindering.

Bovendien vertrouwt S3FS op de metadata-beheercapaciteiten van de onderliggende objectopslag. Wanneer het te maken heeft met een groot aantal bestanden, heeft de frequente interactie met objectopslag om metadata op te halen een significante invloed op de prestaties. In eenvoudige bewoordingen, hoe groter de bestandsgrootte en het totale aantal bestanden dat naar S3FS wordt geschreven, hoe groter het evenredige prestatieoverhead.

Kwestie 2: Waarom Was JuiceFS Sneller?

Analyse: Tijdens de test gebruikten zowel JuiceFS als S3FS FUSE voor het lezen en schrijven. JuiceFS maakte volledig gebruik van de schijfbandbreedte zoals MinIO, maar ondervond geen prestatieproblemen zoals bij S3FS.

Het antwoord ligt in hun respectievelijke technische architectuur. Hoewel gegevens worden verwerkt via de FUSE-laag tijdens het schrijven van bestanden, maakt JuiceFS gebruik van hoge gelijktijdigheid, caching en gegevenssegmentatietechnieken om de communicatieoverhead tussen de FUSE-laag en de onderliggende objectopslag te verminderen. Dit stelt JuiceFS in staat om meer lees- en schrijfrequests voor bestanden tegelijk te verwerken, waardoor wachttijden en overdrachtslag worden verminderd.

Daarnaast maakt JuiceFS gebruik van een toegewijde database (in dit geval Redis) voor het beheer van metadata. Bij het omgaan met een bijzonder groot aantal bestanden kan een onafhankelijk metadata-engine het werklast effectief verlichten, waardoor de snelheid van bestandslocatie wordt verhoogd.

Conclusie

De bovenstaande tests demonstreren dat het gebruik van objectopslag als basis en het implementeren van een POSIX-interface erop niet per se leidt tot een verlies van prestaties. Of er nu grote of kleine bestanden worden geschreven, toont JuiceFS prestaties die vergelijkbaar zijn met directe MinIO-schrijfbewerkingen, zonder enige achteruitgang in de onderliggende objectopslagprestaties door POSIX-toegang. Bovendien blijft in termen van Pandas-tabeloverschrijvingen de FUSE-POSIX-prestatie van JuiceFS consistent en overtreft het zelfs MinIO bijna met een factor twee.

De testresultaten geven aan dat sommige software, zoals s3fs-fuse, mogelijk prestatievermindering ervaart bij het converteren tussen S3 API en POSIX-interfaces. Hoewel het een handig hulpmiddel kan zijn voor tijdelijke S3-toegang, is voor stabiele en hoogwaardige langdurige gebruik zorgvuldig onderzoek en validatie nodig om meer geschikte oplossingen te selecteren.

Voor eenvoudige ongestructureerde bestandsarchivering is het rechtstreeks gebruik van MinIO of cloud objectopslag een goede keuze. Echter, voor scenario’s die betrekking hebben op grote schaal gegevensopslag en verwerking, zoals AI-modeltraining, big data-analyse, Kubernetes-gegevenspersistentie en andere frequente lees- en schrijfbewerkingen, biedt JuiceFS’ onafhankelijke metadata-beheer, gelijktijdige lees- en schrijfcapaciteiten en cachingmechanismen superieure prestaties. Het is een hoogwaardige bestandssysteemoplossing die de moeite waard is om te overwegen.