Introdução
Muitas empresas confiam na AWS para hospedar toda a sua infraestrutura devido às vantagens inerentes da computação em nuvem . No entanto, algumas empresas operam cargas de trabalho de missão crítica em áreas remotas, correndo um risco maior de perder conectividade de rede externa. Por exemplo, uma instalação de investigação localizada num deserto remoto, uma plataforma petrolífera em águas internacionais ou uma base militar no remoto Pacífico. Nesta postagem do blog, exploraremos seis práticas recomendadas ao projetar recuperação de desastres para esses locais remotos com conectividade externa limitada usando serviços da AWS.
Essas empresas exigem uma estratégia de continuidade de operações que utilize recursos locais para mitigar o risco de conectividade. O Departamento de Defesa define isso como comunicações negadas, interrompidas, intermitentes e/ou limitadas (DDIL). A AWS oferece uma opção de computação de borda desconectada com o AWS Snowball Edge que executa um subconjunto de serviços da AWS, como Amazon Elastic Compute Cloud (Amazon EC2), Amazon Simple Storage Service (Amazon S3) e AWS Systems Manager.
Os dispositivos Snowball Edge podem constituir um site local de recuperação de desastres (DR) quando emparelhados com outros serviços da AWS para o site principal em execução na nuvem. Combinar o poder da nuvem com um recurso de DR local permite que as empresas aproveitem as vantagens da nuvem enquanto gerenciam os riscos de conectividade. Com isso em mente, vamos nos aprofundar no planejamento da recuperação de desastres entre um site ativo em execução na nuvem e um site contingente em execução localmente em dispositivos Snowball Edge.
1. Identifique os requisitos
Tal como acontece com qualquer Plano de Recuperação de Desastres, compreender os requisitos do negócio é essencial. Primeiro, considere a criticidade da carga de trabalho – qual a sua importância para o negócio? Para a missão? Qual seria o impacto se essa carga de trabalho diminuísse? Identificar essas respostas e agrupar as cargas de trabalho por nível de criticidade é uma forma eficaz de documentar e gerenciar requisitos. Subestimar a criticidade pode resultar em impacto nos negócios durante um evento, enquanto superestimar a criticidade da carga de trabalho gerará custos e complexidade desnecessários. Trabalhar retroativamente a partir dos requisitos do negócio e da missão é fundamental para atingir o equilíbrio apropriado.
Ao documentar a criticidade da carga de trabalho, é importante definir o escopo da carga de trabalho para garantir que todos os componentes necessários estejam disponíveis em caso de failover. O escopo da carga de trabalho deve levar em conta as árvores de dependência. Por exemplo, se o Aplicativo A for crítico e depender do Aplicativo B, do Banco de Dados C e do Message Broker D, essas dependências também serão críticas.
Ao determinar o nível de criticidade, considere o Objetivo do Ponto de Recuperação (RPO) e o Objetivo do Tempo de Recuperação (RTO). RPO é a quantidade de perda de dados tolerável para um evento de failover e RTO é a duração máxima em que o sistema pode ficar indisponível. Esses requisitos impulsionarão as frequências de replicação e os processos de failover – quatro estratégias comuns de recuperação de desastres para conseguir isso são descritas na Figura 1 abaixo. Consulte Opções de recuperação de desastres na nuvem para obter mais informações sobre essas estratégias.
Figura 1 – Estratégias de recuperação de desastres
Todos os elementos acima se tornam ainda mais importantes em um cenário desconectado, onde você falha do site primário na nuvem para um site de failover local com recursos limitados. Quais cargas de trabalho são essenciais para o failover? O que deve ser priorizado em caso de insuficiência de recursos? Todas essas considerações devem ser analisadas ao planejar sua arquitetura de failover.
2. Arquitetar cargas de trabalho críticas para paridade
Uma vez determinada a criticidade, as cargas de trabalho altamente críticas devem ser arquitetadas para serem executadas na nuvem e localmente, utilizando os recursos disponíveis em ambos os locais. Por exemplo, você pode optar por executar contêineres no Amazon Elastic Kubernetes Service (EKS) em vez do Amazon Elastic Container Service (ECS), porque o EKS pode ser executado no Snowball Edge com o EKS Anywhere.
Aproveitar os serviços da AWS baseados em software de código aberto (OSS) ou software comercial pronto para uso (COTS) que pode ser executado localmente em instâncias EC2 pode mitigar essa diferença. Isso permite que os clientes obtenham os benefícios dos serviços gerenciados na nuvem, mantendo a paridade de recursos do Snowball Edge com sobrecarga limitada. Por exemplo, usar o Amazon Relational Database Service (RDS) na nuvem proporcionará segurança, confiabilidade e benefícios operacionais aos quais os clientes estão acostumados com os serviços gerenciados da AWS, ao mesmo tempo que permitirá o failover para o Snowball Edge. Você pode fazer isso instalando e operando o mesmo mecanismo de banco de dados localmente em instâncias do EC2 para dar suporte à sua carga de trabalho crítica. Por exemplo, o RDS pode executar o PostgreSQL 15.3 na nuvem e você pode executar a mesma versão localmente. Gerenciar dependências de carga de trabalho em ambos os sites é fundamental para um recurso de failover eficaz.
3. Considere as diferenças fundamentais de capacidade entre a nuvem e o site local
A nuvem e os sites locais executam cargas de trabalho com diferentes serviços de suporte básicos. Esses serviços de suporte incluem recursos de rede, recursos de computação e recursos de monitoramento. Felizmente, o planejamento adequado como parte de uma estratégia empresarial DDIL DR/COOP pode facilmente superar essas diferenças:
- Roteamento – Muitos clientes usam Amazon Virtual Private Cloud (Amazon VPC) na nuvem para recursos como sub-redes de rede, roteamento, Dynamic Host Configuration Protocol (DHCP) e Network Time Protocol (NTP). O Amazon VPC não está disponível no Snowball Edge, mas você pode replicar esses recursos; por exemplo:
- O switch e/ou roteador local usado para conectar os dispositivos Snowball Edge e outros equipamentos locais provavelmente pode criar sub-redes e aplicar lógica de roteamento de tráfego.
- Você pode instalar o pacote dhcp ou pen source em um Snowball Edge . Ele contém o servidor DHCP do Internet Systems Consortium (ISC).
- Você pode instalar o pacote chrony em um Snowball Edge para usar sua implementação de NTP em seu site local.
- DNS – o Amazon Route 53 fornece DNS na nuvem, mas não está disponível no Snowball Edge. Você pode instalar e executar o Berkely Internet Name Domain (BIND) localmente no Snowball Edge para fornecer funcionalidade DNS para o site local.
- Balanceamento de carga – Amazon Elastic Load Balancer (Amazon ELB) fornece serviços de balanceamento de carga na nuvem. Embora o ELB não esteja disponível no Snowball Edge, você pode instalar balanceadores de carga de código aberto como HAProxy ou NGINX localmente. Você também pode considerar alternativas COTS como F5 Big IP.
- Computação – o Amazon EC2 está disponível na nuvem e no Snowball Edge, mas oferece diferentes recursos de hardware. Revise as dependências de hardware em relação ao EC2 em ambos os sites para garantir a compatibilidade, especialmente no que diz respeito à arquitetura do processador e às GPUs.
- Monitoramento – Amazon CloudWatch é o principal serviço para monitoramento de aplicativos e infraestrutura na nuvem. O Amazon CloudWatch não está disponível no Snowball Edge, mas você pode usar OSS como OpenSearch, Prometheus, Grafana, Fluent Bit e OpenTelemetry para coletar, processar e visualizar o estado operacional.
Veja o gráfico abaixo para uma visualização de como tudo isso acontece.
Figura 2 – Serviços disponíveis em nuvem e em sites locais com considerações de design
4. Defina sua estratégia de replicação de dados
Os dados devem ser replicados periodicamente da nuvem para o site local, para que o site local passivo possa ser ativado quando necessário. Dados referem-se a ativos que o aplicativo testado precisará para satisfazer o requisito de RPO e podem incluir arquivos de configuração, arquivos de dados e/ou instantâneos de banco de dados. A frequência de replicação de dados também depende do RPO; quanto menor o RPO, mais frequentemente os dados deverão ser atualizados.
Ao replicar dados em escala para um portfólio de cargas de trabalho, é útil preparar os dados em uma única fonte de verdade com taxonomia clara, definida como parte do design DR/COOP. A estrutura deve ser padronizada e espelhar a sua organização para que seja intuitiva a navegação. Uma estrutura simples de bucket seria portfólio, carga de trabalho e componente (ou seja, EnterpriseSecurity/LoginService/FrontEnd). Processos e guarda-corpos também devem manter a estrutura para manter a integridade. Por exemplo, você pode criar políticas IAM limitando quais prefixos várias funções ou usuários podem acessar, evitando que os administradores repliquem dados para os locais errados. Consulte a documentação do Amazon S3 para obter um exemplo de como aplicar permissões a prefixos.
O Amazon S3 é um lugar lógico para servir como fonte de verdade porque é altamente disponível, durável, seguro, econômico e está disponível no Snowball Edges, simplificando o processo de replicação. Na verdade, os dispositivos Snowball Edge locais podem ser agrupados para dimensionar o armazenamento S3 local .
Os dados podem ser copiados para a zona de preparação do S3 usando vários métodos, dependendo do local de origem. Por exemplo:
- O Amazon RDS PostgreSQL pode copiar nativamente snapshots de banco de dados para o S3.
- O AWS DataSync pode copiar dados de vários sistemas de arquivos compartilhados para o S3.
- AWS CLI pode copiar arquivos locais para S3.
O Snowball Edge vem com o AWS Systems Manager – uma solução de gerenciamento segura de ponta a ponta para recursos na AWS e em ambientes híbridos. Ele pode executar tarefas continuamente em um Snowball Edge local para sincronizar o bucket de teste S3 na nuvem com o bucket S3 local correspondente usando uma ferramenta como S5cmd ou AWS CLI. Depois de replicadas, as tarefas do Systems Manager podem aplicar esses artefatos ao ambiente local passivo para que ele esteja pronto quando necessário.
Figura 3 – Exemplo de projeto de replicação de dados primários para sites locais
5. Projete para alta disponibilidade no site local
Assim como você replicaria aplicativos e dados em várias zonas de disponibilidade na nuvem para se proteger contra falhas de AZ, considere replicar esses ativos em vários dispositivos Snowball Edge para mitigar o risco de falha do dispositivo Snowball Edge. Implante aplicativos em vários dispositivos Snowball Edge em uma configuração ativa/passiva ou ativa/ativa usando um balanceador de carga ou verificações de integridade de DNS para failovers. Para garantir que dados críticos não sejam armazenados em um único dispositivo Snowball Edge, você pode usar diversas ferramentas para gerenciar aplicativos e dados em dispositivos Snowball Edge:
- O Systems Manager pode acionar, gerenciar e gerar relatórios sobre tarefas de replicação.
- Um balanceador de carga pode distribuir o tráfego de rede entre dispositivos com verificações de integridade.
- RSYNC pode replicar arquivos de aplicativos.
- Cluster de bancos de dados em vários dispositivos Snowball Edge.
- Os clusters de armazenamento compatíveis com S3 podem gerenciar a disponibilidade em dispositivos Snowball Edge.
Considere o exemplo a seguir, que emprega um subconjunto dessas ferramentas para fornecer redundância:
- Os servidores de aplicativos e de banco de dados são replicados em dois dispositivos Snowball Edge em uma configuração ativa/passiva. A instância passiva está em execução e acessível ao usuário final, portanto, está pronta para ser ativada conforme necessário. Um serviço DNS com verificações de integridade poderia ser usado para acionar um failover.
- Os servidores de banco de dados são agrupados em cluster nos dispositivos Snowball Edge. Cada transação é replicada em dispositivos Snowball Edge para evitar perda de dados em caso de falha de hardware.
- O aplicativo aproveita um cluster Snowball Edge (vários dispositivos Snowball Edge) executando o S3. Esses clusters replicam dados em vários dispositivos para que os dados não sejam perdidos quando um dispositivo falhar. Consulte a documentação Visão geral do cluster para obter mais informações.
Figura 4 – Exemplo de design de redundância de site local com dispositivos Snowball Edge
Por último, planeje também falhas de hardware fora dos dispositivos Snowball Edge. Por exemplo, se você estiver usando um switch local para conectar o Snowball Edge e estações de trabalho locais, considere o que acontecerá quando esse switch falhar e como sua organização se recuperará. O planejamento para falhas de dispositivos no local renderá dividendos quando ativado durante um desastre.
6. Plano de Operações e Manutenção
Manter um site passivo em ambientes heterogêneos requer consideração consistente. As configurações aplicadas ao site da nuvem e não traduzidas com êxito para o site local provavelmente causarão problemas durante o failover. No entanto, este risco pode ser mitigado através da aplicação das seguintes práticas operacionais:
- Considere explicitamente ambos os ambientes durante o processo de controle de mudanças; como essa mudança impactará o ambiente secundário e também o ambiente primário e qual é o plano de teste para cada ambiente? As mudanças ambientais deveriam ser tratadas como operações atômicas; aplicado a ambos os ambientes ou não.
- Mantenha linhas de base de configuração separadas, mas faça referência cruzada para manter a rastreabilidade.
- Aproveite as ferramentas de infraestrutura como código (IaC), como o Ansible, para aplicar alterações de forma consistente em ambos os sites.
- Garanta que o treinamento baseado em função considere os recursos da região da AWS, os recursos do Snowball Edge e os principais procedimentos operacionais padrão (SOPs), como o failover.
- Revise periodicamente as funções de missão crítica em relação à categorização da carga de trabalho e execute exercícios de failover para testar o procedimento de failover, bem como os recursos do ambiente secundário em relação à funcionalidade de missão crítica.
Além disso, oferecemos o AWS OpsHub para gerenciar centralmente dispositivos Snowball Edge existentes localmente em um ambiente. Isso fornece uma interface gráfica do usuário para todas as operações da API Snowball e uma visão unificada de todos os serviços da AWS em execução no Snowball Edges local. Além disso, este serviço funciona com o AWS Systems Manager para automatizar tarefas operacionais no Snowball Edges, conforme discutido anteriormente.
Conclusão
A implementação de uma estratégia de DR/COOP com o Snowball Edge como site local permite que as organizações aproveitem os benefícios da nuvem e, ao mesmo tempo, reduzam o risco de conectividade. Para ter sucesso nesta empreitada, as empresas devem compreender quais cargas de trabalho e recursos são de missão crítica, a árvore de dependências para cada carga de trabalho de missão crítica e como essa carga de trabalho funcionaria em ambos os locais. As empresas também devem levar em conta as diferenças entre cada ambiente nos seus processos operacionais contínuos para garantir que o site local esteja pronto para o failover. Quando implementados com sucesso, os COOPs com site Snowball Edge local permitem que as empresas aproveitem o poder da nuvem, mesmo para cargas de trabalho de missão crítica em locais remotos com conectividade limitada ou intermitente.
Se sua organização estiver interessada em adotar a AWS, mas não puder devido à conectividade limitada, considere esta estratégia COOP local como mitigação. Se sua organização já opera na nuvem, mas está preocupada com a conectividade intermitente, considere criar um site local no Snowball Edge.
Artigo originalmente publicado em Blog AWS
