As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Resiliência na borda

O pilar de confiabilidade engloba a capacidade de uma carga de trabalho realizar a função pretendida de forma correta e consistente quando se espera que isso aconteça. Isso inclui a capacidade de operar e testar a carga de trabalho durante seu ciclo de vida. Nesse sentido, ao projetar uma arquitetura resiliente na borda, você deve primeiro considerar quais infraestruturas você usará para implantar essa arquitetura. Há três combinações possíveis de implementar usando Zonas locais da AWS e AWS Outposts: posto avançado para posto avançado, posto avançado para zona local e zona local para zona local, conforme ilustrado no diagrama a seguir. Embora existam outras possibilidades para arquiteturas resilientes, como combinar serviços de AWS ponta com a infraestrutura local tradicional Regiões da AWS, ou, este guia se concentra nessas três combinações que se aplicam ao design de serviços de nuvem híbrida

Considerações sobre infraestrutura

Em AWS, um dos princípios fundamentais do design de serviços é evitar pontos únicos de falha na infraestrutura física subjacente. Por causa desse princípio, o AWS software e os sistemas usam várias zonas de disponibilidade e são resilientes às falhas de uma única zona. Na borda, AWS oferece infraestruturas baseadas em Locais Zones e Outposts. Portanto, um fator crítico para garantir a resiliência no design da infraestrutura é definir onde os recursos de um aplicativo são implantados.

Zonas Locais

As Zonas Locais agem de forma semelhante às Zonas de Disponibilidade dentro delas Região da AWS, pois podem ser selecionadas como um local de posicionamento para AWS recursos zonais, como sub-redes e instâncias. EC2 No entanto, eles não estão localizados em um Região da AWS, mas perto de grandes centros populacionais, industriais e de TI onde não Região da AWS existem atualmente. Apesar disso, eles ainda mantêm conexões seguras e de alta largura de banda entre as cargas de trabalho locais na zona local e as cargas de trabalho que estão sendo executadas na. Região da AWS Portanto, você deve usar as Zonas Locais para implantar cargas de trabalho mais próximas de seus usuários para requisitos de baixa latência.

Outposts

AWS Outposts é um serviço totalmente gerenciado que estende a AWS infraestrutura Serviços da AWS, APIs, e as ferramentas para seu data center. A mesma infraestrutura de hardware usada no Nuvem AWS é instalada em seu data center. Outposts são então conectados ao mais próximo. Região da AWS Você pode usar o Outposts para suportar suas cargas de trabalho com baixa latência ou requisitos locais de processamento de dados.

Zonas de disponibilidade para pais

Cada zona local ou posto avançado tem uma região principal (também chamada de região de origem). A região principal é onde o plano de controle da infraestrutura de AWS ponta (posto avançado ou zona local) está ancorado. No caso de Zonas Locais, a Região principal é um componente arquitetônico fundamental de uma Zona Local e não pode ser modificada pelos clientes. AWS Outposts estende o Nuvem AWS para o seu ambiente local, portanto, você deve selecionar uma região e uma zona de disponibilidade específicas durante o processo de pedido. Essa seleção ancora o plano de controle da implantação do Outposts na AWS infraestrutura escolhida.

Quando você desenvolve arquiteturas de alta disponibilidade na borda, a região principal dessas infraestruturas, como Outposts ou Locais Zones, deve ser a mesma, para que uma VPC possa ser estendida entre elas. Essa VPC estendida é a base para a criação dessas arquiteturas de alta disponibilidade. Ao definir uma arquitetura altamente resiliente, é por isso que você deve validar a região principal e a zona de disponibilidade da região em que o serviço será (ou está) ancorado. Conforme ilustrado no diagrama a seguir, se você quiser implantar uma solução de alta disponibilidade entre dois Postos Avançados, deverá escolher duas Zonas de Disponibilidade diferentes para ancorar os Postos Avançados. Isso permite uma arquitetura Multi-AZ do ponto de vista do plano de controle. Se você quiser implantar uma solução altamente disponível que inclua uma ou mais Zonas Locais, você deve primeiro validar a Zona de Disponibilidade principal na qual a infraestrutura está ancorada. Para isso, use o seguinte AWS CLI comando:

aws ec2 describe-availability-zones --zone-ids use1-mia1-az1

