Estamos planeando equilibrar la carga de 10 servidores web .NET 3.5. Estamos utilizando el servidor de estado de sesión SQL 2008 para la gestión de sesiones.
¿Qué necesitamos para equilibrar la carga de los servidores web .NET?
Cosas que hemos identificado hasta ahora:
- Los contenidos web deberán ser los mismos.
- El servidor del estado de la sesión deberá apuntar al mismo SQL 2008 para obtener información sobre el estado de la sesión.
- La clave de la máquina debe ser la misma en el archivo web.config.
Respuesta1
Si realmente está pasando de un entorno de un solo servidor a un clúster de 10 con carga equilibrada, eso me activa las alarmas al instante. Tengo un montón de preguntas que espero que ya hayas resuelto, pero las señalaré de todos modos y luego brindaré algunas consideraciones genéricas.
¿Cómo llegaste al número 10? ¿Por qué no escala a 2 o 3 y agrega más según sea necesario?
¿Por qué vas a equilibrar la carga en primer lugar? Por ejemplo, ¿opta por una carga alta, una alta disponibilidad o ambas? ¿Existe una necesidad inmediata o es una necesidad predictiva?
Si ahora está bajo carga e intenta escalar para resolverlo, una gran pregunta que le haría es si realmente ha identificado el cuello de botella. Mencionas que estás usando .NET y SQL para el estado de la sesión, por lo que supongo que también estás trabajando con una aplicación respaldada por SQL. ¿También estás equilibrando el servidor SQL? ¿Puede el servidor SQL manejar 10 veces las conexiones que tiene ahora?
Si busca disponibilidad, ¿ha considerado todos los demás puntos de falla? ¿Tiene redundancia en su balanceador de carga? ¿Tiene redundancia en su(s) servidor(es) de base de datos? ¿Tiene redundancia en su enlace ascendente de Internet (considere todos los puntos: cable único, interruptor único, etc.)? En cuanto a disponibilidad, estará tan seguro como su eslabón más débil. No importa si tiene 10 o incluso 100 servidores web front-end, si solo tiene un servidor de base de datos y este deja de funcionar.
Muchas veces su cuello de botella será su servidor de base de datos. Si ese es el caso, no importa cuántas interfaces tengas.
Si está utilizando SSL, hay dos modos típicos en los que normalmente operan los balanceadores de carga, que afectan el funcionamiento de SSL:
- Capa 4: este es el nivel TCP. SSL lo maneja cada servidor y, por lo tanto, el certificado SSL debe instalarse en cada servidor.
- Capa 7: este es el nivel de aplicación, también llamado proxy inverso. El equilibrador de carga maneja la sesión HTTP y realiza una segunda conexión al servidor de aplicaciones. En este modo, el certificado SSL se instala solo en el balanceador y la conexión a los servidores de aplicaciones suele ser HTTP. Esto a veces se denomina "descarga SSL" y suele ser útil si su balanceador de carga es potente y no desea que su servidor de aplicaciones maneje la sobrecarga de cifrado de SSL (por ejemplo, su aplicación requiere un uso intensivo de la CPU).
Asegúrese de que su balanceador esté configurado para sacar los servidores de su rotación cuando dejen de funcionar y pruebe esta funcionalidad. Debería poder desactivar servidores sin que esto afecte al resto de los servidores. Tenga en cuenta las comprobaciones de PING, HTTP y tiempo de respuesta. (Hacer ping no significa que HTTP esté respondiendo)
Pruebe la carga de su entorno. Es posible que no pueda funcionar al máximo, pero debería poder cargar al menos un par de servidores (con solo esos dos en el balanceador).
Ejecute un entorno de prueba. Puede que no sean 10 servidores, pero deberían ser suficientes para replicar el sistema de producción para las pruebas de implementación.
Tenga un script de implementación automatizado y sea muy estricto con la administración de fuentes y la administración de configuración. Idealmente, esto significa que TODO (incluidos los archivos de configuración) está en un sistema de control de fuente y que tiene compilaciones automatizadas para crear todo hasta su instalador/script.
Obtenga una herramienta que monitoree tanto su sitio externo como todos los servidores internos. Si un servidor muere, nada cambia realmente desde la perspectiva del mundo exterior, pero de todos modos querrás saberlo y repararlo. Si comienza a tener problemas con el rendimiento o la disponibilidad, lo que no querrá encontrar es que 3 servidores hayan estado inactivos durante un mes y el resto esté luchando con la carga adicional.