¿Cuál es la pieza de hardware que se escucha en la dirección IP de Facebook o Wikipedia?


32

Estoy tratando de entender cómo funcionan sitios masivos como Facebook o Wikipedia, para mi curiosidad intelectual. Leí sobre varias técnicas para construir sitios escalables, pero todavía estoy desconcertado sobre un detalle en particular.

La parte que me confunde es que, en última instancia, el DNS asignará todo el dominio a una sola dirección IP, o un puñado de direcciones IP en el caso de DNS de round-robin.

Por ejemplo, wikipedia.org solo tiene un registro DNS tipo A. Por lo tanto, las personas de todo el mundo que visitan Wikipedia deben enviar una solicitud a la única dirección IP especificada en DNS.

¿Cuál es la pieza de hardware que escucha en la dirección IP de un sitio masivo y cómo puede manejar toda la carga proveniente de las solicitudes de usuarios de todo el mundo?

Edición 1: ¡ Gracias por todas las respuestas! Anycast parece una respuesta factible ... ¿Alguien sabe de una manera de verificar si una dirección IP en particular está enrutada de modo alguno, de modo que pueda verificar que este es realmente el truco utilizado en la práctica por sitios grandes?

Edición 2: después de leer más sobre el tema, parece que cualquier difusión normalmente no se usa para contenido web dinámico. Anycast generalmente se usa para UDP (p. Ej., Búsquedas de DNS) o, a veces, para contenido estático.

Una cosa interesante a tener en cuenta es que Facebook usa profile.ak.fbcdn.net para alojar contenido estático como hojas de estilo y bibliotecas javascript. Cada vez que hago ping a este nombre, recibo una respuesta de una dirección IP diferente. Sin embargo, no puedo decir si se trata de un lanzamiento en acción o de una técnica completamente diferente.

Volviendo a mi pregunta original: por lo que puedo decir, incluso un sitio grande tendrá una sola pieza costosa de hardware de equilibrio de carga que escucha en su puñado de direcciones IP públicas.


Grandes preguntas, lástima que la mayoría de la gente no lo entienda. Espero que alguien tenga una respuesta con algunos detalles. Quizás unos 50 millones de dólares en el equilibrio de carga impulsado por la computación cuántica de Cisco.
OliverS

Respuestas:


9

No es necesariamente una pieza de hardware haciendo esto, sino un sistema completo que ha sido diseñado para escalar. Esto no solo abarca el hardware, sino más importante, el diseño de la aplicación, el diseño de la base de datos (relacional o de otro tipo), las redes, el almacenamiento y la forma en que encajan.

Un buen punto de partida para su curiosidad por descubrir cómo algunos de los sitios de gran escala son High Scalability: Start Here y High Scalability en la arquitectura de Wikimedia , Facebook y Twitter como ejemplos.

Con respecto a su pregunta sobre DNS y direcciones IP únicas y round-robin, este tipo de sitios a menudo utilizarán el equilibrio de carga como un método para presentar una sola dirección IP. Esto puede hacerse mediante equilibradores de carga de hardware especializados o mediante software que se ejecuta en servidores de uso general. Las solicitudes entrantes a la IP administrada por el equilibrador de carga se distribuyen a través de una serie de servidores de forma transparente para el usuario final.

Para obtener una buena explicación sobre este tema, incluida una comparación de equilibradores de carga de hardware y software / proxies y cómo se comparan con el round robin de DNS, lea las aplicaciones web de equilibrio de carga .


Gracias Sim. Leí la mayoría de estos artículos antes de hacer mi pregunta, pero no encontré una respuesta concreta. Entonces, ¿realmente hay un solo equilibrador de carga de hardware (o una sola máquina que ejecuta software de equilibrio de carga) que se ve afectado cada vez que alguien ve una página de Wikipedia? O, ¿hay otro truco en alguna parte para evitar el cuello de botella?
Igor Ostrovsky

No estoy seguro de lo que Wikipedia está haciendo ahora, pero este artículo de 2008 habla de ellos usando una serie de servidores de proxy inverso Squid blogs.sun.com/WebScale/entry/scaling_wikipedia_with_lamp_7
Sim

2
También hay direcciones de difusión ilimitada en las que hace ping a una dirección IP, pero se distribuyen (aleatoriamente \ arbitrariamente \ intencionalmente) a uno de un rango de puntos finales "reales". No estoy seguro de si Wikipedia \ Google usa esto, pero estoy bastante seguro de que algunos de los servidores DNS raíz lo hacen. Mis pings a Wikipedia coinciden con los tuyos (y estoy en Irlanda), así que sospecho que podrían estar usando eso.
Helvick

1
Anycast se utiliza en la consulta DNS para obtener la dirección IP más cercana a usted; luego, un equilibrador de carga escucha esa dirección IP y distribuye las solicitudes a los servidores de respaldo.
Andy Shellam

2
Wikipedia también utiliza el backend geoip de pdns para gran parte de su equilibrio de carga. Más información aquí: wikitech.wikimedia.org/view/PowerDNS y aquí: wikitech.wikimedia.org/view/DNS
faultyserver

3

