[Sammelthread] AMCC 3ware 9650SE PCI-e RAID-Controller (+ Kurz-Review)

Oh, scheinbar gibt's den 3DM2 doch für VMware. Habe grade das VMware Addendum dazu bei mir gefunden, liegt eh auf'm Codeset ISO drauf. Wußte ich vorher nicht.

Wenn das RAID-5 selber damit an sich unwichtig geworden ist (falls ich das so richtig verstehe), dann zieh' die Platte doch einfach physisch raus? Wenn du es nach Best Practices machen willst und 3DM2 hast, dann so:​
  • Management -> Maintenance
  • Korrekte Platte finden und "Remove Drive" klicken
  • Mit "OK" bestätigen
  • Die Unit wird jetzt degraded, die Platte kann entfernt werden
Im User Guide findet sich dieser Punkt unter "Configuring Units / Removing a Drive".​
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Genau, die Maschine soll komplett neu aufgebaut werden.
Sollte man jede Platte einzeln entfernen oder kann ich einfach die Unit löschen?

Wenn das erledigt ist stellt sich die Frage was man heutzutage mit so feiner Hardware anstellen kann.
- den letzten möglichen ESXI (irgendwas im 5er Release) mit welchen Einschränkungen muss ich leben ausser Guest OS Comp.?
- Proxmox Virtualisierung
- irgend was ganz anderes, Win Desktop ? :LOL:
 
Du kannst auch einfach die Unit löschen, ja. Wobei du sie dann am VMware Host vorher zur Sicherheit aushängen solltest. Ich weiß nicht wie gern der das hat, wenn man ihm ein Laufwerk unter'm Hintern wegzieht. ;)

Zu VMware ESXi / vSphere Releases kann ich selber nicht genug sagen. Aber: Brauchst du so einen "dicken" Hypervisor überhaupt? Ich meine, man könnte das ganze auch schlanker machen, einfach mit Qemu/KVM unter Linux oder bhyve unter FreeBSD. Oder superbillig, nur halt weniger freie Software: Man setzt ein modernes Windows auf und betreibt seine VMs einfach mit VirtualBox. :LOL:

Was für eine Maschine ist das überhaupt?​
 
hab ich mir 2009 mal voller Übermut zusammen gebastelt zum rumspielen

- Tyan Board S5397 mit 2x Xeon E5405 und 16 GB RAM
- 2x Intel e1000 on board
- und eben der 3Ware 9650 SE 12ML ohne BBU

wäre zu schade zum weggeben und würd´s gern als backup Storage weiternutzen
und paar VM´s zum probieren bzw. truenas fürs storage

am ESXi / vSphere hat mir sehr gut gefallen:

- schlanke Hypervisorinstallation
- vSphere Client zum administrieren, erstellen der VM´s, Snapshots u.s.w. standalone ohne ssl Browser Generve

Qemu/KVM sieht interressant aus

- läuft das zb. auf nem Debian Server?
- Zugriff dann aber sicherlich mit Webgui im Browser?
 
Off-topic:

Qemu und KVM sind Teile des Grundgerüstes vieler "größerer" Hypervisor so wie RHV oder Proxmox. Das ist wirklich nur der minimale Kern für die Virtualisierung, sonst nichts. Die kriegst für so ziemlich jede Linux Distro, für Debian sowieso.

Installiert man noch das libvirt Zeug dazu, bekommt man ein Kommandozeilentool "virsh" für's Management lokal am Hypervisor, auf den du vorher per SSH verbindest. Damit lassen sich im Prinzip alle VM Sachen auf'm Terminal steuern. Es geht aber in vielen Fällen einfacher und schneller: Für oft benötigte Tasks (VM erstellen, rebooten bissl simple Leistungsüberwachung, grafische Konsole) nehme ich den RedHat [virt-manager], gibt's auch auf vielen Linux Distros abseits von RedHat Derivaten (u.a. Debian). Das issn Desktop Tool, das dann im Hintergrund per SSH zum Hypervisor connected (keybasierte Authentifizierung empfohlen). Also das kann ich auf meiner Workstation installieren, und der wartet dann den Hypervisor über's Netzwerk. Grafische Desktops werden dem Client i.d.R. per VNC durchgereicht. Unter Windows geht der virt-manager aber nur [per WSL], soweit ich sehe.

Bei uns auf der Arbeit ist das recht wurscht, weil die Desktop PCs und die Server eh fast allesamt auf Linux laufen. Qemu / KVM Ist halt ggf. mehr Bastelei als so ein fertiges, kommerzielles Trumm. Im "großen" Bereich haben wir dann eben RHV und die Zentrale fährt VMware vSphere.

