Esimese Blockstori versiooni ilmumine - avatud süsteemi, mis haldab hajutatud plokkhoidlat Kubernetes'e jaoks, pakkudes andmete replikatsiooni DRBD-i peal. Blockstor on REST API kaudu ühilduv LINSTOR-iga ja suudab töötada ilma muutusteta olemasoleva kliendiekosüsteemiga, sealhulgas käsurea utiliit linstor, CSI draiver, Piraeus operaator, ha-controller ja golinstor teek. Projekt on täielikult iseseisev (clean-room) teostus Go keeles, mis ei kasuta originaali lähtekoode. Kood levitatakse Apache 2.0 litsentsi all ja areneb Cozystack platvormi raames (CNCF Sandbox projekt).
Projekti autor on Andrei Kvapil (@kvaps), Cozystack'i asutaja ja mittetulundusühingu Piraeus liige, milles arendatakse LINSTOR operaatoreid ja CSI draivereid Kubernetes'e jaoks. Autor on Kubernetes'e kogukonnas tuntud kui LINSTOR'i propageerija ning on korduvalt esinenud tehniliste ettekannetega. Alguses planeeriti arendust kui väikest 'reedese' algatust, kuid see muutus ligikaudu 20 päeva jooksul katkematuks tööks. Praegu areneb projekt uurimistöönäitajana, kuid tulevikus kaalutakse seda kui potentsiaalset asendajat LINSTOR'ile Cozystack'i vaikimisi salvestussüsteemina.
Uue projekti loomise põhjusteks on toodud originaali projekti hooldamise keerukus ja muudatuste edastamine põhiprojekti, samuti LINSTOR'i arhitektuuri piirangud. Originaalprojekt kasutab „request-based” mudelit reaalajas päringute töötlemiseks, mis näitab probleemide ilmnemist suuremõõtmel, samas kui Kubernetes'e deklaratiivne reconciliation lähenemine ja framework controller-runtime, autori arvates, sobivad palju paremini jaotatud süsteemide ülesehitamiseks.
Erinevalt LINSTOR'ist põhineb Blockstori arhitektuur täielikult Kubernetes controller-runtime lähenemisel. Süsteemi konfiguratsioon ja praegune olek on esitatud Kubernetes CRD-objektidena, ning süsteem ei ole ette nähtud töötamiseks väljaspool Kubernetes'i klastrit.
Blockstori peamised võimalused on:
- DRBD peal replikatsiooni teostavad mahud LVM, LVM-thin, ZFS, ZFS-thin ja failibackendite põhjal.
- Replikate automaatne paigutamine, võttes arvesse tsoone, sõlmede omadusi ja 'replicas-on-different' reegleid.
- TieBreaker'i, quorum'i ja mahutite suuruse muutmise tugi ilma töötamise katkestamiseta.
- Töö võimalus ilma DRBD-ta kohaliku (üksiku koopiaga diskful) või diskivaba salvestuse režiimis.
- Mahutite krüptimine LUKS-i kaudu.
- Snapshotide toetamine: loomine, tagasiviimine, kloonimine ja uue ressursina taastamine.
- Snapshotide teisaldamine klastris zfs send/recv ja thin-send-recv kaudu.
- Salvestuspoolide loomine füüsilistest ketastest.
- Erinevate arhitektuuride jaoks kokku pandud konteineripildid (linux/amd64 ja linux/arm64), avaldatud GHCR-is.
Projektis on aktiivselt kasutatud AI tööriistu arenduses. Peaaegu kogu kood valmis Claude Code'i (Opus 4.7 mudel) abil ettevõttelt Anthropic. Arendus toimus peaaegu ööpäevaringselt umbes 20 päeva jooksul. Erinevatel hetkedel töötas korraga kuni 60 AI-agentti ning arenduse kogudialoog koosnes umbes 1320 autori päringust ja ligikaudu 36 000 mudeli vastusest ühes katkestamatu seansi raames.
Tulemusena saadi 1500 commitit, milles 83 000 koodirida läks elluviimisele ja veel 137 000 koodirida testidele. Eelmisel hinnangul on kokku kulutatud umbes 18,9 miljardit tokenit ja selle mahuga API-tariifide kasutamisel oleks kulukord kokku ligikaudu 40 000 dollarit.
Autor arvestas alguses peaaegu täielikku autonoomset arendust AI mudeli abil, kuid DRBD keeruline loogika nõudis pidevat inimosalemist. Kõige keerulisemad olid DRBD olekute kokkulangemise stsenaariumid, Generation Identifier (GI) töötlemine, algse sünkroniseerimise vahelejätmine ja split-brain stsenaariumide töötlemine.
Kuna originaal LINSTORi levitatakse GPL-litsentsi alusel, ei saanud selle koodi otse kasutada. Suurem osa elluviimisest loodi API-lepingute, utiliitide käitumise, LINSTORi Python kliendi ja samaväärsete litsentsiprojektide, sealhulgas piraeus-operator ja CSI draiveri, analüüsi põhjal.
Kõige keerulisemates juhtudel rakendati AI agentide rollide jagamise skeemi: üks agent analüüsis LINSTORi lähtekoodi ja koostas selle käitumise tekstilise spetsifikatsiooni, seejärel realiseeris teine agent funktsionaalsuse ainult selle spetsifikatsiooni järgi, ilma lähtekoodi otsese kopeerimiseta. Avatud testide puudumise tõttu originaalprojektil tuli testimisbaas iseseisvalt luua.
Allikas: opennet.ru
