Serverbetrieb mit MDADM - furchtbar langsam

[Hobbystern]

Hallo Gemeinde,

ich nutze aus Freude seit Jahren Debian - bin sehr zufrieden. Das vorweg.

Ich habe einen Dateiserver der damals ein kleines, heute ein sehr gewachsenens Paket Namens "VmWare Server 1.0.10" beherbergt

Das ganze ist so aufgesetzt das :

3 SATA2 - HDDs je 2 Partitionen haben:
Die 1. (kleine) stellt 30 GBs für ein mdadm-RAID1 als BOOT und ROOT.
Die 2. (große) stellt den Rest (ca. 1TB) für ein mdadm-RAID5 als FREIGABE.

Die HDDs sind in einem HDDCase Einschub verbaut, es wäre als möglich noch mehrere Festplatten einzusetzen, oder eine hot zu tauschen. **Alle HHDs hängen an separaten SATA Kabel, jedoch leider an einem Controller**

Im System selber sind noch weitere Festplatten zu Backup-Zwecken verbaut, sowie 2 externe zu selbigem Zweck angeschlossen.

Das Grundsystem ist ein Debian Lenny seit ca. einem Monat - davor Etch. Ich bin eher ein Update-Muffel (ausser Security).

Die VMWARE stellt ein 24/7 Windows XP mit MSSQL Server 2005 und einem Kassenabrechnungssystem - also hochkritische Daten - die ich gerne und oft als Snapshot sichere (je nach Last habe ich meine Skripte laufen)

Der Rest vom PC ist hier eigentlich unwichtig - aber der Vollständigkeit halber ist es ein P4 mit 3,4Ghz (HP ProLiant) mit 4GB ECC RAM.

Mein Problem besteht darin, dass die ganze Kiste in der letzten Zeit furchtbar langsam geworden ist - hdparm gibt eine Leserate von ~40 aus für das RAID5, 20 für RAID1, als Vergleich - 70 für eine stinknormale SATA HDD ohne mdadm. MDADM gibt functional aus, ist also kein Problem vorhanden, welches ich fixen könnte.

Die Ausgabe von mdstat sieht so aus :

Code: Alles auswählen

Personalities : [raid1] [raid6] [raid5] [raid4] 
md1 : active raid5 sdb2[0] sdd2[2] sdc2[1]
      879108736 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]
      
md0 : active raid1 sdb1[0] sdd1[2] sdc1[1]
      43945664 blocks [3/3] [UUU]
      
unused devices: <none>

Was ich nunmehr aus meiner eigenen Erfahrung heraus tun könnte, wäre :

- Die HDDs an mehrere Controller verteilen (Last drücken-ggf. muss mdadm warten?)
- Einen "echten" HWRaid Controller einsetzen (3Ware zBsp.)

Der Grund warum ich mdadm nutze ist bestechend simpel - es gab vor zahlreichen Jahren ein verlängertes Wochenende (ich meine Pfingsten) - wo mich mein damaliger Windows Server mit einem HWRAID verlassen hatte, der Controller war durchgeraucht, die Festplatten übel zugerichtet. Da es lange geplant war -habe ich den Server nach langem hin und her (und einem fehlenden HW Controller von HP) auf Debian gebracht und mdadm eingesetzt - das hat mich zwar schon hier und da mal überrascht, war aber immer und ohne HW Spielereien wieder aufzubauen. Das fand ich klasse. Die CPU Last ist eine andere Sache.

Als Dienste im Zugriff per "iotop" sehe ich hier reichhaltig pdflush, kjournald und natürlich vmware - hier ein shot :