Saída do comando anterior:

{     "AvailabilityZones": [         
          {
             "State": "available",
             "OptInStatus": "opted-in",
             "Messages": [],
             "RegionName": "us-east-1",
             "ZoneName": "us-east-1-mia-1a",
             "ZoneId": "use1-mia1-az1",
             "GroupName": "us-east-1-mia-1",
             "NetworkBorderGroup": "us-east-1-mia-1",
             "ZoneType": "local-zone",
             "ParentZoneName": "us-east-1d",
             "ParentZoneId": "use1-az2"
         }
     ]
 }

Neste exemplo, a Zona Local de Miami (us-east-1d-mia-1a1) está ancorada na Zona de us-east-1d-az2 Disponibilidade. Portanto, se você precisar criar uma arquitetura resiliente na borda, deverá garantir que a infraestrutura secundária (Outposts ou Zonas Locais) esteja ancorada em uma Zona de Disponibilidade diferente de. us-east-1d-az2 Por exemplo, us-east-1d-az1 seria válido.

O diagrama a seguir fornece exemplos de infraestruturas de ponta altamente disponíveis.

Considerações sobre redes

Esta seção discute as considerações iniciais sobre redes na borda, principalmente para conexões para acessar a infraestrutura de borda. Ele analisa arquiteturas válidas que fornecem uma rede resiliente para o link de serviço.

Rede de resiliência para Zonas Locais

As Zonas Locais são conectadas à região principal com vários links redundantes, seguros e de alta velocidade que permitem que você consuma qualquer serviço regional, como Amazon S3 e Amazon RDS, sem problemas. Você é responsável por fornecer conectividade do seu ambiente local ou dos usuários à Zona Local. Independentemente da arquitetura de conectividade escolhida (por exemplo, VPN ou AWS Direct Connect), a latência que deve ser alcançada por meio dos links de rede deve ser equivalente para evitar qualquer impacto no desempenho do aplicativo no caso de uma falha no link principal. Se você estiver usando AWS Direct Connect, as arquiteturas de resiliência aplicáveis são as mesmas para acessar um Região da AWS, conforme documentado nas recomendações de AWS Direct Connect resiliência. No entanto, existem cenários que se aplicam principalmente às Zonas Locais internacionais. No país em que a Zona Local está habilitada, ter apenas um único AWS Direct Connect PoP impossibilita a criação das arquiteturas recomendadas para AWS Direct Connect resiliência. Se você tiver acesso a apenas um único AWS Direct Connect local ou precisar de resiliência além de uma única conexão, poderá criar um dispositivo VPN na Amazon EC2 e AWS Direct Connect, conforme ilustrado e discutido na postagem do AWS blog, habilitar a conectividade altamente disponível do local para o. Zonas locais da AWS

Rede de resiliência para Outposts

Em contraste com as Zonas Locais, os Outposts têm conectividade redundante para acessar cargas de trabalho implantadas nos Outposts a partir de sua rede local. Essa redundância é obtida por meio de dois dispositivos de rede Outposts (). ONDs Cada OND requer pelo menos duas conexões de fibra de 1 Gbps, 10 Gbps, 40 Gbps ou 100 Gbps para sua rede local. Essas conexões devem ser configuradas como um grupo de agregação de links (LAG) para permitir a adição escalável de mais links.

Para obter mais informações sobre essa conectividade, consulte Conectividade de rede local para Outposts Racks na documentação. AWS Outposts

Para uma experiência e resiliência ideais, AWS recomenda que você use conectividade redundante de pelo menos 500 Mbps (1 Gbps é melhor) para a conexão do link de serviço com o. Região da AWS Você pode usar AWS Direct Connect ou uma conexão com a Internet para o link do serviço. Esse mínimo permite que você inicie EC2 instâncias, anexe volumes e acesse o EBS Serviços da AWS, como Amazon EKS, Amazon EMR e métricas. CloudWatch

O diagrama a seguir ilustra essa arquitetura para uma conexão privada altamente disponível.

O diagrama a seguir ilustra essa arquitetura para uma conexão pública altamente disponível.

Dimensionando as implantações de rack do Outposts com racks ACE

