Protocolos / algoritmos de latidos 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 realiza un procesamiento de datos basado en la entrada proveniente de una base de datos SQL. Debido a que el procesamiento puede ser bastante intenso, agregué la capacidad de tener múltiples instancias de esta aplicación ejecutándose en diferentes servidores para dividir la carga, pero como lo es ahora, el equilibrio 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 el salto de los datos de entrada y reconocer si uno de ellos "desaparece". (se ha bloqueado o se ha apagado) para que las instancias restantes puedan asumir la carga de trabajo de la instancia fallida.

Para implementar esto, estoy considerando usar un protocolo simple de latidos entre las instancias para determinar quién está en línea y quién no, y si bien esto no es terriblemente complicado, me gustaría saber si existen protocolos de red de latidos establecidos. (basado 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, así que al final me gustaría saber si tal vez hay algún protocolo o algoritmo establecido que debería conocer. o implementar.

EDIT

Parece, según las respuestas, que no existen protocolos bien establecidos de latidos del corazón o que nadie los conoce (lo que implicaría que no están tan bien establecidos después de todo), en cuyo caso solo estoy voy a rodar el mío.

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

Gracias a todos por su tiempo ~

Answer 1

Simulación interactiva distribuida (DIS), que se define en IEEE Standard 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 conocido como cómputo muerto 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 prevista.

En su caso, una PDU de estado de entidad DIS sería exagerada. Solo lo menciono para tomar nota del hecho de que los latidos pueden variar en frecuencia dependiendo de las circunstancias. No sé si necesitarías algo como esto para la aplicación que describiste, pero nunca se sabe.

Para los latidos, use UDP, no TCP. Un latido es, por naturaleza, una invención sin conexión, por lo que resulta que UDP (sin conexión) es más relevante aquí que TCP (orientado a la conexión).

Lo que hay que tener en cuenta sobre las transmisiones UDP es que un mensaje de difusión se limita al dominio de difusión . En resumen, si tiene computadoras que están 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 usar la multidifusión, ya que abarcará los dominios de difusión, siempre que el valor de tiempo de vida (TTL) esté configurado lo suficientemente alto. También es un enfoque más automatizado que la unidifusión dirigida, que requeriría que el remitente conozca la dirección IP del receptor para enviar el mensaje.

Answer 2

Transmite un latido cada t usando UDP; Si no ha tenido noticias de una máquina en más de k * t, entonces se supone que está abajo. Tenga cuidado de que el ancho de banda agregado utilizado no sea una pérdida de recursos. Puede usar direcciones de difusión IP o mantener una lista de IP específicas para las que está trabajando.

Asegúrese de que los latidos del corazón incluyan un "recuento de reinicio" así como '' ID de máquina '' para que sepa que el estado del servidor anterior no está presente.

Recomiendo usar MapReduce si cabe. Ahorraría mucho trabajo.

Answer 3

No estoy seguro de que esto responda la pregunta, pero es posible que le interese la forma en que el clúster de Weblogic Server funciona bajo el capó. Del libro Mastering BEA WebLogic Server :

  

[...] El agrupamiento de WebLogic Server proporciona un acoplamiento flexible de los servidores en el cluster. Cada servidor en el 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 en el clúster para informarles que aún está vivo. Los mensajes de 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 el número 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 no recibe tres mensajes de latido seguidos de cualquier otro servidor, saca ese servidor de su lista de miembros hasta que recibe 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 los servidores existentes & # 8217; configuraciones.

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 de HEAD HTTP a los servidores web, para verificar que aún se estén ejecutando (lo que el software del conmutador llama "keepalive", aunque esto no mantiene vivo al servidor). El conmutador 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 la operación por turnos 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 compró uno en eBay por alrededor de $ 300 hace un año. Si puede permitirse uno, representan una solución de hardware probada para la cuestión de cómo hacer que un servicio se extienda de manera transparente a través de múltiples servidores. Redhat incluye una configuración de puerto incorporada para que pueda implementar su propio conmutador Cisco utilizando una caja barata de RedHat. Google para " dirección IP virtual " y "enrutador de contenido de Cisco" para más información.

Answer 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.