Pierwsza wersja Blockstor jest już dostępna - otwartego systemu zarządzania rozproszonym przechowywaniem bloków dla Kubernetes, zapewniającego replikację danych na bazie DRBD. Blockstor jest zgodny z REST API LINSTOR i może działać bez zmian w istniejącej ekosystemie klientów, w tym narzędziem wiersza poleceń linstor, sterownikiem CSI, operatorem Piraeus, ha-controller i biblioteką golinstor. Projekt jest całkowicie samodzielną (clean-room) implementacją w języku Go, nie wykorzystującą kodu źródłowego oryginału. Kod jest rozpowszechniany na licencji Apache 2.0 i rozwija się w ramach platformy Cozystack (projekt CNCF Sandbox).
Autorem projektu jest Andrzej Kwapił (@kvaps), założyciel Cozystack i członek organizacji non-profit Piraeus, w ramach której rozwijane są operator i sterownik CSI LINSTOR dla Kubernetes. Autor jest znany w społeczności Kubernetes jako popularyzator LINSTOR i wielokrotnie wygłaszał techniczne wykłady na ten temat. Początkowo rozwój był zakładany jako mała inicjatywa 'piątkowa', jednak ostatecznie przerodził się w około 20 dni ciągłej pracy. Na chwilę obecną projekt rozwija się jako badawczy, jednak w przyszłości rozważa się go jako możliwą alternatywę dla LINSTOR jako domyślnej systemu przechowywania w Cozystack.
Jako przyczyny stworzenia nowego projektu wymieniane są trudności z utrzymaniem oryginalnego projektu oraz przekazywaniem zmian do głównego projektu, a także ograniczenia architektoniczne LINSTOR. Oryginalny projekt stosuje model przetwarzania żądań oparty na 'request-based', który wykazuje problemy w dużej skali, podczas gdy deklaratywne podejście do rekonsyliacji Kubernetes i framework controller-runtime, według autora, znacznie lepiej nadaje się do budowy rozproszonych systemów.
W przeciwieństwie do LINSTOR, architektura Blockstor jest w pełni oparta na podejściu Kubernetes controller-runtime. Konfiguracja i aktualny stan systemu są przedstawiane w postaci obiektów CRD Kubernetes, a sam system nie jest przeznaczony do pracy poza klastrem Kubernetes.
Do głównych możliwości Blockstor należą:
- Replikowane na bazie DRBD woluminy LVM, LVM-thin, ZFS, ZFS-thin oraz backendy plikowe.
- Automatyczne rozmieszczanie replik biorące pod uwagę strefy, właściwości węzłów i zasady „replicas-on-different”.
- Wsparcie dla TieBreaker, quorum oraz zmiany rozmiaru woluminów bez przerywania pracy.
- Możliwość pracy bez DRBD w trybie lokalnym (single-replica diskful) lub bezdyskowego przechowywania.
- Szyfrowanie woluminów za pomocą LUKS.
- Wsparcie dla migawek: tworzenie, przywracanie, klonowanie i przywracanie jako nowego zasobu.
- Przenoszenie migawek wewnątrz klastra przez zfs send/recv i thin-send-recv.
- Tworzenie pul storage z fizycznych dysków.
- Zbudowane dla różnych architektur obrazy kontenerów (linux/amd64 i linux/arm64), opublikowane w GHCR.
Cechą projektu było aktywne wykorzystanie narzędzi AI podczas tworzenia. Praktycznie cały kod został przygotowany z pomocą Claude Code (model Opus 4.7) firmy Anthropic. Rozwój trwał prawie 24 godziny na dobę przez około 20 dni. W niektórych momentach jednocześnie działało do 60 agentów AI, a całkowity dialog rozwoju wyniósł około 1320 zapytań ze strony autora i około 36 tysięcy odpowiedzi modelu w ramach jednej ciągłej sesji.
Na końcu powstało 1500 commitów, w których 83 tysiące linii kodu zajęła implementacja, a kolejne 137 tysięcy linii kodu to testy. Wstępnie oszacowano, że łącznie zużyto około 18,9 miliarda tokenów, a równoważny koszt takiej objętości przy użyciu stawek API wyniósłby około 40 tysięcy dolarów.
Autor początkowo planował niemal w pełni autonomiczny rozwój przy pomocy modelu AI, jednak skomplikowana logika DRBD wymagała stałego udziału człowieka. Najbardziej skomplikowane okazały się scenariusze konwergencji stanów DRBD, praca z identyfikatorem generacji (GI), pomijanie początkowej synchronizacji oraz obsługa scenariuszy split-brain.
Ponieważ oryginalny LINSTOR jest rozpowszechniany na licencji GPL, nie można było bezpośrednio wykorzystywać jego kodu. Główna część implementacji została stworzona na podstawie analizy kontraktów API, zachowania narzędzi, klienta Python LINSTOR, a także projektów zgodnych z licencją, w tym piraeus-operator i CSI-driver.
W najbardziej skomplikowanych przypadkach zastosowano schemat z podziałem ról agentów AI: jeden agent analizował źródłowy kod LINSTOR i tworzył tekstową specyfikację zachowania, po czym inny agent wdrażał funkcjonalność wyłącznie na podstawie tej specyfikacji bez bezpośredniego kopiowania kodu źródłowego. Z powodu braku otwartych testów w oryginalnym projekcie, bazę testową trzeba było utworzyć samodzielnie.
Źródło: opennet.ru
