As 9 melhores soluções de backup e restauração do OpenShift ETCD

O RedHat OpenShift permite que os usuários provisionem, instanciem, executem e gerenciem um pacote modular que inclui uma plataforma de computação e vários aplicativos, reduzindo significativamente a complexidade da criação e manutenção da infraestrutura que provavelmente estaria associada ao desenvolvimento e ao lançamento dos aplicativos e serviços necessários.

O OpenShift representa uma abordagem específica de como as máquinas virtuais, os contêineres e os ambientes de plataforma como serviço podem trabalhar juntos; a plataforma como um todo costuma ser útil tanto para empresas quanto para indivíduos que estão em posição de explorá-la.

Como o OpenShift consiste em uma família de software, é importante mencionar seu carro-chefe: o OpenShift Container Platform.

O OpenShift Container Platform, ou OSCP, é uma plataforma de nuvem híbrida como um serviço que funciona com contêineres Linux gerenciados pelo Kubernetes. Na maioria das vezes, ela é chamada de “OpenShift”, embora existam vários outros produtos disponíveis nessa mesma família, incluindo o OpenShift Online, o OpenShift Dedicated e outros. Para fins de continuidade, vamos nos referir à plataforma de contêineres OpenShift simplesmente como “OpenShift” no restante deste artigo, porque a maioria dos serviços e soluções a seguir funciona com a OSCP.

O OpenShift foi projetado para ser modular e flexível, o que traz uma série de vantagens para várias implantações que usam o OpenShift. No entanto, essa abordagem flexível e versátil tem suas próprias ressalvas. O primeiro problema é que essa abordagem, embora possa ser muito eficaz, também pode ser propensa a erros e falhas. Assim, um bom sistema de backup é um requisito para a maioria, se não todas, as implantações do OpenShift, especialmente quando dados valiosos e persistentes estão sendo criados e/ou processados.

A necessidade de um sistema de backup cria outro problema significativo para as implantações do OpenShift – nem todas as soluções de backup são capazes de proteger adequadamente os ambientes do OpenShift – e algumas simplesmente não conseguem fazer isso.

Por isso, uma solução de backup e restauração deve ser totalmente compatível com o OpenShift em primeiro lugar. Normalmente, os recursos de backup, como automação de backup, suporte para diferentes locais e mídias de backup e recursos de migração de dados, são uma adição importante ao recurso de backup e recuperação existente do OpenShift.

Capacidades de backup integradas do OpenShift

Não há muitas soluções de backup abrangentes no mercado que também sejam capazes de executar operações de backup e restauração do OpenShift – mas, primeiro, temos que analisar o quanto a própria RedHat pode fazer. É sobre essa funcionalidade de backup integrada que vamos nos estender primeiro.

Backup e recuperação do cluster do OpenShift

Existem dois caminhos possíveis aqui: operações de backup e recuperação para clusters e essas mesmas operações para aplicativos. As operações de backup de clusters dependem totalmente dos dados do etcd, um armazenamento de valores-chave do OSCP (OpenShift Container Platform) que contém informações sobre todos os objetos de recursos em um cluster.

Um administrador de cluster pode ter que desligar ou reiniciar clusters em situações específicas, seja para fins de manutenção ou apenas para economizar recursos executando menos clusters ao mesmo tempo. O processo de desligamento de um cluster OpenShift às vezes é chamado de “graceful shutdown” e inclui o desligamento dos nós do cluster com um comando de desligamento dedicado, bem como o desligamento de todas as dependências que não são mais usadas com o desligamento do cluster.

Há também outro processo chamado “graceful restart” (reinicialização graciosa), que naturalmente é o oposto direto do desligamento gracioso, pois inicia o cluster em vez de pará-lo. Esse processo específico, no entanto, pode ser um pouco mais complicado do que seu oposto, com etapas como:

• Ativar todas as dependências do cluster desativadas anteriormente;
• Iniciar a própria máquina do cluster;
• Verificar se os nós do plano de controle estão prontos;
• Verificar se os nós de trabalho estão prontos;
• Verificar se o cluster como um todo foi iniciado corretamente ou não.