Anycast también se puede usar para conexiones TCP, suponiendo que las conexiones sean de corta duración para que las rutas no cambien durante la vida útil de la conexión. Esta es una buena suposición con las conexiones HTTP (especialmente si Connection: Keep-Alive se mantiene en un corto tiempo de espera o se deshabilita).

Muchos CDN (CacheFly, MaxCDN y probablemente muchos otros) realmente usan anycast para conexiones TCP (HTTP), y no solo DNS. Cuando resuelve un nombre de host en CacheFly, obtiene la misma dirección IP en todo el mundo, simplemente se enruta al clúster CacheFly "más cercano". "Lo más cercano" aquí sería en términos de longitud y métrica de la ruta BGP, que generalmente es una mejor manera de medir la latencia de la red que la simple distancia geográfica.

En el caso de Wikipedia específicamente: http://www.datacenterknowledge.com/archives/2008/06/24/a-look-inside-wikipedias-infrastructure/


3

La forma más fácil de verificar si una dirección IP está usando Anycast es hacer una ruta de seguimiento desde una ubicación diferente. Puede intentar lo siguiente: vaya a traceroute.org, elija una ubicación e intente hacer un traceroute a la dirección IP 8.8.8.8 (DNS público de Google que usa anycast). Debería poder ver ese traceroute desde el servidor en Australia hasta 8.8.8.8 permanecer en Australia.

En lugar de hacer ping, intente buscar el nombre de host: por ejemplo: http://network-tools.com/default.asp?prog=dnsrec&host=profile.ak.fbcdn.net

Verá la lista de direcciones IP detrás de ese nombre. Estas direcciones IP se utilizarán de forma circular cuando haga ping al servidor.



2

Igor, tu pregunta es genial, y como tantas preguntas inocentes, hay muchas, muchas respuestas, todas con diferentes niveles de detalles.

La pieza de hardware es un servidor web. Obviamente ;-)

La pieza de hardware es en realidad un grupo de equilibradores de carga, todos los cuales están configurados para extraer del almacenamiento compartido, por lo que todos están configurados de forma idéntica con material idéntico.

La pieza de hardware es en realidad uno de varios grupos de equilibradores de carga, geográficamente dispersos, y fue dirigido al más cercano a usted, una decisión tomada por el servidor DNS.


1

Google lanzó un poco sobre su arquitectura de hardware local el año pasado y es una buena lectura .


Esta es una lectura interesante, pero no responde a mi pregunta particular. Tengo curiosidad por saber cuál es la pieza de hardware que escucha en las cuatro direcciones IP públicas de Google y distribuye la carga entre los miles de servidores.
Igor Ostrovsky

1

Una sola dirección IP no significa necesariamente un solo servidor: http://en.wikipedia.org/wiki/Anycast


1
Anycast es una configuración difícil de mantener, si tiene alguna sincronización central (como Facebook). Funciona realmente bien, por ejemplo, para servidores DNS, donde las instancias no necesitan mucha comunicación o servidores web con contenido estático.

1
Tienes razón en que una sola IP no significa un solo servidor, pero cualquier difusión se usa en la consulta DNS cuando no te molesta quién responde siempre que recibas una, y por lo tanto solo es útil con el protocolo UDP que Usos de DNS. Con TCP (utilizado en HTTP) debe asegurarse de que el servidor que responde es el que solicitó específicamente.
Andy Shellam

@AndyShellam, Los artículos en.wikipedia.org/wiki/Anycast#Details nanog.org/meetings/nanog37/presentations/matt.levine.pdf parece estar en desacuerdo con usted ...
Pacerier

1

Los sitios más grandes usan varias técnicas diferentes juntas. Todos los sitios web que mencionó tienen varios servidores en casi todos los países. Según la dirección IP del visitante del sitio web, el servidor DNS está devolviendo una dirección IP del clúster que es la más cercana al visitante. Akamai proporciona dicho servicio (haga clic en la imagen de este sitio web para obtener más información).

Esos "grupos" en este centro de datos consisten ahora en varias máquinas diferentes (servidor de base de datos, servidor web, equilibrador de carga, etc.) Dependiendo de lo que esté proporcionando con su sitio web, puede tener algunos servidores para el contenido estático, etc.


1

Los sitios masivos como Facebook o Wikipedia se basan en varias tecnologías diferentes para lograr la escalabilidad.

Una de esas tecnologías es dns. Dns está configurado para equilibrar la carga con round robin. La configuración de dns es lo suficientemente inteligente como para determinar de dónde proviene su solicitud y devolver la dirección del sitio más cercano a usted. Entonces, si hace una excavación, verá varios registros, pero si hace un ping, siempre obtendrá la misma dirección.

En el sitio, la primera pieza de hardware que utiliza es un proxy inverso o un grupo de equilibrador de carga. Los grupos están configurados para que todas las máquinas respondan la misma IP pero devuelvan una nueva IP en el encabezado de la sesión. Todas las solicitudes adicionales pasarán por el mismo nodo.

Los equilibradores de carga empleados para sitios grandes no son grandes equipos caros, son servidores básicos que ejecutan LVS. http://www.linuxvirtualserver.org/


Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.