Estoy considerando utilizar Amazon Elastic Load Balancing (ELB) para reducir el tiempo de inactividad cuando un servidor deja de funcionar. Básicamente, no quiero cambiar los registros DNS relevantes y esperar a que el DNS se propague por todo el mundo, solo quiero redirigir el tráfico a otra máquina que sirve mi aplicación.
Sin embargo, casi todos mis servidores no son instancias EC2, son VPS o servidores dedicados de una empresa que no tiene nada que ver con Amazon.
¿Es posible utilizar alguna combinación de servicios de Amazon (en particular ELB) que me permita apuntar un nombre de dominio a un equilibrador de carga elástico y reenviar solicitudes a 1 o 2 servidores fuera de la red de Amazon?
Si la IP del equilibrador cambia, esto obviamente no funcionará (entonces no se puede señalar un nombre de dominio raíz). Sin embargo, ¿podría asignarle al equilibrador una IP elástica yentonces¿Apuntarle su nombre de dominio + configurarlo para reenviar solicitudes a Non-Amazon-PrivateServer1 y Non-Amazon-PrivateServer2?
Respuesta1
ELB solo enviará tráfico a instancias EC2.
Podría tener un par de instancias nginx EC2 detrás de un tráfico proxy ELB a sus servidores reales, o simplemente podría seguir la ruta simple y reducir su TTL de DNS a unos 10 minutos para que los cambios se reflejen más rápidamente.
Respuesta2
Al 31 de agosto de 2017, elLos balanceadores de carga de aplicaciones admiten direcciones IP como destinos además de los ID de instancia:
Nos complace anunciar que los balanceadores de carga de aplicaciones ahora pueden distribuir tráfico a los recursos de AWS utilizando sus direcciones IP como destinos además de los ID de instancia. También puede equilibrar la carga en recursos fuera de la VPC que aloja el equilibrador de carga utilizando sus direcciones IP como destinos. Esto incluye recursos en VPC emparejadas, EC2-Classic y ubicaciones locales a las que se puede acceder a través de AWS Direct Connect o una conexión VPN. El equilibrio de carga entre AWS y los recursos locales utilizando el mismo equilibrador de carga le facilita la migración a la nube, la ráfaga a la nube o la conmutación por error a la nube.
Respuesta3
¿Por qué no utilizar Route53 con controles de estado para esto?
Primero, crea una verificación de estado basada en IP para cada uno de sus servidores. Estas comprobaciones pueden ser simples y simplemente monitorear el estado de HTTP 200 para una determinada solicitud; o puede crear comprobaciones más avanzadas que busquen una cadena específica en el resultado de la solicitud.
A continuación, si aún no lo ha hecho, cree una zona alojada para el dominio que está utilizando en Route53; y proporcione al registrador de su dominio los servidores DNS asignados por Route53.
Una vez hecho esto, para cada servidor sobre el que desee equilibrar las solicitudes, cree un conjunto de registros (dentro de la zona alojada que acaba de crear) utilizando, por ejemplo, el tipo "ponderado", un TTL corto (60 o menos) y seleccione "Asociar con comprobación de estado". : SÍ y elija la Verificación de estado que creó anteriormente correspondiente al servidor/IP específico para el que está creando el registro. Nuevamente, repita esto para cada servidor/IP.
Terminará con múltiples conjuntos de registros, cada uno con 1 IP y todos asociados con el mismo dominio en Route53. Tras las solicitudes de DNS, Route53 ahora devolverá uno de ellos según el peso que se les asignó Y según el estado actual de cada verificación de estado. Si alguna verificación de estado falla, se omite esa IP específica.
También puedes hacer esto usando otros tipos de conjuntos de registros de Route53; por ejemplo, con 'Failover' tienes 1 o varias IP primarias y 1 o varias IP secundarias. Route53 siempre devolverá una de las IP principales a menos que fallen las comprobaciones de estado, luego cambia a una de las secundarias.
Y hay tipos de registros más complejos en Route53 que también se pueden combinar con comprobaciones de estado: Latencia, Geolocalización, Valor múltiple. Todo muy bien explicado en los documentos de AWS.