A apărut prima versiune a Blockstor - un sistem deschis de gestionare a stocării distribuite bazate pe bloc pentru Kubernetes, care asigură replicarea datelor peste DRBD. Blockstor este compatibil cu API-ul REST al LINSTOR și poate funcționa fără modificări cu ecosistemul existent de clienți, incluzând instrumentul de comandă linstor, driverul CSI, operatorul Piraeus, ha-controller și biblioteca golinstor. Proiectul reprezintă o implementare complet autonomă (clean-room) în limbajul Go, care nu utilizează codul sursă original. Codul este distribuit sub licența Apache 2.0 și este dezvoltat în cadrul platformei Cozystack (proiect CNCF Sandbox).
Autorul proiectului este Andrei Kvapil (@kvaps), fondatorul Cozystack și participant la organizația non-profit Piraeus, în cadrul căreia sunt dezvoltate operatorul și driverul CSI LINSTOR pentru Kubernetes. Autorul este cunoscut în comunitatea Kubernetes ca un promotor al LINSTOR și a susținut în mod repetat prezentări tehnice pe această temă. Inițial, dezvoltarea a fost concepută ca o mică inițiativă de „vineri”, însă în cele din urmă s-a transformat într-o muncă continuă de aproximativ 20 de zile. În prezent, proiectul este dezvoltat ca o cercetare, dar în perspectiva pe termen lung este considerat ca o posibilă înlocuire a LINSTOR ca sistem de stocare implicit în Cozystack.
Printre motivele pentru care s-a creat acest nou proiect se numără dificultățile de întreținere ale proiectului original și transferul modificărilor în proiectul principal, precum și constrângerile arhitecturale ale LINSTOR. Proiectul original folosește un model de procesare a cererilor bazat pe „request-based” în timp real, care întâmpină probleme la scară, în timp ce abordarea de reconciliere declarativă a Kubernetes și framework-ul controller-runtime, în opinia autorului, se potrivesc mult mai bine pentru construirea sistemelor distribuite.
Spre deosebire de LINSTOR, arhitectura Blockstor se bazează complet pe abordarea controller-runtime a Kubernetes. Configurarea și starea curentă a sistemului sunt prezentate sub formă de obiecte CRD Kubernetes, iar sistemul nu este destinat să funcționeze în afara unui cluster Kubernetes.
Printre principalele funcționalități ale Blockstor se numără:
- Volume replicabile peste DRBD pe bază de LVM, LVM-thin, ZFS, ZFS-thin și backend-uri de fișiere.
- Plasarea automată a replicatelor ținând cont de zone, proprietățile nodurilor și regulile «replicas-on-different».
- Suport pentru TieBreaker, quorum și modificarea dimensiunii volumelor fără a opri funcționarea acestora.
- Posibilitatea de a lucra fără DRBD în modul local (diskful cu replicare unică) sau cu stocare fără disc.
- Criptarea volumelor prin LUKS.
- Suport pentru snapshot-uri: creare, revenire, clonare și recuperare ca nou resource.
- Transferul snapshot-urilor în cadrul clusterului prin zfs send/recv și thin-send-recv.
- Crearea de storage pool-uri din discuri fizice.
- Imagini containerizate construite pentru arhitecturi diferite (linux/amd64 și linux/arm64), publicate în GHCR.
Particularitatea proiectului a fost utilizarea activă a instrumentelor AI în dezvoltare. Practic tot codul a fost pregătit cu ajutorul Claude Code (modelul Opus 4.7) al companiei Anthropic. Dezvoltarea a avut loc aproape non-stop timp de aproximativ 20 de zile. În anumite momente, au fost implicați simultan până la 60 de agenți AI, iar dialogul de dezvoltare a însumat aproximativ 1320 de solicitări din partea autorului și în jur de 36.000 de răspunsuri ale modelului într-o sesiune continuă.
La final s-au obținut 1500 de comitete, în care 83.000 de linii de cod au fost destinate implementării și încă 137.000 de linii de cod testelor. Conform estimărilor preliminare, s-au consumat în total aproximativ 18,9 miliarde de tokeni, iar costul echivalent al acestei cantități în cadrul tarifelor API ar fi fost de aproximativ 40.000 de dolari.
Autorul s-a bazat inițial pe o dezvoltare aproape complet autonomă realizată prin intermediul modelului AI, însă logica complexă a DRBD a necesitat o implicare constantă a unei persoane. Cele mai complicate s-au dovedit a fi scenariile de convergență a stărilor DRBD, lucrul cu Identificatorul de Generare (GI), sărind sincronizarea inițială și gestionarea scenariilor de split-brain.
Deoarece LINSTOR original este distribuit sub licența GPL, utilizarea codului său direct nu era permisă. Partea principală a implementării a fost creată pe baza analizei contractelor API, comportamentului utilitarelor, clientului Python LINSTOR, precum și proiectelor compatibile cu licența, inclusiv piraeus-operator și driverul CSI.
În cele mai complexe cazuri, s-a aplicat o schemă de separare a rolurilor agenților AI: un agent analiza codul sursă LINSTOR și elabora o specificație textuală a comportamentului, după care un alt agent implementa funcționalitatea exclusiv pe baza acelei specificații, fără a copia direct codul sursă. Din cauza lipsei testelor deschise din proiectul original, baza de teste a trebuit să fie formată de la început.
Sursa: opennet.ro
