Heartbeat-Protokolle/Algorithmen oder Best Practices

Question

Kürzlich habe ich einige Load-Balancing-Funktionen zu einer Software hinzugefügt, die ich geschrieben habe. Es ist eine vernetzte Anwendung, die einige Daten verarbeitet, basierend auf Eingaben, die von einer SQL-Datenbank kommen. Da das Knirschen ziemlich intensiv sein kann, habe ich die Möglichkeit hinzugefügt, mehrere Instanzen dieser Anwendung auf verschiedenen Servern laufen zu lassen, um die Last zu teilen, aber wie es jetzt ist, ist der Lastausgleich ein manueller Akt. Ein Benutzer muss angeben, welche Instanzen welchen Teil der Eingangsdomäne annehmen.

Ich möchte das auf die nächste Ebene bringen und die Instanzen so programmieren, dass sie das Eintauchen der Eingabedaten automatisch aushandeln und erkennen, ob einer von ihnen "verschwindet" (abgestürzt ist oder heruntergefahren wurde) verbleibende Instanzen können die Arbeitsauslastung der fehlgeschlagenen Instanz übernehmen.

Um dies zu implementieren, überlege ich, ein einfaches Heartbeat-Protokoll zwischen den Instanzen zu verwenden, um festzustellen, wer online und wer nicht ist und während dies nicht schrecklich kompliziert ist, würde ich gerne wissen, ob es etablierte Heartbeat-Netzwerk gibt Protokolle (basierend auf UDP, TCP oder beiden).

Offensichtlich passiert dies viel in der Netzwerkwelt mit Clustering, Failover und Hochverfügbarkeitstechnologien, also würde ich am Ende gerne wissen, ob es vielleicht etablierte Protokolle oder Algorithmen gibt, die ich beachten sollte von oder implementieren.

EDIT

Es scheint, auf der Grundlage der Antworten, dass entweder gibt es keine gut Herzschlag Protokolle etabliert oder dass niemand kennt sie (was bedeuten würde, dass sie gar nicht so gut etabliert sind) In diesem Fall werde ich nur meine eigenen rollen.

Während keine der Antworten bot, was ich speziell suchte, werde ich für Matt Davis's answer abstimmen, da es am nächsten war und er wies auf eine gute Idee, Multicast zu verwenden.

Vielen Dank für Ihre Zeit ~

Answer 1

Distribued Interactive Simulation (DIS), definiert unter IEEE Standard 1278, verwendet einen Standard-Heartbeat von 5 Sekunden über UDP-Broadcast. Ein DIS-Heartbeat ist im Wesentlichen eine Entity-State-PDU, die den Status einschließlich der Position der gegebenen Entität vollständig definiert. Aufgrund seiner Anwendung innerhalb der Simulationsgemeinschaft verwendet DIS auch ein Konzept, das als Koppelnavigation bezeichnet wird, um höherfrequente Herzschläge zu liefern, wenn die tatsächliche Position beispielsweise außerhalb einer gegebenen Schwelle ihrer vorhergesagten Position liegt.

In Ihrem Fall wäre eine DIS Entity State PDU übertrieben. Ich erwähne es nur, um darauf hinzuweisen, dass die Herzschläge in Abhängigkeit von den Umständen variieren können. Ich weiß nicht, dass du so etwas für die Anwendung brauchst, die du beschrieben hast, aber du weißt es nie.

Verwenden Sie für Heartbeats UDP, nicht TCP. Ein Heartbeat ist von Natur aus eine verbindungslose Einrichtung, daher ist UDP (verbindungslos) hier relevanter als TCP (verbindungsorientiert).

Bei UDP-Broadcasts ist zu beachten, dass eine Broadcast-Nachricht auf die broadcast domain beschränkt ist. Kurz gesagt, wenn Sie Computer haben, die durch ein Layer-3-Gerät, z. B. einen Router, getrennt sind, dann werden Broadcasts nicht funktionieren, da der Router keine Broadcast-Nachrichten von einer Broadcast-Domäne zu einer anderen überträgt. In diesem Fall würde ich Multicast empfehlen, da es die Broadcast-Domänen überspannt, vorausgesetzt, der Time-to-Live (TTL) -Wert ist hoch genug eingestellt. Es ist auch ein automatisierterer Ansatz als eine gerichtete Unicast, bei der der Absender die IP-Adresse des Empfängers kennen muss, um die Nachricht zu senden.

