Den första versionen av Blockstor är tillgänglig — ett öppet system för hantering av distribuerad blocklagring för Kubernetes, som möjliggör datareplication ovanpå DRBD. Blockstor är kompatibel med LINSTOR:s REST API och kan utan förändringar fungera med den befintliga ekosystemet av klienter, inklusive kommandoradsverktyget linstor, CSI-drivrutinen, Piraeus-operatören, ha-controller och golinstor-biblioteket. Projektet är en helt fristående (clean-room) implementation på Go, som inte använder källkoden från originalet. Koden distribueras under Apache 2.0-licensen och utvecklas inom ramen för Cozystack-plattformen (CNCF Sandbox-projekt).
Projektets författare är Andrey Kvapil (@kvaps), grundare av Cozystack och medlem av den ideella organisationen Piraeus, som utvecklar operatören och CSI-drivrutinen för LINSTOR för Kubernetes. Författaren är känd i Kubernetes-gemenskapen som en förkämpe för LINSTOR och har flera gånger hållit tekniska presentationer om ämnet. Ursprungligen var utvecklingen avsedd som ett litet "fredags"-initiativ, men slutade upp med cirka 20 dagar av oavbrutet arbete. För tillfället utvecklas projektet som ett forskningsprojekt, men det övervägs som en potentiell ersättning för LINSTOR som standard lagringssystem i Cozystack.
Skälen till skapandet av det nya projektet inkluderar svårigheter med att underhålla det ursprungliga projektet och att överföra ändringar till huvudprojektet, samt arkitekturbegränsningar i LINSTOR. Det ursprungliga projektet använder en "request-based"-modell för realtidsförfrågningar, vilket visar problem i stor skala, medan det deklarativa reconciliation-tillvägagångssättet i Kubernetes och ramen controller-runtime, enligt författaren, passar mycket bättre för att bygga distribuerade system.
Till skillnad från LINSTOR bygger Blockstor-arkitekturen helt på Kubernetes controller-runtime-tillvägagångssättet. Konfigurationen och det aktuella tillståndet för systemet representeras som Kubernetes CRD-objekt, och själva systemet är inte avsett att fungera utanför Kubernetes-klustret.
Bland de viktigaste funktionerna i Blockstor finns:
- Replikerade volymer över DRBD baserat på LVM, LVM-thin, ZFS, ZFS-thin och filbakgrunder.
- Automatisk placering av repliker med hänsyn till zoner, noders egenskaper och regler för "replicas-on-different".
- Stöd för TieBreaker, quorum och ändring av volymer i storlek utan att stoppa driften.
- Möjlighet att arbeta utan DRBD i läge för lokal (single-replica diskful) eller diskfri lagring.
- Kryptering av volymer via LUKS.
- Stöd för snapshots: skapande, återställning, kloning och återställning som en ny resurs.
- Överföring av snapshots inom klustret via zfs send/recv och thin-send-recv.
- Skapande av storage pooler från fysiska diskar.
- Sammanställda containerbilder för olika arkitekturer (linux/amd64 och linux/arm64), publicerade i GHCR.
Projektet kännetecknades av aktiv användning av AI-verktyg under utvecklingen. Praktiskt taget all kod förbereddes med hjälp av Claude Code (modell Opus 4.7) från Anthropic. Utvecklingen pågick nästan dygnet runt under cirka 20 dagar. Under vissa perioder arbetade upp till 60 AI-agenter samtidigt, och den totala utvecklingsdialogen bestod av cirka 1320 förfrågningar från författaren och ungefär 36 000 svar från modellen inom ramen för en sammanhängande session.
Resultatet blev 1500 commits, där 83 000 kodrader användes för implementeringen och ytterligare 137 000 kodrader för tester. Enligt preliminära uppskattningar förbrukades totalt cirka 18,9 miljarder tokens, och det motsvarande värdet för denna volym vid användning av API-priser skulle uppgå till cirka 40 000 dollar.
Författaren räknade initialt med en nästan helt autonom utveckling utförd av AI-modellen, men den komplexa logiken i DRBD krävde konstant mänskligt deltagande. De mest komplicerade scenarierna visade sig vara konvergensen av DRBD-tillstånd, arbete med Generation Identifier (GI), att hoppa över den initiala synkroniseringen och att hantera split-brain-scenarier.
Eftersom den ursprungliga LINSTOR distribueras under GPL-licensen kunde dess kod inte användas direkt. Större delen av implementeringen skapades baserat på analys av API-kontrakt, beteenden hos verktyg, Python-klienten för LINSTOR och även kompatibla projekt med licens, inklusive piraeus-operator och CSI-drivrutinen.
I de mest komplicerade fallen användes en rollfördelningsschemad för AI-agenter: en agent analyserade LINSTOR:s källkod och formulerade en textspecifikation av beteendet, varefter en annan agent implementerade funktionaliteten enbart baserat på denna specifikation utan direkt kopiering av källkoden. På grund av avsaknaden av öppna tester i det ursprungliga projektet tvingades testdatabasen att skapas självständigt.
Källa: opennet.ru