Se o cluster não iniciar corretamente, a única solução seria usar um backup do etcd para restaurar o estado anterior do cluster.

Embora seja verdade que o desligamento gracioso deva permitir que o cluster seja reiniciado com o mínimo de esforço, um backup do etcd deve ser executado antes de cada evento de desligamento do cluster. Os backups do etcd desempenham um papel importante nos cenários de recuperação de desastres e não seria possível restaurar um OSCP defeituoso sem um backup do etcd envolvido no processo.

O processo de backup do etcd em si é bastante simples e inclui três etapas principais: iniciar uma sessão de depuração, alterar o diretório raiz para /host, e iniciar um script chamado “cluster-backup.sh” e, ao mesmo tempo, inserir o local do backup.

O processo de restauração do cluster, por outro lado, é um pouco mais complicado, principalmente porque as restaurações do cluster por meio do backup do etcd são consideradas uma “opção de último recurso” que normalmente só deve ser usada quando nada mais funcionar para recuperar o estado de funcionamento do cluster. Isso envolve várias etapas, como:

• Selecionar um host do plano de controle que executará as operações de restauração;
• Configurar a conectividade SSH com todos os nós do plano de controle, incluindo aquele que será usado para recuperação;
• Copiar manualmente o backup do etcd para o host que foi escolhido como o de recuperação;
• Acessar o host em questão;
• Executar o script de restauração “cluster-restore.sh“;
• Verificar se os nós estão no estado “pronto”;
• Reiniciar o serviço kubelet para todos os hosts do plano de controle, inclusive o de recuperação;
• Aprovação de CSRs pendentes, verificando se o plano de controle de membro único está em funcionamento;
• Apagar e recriar todas as máquinas do plano de controle, com a exclusão da escolhida para fins de recuperação.

Isso nos leva à segunda parte desse longo processo – ele começa com o mesmo usuário fazendo login em uma janela de terminal separada com a função “cluster-admin“. As operações a seguir são:

• Forçar a reimplantação do etcd;
• Verificar se os nós estão atualizados;
• Forçar novas implementações no plano de controle (isso deve reinstalar a API do Kubernetes em todos os nós, pois um balanceador de carga interno é usado para conectar o kubelet ao servidor da API);
• E por último, mas não menos importante, é verificar se todos os hosts do plano de controle recém-instalados estão funcionando e se juntaram ao cluster.

É fácil ver como o processo de restauração do backup do etcd é bastante longo e difícil, o que é um dos motivos pelos quais ele é tratado como uma opção de último recurso.

Agora que já abordamos o funcionamento do backup e da recuperação de contêineres, vamos examinar o processo de backup e recuperação de aplicativos.

Backup e recuperação de aplicativos do OpenShift

O processo de criação de backups de aplicativos no OpenShift também pode ser bastante complicado, mas não vamos nos aprofundar muito nisso, pois os principais pontos de foco deste artigo são o etcd e os clusters. No entanto, ainda vamos examinar a lógica disso.

As operações de backup e restauração de aplicativos no OpenShift podem ser feitas com a ajuda do OADP, ou OpenShift API for Data Protection. Ele usa o Velero para executar tarefas de backup e restauração para recursos e/ou imagens internas, além de poder trabalhar com volumes persistentes via Restic ou com snapshots.

Há uma lista muito específica de variações de armazenamento que podem ser copiadas com o OADP – essa lista inclui MS Azure, AWS, GCP, Multicloud Object Gateway, bem como diversas variações de armazenamento de objetos compatíveis com S3 (Minio, Noobaa etc.). Ao mesmo tempo, os backups de instantâneos também só podem ser realizados para o armazenamento em nuvem habilitado para instantâneos do AWS, Azure, GCP e CSI (Ceph FS, Ceph RBD etc.), pois somente esses suportam a API de instantâneos de nível nativo necessária.

