PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : DRBD & Heartbeat



nr8
19.01.11, 11:59
Hallo.

Ich versuche gerade mit DRBD & Heartbeat einen HA-Server zu machen.
Es soll ein MySQL-Server HA-Fähig gemacht werden.
Distri ist Debian 5

Hier die Infos des Systems
Node1:
eth0: 192.168.182.11
eth1: 192.168.183.11

Node2:
eth0: 192.168.182.12
eth1: 192.168.183.12

Virtuelle IP ist 192.168.182.10 und wird auf eth0 gelegt. Über diese wird dann der Traffic von MySQL gehen.

DBRD soll den Traffic über eth1 schicken das eth0 nicht so belastet wird
Heartbeat checkt die eth0

So jetzt zu meinem Problem.
Ich hab auf beiden Servern MySQL über apt-get installiet. Dann habe ich vom Node1 die Daten von /var/lib/mysql genommen und auf die Partition von DRBD kopiert inkl. Berechtigungen und hab einen Link von der DRBD Partition auf /var/lib/mysql gemacht.
Der MySQL-Server fahrt brav hoch und lauft.

Wenn ich jetzt einmal umschalte auf Node2 fahrt der MySQL-Server nicht hoch. (Den Link hab ich auf Node2 natürlich auch) Grund ist das die Berechtigungen die ich auf Node1 auf dem Verzeichnis gesetzt habe das auf der DRBD Partition liegt jetzt anders sind auf Node2. Warum auch immer?!
Ok jetzt habe ich versucht die Rechte zu setzten und danach MySQL zu starten. Hier bekomme ich diesen Fehler:

Starting MySQL database server: mysqld.
Checking for corrupt, not cleanly closed and upgrade needing tables..
/usr/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)'
ERROR 1045 (28000): Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)

Woran kann das liegen?

Ich kopiere ihr noch die Konfigs dazu:

drbd.conf

global {
usage-count yes;
}
common {
syncer { rate 100M; }
}

resource r0 {
protocol C;
handlers {
pri-on-incon-degr "echo o > /proc/sysrq-trigger ; halt -f";
pri-lost-after-sb "echo o > /proc/sysrq-trigger ; halt -f";
local-io-error "echo o > /proc/sysrq-trigger ; halt -f ";
}

startup {
degr-wfc-timeout 120; # 2 Minuten
}

disk {
on-io-error detach;
}
net {
}

syncer {
rate 100M;
al-extents 257;
}

on node1 {
device /dev/drbd0;
disk /dev/sda4;
address 192.168.183.11:7788;
meta-disk internal;
}

on node2 {
device /dev/drbd0;
disk /dev/sda4;
address 192.168.183.12:7788;
meta-disk internal;
}
}

ha.cf:

logfacility local0
keepalive 1
deadtime 10
ucast eth0 192.168.182.11
auto_failback off
node node1 node2

haresources

node1 IPaddr::192.168.182.10
node1 drbddisk::r0 Filesystem::/dev/drbd0::/drbd-mount::ext3 mysql

Könnt ihr mir bei diesen Problem helfen?
Danke.

nr8
19.01.11, 16:25
Hallo noch einmal.

Das mit dem MySQL hab ich hin bekommen. Das lauft jetzt fein.
Aber ich hab noch immer ein Problem.
Node1 ist Primary und Node2 ist Secondary.

DRBD und Heartbeat lauft.....
Ich nehme jetzt dem Node1 das Netzwerk weg.

Node2 übernimmt super mit allen Daten usw...
Das funktioniert perfekt.
Das Problem ist jetzt wenn Node1 wieder Online kommt. Node1 wird Primary geschalten aber DRBD verliert seine Verbindung:
Node1:

cs:StandAlone st:Primary/Unknown
Node2:

cs:StandAlone st:Secondary/Unknown

