PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : drbd läuft nur über öffentliches interface



magaltman
29-05-2008, 21:34
Hallo,

ich sitze hier an einem SUSE Linux Enterprise Server 10 SP1 (i586) und versuche krampfhaft drbd zum Laufen zu bekommen.
Vorhanden sind zwei SuSEs mit jeweils zwei Netzwerkinterfaces.
Ich bin der Meinung es richtig konfiguriert zu haben, aber die beiden Nodes "sehen" sich einfach nicht. Ich bekomme die beiden System einfach nicht dazu sich zu syncen und "Consistent" zu schalten.
Alle Suchmaschinen lassen mich mal wieder im Stich, also scheint es mal wieder was ganz triviales zu sein.

Lasse ich drbd über das interne Netz "laufen" passiert nichts.


$ cat /proc/drbd
version: 0.7.22 (api:79/proto:74)
SVN Revision: 2572 build by lmb@dale, 2006-10-25 18:17:21
0: cs:WFConnection st:Secondary/Unknown ld:Consistent
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0
1: cs:Unconfigured


Jede gefundene Doku hat einen anderen Weg zum erstmaligen Sync. Passieren tut aber immer nichts. Ein

$ drbdadm primary all
bringt auf dem ersten Knoten immerhin ein "Primary/Unknown" beim state-Feld. Syncen tut er aber immer noch nicht.
Konfiguriere ich drbd allerdings auf die öffentlichen IP-Adressen, geht's weiter wie in den Dokus versprochen.

$ cat /proc/drbd
zeigt einen Fortschrittsbalken bis zum Schlussendlichen sync bzw Diskstatus "Consistent".
Jetzt bleibt also nur noch die Frage: Was mache ich falsch?

So jetzt die Details:

Habe auch keine Ahnung, wo das "1: cs:Unconfigured" herkommt. Die meisten Dokus haben nur eine Ressource definiert oder eben zwei (dann macht's ja auch Sinn).

Die Pakete
drbd
drbd-kmp-default
sind in der Version 0.7.22 installiert.

Doku, die ich bisher so gefunden habe, bezieht sich entweder auf 0.6 oder 0.8 :-( . Jeder scheint es irgendwie anders zu machen, bisher gab es noch keine Deckungsgleiche Doku.

Etwas googeln ergab dann
http://www.linux-magazin.de/heft_abo/ausgaben/2004/07/reservespieler/(kategorie)/0%22
http://www.linux-magazin.de/heft_abo/ausgaben/2004/07/reservespieler/(kategorie)/0%22
http://www.linux-ha.org/DRBD/FAQ
http://www.tecchannel.de/server/linux/1741277/

192.168.1.X soll hierbei die Schnittstelle für DRBD und heartbeat werden, auf der jeweils zweiten Netzwerkkarte
192.168.10.X sollen dann die öffentliche Schnitstelle sein, auf der ersten Netzwerkkarte.
Die Rechner heißen knoten1 und knoten2.


knoten1:
eth0 192.168.10.233 (öffentlich)
eth1 192.168.1.50 (privat mit "Crossover-Kabel")



knoten2:
eth1 192.168.10.232 (öffentlich)
eth2 192.168.1.51 (privat mit "Crossover-Kabel")

zusätzlich habe die Hosts noch in die /etc/hosts mit aufgenommen (bei beiden Rechnern)


$ cat /etc/hosts
192.168.1.51 knoten2
192.168.10.232 knoten2
192.168.10.233 knoten1
192.168.1.50 knoten1


knoten1:/etc # route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0


knoten2:/etc # route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1

Das anpingen über die jeweiligen Interfaces geht.

knoten1:/etc # ping -I eth1 192.168.1.51

funktioniert.


knoten1:/etc # ping -I eth0 192.168.1.51

Funktioniert erwartungsgemäß nicht.

Danach habe die Devices angelegt und das Modul geladen auf beiden Systemen


$ for i in `seq 0 15` ; do mknod -m 0660 /dev/drbd$i b 147 $i; done

$ modprobe drbd

$ drbdadm up all

$ /etc/init.d/drbd start


Ergibt dann nur ein:


Starting DRBD resources: [ ].
..........
************************************************** *************
DRBD's startup script waits for the peer node(s) to appear.
- In case this node was already a degraded cluster before the
reboot the timeout is 120 seconds. [degr-wfc-timeout]
- If the peer was available before the reboot the timeout will
expire after 60 seconds. [wfc-timeout]
(These values are for resource 'drbd0'; 0 sec -> wait forever)
To abort waiting enter 'yes' [ 59]:


Grummel. Alles was google&Co so ausspucken sind Konfig-Fehler in der drbd.conf . Ich vermute mal, dass ich die aber nicht habe, da die ja über das öffentliche Netz ja läuft?!



$ cat /etc/drbd.conf

global {
minor-count 2;
}

resource drbd0{
protocol C; # oder A oder B
disk {
on-io-error panic;
}
startup {
wfc-timeout 60;
degr-wfc-timeout 120;
}
net {
timeout 60; # 0.1 Sekunden
connect-int 10; # Sekunden
ping-int 10; # Sekunden
}
on knoten1 {
device /dev/drbd0;
disk /dev/sdb1;
#address 192.168.10.233:7888;# läuft
address 192.168.1.50:7888; # läuft nicht
meta-disk internal;
}
on knoten2 {
device /dev/drbd0;
disk /dev/sdb1;
#address 192.168.10.232:7888;# läuft
address 192.168.1.51:7888; # läuft nicht
meta-disk internal;
}
syncer { rate 10M;
group 1;
}
}

So wie sie jetzt ist (mit 192.168.1.5[0|1] ) passiert nichts bzw folgende Ausgabe


knoten1:/etc # /etc/init.d/drbd start
Starting DRBD resources: [ ].
..........
************************************************** *************
DRBD's startup script waits for the peer node(s) to appear.
- In case this node was already a degraded cluster before the
reboot the timeout is 120 seconds. [degr-wfc-timeout]
- If the peer was available before the reboot the timeout will
expire after 60 seconds. [wfc-timeout]
(These values are for resource 'drbd0'; 0 sec -> wait forever)
To abort waiting enter 'yes' [ 59]:


knoten1:/etc # cat /proc/drbd
version: 0.7.22 (api:79/proto:74)
SVN Revision: 2572 build by lmb@dale, 2006-10-25 18:17:21
0: cs:WFConnection st:Secondary/Unknown ld:Consistent
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0
1: cs:Unconfigured



knoten2:/etc # cat /proc/drbd
version: 0.7.22 (api:79/proto:74)
SVN Revision: 2572 build by lmb@dale, 2006-10-25 18:17:21
0: cs:WFConnection st:Secondary/Unknown ld:Consistent
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0
1: cs:Unconfigured


knoten1:/etc # drbdadm primary all

Ergibt immerhin ein


knoten1:/etc # cat /proc/drbd
version: 0.7.22 (api:79/proto:74)
SVN Revision: 2572 build by lmb@dale, 2006-10-25 18:17:21
0: cs:WFConnection st:Primary/Unknown ld:Consistent
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0
1: cs:Unconfigured

Aber glücklich macht es auch nicht, da
cat /proc/drbd keine andere Ausgabe produziert.

Auch ein vielfach beschriebenes


knoten1:/etc # drbdadm -- --do-what-I-say primary all
knoten1:/etc # drbdadm primary all
knoten1:/etc #

Tut nada.

Fahre ich es bei beiden wieder runter

$ /etc/init.d/drbd stop

Und tauschen in beiden drbd.conf die IP-Adressen 192.168.1.5[0|1] gegen die 192.168.10.[232|233] aus und starte drbd neu


$ /etc/init.d/drbd start
(erst auf knoten1 und dann auf knoten2)



$ /etc/init.d/drbd start
Starting DRBD resources: [ d0 s0 n0 ].
........
$ cat /proc/drbd
version: 0.7.22 (api:79/proto:74)
SVN Revision: 2572 build by lmb@dale, 2006-10-25 18:17:21
0: cs:Connected st:Secondary/Secondary ld:Consistent
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0
1: cs:Unconfigured

Auf beiden nodes. Mache ich jetzt knoten1 zum primary



knoten1:/etc # drbdadm primary all

knoten1:/etc # cat /proc/drbd
version: 0.7.22 (api:79/proto:74)
SVN Revision: 2572 build by lmb@dale, 2006-10-25 18:17:21
0: cs:Connected st:Primary/Secondary ld:Consistent
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0
1: cs:Unconfigured


knoten2:/etc # cat /proc/drbd
version: 0.7.22 (api:79/proto:74)
SVN Revision: 2572 build by lmb@dale, 2006-10-25 18:17:21
0: cs:Connected st:Secondary/Primary ld:Consistent
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0
1: cs:Unconfigured


Sieht alles gut aus. Alles andere klappt dann auch. Den weiteren Weg mounten / umouten auf primary und secondary klappt dann. Hab schon mal testweise ein Dateisystem auf /dev/drbd0 erstellt und dann (in diesem Fall /daten ) eingehängt, eine Datei erstellt und mir dann auf dem knoten2 angesehen (nachdem ich ihn zum primary gemacht habe).

Aber, ich will diese Konfig ja so nicht. drbd soll ja über das private Interface laufen und nicht wie jetzt über das öffentliche Netz. Aber das will ja irgendwie nicht. So falsch kann mein Weg doch nicht sein, oder? Was mache ich falsch? Habe ich irgendwo einen Denkfehler?

WYS

mag

valhalla
30-05-2008, 19:57
Hi,

schau mal da vielleicht hilft dir das weiter.
http://www.looony.de/index.php/archives/11

magaltman
06-06-2008, 13:38
Hi,

schau mal da vielleicht hilft dir das weiter.
http://www.looony.de/index.php/archives/11

Hm, zumindestens das Video war gut und hat ein paar Unklarheiten beseitigt.
Mein Problem war mal wieder ein typischer PBK-Error (Problem before Keyboard) - wie auch nicht anders zu erwarten.

Meine Ausreden:

System wurde von Kollegen eingerichtet
System wurde von Kollegen konfiguriert
lange nicht mehr vor SuSE gesessen.


Fazit: Die ungewohnte SuSE-Firewall (oder wie das Paket nochmal heisst) Hole das zweite Interface in die interne Zone und schon klappt's mit dem Nachbarn. :o

So jetzt zickt noch das heartbeat, aber das werde ich wohl händisch nachbilden. (manuellen Hochfahren der Dienste), die Lust daran ist mir vergangen. Nur schäbbige warnings und jede im Netz gefundene Doku macht es anders. :mad:

valhalla
20-06-2008, 15:00
was hast du den genau für ein Problem ?

magaltman
22-06-2008, 23:08
Hallo, sorry dass ich jetzt erst antworte.


was hast du den genau für ein Problem ?

- ping auf die Definierte "Master"-IP geht nicht
- ifconfig sacht nix
- definierte Daemonen (wie smb, atalk und nfs) fahren nicht hoch

In den Logs stehen aber beide nodes drin und so wie es aussieht finden die sich auch. Ich hatte leider noch ein paar Projekte nebenbei laufen und bin noch am forschen bzw logs auswerten. In den Logs steht eine Menge drin, aber bisher noch nichts aussagekräftiges.
Wichtig zu erwähnen wäre noch, dass das beides virtuelle Maschinen sind und sich diese auf einem ESX-Server befinden.
Wenn ich das umschalten der IPs nämlich händisch anstoße, d.h.


node1 $: ifconfig eth0:0 down
node2 $: ifconfig eth0:0 193.xxx.xxx.xxx

ist die 193 nicht anpingbar. Vermutlich fuhrwerkt da noch ein ESX-Cache rum und ich muss in der vmware-Konfig nochmal rumklicken.
Leider hat sich jetzt mein Chef dafür entschieden die beiden Server nur mit drbd laufen zu lassen (was ja jetzt geht) und den TakeOver lieber manuell zu machen . Er traut heartbeat nicht, obwohl ich das in einer anderen Firma schon mal hab wunderbar laufen sehen. Insofern sind ja jetzt meine Probleme gelöst.
Interessieren würde es mich aber schon, warum heartbeat nicht läuft.
Dafür müsste ich aber erstmal die Logs durchwühlen um konkrete Fragen stellen zu können.


Mag