O processo de backup em si envolve a criação de um CR, ou recurso personalizado, para fins de backup ou restauração. Essa opção pode ser usada para executar backups restritos, backups programados e para configurar ganchos de backup/restauração a serem executados antes ou depois da conclusão do processo de backup/restauração.

Opções de backup do OpenShift de terceiros

Embora o método de backup/recuperação mencionado anteriormente seja realmente possível, ele tem problemas potenciais associados, principalmente porque não tem recursos adicionais e pode ser um pouco complicado para muitos usuários. É por isso que vamos analisar também as soluções de backup do OpenShift ETCD de terceiros, começando pelo IBM Spectrum.

IBM Spectrum Protect Plus

O IBM Spectrum Protect Plus é uma solução abrangente de proteção de dados que oferece uma variedade de recursos no campo da segurança de dados, incluindo backup, recuperação, retenção e replicação para todos os tipos de locais de destino, sejam eles bancos de dados, aplicativos, máquinas virtuais, cargas de trabalho de SaaS ou até mesmo contêineres.

O IBM Spectrum Protect é uma solução bastante versátil, e é por isso que ele também pode funcionar com sistemas OpenShift. A solução da IBM é capaz de proteger não apenas volumes persistentes, mas também outros recursos dependentes de clusters do OpenShift. Embora tenha um conjunto de requisitos para que os backups do OpenShift funcionem em primeiro lugar, os requisitos em si não são particularmente rigorosos e incluem principalmente um único requisito para que as diferentes partes do sistema de virtualização estejam atualizadas em um grau específico.

O IBM Spectrum Protect permite que seus usuários registrem clusters do OpenShift manualmente, criem backups de dados de contêineres do OpenShift e os restaurem a partir de um instantâneo ou de uma cópia de backup regular, e também pode restaurar recursos específicos com escopo de namespace e de cluster ou até mesmo substituir as configurações de retenção para backups ou instantâneos específicos, expirando as sessões de trabalho de backup do OpenShift.

CronJob

Diferentemente do restante desta lista, o CronJob não é exatamente uma solução de backup por si só. Um CronJob é uma tarefa que pode executar ações específicas seguindo um cronograma específico em sistemas baseados em Unix. Nesse contexto específico, um usuário no GitHub usa o CronJob para executar uma série de operações que resultam na criação de um backup do OpenShift com o mesmo método que mencionamos anteriormente (executando cluster-backup.sh).

Esse CronJob específico cria um pod que executa o script mencionado acima para criar o próprio backup. Ele também copia todo o backup para um PV pré-configurado e, em seguida, expira o próprio trabalho de backup para evitar conflitos futuros. Ele cria dois arquivos separados: um é a coleção dos pods estáticos como um todo, com suas chaves privadas e certificados, e o outro é o snapshot do etcd. Dessa forma, esse “método” específico pode ser chamado de solução de backup ETCD do OpenShift.

Kasten K10

O Kasten K10 é uma plataforma de gerenciamento de dados que é nativa da nuvem como um tipo de armazenamento, oferecendo uma variedade de opções diferentes, como backup, recuperação, mobilidade de aplicativos e recuperação de desastres para aplicativos Kubernetes, além de ser capaz de se integrar a uma variedade de tipos de bancos de dados diferentes, oferecer suporte a vários provedores de armazenamento em nuvem e funcionar com a maioria das distribuições do Kubernetes.

O K10 também pode realizar operações de backup e recuperação do OpenShift com relativa simplicidade. A maior diferença aqui seria a criação de um Secret – a própria versão da Kasten de uma lista de backup que inclui informações sobre rótulos de pods etcd, endpoint de cluster etcd e tudo o mais que precisa de backup. Fora isso, o processo é um pouco semelhante ao modo como o K10 normalmente realiza backups – criando um Blueprint e usando um Secret com um Blueprint para executar a tarefa de backup. O processo de restauração, por outro lado, é semelhante ao que discutimos na seção “métodos incorporados” deste artigo.

Storware Backup and Recovery

