Wie verwalte ich Consul und sein Quorum in Umgebungen mit automatischer Skalierung?

Wir haben Docker-Umgebungen mit automatischer Skalierung, in denen wir Consul für die Serviceerkennung verwenden. Diese Umgebungen können alle paar Minuten eine Instanz hinzufügen oder entfernen.

Unsere frühen Konsulentests haben gezeigt, dass es für den Konsul sehr leicht war, sein Quorum zu verlieren. Vielleicht naiv war unser allererstes Experiment ein Setup, bei dem wir auf allen Instanzen einen Consul-Server starten und diesen Consul-Server dem Cluster beitreten lassen. Dieser Teil funktionierte gut.

Consul erntet jedoch nicht schnell erreichbare Knoten schnell (es dauert ungefähr 72 Stunden?) In einer sehr skalierbaren Umgebung, was bedeutet, dass die Liste der Consul-Server ständig wächst und im Laufe der Zeit die meisten von ihnen "nicht erreichbar" sind und zu diesem Zeitpunkt der Cluster verliert sein Quorum.

Wir haben Armons Antwort von vor fast zwei Jahren auf dieses Problem auf GitHub gesehen: https://github.com/hashicorp/consul/issues/454#issuecomment-125767550

Die meisten dieser Probleme werden durch unser Standardverhalten verursacht, einen angemessenen Urlaub zu versuchen. Unser mentales Modell ist, dass Server eine lange Lebensdauer haben und aus keinem anderen Grund als einem unerwarteten Stromausfall oder einer ordnungsgemäßen Wartung heruntergefahren werden. In diesem Fall müssen Sie den Cluster verlassen. Rückblickend war das ein schlechter Standard. Fast all dies kann vermieden werden, indem nur der Consul-Server getötet wird, um den Stromausfall zu simulieren.

Wir haben versucht, die Ausführung dedizierter, langlebiger Knoten zu vermeiden. Beachten Sie, dass wir zu keinem Zeitpunkt N / 2 + 1-Instanzen aus einer Gruppe mit automatischer Skalierung entfernen. Der EC2-Cluster kann zu jedem Zeitpunkt die meisten Knoten erreichen und sollte abstimmen können, ob ein Knoten aus dem Consul-Cluster (oder einem anderen Tool-Cluster) entfernt werden soll.

autoscaling consul

— Alexandre
quelle

Ich würde mir vorstellen, dass eine aussagekräftige Antwort ohne weitere Daten nicht möglich ist, z. B.: Wie groß (in Zahlen) ist Ihre Instanzpopulation? Haben Sie versucht, den zugrunde liegenden Quorum- / Konsensmechanismus zu debuggen, um festzustellen, was die Verzögerungen bei der Ernte inaktiver Mitglieder verursacht? Was ist der Zeitpunkt für das Entfernen der Instanz? Haben Sie nachverfolgt, ob die Konsulinstanz tatsächlich Zeit hat, dem Rest der ASG eine Nachricht über ihren Tod (anmutig oder nicht) zu senden?

— Michael Bravo

Starten Sie sie als "Server-Modus" oder als "Client-Modus"? In der Dokumentation zu allow_on_terminate heißt es, dass "client-mode" standardmäßig true ist. Mir scheint, Konsulagenten, die als "Server-Modus" gestartet wurden, sollten länger leben als Sie beschreiben

— Thymine

Danke euch allen. Tensibais Antwort ist das, wonach wir gesucht haben.

— Alexandre

Ich würde die leave_on_terminateOption auf true setzen. Gemäß der Dokumentation

leave_on_terminateWenn diese Option aktiviert ist, sendet der Agent beim Empfang eines TERM-Signals eine Leave-Nachricht an den Rest des Clusters und geht ordnungsgemäß. Das Standardverhalten für diese Funktion hängt davon ab, ob der Agent als Client oder als Server ausgeführt wird oder nicht (vor Consul 0.7 wurde der Standardwert unbedingt auf false festgelegt). Bei Agenten im Client-Modus ist dies standardmäßig true und bei Agenten im Server-Modus standardmäßig false.

Wenn ein Knoten ordnungsgemäß heruntergefahren wird, wird SIGTERM vor dem Herunterfahren an alle Prozesse gesendet. Mit dieser Einstellung auf dem Konsulagenten wird der Cluster verlassen, sodass er nicht als Knoten betrachtet wird, der neu gestartet werden kann und in einem Cluster wieder vorhanden ist einige Stunden (was in Ihrem Zitat standardmäßig angegeben ist).

— Tensibai
quelle

Wird der tote Kundenkonsul sofort aktiviert oder gibt es immer noch eine Verzögerung? Ich habe diese Option im Client-Modus Consul getestet und nach dem Ausführen shutdown -h nowwird immer noch ein toter Knoten angezeigt ...

— Casper

@Casper Es gibt verschiedene Möglichkeiten, wie dies möglicherweise nicht wie erwartet funktioniert. Ich denke, es hängt davon ab, ob Ihr Daemon-System dem Konsul-Client genügend Zeit lässt, um ordnungsgemäß anzuhalten (vorausgesetzt, Sie haben den Client nicht mit einem Daemon-Manager und nicht als Befehl gestartet )

— Tensibai

Vielen Dank für die Antwort, es ist eine Weile her :) Mein Ziel ist es also, eine niedrige Erntezeit für tote Knoten zu haben, die Standardzeit von 72 Stunden ist zu lang und es scheint, dass es keine Möglichkeit gibt, die Erntezeit auf Clientknoten anzupassen

— Casper

@Casper Wie oben erwähnt, benötigen wir weitere Details, um Ratschläge zu geben. In einem System-Setup kann der Stopp-Teil so angepasst werden, dass der Konsul-Client ordnungsgemäß gestoppt wird, bevor der Herunterfahrvorgang fortgesetzt wird, damit er sich selbst entfernen kann, oder es liegt irgendwo ein Fehler vor , aber mit den aktuellen Informationen können wir nur raten und SE-Sites sind nicht gut für diese Art von Debug angepasst

— Tensibai