È disponibile il primo rilascio di Blockstor: un sistema open source per la gestione di uno storage distribuito a blocchi per Kubernetes, che garantisce la replica dei dati su DRBD. Blockstor è compatibile con l'API REST di LINSTOR e può funzionare senza modifiche con l'attuale ecosistema di client, inclusi lo strumento da linea di comando linstor, il driver CSI, l'operatore Piraeus, l'ha-controller e la libreria golinstor. Il progetto è un'implementazione completamente autonoma (clean-room) scritta in Go, che non utilizza il codice sorgente originale. Il codice è distribuito con licenza Apache 2.0 ed è sviluppato all'interno della piattaforma Cozystack (progetto CNCF Sandbox).
L'autore del progetto è Andrey Kvapil (@kvaps), fondatore di Cozystack e membro dell'organizzazione non profit Piraeus, che sviluppa l'operatore e il driver CSI di LINSTOR per Kubernetes. L'autore è noto nella comunità Kubernetes come promotore di LINSTOR e ha tenuto numerose presentazioni tecniche sull'argomento. Inizialmente, lo sviluppo era concepito come una piccola iniziativa ‘del venerdì’, ma è poi diventato circa 20 giorni di lavoro intenso. Attualmente il progetto si sviluppa come ricerca, ma in prospettiva è considerato come una possibile sostituzione di LINSTOR nel ruolo di sistema di storage predefinito in Cozystack.
Le ragioni alla base della creazione del nuovo progetto includono le difficoltà nella gestione del progetto originale e nel trasferimento delle modifiche al progetto principale, oltre alle limitazioni architetturali di LINSTOR. Il progetto originale utilizza un modello di elaborazione delle richieste ‘request-based’ in tempo reale, che presenta problemi su larga scala, mentre l'approccio dichiarativo di reconciliation di Kubernetes e il framework controller-runtime, secondo l'autore, si adattano molto meglio alla costruzione di sistemi distribuiti.
A differenza di LINSTOR, l'architettura di Blockstor è interamente basata sull'approccio di Kubernetes controller-runtime. La configurazione e lo stato attuale del sistema sono rappresentati come oggetti CRD di Kubernetes e il sistema non è progettato per funzionare al di fuori di un cluster Kubernetes.
Tra le principali funzionalità di Blockstor ci sono:
- Volumi replicabili su DRBD basati su LVM, LVM-thin, ZFS, ZFS-thin e backend file.
- Posizionamento automatico delle repliche tenendo conto delle zone, delle caratteristiche dei nodi e delle regole ‘replicas-on-different’.
- Supporto per TieBreaker, quorum e modifica delle dimensioni dei volumi senza interruzione del servizio.
- Possibilità di lavorare senza DRBD in modalità locale (single-replica diskful) o senza memorizzazione su disco.
- Crittografia dei volumi tramite LUKS.
- Supporto per snapshot: creazione, ripristino, clonazione e recupero come nuovo risorsa.
- Trasferimento di snapshot all'interno del cluster tramite zfs send/recv e thin-send-recv.
- Creazione di storage pool da dischi fisici.
- Immagini container raccolte per diverse architetture (linux/amd64 e linux/arm64), pubblicate in GHCR.
Una caratteristica del progetto è stata l'uso attivo di strumenti AI durante lo sviluppo. Praticamente tutto il codice è stato preparato con Claude Code (modello Opus 4.7) dell'azienda Anthropic. Lo sviluppo è stato condotto quasi ininterrottamente per circa 20 giorni. In alcuni momenti, fino a 60 agenti AI hanno lavorato contemporaneamente, e il dialogo complessivo di sviluppo ha riguardato circa 1320 richieste da parte dell'autore e circa 36.000 risposte dal modello in un'unica sessione continua.
Alla fine sono stati ottenuti 1500 commit, che hanno visto 83.000 righe di codice per l'implementazione e altre 137.000 righe di codice per i test. Secondo una stima preliminare, sono stati spesi circa 18,9 miliardi di token, e il costo equivalente per un simile volume utilizzando le tariffe API sarebbe stato di circa 40.000 dollari.
L'autore inizialmente sperava di avere uno sviluppo quasi completamente autonomo da parte del modello AI, ma la logica complessa di DRBD ha richiesto la partecipazione costante di un umano. Gli scenari più complessi si sono rivelati quelli relativi alla convergenza degli stati di DRBD, alla gestione di Generation Identifier (GI), al superamento della sincronizzazione iniziale e alla gestione degli scenari di split-brain.
Poiché l'originale LINSTOR è distribuito sotto licenza GPL, non era possibile utilizzare il suo codice direttamente. La maggior parte dell'implementazione è stata creata sulla base dell'analisi dei contratti API, del comportamento delle utility, del client Python di LINSTOR e di progetti compatibili con la licenza, tra cui piraeus-operator e il driver CSI.
Nei casi più complessi è stato utilizzato uno schema con divisione dei ruoli tra gli agenti AI: un agente analizzava il codice sorgente di LINSTOR e formulava una specifica testuale del comportamento, dopo di che un altro agente implementava la funzionalità esclusivamente in base a questa specifica senza copiare direttamente il codice sorgente. A causa della mancanza di test aperti nel progetto originale, è stato necessario formare autonomamente il database di test.
Fonte: opennet.ru
