¿Por qué los sitios grandes usan múltiples servidores en lugar de un servidor con mejores especificaciones?

Leí que Stack Overflow usa 10 o más servidores para servir el sitio Stack Overflow. Los diferentes servidores tienen diferentes funciones, como proxy inverso, servidor de bases de datos o servidor HTTP.

He visto un poderoso servidor único independiente con estas especificaciones:

• 2 x Xeon E5-2630v2 @ 2.60 GHz, total de 12 núcleos, 24 hilos; 30 MB
• 64 GB ECC Reg. hasta 768 GB DDR3 a 1600 MHz
• 4 x 120 GB Intel 520/530 Series (80k IOPS aleatorios, ~ 550 MB / s)
• HP iLo4 Advanced con puerto de administración Ethernet dedicado.

¿Por qué no usar un solo servidor con especificaciones más altas como 768 GB de RAM, 20 TB + HDD, 4+ x Xeon? ¿Cuáles son los beneficios de usar muchos servidores o los inconvenientes de usar un solo servidor de alta especificación?

Un único servidor potente solo puede actualizarse hasta ahora. Una vez que tenga el servidor más potente disponible, su sitio no puede crecer más sin dividirlo entre servidores o hacerlo más eficiente.

También está el factor de costo. Un solo servidor que es súper poderoso puede costar diez veces más que dos servidores que son la mitad de poderosos. Desea poder comprar su hardware al precio más bajo y no estar bloqueado en un precio más alto porque es lo único que funcionará.

El tiempo de actividad y la fiabilidad también entran en juego. Con dos o más servidores, uno puede fallar o quedar fuera de línea por mantenimiento y el sitio puede mantenerse activo. No puedes hacer eso con un solo servidor.

La mayoría de los sitios web grandes usan balanceadores de carga y múltiples servidores. Solía ​​trabajar para TripAdvisor. Publicaron un gran artículo sobre la arquitectura de TripAdvisor y cómo la hacen altamente escalable con múltiples servidores.

Es posible ejecutar un servicio avanzado en un solo servidor. Un ejemplo que conozco es Mailinator. El autor publicó un artículo sobre la arquitectura de Mailinator . Se enfoca en hacer que su código sea más eficiente en lugar de comprar nuevos servidores. Esto termina siendo una limitación que dicta cómo funciona su servicio. Mantiene el correo solo unas pocas horas antes de que la única máquina lo elimine para dejar espacio para más.

La actualización de un solo servidor se conoce como escalamiento vertical . Agregar más servidores se conoce como escalado horizontal . Para obtener más información sobre este tema, aquí hay algunos artículos que comparan los dos:

• Wikipedia: escala horizontal y vertical
• Pensamientos de IBM sobre la nube: cómo explicar la escala vertical y horizontal en la nube
• Video de Internap: escala vertical vs horizontal

Del Contralmirante Grace Hopper:

Sobre la construcción de computadoras más grandes: "En los días de los pioneros usaban bueyes para jalar con fuerza, y cuando un buey no podía mover un tronco, no intentaban hacer crecer un buey más grande. No deberíamos intentar computadoras más grandes, pero para más sistemas de computadoras ".

fuente

Stephen explica la mayor consideración a tener en cuenta al decidir sobre una arquitectura de sistemas: la compensación en escala vertical y horizontal. Agregaré algunas otras consideraciones:

• Separación de preocupaciones: usted menciona múltiples sistemas radicalmente diferentes: servidores proxy inversos, bases de datos, servidores de contenido, etc. Desde el punto de vista del mantenimiento y la seguridad, es claramente ventajoso mantener estas responsabilidades repartidas en diferentes sistemas para que puedan ejecutar un sistema operativo diferente (versión) si es necesario, se puede actualizar por separado y no afecta a otros servicios cuando se ve comprometido.
• Entrega de contenido: este es el objetivo final de un servidor web y se presta bien a un modelo distribuido. Los sistemas se pueden duplicar y extender geográficamente para minimizar la latencia de las conexiones de larga distancia. También permite la redundancia . Los sitios web grandes usan equilibradores de carga (¡otro conjunto de servidores!) Para permitir la conmutación por error automática para mantener el servicio activo en todo momento.

En realidad, hay una clase de servidor completa que lleva la escala vertical a otro nivel: mainframes. Tienen una variedad de ventajas (velocidad, confiabilidad) y desventajas (costo), pero en general se usan cuando se deben manejar enormes volúmenes de datos a través del procesamiento de Entrada-Salida en lo que llamamos procesamiento de transacciones (piense en compras con tarjeta de crédito, banca , datos electorales y censales). Los bancos, por ejemplo, prestan servicios a servidores web escalados verticalmente, mientras que el back-end terminaría procesando transacciones a través del mainframe.

Curiosamente, compañías como Paypal y Visa se han alejado del mainframe hacia sistemas agrupados de miles de sistemas a escala horizontal. En el mundo digital en rápida evolución, incluso los mainframes están alcanzando el techo de escala horizontal:

"Con todos los requisitos de disponibilidad y rendimiento, no pudimos seguir procesando pagos en mainframes,

Fuente: Adam Banks, en ComputerWorldUK