Frontends für Qemu / KVM gibt es ansonsten aber scheinbar wie den sprichwörtlichen Sand am Meer, auch Web GUI Zeug, [siehe hier]. Ich habe mir diese Optionen nie durchgeschaut, weil ich mit virt-manager und virsh auskomme. Weiß daher nicht was da brauchbar ist und was nicht.

Aber wie gesagt: Ist sicher mehr Bastelei, vor allem wenn man sowas noch nicht gemacht hat. Die kommerziellen Hersteller machen es einem hier halt wohl einfacher, speziell wenn man auf MS Windows sitzt. Dafür läßt sich ein Linux Server mit Qemu / KVM recht einfach in eine eierlegende Wollmilchsau verwenden. Also man kann dann auch den baremetal Hypervisor für andere Sachen mit nutzen. Oder man lagert alle weiteren Dienste in VMs aus, wie immer man will.


Zumindest tlw. on-topic:

Zum Server: Cool, das ist noch eins von den Brettern mit 133 MHz PCI-X und PCIe, und FBDIMM auch noch! Ich höre ihn schon schreien nach zwei X5492 und 128 GiB RAM, und dann noch einen fetten (und leistungs- & kompatibilitätstechnisch ziemlich sinnlosen) PCI-X SCSI RAID Controller mit ein paar 15.000 rpm Disks. :whistle:

Die Hardware die du da hast dürfte 2009 noch recht teuer gewesen sein? Wenn die 3ware Software heute nicht tlw. schon so problematisch wäre, könnte man den 3ware ja direkt einfach drin lassen, zeitlich paßt er ja glaube ich nicht ganz so schlecht dazu.​
 
Hat schonmal jemand einen alten 9650 oder 9750 auf einer AM5-Plattform getestet?

Beim Umstieg auf AM4 hatte mein 9650 unter Linux nicht laufen wollen, mutmaßlich im Zusammenspiel mit dem Mainboard, welches ggf. Probleme mit PCIe 1.0 hatte. Dagegen spricht etwas, dass der 9650 unter Windows mit AM4 lief. Der 9750 (PCIe 2.0) lief dann problemlos unter Windows und Linux.

Anyway: Wie sieht das nun wohl mit AM5 aus? Angaben seitens der Hersteller bzgl. PCIe 2.0 gibt es natürlich nicht und wir wissen natürlich, dass die an anderen Stellen stets betonte Abwärtskompatibilität von PCIe nur die halbe Wahrheit ist. Daher wäre mir ein Erfahrungsbericht sehr gelegen, zumal ich den 9750 wirklich immer mehr zu schätzen weiß und mich das wahrscheinlich von einem Umstieg auf AM5 abhalten würde.
 
Hallo, ich habe an meinem 12ML aktuell 4 HDDs à 4 TB als RAID5 (also 12 TB Nettokapazität) verbaut. Ich würde aber gerne auf 3 SSDs mit jeweils 8 TB (also 16 TB Kapazität) umsteigen.

Kann ich die neuen SSDs einfach an die verbliebenen Ports abschließen, parallel zum alten ein neues RAID5 erstellen und dann die Daten im OS darauf kopieren?

Vielen Dank im Voraus!
 
Hallo, ich habe an meinem 12ML aktuell 4 HDDs à 4 TB als RAID5 (also 12 TB Nettokapazität) verbaut. Ich würde aber gerne auf 3 SSDs mit jeweils 8 TB (also 16 TB Kapazität) umsteigen.

Kann ich die neuen SSDs einfach an die verbliebenen Ports abschließen, parallel zum alten ein neues RAID5 erstellen und dann die Daten im OS darauf kopieren?

Vielen Dank im Voraus!

Ich zitier mich mal selbst :rolleyes2:

Ich habe die drei SSDs nun verbaut und massive Probleme: Egal, wie ich das neue Array einrichte, es wird in Windows 7 immer nur mit 2TB erkannt. Damit meine ich nicht, dass die Partition mit MBR oder GPT initialisiert wurde, nein, der resultierende Datenträger wird in der Hardwareübersicht partout nur mit 2TB angezeigt. Wenn ich über eine Linux Boot-CD starte, dann wird die volle Größe angeboten und ich kann das Array mit GPT und die Partition in der vollständigen Größe (14,xxTB) formatieren. Wenn ich dann testweise in Windows boote, dann wird die Partition zwar richtig angezeigt, aber wenn ich beginne, sie vollzuschreiben, dann killt sich das Dateisystem nach 2TB durch eigenes Überschreiben und die Partition ist kaputt.

