Está disponível a primeira versão do Blockstor — um sistema de gerenciamento de armazenamento em bloco distribuído para Kubernetes, que fornece replicação de dados sobre DRBD. O Blockstor é compatível com a API REST do LINSTOR e pode funcionar sem alterações na ecossistema existente de clientes, incluindo a ferramenta de linha de comando linstor, o driver CSI, o operador Piraeus, ha-controller e a biblioteca golinstor. O projeto é uma implementação totalmente independente (clean-room) em Go, sem usar o código-fonte original. O código é distribuído sob a licença Apache 2.0 e está sendo desenvolvido na plataforma Cozystack (projeto do CNCF Sandbox).
O autor do projeto é Andrei Kvapil (@kvaps), fundador da Cozystack e participante da organização sem fins lucrativos Piraeus, na qual o operador e o driver CSI do LINSTOR para Kubernetes estão em desenvolvimento. O autor é conhecido na comunidade Kubernetes como um defensor do LINSTOR e já apresentou diversas palestras técnicas sobre o tema. Inicialmente, o desenvolvimento foi concebido como uma pequena iniciativa 'de sexta-feira', mas acabou se transformando em cerca de 20 dias de trabalho contínuo. Neste momento, o projeto está sendo desenvolvido como uma pesquisa, mas no futuro pode ser considerado como uma possível substituição ao LINSTOR como sistema de armazenamento padrão na Cozystack.
Entre as razões para a criação do novo projeto estão as dificuldades em dar suporte ao projeto original e transferir mudanças para o projeto principal, além das limitações arquitetônicas do LINSTOR. O projeto original utiliza um modelo de processamento de solicitações 'baseado em requisições' em tempo real, o que revela problemas em larga escala, enquanto o abordagem declarativa de reconciliation do Kubernetes e o framework controller-runtime, segundo o autor, se adaptam muito melhor para a construção de sistemas distribuídos.
Ao contrário do LINSTOR, a arquitetura do Blockstor é totalmente baseada na abordagem do Kubernetes controller-runtime. A configuração e o estado atual do sistema são apresentados como objetos CRD do Kubernetes, e o próprio sistema não foi projetado para funcionar fora de um cluster Kubernetes.
Entre as principais funcionalidades do Blockstor:
- Volumes replicáveis sobre DRBD baseados em LVM, LVM-thin, ZFS, ZFS-thin e backends de arquivos.
- Colocação automática de réplicas levando em conta zonas, propriedades dos nós e regras de 'réplicas em diferentes'.
- Suporte a TieBreaker, quorum e redimensionamento de volumes sem interromper a operação.
- Capacidade de operação sem DRBD em modo local (disco único com réplica) ou armazenamento sem disco.
- Criptografia de volumes via LUKS.
- Suporte a snapshots: criação, rollback, clonagem e recuperação como um novo recurso.
- Transferência de snapshots dentro do cluster através de zfs send/recv e thin-send-recv.
- Criação de pools de armazenamento a partir de discos físicos.
- Imagens de contêineres compiladas para diferentes arquiteturas (linux/amd64 e linux/arm64), publicadas no GHCR.
Uma característica do projeto foi o uso ativo de ferramentas de IA durante o desenvolvimento. Praticamente todo o código foi preparado com a ajuda do Claude Code (modelo Opus 4.7) da Anthropic. O desenvolvimento foi realizado quase 24 horas por dia durante cerca de 20 dias. Em certos momentos, até 60 agentes de IA estavam operando simultaneamente, e o diálogo de desenvolvimento consistiu em cerca de 1320 perguntas do autor e aproximadamente 36 mil respostas do modelo em uma única sessão contínua.
No final, foram gerados 1500 commits, dos quais 83 mil linhas de código foram dedicadas à implementação e mais 137 mil linhas de código foram para testes. A avaliação preliminar indica que foram gastos cerca de 18,9 bilhões de tokens, e o custo equivalente do uso das tarifas de API seria de aproximadamente 40 mil dólares.
O autor inicialmente esperava um desenvolvimento quase totalmente autônomo por parte do modelo de IA, porém, a lógica complexa do DRBD exigiu a participação constante de um humano. Os cenários mais complicados foram a convergência dos estados do DRBD, trabalho com o Identificador de Geração (GI), bypass da sincronização inicial e tratamento de cenários de split-brain.
Como o LINSTOR original é distribuído sob a licença GPL, seu código não podia ser usado diretamente. A maior parte da implementação foi criada com base na análise dos contratos da API, no comportamento das utilitárias, no cliente Python do LINSTOR, e em projetos compatíveis com a licença, incluindo o piraeus-operator e o driver CSI.
Nos casos mais complexos, foi aplicada uma abordagem com divisão de papéis entre os agentes de IA: um agente analisava o código-fonte do LINSTOR e formulava uma especificação textual do comportamento, após o que outro agente implementava a funcionalidade exclusivamente com base nessa especificação, sem cópia direta do código-fonte. Devido à falta de testes abertos no projeto original, a base de testes teve que ser formada de forma independente.
Fonte: opennet.ru
