Seit wir CentOS 7 verwenden, sind wir von einem normalen Heartbeat-Setup auf Pacemker umgestiegen.
Hauptsächlich haben wir IP-Ressourcen, die auf einem Knoten aktiv sind und bei einem Failover auf einen zweiten Knoten umschalten. Außerdem führen wir im Falle eines Failovers einige Skripte aus. Nichts Besonderes.
Damit Ressourcen immer auf dem primären Knoten gestartet werden, verwende ich
pcs constraint location Cluster_IP prefers server1=master-server
Ich benutze auch
pcs resource defaults resource-stickiness=INFINITY
um zu verhindern, dass Ressourcen nach einem Failover zurück verschoben werden.
Dies funktioniert bei mir einwandfrei, wenn der Master ausfällt (beispielsweise aufgrund eines Hardwarefehlers).
Da es für mich kein Problem ist, wenn das Failover eine Weile dauert, würde ich für den Fall eines kurzen Split Brain gerne eine Art Verzögerung implementieren.
Bevor etwas unternommen wird, sollte der Slave ca. 2 Minuten warten, bevor er übernimmt, falls der Master in diesen ca. 2 Minuten wieder erreichbar ist.
Ich habe mich gefragt, wie man das am besten macht.
Antwort1
tokenIch habe ein Token-Timeout in Corosync nie auf einen Wert über 10 Sekunden eingestellt, aber Sie könnten versuchen, den Wert in Ihrem corosync.confauf 120000(120 Sekunden in Millisekunden) zu erhöhen/einzustellen . Weitere Einzelheiten tokenfinden Sie im totem{}Abschnitt Ihres corosync.conf; .man corosync.conf
Dies sollte verhindern, dass Corosync einen Knoten für 120 Sekunden für tot erklärt, wenn das Netzwerk ausfällt.
Antwort2
Sie können das Überwachungsintervall der Ressource mit ändern, op monitor interval=Nswobei Ndie Anzahl der Sekunden ist, und dann migration-thresholdfür die Ressource auf festlegen 2. Beachten Sie, dass bei einer Einstellung von 120seine Gesamtverzögerung von 120–240 Sekunden auftreten kann, je nachdem, wann der erste Fehler im Überwachungsintervall auftritt.
Es gibt noch weitere Einschränkungen, da der Fehlerzähler migration-thresholdbei Erfolg nicht zurückgesetzt wird. Dazu müssten Sie ihn ebenfalls festlegen failure-timeoutoder manuell eingreifen.
Mit op monitor interval=120s, migration-threshold=2, failure-timeout=121sund Ihrer resource-stickinessEinstellung müssten Sie testen, ob dies die erwartete Funktionalität bietet und wie sich die Fehlerzähler verhalten, wenn der ursprüngliche Master wiederhergestellt wird. Es könnte ein manuelles Eingreifen erforderlich sein, aber da bin ich mir nicht 100 % sicher