De eerste release van Blockstor is beschikbaar ā een open source systeem voor het beheren van gedistribueerde blokopslag voor Kubernetes, dat gegevensreplicatie bovenop DRBD biedt. Blockstor is REST API-compatibel met LINSTOR en kan zonder wijzigingen functioneren binnen het bestaande ecosysteem van klanten, inclusief de commandoregeltool linstor, CSI-driver, Piraeus-operator, ha-controller en de golinstor-bibliotheek. Het project is een volledig autonome (clean-room) implementatie in de programmeertaal Go, die geen gebruik maakt van de originele broncode. De code wordt verspreid onder de Apache 2.0-licentie en wordt ontwikkeld binnen het Cozystack-platform (CNCF Sandbox-project).
De auteur van het project is Andrei Kvapil (@kvaps), oprichter van Cozystack en lid van de non-profitorganisatie Piraeus, die de operator en CSI-driver LINSTOR voor Kubernetes ontwikkelt. De auteur is bekend binnen de Kubernetes-gemeenschap als promotor van LINSTOR en heeft herhaaldelijk technische presentaties over dit onderwerp gegeven. Aanvankelijk was de ontwikkeling bedoeld als een kleine 'vrijdag'-initiatief, maar het is uiteindelijk uitgegroeid tot ongeveer 20 dagen onafgebroken werk. Momenteel wordt het project ontwikkeld als een onderzoeksproject, maar op langere termijn wordt het beschouwd als een mogelijke vervanging van LINSTOR als de standaard opslagoplossing in Cozystack.
Als redenen voor de oprichting van het nieuwe project worden de complicaties rondom het onderhoud van het originele project en de overdracht van wijzigingen naar het hoofdproject genoemd, evenals architectonische beperkingen van LINSTOR. Het originele project maakt gebruik van een 'request-based' model voor het verwerken van realtime aanvragen, wat problemen toont op grotere schaal, terwijl de declaratieve reconciliatie-aanpak van Kubernetes en het controller-runtime framework volgens de auteur aanzienlijk beter geschikt zijn voor het bouwen van gedistribueerde systemen.
In tegenstelling tot LINSTOR is de architectuur van Blockstor volledig gebaseerd op de Kubernetes controller-runtime benadering. De configuratie en de huidige status van het systeem worden gepresenteerd in de vorm van Kubernetes CRD-objecten, en het systeem is niet ontworpen om buiten de Kubernetes-cluster te functioneren.
Onder de belangrijkste mogelijkheden van Blockstor behoren:
- Repliceerbare volumes bovenop DRBD op basis van LVM, LVM-thin, ZFS, ZFS-thin en bestandsbackends.
- Automatische plaatsing van replicaten rekening houdend met zones, eigenschappen van knooppunten en regels voor 'replicas-on-different'.
- Ondersteuning voor TieBreaker, quorum en het wijzigen van de grootte van volumes zonder een stopzetting van de werking.
- De mogelijkheid om te werken zonder DRBD in lokale (single-replica diskful) of diskless opslagmodus.
- Versleuteling van volumes via LUKS.
- Ondersteuning voor snapshots: aanmaken, terugzetten, klonen en herstellen als een nieuwe bron.
- Verplaatsen van snapshots binnen het cluster via zfs send/recv en thin-send-recv.
- Aanmaken van storage pools uit fysieke schijven.
- Gebouwde containerafbeeldingen voor verschillende architecturen (linux/amd64 en linux/arm64), gepubliceerd in GHCR.
Een kenmerk van het project was het actieve gebruik van AI-tools tijdens de ontwikkeling. Bijna de hele code is voorbereid met behulp van Claude Code (model Opus 4.7) van Anthropic. De ontwikkeling vond bijna continu plaats gedurende ongeveer 20 dagen. Op bepaalde momenten werkten er tot 60 AI-agenten tegelijk, en de totale ontwikkelingsdialoog bestond uit ongeveer 1320 verzoeken van de auteur en rond de 36.000 antwoorden van het model binnen Ć©Ć©n doorlopende sessie.
Aan het einde waren er 1500 commits, waarvan 83.000 code regels nodig waren voor de implementatie en nog eens 137.000 regels voor tests. Volgens voorlopige schattingen zijn er in totaal ongeveer 18,9 miljard tokens verbruikt, en de equivalente kosten voor zo'n volume bij het gebruik van API-tarieven zouden ongeveer 40.000 dollar bedragen.
De auteur rekende aanvankelijk op een bijna volledig autonome ontwikkeling door de AI-model, maar de complexe logica van DRBD vereiste constante menselijke deelname. De meest complexe scenario's betrof de convergentie van DRBD-toestanden, de omgang met Generation Identifier (GI), het overslaan van de initiƫle synchronisatie en de afhandeling van split-brain scenario's.
Aangezien de originele LINSTOR onder de GPL-licentie wordt verspreid, mocht zijn code niet direct worden gebruikt. Het grootste deel van de implementatie werd gemaakt op basis van de analyse van API-contracten, het gedrag van hulpprogramma's, de Python-client van LINSTOR, en ook licentievriendelijke projecten, waaronder piraeus-operator en CSI-driver.
In de meest complexe gevallen werd een schema met rolverdeling van AI-agenten toegepast: Ć©Ć©n agent analyseerde de broncode van LINSTOR en formuleerde een tekstuele specificatie van het gedrag, waarna een andere agent de functionaliteit uitsluitend volgens deze specificatie realiseerde zonder directe kopie van de broncode. Vanwege het ontbreken van open tests bij het originele project, moest de testbasis zelf worden opgebouwd.
Bron: opennet.ru
