Los equilibradores de carga generalmente se incluirán en una de las siguientes categorías.
1. Balanceadores de carga a nivel de aplicación: operan en la capa de aplicación. Son mucho más lentos que los equilibradores de carga que operan en las capas inferiores
2. Balanceadores de carga L3: operan a nivel IP. Son más rápidos que los equilibradores de carga de nivel de aplicación.
3. Balanceadores de carga L2: operan a nivel TCP. Tienen menos gastos generales y son realmente rápidos.
Su afirmación sobre los equilibradores de carga que tienen un límite es absolutamente cierta. El límite depende de cómo se implemente el equilibrador de carga. Los equilibradores de carga de la capa de aplicación generalmente tienen un límite máximo de conexión más bajo porque operan a un nivel más alto y, por lo tanto, tienen una sobrecarga más alta. Los equilibradores de carga de nivel inferior tienen un límite máximo de conexión más alto porque tienen una sobrecarga menor; por ejemplo, no tienen que mantener sesiones TCP.
Otra pregunta que tenía era sobre el equilibrio de carga jerárquico. Sí, algunas compañías lo hacen. De hecho, cuando solía trabajar en Yahoo !, hicimos un equilibrio de carga jerárquico.
- Cómo vincular una imagen al control deslizante de revolución en lugar de tomarla de la biblioteca de medios de WP
- ¿Cuál es el mejor flujo de desarrollo para crear aplicaciones de una sola página?
- Cómo guardar formularios usando transacciones de bases de datos en el marco de Yii
- ¿Qué startups usan Meteor en producción?
- ¿Necesito CPU de gama alta para diseño web?
El límite máximo de conexión de los equilibradores de carga depende totalmente de cómo se implemente la administración de la conexión y en qué modo se esté ejecutando el equilibrador de carga. Mire el video Los modos del equilibrio de carga del servidor (# 2) para obtener más información sobre los diferentes modos de equilibrio de carga.
EDITAR: Dado que la persona que hizo esta pregunta todavía quería más aclaraciones, intentaré explicar las cosas con un ejemplo a continuación.
Digamos que tengo un sitio web y, por simplicidad, consideremos que solo sirve páginas estáticas. Inicialmente, comienzo con un solo servidor. Digamos que la capacidad de este servidor (hablaré solo en términos de conexiones máximas que el servidor puede manejar) es X conexiones por segundo. Después de unos días de lanzamiento, mi sitio se vuelve viral y estoy bastante seguro de que alcanzaré el número X muy pronto. Lo que decido hacer es agregar otro servidor que también pueda manejar X número de conexiones. Ahora, tengo el doble de capacidad y ahora puedo distribuir la carga. Me doy cuenta de que en los próximos meses, mi sitio web recibirá MUCHO tráfico, así que compro un equilibrador de carga de hardware que puede admitir conexiones máximas Z (donde Z es MUCHO mayor que X) por segundo. Después de un par de meses, alcancé el límite de 2X muy fácilmente y agregué más y más servidores detrás del equilibrador de carga. Todo esto funciona muy bien para mí y pronto me doy cuenta de que ahora estamos cerca de alcanzar las conexiones Z por segundo. Para que mi sitio tome tanto tráfico, decido que puedo agregar más servidores pero necesito un balanceador de carga más. Compro uno más, agrego más servidores detrás de él. Así que ahora tengo 2 equilibradores de carga y tengo que hacer que ambos vivan, ¿qué hacer? Una opción es utilizar el equilibrio de carga basado en DNS. Puedo asociar el nombre de dominio con los equilibradores de carga y el servidor DNS enrutará las solicitudes de forma circular. Por supuesto, los servidores DNS deberían ser capaces de manejar la carga (solicitudes) que ingresan. También se puede usar un grupo de equilibradores de carga basados en software (no estoy seguro si se puede lograr con equilibradores de carga de hardware).
Se ha investigado mucho sobre cómo hacer un equilibrio de carga jerárquico (busque en Google el equilibrio de carga jerárquico), pero si solo desea escalar sitios web, existen otras formas. Puede dividir su sitio web en ciertos componentes como: activos (javascript, archivos css, imágenes) y contenido (las páginas html reales que contienen activos y contenido). Puede alojar los activos detrás de un conjunto separado de servidores que tienen un equilibrio de carga mientras que el contenido se puede alojar detrás de un conjunto separado de servidores. Efectivamente, ha distribuido el tráfico en silos y, por lo tanto, aún puede escalar su sitio web.
