OVH Community, your new community space.

RAID5 und mehr..


rex2
12.01.12, 23:33
Das ist ein guter Hinweiß. Schau ich mir mal an. Danke.

Dark-Sider
12.01.12, 23:27
Kann es sein, dass im System-Bios die IDE legacy compatibility eingestellt ist und deshalb die platten gegroupt werden? Oder die billigen chips machen's halt einfach so, weil man sie auf basis alter ide chips weiter entwickelt hat...
Schließlich laufen die Platten ja auch mit "ata2: SATA max UDMA/133 " UDMA/133" und nicht SATA1 - was ja 150MB/s oder SATA2 was 300MB/s wären.

bye
Darky

rex2
12.01.12, 23:09
Ich halte Deine Vermutung nicht für die richtige... Beide Platten sind zeitgleich und nicht nach erst ca. 10 sek. ausgefallen. Weiterhin ist es kein Zufall dass, die sdc ausgefallen ist.

Code:
Jan  2 14:08:19 ns367967 kernel: ata2.00: disabled
Jan  2 14:08:19 ns367967 kernel: ata2.01: disabled"
ata2.00=sdc
ata2.01=sdd

Wäre die Festplatte sdc nicht in dem gleichen "ata-link" wäre sie auch nicht ausgefallen. Der Kernel hat einfach die sdc abgetrennt, weil sdd nicht antwortete und sich in diesem "ata2-link" befindet.

Aber das ist erstmal nicht das Problem. Mich interessiert nur, wieso die Platten so komisch zusammengefasst werden.

Dark-Sider
12.01.12, 22:36
Hallo,

ich kenne die genau Hardware des Servers nicht, ist aber auch nicht so wichtig. Meine Erklärung zielte darauf ab: Der Controller (alle 4 Platten hängen da dran) versucht die defekte platte zu lesen und bleibt dabei "hängen". Nach sagen wir 10 sekunden dropt md-raid die festplatte da keine antwort kommt. Damit hört der Controller aber nicht auf die defekte platte zu lesen und hängt immer noch. Damit md-raid den lese/schreibvorgang beenden kann muss es jetzt auf eine weitere platte zugreifen. Auch diese wird aufgrund des hängenden controllers nicht antworten und md-raid dropt diese auch nach sagen wir weiteren 10 sekunden. Dass das nun sdc war und nicht sda oder sdb kann purer zufall sein. Da nach dem ausfall der 2. Platte es keinen sinn mehr macht weitere platten zu lesen wird das raid komplett offline genommen.

Das ist eine mögliche Erklärung von vermutlich vielen.

bye
Darky

rex2
12.01.12, 18:36
Danke für die Erklärung. Aber wie ist das mit ata1 und ata2 zu erklären? Wieso werden jeweils 2 Platten zusammengefasst? Und wenn der Controller dabei hängt, wieso sind dann die anderen Platten nicht ausgefallen..

Dark-Sider
12.01.12, 13:19
Hallo,

ich würde einfach mal sagen, dass Du soeben die Nachteile eines Software Raids im Zusammenspiel mit günstigen onboard Controllern entdeckt hast. Wobei man auch ganz klar sagen muss dass ein md-raid oder auch ein dynamisches Windows Raid-5 noch allemal besser sind als die software Raid-Funktion von billigen chisätzen zu benutzen.

Zur möglichen Erklärung:
Je nach defekt an der Festplatte, kann auch der Controller aus dem Tritt kommen. Wenn nun das Betriebssystem versucht von sdd zu lesen dropt es die platte. Für die dann notwendig werdende parity berechnung wird sdc angesprochen. Da der Controller noch "hängt" kann er auch die Antwort für sdc nicht erbringen und auch diese Platte wird als nicht verfügbar angezeigt. Danach geht das mdraid offline und keine weiteren Leseversuche werden unternommen.

Der Fehler muss auch garnicht selbst an der Platte liegen, sondern es kann sich auch um ein defektes bzw. lockeres SATA-Kabel oder einen defekten Controller handeln.

bye
Darky

rex2
12.01.12, 11:15
Ich habe mehrere SuperPlan Storage Server (4x 1,5 T Platten). Eines Morgens erhalte ich eine Meldung, dass das RAID5 ausgefallen ist..:

Code:
cat /proc/mdstat  
Personalities : [linear] [raid0] [raid1] [raid10] [raid6]
[raid5] [raid4] [multipath] [faulty] 
md1 : active raid1 sdd1[4](F) sdb1[1] sdc1[5](F) sda1[0]
      10484672 blocks [4/2] [UU__]
      
md3 : active raid5 sdd3[4](F) sdb3[1] sdc3[5](F) sda3[0]
      4357653312 blocks level 5, 64k chunk, algorithm 2
[4/2] [UU__]
Das Merkwürdige: Es sind gleichzeitig 2 Festplatten ausgefallen, was für RAID5 den Tod bedeutet..

In Wirklichkeit war nur die Festplatte sdd kaputt, sdc war nach dem Reboot wieder komplett da. Zu den Logs:

Code:
"Jan  2 14:07:14 ns367967 kernel: ata2: link is slow to
 respond, please be patient (ready=0)
 Jan  2 14:07:19 ns367967 kernel: ata2: device not ready
 (errno=-16), forcing hardreset
 Jan  2 14:07:19 ns367967 kernel: ata2: soft resetting link
 Jan  2 14:07:24 ns367967 kernel: ata2: link is slow to
 respond, please be patient (ready=0)
 Jan  2 14:07:29 ns367967 kernel: ata2: soft resetting link
 Jan  2 14:07:34 ns367967 kernel: ata2: link is slow to
 respond, please be patient (ready=0)
 Jan  2 14:07:39 ns367967 kernel: ata2: soft resetting link
 Jan  2 14:07:44 ns367967 kernel: ata2: link is slow to
 respond, please be patient (ready=0)
 Jan  2 14:08:14 ns367967 kernel: ata2: soft resetting link
 Jan  2 14:08:19 ns367967 kernel: ata2.00: disabled
 Jan  2 14:08:19 ns367967 kernel: ata2.01: disabled"
Wenn ich es richtig verstehe, werden jeweils 2 Festplatten in einem "ata-link" zusammengefasst. ata2= sdc/sdd. Sdd geht also mechanisch kaputt, fällt gleichzeitig auch sdc aus.

Code:
scsi0 : ata_piix
scsi1 : ata_piix
ata2: ACPI get timing mode failed (AE 0x300b)
ata1: SATA max UDMA/133 cmd 0xf0e0 ctl 0xf0d0 bmdma 0xf0a0 irq 19
ata2: SATA max UDMA/133 cmd 0xf0c0 ctl 0xf0b0 bmdma 0xf0a8 irq 19
ioatdma: Intel(R) QuickData Technology Driver 4.00
ata2.00: ATA-8: Hitachi HDS723015BLA642, MN5OA580, max UDMA/133
ata2.00: 2930277168 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata2.01: ATA-8: Hitachi HDS723015BLA642, MN5OA580, max UDMA/133
ata2.01: 2930277168 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata1.00: ATA-8: Hitachi HDS723015BLA642, MN5OA580, max UDMA/133
ata1.00: 2930277168 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata1.01: ATA-8: Hitachi HDS723015BLA642, MN5OA580, max UDMA/133
ata1.01: 2930277168 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata2.00: configured for UDMA/133
ata1.00: configured for UDMA/133
ata2.01: configured for UDMA/133
ata1.01: configured for UDMA/133
Einen RAID5 auf OVH-Server zu betreiben, scheint sinnlos. Wie ist das ganze zu erklären?