DRBD Cluster, Heartbeat 1. Problem nach Failover
Moin zusammen.
Ich habe da ein kleines Problem.
ich habe ein DRBD Cluster mit Heartbeat 1 (Primary/Primary) aufgebaut. Läuft auch alles soweit ganz gut. Wenn ich nun bei einem die Heartbeatverbindung trenne, übernimmt der andere die Freigabe des NFS-Speichers und wechselt. Der Status wechselt nun auf Unknown/Primary.
Kommt der vorherige Node wieder, wechselt der Status auf Primary/Secondary, aber nicht mehr auf Primary/Primary.
Woran kann das liegen?
Auszug aus der ha-log von node-a:
ResourceManager[6184]: 2014/01/22_11:31:27 info: Running /etc/ha.d/resource.d/drbddisk cluster start
Filesystem[6424]: 2014/01/22_11:31:27 INFO: Resource is stopped
ResourceManager[6184]: 2014/01/22_11:31:27 info: Running /etc/ha.d/resource.d/Filesystem /dev/drbd0 /data ext4 start
Filesystem[6499]: 2014/01/22_11:31:27 INFO: Running start for /dev/drbd0 on /data
Filesystem[6493]: 2014/01/22_11:31:28 INFO: Success
ResourceManager[6184]: 2014/01/22_11:31:28 info: Running /etc/init.d/nfs-kernel-server start
Jan 22 11:31:28 node-a heartbeat: [6170]: info: local HA resource acquisition completed (standby).
Jan 22 11:31:28 node-a heartbeat: [6143]: info: Standby resource acquisition done [foreign].
Jan 22 11:31:28 node-a ipfail: [6167]: info: Ping node count is balanced.
Jan 22 11:31:28 node-a heartbeat: [6143]: info: remote resource transition completed.
Auszug aus der ha-log von node-b:
ResourceManager[3397]: 2014/01/22_11:31:26 info: Running /etc/ha.d/resource.d/IPaddr 192.168.153.152/24/eth3 stop
IPaddr[3612]: 2014/01/22_11:31:26 INFO: ifconfig eth3:0 down
IPaddr[3588]: 2014/01/22_11:31:26 INFO: Success
Jan 22 11:31:26 node-b heartbeat: [3383]: info: foreign HA resource release completed (standby).
Jan 22 11:31:26 node-b heartbeat: [2570]: info: Local standby process completed [foreign].
Jan 22 11:31:28 node-b heartbeat: [2570]: WARN: 1 lost packet(s) for [node-a] [13:15]
Jan 22 11:31:28 node-b heartbeat: [2570]: info: remote resource transition completed.
Jan 22 11:31:28 node-b heartbeat: [2570]: info: No pkts missing from node-a!
Jan 22 11:31:28 node-b heartbeat: [2570]: info: Other node completed standby takeover of foreign resources.
Jan 22 11:31:29 node-b ipfail: [2614]: info: No giveup timer to abort.
Auszug aus der ha-debug von node-a:
Jan 22 11:31:28 node-a heartbeat: [6143]: info: Standby resource acquisition done [foreign].
Jan 22 11:31:28 node-a ipfail: [6167]: debug: Other side is now stable.
Jan 22 11:31:28 node-a ipfail: [6167]: debug: Other side is now stable.
Jan 22 11:31:28 node-a ipfail: [6167]: debug: Got asked for num_ping.
Jan 22 11:31:28 node-a ipfail: [6167]: info: Ping node count is balanced.
Jan 22 11:31:28 node-a ipfail: [6167]: debug: Abort message sent.
Jan 22 11:31:28 node-a ipfail: [6167]: debug: Other side is unstable.
Jan 22 11:31:28 node-a heartbeat: [6143]: info: remote resource transition completed.
Jan 22 11:31:28 node-a ipfail: [6167]: debug: Other side is now stable.
Jan 22 11:31:28 node-a ipfail: [6167]: debug: Other side is now stable.
Auszug aus der ha-debug von node-b:
INFO: Success
Jan 22 11:31:26 node-b heartbeat: [3383]: info: foreign HA resource release completed (standby).
Jan 22 11:31:26 node-b heartbeat: [2570]: info: Local standby process completed [foreign].
Jan 22 11:31:28 node-b heartbeat: [2570]: info: remote resource transition completed.
Jan 22 11:31:28 node-b heartbeat: [2570]: info: No pkts missing from node-a!
Jan 22 11:31:28 node-b heartbeat: [2570]: info: Other node completed standby takeover of foreign resources.
Jan 22 11:31:28 node-b ipfail: [2614]: debug: Other side is now stable.
Jan 22 11:31:29 node-b ipfail: [2614]: debug: Other side is now stable.
Jan 22 11:31:29 node-b ipfail: [2614]: info: No giveup timer to abort.
ha.cf von node-a:
debugfile /var/log/ha-debug
logfile /var/log/ha-log
logfacility local0
keepalive 2
warntime 5
deadtime 8
initdead 30
ucast eth2 192.168.152.151 #IP node-b
respawn hacluster /usr/lib/heartbeat/ipfail
auto_failback off
node node-a
node node-b
autojoin none
crm off
ha.cf von node-b:
debugfile /var/log/ha-debug
logfile /var/log/ha-log
logfacility local0
keepalive 2
warntime 5
deadtime 8
initdead 30
ucast eth2 192.168.152.150 # IP node-a
respawn hacluster /usr/lib/heartbeat/ipfail
auto_failback off
node node-a
node node-b
autojoin none
crm off
DRBD global_common.conf:
global {
usage-count no;
}
common {
protocol C;
handlers {
pri-on-incon-degr "/usr/lib/drbd/notify-pri-on-incon-degr.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
}
startup {
degr-wfc-timeout 30;
wfc-timeout 20;
become-primary-on both;
}
disk {
on-io-error detach;
no-disk-barrier;
no-disk-flushes;
}
net {
allow-two-primaries;
max-buffers 8000;
max-epoch-size 8000;
sndbuf-size 512k;
}
syncer {
rate 1G;
al-extents 3389;
}
}
Ich habe da ein kleines Problem.
ich habe ein DRBD Cluster mit Heartbeat 1 (Primary/Primary) aufgebaut. Läuft auch alles soweit ganz gut. Wenn ich nun bei einem die Heartbeatverbindung trenne, übernimmt der andere die Freigabe des NFS-Speichers und wechselt. Der Status wechselt nun auf Unknown/Primary.
Kommt der vorherige Node wieder, wechselt der Status auf Primary/Secondary, aber nicht mehr auf Primary/Primary.
Woran kann das liegen?
Auszug aus der ha-log von node-a:
ResourceManager[6184]: 2014/01/22_11:31:27 info: Running /etc/ha.d/resource.d/drbddisk cluster start
Filesystem[6424]: 2014/01/22_11:31:27 INFO: Resource is stopped
ResourceManager[6184]: 2014/01/22_11:31:27 info: Running /etc/ha.d/resource.d/Filesystem /dev/drbd0 /data ext4 start
Filesystem[6499]: 2014/01/22_11:31:27 INFO: Running start for /dev/drbd0 on /data
Filesystem[6493]: 2014/01/22_11:31:28 INFO: Success
ResourceManager[6184]: 2014/01/22_11:31:28 info: Running /etc/init.d/nfs-kernel-server start
Jan 22 11:31:28 node-a heartbeat: [6170]: info: local HA resource acquisition completed (standby).
Jan 22 11:31:28 node-a heartbeat: [6143]: info: Standby resource acquisition done [foreign].
Jan 22 11:31:28 node-a ipfail: [6167]: info: Ping node count is balanced.
Jan 22 11:31:28 node-a heartbeat: [6143]: info: remote resource transition completed.
Auszug aus der ha-log von node-b:
ResourceManager[3397]: 2014/01/22_11:31:26 info: Running /etc/ha.d/resource.d/IPaddr 192.168.153.152/24/eth3 stop
IPaddr[3612]: 2014/01/22_11:31:26 INFO: ifconfig eth3:0 down
IPaddr[3588]: 2014/01/22_11:31:26 INFO: Success
Jan 22 11:31:26 node-b heartbeat: [3383]: info: foreign HA resource release completed (standby).
Jan 22 11:31:26 node-b heartbeat: [2570]: info: Local standby process completed [foreign].
Jan 22 11:31:28 node-b heartbeat: [2570]: WARN: 1 lost packet(s) for [node-a] [13:15]
Jan 22 11:31:28 node-b heartbeat: [2570]: info: remote resource transition completed.
Jan 22 11:31:28 node-b heartbeat: [2570]: info: No pkts missing from node-a!
Jan 22 11:31:28 node-b heartbeat: [2570]: info: Other node completed standby takeover of foreign resources.
Jan 22 11:31:29 node-b ipfail: [2614]: info: No giveup timer to abort.
Auszug aus der ha-debug von node-a:
Jan 22 11:31:28 node-a heartbeat: [6143]: info: Standby resource acquisition done [foreign].
Jan 22 11:31:28 node-a ipfail: [6167]: debug: Other side is now stable.
Jan 22 11:31:28 node-a ipfail: [6167]: debug: Other side is now stable.
Jan 22 11:31:28 node-a ipfail: [6167]: debug: Got asked for num_ping.
Jan 22 11:31:28 node-a ipfail: [6167]: info: Ping node count is balanced.
Jan 22 11:31:28 node-a ipfail: [6167]: debug: Abort message sent.
Jan 22 11:31:28 node-a ipfail: [6167]: debug: Other side is unstable.
Jan 22 11:31:28 node-a heartbeat: [6143]: info: remote resource transition completed.
Jan 22 11:31:28 node-a ipfail: [6167]: debug: Other side is now stable.
Jan 22 11:31:28 node-a ipfail: [6167]: debug: Other side is now stable.
Auszug aus der ha-debug von node-b:
INFO: Success
Jan 22 11:31:26 node-b heartbeat: [3383]: info: foreign HA resource release completed (standby).
Jan 22 11:31:26 node-b heartbeat: [2570]: info: Local standby process completed [foreign].
Jan 22 11:31:28 node-b heartbeat: [2570]: info: remote resource transition completed.
Jan 22 11:31:28 node-b heartbeat: [2570]: info: No pkts missing from node-a!
Jan 22 11:31:28 node-b heartbeat: [2570]: info: Other node completed standby takeover of foreign resources.
Jan 22 11:31:28 node-b ipfail: [2614]: debug: Other side is now stable.
Jan 22 11:31:29 node-b ipfail: [2614]: debug: Other side is now stable.
Jan 22 11:31:29 node-b ipfail: [2614]: info: No giveup timer to abort.
ha.cf von node-a:
debugfile /var/log/ha-debug
logfile /var/log/ha-log
logfacility local0
keepalive 2
warntime 5
deadtime 8
initdead 30
ucast eth2 192.168.152.151 #IP node-b
respawn hacluster /usr/lib/heartbeat/ipfail
auto_failback off
node node-a
node node-b
autojoin none
crm off
ha.cf von node-b:
debugfile /var/log/ha-debug
logfile /var/log/ha-log
logfacility local0
keepalive 2
warntime 5
deadtime 8
initdead 30
ucast eth2 192.168.152.150 # IP node-a
respawn hacluster /usr/lib/heartbeat/ipfail
auto_failback off
node node-a
node node-b
autojoin none
crm off
DRBD global_common.conf:
global {
usage-count no;
}
common {
protocol C;
handlers {
pri-on-incon-degr "/usr/lib/drbd/notify-pri-on-incon-degr.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
}
startup {
degr-wfc-timeout 30;
wfc-timeout 20;
become-primary-on both;
}
disk {
on-io-error detach;
no-disk-barrier;
no-disk-flushes;
}
net {
allow-two-primaries;
max-buffers 8000;
max-epoch-size 8000;
sndbuf-size 512k;
}
syncer {
rate 1G;
al-extents 3389;
}
}
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 227390
Url: https://administrator.de/forum/drbd-cluster-heartbeat-1-problem-nach-failover-227390.html
Ausgedruckt am: 23.12.2024 um 12:12 Uhr
17 Kommentare
Neuester Kommentar
Hallo,
http://www.drbd.org/users-guide/s-dual-primary-mode.html
Also ich verstehe den Link so, das NFS und primary/primary eigendlich nicht gehen soll.
Du verschweigst die Resource die ha verwaltet und ob DRBD auf beiden UpToDate ist.
heartbeat sorgd bei einem Failover im Normalfall dafür, das der Primary wechselt.
Also wenn Du das nicht umkonfiguriert hast wird im Failoverfall immer einer Secundary bleiben.
Aber ich würde Dir von primary/primary bei DRBD abraten, wenn Du sowas willst, dann nim GlusterFS.
Gruß
Chonta
http://www.drbd.org/users-guide/s-dual-primary-mode.html
Also ich verstehe den Link so, das NFS und primary/primary eigendlich nicht gehen soll.
Du verschweigst die Resource die ha verwaltet und ob DRBD auf beiden UpToDate ist.
heartbeat sorgd bei einem Failover im Normalfall dafür, das der Primary wechselt.
Also wenn Du das nicht umkonfiguriert hast wird im Failoverfall immer einer Secundary bleiben.
Aber ich würde Dir von primary/primary bei DRBD abraten, wenn Du sowas willst, dann nim GlusterFS.
Gruß
Chonta
drbddisk::cluster Filesystem::/dev/drbd0
Darüber wird DRBD von Heartbeat gesteuert über die Scripte von Heartbeat. Und die sehen nur einen Primary/secundary Betrieb vor.
Wie im Link von mir steht, wird Primary/Primary nicht für NFS verwenet sondern nur in Verbindung mit Clusterfilesystemen.
Was Du aber machen willst, ist ein Failover deiner normalen Netzwerkfreigabe.
Die NFS Freigabe ist bei einer IP und diese eine IP ist bei einem einzigen Rechner.
Gruß
Chonta
Darüber wird DRBD von Heartbeat gesteuert über die Scripte von Heartbeat. Und die sehen nur einen Primary/secundary Betrieb vor.
Wie im Link von mir steht, wird Primary/Primary nicht für NFS verwenet sondern nur in Verbindung mit Clusterfilesystemen.
Was Du aber machen willst, ist ein Failover deiner normalen Netzwerkfreigabe.
Die NFS Freigabe ist bei einer IP und diese eine IP ist bei einem einzigen Rechner.
Gruß
Chonta
Ich weiß das
Die Frage ist, wo in deiner Konstellation ein primary/primary überhaupt sinn machen würde, Wenn der Netzwerkzugriff eigendlich eh nur von einer Seiteaus statfinden kann
Belass es bei Primary/scundary und du hast was stabiles das funktioniert und selten Probleme macht (Splitbrain)
Gruß
Chonta
Die Frage ist, wo in deiner Konstellation ein primary/primary überhaupt sinn machen würde, Wenn der Netzwerkzugriff eigendlich eh nur von einer Seiteaus statfinden kann
Belass es bei Primary/scundary und du hast was stabiles das funktioniert und selten Probleme macht (Splitbrain)
Gruß
Chonta
Aber in deiner Konstellation gibt es kein LB!
Vereinfacht ist ein DRBD ein RAID1 über das Netzwerk, alle Schreibzugriffe erfolgen simultan. In deinem Setup hat immer nur ein Server die Freigabe gemountet und auch die Cluster IP dh nur von diesem einen kann gelesen werden und Schreibzugriffe werden von den Clients auch nur an diesen einen gesendet und dann vom Server zu seinem anderen DRBD Node weitergeleitet (Schreibzugriff erfolgt natürlich gleichzeitig)
Gruß
Chonta
Vereinfacht ist ein DRBD ein RAID1 über das Netzwerk, alle Schreibzugriffe erfolgen simultan. In deinem Setup hat immer nur ein Server die Freigabe gemountet und auch die Cluster IP dh nur von diesem einen kann gelesen werden und Schreibzugriffe werden von den Clients auch nur an diesen einen gesendet und dann vom Server zu seinem anderen DRBD Node weitergeleitet (Schreibzugriff erfolgt natürlich gleichzeitig)
Gruß
Chonta
Hallo,
die Systeme fahren nichtmal runter Die DIenste switchen auf den verbleibenden Node, wenn das der Secundary war und der wird dann durch Heartbeat zum primary erklärt.
Wenn der andere Server wieder hochfährt dann wird der zum secundary und synct sich mit dem primary.
ABER die Steuerung wer Primary ist, obliegt bei Heartbeat und da gibt es nur einen Highlander in deinem Setup.
Du kannst jetzt zwar händisch noch manipolieren, aber damit würdes Du die Schutzmechanismen aushebeln
Gruß
Chonta
die Systeme fahren nichtmal runter Die DIenste switchen auf den verbleibenden Node, wenn das der Secundary war und der wird dann durch Heartbeat zum primary erklärt.
Wenn der andere Server wieder hochfährt dann wird der zum secundary und synct sich mit dem primary.
ABER die Steuerung wer Primary ist, obliegt bei Heartbeat und da gibt es nur einen Highlander in deinem Setup.
Du kannst jetzt zwar händisch noch manipolieren, aber damit würdes Du die Schutzmechanismen aushebeln
Gruß
Chonta
Hallo,
garnicht.
Wenn eine Datei auf dem Master beschädigt wird, ist diese auch auf dem Slave zu 99% beschädigt.
Warum? Weil das System alle Änderungen überträgt.
Warum? Weil gegen was soll den geprüft werden ob die Änderung auch die Datei nicht beschädigt?
Ein DRBD oder eine HA Umgebung ersetzt kein Backup. Wenn Daten mit fsck repariert werden können, gut, wenn nicht löschen und aus dem Backup wiederherstellen.
Wenn kein Backup vorhanden ist war es eine unwichtige Datei
Gruß
Chonta
PS: Es gibt evtl auch Systeme die vor einer Replizierung die Datenintegrität gegen irgendetwas prüfen, aber das kostet Zeit und Performance.
garnicht.
Wenn eine Datei auf dem Master beschädigt wird, ist diese auch auf dem Slave zu 99% beschädigt.
Warum? Weil das System alle Änderungen überträgt.
Warum? Weil gegen was soll den geprüft werden ob die Änderung auch die Datei nicht beschädigt?
Ein DRBD oder eine HA Umgebung ersetzt kein Backup. Wenn Daten mit fsck repariert werden können, gut, wenn nicht löschen und aus dem Backup wiederherstellen.
Wenn kein Backup vorhanden ist war es eine unwichtige Datei
Gruß
Chonta
PS: Es gibt evtl auch Systeme die vor einer Replizierung die Datenintegrität gegen irgendetwas prüfen, aber das kostet Zeit und Performance.