Protocolli heartbeat/Algoritmi o buone pratiche

Question

Recentemente ho aggiunto alcune funzionalità di bilanciamento del carico a un software che ho scritto. Si tratta di un'applicazione in rete che esegue alcuni scricchiolii di dati basati su input provenienti da un database SQL. Dato che il crunch può essere piuttosto intenso, ho aggiunto la possibilità di avere più istanze di questa applicazione in esecuzione su server diversi per suddividere il carico, ma poiché ora il bilanciamento del carico è un atto manuale. Un utente deve specificare quali istanze prendono quale parte del dominio di input.

Vorrei portarlo al livello successivo e programmare le istanze per negoziare automaticamente l'immersione dei dati di input e per riconoscere se uno di essi "scompare" (si è arrestato o è stato spento) in modo che le istanze rimanenti possono assumere il carico di lavoro dell'istanza non riuscita.

Per implementare questo obiettivo sto prendendo in considerazione l'utilizzo di un semplice protocollo heartbeat tra le istanze per determinare chi è online e chi no e mentre questo non è molto complicato vorrei sapere se ci sono network di heartbeat stabiliti protocolli (basati su UDP, TCP o entrambi).

Ovviamente questo accade molto nel mondo di networking con tecnologie di clustering, failover e alta disponibilità quindi suppongo che alla fine mi piacerebbe sapere se forse ci sono protocolli o algoritmi stabiliti che dovrei essere a conoscenza di o implementare.

EDIT

Sembra, sulla base delle risposte, che O non ci sono ben stabiliti protocolli battito cardiaco o che nessuno sa su di loro (il che implica che essi non sono così ben consolidata, dopo tutto) nel qual caso sto andando a rotolare il mio.

Mentre nessuna delle risposte ha offerto ciò che stavo cercando in particolare, ho intenzione di votare per Matt Davis's answer poiché era il più vicino e ha sottolineato una buona idea per usare il multicast.

Grazie a tutti per il vostro tempo ~

Answer 1

Distribued Interactive Simulation (DIS), che è definito in IEEE Standard 1278, utilizza un heartbeat predefinito di 5 secondi tramite trasmissione UDP. Un heartbeat DIS è essenzialmente una PDU State Entity, che definisce completamente lo stato, inclusa la posizione, dell'entità data. A causa della sua applicazione all'interno della comunità di simulazione, DIS utilizza anche un concetto denominato dead-reckoning per fornire heartbeat a frequenza più elevata quando la posizione effettiva, ad esempio, è al di fuori di una data soglia della sua posizione prevista.

Nel vostro caso, una PDU di stato entità DIS sarebbe eccessiva. L'ho solo menzionato per prendere nota del fatto che i battiti del cuore possono variare in frequenza a seconda delle circostanze. Non so che avresti bisogno di qualcosa del genere per l'applicazione che hai descritto, ma non si sa mai.

Per heartbeat, utilizzare UDP, non TCP. Un battito cardiaco è, per sua natura, un congegno senza connessione, quindi va detto che UDP (connectionless) è più rilevante qui rispetto al TCP (orientato alla connessione).

La cosa da tenere a mente sulle trasmissioni UDP è che un messaggio broadcast è limitato allo broadcast domain. In breve, se si dispone di computer separati da un dispositivo di livello 3, ad esempio un router, le trasmissioni non funzioneranno perché il router non trasmetterà i messaggi trasmessi da un dominio di trasmissione a un altro. In questo caso, consiglierei di utilizzare il multicast poiché coprirà i domini broadcast, fornendo un valore TTL (time-to-live) sufficientemente elevato. È anche un approccio più automatizzato rispetto a unicast diretto, che richiederebbe al mittente di conoscere l'indirizzo IP del ricevitore per inviare il messaggio.

Answer 2

Broadcast un battito cardiaco ogni t utilizzando UDP; se non hai sentito da una macchina in più di k * t, allora è scontato. Fai attenzione che la larghezza di banda aggregata utilizzata non è un drenaggio delle risorse. Puoi utilizzare gli indirizzi di trasmissione IP o mantenere un elenco di IP specifici per cui lavori.

Assicurarsi che l'heartbeat includa un "reboot count" e un "machine ID" in modo da sapere che lo stato del server precedente non è intorno.

Si consiglia di utilizzare MapReduce se si adatta. Farebbe risparmiare molto lavoro.

Answer 3

Non sono sicuro che questo risponda alla domanda ma potresti essere interessato dal modo in cui il clustering di Weblogic Server funziona sotto il cofano. Dal libro Mastering BEA WebLogic Server:

[...] Il clustering di server WebLogic fornisce un accoppiamento lento dei server nel cluster. Ogni server nel cluster è indipendente e non si basa su nessun altro server per operazioni fondamentali. Anche se il contatto con ogni altro server viene perso, ogni server continuerà a funzionare e sarà in grado di elaborare le richieste che riceve. Ogni server nel cluster mantiene il proprio elenco di altri server nel cluster tramite i messaggi di heartbeat periodici. Ogni 10 secondi, ciascun server invia un messaggio heartbeat agli altri server nel cluster per informarli che è ancora attivo. I messaggi heartbeat vengono inviati utilizzando la tecnologia multicast IP incorporata nella JVM, rendendo questo meccanismo efficiente e scalabile man mano che il numero di server nel cluster aumenta.Ogni server riceve questi messaggi heartbeat da altri server e li utilizza per mantenere l'elenco di appartenenza al cluster corrente. Se un server perde la ricezione di tre messaggi heartbeat in una riga da qualsiasi altro server, prende quel server dall'elenco dei membri finché non riceve un altro messaggio heartbeat da quel server. Questa tecnologia heartbeat consente ai server di essere aggiunti e rilasciati dinamicamente dal cluster senza alcun impatto sulle configurazioni dei server esistenti.

Answer 4

Gli switch di contenuto Cisco sono una soluzione hardware per questo problema. Implementano un indirizzo IP virtuale come front-end su più real server, i cui reali indirizzi IP sono noti allo switch. Lo switch invia periodicamente richieste HEAD HTTP ai server Web per verificare che siano ancora in esecuzione (che il software dello switch chiama "keepalive", sebbene questo non mantenga attivo il server stesso). Lo switch Cisco accetta il traffico sull'IP virtuale e lo inoltra ai server Web attuali, utilizzando il bilanciamento del carico configurabile come round-robin o il bilanciamento del carico definito dall'utente.

Questi switch vendono al dettaglio nell'intervallo $ 3-10 K, anche se il mio socio in affari ne ha acquistato uno su eBay per circa $ 300 un anno fa. Se puoi permetterne uno, rappresentano una soluzione hardware collaudata alla domanda su come far sì che un servizio si diffonda in modo trasparente su più server. Redhat include una configurazione di porta integrata in modo da poter implementare il proprio switch Cisco utilizzando una scatola RedHat economica. Google per "indirizzo IP virtuale" e "router di contenuto Cisco" per ulteriori informazioni.

Answer 5

Oltre a provare i bilanciatori di carico hardware, è anche possibile provare un'applicazione di bilanciamento del carico open-source come HAProxy, disponibile per Linux e BSD.