Die erste Version von Blockstor ist jetzt verfügbar – ein offenes System zur Verwaltung von verteiltem Blockspeicher für Kubernetes, das Datenreplikation über DRBD ermöglicht. Blockstor ist REST-API-kompatibel mit LINSTOR und kann ohne Änderungen in der bestehenden Kundenökosystem arbeiten, einschließlich des Kommandozeilenwerkzeugs linstor, des CSI-Treibers, des Piraeus Operators, des ha-Controllers und der Golinstor-Bibliothek. Das Projekt ist eine vollständig eigenständige (Clean-Room) Implementierung in der Programmiersprache Go und verwendet nicht den Quellcode des Originals. Der Code wird unter der Apache 2.0 Lizenz veröffentlicht und entwickelt sich im Rahmen der Cozystack-Plattform (CNCF Sandbox-Projekt).
Projektinitiator ist Andrei Kvapil (@kvaps), Gründer von Cozystack und Mitglied der Non-Profit-Organisation Piraeus, die den LINSTOR-Operator und den CSI-Treiber für Kubernetes entwickelt. Er ist in der Kubernetes-Community als Befürworter von LINSTOR bekannt und hat mehrfach technische Vorträge zu diesem Thema gehalten. Ursprünglich wurde die Entwicklung als kleine „Freitags“-Initiative angedacht, entwickelte sich jedoch schließlich zu etwa 20 Tagen ununterbrochener Arbeit. Aktuell wird das Projekt als Forschungsinitiative weiterentwickelt, wird jedoch als potenzielle Alternative zu LINSTOR als Standardspeichersystem in Cozystack angesehen.
Als Gründe für die Schaffung eines neuen Projekts werden die Schwierigkeiten bei der Pflege des Originalprojekts und der Übertragung von Änderungen in das Hauptprojekt sowie architektonische Einschränkungen von LINSTOR genannt. Das Originalprojekt verwendet ein „request-based“ Modell zur Verarbeitung von Echtzeitanfragen, das Probleme in größeren Maßstäben aufzeigt. Der deklarative Reconciliation-Ansatz von Kubernetes und das Controller-Runtime-Framework eignen sich laut Autor deutlich besser für den Aufbau verteilter Systeme.
Im Gegensatz zu LINSTOR basiert die Architektur von Blockstor vollständig auf dem Kubernetes controller-runtime-Ansatz. Die Konfiguration und der aktuelle Status des Systems sind in Form von Kubernetes CRD-Objekten dargestellt, und das System ist nicht für den Betrieb außerhalb eines Kubernetes-Clusters konzipiert.
Zu den Hauptfunktionen von Blockstor gehören:
- Replizierbare Volumes auf Basis von DRBD, LVM, LVM-thin, ZFS, ZFS-thin und Dateibackends.
- Automatische Platzierung von Replikaten unter Berücksichtigung von Zonen, Knoten-Eigenschaften und den Regeln "replicas-on-different."
- Unterstützung von TieBreaker, Quorum und Größenänderung von Volumes ohne Unterbrechung des Betriebs.
- Möglichkeit der Nutzung ohne DRBD im Modus lokal (single-replica diskful) oder als diskloser Speicher.
- Verschlüsselung von Volumes mit LUKS.
- Unterstützung von Snapshots: Erstellen, Wiederherstellen, Klonen und Wiederherstellen als neue Ressource.
- Übertragung von Snapshots innerhalb des Clusters über zfs send/recv und thin-send-recv.
- Erstellung von Storage-Pools aus physischen Festplatten.
- Für verschiedene Architekturen gebaute Container-Images (linux/amd64 und linux/arm64), veröffentlicht in GHCR.
Ein Merkmal des Projekts war die aktive Nutzung von KI-Tools während der Entwicklung. Fast der gesamte Code wurde mit Claude Code (Modell Opus 4.7) von Anthropic vorbereitet. Die Entwicklung fand nahezu rund um die Uhr über einen Zeitraum von etwa 20 Tagen statt. Zu bestimmten Zeiten arbeiteten bis zu 60 KI-Agenten gleichzeitig, und der gesamte Entwicklungsdialog umfasste etwa 1320 Anfragen des Autors und rund 36.000 Antworten des Modells in einer einzigen kontinuierlichen Sitzung.
Am Ende gab es 1500 Commits, bei denen 83.000 Codezeilen für die Implementierung verwendet wurden und weitere 137.000 Codezeilen für Tests. Nach ersten Schätzungen wurden insgesamt etwa 18,9 Milliarden Tokens verbraucht, und die äquivalente Kosten eines solchen Volumens bei Nutzung der API-Tarife würden etwa 40.000 Dollar betragen.
Der Autor plante ursprünglich eine nahezu vollständig autonome Entwicklung durch das KI-Modell, jedoch erforderte die komplexe Logik von DRBD die ständige Einbeziehung eines Menschen. Besonders herausfordernd waren die Szenarien für die Übereinstimmung der DRBD-Zustände, die Arbeit mit dem Generation Identifier (GI), die Überspringung der ursprünglichen Synchronisation und die Verarbeitung von Split-Brain-Szenarien.
Da der originale LINSTOR unter der GPL-Lizenz veröffentlicht wird, war es nicht möglich, seinen Code direkt zu verwenden. Der Großteil der Implementierung wurde auf Grundlage der Analyse von API-Verträgen, dem Verhalten von Dienstprogrammen, dem Python-Client von LINSTOR sowie kompatiblen Lizenzprojekten, einschließlich piraeus-operator und CSI-Treiber, erstellt.
In den komplexesten Fällen kam ein Modell mit einer Rollenverteilung von KI-Agenten zum Einsatz: Ein Agent analysierte den Quellcode von LINSTOR und erstellte eine textuelle Spezifikation des Verhaltens, nach der ein anderer Agent die Funktionalität ausschließlich basierend auf dieser Spezifikation ohne direkte Kopie des Quellcodes umsetzte. Aufgrund fehlender öffentlicher Tests des ursprünglichen Projekts musste die Testdatenbasis selbst erstellt werden.
Quelle: opennet.ru
