Recuperação de desastres em múltiplas regiões com o Amazon EKS e o Amazon EFS para cargas de trabalho com estado

Por Dumlu Timuralp e Eric Heinrichs

Introdução

O Amazon Elastic File System (EFS) é um serviço de armazenamento gerenciado que pode ser usado para fornecer acesso compartilhado aos dados para os Pods do Kubernetes, executados em nós computacionais em diferentes zonas de disponibilidade (AZ), gerenciadas pelo Amazon Elastic Kubernetes Service (EKS). O Amazon EFS oferece suporte a replicação nativa de dados entre regiões da AWS. Esse recurso ajuda a projetar uma solução de recuperação de desastres (DR) multirregional para cargas de trabalho de missão crítica em seus clusters EKS.

O Container Storage Interface (CSI) é um padrão que permite expor vários sistemas de armazenamento aos seus Pods. Isso permite que você execute cargas de trabalho com estado em seus clusters Kubernetes. O CSI realiza essa tarefa montando volumes persistentes (PV) nos Pods e mantendo o ciclo de vida dos Pods completamente independente do ciclo de vida dos PVs. O driver CSI do Amazon EFS é uma solução que configura os PVs do Kubernetes na forma de pontos de acesso no sistema de arquivos EFS. Os desenvolvedores usam Persistent Volume Claims (PVC) para montar os volumes persistentes nos Pods.

Neste post, discutimos como alcançar a continuidade dos negócios na AWS usando o Amazon EFS e o Amazon EKS entre as regiões da AWS. A solução que está sendo proposta, corresponde às estratégias Pilot light e Warm standby definidas no whitepaper Recuperação de desastres de workloads na AWS.

Desafios

O Amazon EFS implementa um ponto de acesso exclusivo para cada PV em um cluster Kubernetes. Um ID do File System Access Point (FSAP) deve ser especificado para cada volume.

O FSAP pode ser definido manualmente para cada PV usando o provisionamento estático. No entanto, isso pode ser demorado para os desenvolvedores ou administradores de armazenamento, pois cada ponto de acesso deve ser criado no Amazon EFS antes da criação de um PVC no Kubernetes.
O provisionamento dinâmico permite que os desenvolvedores criem PVCs sem a necessidade de ter um ponto de acesso provisionado previamente, pois cria pontos de acesso sob demanda usando o ID do sistema de arquivos do EFS.

Embora o provisionamento dinâmico torne a experiência do desenvolvedor muito melhor, há um desafio ao usar a replicação do Amazon EFS. A replicação do Amazon EFS replica todos os dados no sistema de arquivos, mas não os FSAPs. Portanto, isso limita para o uso do provisionamento estático em cada cluster EKS. Isso resulta em manuais de execução de DR complexos. Porque sempre que quiser fazer o failback para a região primária, você precisa reconfigurar manualmente os IDs exclusivos do FSAP nos PVs dessa região. Isso é muito difícil de manter e propenso a erros. Portanto, precisamos de uma solução que seja abstraída da camada Kubernetes, mas que ainda possa garantir o acesso compartilhado ao mesmo conjunto de dados de qualquer cluster EKS.

Visão geral da solução

A solução usa duas regiões da AWS, cada uma com um cluster EKS e um sistema de arquivos EFS. Usamos o driver CSI do EFS em cada cluster EKS. Para simplificar, mantivemos o Amazon Route 53 e suas políticas de roteamento para rotear solicitações de clientes nessa arquitetura multirregional, fora do escopo desta postagem.

Figura 1: Visão geral da solução

Conforme mostrado na figura anterior, usamos duas AZs por região da AWS, fornecendo mais resiliência na arquitetura. Usamos a replicação do Amazon EFS para replicar dados nativamente da Região 1, como origem, para a Região 2, como destino. Quando a replicação inicial é concluída, os dados no sistema de arquivos de destino ficam somente para leitura. Cada nó de trabalho do EKS acessa o sistema de arquivos do EFS (dentro da mesma região) por meio do ponto de montagem específico do Amazon EFS para cada AZ.

Conseguimos a abstração entre as camadas do Amazon EKS e do Amazon EFS configurando um objeto Kubernetes StorageClass em cada cluster EKS. Você deve especificar o ID do sistema de arquivos EFS da respectiva região no objeto StorageClass.

Você já deve estar pensando: “Então, o que há de novo? É assim que você integra o Amazon EFS e o Amazon EKS usando o driver CSI do EFS ?” Ao usar o StorageClass com a replicação do Amazon EFS, há um novo parâmetro chamado subpathPattern, que é introduzido na versão 1.7.0 do driver CSI do EFS. Ele permite que você forneça acesso compartilhado ao mesmo conjunto de dados em dois sistemas de arquivos EFS diferentes, mesmo que cada sistema de arquivos tenha um ID FSAP distinto para esse conjunto de dados. Vamos ver como isso funciona.

No manifesto do objeto StorageClass, você configura o subPathPattern, conforme mostrado a seguir, com o nome do PVC e a variável de namespace do PVC. O padrão pode ser composto por sequências fixas e variáveis limitadas. O padrão a seguir, permite que você comece a usar exatamente os mesmos manifestos de implantação, Pod e PVC do Kubernetes para ambas as regiões, primária e de DR. Você não precisa incorporar parâmetros de configuração específicos da região da AWS como o ID do sistema de arquivos EFS e/ou o ID do FSAP em seus manifestos de carga de trabalho. Tudo isso é abstraído pelo driver CSI do EFS, o que é muito legal!


kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: efs-sc
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap
  fileSystemId: fs-92107410
  directoryPerms: "700"
  gidRangeStart: "1000" # optional
  gidRangeEnd: "2000" # optional
  basePath: "/dynamic_provisioning" # optional
  subPathPattern: "${.PVC.namespace}/${.PVC.name}" # optional
  ensureUniqueDirectory: "false" # optional
  reuseAccessPoint: "false" # optional

Há mais um parâmetro que você precisa definir em conjunto com o

subPathPattern, é o parâmetro ensureUniqueDirectory

Ao definir esse parâmetro como false, garantimos que o driver do Amazon EFS aponte o PV em cada região da AWS para o mesmo diretório no sistema de arquivos do EFS.

Em seguida, implantamos nossas cargas de trabalho (essencialmente Pods) e usamos solicitações de PVC.

Vale ressaltar que o uso do GitOps para esse tipo de arquitetura, oferece a capacidade de gerenciar o estado de vários clusters Kubernetes e sistemas de arquivos EFS usando as melhores práticas de DevOps, como controle de versão, artefatos imutáveis e automação.

Failover e failback

No caso de uma falha na região primária da AWS, você deve primeiro converter o sistema de arquivos EFS na região DR (destino) de somente leitura para gravação. Você consegue isso simplesmente excluindo a configuração de replicação do sistema de arquivos EFS.

Recentemente, introduzimos o recurso de failback para a replicação do Amazon EFS. Quando você decide fazer o failback para a região primária, primeiro você replica os dados recentes na região de DR de volta para o sistema de arquivos EFS da região primária. Depois que a replicação for concluída, você poderá excluir a configuração de replicação no sistema de arquivos EFS na região primária, basicamente convertendo-a de somente leitura para gravação. Finalmente, você configura a replicação novamente para tornar a região primária como o novo sistema de arquivos de origem da replicação do Amazon EFS.

Consulte a seção failover e failback do sistema de arquivos no guia do usuário do Amazon EFS para obter mais informações.

Exemplo de código

Criamos um repositório no GitHub onde você pode implantar a solução nesta publicação. Orientamos você nas etapas de implementação e guiamos você sobre como realizar as operações de failover e failback. A amostra de código é apenas para fins de demonstração. Não deve ser usada em ambientes de produção. Consulte os guias de melhores práticas do Amazon EKS e as melhores práticas de criptografia do Amazon EFS para saber como executar cargas de trabalho de produção usando o Amazon EKS e o Amazon EFS.

Considerações

A replicação do Amazon EFS mantém um RPO de 15 minutos para a maioria dos sistemas de arquivos. Você precisa levar isso em consideração ao projetar seu aplicativo em relação a qualquer tipo de transação ou recuperação de estado. Para obter mais informações sobre RTO e RPO, leia esta publicação sobre armazenamento da AWS e a seção Replicação de sistemas de arquivos no guia do usuário do Amazon EFS.
Ao implantar uma carga de trabalho, que usa um novo PVC na região primária, você precisa esperar que a sincronização inicial do Amazon EFS seja concluída para esse conjunto de dados, antes de implantar a mesma carga de trabalho na região secundária.
A exclusão da configuração de replicação leva vários minutos, lembre-se disso ao planejar suas operações e o RTO de destino.
Cada PVC consome um ponto de acesso do Amazon EFS. Verifique as cotas e limites atuais do Amazon EFS antes de tomar decisões de design.

Conclusão

Neste blog, mostramos como usar a replicação do Amazon EFS entre as regiões da AWS para suas cargas de trabalho com estado em execução em clusters EKS e também como obter recuperação de desastres nesse tipo de arquitetura. O driver CSI do Amazon EFS fornece uma solução simples para replicar volumes persistentes para Kubernetes em regiões da AWS, permitindo cargas de trabalho com estado tanto para failover quanto para failback.

Este blog é uma tradução do blog original em inglês (link aqui).

Autores

Dumlu Timuralp é arquiteto sênior de soluções da Amazon Web Services (AWS) com sede no Reino Unido. Nessa função, ele fornece orientação de arquitetura sobre migração para a nuvem, modernização de aplicativos e padrões nativos da nuvem. Ele adora trabalhar com clientes e atender às necessidades de seus negócios com tecnologia.

Eric Heinrichs é arquiteto de soluções na AWS especializado em soluções de armazenamento executadas na nuvem. Eric está empenhado em ajudar os clientes a encontrar novas maneiras de aproveitar as soluções em nuvem para obter um novo valor para seus clientes e em seus negócios. Ele passou quase duas décadas ajudando os clientes a construir suas infraestruturas usando soluções de armazenamento corporativo e agora está apaixonado por ajudá-los a adaptar e modernizar essas infraestruturas, aproveitando o poder da nuvem.

Tradutores

Marcelo Moras é Arquiteto de Soluções na AWS atendendo clientes Enterprise com foco em mercado financeiro. Com mais de 15 anos de experiência atuando com infraestrutura, administração de sistemas, redes, containers e segurança.

Daniel Abib é Senior Solution Architect na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e segurança. Ele trabalha apoiando clientes corporativos, ajudando-os em sua jornada para a nuvem.

https://www.linkedin.com/in/danielabib/

O blog da AWS