AWS ELB página “desculpe, o site está inativo”

Question

Eu tenho um site ELB v2 básico. Nenhum agrupamento ou qualquer coisa ainda. Eu sou muito inexperiente com a AWS.

Minha pilha é nginx / uwsgi / django + alguns outros serviços.

Eu queria saber se alguém pensou em fazer uma página "desculpe, o site está inativo ..." - sempre que houver tempo de inatividade por qualquer motivo, e a integridade da instância é vermelha. Não parece que a Amazon oferece essa capacidade - estou faltando alguma coisa? Existe uma maneira de criar uma instância separada, super minúscula, que é SOMENTE servida se a principal for vermelha ou algo do tipo?

Obrigado!

    

Answer 1

A solução simples e interessante aqui é colocar o seu ELB no CloudFront.

Se o servidor de origem (o ELB, neste caso) lança um erro 5XX (ou 4XX, se quiser), o CloudFront pode retornar um página de erro personalizada , que você pode configurar o CloudFront para buscar a partir de um bucket do S3 criando uma segunda origem apontando para o bucket e criando um roteamento de comportamento do cache (por exemplo) /errors/static/* para o balde.

Isso funciona melhor do que o failover do Route 53 por uma razão importante ... uma falha fatal, se você ... os navegadores forem terríveis com o cache de pesquisas de DNS por muito mais tempo do que o esperado. O TTL do DNS não é relevante.

Essencialmente, quando um navegador tem uma entrada de DNS em mãos, ele simplesmente tenta usá-lo ... normalmente, até que todas as janelas do navegador sejam fechadas.

Portanto, se o seu site ficar inativo para um visitante que já estava no site, é improvável que ele veja o site alternativo.

Pior, se um visitante acessar seu site pela primeira vez enquanto estiver inativo, ele ficará "preso" na página de manutenção até fechar todas as janelas do navegador.

Se você usa o DNS de failover, isso é realmente bom somente se o destino de failover ainda for seu aplicativo, talvez um pouco mais longe.

Você pode desativar o cache do CloudFront se não precisar dele.

Você também pode configurar o TTL de cache de erros do CloudFront para um valor diferente de zero se quiser que ele pare de martelar seu site enquanto ele estiver inativo e tentando se recuperar. Para uma determinada página que gera um erro, ela continuará mostrando a página de erro e não incomodará o servidor com mais solicitações para essa página até que o Erro CachingTTL expire.

    

Answer 2

Use o DNS Route53 e o roteamento de failover . Você deve conseguir um bucket S3 que hospede um site estático de página única. Eu não acho que você pode fazer isso apenas com o ELB.

A Amazon tem uma postagem no blog que mostra como fazer isso aqui .

Atualização: como Michael diz, há uma desvantagem em relação ao cache do DNS do navegador, veja sua resposta para mais informações. O Route 53 é provavelmente uma opção mais simples que o CloudFront, mas o CF tem outras vantagens, desempenho e, em alguns casos de uso, pode reduzir os custos.

    

Answer 3

Várias soluções já foram mencionadas, incluindo o CloudFront e o Route53. O CloudFront é uma excelente solução e, na minha experiência, não diminuiu a velocidade das coisas, mas traz um custo adicional. E o Route53 tem os problemas de cache do DNS já mencionados.

Até que o ALB ofereça suporte a páginas de erro personalizadas prontas para uso (o que pode ou não acontecer), há potencialmente uma nova solução após o anúncio recente de ALB respostas fixas , mas não é apontar e clicar: você pode configurar uma função do Lambda que adiciona temporariamente uma regra ao seu balanceador de carga, fornecendo uma resposta fixa com o conteúdo da sua "página de erro".

Além de escrever o Lambda, você precisará encontrar uma maneira de ativá-lo e desativá-lo, o que pode ser feito por meio de uma verificação de saúde de Route53 ou de verificação de grupo de destino do balanceador de carga (provavelmente por meio do alarme do CloudWatch > SNS - > Lambda).

Não é exatamente simples, mas provavelmente funcionaria bem depois de configurado!

    

Answer 4

Como foi escrito por @Tim e @Micheal, você tem a escolha de usar o DNS Route53 e roteamento de failover ou CloudFront com páginas de erro personalizadas . Ambos os métodos têm seus prós e contras.

Se você ainda não usa o Cloudfront, acho que o Route53 é uma solução mais simples. Veja a postagem no blog atualizada da AWS (que agora inclui um método mais simples para integração de ELB).

O CloudFront é muito mais complicado de configurar e levará cerca de 15 minutos para cada atualização. A Cloudfront também armazena em cache (como seria de se esperar), portanto, não está claro se isso será mais lento para responder do que os problemas de cache do DNS com o Route 53.

Observe que, se o site do ELB responder apenas ao SSL, você não poderá usar a solução simples do S3, conforme descrito no blog da AWS 3 . Nesse caso, você terá que adicionar o Cloudfront na frente do bucket do S3 para adicionar o SSL, o que torna a solução de roteamento de falhas do DNS mais complicada.