Das Problem an der Sache ist das Node1 jetzt mit dem alten Datenstand lauft und nicht mit dem Datenstand der sich schon verändert hat da Node2 ja als Primary während des "Ausfalls" gelaufen ist.

Könnt ihr mir da weiter helfen?
Danke.

EDIT:
Ich habe jetzt noch ein wenig getestet.
Es lauft alles so wie gewünscht. Wenn ich einen Server abdrehe (runterfahren) übernimmt der andere und wenn der Server wieder hochkommt bleibt er als Secondary. Das Passt alles.

Nur wenn ich hinten am Server die Netzwerkkarbel ziehe und dann später wieder anstecke (Dies passiert aber nur wenn ich die Kabel vom Primary ziehe) dann habe ich einen "Split-Brain"....
Ok. Das soll so sein. ABER was dabei NICHT sein darf ist das automatisch wenn dies vorkommt der Server der als Primary konfiguriert ist automatisch als Primary übernimmt weil es könnte ja sein das die Daten am Secondary neuer sind. Wenn jetzt aber der Primary online geht werden auf dem wieder Daten geschrieben und damit hab ich einen Datenstand den ich nie wieder herstellen kann.

Wie kann man sowsa umgehen?
Danke

Huhn Hur Tu
19.01.11, 18:54
Version????
Pacemaker oder Heartbeat.
Heartbeat2 aus dem Stable Repo ist veraltet, aktuelle ist Pacemaker mit Heartbeat oder Corosync.

Gruss Stefan

nr8
20.01.11, 09:14
Ich verwende Heartbeat mit DRBD.
Heatbeat habe ich von Debian selbst verwendet.
Heatbeat Version -> 2.1.3-6 64Bit
DRBD Version 8 64Bit

Weisst das jetzt das man Heartbeat mit DRBD nicht mehr verwenden sollte weil dies abgelöst wurde von Pacemaker und Corosync?

Huhn Hur Tu
21.01.11, 20:59
Haertbeat wurde nicht von Pacemaker abgeloest sondern der Cluster Resource manager wurde als eigenstaendiges Modul gemacht und Pacemaker genannt, Heartbeat ist der rest des alten Heartbeat und macht nur noch den Cluster Communication Manager.
Um Kompatibiliaet zu Proprietaeren HA Systemen zu haben wurde das Projekt OpenAIS gestartet um restlichen Heartbeat abzuloesen.
Das war soweit gut bis man bei RedHat auf die Idee kam, das geht auch noch Modularer und wir machen Corosync, was zwar funktioniert aber noch nicht (stand Fruehjahr) die ganze Funktionalitaet des alten Heartbeat hat. Durch Corosync schlief die Entwicklung an OpenAIS ein und kann als Tot betrachtet werden. Die Leute von DRBD, die auch aktiv im HA Bereich arbeiten empfehlen deswegen die Kombination Pacemaker/Heartbeat wegen der groesseren Stabilitaet da Corosync immer noch In einer sehr Veraenderlichen Entwicklung steckt (Probieren darf natuerlich jeder).

Anmerken darf ich nach eigenen Versuchen im Fruehjahr, das die Heartbeat2 Gui instabil wie Sau ist und nicht verwendet werden sollte.
Pacemaker bringt eine einigermassen Stabile Gui mit und viel interessanter eine taugliche Shell und Werkzeuge die sehr einfach geskriptet werden koennen.
Nur fuer den Fall, und ich weiss dass dies keiner ist, und du solltest ein ausgesprochener Masochist sein, dann Versuche doch mal im laufenden Betrieb an der XML Config was zu aendern. Wenn da was nicht stimmt ist dein Cluster in der Tonne.
Gui ist geil und noch geiler ist die CRM Shell von Pacemaker.


Viele Gruesse Stefan

P.S.:
Das ganze klingt jetzt sehr von oben herab, aber glaube mir ich habe viele Wochen in das Bewustwerden obiger Tatsachen investiert, tu dir einen Gefallen und glaube mir einfach dass HB2 nicht verwendet werden sollte.

