Perdón por una pregunta de tan alto nivel. Entiendo los conceptos básicos del equilibrio de carga del servidor, pero el concepto de administrar 30.000 servidores me resulta un poco extraño. ¿Es realmente el mismo concepto de equilibrar 2 o 3 servidores ampliados 10.000 veces?
¿Cómo se relaciona esto con cosas como memcached, sql/mysql, motores de búsqueda, etc.?
¿Es un sistema jerárquico de tener servidores 'controladores' y servidores esclavos que entregan los datos en función de esto? ¿Cómo se maneja la redundancia?
Gracias por cualquier información o dirección a un artículo sobre el tema.
EDITARGracias por las respuestas chicos. Mi publicación se cerró, pero renové el título, espero que se vuelva a abrir ya que encuentro fascinante el proceso de resolución de problemas involucrado con estas soluciones de datos de nivel súper alto, y actualmente estoy creando una API que requerirá una carga básica. equilibrio, de ahí la pregunta.
Respuesta1
La mayor parte del software que Google utiliza en sus servidores se desarrolló internamente. Para disminuir los efectos de fallas inevitables del hardware, el software está diseñado para ser tolerante a fallas.
Fuente:Plataforma de Google
Después de leer el artículo, supongo que es el mismo concepto que equilibrar la carga entre unos pocos servidores ampliados hasta más de 1000 servidores mediante el uso de una pila de software interna desarrollada sobre Linux. p.ejSGF(Sistema de archivos de Google),Mesa grande- Sistema de almacenamiento estructurado basado en GFS
EsteEl enlace describe cómo equilibran la carga de la red.
Ellos usanInterruptores de equilibrio de cargapara distribuir la carga. Todas las solicitudes del sitio web llegan a una máquina que luego pasa la solicitud a uno de los servidores disponibles. El conmutador puede averiguar en los servidores cuál está menos cargado, por lo que todos realizan la misma cantidad de trabajo.
Topología de red de Googlees el siguiente:
Cuando una computadora cliente intenta conectarse a Google, varios servidores DNS resuelven www.google.com en múltiples direcciones IP mediante la política Round Robin. Además, esto actúa como el primer nivel de equilibrio de carga y dirige al cliente a diferentes clústeres de Google. Un clúster de Google tiene miles de servidores y una vez que el cliente se ha conectado al servidor, se realiza un equilibrio de carga adicional para enviar las consultas al servidor web menos cargado.
Respuesta2
La gran parte aquí es que si el software no está diseñado para escalar, ¿cómo puede hacerlo? Por ejemplo, una de las mayores restricciones de Facebook en este momento es su dependencia de MySQL; han podido evitar el problema arrojándole más y más máquinas, perosu propio ingeniero lo llama "un destino peor que la muerte".
Por lo general, necesitará poder equilibrar la carga de las solicitudes, y muchos proyectos, de código abierto o de otro tipo, están diseñados. Pero esto conlleva gastos generales, que incluyen registros de escritura, escrituras retrasadas y arquitecturas "eventualmente consistentes". En otras palabras, escalar no es barato.
Por lo tanto, cosas como los servidores web, que sirven contenido estático, se pueden paralelizar fácilmente. Memcached y otros sistemas de almacenamiento en caché se equilibran la carga fácilmente. Pero, ¿cómo se cambian los puntos únicos de falla? ¿Cómo se escala su base de datos relacional única y grande? ¿Qué pasa con los almacenes de archivos? En esencia, se trata de toda una rama de la investigación... no algo que pueda responderse con una sola pregunta.
Respuesta3
Creo que los mismos conceptos deberían ser los mismos y el punto crítico es cómo distribuye la carga y los datos entre los recursos disponibles y cómo ubica sus datos.
Una forma es la distribución geográfica de los servidores. Cada usuario será dirigido al servidor más cercano.
Se puede utilizar un servicio similar a un registro para buscar los datos solicitados.
Piense en la implementación del servicio DNS. Tiene una base de datos distribuida muy grande. Los nodos raíz dirigen a los usuarios a otros nodos de nivel inferior y así sucesivamente hasta llegar al nodo responsable que puede responder a su consulta.