Ilmuni Blockstor - avatud jaotatud plokkide salvestussüsteemi haldamise esimesest väljaandest Kubernetes'e jaoks, mis tagab andmete replikatsiooni DRBD üle. Blockstor on REST API poolest ühilduv LINSTORiga ja suudab töötada olemasoleva kliendiekosüsteemiga, sealhulgas käsurea tööriist linstor, CSI-draiver, Piraeus operator, ha-controller ja golinstor'i raamatukogu. Projekt on täielikult iseseisev (clean-room) rakendus Go keeles, mis ei kasuta originaali lähtekoodi. Kood levitatakse Apache 2.0 litsentsi alusel ja areneb Cozystack platvormi raames (CNCF Sandbox projekti).
Projekti autor on Andre Kvalpil (@kvaps), Cozystack asutaja ja mittetulundusühingu Piraeus liige, mille raames arendatakse LINSTOR'i operatorit ja CSI-draiverit Kubernetes'e jaoks. Autor on Kubernetes'e kogukonnas tuntud kui LINSTOR'i populariseerija ning on korduvalt esinenud tehniliste ettekannetega. Esialgu kavandati arendus väiksena «reedese» algatusena, kuid lõpuks muutus see umbes 20 päeva järjestikuseks tööks. Praeguseks areneb projekt uurimistööna, kuid tulevikus kaalutakse seda LINSTOR'i võimaliku asendusena Cozystacki vaikimisi salvestussüsteemina.
Uue projekti loomise põhjusi nimetatakse originaalprojekti haldamise keerukuseks ja muudatuste edastamiseks peaprojekti, samuti LINSTOR'i arhitektuuriliste piirangute tõttu. Originaalprojekt kasutab „request-based” mudelit reaalajas päringute töötlemiseks, mis näitab probleeme suuremõõtmel, samas kui autor arvab, et Kubernetes'e deklaratiivne reconciliation-lähteviis ja framework controller-runtime sobib kaugelt paremini jaotatud süsteemide loomisel.
Erinevalt LINSTOR'ist põhineb Blockstor'i arhitektuur täielikult Kubernetes controller-runtime lähenemisel. Süsteemi konfiguratsioon ja praegune olek on esitatud Kubernetes CRD-objektidena, ning süsteem ei ole mõeldud töötamiseks väljaspool Kubernetes'i klastrit.
Blockstor'i peamiste võimaluste hulka kuuluvad:
- DRBD'i põhjal replitseeritud mahud LVM, LVM-thin, ZFS, ZFS-thin ja failibekendite põhjal.
- Automaatne replikate paigutamine, arvestades tsoone, sõlmede omadusi ja „replicas-on-different” reegleid.
- Tuge toetamine, quorum ja mahutite suuruse muutmine ilma töö katkestamiseta.
- Võime töötada ilma DRBD'ita kohalikus (single-replica diskful) või diskivaba salvestuse režiimis.
- Kettade krüptimine läbi LUKS.
- Snapshootide tugi: loomine, tagasiviimine, kloonimine ja uue ressursina taastamine.
- Klastri sees snapshootide edastamine läbi zfs send/recv ja thin-send-recv.
- Salvestuspaikade loomine füüsilistest ketastest.
- Kogutud erinevatele arhitektuuridele konteineripildid (linux/amd64 ja linux/arm64), avaldatud GHCR'is.
Projekt eristus aktiivse AI-tööriistade kasutamisega arendamisel. Peaaegu kogu kood valmistati ette Claude Code (Opus 4.7 mudel) abil firmast Anthropic. Arendustööd jätkusid peaaegu ööpäevaringselt umbes 20 päeva jooksul. Erakordsetel hetkedel töötas samal ajal kuni 60 AI-agenti, ning arenduse kogudialoog koosnes umbes 1320 päringust autori poolt ja ligikaudu 36 000 mudeli vastusest ühe pikaajalise seansi jooksul.
Tulemusena tekkis 1500 commit'i, millest 83 000 koodirea võttis teostus ja veel 137 000 koodirea testid. Eelneva hinnangu kohaselt kulus kokku umbes 18.9 miljardit tokenit, ja selle mahtu API-tasude kasutamisel hinnataks ligikaudu 40 000 dollari võrra.
Autor lootsis algselt peaaegu täielikult autonoomset arendust AI-mudeli abil, kuid DRBD'i keeruline loogika nõudis pidevat inimlikku sekkumist. Kõige keerulisemaks osutus DRBD'i olekute konvergentsi stsenaariumide haldamine, Generation Identifier'iga (GI) töötamine, algse sünkroonimise vahelejätmine ja split-brain stsenaariumide töötlemine.
Kuna originaalne LINSTOR on litsentseeritud GPL'i all, ei saanud selle koodi otse kasutada. Peamine teostus luuakse API-lepingute, utiliitide käitumise, LINSTOR'i Python-klientide ning litsentsiga ühilduvate projektide, sealhulgas Piraeus'e operaatori ja CSI-kettajuhiku uuringu põhjal.
Kuna kõige keerulisemates olukordades rakendati AI-agentide rollide jagamise skeemi: üks agent analüüsis LINSTOR'i originaalkoodi ja koostas käitumise tekstilist spetsifikatsiooni, seejärel rakendas teine agent funktsionaalsust ainult selle spetsifikatsiooni alusel, ilma otse originaalkoodi kopeerimata. Originaalprojektil puuduvad avatud testid, seetõttu tuli testibaas ise koostada.
Allikas: opennet.ru
