[eside-ghost] alta disponibilidad en routing basico
Jose Ignacio Sanchez
sanchez en osha.eu.int
Jue Feb 10 14:30:26 CET 2005
Aupa zgor!
Casualmente durante este ultimo año me he rayado mucho con ese tema pq
tenemos un proyecto entre manos para hacer una redundancia total a nivel de
red y aplicacion.
Primero, tienes que decidir si quieres el "fail-over" para conexiones
entrantes (es decir, servicios que ofreces al exterior), o para conexiones
salientes (navegar).
[lo que te cuento no requiere ningun hardware especial, con lo que el coste
es 0, pq imagino tendras ya un router linux que hace de firewall]
En el primer caso la mejor solucion mas barata (sin contratar BGP entre los
ISP) e inteligente pasa por jugar con el NAT y usar el "fail-over" inherente
al servicio DNS. La movida, tal y como la pense, sería asi:
1) Conectas ambas lineas de los proveedores de internet que tienes, a un
router/firewall linux tuyo. Cada proveedor te dara un rango de direcciones
IP distinto.
2) A los servidores de tu DMZ, les pones direcciones IP INTERNAS. Con el
router linux haces un NAT para traducir cada una de esas direcciones IP
interna hacia 2 direcciones ip reales, una de CADA PROVEEDOR.
3) Tus servidores DNS por tanto, como todos los demas, tendran 2 direcciones
reales, una de cada servidor. Lo que hay que hacer es DELEGAR tu dominio en
un DNS primario que sera la IP-1 real de tu server DNS, y secundario la IP-2
de tu DNS. De tal manera que ambos son el mismo server pero distintas IPs.
4) Aqui viene el meollo de la cuestion. En cada servidor DNS resuelves los
registros A a distintas IPs. En el servidor DNS_A con IP real de telefonica
(imaginemos), resolvera www.zgor.com a IP-1. Mientras que el DNS_B con IP
real de otro proveedor (imaginemos), resolvera www.zgor.com a IP-2 (este
DNS, no replica al primario!).
Tus clientes cuando quieran ver tu web, usaran el DNS_A y resolveran a IP-1.
PERO, si la conexion con telefonica cae, tus clientes fallaran al acceder a
DNS_A, y accederan al secundario DNS_B que resolvera www.zgor.com a IP-2 con
lo que de forma automatica entraran por la otra conexion activa.
La historia es poner un TTL bajo, para que cuando tu conexion principal se
levante, los clientes entren por ella.
Lo wapo de este asunto es que el mecanismo inherente al servicio DNS hace el
failover sin necesidad de ningun hardware especial. Incluso si en vez de un
router linux, pones 2 con VRRP, y en vez de un servidor web, pones 2 por
VRRP y roundrobin DNS, tienes un failover total con balanceo de carga
parcial y ni un solo "single point of failure". Genial.
Esto funciona que te cagas para ofrecer servicios al exteior. Para lo otro,
conexiones salientes para que los usuarios de tu empresa naveguen, tienes
que usar otra cosa.
Lo que has comentado de SNMP no vale por la sencilla razon de que el fallo
puede estar en un router de zona de tu ISP, y ni tus routers ni los
inmediatamente conectados a ti, se darian cuenta y lo reportarian (a no ser
que haya algun protocolo de enrutado dinamico llegando hasta ti).
Lo mejor, mas sencillo pero efectivo es lo que has comentado del script que
pingee. En vez de pingar quizas es mejor lanzar SYN a puertos 80 de
servidores web de internet y esperar SYN-ACK respuesta. Si lo haces con 10
servidores y ninguno responde es claro que tu linea ha caido, entonces
peudes cambiar los pesos en las rutas por defecto del router.
Yo tengo ese script implementado, si te interesa te lo rulo.
Espero que esto te sirva.
Un saludo!
Topo[LB]
> -----Original Message-----
> From: eside-ghost-bounces en deusto.es
> [mailto:eside-ghost-bounces en deusto.es]On Behalf Of zgor
> Sent: jueves, 10 de febrero de 2005 13:07
> To: Lista de eside-ghost
> Subject: [eside-ghost] alta disponibilidad en routing basico
>
>
> Aupi,
> Tengo una pequeña duda ....
> Si por ejemplo tenemos un router gnu linux con dos posibles accesos a
> internet (no balanceados pero si disponibles ambos) directamente
> conectados a su/sus ifaces (dos adsls, cable modems, ...
> cualquier cosa
> ethernet vamos), como hariais para detectar un fallo en un acceso y
> actuar en base a ello (cambiar la default route basicamente)?
>
> He estado mirando historias de LVS y tal pero en principio
> creo que no
> me sirven, son más bien para redundar hosts con servicios o incluso
> routers, pero el caso es que no es el router gnu linux el que
> puede fallar.
> Lo que tengo pensado es un un mini script que envia un ping a
> un host de
> internet con garantia muy alta de estar vivo (kernel.org,
> google ....,
> una ip de paso de un router de nuestro isp ...) y si no hay respuesta
> tras X intentos en Y tiempo maximo, se cambia la default route, de
> mientras sigue en background comprobando si ha vuelto el
> acceso original
> para dejar la ruta por defecto como estaba antes (para ello enviar un
> ping pero con ruta especifica).
> El caso es que me parece un poco chapucero, quizas seria
> mejor mirar por
> snmp si esta el iface levantado/caido, pero eso tampoco es
> una garantia
> de que nuestro isp nos esté encaminando.... Tambien se podria hacer
> quizas con nagios, lo que no se es si el check_ping que trae
> se le puede
> pasar por parametro una ruta especifica.
>
> Aunque pensandolo bien, tambien se podria configurar el routing para
> encaminar por ejemplo un hostA (que no se suela acceder mucho) por el
> acceso secundario y viceversa con un HostB y bastaria con
> pingar a esos
> dos hosts sin preocuparse por donde vaya porque se supone que ya esta
> configurada la ruta ... ummm
>
> Luego tambien se plantea la historia de los servicios que
> estén detrás
> de esa maquina, mail, web, etc .... el caso es que abría que
> modificar
> nuestros dns para que apunten a la nueva ip (la del otro
> acceso), eso se
> podria hacer si por ejemplo tenemos el dns fuera y ejecutar
> un comando
> automatico que intercambie las configuraciones del dns ... no
> se, como
> lo veis ? Mucho cristo? Quizas sea mejor confiar en que el ISP no nos
> dejará tirados?
>
> Justo antes de enviar este mail he encontrado:
> http://www.ssi.bg/~ja/nano.txt, que parece interesante, quizas sea la
> solucion....aunque la problematica de los servicios por dns seguira
> existiendo
>
> no se, como lo veis?
>
>
>
> _______________________________________________
> eside-ghost mailing list
> eside-ghost en deusto.es
> https://listas.deusto.es/mailman/listinfo/eside-ghost
Más información sobre la lista de distribución eside-ghost