Публикувана е система за съхранение Blockstor, която е алтернатива на LINSTOR

Достъпен е първият брой на 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. Оригиналният проект използва модел на обработка на заявки в реално време, който показва проблеми на мащабите, докато декларативният подход на reconciliation в Kubernetes и framework controller-runtime, според автора, е значително по-подходящ за изграждането на разпределени системи.

За разлика от LINSTOR, архитектурата на Blockstor е напълно базирана на подхода на Kubernetes controller-runtime. Конфигурацията и текущото състояние на системата са представени като Kubernetes CRD обекти, а самата система не е проектирана да работи извън Kubernetes клъстера.

Сред основните възможности на Blockstor са:

• Реплицирани томове над DRBD с база данни LVM, LVM-thin, ZFS, ZFS-thin и файлови бекенди.
• Автоматично разпределение на репликите, като се вземат предвид зоните, свойствата на възлите и правилата за „реплики на различни места“.
• Поддръжка на TieBreaker, кворум и промяна на размера на томовете без спиране на работата.
• Възможност за работа без DRBD в режим на локален (single-replica diskful) или бездисково хранилище.
• Шифроване на томове чрез 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