DRBD Probleme unter Volllast

[cartmen]

Hallo,

heut komme ich mal wieder mit schwierigen Problemen. Wir haben 2 Server mit Debian Kernel 2.6.18-6. Auf den Servern läuft Xen 3.2.1 aus Backports und DRBD 8.0.7 auch aus Backports. Wir haben 8 VMs gestartet und alles funktioniert auch ohne Probleme. Migration und auch Heartbeat funktioniert auch ohne Probleme. Wenn ich jetzt allerdings von einem externen Server große Datenmengen auf eine VM schicke dann bricht die DRBD Verbindung zusammen. Die DRBD Verbindung würd über eine Gigabit-Verbindung hergestellt, die Bridge für die VMs über eine andere Netzwerkkarte. Die Syncrate ist auf 10M eingestellt. Wir sind mit unserem Wissen am Ende.

Hier mal der Auszug aus dem Log:


Mar 29 01:27:10 fry kernel: drbd2: PingAck did not arrive in time.
Mar 29 01:27:10 fry kernel: drbd2: peer( Secondary -> Unknown ) conn(
Connected -> NetworkFailure ) pdsk( UpToDate -> DUnknown )
Mar 29 01:27:10 fry kernel: drbd2: Creating new current UUID
Mar 29 01:27:10 fry kernel: drbd2: asender terminated
Mar 29 01:27:10 fry kernel: drbd2: short read expecting header on sock:
r=-512
Mar 29 01:27:11 fry kernel: drbd2: tl_clear()
Mar 29 01:27:11 fry kernel: drbd2: Connection closed
Mar 29 01:27:11 fry kernel: drbd2: Writing meta data super block now.
Mar 29 01:27:11 fry kernel: drbd2: conn( NetworkFailure -> Unconnected )
Mar 29 01:27:11 fry kernel: drbd2: receiver terminated
Mar 29 01:27:11 fry kernel: drbd2: receiver (re)started
Mar 29 01:27:11 fry kernel: drbd2: conn( Unconnected -> WFConnection )
Mar 29 01:27:11 fry kernel: drbd2: conn( WFConnection -> WFReportParams )
Mar 29 01:27:11 fry kernel: drbd2: Handshake successful: DRBD Network
Protocol version 86
Mar 29 01:27:11 fry kernel: drbd2: peer( Unknown -> Secondary ) conn(
WFReportParams -> WFBitMapS ) pdsk( DUnknown -> UpToDate )
Mar 29 01:27:22 fry kernel: drbd2: PingAck did not arrive in time.
Mar 29 01:27:22 fry kernel: drbd2: peer( Secondary -> Unknown ) conn(
WFBitMapS -> NetworkFailure ) pdsk( UpToDate -> DUnknown )
Mar 29 01:27:22 fry kernel: drbd2: asender terminated
Mar 29 01:27:28 fry kernel: drbd2: short sent ReportBitMap size=4096
sent=3512
Mar 29 01:27:28 fry kernel: drbd2: Writing meta data super block now.
Mar 29 01:27:28 fry kernel: drbd2: md_sync_timer expired! Worker calls
drbd_md_sync().
Mar 29 01:27:28 fry kernel: drbd2: md_sync_timer expired! Worker calls
drbd_md_sync().
Mar 29 01:27:28 fry kernel: drbd2: tl_clear()
Mar 29 01:27:28 fry kernel: drbd2: Connection closed

Vielleicht könnt ihr damit ja etwas anfangen. Vielen Dank für eure Hilfe.

[x86-64]

Hallo,

heut komme ich mal wieder mit schwierigen Problemen. Wir haben 2 Server mit Debian Kernel 2.6.18-6. Auf den Servern läuft Xen 3.2.1 aus Backports und DRBD 8.0.7 auch aus Backports. Wir haben 8 VMs gestartet und alles funktioniert auch ohne Probleme. Migration und auch Heartbeat funktioniert auch ohne Probleme. Wenn ich jetzt allerdings von einem externen Server große Datenmengen auf eine VM schicke dann bricht die DRBD Verbindung zusammen. Die DRBD Verbindung würd über eine Gigabit-Verbindung hergestellt, die Bridge für die VMs über eine andere Netzwerkkarte. Die Syncrate ist auf 10M eingestellt. Wir sind mit unserem Wissen am Ende.

