☰

Pacemaker: Anhalten der Ressource nach N-maliger Migration aufgrund eines Failovers

tag-icon • tag-icon cluster pacemaker
Pacemaker: Anhalten der Ressource nach N-maliger Migration aufgrund eines Failovers

Ich habe eine Konfiguration mit 5 Knoten, 4 davon können Ressourcen hosten und 1 Ressource. Ich möchte erreichen, dass die Ressource nach N-maliger Migration von Knoten zu Knoten vollständig gestoppt wird.

Ein Beispielszenario wäre also: Ressource VIP1 läuft auf Knoten one; ihr Monitor schlägt fehl, migration-thresholdwird erreicht, sie verschiebt sich zu Knoten two; dann schlägt sie dort erneut fehl und verschiebt sich zu Knoten three; und dann schlägt sie erneut fehl, aber irgendeine Regel (nach der ich suche) verhindert, dass sie zu Knoten migriert four. Ich schätze, ich brauche eine Art Migrationszähler.

Dies ist eine Testkonfiguration. In Wirklichkeit werde ich mehr Knoten und mehr Ressourcen haben. Daher möchte ich, dass die Konfiguration so einfach wie möglich ist. Ich gehe davon aus, dass ich dies mit einer Opt-in- oder Opt-out-Standortpräferenzstrategie für jede Ressource erreichen kann, aber es ist weder einfach noch leicht zu warten. Gibt es einen besseren Weg?

PS: Wenn ich meinen VIP mit der aktuellen Konfiguration überflute hping, durchläuft er alle Knoten, bevor er vollständig stoppt (weil er keine Knoten mehr hat, auf denen er ausgeführt werden kann, bis ich ihn bereinige oder eine failure-timeoutOption einführe).

Versionen:

[~] corosync -v
Corosync Cluster Engine, version '2.3.6'
Copyright (c) 2006-2009 Red Hat, Inc.
[~] crm --version
crm 2.2.0
[~] cat /etc/debian_version
8.5

Herzschrittmacherkonfiguration:

[~] crm configure show
node 1: one
node 2: two
node 3: three
node 4: arbitr \
        attributes standby=on
node 5: four
primitive VIP1 IPaddr2 \
        params ip=10.10.11.230 cidr_netmask=22 \
        op monitor interval=1s timeout=40ms \
        meta migration-threshold=1 target-role=Started
location preferOne VIP1 50: one
property cib-bootstrap-options: \
        dc-version=1.1.14-70404b0 \
        cluster-infrastructure=corosync \
        cluster-name=debian \
        stonith-enabled=false \
        last-lrm-refresh=1474984960 \
        have-watchdog=false

EDIT: Der Kontext und die Geschichte der gesamten Konfiguration ist folgende: Wir haben zwei Load Balancer mit LVS, die den Datenverkehr an unsere Frontends weiterleiten. Hohe Verfügbarkeit wurde früher mit einer einfachen Keepalived-Konfiguration und 2 VIPs erreicht (eine Active-Active-Konfiguration; in einer normalen Situation hat jedes LVS 1 VIP). Aber in letzter Zeit haben einige Leute angefangen, uns regelmäßig mit DDoS-Angriffen zu überziehen, und das Keepalived-Setup funktioniert nicht mehr wie erwartet: Selbst wenn sie nur 1 VIP, also 1 Host, mit DDoS-Angriffen angreifen, verliert sein Keepalived eingehenden Datenverkehr von einem anderen Host, schnappt sich den zweiten VIP und legt das gesamte System lahm.

Daher dachten wir, dass wir a) etwas finden, um VIPs mit Quorum zu verwalten, um Split-Brains zu vermeiden; und b) die LVS-Hosts mindestens verdoppeln.

Ich habe also Pacemaker+Corosync getestet und die Konfiguration ist wirklich einfach, wenn wir zwei aktive und einen Standby-Knoten haben. Wie erwartet migriert einer der VIPs, wenn er einem DDoS-Angriff ausgesetzt ist, zuerst zu einem anderen Knoten und fährt dann vollständig herunter. Wenn wir Knoten hinzufügen, wird dieser „Ressourcenweg“ länger, was nicht ganz das ist, was wir wollen: Wir wollen, dass der VIP so schnell wie möglich heruntergefahren wird, aber wir wollen natürlich auch die Möglichkeit haben, sich automatisch von einem internen Hardwareproblem zu erholen (wenn der Knoten plötzlich ausfällt, FE). Also dachte ich ... vielleicht gibt es eine Möglichkeit, eine Ressource nur EINMAL zu migrieren und wenn es immer noch fehlschlägt, dann ist es damit erledigt. Das erspart uns Hardwarefehler und spart uns Zeit, wenn wir teilweise einem DDoS-Angriff ausgesetzt sind.

Das ist im Großen und Ganzen alles. Tut mir leid, wenn es zu ausführlich ist. Wenn wir von Anfang an das falsche Instrument gewählt haben, um damit umzugehen, lassen Sie es mich bitte wissen. (Natürlich schützen wir uns mit anderen Methoden vor DDoS, aber wenn der Angriff durchkommt, wollen wir den Schaden minimieren.)

Antwort1

Das ist definitiv ein interessanter Anwendungsfall, danke fürs Teilen …

Während Ihre VIPs DDoS-Angriffen ausgesetzt sind, können sie wahrscheinlich keinen zuverlässigen Ping senden. Vielleicht sollten Sie sich den „Ping“-Ressourcenagenten für Pacemaker ansehen.

In der Clusterlabs-Dokumentation wird es hier kurz erwähnt: http://clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/ch09s03s03.html

Weitere Informationen finden Sie, indem Sie die Informationen zum Ressourcen-Agenten über Ihr bevorzugtes Cluster-Konfigurationsverwaltungstool prüfen:

# crm ra info ping
--or--
# pcs resource describe ping

Hoffe, das ist hilfreich.

verwandte Informationen