sockets - tls - Protocolos de latido del corazón/algoritmos o mejores prácticas
que es tls en informatica (5)
Además de probar los equilibradores de carga de hardware, también puede probar una aplicación de software de equilibrio de carga de código abierto, como HAProxy , disponible para Linux y los BSD.
Recientemente, he agregado algunas capacidades de equilibrio de carga a un software que escribí. Es una aplicación en red que realiza algunos procesos de procesamiento de datos en función de la información proveniente de una base de datos SQL. Dado que el procesamiento puede ser bastante intenso, he agregado la capacidad de tener varias instancias de esta aplicación ejecutándose en diferentes servidores para dividir la carga, pero como está ahora, el equilibrio de carga es un acto manual. Un usuario debe especificar qué instancias toman qué parte del dominio de entrada.
Me gustaría llevar eso al siguiente nivel y programar las instancias para negociar automáticamente el salto de los datos de entrada y reconocer si uno de ellos "desaparece" (se estrelló o se apagó) para que las instancias restantes puedan tomar en la carga de trabajo de la instancia fallida.
Para implementar esto, estoy considerando usar un protocolo simple de latido entre las instancias para determinar quién está en línea y quién no, y aunque esto no es muy complicado, me gustaría saber si existen protocolos de red de latidos establecidos (basados en UDP, TCP o ambos).
Obviamente, esto sucede mucho en el mundo de las redes con tecnologías de clúster, conmutación por error y alta disponibilidad, por lo que supongo que al final me gustaría saber si hay protocolos o algoritmos establecidos que debería conocer o implementar.
EDITAR
Parece, según las respuestas, que o bien no hay protocolos de latidos del corazón bien establecidos o que nadie los conoce (lo que implicaría que no están tan bien establecidos después de todo), en cuyo caso simplemente voy a rodar mío.
Si bien ninguna de las respuestas ofrecía lo que buscaba específicamente, votaré por la respuesta de Matt Davis, ya que era la más cercana y él señaló una buena idea para usar la multidifusión.
Gracias a todos por su tiempo ~
Los conmutadores de contenido de Cisco son una solución de hardware para este problema. Implementan una dirección IP virtual como una interfaz para múltiples servidores reales, cuyas direcciones IP reales son conocidas por el conmutador. El conmutador envía periódicamente solicitudes HTTP HEAD a los servidores web para verificar que aún se estén ejecutando (lo que el software del conmutador denomina "keepalive", aunque esto no mantiene vivo al servidor). El switch de Cisco acepta el tráfico en la IP virtual y lo reenvía a los servidores web reales, utilizando el equilibrio de carga configurable, como el round-robin, o el equilibrio de carga definido por el usuario.
Estos interruptores se venden al por menor en el rango de $ 3-10K, aunque mi socio comercial lo compró en eBay por aproximadamente $ 300 hace un año. Si puede pagar uno, representan una solución de hardware comprobada para la pregunta de cómo hacer que un servicio se distribuya de manera transparente en varios servidores. Redhat incluye una configuración de puerto incorporada para que pueda implementar su propio conmutador Cisco utilizando una caja RedHat barata. Google para "dirección IP virtual" y "enrutador de contenido de Cisco" para obtener más información.
No estoy seguro de que esto responda a la pregunta, pero podría interesarle la forma en que el clúster de Weblogic Server funciona bajo el capó. Del libro Mastering BEA WebLogic Server :
[...] La agrupación de WebLogic Server proporciona un acoplamiento suelto de los servidores en la agrupación. Cada servidor del clúster es independiente y no depende de ningún otro servidor para ninguna operación fundamental. Incluso si se pierde el contacto con cualquier otro servidor, cada servidor continuará ejecutándose y podrá procesar las solicitudes que recibe. Cada servidor en el clúster mantiene su propia lista de otros servidores en el clúster a través de mensajes periódicos de latidos. Cada 10 segundos, cada servidor envía un mensaje de latido a los otros servidores del clúster para avisar que aún está vivo. Los mensajes de latido se envían utilizando la tecnología de multidifusión IP integrada en la JVM, lo que hace que este mecanismo sea eficiente y escalable a medida que aumenta la cantidad de servidores en el clúster. Cada servidor recibe estos mensajes de latido de otros servidores y los usa para mantener su lista actual de miembros del clúster. Si un servidor pierde la recepción de tres mensajes de latido en una fila de cualquier otro servidor, saca ese servidor de su lista de miembros hasta que reciba otro mensaje de latido de ese servidor. Esta tecnología de latido permite que los servidores se agreguen dinámicamente y se eliminen del clúster sin afectar las configuraciones de los servidores existentes.
Transmita un latido del corazón cada t usando UDP; Si no ha escuchado de una máquina en más de k * t, se supone que está caído. Tenga cuidado de que el ancho de banda agregado que se utiliza no sea una pérdida de recursos. Puede usar direcciones de transmisión IP o mantener una lista de IP específicas para las que está trabajando.
Asegúrese de que el latido del corazón incluya un "recuento de reinicio" y una "ID de máquina" para que sepa que el estado del servidor anterior no está disponible.
Recomiendo usar MapReduce si cabe. Se ahorraría mucho trabajo.
La simulación interactiva distribuida (DIS), que se define en la IEEE 1278, utiliza un latido predeterminado de 5 segundos a través de la transmisión UDP. Un latido DIS es esencialmente una PDU de estado de entidad, que define completamente el estado, incluida la posición, de la entidad dada. Debido a su aplicación dentro de la comunidad de simulación, DIS también utiliza un concepto denominado cálculo de cuentas para proporcionar latidos cardíacos de mayor frecuencia cuando la posición real, por ejemplo, está fuera de un umbral dado de su posición predicha.
En su caso, una PDU de estado de entidad DIS sería una exageración. Solo lo menciono para tomar nota del hecho de que los latidos pueden variar en frecuencia dependiendo de las circunstancias. No sé si necesitaría algo como esto para la aplicación que describió, pero nunca se sabe.
Para los latidos del corazón, use UDP, no TCP. Un latido del corazón es, por naturaleza, un dispositivo sin conexión, por lo que dice que el UDP (sin conexión) es más relevante aquí que el TCP (orientado a la conexión).
Lo que hay que tener en cuenta acerca de las transmisiones UDP es que un mensaje de difusión está limitado al dominio de difusión . En resumen, si tiene computadoras separadas por un dispositivo de capa 3, por ejemplo, un enrutador, las transmisiones no funcionarán porque el enrutador no transmitirá mensajes de transmisión de un dominio de transmisión a otro. En este caso, recomendaría el uso de multidifusión, ya que abarcará los dominios de transmisión, siempre que el valor de tiempo de vida (TTL) se establezca lo suficientemente alto. También es un enfoque más automatizado que el unicast dirigido, que requeriría que el remitente conozca la dirección IP del receptor para enviar el mensaje.