Code: Alles auswählen

 6020 root       13.48 M/s       0 B/s  0.00 % 66.35 % rsync -aeH --delete --exclude=/proc --exclude=/sys --exclude=backu* / /backup-500gb-ext
 6535 root        2.64 M/s       0 B/s  0.00 % 36.15 % clamscan --quiet -ir --scan-mail=yes --tempdir=/tmp --log=/var/log/clam-scanner.log --s
 6327 root      984.57 K/s    3.85 K/s  0.00 % 31.24 % vmware-vmx -C /freigabe/vm-server/WindowsSQL/WindowsVM.vmx -@ ""
 6326 root      246.14 K/s       0 B/s  0.00 % 20.14 % vmware-vmx -C /freigabe/vm-server/WindowsSQL/WindowsVM.vmx -@ ""
 6328 root     1011.49 K/s       0 B/s  0.00 % 18.95 % vmware-vmx -C /freigabe/vm-server/WindowsSQL/WindowsVM.vmx -@ ""
 6324 root      430.75 K/s    3.85 K/s  0.00 % 17.83 % vmware-vmx -C /freigabe/vm-server/WindowsSQL/WindowsVM.vmx -@ ""
 7540 root           0 B/s   61.54 K/s  0.00 % 15.43 % [kjournald]
 6325 root      776.89 K/s       0 B/s  0.00 %  9.92 % vmware-vmx -C /freigabe/vm-server/WindowsSQL/WindowsVM.vmx -@ ""
 6802 root           0 B/s    3.85 K/s  0.00 %  7.75 % [pdflush]
 6329 root      738.43 K/s       0 B/s  0.00 %  6.28 % vmware-vmx -C /freigabe/vm-server/WindowsSQL/WindowsVM.vmx -@ ""
 6798 root        3.85 K/s  584.59 K/s  0.00 %  4.95 % [pdflush]
 6319 root           0 B/s  473.05 K/s  0.00 %  0.00 % vmware-vmx -C /freigabe/vm-server/WindowsSQL/WindowsVM.vmx -@ ""
 6330 root           0 B/s   15.38 K/s  0.00 %  0.00 % vmware-vmx -C /freigabe/vm-server/WindowsSQL/WindowsVM.vmx -@ ""
 6331 root           0 B/s    3.39 M/s  0.00 %  0.00 % vmware-vmx -C /freigabe/vm-server/WindowsSQL/WindowsVM.vmx -@ ""
 6022 root           0 B/s   12.98 M/s  0.00 %  0.00 % rsync -aeH --delete --exclude=/proc --exclude=/sys --exclude=backu* / /backup-500gb-ext

