Den første udgave af Blockstor er tilgængelig — et åbent system til styring af distribueret bloklager til Kubernetes, der muliggør datareplikering via DRBD. Blockstor er REST API-kompatibel med LINSTOR og kan fungere uændret inden for den eksisterende kundekosystem, herunder kommandolinjeværktøjet linstor, CSI-driveren, Piraeus-operatøren, ha-controller og biblioteket golinstor. Projektet er en helt selvstændig (clean-room) implementering i Go-sprog, der ikke bruger kildekoden fra originalen. Koden distribueres under Apache 2.0-licensen og udvikles inden for Cozystack-platformen (CNCF Sandbox-projekt).
Projektets forfatter — Andrey Kvapil (@kvaps), grundlægger af Cozystack og deltager i den nonprofitorganisation Piraeus, der udvikler operatøren og CSI-driveren LINSTOR til Kubernetes. Forfatteren er kendt i Kubernetes-samfundet som en forkæmper for LINSTOR og har gentagne gange præsenteret tekniske oplæg om emnet. Oprindeligt blev udviklingen tænkt som en lille 'fredags'-initiativ, men er i stedet blevet til cirka 20 dages uafbrudt arbejde. I øjeblikket udvikles projektet som et forskningsprojekt, men overvejes i fremtiden som en mulig erstatning for LINSTOR som standard lagerløsning i Cozystack.
Som årsager til oprettelsen af det nye projekt nævnes vanskeligheder med at vedligeholde det originale projekt og overføre ændringer til hovedprojektet samt arkitektoniske begrænsninger i LINSTOR. Det originale projekt bruger en "request-based" model til behandling af anmodninger i realtid, som viser problemer i større skalaer, mens den deklarative reconciliation-tilgang i Kubernetes og framework controller-runtime, ifølge forfatteren, er langt bedre til at opbygge distribuerede systemer.
I modsætning til LINSTOR er Blockstors arkitektur helt baseret på tilgangen fra Kubernetes controller-runtime. Konfigurationen og den nuværende tilstand af systemet præsenteres som Kubernetes CRD-objekter, og selve systemet er ikke designet til at fungere uden for et Kubernetes-klynge.
Blandt de vigtigste funktioner i Blockstor:
- Replikerbare volumener over DRBD baseret på LVM, LVM-thin, ZFS, ZFS-thin og filbackend.
- Automatisk placering af replikaer under hensyntagen til zoner, nodernes egenskaber og reglerne "replicas-on-different".
- Understøttelse af TieBreaker, quorum og ændring af volumestørrelser uden nedetid.
- Mulighed for drift uden DRBD i lokal tilstand (single-replica diskful) eller uden disk lager.
- Kryptering af volumener via LUKS.
- Understøttelse af snapshots: oprettelse, rulle tilbage, kloning og genoprettelse som en ny ressource.
- Flytning af snapshots inden for klyngen via zfs send/recv og thin-send-recv.
- Oprettelse af storage pools fra fysiske diske.
- Samlede containerbilleder til forskellige arkitekturer (linux/amd64 og linux/arm64), publiceret i GHCR.
Et særpræg ved projektet var den aktive brug af AI-værktøjer under udviklingen. Næsten hele koden blev forberedt ved hjælp af Claude Code (Opus 4.7-modellen) fra Anthropic. Udviklingen foregik næsten døgnet rundt i cirka 20 dage. På enkelte tidspunkter arbejdede op til 60 AI-agenter samtidigt, og den samlede udviklingsdialog omfattede omkring 1320 forespørgsler fra forfatteren og cirka 36.000 model svar i et sammenhængende session.
Det resulterede i 1500 commits, hvori 83.000 linjer kode blev brugt til implementeringen, og yderligere 137.000 linjer kode til tests. Ifølge foreløbige vurderinger blev der samlet brugt omkring 18,9 milliarder tokens, og omkostningerne ved at anvende API-priserne ville have været omkring 40.000 dollars.
Forfatteren havde oprindeligt planlagt stort set autonom udvikling via AI-modellen, men den komplekse logik i DRBD krævede konstant menneskelig deltagelse. De sværest scenarier var konvergens af DRBD-tilstande, arbejde med Generation Identifier (GI), udeladelse af den oprindelige synkronisering og håndtering af split-brain scenarier.
Da den originale LINSTOR distribueres under GPL-licensen, kunne dens kode ikke bruges direkte. Hovedparten af implementeringen blev skabt baseret på analyse af API-kontrakter, værktøjernes adfærd, LINSTOR Python-klienten samt licenskompatible projekter, herunder piraeus-operator og CSI-driver.
I de mest komplekse tilfælde blev der anvendt en ordning med opdelte roller for AI-agenter: en agent analyserede koden fra LINSTOR og dannede en tekstspecifikation for adfærden, hvorefter en anden agent implementerede funktionaliteten udelukkende efter denne specifikation uden direkte kopiering af koden. På grund af manglende åbne test i det originale projekt måtte testbasen dannes selvstændigt.
Kilde: opennet.ru