O rack Aggregation, Core, Edge (ACE) serve como um ponto de agregação crítico para implantações de AWS Outposts vários racks e é recomendado principalmente para instalações que excedam três racks ou para planejar futuras expansões. Cada rack ACE possui quatro roteadores que suportam conexões de 10 Gbps, 40 Gbps e 100 Gbps (100 Gbps é o ideal). Cada rack pode se conectar a até quatro dispositivos upstream do cliente para obter redundância máxima. Os racks ACE consomem até 10 kVA de energia e pesam até 705 libras. Os principais benefícios incluem requisitos reduzidos de rede física, menos uplinks de cabeamento de fibra e menos interfaces virtuais de VLAN. AWS monitora esses racks por meio de dados de telemetria por meio de túneis VPN e trabalha em estreita colaboração com os clientes durante a instalação para garantir a disponibilidade adequada de energia, a configuração da rede e o posicionamento ideal. A arquitetura de rack ACE fornece valor crescente à medida que as implantações se expandem e simplifica efetivamente a conectividade, ao mesmo tempo em que reduz a complexidade e os requisitos de portas físicas em instalações maiores.  Para obter mais informações, consulte a postagem do AWS blog Dimensionando implantações de AWS Outposts rack com ACE Rack.

Distribuindo instâncias em Outposts e Zonas Locais

Outposts e Locais Zones têm um número finito de servidores computacionais. Se seu aplicativo implantar várias instâncias relacionadas, essas instâncias poderão ser implantadas no mesmo servidor ou em servidores no mesmo rack, a menos que estejam configuradas de forma diferente. Além das opções padrão, você pode distribuir instâncias entre servidores para reduzir o risco de executar instâncias relacionadas na mesma infraestrutura. Você também pode distribuir instâncias em vários racks usando grupos de posicionamento de partições. Isso é chamado de modelo de distribuição de spread rack. Use a distribuição automática para distribuir instâncias entre as partições do grupo ou implante instâncias em partições de destino selecionadas. Ao implantar instâncias nas partições de destino, você pode implantar recursos selecionados no mesmo rack enquanto distribui outros recursos entre os racks. Outposts também fornece outra opção chamada spread host, que permite distribuir sua carga de trabalho no nível do host. O diagrama a seguir mostra as opções de distribuição do rack de distribuição e do host de distribuição.

Amazon RDS Multi-AZ em AWS Outposts

Quando você usa implantações de instâncias Multi-AZ em Outposts, o Amazon RDS cria duas instâncias de banco de dados em dois Outposts. Cada posto avançado funciona em sua própria infraestrutura física e se conecta a diferentes zonas de disponibilidade em uma região para obter alta disponibilidade. Quando dois Outposts são conectados por meio de uma conexão local gerenciada pelo cliente, o Amazon RDS gerencia a replicação síncrona entre as instâncias de banco de dados primária e em espera. No caso de uma falha de software ou infraestrutura, o Amazon RDS promove automaticamente a instância em espera para a função principal e atualiza o registro DNS para apontar para a nova instância primária. No caso de implantações multi-AZ, o Amazon RDS cria uma instância de banco de dados primário em um Outpost e replica de forma síncrona os dados em uma instância de banco de dados em espera em outro Outpost. As implantações Multi-AZ em Outposts operam como implantações Multi-AZ em Regiões da AWS, com as seguintes diferenças:

As implantações Multi-AZ estão disponíveis para todas as versões compatíveis do MySQL e do PostgreSQL no Amazon RDS on Outposts. Os backups locais não são compatíveis com implantações Multi-AZ.

O diagrama a seguir mostra a arquitetura do Amazon RDS nas configurações Multi-AZ do Outposts.

Mecanismos de failover

Balanceamento de carga e escalabilidade automática