• Límite de tamaño. Nos gusta pretender que una sola caja con múltiples procesadores, chips de memoria y discos es uniforme. Esto no es del todo cierto, pero es lo suficientemente cierto si sus números no son demasiado grandes. Existen límites técnicos sobre el calor, la energía, la proximidad, etc., lo que significa que siempre habrá un límite práctico sobre cuán grande puede ser un solo servidor.

• Escalabilidad: existe una gran diferencia entre un sistema de servidor único, que usa memoria compartida para IPC y un sistema de servidores múltiples que usa redes o clustering. Sin embargo, la diferencia entre dos servidores y 200 es considerablemente menor: si ha creado un sistema que se puede escalar, puede hacerlo MUCHO más grande antes de que haya un problema ... y si lo tiene, entonces no hay necesidad de un servidor único enorme en primer lugar.

• Resiliencia: un servidor es un lugar en el que un administrador podría "¡Uy!". O hay un problema físico que significa que se interrumpe el servicio a todo el trozo de estaño. (Fuga de agua del centro de datos, alguien choca contra un estante y lo tira, ese tipo de cosas). Se pueden distribuir varios servidores dentro de un centro de datos, o mejor aún, distribuirse geográficamente. Y si ya está distribuyendo su aplicación, escalar en máquinas de tamaño 'mediano' es casi siempre más barato que la misma cantidad de CPU / memoria / IO en una cantidad menor de máquinas más grandes.

• Actualizaciones: si parcheo un servidor, esto puede hacer que un servicio sea inestable, requiera un reinicio o, de lo contrario, demande algún tiempo de inactividad. Si tengo 4 servidores que ejecutan lo mismo, puedo dejar uno fuera de servicio por un tiempo para hacer esto. Y déjelo fuera de servicio si el ciclo de parcheo / actualización sale mal.

Tomemos el problema a pequeña escala. Una pequeña oficina con un servidor que ejecuta correo, ActiveDirectory, archivos compartidos y el sitio web de la empresa.

Los hackers lo golpean y tienes que reiniciar porque IIS está en mal estado. O Exchange necesita una actualización y un reinicio. O Active Directory se corrompió.

Cualquiera de estos problemas aislados de "un servicio está inactivo" afecta a todo el servidor, por lo que cualquier cosa que se comparta en ese servidor los afectará en virtud de tener que reiniciar o cualquier otra cosa.

Una vez que aparece un verdadero experto en TI y ve ese servidor, va a recomendar dividirlos en servidores separados (y tener un servidor controlador de dominio de respaldo).

Es el viejo adagio de "no pongas todos tus huevos en una canasta"

Ahora esa filosofía se aplica a los servidores web. Si tengo un solo servidor web y publico mi aplicación web (el nuevo MyFaceLink.com) y se vuelve realmente popular, tengo nuevos problemas. No puedo eliminar el sitio para realizar tareas de mantenimiento mientras los usuarios están en él. Y si se bloquea o si tengo demasiados usuarios, me manguito. Incluso el servidor único más grande del mundo se verá abrumado por la llegada de mil millones de conversiones FB.

Entonces, el equilibrio de carga entra en juego, por la misma razón de "huevos en la canasta". Distribuya el sitio en 3 servidores, y si uno se cae, los 2 restantes manejan la capacidad. Si necesito hacer parches, solo hago uno a la vez, y nadie se da cuenta.

En el más simple, no se trata del precio del mega servidor o si realmente puede manejar la carga (aunque puede serlo). Se trata de un solo punto de falla. Una vez que la empresa está lo suficientemente ocupada y está disponible las 24 horas del día, los 7 días de la semana, en lugar de 5 usuarios que trabajan de 8 a 5, el tiempo de inactividad no es aceptable. Las interrupciones programadas son más difíciles de programar. Entonces, extiendes la carga.

Si uno intenta que una máquina haga el trabajo de dos, algunas partes de la máquina necesitarán ser más grandes pero funcionar a la misma velocidad, algunas pueden permanecer del mismo tamaño pero necesitarán funcionar más rápido, y algunas necesitarán ser más grandes Y más rápido. La medida en que tiene sentido combinar los roles de máquinas más pequeñas en uno más grande, o dividir los roles de máquinas más grandes en máquinas más pequeñas, depende en gran medida de qué tipo de escala se aplicaría a las partes más caras de las máquinas. Si las cargas de trabajo de demasiadas máquinas se combinan en un enorme coloso, entonces los costos estarán dominados por cosas que tendrían que aumentar y aumentar.más rápido para manejar mayores cargas de trabajo. Incluso si los costos de tales cosas fueran lineales con respecto a la velocidad y el tamaño, duplicar la carga de trabajo duplicaría con creces el costo de una máquina para procesarla. El hecho de que la velocidad aumente más allá de cierto punto da como resultado un aumento de costo (mucho) mayor que el lineal magnifica el efecto.

Realmente no hay un punto fijo donde la practicidad obliga a la subdivisión del trabajo; Dependiendo del tipo de trabajo a realizar, una máquina que combina las cargas de trabajo de dos podría funcionar con menos del doble de memoria, o funcionando a menos del doble de la velocidad. Por otro lado, cuantas más tareas se le asignen a una máquina, mayor será el grado en que los requisitos de memoria y velocidad comienzan a escalar linealmente con la carga de trabajo. Cuanto más va más allá, mayor es el aumento en el costo relativo por cada duplicación de la carga de trabajo.