Waarom FTP en mounten niet werken bij S3-compatible object storage

Het lijkt op een fileserver. Dat is het niet

Een bucket vol objecten, geordend onder prefixes die op mappen lijken en te doorbladeren in een UI, lijkt genoeg op een gedeelde schijf om aan te nemen dat je hem kunt mounten, of dat je er via FTP mee kunt verbinden zoals bij een traditionele fileserver. Die aanname klopt niet, en het is een van de meest voorkomende bronnen van verwarring voor iedereen die net met object storage begint. Object storage is nooit gebouwd als een bestandssysteem met een netwerkprotocol erbovenop. Het is vanaf de basis opgebouwd als API, en de bucket browser die je in een beheerconsole ziet, is een gemak voor de UI bovenop die API, geen bewijs dat er een bestandssysteem onder zit.

Waarom het onderliggende model anders is

Een echt bestandssysteem, lokaal of gemount via bijvoorbeeld NFS of CIFS, laat je een bestand openen, naar een specifieke byte-offset springen, een kleine wijziging schrijven en het bestand weer sluiten, waarbij alleen het gewijzigde deel wordt aangeraakt. FTP en SFTP werken in diezelfde bestandsgerichte wereld. Zo werkt object storage niet. Je vervangt een object, je bewerkt het niet: je doet een PUT van een object om het te uploaden, een GET om het te downloaden, je list objecten, je verwijdert objecten. Range reads en multipart uploads bestaan wel, maar geen van beide maakt van een bucket een bestandssysteem, want er bestaat op protocolniveau nog steeds geen concept van een object openen en drie bytes middenin herschrijven. Dat is een bewuste architecturale keuze, geen ontbrekende functie: het is precies wat object storage in staat stelt om te schalen zoals het doet, over enorme aantallen objecten en enorme hoeveelheden data.

FTP, SFTP, NFS en CIFS zijn allemaal bestandssysteemgerichte protocollen, gebouwd rond dat model van openen, springen en schrijven. De API van object storage spreekt een fundamenteel andere taal, dus die protocollen zijn simpelweg niet van toepassing, niet omdat er een instelling ontbreekt, maar omdat de twee modellen niet op elkaar aansluiten.

Hoe je in de praktijk met object storage werkt

In plaats van een fileserverprotocol praat je met object storage via S3-compatible tools en libraries die precies voor deze API gebouwd zijn:

• De AWS CLI, gericht op het S3-endpoint van je eigen provider in plaats van dat van Amazon, werkt tegen elke S3-compatible service, ook die van Worldstream.
• rclone, een general-purpose synctool die S3 en een lange lijst andere storage-backends begrijpt, handig voor bulkoverdrachten en mirroring.
• SDK's zoals boto3 voor Python, of equivalenten in andere talen, om object storage-aanroepen rechtstreeks in een applicatie te bouwen.

Ze spreken allemaal dezelfde onderliggende API. Zie Object Storage: CLI- en SDK-naslag voor concrete voorbeelden om mee aan de slag te gaan.

FUSE-based mounten: een gemakslaag, geen bestandssysteem

Er bestaan tools, meestal gebouwd op FUSE (Filesystem in Userspace), die een S3-compatible bucket laten verschijnen als een gemount bestandssysteem, zodat je hem met gewone bestandstools kunt doorbladeren. Die zijn echt nuttig voor casual browsen of voor scripts die een bestandssysteeminterface verwachten. Wat ze niet veranderen, is wat er onder water gebeurt: elke bestandsbewerking die je op die mount uitvoert, wordt nog steeds vertaald naar een API-aanroep op een heel object. Een groot bestand openen en er een klein beetje data aan toevoegen, iets wat een echt bestandssysteem goedkoop afhandelt, betekent bij zo'n tool meestal dat het hele object achter de schermen opnieuw wordt geüpload. Daarom worden FUSE-based mounts over het algemeen niet aangeraden voor performance-gevoelige workloads of alles met een zwaar schrijfpatroon: een applicatie die veel kleine writes doet, voelt die vertaallaag direct. Ze zijn een gemak voor mensen, geen vervanging voor het correct gebruiken van de API in een applicatie.