Die Firmware ist die v4.10.00.027 vom 9.5.5.1 Codeset, der Treiber v3.00.05.058 von 9.5.5.2 Codeset. Auto-Carving ist selbstverständlich deaktiviert (wobei es im bestehenden RAID aktiviert war). Windows bootet von einer seperaten SATA SSD, im Array selbst ist entsprechend keine Boot Partition eingerichtet.

Hat da jemand eine Idee?

Vielen Dank!
 
Ist das Windows 7 zufällig die 32bit Version? Bin mir nicht sicher, aber ich glaube da gabs Probleme....

Edit: ach, die alten 4x 4TB liefen ja auch auf dem gleichen Win7 oder? dann ist es seltsam
 
Ja, aber es war wie gesagt Carving aktiviert, daher ist das nie aufgefallen. Das Windows ist ein x64
 
Mal was negatives: Seagate Ironwolf (ST14000NE0008, Firmware EN02) funktionieren NICHT am 3ware 9650 und 9750. Der Controller erkennt die Festplatte zwar und es lassen sich SMART-Werte auslesen, aber der Status des Laufwerks ist CFG-OP-FAIL (CLI) bzw. CONFIG FAILURE (3dm2) und die Platte ist nicht benutzbar.
Ich finde nur (wie auch hier im Thread) positive Meldungen für Toshiba-Festplatten, wobei es auch da Einschränkungen gibt. Bei der 16TB MG08ACA16TE braucht man wohl Firmware 0103 (oder 0101), Firmware 0102 macht Probleme (HDD wird aus RAID geschmissen).

Gibt es weitere Erfolgsmeldungen für größere Festplaten am 9650 oder 9750?
 
Also bei dem 9650 ist bei 8TB Schluss. Die 9750 müsste damit aber eigentlich gehen.

Ach ja: Mein Problem hat sich aufgeklärt: Ein defekter Speicherriegel schien die Ursache allen Übels zu sein. Nach einem Austausch gehen große Partitionen ohne Probleme. Darauf muss man erst einmal kommen…
 
RAM kann generell eine Sau sein, weil das Fehlerbild oft komplett erratisch ist. Seitdem ich das selber erlebt habe (lustige SIGBUS und SIGSEGV Fehler/Programmcrashes), gehört Memtest zum Standardrepertoire beim Debuggen. Außer du meinst den Cachebaustein am Controller und nicht deinen Systemspeicher, da geht das natürlich nicht.

Bzw. Unter FreeBSD nehme ich da "memtester", gibt's als Package, dann spart man sich das Booten von USB o.ä. Obwohl man das nicht im laufenden Betriebssystem machen sollte, hat der bei mir super zuverlässig Fehler detektiert, als einer von acht Steinen hinüber war.​
 
Also bei dem 9650 ist bei 8TB Schluss. Die 9750 müsste damit aber eigentlich gehen.
Das hat mich auch gewundert, zumal ich auch Meldungen in Erinnerung habe, dass 16TB IronWolfs gehen sollen.

Hatte erst ein LBA-Problem vermutet und eine Platte mit SeaChest auf 4k-Sektoren umgestellt:
Code:
SeaChest_Lite_x64_windows.exe -d pd0 --setSectorSize 4096 --confirm this-will-erase-data-and-may-render-the-drive-inoperable

Fand der Controller aber auch nicht lustig, hat den Status auf "Drive Error" und "DCB Read Failure" geändert und eine Kapazität von 1,59TB angezeigt - also die Anzahl der Sektoren*512 statt *4096.
Habe dann mit den SeaTools den Max-LBA-Wert auf 2^34 gesetzt, also der 8TB-(LBA34)-Wert des 9650-Controllers, Sektoren immernoch auf 4096. Es gibt immernoch ein "Drive Error" und Kapazität ist gesunken auf 1TB, also wie zuvor Anzahl der Sektoren*512 statt *4096.
Da ich die Platte wenigstens einmal lauffähig sehen wollte, habe ich die Sektor-Größe wieder auf 512 gesetzt. Glücklicherweise habe ich vergessen die LBA-Werte wieder für ein 8TB-Limit anzupassen, denn: Die Platte wurde nun korrekt vom 9750 als 14TB-Platte mit Status OK erkannt!

Ich kann mir das nur so erklären, dass Seagate in dem für den 3ware-Controller wichtigen Disk Configuration Block (DCB), irgend etwas proprietäres reinschreibt und er durch das hin- und herkonvertieren gelöscht wird.

