Die erste Ausgabe von Blockstor ist jetzt verfügbar - einem Open-Source-Verwaltungssystem für verteilten Blockspeicher in Kubernetes, das eine Datenreplikation über DRBD ermöglicht. Blockstor ist über die REST-API mit LINSTOR kompatibel und kann ohne Anpassungen in der bestehenden Client-Umgebung, einschließlich der Befehlszeilen-Dienstprogramme linstor, CSI-Treiber, Operator Piraeus, ha-controller und der Bibliothek golinstor, eingesetzt werden. Das Projekt ist eine vollständig eigenständige (clean-room) Implementierung in der Programmiersprache Go, die keinen Originalquellcode verwendet. Der Code wird unter der Apache 2.0-Lizenz veröffentlicht und entwickelt sich im Rahmen der Cozystack-Plattform (CNCF Sandbox-Projekt).
Der Projektleiter ist Andrej Kwapil (@kvaps), der Gründer von Cozystack und Mitglied der gemeinnützigen Organisation Piraeus, in deren Rahmen der Operator und der CSI-Treiber LINSTOR für Kubernetes entwickelt werden. Der Autor ist in der Kubernetes-Community als Förderer von LINSTOR bekannt und hat mehrfach technische Vorträge zu diesem Thema gehalten. Ursprünglich wurde die Entwicklung als kleine 'Freitag'-Initiative gedacht, entwickelte sich jedoch letztendlich über etwa 20 Tage kontinuierlicher Arbeit. Aktuell wird das Projekt als Forschungsprojekt weiterentwickelt, jedoch wird in der Zukunft eine mögliche Ablösung von LINSTOR als standardmäßige Speicherlösung in Cozystack in Betracht gezogen.
Zu den Gründen für die Gründung des neuen Projekts zählen die Schwierigkeiten bei der Wartung des Originalprojekts und der Übertragung von Änderungen in das Hauptprojekt sowie architektonische Einschränkungen von LINSTOR. Das Originalprojekt verwendet ein 'request-based'-Modell zur Verarbeitung von Echtzeitanfragen, das bei großen Maßstäben Probleme zeigt, während der deklarative Rekonsilierungsansatz von Kubernetes und das Framework controller-runtime, so der Autor, deutlich besser für den Aufbau verteilter Systeme geeignet ist.
Im Gegensatz zu LINSTOR basiert die Architektur von Blockstor vollständig auf dem Ansatz von Kubernetes controller-runtime. Die Konfiguration und der aktuelle Zustand des Systems werden in Form von Kubernetes CRD-Objekten dargestellt, und das System ist nicht dafür ausgelegt, außerhalb eines Kubernetes-Clusters zu arbeiten.
Zu den Hauptfunktionen von Blockstor gehören:
- Replizierte LVM-, LVM-thin-, ZFS-, ZFS-thin- und Dateispeicher-Volumes, die auf DRBD basieren.
- Automatische Platzierung von Replikaten unter Berücksichtigung von Zonen, Knotenmerkmalen und Regeln wie 'replicas-on-different'.
- Unterstützung für TieBreaker, Quorum und Größenänderung von Volumes ohne Unterbrechung des Betriebs.
- Möglichkeit des Betriebs ohne DRBD im lokalen Modus (single-replica diskful) oder ohne Disk-Speicher.
- Verschlüsselung von Volumes über LUKS.
- Unterstützung von Snapshots: Erstellen, Zurücksetzen, 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-Abbilder (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 Hilfe von Claude Code (Modell Opus 4.7) von Anthropic erstellt. Die Entwicklung fand fast 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 bestand aus etwa 1320 Anfragen des Autors und rund 36.000 Antworten des Modells im Rahmen einer einzigen kontinuierlichen Sitzung.
Es entstanden 1500 Commits, in denen 83.000 Codezeilen für die Implementierung und weitere 137.000 Codezeilen für Tests benötigt wurden. Schätzungen zufolge wurden insgesamt etwa 18,9 Milliarden Token verbraucht, wobei die äquivalente Kosten für ein solches Volumen bei Nutzung von API-Tarifen ungefähr 40.000 Dollar betragen würde.
Der Autor plante ursprünglich eine fast vollständig autonome Entwicklung durch das KI-Modell, jedoch erforderte die komplexe Logik von DRBD ständige menschliche Intervention. Am schwierigsten waren die Szenarien der DRBD-Zustandsübereinstimmung, die Arbeit mit dem Generation Identifier (GI), das Überspringen der anfänglichen Synchronisation und die Behandlung von Split-Brain-Szenarien.
Da das ursprüngliche LINSTOR unter der GPL-Lizenz vertrieben wird, konnte der Code nicht direkt verwendet werden. Der Großteil der Implementierung wurde auf der Analyse von API-Verträgen, dem Verhalten von Tools, dem Python-Client von LINSTOR sowie von lizenzierten kompatiblen Projekten, einschließlich piraeus-operator und CSI-Driver, erstellt.
In den schwierigsten Fällen wurde ein Schema mit der Teilung von Rollen der KI-Agenten angewendet: Ein Agent analysierte den Quellcode von LINSTOR und erstellte eine Textspezifikation des Verhaltens, während ein anderer Agent die Funktionalität ausschließlich nach dieser Spezifikation ohne direktes Kopieren des Quellcodes umsetzte. Aufgrund fehlender öffentlicher Tests des ursprünglichen Projekts musste die Testbasis selbständig erstellt werden.
Quelle: opennet.ru
