Este documento está em processo de atualização. Nesse ínterim, parte do conteúdo pode não ser precisa.

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á.

Pensando em termos de modos de falha

Ao projetar um aplicativo ou sistema altamente disponível, você deve considerar quais componentes podem falhar, qual impacto as falhas de componentes terão no sistema e quais mecanismos você pode implementar para mitigar ou eliminar o impacto das falhas de componentes. Seu aplicativo é executado em um único servidor, em um único rack ou em um único datacenter? O que acontecerá quando um servidor, rack ou datacenter sofrer uma falha temporária ou permanente? O que acontece quando há uma falha em um subsistema crítico, como rede ou no próprio aplicativo? Esses são modos de falha.

Você deve considerar os modos de falha nesta seção ao planejar seus Outposts e implantações de aplicativos. As seções a seguir analisarão como mitigar esses modos de falha para fornecer um maior nível de alta disponibilidade para seu ambiente de aplicativos.

Modo de falha 1: Rede

A implantação de um Outpost depende de uma conexão resiliente com sua região principal para gerenciamento e monitoramento. As interrupções na rede podem ser causadas por uma variedade de falhas, como erros do operador, falhas no equipamento e interrupções no provedor de serviços. Um Outpost, que pode ser composto por um ou mais racks conectados entre si no local, é considerado desconectado quando não consegue se comunicar com a Região por meio do Link de Serviço.

Caminhos de rede redundantes podem ajudar a reduzir o risco de eventos de desconexão. Você deve mapear as dependências do aplicativo e o tráfego de rede para entender o impacto que os eventos de desconexão terão nas operações da carga de trabalho. Planeje redundância de rede suficiente para atender aos requisitos de disponibilidade de seus aplicativos.

Durante um evento de desconexão, as instâncias executadas em um Outpost continuam em execução e podem ser acessadas a partir de redes locais por meio do Outpost Local Gateway (). LGW As cargas de trabalho e os serviços locais podem ser prejudicados ou falhar se dependerem de serviços na região. Solicitações mutantes (como iniciar ou interromper instâncias no Posto Avançado), operações do plano de controle e telemetria de serviço (por exemplo, CloudWatch métricas) falharão enquanto o Posto Avançado estiver desconectado da Região.

Modo de falha 2: Instâncias

EC2As instâncias podem ficar danificadas ou falhar se o servidor em que estão sendo executadas tiver um problema ou se a instância apresentar uma falha no sistema operacional ou no aplicativo. A forma como os aplicativos lidam com esses tipos de falhas depende da arquitetura do aplicativo. Os aplicativos monolíticos geralmente usam recursos do aplicativo ou do sistema para recuperação, enquanto as arquiteturas modulares orientadas a serviços ou de microsserviços geralmente substituem os componentes com falha para manter a disponibilidade do serviço.

Você pode substituir instâncias com falha por novas instâncias usando mecanismos automatizados, como grupos de EC2 Auto Scaling. A recuperação automática de instâncias pode reiniciar instâncias que falham devido a falhas no servidor, desde que haja capacidade disponível suficiente nos servidores restantes.

Modo de falha 3: Computação

Os servidores podem falhar ou ficar danificados e podem precisar ser retirados de operação (temporária ou permanentemente) por vários motivos, como falhas de componentes e operações de manutenção programadas. A forma como os serviços no rack Outposts lidam com falhas e deficiências do servidor varia e pode depender de como os clientes configuram as opções de alta disponibilidade.

Você deve solicitar capacidade computacional suficiente para suportar um modelo de disponibilidade N+M, onde N é a capacidade necessária e M a capacidade ociosa provisionada para acomodar falhas no servidor.

As substituições de hardware para servidores com falha são fornecidas como parte do serviço de AWS Outposts rack totalmente gerenciado. AWS monitora ativamente a integridade de todos os servidores e dispositivos de rede em uma implantação do Outpost. Se houver necessidade de realizar manutenção física, a AWS agendará um horário para visitar seu site para substituir os componentes com defeito. O provisionamento de capacidade não utilizada permite que você mantenha suas cargas de trabalho em execução enquanto os servidores com falha são retirados de serviço e substituídos.

Modo de falha 4: racks ou datacenters

As falhas nos racks podem ocorrer devido à perda total de energia dos racks ou devido a falhas ambientais, como perda de resfriamento ou danos físicos ao datacenter causados por uma inundação ou terremoto. Deficiências nas arquiteturas de distribuição de energia do datacenter ou erros durante a manutenção padrão da energia do datacenter podem resultar na perda de energia de um ou mais racks ou até mesmo de todo o datacenter.

Esses cenários podem ser mitigados com a implantação de infraestrutura em vários andares ou locais de datacenter que sejam independentes uns dos outros dentro do mesmo campus ou área metropolitana.

Adotar essa abordagem com o AWS Outposts rack exigirá uma análise cuidadosa de como os aplicativos são arquitetados e distribuídos para serem executados em vários Outposts lógicos separados para manter a disponibilidade dos aplicativos.

Modo de falha 5: zona ou região de AWS disponibilidade

Cada Outpost está ancorado em uma Zona de Disponibilidade (AZ) específica dentro de uma Região da AWS. Falhas na AZ âncora ou na região-mãe podem causar a perda do gerenciamento e da mutabilidade do Outpost e podem interromper a comunicação de rede entre o Outpost e a Região.

Semelhantes às falhas de rede, as falhas na AZ ou na região podem fazer o Outpost ser desconectado da região. As instâncias executadas em um Posto Avançado continuam em execução e são acessíveis a partir de redes locais por meio do Outpost Local Gateway (LGW) e podem ser prejudicadas ou falhar se dependerem de serviços na Região, conforme descrito anteriormente.

Para mitigar o impacto das falhas de AWS AZ e região, você pode implantar vários Outposts, cada um ancorado em uma AZ ou região diferente. Em seguida, você pode projetar sua carga de trabalho para operar em um modelo distribuído de implantação Multi-Outpost usando muitos dos mecanismos e padrões de arquitetura semelhantes que você usa para projetar e implantar atualmente. AWS