La première version de Blockstor est maintenant disponible — un système de gestion open source de stockage block distribué pour Kubernetes, assurant la réplication des données via DRBD. Blockstor est compatible avec l'API REST de LINSTOR et peut fonctionner sans modifications avec l'écosystème client existant, y compris l'outil de ligne de commande linstor, le driver CSI, l'opérateur Piraeus, ha-controller et la bibliothèque golinstor. Le projet est une implémentation totalement autonome (clean-room) en langage Go, n'utilisant pas le code source de l'original. Le code est distribué sous la licence Apache 2.0 et est développé dans le cadre de la plateforme Cozystack (projet CNCF Sandbox).
L'auteur du projet est Andrey Kvapil (@kvaps), fondateur de Cozystack et membre de l'organisation à but non lucratif Piraeus, qui développe l'opérateur et le driver CSI LINSTOR pour Kubernetes. L'auteur est connu dans la communauté Kubernetes en tant que promoteur de LINSTOR et a donné de nombreuses conférences techniques sur le sujet. Initialement, le développement était conçu comme une initiative « vendredi » modeste, mais il a finalement abouti à environ 20 jours de travail continu. Actuellement, le projet se développe en tant que recherche, mais il est envisagé comme un remplacement possible de LINSTOR en tant que système de stockage par défaut dans Cozystack.
Parmi les raisons de création du nouveau projet, on mentionne les difficultés de maintenance de l'original et la transmission de modifications au projet principal, ainsi que les limitations architecturales de LINSTOR. Le projet original utilise un modèle de traitement des requêtes « request-based » en temps réel, qui présente des problèmes à grande échelle, tandis que l'approche de réconciliation déclarative de Kubernetes et le framework controller-runtime, selon l'auteur, conviennent beaucoup mieux à la construction de systèmes distribués.
Contrairement à LINSTOR, l'architecture de Blockstor est entièrement basée sur l'approche controller-runtime de Kubernetes. La configuration et l'état actuel du système sont présentés sous forme d'objets CRD Kubernetes, et le système n'est pas conçu pour fonctionner en dehors d'un cluster Kubernetes.
Parmi les principales fonctionnalités de Blockstor :
- Volumes répliqués via DRBD basés sur LVM, LVM-thin, ZFS, ZFS-thin et des backends de fichiers.
- Placement automatique des répliques en tenant compte des zones, des propriétés des nœuds et des règles « replicas-on-different ».
- Prise en charge de TieBreaker, quorum et dimensionnement des volumes sans interruption de service.
- Possibilité de fonctionner sans DRBD en mode local (disque unique avec réplication) ou avec stockage sans disque.
- Chiffrement des volumes via LUKS.
- Support des snapshots : création, restauration, clonage et récupération sous forme de nouvelle ressource.
- Transfert de snapshots à l'intérieur du cluster via zfs send/recv et thin-send-recv.
- Création de pools de stockage à partir de disques physiques.
- Images de conteneurs compilées pour différentes architectures (linux/amd64 et linux/arm64), publiées sur GHCR.
Une caractéristique du projet a été l'utilisation active des outils d'IA lors du développement. Pratiquement tout le code a été préparé avec Claude Code (modèle Opus 4.7) de la société Anthropic. Le développement a duré presque 20 jours avec un travail presque continu. À certains moments, jusqu'à 60 agents d'IA ont travaillé simultanément, et le dialogue de développement a compté environ 1320 requêtes de l'auteur et environ 36 000 réponses du modèle dans le cadre d'une session continue.
Au total, il y a eu 1500 commits, avec 83 000 lignes de code pour l'implémentation et 137 000 lignes de code pour les tests. Selon les estimations, environ 18,9 milliards de tokens ont été utilisés, et le coût équivalent pour un tel volume avec les tarifs API serait d'environ 40 000 dollars.
L'auteur comptait initialement sur un développement presque entièrement autonome par des modèles d'IA, mais la logique complexe de DRBD nécessitait une participation humaine constante. Les scénarios de synchronisation des états DRBD, le travail avec l'identifiant de génération (GI), le saut de synchronisation initiale et le traitement des scénarios de split-brain se sont révélés être les plus complexes.
Puisque le LINSTOR original est distribué sous licence GPL, il n'était pas possible d'utiliser son code directement. La majeure partie de l'implémentation a été réalisée sur la base de l'analyse des contrats API, du comportement des utilitaires, du client Python de LINSTOR ainsi que de projets compatibles par licence, y compris piraeus-operator et CSI-driver.
Dans les cas les plus complexes, un schéma de division des rôles des agents d'IA a été appliqué : un agent analysait le code source de LINSTOR et élaborait une spécification textuelle de comportement, après quoi un autre agent mettait en œuvre la fonctionnalité uniquement selon cette spécification sans copier directement le code source. En raison de l'absence de tests ouverts dans le projet original, il a fallu constituer la base de tests par nous-mêmes.
Source : opennet.ru
