È disponibile il primo rilascio di Blockstor, un sistema di gestione open-source per lo storage a blocchi distribuito progettato per Kubernetes, che garantisce la replica dei dati tramite DRBD. Blockstor è compatibile con l'API REST di LINSTOR e può funzionare senza modifiche con l'ecosistema esistente dei client, inclusi l'utilità da riga di comando linstor, il driver CSI, l'operatore Piraeus, l'ha-controller e la libreria golinstor. Il progetto è una realizzazione completamente autonoma (clean-room) scritta in Go, che non utilizza il codice sorgente dell'originale. Il codice è distribuito con licenza Apache 2.0 ed è sviluppato all'interno della piattaforma Cozystack (progetto CNCF Sandbox).
Il progetto è stato realizzato da Andrej Kvapil (@kvaps), fondatore di Cozystack e membro dell'organizzazione no-profit Piraeus, che sviluppa l'operatore e il CSI-driver LINSTOR per Kubernetes. È noto nella comunità di Kubernetes come promotore di LINSTOR e ha presentato numerosi interventi tecnici sul tema. Inizialmente, lo sviluppo era concepito come una piccola iniziativa 'del venerdì', ma si è trasformato in circa 20 giorni di lavoro ininterrotto. Attualmente, il progetto si sviluppa come un'iniziativa di ricerca, ma è considerato, in prospettiva, come una potenziale sostituzione di LINSTOR come sistema di archiviazione predefinito in Cozystack.
Le ragioni alla base della creazione del nuovo progetto comprendono le difficoltà nella manutenzione del progetto originale e nel trasferimento delle modifiche al progetto principale, oltre alle limitazioni architettoniche di LINSTOR. Il progetto originale utilizza un modello di elaborazione delle richieste 'request-based' in tempo reale, che mostra problemi su larga scala, mentre, secondo l'autore, l'approccio dichiarativo di reconciliation di Kubernetes e il framework controller-runtime si adattano molto meglio alla costruzione di sistemi distribuiti.
A differenza di LINSTOR, l'architettura Blockstor è completamente basata sull'approccio Kubernetes controller-runtime. La configurazione e lo stato attuale del sistema sono rappresentati come oggetti CRD Kubernetes, e il sistema stesso non è progettato per funzionare al di fuori di un cluster Kubernetes.
Tra le principali funzionalità di Blockstor:
- Volume replicabili sopra DRBD basati su LVM, LVM-thin, ZFS, ZFS-thin e backend di file.
- Posizionamento automatico delle repliche tenendo conto delle zone, delle caratteristiche dei nodi e delle regole «replicas-on-different».
- Supporto per TieBreaker, quorum e ridimensionamento dei volumi senza fermare il funzionamento.
- Possibilità di operare senza DRBD in modalità locale (single-replica diskful) o senza disco.
- Crittografia dei volumi tramite LUKS.
- Supporto per snapshot: creazione, ripristino, clonazione e recupero come nuova risorsa.
- Trasferimento di snapshot all'interno del cluster tramite zfs send/recv e thin-send-recv.
- Creazione di pool di storage da dischi fisici.
- Immagini container costruite per diverse architetture (linux/amd64 e linux/arm64), pubblicate in GHCR.
Il progetto si è distinto per l'uso attivo di strumenti AI durante lo sviluppo. Praticamente tutto il codice è stato preparato con il Claude Code (modello Opus 4.7) della Anthropic. Lo sviluppo è proseguito quasi ininterrottamente per circa 20 giorni. In alcuni momenti, fino a 60 agenti AI lavoravano contemporaneamente, e il dialogo complessivo di sviluppo ha raggiunto circa 1320 richieste da parte dell'autore e circa 36.000 risposte del modello in una sola sessione continua.
Il risultato è stato di 1500 commit, in cui 83.000 righe di codice sono state dedicate all'implementazione e altre 137.000 righe di codice ai test. Secondo una stima preliminare, sono stati spesi circa 18,9 miliardi di token, e il costo equivalente per una tale quantità, utilizzando le tariffe API, sarebbe stato di circa 40.000 dollari.
L'autore inizialmente prevedeva uno sviluppo quasi completamente autonomo da parte del modello AI, tuttavia la logica complessa di DRBD ha richiesto il continuo coinvolgimento umano. Gli scenari più complessi si sono rivelati essere quelli della convergenza degli stati DRBD, il lavoro con il Generation Identifier (GI), il superamento della sincronizzazione iniziale e la gestione degli scenari di split-brain.
Poiché LINSTOR originale è distribuito con licenza GPL, non è stato possibile utilizzare il suo codice direttamente. La parte principale dell'implementazione è stata creata sulla base dell'analisi dei contratti API, del comportamento degli strumenti, del client Python di LINSTOR, oltre a progetti compatibili con la licenza, incluso piraeus-operator e il driver CSI.
Nei casi più complessi è stato applicato uno schema di separazione dei ruoli degli agenti AI: un agente analizzava il codice sorgente di LINSTOR e creava una specifica testuale del comportamento, dopodiché 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
