Eu estou olhando para usar o ELB (Elastic Load Balancing), a fim de reduzir o tempo de inatividade quando um servidor fica inativo. Basicamente, eu não quero mudar os registros DNS relevantes e esperar pela propagação do DNS em todo o mundo, eu só quero redirecionar o tráfego para outra máquina servindo meu aplicativo.
No entanto, quase todos os meus servidores não são instâncias do EC2, são VPS ou servidores dedicados com uma empresa que não tem nada a ver com a Amazon.
É possível usar alguma combinação de serviços da Amazon (em especial o ELB) que me permita apontar um nome de domínio em um balanceador de carga elástico e fazer com que ele encaminhe solicitações para 1-2 servidores fora da rede da Amazon?
Se o IP do balanceador for alterado, isso obviamente não funcionará (não é possível apontar um nome de domínio raiz para ele). No entanto, você poderia atribuir ao balanceador um IP elástico, e então apontar seu nome de domínio para ele + configurá-lo para encaminhar solicitações para Non-Amazon-PrivateServer1 e Non-Amazon-PrivateServer2?
O ELB só envia tráfego para instâncias do EC2.
Você pode ter algumas instâncias nginx EC2 atrás de um tráfego proxy ELB para seus servidores reais, ou você pode simplesmente seguir a rota simples e soltar seu DNS TTL para algo como 10 minutos para que as alterações reflitam mais rapidamente.
A partir de 31 de agosto de 2017, o Application Load Balancers suportam endereços IP como destinos além de IDs de instância :
We are pleased to announce that Application Load Balancers can now distribute traffic to AWS resources using their IP addresses as targets in addition to the instance IDs. You can also load balance to resources outside the VPC hosting the load balancer using their IP addresses as targets. This includes resources in peered VPCs, EC2-Classic, and on-premises locations reachable over AWS Direct Connect or a VPN connection. Load balancing across AWS and on-premises resources using the same load balancer makes it easy for you to migrate-to-cloud, burst-to-cloud, or failover-to-cloud.
Por que não usar o Route53 com verificações de saúde para isso?
Primeiro, você cria uma verificação de integridade baseada em IP para cada um dos seus servidores. Essas verificações podem ser simples e apenas monitorar o status HTTP 200 para uma determinada solicitação; ou você pode criar verificações mais avançadas que pesquisam uma string específica no resultado da solicitação.
Em seguida, se ainda não o fez, crie uma zona hospedada para o domínio que você está usando no Route53; e forneça ao registrador do seu domínio os servidores DNS atribuídos ao Route53.
Uma vez feito isso, para cada servidor que você deseja balancear os pedidos, crie um Conjunto de Registros (dentro da Zona Hospedada que acabou de criar) usando por exemplo o tipo 'Ponderado', um TTL curto (60 ou inferior) e selecione 'Associado com Health Check: YES 'e escolha a Health Check que você criou acima correspondente ao servidor / IP específico para o qual você está criando o registro. Novamente, repita isso para cada servidor / IP.
Você acaba com vários conjuntos de registros, cada um com 1 IP e todos associados ao mesmo domínio no Route53. Em solicitações de DNS, o Route53 retornará um deles com base no peso atribuído a eles E com base no status atual de cada verificação de integridade. Se alguma verificação de integridade falhar, esse IP específico será omitido.
Você também pode fazer isso usando outros tipos de conjuntos de registros Route53; por exemplo, com 'Failover' você tem 1 ou vários IPs primários e 1 ou vários IPs secundários. O Route53 sempre retornará um dos IPs principais, a menos que as verificações de integridade para eles falhem e, em seguida, ele mude para um dos secundários.
E há tipos de registro mais complexos no Route53 que também podem ser combinados com verificações de integridade: Latência, Geolocalização, Multivalor. Tudo muito bem explicado nos documentos da AWS.