Protocolos/algoritmos Heartbeat o mejores prácticas

Question

Recientemente he agregado algunas capacidades de equilibrio de carga a una pieza de software que escribí. Es una aplicación en red que hace algunos crujidos de datos en función de la entrada proveniente de una base de datos SQL. Debido a que la compresión puede ser bastante intensa, he agregado la capacidad de tener varias instancias de esta aplicación ejecutándose en diferentes servidores para dividir la carga, pero como ahora el balanceo de carga es un acto manual. Un usuario debe especificar qué instancias toman qué porción del dominio de entrada.

Me gustaría llevar eso al siguiente nivel y programar las instancias para negociar automáticamente la inmersión de los datos de entrada y reconocer si uno de ellos "desaparece" (se ha bloqueado o se ha apagado) para que el las instancias restantes pueden asumir la carga de trabajo de la instancia fallida.

Para implementar esto estoy considerando usar un protocolo de latido simple entre las instancias para determinar quién está conectado y quién no y, aunque esto no es demasiado complicado, quisiera saber si hay alguna red establecida de latidos protocolos (basados ​​en UDP, TCP o ambos).

Obviamente, esto sucede mucho en el mundo de las redes con tecnologías de clustering, fail-over y alta disponibilidad, así que supongo que al final me gustaría saber si tal vez haya protocolos o algoritmos establecidos de los que deba tener conocimiento de o implementar.

EDITAR

Parece, sobre la base de las respuestas, que, o bien porque no se han establecido protocolos de latido del corazón o que nadie sabe acerca de ellos (lo que implica que no están tan bien establecidas después de todo) en cuyo caso voy a hacer mi propia versión.

Si bien ninguna de las respuestas ofrecía lo que estaba buscando específicamente, voy a votar por Matt Davis's answer ya que era la más cercana y señaló que era una buena idea usar la multidifusión.

Gracias a todos por su tiempo ~

Answer 1

Distribued Interactive Simulation (DIS), que se define en IEEE El estándar 1278, utiliza un latido del corazón predeterminado de 5 segundos mediante transmisión UDP. Un latido cardíaco 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 usa un concepto que se conoce como navegación a estima para proporcionar latidos de frecuencia más alta cuando la posición real, por ejemplo, está fuera de un umbral dado de su posición pronosticada.

En su caso, un Estado PDU DIS Entidad sería una exageración. Solo lo menciono para tomar nota del hecho de que los latidos del corazón 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, una invención sin conexión, de modo que UDP (sin conexión) es más relevante aquí que TCP (orientado a la conexión).

Lo que hay que tener en cuenta acerca de las difusiones UDP es que un mensaje de difusión se limita al broadcast domain. 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 difusió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 difusión, siempre que el valor de tiempo de vida (TTL) sea lo suficientemente alto. También es un enfoque más automatizado que la unidifusión dirigida, que requeriría que el remitente supiera la dirección IP del receptor para enviar el mensaje.

Answer 2

Broadcast un latido cada t usando UDP; si no ha tenido noticias de una máquina en más de k * t, entonces se asume que está inactivo. Tenga cuidado de que el ancho de banda agregado no sea un gasto de recursos. Puede usar direcciones de difusión IP o mantener una lista de direcciones IP específicas para las que está trabajando.

Asegúrese de que el latido incluye un "recuento de reinicio", así como también "ID de máquina" para que sepa que el estado del servidor anterior no existe.

Recomendaría usar MapReduce si corresponde. Me ahorraría mucho trabajo.

Answer 3

No estoy seguro de que esto responda la pregunta, pero podría interesarle la forma en que la agrupación de servidores Weblogic funciona bajo el capó. Del libro Mastering BEA WebLogic Server:

[...] El agrupamiento del servidor WebLogic proporciona un acoplamiento flexible de los servidores en el clúster. 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 reciba. Cada servidor del clúster mantiene su propia lista de otros servidores en el clúster a través de mensajes de latido periódicos. Cada 10 segundos, cada servidor envía un mensaje de latido a los otros servidores del clúster para informarles que todavía está activo. Los mensajes Heartbeat 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 otros servidores y los usa para mantener su lista de miembros del clúster actual. Si un servidor deja de recibir tres mensajes de latido en una fila de otro servidor, quita ese servidor de su lista de miembros hasta que recibe otro mensaje de latido de ese servidor. Esta tecnología de heartbeat permite que los servidores se agreguen y eliminen dinámicamente del clúster sin afectar las configuraciones de los servidores existentes.

Answer 4

Los conmutadores de contenido de Cisco son una solución de hardware para este problema. Implementan una dirección IP virtual como 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 sigan ejecutándose (lo que el software del switch llama "keepalive", aunque esto no mantiene vivo al servidor). El conmutador 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 round-robin o balance de carga definido por el usuario.

Estos interruptores de venta al por menor en el rango de $ 3-10K, aunque mi socio de negocios recogió uno en eBay por cerca de $ 300 hace un año. Si puede pagar uno, representan una solución de hardware comprobada para la cuestión de cómo distribuir un servicio de manera transparente en varios servidores. Redhat incluye una configuración de puerto integrada para que pueda implementar su propio conmutador de Cisco utilizando una caja RedHat barata. Google para "dirección IP virtual" y "enrutador de contenido Cisco" para obtener más información.

Answer 5

Además de intentar equilibradores de carga de hardware, también puede probar una aplicación de software de equilibrio de carga de código abierto libre como HAProxy, disponible para Linux y BSD.