Voy a responder primero a la parte de la conexión persistente porque es más fácil. Todas las buenas soluciones de equilibrio de carga de red (incluido el servicio NLB de Microsoft integrado en Windows Server, pero también los dispositivos de equilibrio de carga como F5 BigIP) tienen la capacidad de "pegar" las conexiones individuales de los clientes a nodos de clúster específicos durante la conexión. En la NLB de Microsoft esto se llama "Single Affinity", mientras que otros equilibradores de carga lo llaman "Sesiones adhesivas". A veces hay advertencias (por ejemplo, la NLB de Microsoft romperá las conexiones si se agrega un nuevo miembro al clúster, aunque una sola conexión nunca se mueve de un host a otro).
re: variables globales, son la ruina de los sistemas de carga equilibrada. La mayoría de los diseñadores de aplicaciones con equilibrio de carga harán un lote de re-arquitectura para minimizar la dependencia del estado compartido ya que impide la escalabilidad y la disponibilidad de una aplicación de equilibrio de carga. La mayoría de estos enfoques se reducen a una estrategia de dos pasos: primero, mover el estado compartido a una ubicación de alta disponibilidad, y segundo, cambiar la aplicación para minimizar el número de veces que se debe acceder al estado compartido.
La mayoría de las aplicaciones en clúster que he visto almacenarán el estado compartido (incluso el estado volátil compartido, como las variables globales) en un RDBMS. Esto es principalmente por conveniencia. También puede usar un in-memory database para un rendimiento máximo. Pero la simplicidad de usar un RDBMS para todo el estado compartido (transitorio y duradero), más el uso de herramientas de bases de datos existentes para alta disponibilidad, tiende a funcionar para muchos servicios. El rendimiento de un RDBMS es, por supuesto, órdenes de magnitud más lento que las variables globales en la memoria, pero si el estado compartido es pequeño, leerá de todos modos el caché del RDBMS, y si está haciendo una red hop para leer/escribir los datos la diferencia es relativamente menor. También puede marcar una gran diferencia optimizando el esquema de su base de datos para una lectura/escritura rápida, por ejemplo, eliminando índices innecesarios y usando NOLOCK para todas las consultas leídas donde no se requiere exactitud exacta de hasta milisegundos.
No digo que un RDBMS siempre será la mejor solución para el estado compartido, solo que mejorar los tiempos de acceso al estado compartido no suele ser la forma en que las aplicaciones con equilibrio de carga obtienen su rendimiento, sino que obtienen rendimiento por eliminando la necesidad de acceder de forma síncrona (y, especialmente, escribir) estado compartido en cada solicitud. Esa es la segunda cosa que anoté más arriba: cambiar su aplicación para reducir la dependencia del estado compartido.
Por ejemplo, para simples "contadores" y métricas similares, las aplicaciones a menudo pondrán en cola sus actualizaciones y tendrán un solo hilo a cargo de actualizar el estado compartido de forma asíncrona desde la cola.
Para casos más complejos, las aplicaciones pueden surgir de Concurrencia pesimista (verificando que un recurso esté disponible de antemano) en Optimistic Concurrency (suponiendo que esté disponible y luego anular el trabajo si terminó, por ejemplo, vendiendo el mismo artículo a dos clientes diferentes!).
Net-net, en situaciones de equilibrio de carga, las soluciones de fuerza bruta a menudo no funcionan tan bien como pensar creativamente acerca de su dependencia en estado compartido y encontrar formas ingeniosas para evitar tener que esperar para leer o escribir sincrónicamente estado en cada solicitud.
No me molestaría en utilizar MSCS (Microsoft Cluster Service) en su escenario. MSCS es una solución de conmutación por error, lo que significa que es buena para mantener una aplicación de un servidor altamente disponible incluso si uno de los nodos del clúster falla, pero no obtendrá la escalabilidad y simplicidad que obtendrá de un verdadero servicio de equilibrio de carga. Sospecho que MSCS tiene formas de compartir estado (en un disco compartido) pero requieren configurar un clúster de MSCS que implique la configuración de failover, el uso de un disco compartido y otra complejidad que no es apropiada para la mayoría de las aplicaciones con equilibrio de carga. Es mejor utilizar una base de datos o una solución en memoria especializada para almacenar su estado compartido.
Gracias por el enlace Apache! – Jaywalker
No hay problema Todavía está en desarrollo, pero escuché que es bastante robusto. – orokusaki