K dispozici je první vydání Blockstor — otevřeného systému správy distribuovaného blokového úložiště pro Kubernetes, které zajišťuje replikaci dat nad DRBD. Blockstor je kompatibilní přes REST API s LINSTOR a může fungovat bez změn v existujícím ekosystému klientů, včetně příkazové utility linstor, CSI ovladače, operátora Piraeus, ha-controlleru a knihovny golinstor. Projekt představuje plně samostatnou (clean-room) implementaci v jazyce Go, která nepoužívá zdrojový kód originálu. Kód je šířen pod licencí Apache 2.0 a je vyvíjen v rámci platformy Cozystack (projekt CNCF Sandbox).
Autorem projektu je Andrej Kvapil (@kvaps), zakladatel Cozystack a účastník neziskové organizace Piraeus, v rámci které se vyvíjí operátor a CSI ovladač LINSTOR pro Kubernetes. Autor je v komunitě Kubernetes znám jako popularizátor LINSTOR a opakovaně vystupoval s technickými prezentacemi na toto téma. Původně byla vývoj plánována jako malá 'páteční' iniciativa, ale nakonec se proměnila v přibližně 20 dní nepřetržité práce. V současné době je projekt vyvíjen jako výzkumný, ale do budoucna se zvažuje jako možná náhrada LINSTOR v roli výchozího úložiště v Cozystack.
Mezi důvody vzniku nového projektu se uvádějí obtíže s údržbou originálního projektu a předáváním změn do hlavního projektu, stejně jako architektura LINSTOR. Originální projekt používá 'request-based' model zpracování požadavků v reálném čase, který vykazuje problémy při škálování, zatímco deklarativní přístup k usmiřování Kubernetes a framework controller-runtime se podle autora mnohem lépe hodí pro výstavbu distribuovaných systémů.
Na rozdíl od LINSTOR je architektura Blockstor plně založena na přístupu Kubernetes controller-runtime. Konfigurace a aktuální stav systému jsou reprezentovány jako objekty Kubernetes CRD, a samotný systém není navržen k provozu mimo Kubernetes cluster.
Mezi hlavní funkcionality Blockstor patří:
- Replikované nad DRBD objemy na bázi LVM, LVM-thin, ZFS, ZFS-thin a souborových backendů.
- Automatické umístění replik s ohledem na zóny, vlastnosti uzlů a pravidla 'replicas-on-different'.
- Podpora TieBreaker, quorum a změny velikosti objemů bez přerušení provozu.
- Možnost provozu bez DRBD v režimu místního (single-replica diskful) nebo bezdiskového úložiště.
- Šifrování svazků pomocí LUKS.
- Podpora snapshotů: vytváření, vracení zpět, klonování a obnovení jako nového zdroje.
- Přenášení snapshotů uvnitř clusteru prostřednictvím zfs send/recv a thin-send-recv.
- Vytváření storage poolů z fyzických disků.
- Sestavené kontejnerové obrazy pro různé architektury (linux/amd64 a linux/arm64), publikované v GHCR.
Hlavním rysem projektu bylo aktivní využívání AI nástrojů při vývoji. Prakticky celý kód byl připraven pomocí Claude Code (model Opus 4.7) společnosti Anthropic. Vývoj probíhal téměř nepřetržitě po dobu přibližně 20 dní. V některých okamžicích pracovalo současně až 60 AI agentů a celkový dialog vývoje činil přibližně 1320 dotazů ze strany autora a asi 36 tisíc odpovědí modelu v rámci jedné nepřetržité relace.
Na konci bylo 1500 commitů, ve kterých 83 tisíc řádků kódu zabralo implementace a dalších 137 tisíc řádků kódu testy. Podle předběžného odhadu bylo celkem vynaloženo asi 18,9 miliardy tokenů a ekvivalentní náklady na tuto velikost při použití API tarifů by činily přibližně 40 tisíc dolarů.
Autor původně počítal s téměř plně autonomním vývojem pomocí AI modelu, avšak složitá logika DRBD vyžadovala stálou účast člověka. Nejnáročnější byly scénáře shody DRBD stavů, práce s Generačním identifikátorem (GI), vynechání původní synchronizace a zpracování scénářů split-brain.
Protože originální LINSTOR je distribuován pod licencí GPL, nebylo možné používat jeho kód přímo. Hlavní část implementace byla vytvářena na základě analýzy API kontraktů, chování utilit, Python klienta LINSTOR a dalších projektů kompatibilních s licencí, včetně piraeus-operator a CSI ovladače.
V nejkomplexnějších případech byla použita schéma s rozdělením rolí AI agentů: jeden agent analyzoval zdrojový kód LINSTOR a vytvářel textovou specifikaci chování, načež druhý agent implementoval funkčnost výhradně podle této specifikace, bez přímého kopírování zdrojového kódu. Vzhledem k nedostatku otevřených testů v původním projektu bylo nutné testovací základnu vytvořit samostatně.
Zdroj: opennet.ru