O Storware Backup and Recovery é um software de proteção de dados nativo da nuvem que funciona muito bem quando se trata de criar backups de volumes persistentes ou metadados anexados aos pods do OpenShift. Ele tem o status de um Red Hat OpenShift Operator certificado, proporcionando consistência em seus esforços de proteção de dados, combinados com recursos como agendamento, modificação da política de backup, automação de backup e assim por diante. É uma excelente solução de backup e restauração do OpenShift ETCD que abrange vários planos diferentes de dados do OpenShift – o etcd mencionado anteriormente, metadados, volumes persistentes e muito mais.

Portworx Backup

A Portworx é uma plataforma de serviços de dados que se concentra no desenvolvimento de soluções para usuários do Kubernetes para ajudar a executar aplicativos em contêineres sem interrupções e eventos de perda de dados. Ela oferece acesso mais fácil a backups de aplicativos com consistência e vários recursos, como agendamento de backup, RBAC, gerenciamento de usuários e muito mais. A Portworx também pode oferecer recursos de recuperação de desastres, implementação de CSI, criptografia em todo o cluster, snapshots, bem como muitos outros recursos para clusters e aplicativos OpenShift.

Cloudcasa

O Cloudcasa é um serviço de backup resiliente e poderoso, com grande escalabilidade e uma interface amigável. Ele pode oferecer proteção de dados em várias nuvens, várias opções de resiliência cibernética e vários tipos diferentes de backup em seus ambientes OpenShift (recursos Kubernetes, backups etcd e instantâneos CSI). O Cloudcasa também pode executar vários níveis diferentes de operações de recuperação, seja em nível granular ou de cluster, o que o torna uma solução de backup e restauração do OpenShift ETCD bastante conveniente e útil.

Dell EMC PowerProtect Data Manager

A Dell EMC é uma potência tecnológica que oferece uma variedade de produtos e serviços para vários mercados diferentes. O PowerProtect Data Manager da Dell EMC é uma solução versátil de proteção de dados que oferece suporte a vários tipos de ambiente e pode funcionar com uma infinidade de locais de armazenamento diferentes. Ele também é compatível com ambientes OpenShift, oferecendo proteção para suas cargas de trabalho, além de ser uma solução de backup e restauração confiável e útil. Ele integra os ambientes do OpenShift em sua própria interface centralizada, fornecendo a capacidade de atribuir políticas de proteção a namespaces, clusters e tudo o mais que o OpenShift possui.

Bacula Enterprise

O Bacula Enterprise é uma solução de backup corporativo exclusiva e altamente segura que suporta uma gama especialmente ampla de ambientes e recursos por meio de seu sistema de “módulos”. Um desses módulos foi criado especificamente para operações abrangentes de backup e restauração do OpenShift, fornecendo uma variedade de recursos de proteção de dados para ambientes OpenShift. Esse módulo específico oferece recursos como proteção do estado do cluster, reimplantação eficaz de recursos do cluster, recursos de recuperação de aplicativos, restauração de dados PV direcionada, transferência de configuração para outras operações e assim por diante. O Bacula Enterprise não só pode ser útil para proteger seus dados do OpenShift como um todo, mas também pode facilitar os planos de recuperação de desastres, oferecer segurança adicional aos seus dados, ajudar nas tarefas de migração de cluster, oferecer recursos de replicação de ambiente e muito mais. É importante observar que seu modelo de licenciamento baseado em assinatura e sua alta escalabilidade o tornam vantajoso para implantações de médio e grande porte.

Conclusão

Os ambientes OpenShift são extremamente úteis em áreas específicas e áreas de aplicativos, mas também são relativamente novos, o que significa que a proteção de dados neles pode ser um pouco problemática. Como os ambientes Kubernetes de qualquer tipo estão sendo cada vez mais implantados, o backup dos dados, especialmente dos dados persistentes, é cada vez mais importante. Este artigo discute diferentes soluções de backup do OpenShift, incluindo opções integradas e de terceiros que estão disponíveis, e pode ser útil para encontrar uma solução para um caso de uso específico do usuário.