Answer 2

Sendung ein Herzschlag jedes t UDP verwendet wird; Wenn Sie von einer Maschine nicht mehr als k * t gehört haben, wird angenommen, dass sie nicht funktioniert. Achten Sie darauf, dass die verwendete Gesamtbandbreite keine Ressourcen verbraucht. Sie können IP-Broadcast-Adressen verwenden oder eine Liste mit bestimmten IP-Adressen führen, für die Sie arbeiten.

Stellen Sie sicher, dass der Heartbeat einen "Neustart Count" sowie "Machine ID" enthält, so dass Sie wissen, dass der vorherige Serverstatus nicht vorhanden ist.

Ich würde empfehlen, MapReduce zu verwenden, wenn es passt. Es würde viel Arbeit sparen.

Answer 3

Ich bin nicht sicher, dass dies die Frage beantworten wird, aber Sie könnten interessiert sein, wie Weblogic Server Clustering unter der Haube arbeiten. Aus dem Buch Mastering BEA WebLogic Server:

[...] WebLogic Server-Clustering bietet eine lose Kopplung der Server im Cluster. Jeder Server im Cluster ist unabhängig und benötigt keine anderen Server für grundlegende Vorgänge. Selbst wenn der Kontakt mit jedem anderen Server verloren geht, wird jeder Server weiterhin ausgeführt und kann die empfangenen Anfragen verarbeiten. Jeder Server im Cluster verwaltet seine eigene Liste anderer Server im Cluster durch periodische Heartbeat-Nachrichten. Alle 10 Sekunden sendet jeder Server eine Überwachungssignalnachricht an die anderen Server im Cluster, um ihn darüber zu informieren, dass er noch aktiv ist. Heartbeat-Nachrichten werden mithilfe der in der JVM integrierten IP-Multicast-Technologie gesendet, wodurch dieser Mechanismus effizient und skalierbar wird, wenn die Anzahl der Server im Cluster zunimmt.Jeder Server empfängt diese Heartbeat-Nachrichten von anderen Servern und verwendet sie, um seine aktuelle Clustermitgliedschaftsliste zu verwalten. Wenn ein Server es versäumt, drei Heartbeat-Nachrichten in einer Reihe von einem anderen Server zu empfangen, nimmt er diesen Server aus seiner Mitgliedschaftsliste, bis er eine weitere Heartbeat-Nachricht von diesem Server erhält. Mit dieser Heartbeat-Technologie können Server dynamisch hinzugefügt und aus dem Cluster entfernt werden, ohne dass dies Auswirkungen auf die Konfiguration der vorhandenen Server hat.

Answer 4

Cisco Inhaltsschalter sind eine Hardwarelösung für dieses Problem. Sie implementieren eine virtuelle IP-Adresse als Front-End für mehrere reale Server, deren reale IP-Adressen dem Switch bekannt sind. Der Switch sendet regelmäßig HTTP HEAD-Anfragen an die Webserver, um zu überprüfen, ob sie noch laufen (was die Switch-Software "Keepalive" nennt, obwohl dies den Server selbst nicht am Leben erhält). Der Cisco-Switch akzeptiert den Datenverkehr auf der virtuellen IP-Adresse und leitet ihn mithilfe eines konfigurierbaren Lastenausgleichs wie Round-Robin oder benutzerdefiniertem Lastenausgleich an die tatsächlichen Webserver weiter.

Diese Switches sind im Bereich $ 3-10K erhältlich, obwohl mein Geschäftspartner vor einem Jahr einen eBay-Gewinn von etwa $ 300 erzielte. Wenn Sie sich eines leisten können, sind sie eine bewährte Hardwarelösung für die Frage, wie sich ein Service transparent auf mehrere Server verteilen lässt. Redhat enthält eine integrierte Port-Konfiguration, so dass Sie Ihren eigenen Cisco-Switch mit einer billigen RedHat-Box implementieren können. Google für "virtuelle IP-Adresse" und "Cisco Content-Router" für weitere Informationen.

Answer 5

Zusätzlich zu den Hardware-Lastenausgleichsfunktionen können Sie auch eine kostenlose Open-Source-Lastausgleichs-Software wie HAProxy, die für Linux und die BSDs verfügbar ist, ausprobieren.