Quando as equipes de TI, virtualização, backup, armazenamento e operações exploram Kubernetes, eles comparam recursos de proteção de dados e armazenamento com instalações tradicionais de bare metal e máquina virtual (VM).
Como a arquitetura nativa da nuvem é inerentemente distribuída, orientada por API e fracamente acoplada, as operações nativas da nuvem exigem novas ferramentas e habilidades para atingir os mesmos resultados comerciais de recuperação de desastres (DR). Embora muitos benefícios do armazenamento nativo da nuvem sejam impressionantes, uma área crítica ainda está faltando: rastreamento de bloco alterado (CBT).
Poder do Rastreamento de Blocos Alterados
No caso mais simples, o CBT melhora a eficiência do backup com backup incremental — encontrando e transmitindo apenas a diferença entre o que está atualmente armazenado e a imagem de backup mais recente. O CBT pode descobrir que houve pouca ou nenhuma alteração desde o último backup e fazer um novo backup quase instantâneo com consumo mínimo de tempo, CPU, memória ou armazenamento. Tornar as janelas de backup curtas e leves também ajuda as organizações a executar backups em uma frequência maior, o que reduz os objetivos do ponto de recuperação (RPOs) ou a quantidade de perda de dados incorrida.
CBT é um recurso de sistemas de armazenamento. A maioria desses sistemas oferece a capacidade de fazer snapshots de volumes, o que cria uma visualização somente leitura do seu volume no momento em que o snapshot é tirado.
Com o CBT habilitado, o sistema de armazenamento rastreará cada bloco gravado e pode fornecer uma lista de blocos que foram alterados entre os dois snapshots. Se um bloco for gravado várias vezes entre snapshots, ele só precisa ser copiado uma vez, pois o estado no momento do backup do snapshot é o único que precisa ser mantido. Isso torna o backup de volume muito eficiente, principalmente porque blocos que nunca foram gravados não precisam ser copiados.
A Ausência de CBT no Armazenamento Nativo da Nuvem
Como quase todos os provedores de armazenamento oferecem CBT, é surpreendente que o armazenamento nativo em nuvem com Kubernetes não tenha essa capacidade. Por quê? Uma resposta mais longa segue, mas a resposta curta é que, após dois anos de trabalho, o CBT do Kubernetes está quase aqui! Fornecedores e projetos de armazenamento e backup podem prototipar, dar feedback e melhorar o CBT em uma solução para todo o setor à medida que ele entra na fase alfa do Kubernetes.
Cargas de Trabalho e Armazenamento do Kubernetes com Estado
Dez anos após o lançamento do Kubernetes, cargas de trabalho com estado são comuns. Mas quando o Kubernetes lançou o StatefulSets em 2018, levou tempo para o armazenamento nativo da nuvem acelerar.
A versão 1.0 do Container Storage Interface (CSI) também foi adotada em 2018 com o Kubernetes 1.13 . O CSI fornece uma API uniforme para diferentes provedores de armazenamento e é um consórcio independente que publica especificações para todo o setor. Ele foi adotado por plataformas líderes, como Cloud Foundry , Apache Mesos e HashiCorp Nomad.
Os fornecedores de armazenamento criam drivers CSI, que são instalados em clusters Kubernetes . Todos os drivers de armazenamento "in-tree" proprietários na base de código do Kubernetes foram (ou estão em processo de serem) removidos em favor do CSI.
O Trabalho da Comunidade
O Kubernetes Data Protection Working Group (DPWG) foi formado em 2020 pelo Kubernetes Storage Special Interest Group (SIG-Storage). Também em 2020, a especificação CSI foi publicada VolumeSnapShot, que foi lançada no Kubernetes 1.20.
Anteriormente, o backup e a recuperação do Kubernetes só podiam lidar com sistemas de arquivos via CSI ou recorrer a drivers de armazenamento proprietários. O backup de armazenamento em bloco CSI rapidamente se tornou possível e mais robusto do que o backup do sistema de arquivos.
Em maio de 2022, o DPWG iniciou a Kubernetes Enhancement Proposal (KEP) #3314: Changed Block Tracking . Com orientação e revisão da liderança do SIG, SIGs pares, fornecedores (incluindo Veeam ) e a comunidade Kubernetes, o KEP 3314 passou por três grandes reformulações.
Cada uma progrediu por fases conceituais repetidas para revisão e defesa do design, com cada etapa melhorando o escopo para abordar problemas e lacunas. Este design CBT melhorou depois que os Grupos de Interesse Especial de API e Segurança (SIG API e SIG Security ) ajudaram a incorporar a arquitetura do Kubernetes e as melhores práticas de segurança.
Finalmente, em 2023, o terceiro design foi aprovado pelo DPWG, um protótipo de código foi concluído e uma proposta foi feita para adicionar CBT à especificação CSI.
O Design do CBT Nativo da Nuvem
A especificação CSI 1.11.0 com CBT por meio do SnapshotMetadataserviço foi publicada e atualizou o status do KEP-3314 para "implementável" em junho de 2024. O primeiro alvo foi o Kubernetes 1.31 como APIs alfa com o código protótipo, mas preparar pipelines para testar, adicionar documentação e aprender outras tarefas do Kubernetes e do mantenedor CSI fez com que ele escorregasse para o Kubernetes 1.32.
O público-alvo para a implementação do CSI CBT são os fornecedores de backup e armazenamento nativos em nuvem do Kubernetes. O processo de design do CBT inclui duas novas áreas:
- Fornecedores e projetos de armazenamento devem adotar e implantar o contêiner sidecar do serviço de metadados CBT do SIG-Storage CSI e recurso(s) personalizado(s). Então, o driver CSI deve implementar: - Adicione um novo SnapshotMetadataserviço para permitir que o orquestrador de contêineres obtenha metadados de bloco alocados ou alterados para snapshots.
- Fornecedores e projetos de backup devem adotar novas APIs do Kubernetes, que consomem CBT via gRPC
O diagrama de segurança a seguir mostra como o software de backup e o armazenamento em cluster podem orquestrar e fornecer acesso CBT a VolumeSnapShot:
Compartilhe Seu Feedback
A jornada para o CSI CBT nativo da nuvem acaba de começar sua fase de implementação. O Kubernetes DPWG e o CSI Consortium querem seu feedback sobre o CSI CBT.
Conforme o CSI CBT entra em sua fase alfa, você pode ajudar com a adoção e melhorias. Por favor, espalhe a palavra e forneça feedback que pode ser incorporado na fase beta.
Para fornecedores e projetos de armazenamento: Adotar o CSI CBT é tão simples quanto expor funcionalidades existentes por meio da nova API de contêiner sidecar do CSI CBT? Isso depende da arquitetura atual do driver CSI e da sua funcionalidade de CBT de armazenamento subjacente. Por favor, deixe-nos saber se este exemplo é útil.
Para fornecedores e projetos de backup: A adoção do CSI CBT não deveria ser tão fácil quanto consumir as novas APIs do Kubernetes com um fornecedor de armazenamento CSI CBT de suporte? Onde estão os provedores e testes simulados, e eles atendem às suas necessidades?
Para a comunidade Kubernetes: entre em contato com seus fornecedores e projetos de backup e armazenamento e peça que adotem o CSI CBT para melhorar sua proteção de dados. Ajude o CSI CBT a ser um sucesso. Participe da reunião quinzenal do DPWG ou entre em contato pelo canal do Slack e pela lista de e-mails ; estamos disponíveis para responder perguntas.
Além disso, registre-se para participar da palestra Kubernetes Data Protection Working Group Deep Dive na quarta-feira, 13 de novembro, na KubeCon + CloudNativeCon North America.
A cada dia, mais pessoas perguntam: "Agora é a hora de migrar para o Kubernetes?" Levar o CSI CBT para o armazenamento nativo da nuvem remove RPOs mais longos, uma desvantagem crítica quando comparado à infraestrutura tradicional. Estamos ansiosos para colaborar com o ecossistema e a comunidade nativos da nuvem para implementar o CSI CBT e impulsionar a proteção de dados nativa da nuvem de classe mundial.