In diesem Beispiel gibt iotop die Last gesamt so aus (und das bringt das System schon dazu meine Befehle einzeln binnen 5-10 Sekunden Wartezeit auszuführen (zbsp. das editieren einer datei dauert beim lesen so lange)

Code: Alles auswählen

Total DISK READ: 20.21 M/s | Total DISK WRITE: 17.49 M/s

Testweise habe ich mal vmware komplett gestoppt und auch die Module entladen, BackupJobs gestoppt, alle möglichen Lasten beseitigt, das Problem war dasselbe - der Server braucht sehr lange um HDD Operationen durchzuführen, s.h. auch mit einem Umstieg von VM auf zBsp VirtualBox wäre mir nicht geholfen, da die Grundstruktur nicht okay ist.

Das Ärgerliche ist, das dass System nun seit 2 Jahren in dieser Konfig läuft und erst seit ca. 6 Monaten beginnt langsamer zu werden. Smartmontools ist übrigends installiert und findet auch bei extended test keine auffälligkeiten

Habt ihr einen guten Rat der vielleicht nicht nur der Rat nach einem HW Controller ist...?!

LG Stefan

EDIT

Ich habe gerade mal smartctl nach allen Errors auf den Platten abgefragt und dieses hier über die 3 Partitionen gesammelt :

1

Code: Alles auswählen

Error 10 occurred at disk power-on lifetime: 5787 hours (241 days + 3 hours)
  40 51 00 db 02 3d 05  Error: UNC at LBA = 0x053d02db = 87884507
Error 9 occurred at disk power-on lifetime: 5787 hours (241 days + 3 hours)
  40 51 00 db 02 3d 05  Error: UNC at LBA = 0x053d02db = 87884507
Error 8 occurred at disk power-on lifetime: 5787 hours (241 days + 3 hours)
  40 51 00 db 02 3d 05  Error: UNC at LBA = 0x053d02db = 87884507
Error 7 occurred at disk power-on lifetime: 5787 hours (241 days + 3 hours)
  40 51 00 db 02 3d 05  Error: UNC at LBA = 0x053d02db = 87884507
Error 6 occurred at disk power-on lifetime: 5787 hours (241 days + 3 hours)
  40 51 00 db 02 3d 05  Error: UNC at LBA = 0x053d02db = 87884507

2

Code: Alles auswählen

No Errors Logged

3

Code: Alles auswählen

  1 Raw_Read_Error_Rate     0x000f   116   099   006    Pre-fail  Always       -       107705842
  7 Seek_Error_Rate         0x000f   084   060   030    Pre-fail  Always       -       253807216
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
SMART Error Log Version: 1
No Errors Logged

Habe ich mir damit ggf. selber die Antwort gegeben? HDD 1 scheint ein Problem zu haben und auch HDD 3 sieht nicht so rosig aus - würde ich als smart anfänger sagen ....

[pluvo]

[...], als Vergleich - 70 für eine stinknormale SATA HDD ohne mdadm.

Welche? Hast du die Festplatten (sdb, sdc, sdd) schon mal einzeln mit hdparm getestet? Wenn ja, welche Ergebnisse hattest du? (Alle unnötigen Dienste deaktivieren)

Kannst du ausschließen, dass dein HDDCase irgendwie Probleme macht? Sind die Festplatten direkt am Mainboard angeschlossen, oder hat dieses HDDCase eine eigene Platine?

Was für ein SATA-Controller hast du? Und an dem hängen also 5 Festplatten?

[Hobbystern]

Gute Nacht pluvo,

(bitte beachte den EDIT oben - ich habe gerade mal smartctl laufen lassen...jetzt läuft ein extended test auf allen beteiligten laufwerken)

Hast du die Festplatten (sdb, sdc, sdd) schon mal einzeln mit hdparm getestet?

Jein - ich kann sie nur unter Last ansprechen, einen richtig ruhigen Rahmen gäbe es nur jetzt - dann allerdings unter beenden aller Wartungsaufgaben, nach dem Ergbnis von smartctl denke ich nunmehr etwas anders

Kannst du ausschließen, dass dein HDDCase irgendwie Probleme macht?

Technisch ja - wäremtechnisch bin ich etwas skeptisch - smart meldet 40°C je Platte, das wäre mehr als optimal

Sind die Festplatten direkt am Mainboard angeschlossen

Sie liegen an einem Adaptec SATA RAID-Controller, einem "unechten" mit 4 Anschlüssen, möglich wäre die Halbierung und Nutzung der Mainboard-Anchlüsse, also zBsp 2 und 2.



Nachdem ich einen definitiven FailureOutput von smartctl erhalten habe - für eine HDD auf jedenfall - habe ich mir gerade 3 Neue bestellt, ich werde dann 2 austauschen und eine als SPARE hinzufügen, das war mir schon immer ein Gräuel, das kein Spare Laufwerk vorhanden war.

Wie sieht es eigentlich mit einem Grow/Change von RAID 5 zu RAID 10 aus? Sollte doch weniger CPU Last produzieren?!

Was ist Deine Meinung zu dem ganzen?

LG Stefan

[pluvo]

Nachdem ich einen definitiven FailureOutput von smartctl erhalten habe - [...]

Ich würde es auf jeden Fall nochmal mit dem Hersteller-Tool überprüfen.

Wenn eine Festplatte andauernd Fehler produziert und diese eigenständig beheben kann, kann der SW-Raid träge werden. Ich hatte sowas ähnliches schon mal. (Das hat aber auch nicht lange gedauert, bis die Festplatte komplett aus dem RAID geflogen ist.)

Am besten mal die Logs durchschauen.

[Hobbystern]

Hi pluvo, ich hoffe Du hast den Weg ins Bett gefunden

meine Sonntagsschicht ist vorbei - ich habe gerade mal die angestossenen Selftests eingesehen - alle sind da und unauffällig - bis auf die o.g. sdb - die meldet die alten fehler, aber auch das der test noch nicht zu ende ist (nach 5 Stunden) :

Code: Alles auswählen

# 1  Extended offline    Self-test routine in progress 90%     11170         -

Ich habe 2 neue bestellt - die alte geht so wie sie ist in den Abfall - ist halt keine Serverplatte (mensch was hab ich scsi geliebt)

Ich werd die ganze Kiste nunmal für einen Tag zur Wartung freigeben, dann auch mit einem zweiten Controller versehen.

Was mich nur richtig ärgert - ist das ich das ganze per "Manuel" herausfinden musste - wozu hat smartd meine Emailadresse .. ?

Danke für Deine nächtliche seelische Unterstützung...!

EDIT - ich dachte er hätte 90% geschafft - von wegen ...: " 90% of test remaining." Mülleimer ruft!
EDIT2 - Vielleicht noch ganz interessant - Monitoring hinter RAID oder auch - Self-Test ist PASSED, es treten aber Fehler auf(wie bei mir)
LG Stefan

[meti]

Damit Du den Plattenkäfig ausschließen kannst würde ich die Platten aber vorübergehend alle direkt an den Controller anstöpseln. Wenn der Fehler dann weg sein sollte, dann kannst schon mal nen neuen Plattenkäfig kaufen. Das Problem hab ich gerade auch, nur das bei mir bisher das RAID bereits zweimal ausgefallen ist. Wenn es bei Dir soweit ist und du 24/7 Betrieb mit kritischen Diensten hast dann hast ein richtiges Problem.

Es muss nicht sein, aber drauf verlassen würd ich mich nicht.

[Hobbystern]

Ich würde aus der Fallbeschreibung her (mal rein objektiv) den Käfig direkt ausschließen, wenigstens zum aktuellen Zeitpunkt. Es ist ja wirklich so das :

sdb
sdc
sdd

Mitglieder des Verbundes sind.

Der Datendurchsatz (mal eben aus dem Ärmel geschüttelt) so aussieht :

sdb 30
sdc 49.9
sdd 50.2

Nebenher meldet smartctl für sdb Fehler.

Was ich natürlich nicht ausschließen kann ist das der Anschluss an sdb Probleme macht.

Wartungsbeginn ist nächsten Samstag, im Plan ist Festplattentausch, Controller hinzufügen, alle Anschlüsse kontrollieren und wo wir gerade dabei sind bekommt die Kiste mehr Speicher (8 statt 4) und somit den IMHO notwendigen BIGMEM Kernel, was es dann nebenher möglich macht virtualbox mit zu starten. So wäre der Engpass "Up2Date mit VmWare 1.x" auch gelöst (denn auch in diesem Beitrag ging es (after all) um das Festplattenproblem...

Soweit - ich werd mal dazu schreiben wenn alles vorbei ist, sozusagen für die Nachwelt...

EDIT - ABer damit einem nicht langweilig wird bekomme ich gerade das hier rein

Code: Alles auswählen

Asterisk Server --> UPS battery needs changing NOW.

(Es ist natürlich NICHT der gleiche Server, dessen USV Batterie gerade mal auf Austausch gehüpft ist)
Ist es nicht schön Systeme zu betreuen?

LG Stefan

[Hobbystern]

BTW

Ist es eigentlich machbar von der aktuellen wackeligen Platte die Partitionierungsangaben auf die Neuen zu überspielen, dann müsste ich nicht erst wieder herausfinden wie ich die Platten damals partitioniert hatte...

(Mensch bin ich faul )

[pluvo]

Ist es eigentlich machbar von der aktuellen wackeligen Platte die Partitionierungsangaben auf die Neuen zu überspielen, dann müsste ich nicht erst wieder herausfinden wie ich die Platten damals partitioniert hatte...

Klar wenn die neue gleich groß ist.


Was wurde denn aus deinem Problem?

[Hobbystern]

Hallo Pluvo,

das Problem als Ganzes ist gelöst, es läuft nunmehr ein stabiles RAID10, ich habe es sogar geschafft aus dem alten RAID5 ein RAID10 zu machen - IMHO habe ich das hier im Forum als Tip gepostet, bin mir aber nicht mehr ganz sicher Kann auch im "unixboard" gewesen sein (Sonntag früh halt )

Das ganze lag anscheinend an der einen wackeligen Platte, ich habe diese entfernt und 3 Neue verbaut, so habe ich nunmehr ein RAID10 mit einer einsatzbereiten Partition bei Problemen, läuft gut - aber nicht so schnell wie erwartet, aber das ist nicht sooo wichtig. Ich schiebe das einfach mal darauf das alle Platten an einem Controller hängen, genauer gesagt 4 am internen Intel Controller und 2 an einem Adaptec (fake raid) (1 Platte ist noch als BackupHDD verbaut) - es ist sicher nicht des Rätsels Lösung wie ich es aktuell dort habe, aber ich bin mir ziemlich sicher das bei Zeiten eh die ganze Maschine überholt werden muss. Ich bin mir noch nicht ganz schlüssig ob es dann endlich zu einem "echten" Server Kasten kommt, also einem 19" Rack mit mW Blades oder sowas....Milchmädchenrechnung.

Es läuft, es ist stabil, es ist laufend gebackupped (shadow) und es hat einen redundanten Bruder neben sich stehen, der allerdings nur über 1 HDD verfügt, als reines BackupSystem - jedoch mit dem gleichen Inhalt und Aufbau (HA). Passt erstmal.

Danke für die Nachfrage! Ich wünsch´ Dir nen ruhigen Sonntag!

EDIT : Ich habe mir gerade mal meine (oben geposteten) Durchsatzraten angesehen ... :

Code: Alles auswählen

sdb 30
sdc 49.9
sdd 50.2

Hier sind die aktuellen dieser 3 - nein 4 Parteien :

Code: Alles auswählen

/dev/sda:
 Timing cached reads:   2272 MB in  2.00 seconds = 1137.19 MB/sec
 Timing buffered disk reads:  254 MB in  3.01 seconds =  84.31 MB/sec
/dev/sdb:
 Timing cached reads:   2382 MB in  2.00 seconds = 1191.49 MB/sec
 Timing buffered disk reads:  276 MB in  3.02 seconds =  91.36 MB/sec
/dev/sdc:
 Timing cached reads:   2232 MB in  2.00 seconds = 1116.66 MB/sec
 Timing buffered disk reads:  372 MB in  3.01 seconds = 123.64 MB/sec
/dev/sdd:
 Timing cached reads:   2168 MB in  2.00 seconds = 1084.38 MB/sec
 Timing buffered disk reads:  402 MB in  3.01 seconds = 133.41 MB/sec

(anbei - es sind nur "Montagsergebnisse" - heute laufen viele Wartungs und BackupJobs..)

Und das RAID10 ..

Code: Alles auswählen

/dev/md5:
 Timing cached reads:   2184 MB in  2.00 seconds = 1092.65 MB/sec
 Timing buffered disk reads:  372 MB in  3.08 seconds = 120.78 MB/sec

Nicht gerade eine Rakete, ich denke es liegt wirklich ganz hinten auch noch am Controller...

Stefan

[DynaBlaster]

Und das RAID10 ..

Code: Alles auswählen

    /dev/md5:
    Timing cached reads:   2184 MB in  2.00 seconds = 1092.65 MB/sec
    Timing buffered disk reads:  372 MB in  3.08 seconds = 120.78 MB/sec

Nicht gerade eine Rakete, ich denke es liegt wirklich ganz hinten auch noch am Controller.

Hm, nicht unbedingt.

ich experimentiere auch gerade mit Software-RAID's herum. Das Mainboard Gigabyte-GA-MA770-UD3 hat 6 SATA-Anschlüsse und an 4 von denen hängt jeweils eine 1TB-Hitachi-Platte. Die 4 Platten wurden folgendermassen zu einem SW-RAID10 zusammegefasst. Als Dateisystem wird XFS verwendet, das nach Google-Recherche mit folgenden Optimierungen, erzeugt werden sollte.

Code: Alles auswählen

mdadm -C /dev/md5 --chunk=256 -n 4 -l 10 -p f2 /dev/sd[abcd]7
mkfs.xfs -f /dev/md5 -b size=4096 -d sunit=256,swidth=1024

Interessanterweise liefert hdparm für das "ungemountete" /dev/md5 etwa 3,5 mal höhere Werte als wenn /dev/md5 "gemountet" ist.

Code: Alles auswählen

cat /proc/mdstat
Personalities : [raid1] [raid10]
md5 : active raid10 sdd7[3] sdc7[2] sdb7[1] sda7[0]
      629153792 blocks super 1.2 256K chunks 2 far-copies [4/4] [UUUU]

hdparm -tT /dev/md5

/dev/md5:
 Timing cached reads:   2346 MB in  2.00 seconds = 1173.75 MB/sec
 Timing buffered disk reads:  1394 MB in  3.00 seconds = 464.15 MB/sec

mount -t xfs -o sunit=256,swidth=1024 /dev/md5 /mnt/md5/

hdparm -tT /dev/md5

/dev/md5:
 Timing cached reads:   2328 MB in  2.00 seconds = 1164.56 MB/sec
 Timing buffered disk reads:  384 MB in  3.01 seconds = 127.66 MB/sec

Wenn ich mit dd herumspiele, kommen folgende Ergebnisse:

Code: Alles auswählen

dd if=/dev/zero of=/mnt/md5/testfile bs=128k count=100k
102400+0 Datensätze ein
102400+0 Datensätze aus
13421772800 Bytes (13 GB) kopiert, 97,8934 s, 137 MB/s

dd if=/mnt/md5/testfile of=/dev/null bs=128k count=100k
102400+0 Datensätze ein
102400+0 Datensätze aus
13421772800 Bytes (13 GB) kopiert, 26,5863 s, 505 MB/s

So richtig schlau werde ich aus den Ausgaben nicht, aber ich vermute, dass hdparm irgendwie keine wirklich aussgakräftigen Werte liefert. Die 505 MB/s beim Lesevorgang von dd sind vermutlich auch zu hoch, weil ein Teil der gelesenen Daten wahrscheinlich aus dem Platencache kamen. Aber auch wenn die Leseperformance bei 350 MB/s liegen sollte, ist das ein durchaus akzeptabler Wert. Inwieweit der Parameter "-p f2" beim mdadm-Kommando die Schreibgeschwindigkeit negativ beeinflusst hat, kann ich auch nicht sagen. Wenn Interesse besteht, kann ich morgen das Array /dev/md5 mal mit dem Parameter "-p n2" neu erstellen und die Ausgaben nachliefern. Inwieweit die XFS-Mount-Optionen sunit und switdh auch eine Rolle spielen, kann ich auch nicht sagen - Google liefert keine eindeutigen Aussagen. Mal heisst es, man solle für sunit die Chunk-Size des mdadm-Kommandos verwenden swidth=sunit*AnzahlderPlatten setzen. An anderer Stelle steht, man solle für ein RAID10 swidth=sunit*AnzahlderPlatten/2 nehmen.

Was richtig ist, keine Ahnung

[DynaBlaster]

Moinsen,

habe mal etwas weiter rumprobiert. Wenn das Raid10 mit der Option -n2 (das ist die Standard-Option) erstellt wir, bekomme ich folgende Werte.

Code: Alles auswählen

mdadm -C /dev/md5 --chunk=256 -n 4 -l 10 -p n2 /dev/sd[abcd]7
mkfs.xfs -f /dev/md5 -b size=4096 -d sunit=256,swidth=512

cat /proc/mdstat
md5 : active raid10 sda7[0] sdd7[3] sdc7[2] sdb7[1]
629154304 blocks super 1.2 256K chunks 2 near-copies [4/4] [UUUU]

#hdparm ungemountetes /dev/md5
hdparm -tT /dev/md5
/dev/md5:
Timing cached reads:   2380 MB in  2.00 seconds = 1190.98 MB/sec
Timing buffered disk reads:  758 MB in  3.00 seconds = 252.36 MB/sec

mount -t xfs -o sunit=256,swidth=512 /dev/md5 /mnt/md5/

#hdparm gemountetes /dev/md5
hdparm -tT /dev/md5
/dev/md5:
Timing cached reads:   2352 MB in  2.00 seconds = 1176.08 MB/sec
Timing buffered disk reads:  370 MB in  3.01 seconds = 123.01 MB/sec

#dd schreibend
dd if=/dev/zero of=/mnt/md5/testfile bs=128k count=100k
102400+0 Datensätze ein
102400+0 Datensätze aus
13421772800 Bytes (13 GB) kopiert, 47,2795 s, 284 MB/s

#dd lesend
dd if=/mnt/md5/testfile of=/dev/null bs=128k count=100k
102400+0 Datensätze ein
102400+0 Datensätze aus
13421772800 Bytes (13 GB) kopiert, 50,0022 s, 268 MB/s

So drastisch hätte ich mir den Unterschied zwischen den Optionen -n2 und -f2 beim RAID10 wahrlich nicht vorgestellt.