Ya está disponible la primera versión de Blockstor: un sistema de gestión de almacenamiento en bloque distribuido de código abierto para Kubernetes, que proporciona replicación de datos por encima de DRBD. Blockstor es compatible con la API REST de LINSTOR y puede funcionar sin cambios dentro del ecosistema existente de clientes, incluyendo la utilidad de línea de comandos linstor, el controlador CSI, el operador Piraeus, ha-controller y la biblioteca golinstor. El proyecto es una implementación completamente independiente (clean-room) en el lenguaje Go, que no utiliza el código fuente del original. El código se distribuye bajo la licencia Apache 2.0 y se desarrolla dentro de la plataforma Cozystack (proyecto CNCF Sandbox).
El autor del proyecto es Andrei Kvapil (@kvaps), fundador de Cozystack y miembro de la organización sin fines de lucro Piraeus, que desarrolla el operador y el controlador CSI de LINSTOR para Kubernetes. El autor es conocido en la comunidad de Kubernetes como un promotor de LINSTOR y ha dado numerosas charlas técnicas sobre el tema. Inicialmente, el desarrollo se concibió como una pequeña iniciativa 'de viernes', pero finalmente se convirtió en aproximadamente 20 días de trabajo continuo. Actualmente, el proyecto se desarrolla como una investigación, pero a futuro se plantea como un posible reemplazo de LINSTOR en el rol de sistema de almacenamiento predeterminado en Cozystack.
Como razones para la creación del nuevo proyecto se mencionan las dificultades con el mantenimiento del proyecto original y la transferencia de cambios al proyecto principal, así como las limitaciones arquitectónicas de LINSTOR. El proyecto original utiliza un modelo de procesamiento de solicitudes 'basado en solicitudes' en tiempo real, que muestra problemas a gran escala, mientras que el enfoque de reconciliación declarativa de Kubernetes y el framework controller-runtime, en opinión del autor, se adapta significativamente mejor a la construcción de sistemas distribuidos.
A diferencia de LINSTOR, la arquitectura de Blockstor se basa completamente en el enfoque controller-runtime de Kubernetes. La configuración y el estado actual del sistema se representan en forma de objetos CRD de Kubernetes, y el sistema no está diseñado para funcionar fuera del clúster de Kubernetes.
Entre las principales capacidades de Blockstor:
- Volúmenes replicados sobre DRBD basados en LVM, LVM-thin, ZFS, ZFS-thin y backends de archivos.
- Colocación automática de réplicas teniendo en cuenta zonas, propiedades de nodos y reglas 'replicas-on-different'.
- Soporte para TieBreaker, quorum y cambio de tamaño de volúmenes sin interrumpir el funcionamiento.
- La posibilidad de operar sin DRBD en modo local (diskful de réplica única) o almacenamiento sin disco.
- Cifrado de volúmenes a través de LUKS.
- Soporte para instantáneas: creación, reversión, clonación y recuperación como un nuevo recurso.
- Transferencia de instantáneas dentro del clúster a través de zfs send/recv y thin-send-recv.
- Creación de pools de almacenamiento a partir de discos físicos.
- Imágenes de contenedor construidas para diferentes arquitecturas (linux/amd64 y linux/arm64), publicadas en GHCR.
Una característica del proyecto fue el uso activo de herramientas de IA durante el desarrollo. Prácticamente todo el código fue preparado con Claude Code (modelo Opus 4.7) de la empresa Anthropic. El desarrollo se llevó a cabo casi de manera continua durante aproximadamente 20 días. En ciertos momentos, hasta 60 agentes de IA trabajaron simultáneamente, y el diálogo total de desarrollo consistió en alrededor de 1320 consultas del autor y aproximadamente 36 mil respuestas del modelo en el marco de una única sesión continua.
Al final, se generaron 1500 commits, de los cuales 83 mil líneas de código se dedicaron a la implementación y otras 137 mil líneas a las pruebas. Según estimaciones preliminares, se consumieron alrededor de 18.9 mil millones de tokens, y el costo equivalente de tal volumen utilizando tarifas de API habría sido de aproximadamente 40 mil dólares.
El autor inicialmente esperaba un desarrollo casi completamente autónomo por parte del modelo de IA, sin embargo, la lógica compleja de DRBD requirió participación humana constante. Los escenarios más complicados fueron el alineamiento de estados de DRBD, el trabajo con el Identificador de Generación (GI), la omisión de la sincronización inicial y el manejo de escenarios de split-brain.
Dado que el LINSTOR original se distribuye bajo la licencia GPL, no se podía utilizar su código directamente. La mayor parte de la implementación se creó a partir del análisis de contratos de API, el comportamiento de utilidades, el cliente de Python LINSTOR y proyectos compatibles con la licencia, incluidos piraeus-operator y el controlador CSI.
En los casos más complejos se utilizó un esquema de división de roles para los agentes de IA: un agente analizó el código fuente de LINSTOR y generó una especificación de texto del comportamiento, después otro agente implementó la funcionalidad exclusivamente según esa especificación sin copiar directamente el código fuente. Debido a la falta de pruebas abiertas en el proyecto original, la base de pruebas tuvo que formarse de manera independiente.
Fuente: opennet.ru
