DRBD Cluster, Heartbeat 1. Problem nach Failover

wild-wolf
Goto Top
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;
}
}

Content-Key: 227390

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

Ausgedruckt am: 19.05.2022 um 11:05 Uhr

Mitglied: Chonta
Chonta 22.01.2014 um 17:05:29 Uhr
Goto Top
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
Mitglied: Wild-Wolf
Wild-Wolf 24.01.2014 um 09:29:23 Uhr
Goto Top
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
Mitglied: Chonta
Chonta 24.01.2014 um 09:38:38 Uhr
Goto Top
Das ist nicht die /etc/heartbeat/haresources und um die geht es mir.
Davon abgesehen ist primary/primary keine gute idee.
Mitglied: Wild-Wolf
Wild-Wolf 24.01.2014 um 09:44:02 Uhr
Goto Top
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?
Mitglied: Chonta
Chonta 24.01.2014 um 10:07:14 Uhr
Goto Top
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
Mitglied: Wild-Wolf
Wild-Wolf 24.01.2014 um 10:10:50 Uhr
Goto Top
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.
Mitglied: Chonta
Chonta 24.01.2014 um 10:35:53 Uhr
Goto Top
Ich weiß das :-) face-smile
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 :-) face-smile
Belass es bei Primary/scundary und du hast was stabiles das funktioniert und selten Probleme macht (Splitbrain)

Gruß

Chonta
Mitglied: Wild-Wolf
Wild-Wolf 24.01.2014 um 10:37:32 Uhr
Goto Top
P/P nutzt man ja eigentlich nur als load balancing wenn ich es richtig gelesen habe oder?
Mitglied: Chonta
Chonta 24.01.2014 um 11:00:15 Uhr
Goto Top
Aber in deiner Konstellation gibt es kein LB! :-) face-smile

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
Mitglied: Wild-Wolf
Wild-Wolf 03.02.2014 um 10:03:28 Uhr
Goto Top
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.
Mitglied: Chonta
Chonta 03.02.2014 um 11:48:13 Uhr
Goto Top
Hallo,

die Systeme fahren nichtmal runter :-) face-smile 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
Mitglied: Wild-Wolf
Wild-Wolf 18.02.2014 um 15:34:00 Uhr
Goto Top
@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.
Mitglied: Chonta
Chonta 18.02.2014 um 16:14:39 Uhr
Goto Top
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 ;-) face-wink

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.
Mitglied: Wild-Wolf
Wild-Wolf 18.02.2014 um 16:16:57 Uhr
Goto Top
Einige Sachen gehen schon wieder mehr in die Materie.
Meinst du sowas würde da sind machen?
http://www.drbd.org/users-guide-8.3/s-configure-io-error-behavior.html
Mitglied: Chonta
Chonta 18.02.2014 um 16:22:42 Uhr
Goto Top
Hallo,

jo würde ich machen. Aber 100%igen Schutz gegen korupte Dateien bietet das auch nicht.

Gruß

Chonta
Mitglied: Wild-Wolf
Wild-Wolf 18.02.2014 um 16:25:23 Uhr
Goto Top
Welche option würdest du denn empfehlen?
Mitglied: Chonta
Chonta 18.02.2014 um 16:32:22 Uhr
Goto Top
on-io-error detach