wild-wolf
Jan 22, 2014, updated at 11:13:04 (UTC)
view4165
view17
0
Goto Top

DRBD Cluster, Heartbeat 1. Problem nach Failover

GermanQuestionClusterNetworks
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;
}
}
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 227390

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

Printed on: April 19, 2024 at 03:04 o'clock

17 Comments
Latest comment
Goto Top
Member: Chonta
Chonta Jan 22, 2014 at 16:05:29 (UTC)
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
Member: Wild-Wolf
Wild-Wolf Jan 24, 2014 at 08:29:23 (UTC)
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
Member: Chonta
Chonta Jan 24, 2014 at 08:38:38 (UTC)
Goto Top
Das ist nicht die /etc/heartbeat/haresources und um die geht es mir.
Davon abgesehen ist primary/primary keine gute idee.
Member: Wild-Wolf
Wild-Wolf Jan 24, 2014 at 08:44:02 (UTC)
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?
Member: Chonta
Chonta Jan 24, 2014 at 09:07:14 (UTC)
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
Member: Wild-Wolf
Wild-Wolf Jan 24, 2014 at 09:10:50 (UTC)
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.
Member: Chonta
Chonta Jan 24, 2014 at 09:35:53 (UTC)
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
Member: Wild-Wolf
Wild-Wolf Jan 24, 2014 at 09:37:32 (UTC)
Goto Top
P/P nutzt man ja eigentlich nur als load balancing wenn ich es richtig gelesen habe oder?
Member: Chonta
Chonta Jan 24, 2014 at 10:00:15 (UTC)
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
Member: Wild-Wolf
Wild-Wolf Feb 03, 2014 at 09:03:28 (UTC)
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.
Member: Chonta
Chonta Feb 03, 2014 at 10:48:13 (UTC)
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
Member: Wild-Wolf
Wild-Wolf Feb 18, 2014 at 14:34:00 (UTC)
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.
Member: Chonta
Chonta Feb 18, 2014 at 15:14:39 (UTC)
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.
Member: Wild-Wolf
Wild-Wolf Feb 18, 2014 at 15:16:57 (UTC)
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
Member: Chonta
Chonta Feb 18, 2014 at 15:22:42 (UTC)
Goto Top
Hallo,

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

Gruß

Chonta
Member: Wild-Wolf
Wild-Wolf Feb 18, 2014 at 15:25:23 (UTC)
Goto Top
Welche option würdest du denn empfehlen?
Member: Chonta
Chonta Feb 18, 2014 at 15:32:22 (UTC)
Goto Top
on-io-error detach
GermanQuestionClusterNetworks
Hotly discussed
AlexWishaHow to set up and configure a Linux GRE tunnelAlexWisha - 3 CommentsjstrickerWIREGUARD VPN ON UDM PRO BEHIND FRITZBOX - HANDSHAKE DID NOT COMPLETEjstricker - 1 CommentDaniEnd of Support dates for Office 2016, 2019 Apps und Productivity ServersDani - 1 Comment