Resumo

  • Se os registros principal e secundário de failover tiverem verificações de integridade e ambos forem considerados não íntegros, Route 53 retorna o principal.
  • A AWS preserva uma chance de acesso diante de verificações erradas ou sobrecarga em cadeia. Cabe à empresa definir o que sua aplicação pode continuar confirmando nesse estado.

O reserva não responde por tudo

Uma segunda instalação rende uma boa fotografia para a apresentação de continuidade. O principal cai, o reserva assume e a reunião termina com a palavra resiliência. O problema é que o reserva também pode receber um cartão vermelho. Nessa hora, o orçamento já foi aprovado, mas a decisão comercial talvez ainda não tenha sido tomada.

A regra de Route 53 é direta para dois registros de failover com verificações associadas. Principal íntegro: retorna o principal. Principal não íntegro e secundário íntegro: retorna o secundário. Ambos não íntegros: retorna o principal. O titular volta ao campo sem uma nova aprovação médica. Como os registros são escolhidos

O retorno ocorre na resposta DNS. A classificação de integridade não muda por esse motivo. O endereço escolhido ainda leva a uma aplicação que terá de lidar com a solicitação de verdade. Existe, portanto, uma distância entre fornecer um destino e concluir uma tarefa, mesmo que a proposta de compra use disponibilidade para falar dos dois.

No último caso, o serviço expressa uma preferência: quando a medição rejeita todas as alternativas, mantém uma tentativa possível. O comprador que esperava um bloqueio automático de todos os destinos ruins precisa conferir se sua aplicação implementa a política que imaginou ter comprado.

Uma medição errada também derruba serviço

A AWS explica por que evita eliminar todas as respostas. Uma verificação configurada incorretamente pode reprovar uma aplicação que continua atendendo usuários. Se a reprovação retirasse todas as opções, o instrumento de observação produziria a interrupção. A resposta de último recurso conserva uma oportunidade. Explicação dos problemas de failover

A documentação traz ainda um exemplo de sobrecarga. Um entre três destinos é excluído; os outros dois recebem mais trabalho e também falham. Redistribuir novamente entre os três pode ser melhor do que mantê-los todos fora. Esse é o exemplo oficial usado para explicar o projeto, sem atribuição a um prejuízo observado em algum cliente.

O raciocínio é sensato. Uma sonda observa uma parte do sistema, com condições que alguém definiu. Transformá-la em autoridade absoluta para fechar todas as portas acrescenta sua precisão à lista de dependências do negócio. Dar uma última chance pode salvar uma consulta que ainda funcionaria.

O valor da chance depende da tarefa. Recarregar uma página informativa e confirmar uma operação difícil de desfazer carregam riscos econômicos diferentes. Uma aplicação pode permitir certas leituras durante a degradação e restringir certas confirmações. Essa escolha exige conhecimento do negócio e um mecanismo capaz de aplicá-la.

O servidor reserva não traz essa regra na caixa. Ele pode acrescentar capacidade e outro caminho. A autorização para continuar assumindo compromissos precisa de um dono dentro da empresa.

O tamanho real do selo de integridade

Nas verificações de endpoint, o cliente define protocolo, intervalo e limiar de falhas, entre outros parâmetros. Falhas consecutivas levam à classificação negativa ao atingir o limiar; um sucesso anterior reinicia a contagem. Notificações podem ser configuradas com CloudWatch e SNS. Avisar o operador e selecionar um registro são funções com regras próprias. Funcionamento das verificações

Os intervalos das verificações de endpoint são de dez ou trinta segundos, com verificadores independentes. Cada pergunta DNS não dispara uma nova simulação completa da operação do cliente. O roteamento utiliza observações periódicas. Condições de integridade

Uma resposta HTTP ou HTTPS que atende ao teste oferece informação útil. Concluir uma compra com consulta de estoque, confirmação e registro do resultado exige evidência adicional. A própria AWS informa que as verificações HTTPS não validam certificados SSL/TLS. O selo cobre a prova executada, por mais abrangente que pareça o nome.

Há também o caso do reserva sem verificação. Um registro sem esse controle é considerado íntegro. Quando o principal reprova, o secundário pode ser retornado mesmo que seu destino esteja realmente com problemas. Retirar o exame muda a seleção do candidato; não aumenta sua capacidade.

A compra deveria separar três coisas: recursos alternativos, capacidade de observar falhas e capacidade de produzir resultados corretos durante uma degradação. Duas entradas que dependem do mesmo componente indispensável podem continuar representando uma única maneira de terminar o trabalho. Contar endereços não revela essa dependência.

A homologação precisa dos dois vermelhos

Testar o principal indisponível com o reserva funcionando é útil. É preciso também examinar, em ambiente controlado, o estado em que ambas as verificações indicam falta de integridade. O registro do teste deve juntar o julgamento das sondas, as respostas DNS recebidas e as ações que a aplicação efetivamente permite concluir.

A console oferece estado, motivo da última falha, endereço do verificador e horário para as verificações correspondentes, com exceções para as calculadas. Esses dados ajudam a montar uma sequência verificável. Como consultar o estado

O lugar da observação importa. A AWS explica que uma partição de rede pode dar a diferentes locais de Route 53 visões distintas da integridade, inclusive diferentes de CloudWatch. Uma captura da tela central não substitui as respostas recebidas em cada ponto.

Os documentos oficiais não fornecem a taxa de sucesso de um cliente específico nesse estado duplo; avaliar um incidente exige respostas DNS e resultados da aplicação no mesmo período.

Para a decisão de compra, a regra já oferece material suficiente. A AWS escreveu sua última alternativa. A empresa precisa escrever quais promessas pode aceitar quando alguém chegar por ela. O destino continua sendo uma informação técnica; o compromisso assumido ali entra no balanço do negócio.