Vielleicht hätte es auch manuell gereicht den ersten und letzten Block der Platte zu löschen, könnte so vielleicht funktionieren (ungetestet!):
Code:
SeaChest_Erase_x64_windows.exe -d pd0 --overwrite 0 --overwriteRange 4096 --confirm this-will-erase-data
SeaChest_Erase_x64_windows.exe -d pd0 --overwrite <last-LBA> --overwriteRange 4096 --confirm this-will-erase-data

Ggf. für die 4096 dann 512 nehmen.

Falls also jemand anderes Probleme mit Seagates am 3ware-Controller hat, mit den o.g. Konvertierungen wird es dann vermutlich funktionieren.



UPDATE:
Wirklich problemfrei sind die IronWolfs nicht. RAID-Initialisierung lief zwar noch problemlos und ich ich konnte auch die vollen 14TB bespielen, aber nach zirka einer Woche hat sich eine der beiden Platten mit "CONFIG FAILURE" aus dem RAID-Verbund verabschiedet. Da die Platte beim starten markante Geräusche und Vibrationen gemacht hat, bin ich von einem HW-Defekt ausgegangen. SMART-Werte waren aber alle gut und einzelnd am Mainboard angeschlossen war die Platte auch unauffällig - auch one Geräusche. Wieder zurück am 3ware-Controller wieder mit geräuschen. Habe dann zum Test neue Partitionstabelle erstellt usw. und die Platte schließlich wieder am RAID-Controller angeschlossen mit dem Gedanken mir einfach eune neue Platte zu kaufen. Nach zirka 10h Betrieb war sie wieder im Status "OK" und ich konnte auch ein Rebuild durchführen. Dann war wieder eine Woche alles in Ordnung bis wieder die RAID-Unit auf gedraded stand mit demselben Fehler... aber nun oh freu: Mit der ANDEREN Platte im RAID-Verbund.
Nach ein paar wahllosen Warm- und Kaltstarts wurde die Platte auch direkt beim Booten wieder als "OK" vom RAID-Controller befunden, eine Stunde später bei einem Kaltstart wieder als "CONFIG FAILURE". Irgendwelche Scheduled Tasks seitens 3ware kann ich ausschließen. Ich vermute, dass das Modell einfach eine eigenwillige Firmware hat bzw. irgendwelche untypischen Self-Tests anstößt, die den RAID-Controller sören. Daher mein finales Fazit: NICHT empfehlenswert.
 
Zuletzt bearbeitet:
RAM kann generell eine Sau sein, weil das Fehlerbild oft komplett erratisch ist. Seitdem ich das selber erlebt habe (lustige SIGBUS und SIGSEGV Fehler/Programmcrashes), gehört Memtest zum Standardrepertoire beim Debuggen. Außer du meinst den Cachebaustein am Controller und nicht deinen Systemspeicher, da geht das natürlich nicht.

Bzw. Unter FreeBSD nehme ich da "memtester", gibt's als Package, dann spart man sich das Booten von USB o.ä. Obwohl man das nicht im laufenden Betriebssystem machen sollte, hat der bei mir super zuverlässig Fehler detektiert, als einer von acht Steinen hinüber war.​

Ja, bei mir hat der Memtest86+ meiner Live-CD die Lösung gebracht. Zu diesem Zeitpunkt hatte ich schon auf verschiedensten Partitionen Datenkorrumption, die ich jetzt gerade beheben muss.

Und ich dachte erst, eine meiner Platten würde sterben, weil sich das Array ständig verifiziert hatte. So kam ich ja erst auf die Idee, auf neue SSDs umzusteigen. :rolleyes2:

Aber wo ich gerade Deine Aufmerksamkeit habe: Glaubst Du, es macht Sinn, vor der Nutzung im Array die Spare Area der SSDs mittels hdparm zu erhöhen? Ich hatte in Deinem Forum gelesen, dass TRIM am 9650 nicht möglich ist und mein Gedanke ist, dass die interne Garbage Collection mit mehr Over-Provisioning besser arbeiten könnte.
 
Zuletzt bearbeitet:
Hallo Zusammen,

ich habe da auch ein aktuelles Problem mit einem 3ware/LSI, daher stelle ich das mal hier ein.
NAS.
Erst mal die Hardware:
Gehäuse: 24 HDD NAS Gehäuse mit zwei redundanten Netzteilen.
Board: Supermicro x8DA6 (vorher x7DCL-I)
Zwei CPU
Reichlich Ram
Controller: 3ware/LSI 9650SE-24M8