Svenny
24.01.11, 07:51
Wir haben auch einige MySQL Server, welche hochverfügbar sind.
Wenn du im Netz schaust sind viele Ideen wie du sie hast mit /var/lib/mysql aufs drbd legen kommentiert mit "Don't do that"....
MySQL hat eine eigene Replicationsmöglichkeit, welche durchaus nutzbar ist.



Nur wenn ich hinten am Server die Netzwerkkarbel ziehe und dann später wieder anstecke (Dies passiert aber nur wenn ich die Kabel vom Primary ziehe) dann habe ich einen "Split-Brain"....
Ok. Das soll so sein. ABER was dabei NICHT sein darf ist das automatisch wenn dies vorkommt der Server der als Primary konfiguriert ist automatisch als Primary übernimmt weil es könnte ja sein das die Daten am Secondary neuer sind. Wenn jetzt aber der Primary online geht werden auf dem wieder Daten geschrieben und damit hab ich einen Datenstand den ich nie wieder herstellen kann.

Da gibt es doch eine entsprechende Einstellung, dass der eigentliche Primary nach dem Takeover bis zur manuellen Zurückschaltung Secondary bleibt.
Zur not schieß ihn ab (Stonith).

nr8
24.01.11, 09:20
@Huhn Hur Tu: Vielen dank für die vielen Infos.
Ich werde jetzt einmal mit dem System so leben müssen wie es lauft da es morgen online gehen muss.

Aber ich werde mich die nächsten Tage noch weiter mit diesem Thema beschäftigen.

@Svenny: Ich werde schauen das ich dies finde...
Danke.

Huhn Hur Tu
24.01.11, 12:26
Ein Update von HB2 auf Pacemaker/HB3 ist relativ schmerzfrei wenn man mal weiss wie das ganze funzt.
Ich kann nur Zustimmen dass es sinnvoller ist MySQL auf eigener Replikation laufen zu lassen, da im Stecker raus Fall die letzte Transaktion eben defekt sein kann.

Gruss Stefan

OliverH
24.01.11, 16:35
Ein Update von HB2 auf Pacemaker/HB3 ist relativ schmerzfrei wenn man mal weiss wie das ganze funzt.
Ich kann nur Zustimmen dass es sinnvoller ist MySQL auf eigener Replikation laufen zu lassen, da im Stecker raus Fall die letzte Transaktion eben defekt sein kann.

Gruss Stefan

Gilt das auch bei Verwendung von InnoDB (sprich bei vorhandenem Transaktionslog)?

Gruß,
Oli

Huhn Hur Tu
25.01.11, 11:13
Hier kommt die drei "T" Regel zum Tragen.
Testen testen testen.
Auch ein InnoDB kann geschrottet werden wenn das zugrundeliegende FS kaputt ist und die Fehler per DRBD repliziert werden.
Hier kommt die wichtigste Regel im HA Betrieb zum tragen. Die drei "R" Regel.
Redundanz Redundanz Redundanz.

Gruss Stefan

OliverH
26.01.11, 08:34
Hier kommt die drei "T" Regel zum Tragen.
Testen testen testen.
Auch ein InnoDB kann geschrottet werden wenn das zugrundeliegende FS kaputt ist und die Fehler per DRBD repliziert werden.
Hier kommt die wichtigste Regel im HA Betrieb zum tragen. Die drei "R" Regel.
Redundanz Redundanz Redundanz.

Gruss Stefan

Dass InnoDB ein defektes FS nicht überlebt ist klar.
Da Ext3/4 jedoch journaling fs sind, sollte ein Defekt eigentlich nicht auftreten.

Wichtiger als die 3R-Regel ist die 5T-Regel ;-) (Testen Testen Testen...)

Oli

Huhn Hur Tu
27.01.11, 00:46
Klug*******en ist einfach geil:D

Gruss Stefan