Hier mal der Auszug aus dem Log:

Vielleicht könnt ihr damit ja etwas anfangen. Vielen Dank für eure Hilfe.


Stell mal die Sync-Rate höher. 40-50 MB/s sollten für aktuelle Platten und Netzwerkhardware kein Problem sein. Bei schnellen Raid-Controllern mit vielen Platten kannst sogar noch höher gehen.

Auf welchen Protokoll (a,b oder c) läuft das drbd ?

[cartmen]

Also wir hatten die Rate vorher auf 100M eingestellt. Allerdings erzeugt das bei ziemlich viel Last, wenn doch mal alle Devices gesynced werden sollen. Achso es sind ingesamt 9 DRBD Devices mit unterschiedlichen Größen. Wir verwenden für alle das Protokoll C.

[bla!zilla]

Stell mal die Sync-Rate höher. 40-50 MB/s sollten für aktuelle Platten und Netzwerkhardware kein Problem sein. Bei schnellen Raid-Controllern mit vielen Platten kannst sogar noch höher gehen.

Auf welchen Protokoll (a,b oder c) läuft das drbd ?

40 bis 50 MB sind für eine Einzelplatte kein Problem, ein RAID bringt aber nicht die Leistung von n-Platten, vor allem, wenn Read- und Write IOs gleichzeitig auf das Array einschlagen. Dazu vielleicht mal ein paar hilfreiche Links:

Link 1 (http://www.blazilla.de/index.php?/archives/269-IOPS-Kalkulation.html)
Link 2 (http://www.blazilla.de/index.php?/archives/270-MBs-vs.-IOPS.html)
Link 3 (http://www.blazilla.de/index.php?/archives/311-Die-richtige-Chunksize.html)


Also wir hatten die Rate vorher auf 100M eingestellt. Allerdings erzeugt das bei ziemlich viel Last, wenn doch mal alle Devices gesynced werden sollen. Achso es sind ingesamt 9 DRBD Devices mit unterschiedlichen Größen. Wir verwenden für alle das Protokoll C.

Was für ein IO System habt ihr darunter?

- Wieviele Platten
- Was für Platten
- RAID Level
- RAID Controller oder Software-RAID
- Wenn Markenhardware, was für ein Hersteller und Modell
- Ist die DRBD Verbindung über eine dedizierte Gigabit-Verbindung realisiert?

[marce]

Wenn ich jetzt allerdings von einem externen Server große Datenmengen auf eine VM schicke dann bricht die DRBD Verbindung zusammen. Die DRBD Verbindung würd über eine Gigabit-Verbindung hergestellt
zusätzlich zu den Fragen von bla!zilla:

GB direkt oder über einen Switch? Gibt's parallel zum Einbruch Netzwerk-Fehler? Evtl. mal ein NetIO drüberrattern lassen zum Test...
bricht die Verbindung auch zusammen, wenn Du in einer VM lokal ein dd startest? Was sägt denn ein top / vmstat parallel zum Transfer?

[cartmen]

Es gibt leider kein Raid, weder Sortware noch Hardware. In den Kisten ist nur eine Platte drin. Es ist eine SAMSUNG SP2514N mit 250GB. Wir haben 50GB für die Dom0 gelassen und der Rest ist auf das DRBD aufgeteilt. Es handelt sich hierbei um eine Sata-Platte. Kann auch die Tatsache, dass DRBD und normales Dateisystem auf einer Platte sind, für solche Probleme sorgen? Die Gigabitverbindung wird über eine Direktverbindung hergestellt. Es sind einfach die beiden Gigabitports auf den Mainboards durch ein Cat5e Kabel verbunden. Sobald das DRBD zusammenbricht kriegt das DRBD auf einer Seite immer den Status "Networkfailure". Sonst sind mir keine Fehler aufgefallen, es gibt auch keine Drops oder ähnliches. Die anderen Tests, wie dd kann ich erst heut Abend machen. Ich kann nurnoch sagen, dass ein Test mit iperf ohne Probleme mit einer Bandbreite von >900MBit läuft. Es kommt da auch nicht zu Fehlern oder Einbrüchen.

[bla!zilla]

Bitte mal per vmstat nachsehen was die Kiste da so treibt. Ich tippe auf ein IO Problem im Bereich Platte / Netzwerk.

[marce]

Was sagt denn der Bus, wenn über Netz xMbit reinkommen, auf HD geschrieben werden, dann von dort wieder gelesen und dann noch per Netz ausgegeben werden?

Da könnte ich mir einen Engpass auch durchaus vorstellen...

[bla!zilla]

So über den Daumen gepeilt bringt die Platte 80 IOPS. Die in Tests erreichten im Schnitt 55 MB/s (schreiben bzw. lesen) halte ich bei einer Transfersize von umgerechnet 640 KB für realistisch.

Da hilft nur eins: Mehr Platten, mehr IOPS.

[cartmen]

So ich hab den Fehler dann nochmal provoziert. Also wenn das alles noch geht und das System unter geringer Last steht sieht das so aus:



root@fry:/# vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 96 19532 5812 48528 0 0 67 18 149 47 0 0 100 0

root@fry:/# iostat -m
Linux 2.6.18-6-xen-amd64 (fry) 31.03.2008

avg-cpu: %user %nice %system %iowait %steal %idle
0,04 0,00 0,11 0,07 0,07 99,71

Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn
hda 6,96 0,15 0,06 8847 3230


kurz vor dem Zusammenbruch:



root@fry:/# vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 96 14564 6256 48664 0 0 66 28 173 49 0 0 100 0

root@fry:/# iostat -m
Linux 2.6.18-6-xen-amd64 (fry) 31.03.2008

avg-cpu: %user %nice %system %iowait %steal %idle
0,04 0,00 0,13 0,07 0,08 99,68

Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn
hda 7,04 0,15 0,07 8847 4338


und während des Zusammenbruchs:


root@fry:/# vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 96 14572 6300 48684 0 0 66 29 177 49 0 0 100 0

root@fry:/# iostat -m
Linux 2.6.18-6-xen-amd64 (fry) 31.03.2008

avg-cpu: %user %nice %system %iowait %steal %idle
0,04 0,00 0,14 0,07 0,08 99,68

Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn
hda 7,08 0,15 0,08 8847 4817


Der Rsync von außen geht auch weiter nachdem die Verbindung zusammen gebrochen ist nur das im DRBD der Status WFConnection oder NetworkFailure steht.

[bla!zilla]

Da ändert sich ja gar nichts.... Sieht sehr merkwürdig aus.

[cartmen]

Du sagst es. Deswegen wundert mich das Ganze ja auch. Passiert mir das erste Mal, dass sich das so verhällt. Nach dem Zusammenbruch haben beide Maschinen einen Load von 3 und das DRBD lässt sich nicht stoppen.



Stopping all DRBD resourcesChild process does not terminate!
Exiting.
ERROR: Module drbd is in use


Die Prozesse hängen sich auch auf:



root@fry:/# ps wax |grep D
PID TTY STAT TIME COMMAND
3686 ? D 0:00 [drbd1_receiver]
3694 ? D 0:04 [drbd2_receiver]
3734 ? D 0:00 [drbd5_receiver]

Es sind aber alle VMs heruntergefahren also ist das auch nicht mehr in Benutzung. Übrigens passiert die Trennung meist wenn grad große Dateien gesynct werden, also um die 700MB. Wenn man das mit vielen kleinen Dateien macht passiert nix.

[bla!zilla]

Steig mal bitte auf Protokoll A um.

[cartmen]

Das bringt leider garnix, es wird sogar noch schlimmer, da die Verbindung jetzt sogar ohne Last zusammenbricht, sich verbindet, zusammenbricht und so weiter.

[McAldo]

Gibt es denn nun schon eine Lösung für das Problem?

Bei mir wird offenbar das Socket auf einem der Server nicht gebildet. :(

McAldo