Creo que se esta hablando de 2 cosas un poco distintas. Por un lado tenemos un servicio como DNS que nos brinda la resolucion de nombres y por otro lado tenemos el balanceo de carga, failover o cluster de servicios. Si el problema es que se pierde servicio por un problema de internet creo que la alternativa es poner un punto comun fuera de ese data center o directamente hablar con el ISP o encargado del servicio de internet. Por otro lado si estamos hablando que el problema es el servidor en donde se hostea el servicio lo que habria que hacer es poner un punto en comun que solamente distribuya la carga a los servidores que brindan el servicio. Por ejemplo si lo que queremos hacer es un fileover de un webserver, lo que se puede hacer es poner un servidor con haproxy (por ejemplo) que solamente forwarde los pedidos a un servidor master y en el caso de que este no este UP a un servidor de failover. El servidor que tiene la IP publica, o la que concentra el servicio es el que esta adelante (el que tiene el haproxy) y su ip es la que va a estar declarada en los DNS. RR para resolucion nombres solo sirve como 'balanceador' y no es muy bueno ya que te resuelve de forma aleatoria entre las IPs que conforman el RR, google y otras empresas con una gran cantidad de conexiones concurrentes lo utilizan para eso.
Por ahi no entendi bien el problema pero creo que un servicio en failover y una resolucion de nombres, si bien pueden ir de la mano son cosas un poco distintas. 2012/12/16 Alejandro <[email protected]>: > En mi caso tengo sitios con load balancers y sitios con RoundRobin, lo que > les puedo garantizar es que el RoundRobin no garantiza ningun failover, > simplemente funciona muy bien para balancear la carga entre multiples > servers, si no tenes un load balancer adelante, algo que tambien por > experiencia puedo confirmar es que el primer registro del DNS siempre recibe > un poco mas de trafico. > > Si tenes 2 IPs publicadas y 1 no anda el 50% del trafico va a dar error sin > reintentar... en el caso de los MX el DNS y el protocolo esta preparado para > reintentar con prioridades en los registros A y demas eso no existe por lo > que no hay forma de tener failover con RR. > > > > El 16 de diciembre de 2012 21:53, Ariel Camino <[email protected]> > escribió: > >> El 16/12/12 21:16, Cristian Mitchell escribió: >> > El día 16 de diciembre de 2012 20:15, Tio Oscar <[email protected]> >> > escribió: >> >> El 16 de diciembre de 2012 20:09, Ariel Camino <[email protected]> >> >> escribió: >> >> >> >>> El 16/12/12 19:57, Tio Oscar escribió: >> >>>> El 16 de diciembre de 2012 18:40, Ariel Camino <[email protected] >> >>>> <mailto:[email protected]>> escribió: >> >>>> >> >>>> Supongámosle que uno tiene uno o varios servidores web, de algo >> >>>> que >> >>>> no >> >>>> se puede caer bajo ningún tipo de circunstancia. >> >>>> >> >>>> Lo que normalmente se hace es poner un proxy reverso/balanceador >> >>>> nuboso >> >>>> o lo que a alguno se le ocurra, para que ante un fallback de x >> >>>> request, >> >>>> se pueda redireccionar la petición a otro servidor. >> >>>> >> >>>> Ahora el problema está en que cuando el navegador web quiere >> >>>> acceder >> >>>> a >> >>>> una URL, normalmente pregunta a el o los servidores DNS por un >> >>>> registro >> >>>> A, y obtiene solo una IP de respuesta (donde se encuentra el node >> >>>> balancer, nginx, pound, o lo que sea). >> >>>> >> >>>> Y generalmente ese es el server que se cae, y se rompe todo. >> >>>> >> >>>> Ahora, si uno pregunta "Dónde está google?" se encuentra con >> >>>> varias >> >>>> respuestas: >> >>>> >> >>>> dig A google.com <http://google.com> >> >>>> >> >>>> ; <<>> DiG 9.8.1-P1 <<>> A google.com <http://google.com> >> >>>> ;; global options: +cmd >> >>>> ;; Got answer: >> >>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20859 >> >>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 4, >> >>>> ADDITIONAL: >> >>>> 4 >> >>>> >> >>>> ;; QUESTION SECTION: >> >>>> ;google.com <http://google.com>. IN A >> >>>> >> >>>> ;; ANSWER SECTION: >> >>>> google.com <http://google.com>. 293 IN A >> >>>> 173.194.42.1 >> >>>> google.com <http://google.com>. 293 IN A >> >>>> 173.194.42.9 >> >>>> google.com <http://google.com>. 293 IN A >> >>>> 173.194.42.4 >> >>>> google.com <http://google.com>. 293 IN A >> >>>> 173.194.42.8 >> >>>> google.com <http://google.com>. 293 IN A >> >>>> 173.194.42.0 >> >>>> google.com <http://google.com>. 293 IN A >> >>>> 173.194.42.3 >> >>>> google.com <http://google.com>. 293 IN A >> >>>> 173.194.42.5 >> >>>> google.com <http://google.com>. 293 IN A >> >>>> 173.194.42.6 >> >>>> google.com <http://google.com>. 293 IN A >> >>>> 173.194.42.2 >> >>>> google.com <http://google.com>. 293 IN A >> >>>> 173.194.42.14 >> >>>> google.com <http://google.com>. 293 IN A >> >>>> 173.194.42.7 >> >>>> >> >>>> La pregunta es, funciona como un registro MX? es decir que si mi >> >>>> navegador no logra conectarse a la primer IP, prueba con la >> >>>> segunda, >> >>>> y >> >>>> así? tiene que ser un navegador especial? (como Chrome/Chromium) >> >>>> o >> >>>> esos >> >>>> registros están para otros servicios? >> >>>> >> >>>> Saludos! >> >>>> -- >> >>>> Ariel Camino >> >>>> Lanux - Grupo de usuarios de GNU/Linux de Lanus >> >>>> Visitanos en: http://www.lanux.org.ar >> >>>> >> >>>> Reglas de etiqueta para el posteo de mensajes a la lista: >> >>>> http://www.lanux.org.ar/?page_id=35 >> >>>> >> >>>> Articulos y noticias por rss: >> >>>> http://www.lanux.org.ar/?feed=rss2 >> >>>> >> >>>> Lanux por irc: >> >>>> irc.freenode.net <http://irc.freenode.net> -> #lanux. >> >>>> _______________________________________________ >> >>>> General mailing list >> >>>> [email protected] <mailto:[email protected]> >> >>>> http://listas.lanux.org.ar/cgi-bin/mailman/listinfo/general >> >>>> >> >>>> >> >>>> Vos podés definir varios registros A a un dominio, pero al final se >> >>>> va a >> >>>> elegir uno al azar, no hay fail over porque la conexión la realiza >> >>>> despues de conocer el dominio, como mucho podrías configurar tu >> >>>> server >> >>>> de DNS para que, en caso de caerse un server modifique los registros >> >>>> que >> >>>> devuelve, pero no safás de la cache de los ISP. >> >>>> >> >>>> Igualmente tengo entendido que hay fail over de conexiones dedicadas, >> >>>> no >> >>>> se como funcionaran, pero supongo que en grandes arquitecturas el >> >>>> router que decide a donde apuntan las IPs es el encargado del >> >>>> failover. >> >>>> >> >>>> Tambien podrías poner 2 balanceadores, uno primario y otro de >> >>>> failover y >> >>>> configurarlos con hearbit para que el backup tome el lugar del master >> >>>> en >> >>>> caso de ser necesario. >> >>>> >> >>>> Personalmente te puedo decir que un debian con nginx proxiando es >> >>>> inderribable: >> >>>> >> >>>> exos@Carl-Front-02:~$ uptime >> >>>> 22:50:50 up 258 days, 21:04, 1 user, load average: 0.13, 0.12, >> >>>> 0.09 >> >>>> exos@Carl-Front-02:~$ ps aux | grep nginx >> >>>> root 7333 0.0 0.5 38072 5996 ? Ss Aug27 0:00 >> >>>> nginx: >> >>>> master process /usr/sbin/nginx >> >>>> www-data 22895 0.5 0.8 38072 8328 ? S Dec11 43:09 >> >>>> nginx: >> >>>> worker process >> >>>> www-data 22896 0.5 0.8 38072 8316 ? S Dec11 43:13 >> >>>> nginx: >> >>>> worker process >> >>>> www-data 22897 0.5 0.8 38072 8836 ? R Dec11 43:36 >> >>>> nginx: >> >>>> worker process >> >>>> www-data 22898 0.5 0.8 38072 8572 ? S Dec11 43:24 >> >>>> nginx: >> >>>> worker process >> >>>> exos@Carl-Front-02:~$ netstat -a | grep www | wc -l >> >>>> 709 >> >>>> >> >>>> Y hace poco se tuvo que migrar el otro front y se perdio el uptime, >> >>>> pero >> >>>> tenia mas de 300 dias. El Nginx tiene reiniciadas pero solo para >> >>>> cambios >> >>>> de configuración y actualizaciones. Nunca se cayó. >> >>>> >> >>>> -- >> >>>> El Tio ~ Programador, hacker y filósofo >> >>>> web: http://blog.exodica.com.ar >> >>>> Linked'in: http://www.linkedin.com/in/ogentilezza >> >>>> Twitter: @exos, Indeti.ca: @exos >> >>>> Tels: [+54 11] 638-LINUX (54689) - [+54 9 11] 6133-2442 >> >>>> >> >>>> -----BEGIN GEEK CODE BLOCK----- >> >>>> Version: 3.1 >> >>>> GCS/IT d-- s:++ a- C+++$ UBL+++$ P(-) L+++$ !E--- W+++$ !N !o K-? >> >>>> !w--- >> >>>> !O !M-- V? PS+++@ !PE Y+(++) PGP++ !t--- !5 X++ R(+) tv--? b- DI D-- >> >>>> G >> >>>> e@ h>++ r+++(-) y+++>+++++ >> >>>> ------END GEEK CODE BLOCK------ >> >>> >> >>> Sí igual con caídas no me refería a que se sature el server, sino a >> >>> caídas en conexiones, dado que ningún datacenter te asegura un uptime >> >>> del 100%. Si se podría implementar un sistema de failover a nivel DNS >> >>> como sucede con los registros MX, uno podría contratar varias >> >>> plataformas alrededor del mundo y quedarse un poco más tranquilo. >> >>> >> >>> Salutes! >> >>> -- >> >>> Ariel Camino >> >>> Lanux - Grupo de usuarios de GNU/Linux de Lanus >> >>> Visitanos en: http://www.lanux.org.ar >> >>> >> >>> Reglas de etiqueta para el posteo de mensajes a la lista: >> >>> http://www.lanux.org.ar/?page_id=35 >> >>> >> >>> Articulos y noticias por rss: >> >>> http://www.lanux.org.ar/?feed=rss2 >> >>> >> >>> Lanux por irc: >> >>> irc.freenode.net -> #lanux. >> >>> _______________________________________________ >> >>> General mailing list >> >>> [email protected] >> >>> http://listas.lanux.org.ar/cgi-bin/mailman/listinfo/general >> >> >> >> >> >> Seguramente algo debe haber >> >> >> >> >> >> -- >> >> El Tio ~ Programador, hacker y filósofo >> >> web: http://blog.exodica.com.ar >> >> Linked'in: http://www.linkedin.com/in/ogentilezza >> >> Twitter: @exos, Indeti.ca: @exos >> >> Tels: [+54 11] 638-LINUX (54689) - [+54 9 11] 6133-2442 >> >> >> >> -----BEGIN GEEK CODE BLOCK----- >> >> Version: 3.1 >> >> GCS/IT d-- s:++ a- C+++$ UBL+++$ P(-) L+++$ !E--- W+++$ !N !o K-? !w--- >> >> !O >> >> !M-- V? PS+++@ !PE Y+(++) PGP++ !t--- !5 X++ R(+) tv--? b- DI D-- G e@ >> >> h>++ >> >> r+++(-) y+++>+++++ >> >> ------END GEEK CODE BLOCK------ >> >> >> >> Lanux - Grupo de usuarios de GNU/Linux de Lanus >> >> Visitanos en: http://www.lanux.org.ar >> >> >> >> Reglas de etiqueta para el posteo de mensajes a la lista: >> >> http://www.lanux.org.ar/?page_id=35 >> >> >> >> Articulos y noticias por rss: >> >> http://www.lanux.org.ar/?feed=rss2 >> >> >> >> Lanux por irc: >> >> irc.freenode.net -> #lanux. >> >> _______________________________________________ >> >> General mailing list >> >> [email protected] >> >> http://listas.lanux.org.ar/cgi-bin/mailman/listinfo/general >> >> >> > >> > reviste esto "round robin" >> > >> > >> >> que interesante! >> http://es.wikipedia.org/wiki/Dns_round_robin >> >> Saludos! >> -- >> Ariel Camino >> Lanux - Grupo de usuarios de GNU/Linux de Lanus >> Visitanos en: http://www.lanux.org.ar >> >> Reglas de etiqueta para el posteo de mensajes a la lista: >> http://www.lanux.org.ar/?page_id=35 >> >> Articulos y noticias por rss: >> http://www.lanux.org.ar/?feed=rss2 >> >> Lanux por irc: >> irc.freenode.net -> #lanux. >> _______________________________________________ >> General mailing list >> [email protected] >> http://listas.lanux.org.ar/cgi-bin/mailman/listinfo/general > > > > Lanux - Grupo de usuarios de GNU/Linux de Lanus > Visitanos en: http://www.lanux.org.ar > > Reglas de etiqueta para el posteo de mensajes a la lista: > http://www.lanux.org.ar/?page_id=35 > > Articulos y noticias por rss: > http://www.lanux.org.ar/?feed=rss2 > > Lanux por irc: > irc.freenode.net -> #lanux. > _______________________________________________ > General mailing list > [email protected] > http://listas.lanux.org.ar/cgi-bin/mailman/listinfo/general > Lanux - Grupo de usuarios de GNU/Linux de Lanus Visitanos en: http://www.lanux.org.ar Reglas de etiqueta para el posteo de mensajes a la lista: http://www.lanux.org.ar/?page_id=35 Articulos y noticias por rss: http://www.lanux.org.ar/?feed=rss2 Lanux por irc: irc.freenode.net -> #lanux. _______________________________________________ General mailing list [email protected] http://listas.lanux.org.ar/cgi-bin/mailman/listinfo/general
