Melhores práticas para controle de roteamento em ARC

Em um cenário de recuperação de desastres (DR), reduza ao mínimo as dependências do sistema usando uma abordagem simples para acessar AWS e executar tarefas de recuperação. Crie credenciais de IAM longa duração especificamente para tarefas de DR e guarde as credenciais com segurança em um cofre físico local ou em um cofre virtual, para acessar quando necessário. ComIAM, você pode gerenciar centralmente as credenciais de segurança, como chaves de acesso e permissões de acesso aos AWS recursos. Para tarefas que não sejam de DR, recomendamos que você continue usando o acesso federado, usando serviços da AWS como o AWS Single Sign-On.

Para realizar tarefas de failover ARC com o plano de dados do cluster de recuperaçãoAPI, você pode anexar uma ARC IAM política ao seu usuário. Para saber mais, consulte Exemplos de políticas baseadas em identidade em .

Para DNS registros que talvez você precise alterar como parte do mecanismo de failover, especialmente registros com verificação de integridade, é apropriado usar TTL valores mais baixos. Definir um TTL de 60 ou 120 segundos é uma escolha comum para esse cenário.

A configuração DNS TTL (tempo de vida) informa aos DNS resolvedores por quanto tempo armazenar um registro em cache antes de solicitar um novo. Ao escolher umTTL, você faz uma troca entre latência e confiabilidade e capacidade de resposta às mudanças. Com um menor TTL em um registro, os DNS resolvedores notam atualizações no registro mais rapidamente porque isso TTL especifica que eles devem consultar com mais frequência.

Para obter mais informações, consulte Escolha de TTL valores para DNS registros em Melhores práticas para o Amazon Route 53 DNS.

Quando você usa controles de roteamento para mudar de um Região da AWS para outro, o mecanismo que o Amazon Application Recovery Controller (ARC) usa para mover o tráfego do seu aplicativo é uma DNS atualização. Essa atualização faz com que todas as novas conexões sejam direcionadas para fora do local danificado.

No entanto, clientes com conexões abertas preexistentes podem continuar fazendo solicitações no local danificado até que os clientes se reconectem. Para garantir uma recuperação rápida, recomendamos que você limite a quantidade de tempo que os clientes permanecem conectados aos seus endpoints.

Se você usar um Application Load Balancer, poderá usar a keepalive opção para configurar por quanto tempo as conexões continuarão. Para obter mais informações, consulte a duração HTTP do keepalive do cliente no Guia do usuário do Application Load Balancer.

Por padrão, os Application Load Balancers definem o valor da duração HTTP do keepalive do cliente como 3.600 segundos ou 1 hora. Sugerimos que você reduza o valor para estar alinhado com a meta de tempo de recuperação do aplicativo, por exemplo, 300 segundos. Ao escolher o tempo de duração HTTP do keepalive de um cliente, considere que esse valor é uma troca entre se reconectar com mais frequência em geral, o que pode afetar a latência, e afastar mais rapidamente todos os clientes de uma AZ ou região com problemas.

Recomendamos que você mantenha uma cópia local dos endpoints do cluster ARC regional, em marcadores ou salva no código de automação que você usa para testar novamente seus endpoints. Durante um evento de falha, talvez você não consiga acessar algumas API operações, incluindo ARC API operações que não estão hospedadas no cluster de plano de dados extremamente confiável. Você pode listar os endpoints dos seus ARC clusters usando a DescribeClusterAPIoperação.

Recomendamos que, quando você precisar fazer o failover, atualize (e recupere) os estados de controle de roteamento usando um endpoint aleatório de seus cinco endpoints de cluster regionais. Se esse endpoint falhar, tente novamente cada um dos outros endpoints regionais. Para obter informações sobre como usar exemplos de código com o AWS SDK, incluindo exemplos para testar endpoints de cluster, consulteExemplos de código para o Application Recovery Controller usando AWS SDKs.

Usando o plano de ARC dadosAPI, visualize seus controles e estados de roteamento com a ListRoutingControlsoperação e atualize os estados de controle de roteamento para redirecionar o tráfego para failover com a operação. UpdateRoutingControlState Você pode usar o AWS CLI (como nesses exemplos) ou o código que você escreve usando um dos AWS SDKs. ARCoferece extrema confiabilidade API no plano de dados para fazer failover o tráfego. Recomendamos usar o API em vez de alterar os estados de controle de roteamento no AWS Management Console.

Conecte-se a um dos seus endpoints de cluster regionais ARC para usar o plano API de dados. Se o endpoint não estiver disponível, tente se conectar a outro endpoint do cluster.

Se uma regra de segurança bloquear uma atualização do estado do controle de roteamento, você poderá ignorá-la para fazer a atualização e fazer o failover do tráfego. Para obter mais informações, consulte Sobrepor regras de segurança para redirecionar o tráfego.

Teste o failover regularmente com controle de ARC roteamento, para fazer o failover de sua pilha de aplicativos primária para uma pilha de aplicativos secundária. É importante garantir que as ARC estruturas que você adicionou estejam alinhadas com os recursos corretos em sua pilha e que tudo funcione conforme o esperado. Você deve testar isso depois de configurar ARC seu ambiente e continuar testando periodicamente, para que seu ambiente de failover esteja preparado, antes de enfrentar uma situação de falha na qual você precise que seu sistema secundário esteja pronto e funcionando rapidamente para evitar tempo de inatividade para seus usuários.