Melhores práticas para controle de roteamento no 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 longa duração do IAM especificamente para tarefas de DR e mantenha as credenciais com segurança em um cofre físico local ou em um cofre virtual, para acessar quando necessário. Com o IAM, 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 no ARC com a API do plano de dados do cluster de recuperação, você pode anexar uma política do ARC IAM ao seu usuário. Para saber mais, consulte Exemplos de políticas baseadas em identidade no Amazon Application Recovery Controller (ARC).

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

A configuração DNS TTL informa aos resolvedores de DNS por quanto tempo armazenar um registro em cache antes de solicitar um novo. A escolha de um TTL envolve um equilíbrio entre latência e confiabilidade e capacidade de resposta à mudança. Com TTLs mais curtos em um registro, os resolvedores de DNS perceberão atualizações no registro mais rapidamente, pois deverão consultá-lo com mais frequência.

Para obter mais informações, consulte Escolher valores de TTL para registros DNS em Práticas recomendadas para o DNS do Amazon Route 53.

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 atualização de DNS. 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 do keepalive do cliente HTTP no Guia do usuário do Application Load Balancer.

Por padrão, os Application Load Balancers definem o valor da duração do keepalive do cliente HTTP 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 do keepalive de um cliente HTTP, 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 tentar novamente seus endpoints. Durante um evento de falha, talvez você não consiga acessar algumas operações de API, incluindo operações de API ARC que não estão hospedadas no cluster de plano de dados extremamente confiável. Você pode listar os endpoints dos seus clusters ARC usando a operação de DescribeClusterAPI.

Os controles de roteamento fornecem cinco endpoints regionais para garantir alta disponibilidade, mesmo ao lidar com falhas. Para alcançar sua resiliência total, é importante ter uma lógica de repetição que possa usar todos os cinco endpoints conforme necessário. Para obter informações sobre como usar exemplos de código com o AWS SDK, incluindo exemplos para testar endpoints de cluster, consulte. Exemplos de código para o Application Recovery Controller usando AWS SDKs

Usando a API do plano de dados ARC, 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. O ARC oferece extrema confiabilidade com a API no plano de dados para fazer failover o tráfego. Recomendamos usar a API em vez de alterar os estados de controle de roteamento no AWS Management Console.

Conecte-se a um de seus endpoints de cluster regionais para ARC para usar a API do plano 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 o controle de roteamento ARC, para fazer o failover de sua pilha de aplicativos primária para uma pilha de aplicativos secundária. É importante garantir que as estruturas ARC 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 o ARC para 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.