Betriebssystem:
Windows 10 Pro 64bit, aktueller Stand.

Konfiguration:
Raid-50 mit 3 Subunits a 7 HDD (2TB/HDD), 3 Spare

Hergang:
Nachts war noch alles i.O. System ganz normal heruntergefahren.
Am Morgen neu gestartet und.... Raid fehlte.
In die Software (3DM2) geschaut.
Unit 3 (einzige Unit) Inoperabel.
Subunit 0 = i.O.
Subunit 1 = 3 HDD nicht vorhanden.
Subunit 2 = 2 HDD nicht vorhanden.

Die fehlenden 5 HDD werden aber erkannt und unter den verfügbaren Platten angezeigt.
3 HDD werden als Spare angezeigt.

Rebuild startet aber nicht!
Rebuild manuel in 3DM2 angestoßen: "(0x0B:0x0033) Unit busy: Faild to start Rebuild on Unit 3" (auch bei mehrmaligem auslösen).
Vorgang:
Unit kennzeichnen - >Rebuild> anklicken - Im Fenster 5 HDD auswählen - Bestätigen

Das selbe habe ich mit TW_CLI versucht.
Da bekomme ich nur eine Error-Meldung.
Ansonsten wird alles schön angezeigt.

Anhang:
Die anhängende Datei ist über den TW-CLI-befehl diag erstellt.

Achj ja, ich habe
- den Controller getauscht = keine Veränderung.
- das Board getauscht = keine Veränderung.
- alle 8 HDD getauscht = keine Veränderung.
- alle 8 HDD geprüft = keine Defekte gefunden
So langsam weiß ich nicht mehr weiter.
Angeblich soll der 2. Level-Support von 3Ware/LIS seinerzeit in der Lage gewesen sein so einen Fehler zu beseitigen. Nur gibt es den ja nicht mehr.

Irgend einen Tipp?
 

Anhänge

  • Diag file 9650SE-24.pdf
    4,7 MB · Aufrufe: 77
[...] Aber wo ich gerade Deine Aufmerksamkeit habe: Glaubst Du, es macht Sinn, vor der Nutzung im Array die Spare Area der SSDs mittels hdparm zu erhöhen? Ich hatte in Deinem Forum gelesen, dass TRIM am 9650 nicht möglich ist und mein Gedanke ist, dass die interne Garbage Collection mit mehr Over-Provisioning besser arbeiten könnte.
Ja, das ist korrekt, auch das Thomas-Krenn Wiki [bestätigt das]. Was ich aber nicht einschätzen kann ist wie groß man die Spare Area dafür dimensionieren sollte. Ich hatte damit noch nie herumexperimentiert, weil ich keine SSDs am 9650SE betrieben habe.

@Audiprinz : Ich habe mir das Mal angeschaut. Ich bin mir nicht zu 100% sicher, aber offenbar gibt oder gab es defekte SATA Kanäle ("sub-channels") und es finden auch Hard Rests einiger SATA Links statt. Wenn du da ein RAID-50 mit zuvielen scheinbar toten Platten hast, war's das natürlich mit'm Rebuild. Wenn die Platten in Wahrheit okay sind, müßtest du sie in den Array zurückzwingen.

Ich fürchte daß man dazu die DCB's (Disk Configuration Blocks) der betroffenen Platten modifizieren müßte, und das können wir ohne den Support nicht mehr, weil die DCB's nicht öffentlich dokumentiert sind. Außer irgendein fähiger Hacker hätte sich die Mal angeschaut, aber das wird's wohl nicht spielen, ich finde zumindest keine Doku. :(

Ursprünglich würde man von einer 16-bit Real Mode DOS Bootdiskette mit dem von 3ware bereitgestellten Tool dumpdcb drauf diese Blöcke in binäre Dateien herausschreiben und zur Modifikation an den 3ware/LSI Support schicken. Alles was ich machen kann ist dir Mal die dumpdcb Floppyimages hier anzuhängen. Quelle: [Broadcom] bzw. [User "slevy" von der University of Illinois Urbana-Champaign]. Für 3 TB Platten braucht's eine eigene Version, die andere geht bis 2 TB. Vielleicht wird ja irgendwer aus deinen DCB's schlau, falls du sie rausgeschrieben bekommst. Wäre echt Mal cool wenn wir das Datenformat dieser proprietären Konfigurationsblöcke verstehen könnten.​
 

Anhänge

  • dumpdcb.zip
    497 KB · Aufrufe: 64
  • dumpdcb-3TB.zip
    102,3 KB · Aufrufe: 41
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh