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;
}
}

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 227390

Url: https://administrator.de/contentid/227390

Ausgedruckt am: 22.11.2024 um 13:11 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

Vergesen:

resource cluster {
device /dev/drbd0;
disk /dev/vg01/drbd;
meta-disk internal;

on node-a {
address 192.168.151.150:7788;
}
on node-b {
address 192.168.151.151:7788;
}
}

Japp sind beide UpToDate

Das ist nicht die /etc/heartbeat/haresources und um die geht es mir.
Davon abgesehen ist primary/primary keine gute idee.

Dman. Hätte ich doch erst die Kopieren sollen...
node-a IPaddr::192.168.153.152/24/eth3 drbddisk::cluster Filesystem::/dev/drbd0::/data::ext4 nfs-kernel-server

Ist auch erstmal nur testweise.
Aber wieso würdest du das als keine gute Idee erachten?

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

Das ist eine Virtuelle IP die aber bei Ausfall switcht. Und das geht auch ohne Probelme.
Sie ist nur solange bei dem Rechner, bis der node ausfällt.

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

P/P nutzt man ja eigentlich nur als load balancing wenn ich es richtig gelesen habe oder?

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

Ok das ist klar. Sonst wären die Daten ja nicht UptoDate.
Wenn der P abstürzt, springt ja der S ein. danach fahren ja die Systeme wieder hoch... eigentlich.

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

@Chonta,
ich habe jetzt auf P/S umgestellt. Eine Frage habe ich aber noch.
Ich habe jetzt das Problem, das beim Testsystem ein i/o Fehleraufgetreten ist. fsck meldet mir auch einige Fehler. Wie kann ich es verhindern, dass die Fehler mit auf den S node gesynct werden?

Ich weiß es gibt da einen handler, aber ich verstehe den Ablauf net so ganz.

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.