Het probleem
SAN- en block-storage is snel en betrouwbaar, maar duur per terabyte. In veel omgevingen staat er een groot deel data op die zelden wordt gelezen: archieven, exports, documenten, gebruikersbestanden, build-artefacten. Die data betaalt de prijs van snelle opslag, terwijl alleen een klein deel echt "warm" is.
Objectopslag (S3) is een fractie van de prijs per terabyte, maar applicaties verwachten een bestandssysteem, geen API. En een naïeve S3-mount is traag bij veel kleine bestanden en bij metadata-operaties zoals ls en stat.
Waarom JuiceFS
JuiceFS splitst een bestandssysteem in twee delen:
| Laag | Waar | Wat |
|---|---|---|
| Metadata | Een database (Redis of PostgreSQL) | Mappen, bestandsnamen, rechten, de indeling van bestanden in chunks |
| Data | S3-objectopslag | De inhoud, in blokken |
| Cache | Lokale SSD op de client | Recent gelezen en geschreven blokken |
Dat verklaart de snelheid. Metadata-operaties gaan naar een snelle database, niet naar S3. De warme data staat in de lokale cache en wordt op SSD-snelheid gelezen. Alleen koude data komt uit S3. Voor applicaties is het een gewoon POSIX-bestandssysteem, en in Kubernetes is er een CSI-driver, zodat het een normale PersistentVolume wordt.
Het plan
- Inventariseren: welke volumes staan op SAN, hoe groot zijn ze, en hoe ziet het toegangspatroon eruit (hoeveel is warm, lezen of schrijven, grote of kleine bestanden)?
- Kandidaten kiezen: data die groot is en grotendeels koud. Niet voor databases of andere workloads met veel willekeurige schrijfacties en
fsync. Die blijven op block-storage. - Metadata-engine robuust maken. Valt de metadata weg, dan is het bestandssysteem weg. Daarom op een HA-opstelling met backups: een PostgreSQL-cluster met point-in-time recovery of Redis met Sentinel. Beide heb ik al eerder in Kubernetes neergezet (zie PostgreSQL met PITR en de Redis-migratie).
- Cache dimensioneren op de warme dataset, op lokale SSD.
- Pilot met metingen: hetzelfde volume op SAN en op JuiceFS, met realistische belasting. Doorvoer, latency (p95/p99), metadata-operaties per seconde, en het gedrag bij een koude cache.
- Migreren per volume, met rsync of rclone. Eerst naast elkaar, daarna omschakelen, met de SAN-kopie als terugweg tot de nieuwe opzet zich bewezen heeft.
Aandachtspunten
- Versleuteling: JuiceFS kan data versleutelen voordat het naar S3 gaat. Dat past bij de eis dat de opslagpartij geen leesbare data heeft.
- Consistentie en gelijktijdigheid: meerdere clients kunnen tegelijk mounten. Het gedrag bij gelijktijdig schrijven moet wel passen bij de applicatie.
- Monitoring: JuiceFS levert Prometheus-metrics, zoals cache hit ratio, S3-latency en metadata-latency. Een dalende hit ratio is het eerste signaal dat de cache te klein is.
- Kosten eerlijk rekenen: niet alleen opslag per terabyte, maar ook de requests en het uitgaande verkeer van S3, de cache-SSD's en de metadata-database.
Verwachte opbrengst
Bij grote volumes die nu op SAN staan, kan de besparing oplopen tot enkele duizenden euro's per maand, met dezelfde ervaren snelheid voor de warme data. De pilot moet uitwijzen welke volumes daarvoor in aanmerking komen, en wat de werkelijke prestaties zijn.
Status
Concept. Volgende stap: inventarisatie en een pilot op één kandidaatvolume.