Наличен е първият вариант на Blockstor — открита система за управление на разпределено блочно съхранение за Kubernetes, която осигурява репликация на данни върху DRBD. Blockstor е съвместим по REST API с LINSTOR и може да работи без промени с съществуващата екосистема на клиентите, включително командния инструмент linstor, CSI драйвера, оператора Piraeus, ha-controller и библиотеката golinstor. Проектът представлява напълно самостоятелна (clean-room) реализация на езика Go, която не използва изходния код на оригинала. Кодът се разпространява под лицензия Apache 2.0 и се развива в рамките на платформата Cozystack (проект на CNCF Sandbox).
Автор на проекта е Андрей Квапил (@kvaps), основател на Cozystack и участник в неправителствената организация Piraeus, в рамките на която се развиват операторът и CSI драйверът на LINSTOR за Kubernetes. Авторът е известен в общността на Kubernetes като популяризатор на LINSTOR и многократно е изнасял технически доклади по темата. Първоначално разработката е била замислена като малка "петъчна" инициатива, но в крайна сметка е прераснала в около 20 дни непрекъсната работа. В момента проектът се развива като изследователски, но в перспектива се разглежда като възможна замяна на LINSTOR в ролята на система за съхранение по подразбиране в Cozystack.
Като причини за създаването на новия проект се посочват трудности с поддръжката на оригиналния проект и предаването на изменения в основния проект, както и архитектурни ограничения на LINSTOR. Оригиналният проект използва "request-based" модел на обработка на заявки в реално време, който показва проблеми при мащабиране, докато декларативният reconciliation подход на Kubernetes и framework controller-runtime, според автора, значително по-добре подхождат за изграждане на разпределени системи.
В отличие от LINSTOR, архитектурата на Blockstor е напълно основана на подхода на Kubernetes controller-runtime. Конфигурацията и текущото състояние на системата са представени под формата на Kubernetes CRD обекти, а самата система не е предназначена да работи извън кластер на Kubernetes.
Сред основните възможности на Blockstor:
- Реплицирани върху DRBD тома на базата на LVM, LVM-thin, ZFS, ZFS-thin и файлови бекенди.
- Автоматично разпределение на репликите, като се взимат предвид зони, свойства на възлите и правила „replicas-on-different”.
- Поддръжка на TieBreaker, quorum и промяна на размера на томовете без прекъсване на работата.
- Възможност за работа без DRBD в режим локално (single-replica diskful) или бездисково хранилище.
- criptиране на томове чрез LUKS.
- Поддръжка на снимки: създаване, възстановяване, клониране и възстановяване като нов ресурс.
- Прехвърляне на снимки в кластера чрез zfs send/recv и thin-send-recv.
- Създаване на storage pool'ове от физически дискове.
- Събрани за различни архитектури контейнерни образи (linux/amd64 и linux/arm64), публикувани в GHCR.
Характерна черта на проекта е активното използване на AI инструменти в разработката. Практически целият код е бил подготвен с помощта на Claude Code (модел Opus 4.7) на компанията Anthropic. Разработката е протекла почти денонощно в продължение на около 20 дни. В отделни моменти едновременно работят до 60 AI агента, а общият диалог по разработката е съставил около 1320 запитвания от страна на автора и около 36 хиляди отговора на модела в рамките на една непрекъсната сесия.
На изхода получихме 1500 комита, в които 83 хиляди реда код заеха реализацията и още 137 хиляди реда код за тестове. Според предварителна оценка, общо бяха изразходвани около 18.9 млрд токена, а еквивалентната стойност на този обем при използване на API тарифите възлиза на около 40 хиляди долара.
Авторът първоначално разчиташе на почти напълно автономно разработване с помощта на AI модела, но сложната логика на DRBD изискваше постоянно участие на човек. Най-сложни се оказаха сценарии на сближаване на състоянията на DRBD, работа с Generation Identifier (GI), пропуск на първоначалната синхронизация и обработка на сценарии на split-brain.
Тъй като оригиналният LINSTOR се разпространява под лиценз GPL, не можеше да се използва директно неговият код. Основната част от реализацията беше изградена на база анализ на API договори, поведението на утилитите, Python клиента на LINSTOR, както и съвместими проекти по лиценз, включително piraeus-operator и CSI драйвера.
В най-сложните случаи бе използвана схема с разделяне на ролите на AI агенти: един агент анализираше изходния код на LINSTOR и формулираше текстова спецификация на поведението, след което друг агент реализираше функционалността изцяло по тази спецификация без директно копиране на изходния код. Поради липсата на открити тестове на оригиналния проект, тестовата база трябваше да бъде формирана самостоятелно.
Източник: opennet.ru
