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