O Elastic Load Balancing (ELB) distribui automaticamente o tráfego de entrada do aplicativo em todas as EC2 instâncias que você está executando. O ELB ajuda a gerenciar as solicitações recebidas roteando o tráfego de forma otimizada para que nenhuma instância fique sobrecarregada. Para usar o ELB com seu grupo Amazon EC2 Auto Scaling, conecte o balanceador de carga ao seu grupo de Auto Scaling. Isso registra o grupo com o balanceador de carga, que atua como um único ponto de contato para todo o tráfego de entrada da web em seu grupo. Ao usar o ELB com seu grupo de Auto Scaling, não é necessário registrar instâncias EC2 individuais com o balanceador de carga. As instâncias iniciadas pelo grupo do Auto Scaling serão automaticamente registradas no balanceador de carga. Da mesma forma, as instâncias que são encerradas pelo seu grupo de Auto Scaling são automaticamente canceladas do balanceador de carga. Depois de conectar um balanceador de carga ao seu grupo do Auto Scaling, você pode configurar seu grupo para usar métricas do ELB (como a contagem de solicitações do Application Load Balancer por destino) para escalar o número de instâncias no grupo conforme a demanda flutua. Opcionalmente, você pode adicionar verificações de saúde do ELB ao seu grupo de Auto Scaling para que o Amazon Auto EC2 Scaling possa identificar e substituir instâncias não íntegras com base nessas verificações de saúde. Você também pode criar um CloudWatch alarme da Amazon que o notifique se a contagem saudável de anfitriões do grupo-alvo estiver abaixo do permitido.

O diagrama a seguir ilustra como um Application Load Balancer gerencia cargas de trabalho na Amazon em EC2 . AWS Outposts

O diagrama a seguir ilustra uma arquitetura similar para a Amazon EC2 em Zonas Locais.

Amazon Route 53 para failover de DNS

Quando você tem mais de um recurso executando a mesma função, por exemplo, vários servidores HTTP ou de e-mail, você pode configurar o Amazon Route 53 para verificar a integridade dos seus recursos e responder às consultas de DNS usando somente os recursos íntegros. Por exemplo, vamos supor que seu site,example.com, esteja hospedado em dois servidores. Um servidor está em uma zona local e o outro em um posto avançado. Você pode configurar o Route 53 para verificar a integridade desses servidores e responder às consultas de DNS example.com usando somente os servidores que estão íntegros no momento. Se você estiver usando registros de alias para rotear o tráfego para AWS recursos selecionados, como balanceadores de carga do ELB, você pode configurar o Route 53 para avaliar a integridade do recurso e rotear o tráfego somente para recursos que estejam íntegros. Ao configurar um registro de alias para avaliar a integridade de um recurso, você não precisa criar uma verificação de saúde para esse recurso.

O diagrama a seguir ilustra os mecanismos de failover do Route 53.

Amazon Route 53 Resolver em AWS Outposts

Amazon Route 53 Resolverestá disponível nos racks Outposts. Ele fornece aos seus serviços e aplicativos locais resolução de DNS local diretamente do Outposts. Os endpoints locais do Route 53 Resolver também permitem a resolução de DNS entre Outposts e seu servidor DNS local. O Route 53 Resolver on Outposts ajuda a melhorar a disponibilidade e o desempenho de seus aplicativos locais.

Um dos casos de uso típicos do Outposts é implantar aplicativos que exigem acesso de baixa latência a sistemas locais, como equipamentos de fábrica, aplicativos comerciais de alta frequência e sistemas de diagnóstico médico.

Quando você opta por usar resolvedores locais do Route 53 em Outposts, os aplicativos e serviços continuarão se beneficiando da resolução de DNS local para descobrir outros serviços, mesmo que a conectividade com um Região da AWS dos pais seja perdida. Os resolvedores locais também ajudam a reduzir a latência das resoluções de DNS porque os resultados das consultas são armazenados em cache e veiculados localmente a partir dos Outposts, o que elimina viagens de ida e volta desnecessárias ao pai. Região da AWS Todas as resoluções de DNS para aplicativos em Outposts VPCs que usam DNS privado são servidas localmente.

Além de habilitar resolvedores locais, esse lançamento também habilita endpoints locais do Resolver. Os endpoints de saída do Route 53 Resolver permitem que os resolvedores do Route 53 encaminhem consultas de DNS para os resolvedores de DNS que você gerencia, por exemplo, em sua rede local. Por outro lado, os endpoints de entrada do Route 53 Resolver encaminham as consultas de DNS que recebem de fora da VPC para o Resolver que está sendo executado nos Outposts. Ele permite que você envie consultas de DNS para serviços implantados em uma VPC privada do Outposts de fora dessa VPC. Para obter mais informações sobre endpoints de entrada e saída, consulte Resolvendo consultas de DNS entre VPCs e sua rede na documentação do Route 53.