Neues Mainboard geplant - bitte Kommentar

[drnicolas]

Mein vsphere 5.1U1 läuft eigentlich inzwischen nicht schlecht.

Dennoch, die Hardware ist in die Jahre gekommen, alles andere als auf der HCL zu finden und das jetzige MB würde anderweitig noch immer ein ordentliche Figur machen.

Angetan hat es mir eines der Supermicro-Boards aus der X10-Reihe, also

Haswell-Chpsatz,
neuester Xeon
16 oder 32GB

Das Board MUSS PCI-passthrough können.

Unter den verschiedenen Varianten ist eines (X10-SL7-F) mit integriertem RAID-Controller.
mich stören die wenigen PCI-e-Steckplätze. Andere MOdelle habe mehr PCIes, aber eben keinen onboard-RAID.

Ist ein RAID-Controller überhaupt notwendig ? Zumal wohl keine BBU auf dem Board vorhanden ist. Wichtige HDDs sind inzwischen schon durch SSDs ersetzt - ist natürlich keine Gewähr

Derzeit habe ich einen über ebay geschossenen Dell PERC 6/i im Einsatz - mit BBU.
Funzt wunderbar und würde wahrscheinlich auch in dem neuen Board laufen

[Dayworker]

Also laut http://www.supermicro.com/products/motherboard/xeon/c220/x10sl7-f.cfm ist dort verbaut:

• SAS2 (6Gbps) via LSI 2308
• SW RAID 0, 1, 1E, 10 Support

Klingt für mich erstmal nach Fake-Raid. Schau mal im MB-Manual nach und berichte.

[drnicolas]

In der Tat!
Die ANgaben zum RAID scheinen sich auf die Intel-Onboard-Ports zu beziehen.

Aber was macht dann der LSI2308 ?
Immerhin hat der 8 Ports für SAS/SATA und auch separate Ausgänge für die Status-LEDS wohl über SGPIO

Ich habe auch beim Drüberlesen des Manuals keine separaten Option für den LSI gefunden .

Eigenartig...

[gea]

In der Tat!
Die ANgaben zum RAID scheinen sich auf die Intel-Onboard-Ports zu beziehen.

Aber was macht dann der LSI2308 ?
Immerhin hat der 8 Ports für SAS/SATA und auch separate Ausgänge für die Status-LEDS wohl über SGPIO

Ich habe auch beim Drüberlesen des Manuals keine separaten Option für den LSI gefunden .

Eigenartig...

Der Onboard Controller entspricht einem LSI 9217 für 6G SAS und Sata Festplatten.
Das ist ein absoluter Highend Controller. Er unterstützt Hotplug sowie Raid 0/1/10 mit der Raid-Firmware.
Daher wird auch keine Batterie und Cache benötigt.

Meist wird der 2308 Controller aber als reiner HBA mit der IT Firmware ohne Raid-Funktionalität benutzt-
vor allem im Storagebereich. Im Zusammenhang mit Solaris und ZFS ist er sogar der
aktuelle Standard Controller schlechthin - best of all.

Zusammen mit ESXi und pass-through läßt sich damit auch ein perfektes All-In-One System bauen.
(ESXi mit integriertem Multiprotokoll ZFS NAS/SAN über Storagehardware pass-through).

Infos
http://www.napp-it.org/doc/downloads/all-in-one.pdf
http://www.napp-it.org/doc/manuals/flas ... 7tf_it.pdf

[UrsDerBär]

Ich arbeite ja auch gerne mit den Supermicro-Produkten. Preiswert, sehr gut und excellenter End-User Support den ich so noch bei keinem grösseren Hersteller (ausser Teradici) ohne kostenpflichtigen Support erlebt habe.

Von High-End RAID-Controller würde ich jetzt nicht sprechen. Von einem sehr guten HBA schon eher.

Natürlich braucht ein Hardware-RAID-Controller nach wie vor grundsätzlich Cache und eine Batterie/Kondi-Flash-Kombi, damit er eben Write-Anforderungen zwischenspeichern kann, weil die Festplatten nicht mithalten können. Sonst geht der Speed extremst in die Knie und ist unglaublich unbeständig. Zumindest bei allem was was nicht Flashbasiert ist. Weil der Festplattencache gehört ohne entsprechende eigene Stromversorgung der Backplane und HDD's immer ausgeschaltet.

Fakt ist, es ist und bleibt ein Software-RAID wenn dessen Raid-Fuktionen genutzt werden. Benutzt man SSD's die sogar noch über eigene Kondis verfügen kann man sich einen richtigen Controller unter Umständen durchaus sparen. LSI leitet diese jeweils auch direkt und nicht viea Cache zu den Flash-Speicher. Bei Ihren dicken Normal-Controller.

Deshalb: Ich verwende das Teil nur als HBA oder höchstens als RAID für zbsp. das OS der Storage-Appliance. Ansonsten lasse ich Windows Server das RAID machen. Und auch nur mit Flash-basierten Speicher, sonst macht das kein Spass.

[gea]

Von High-End RAID-Controller würde ich jetzt nicht sprechen. Von einem sehr guten HBA schon eher.

Natürlich braucht ein Hardware-RAID-Controller nach wie vor grundsätzlich Cache und eine Batterie/Kondi-Flash-Kombi, damit er eben Write-Anforderungen zwischenspeichern kann, weil die Festplatten nicht mithalten können. Sonst geht der Speed extremst in die Knie und ist unglaublich unbeständig. Zumindest bei allem was was nicht Flashbasiert ist. Weil der Festplattencache gehört ohne entsprechende eigene Stromversorgung der Backplane und HDD's immer ausgeschaltet.

Fakt ist, es ist und bleibt ein Software-RAID wenn dessen Raid-Fuktionen genutzt werden. Benutzt man SSD's die sogar noch über eigene Kondis verfügen kann man sich einen richtigen Controller unter Umständen durchaus sparen. LSI leitet diese jeweils auch direkt und nicht viea Cache zu den Flash-Speicher. Bei Ihren dicken Normal-Controller.

Deshalb: Ich verwende das Teil nur als HBA oder höchstens als RAID für zbsp. das OS der Storage-Appliance. Ansonsten lasse ich Windows Server das RAID machen. Und auch nur mit Flash-basierten Speicher, sonst macht das kein Spass.

Es ist schon eher ein Hardware Raid, da die Raid-Funktionalität über den Controller und die Controller Firmware und nicht über den Treiber realisiert wird.
Das ist bei Raid 1 aber ohnehin unerheblich.

Ob der Controller eine gute Wahl ist, hängt vom Betriebssystem und dem Dateisystem ab.
Unter Windows wird man damit nicht glücklich. Software Raid unter Windows - naja und Hardware Raid 5/6 kann der Controller nicht.
Mit ZFS ist er aber state of the Art und jedem viel teureren Hardwarecontroller mit Cache und Batterie vorzuziehen. - ja man sollte diese Raid-Controller
sogar strikt meiden. ZFS kann das eh viel besser (kein write-hole, checksums, copy on write etc) und mit dem normalen RAM auch viel schneller.
Der wird da nämlich komplett als readcache und für die letzten 5s als write cache benutzt. Moderne CPUs sind auch schnell genug für Raidberechnungen.
Selbst ein Software-Raid-Z aus SSD Platten erzeugt kaum CPU Last bei > 1 GB/s Durchsatz.

Neben High-end Storage macht der Controller noch als Boot-Raid1 für ESXi Sinn. Da wird er auch unterstützt.

[UrsDerBär]

Wie gesagt, es ist ein Software-Controller bzw. ein HBA mit RAID-Funktionalität. Damit hat es sich.

Software-RAID mit NTFS unter Windows 2012/2012 R2 ist garantiert zuverlässiger punkto Crashes als ZFS ohne entsprechende Hardware-Caches.

ZFS ist genial punkto Features. Punkto Datensicherheit muss man aber auch ne Menge tun um zbsp. einen Hostcrash zuverlässig auffangen zu können. NTFS als Filesystem ist seit Jahren bzw. fast Jahrzehnten extrem bewährt. Recoverys davon auch sehr erfolgsversprechend.

[gea]

Software-RAID mit NTFS unter Windows 2012/2012 R2 ist garantiert zuverlässiger punkto Crashes als ZFS ohne entsprechende Hardware-Caches.

Nicht correkt. NTFS ist ok, aber nicht Stand der Technik.
Das ist aktuell ZFS, eventuell mal zusammen mit Btrfs und ReFS
wg CopyOnWrite und Prüfsummen.

Hardware-Cache ist bei ZFS definitiv falsch und fehl am Platz.

ZFS ist genial punkto Features. Punkto Datensicherheit muss man aber auch ne Menge tun um zbsp. einen Hostcrash zuverlässig auffangen zu können. NTFS als Filesystem ist seit Jahren bzw. fast Jahrzehnten extrem bewährt. Recoverys davon auch sehr erfolgsversprechend.

Nicht korrekt was Datensichheit angeht.
Ein CopyOnWrite Dateisystem wie ZFS ist immer konsistent- ohne Batterie und Cache.
Das ist bei ntfs nicht möglich und auch der beste Raid-Controller mit Cache und Batterie hilft da nur bedingt.

[Dayworker]

btrfs und ReFS sind in meinen Augen noch weit entfernt für Aussagen zur Zuverlässigkeit. Während ersteres seit Jahren (eingeführt im März 2009 mit Kernel 2.6.29) trotz kontinuierlicher Weiterentwicklung immer noch im Testzustand rumgurkt, dürften bei letzterem zwar noch nicht alle Macken gefunden sein, trotzdem sind die Erfolgsaussichten in meinen Augen grösser als jemals mit btrfs zu erreichen ist. Bei allem was ReFS trotz der M$-Marktdurchdringung nicht seinen Stempel aufdrücken kann, wird der Gegner wohl immer ZFS lauten.
Das ZFS auch unter Linux inzwischen, wenn auch mit Einschränkungen bei CIFS- und NFS-Freigaben (benötigt momentan zusätzlich die NFS- und SMB-Pakete der eingesetzten Distribution), recht passabel läuft, dürfte eine weitere bittere Pille für btrfs sein.


Ein HW-Raidcontroller ist bei ZFS wirklich rausgeschmissenes Geld. Sowohl Cache (Grösse nur vom RAM im Rechner abhängig) als auch Prüfsummen (bedingt ECC-RAM im Rechner) und Raidfunktionalität bzw -level werden direkt über ZFS abgebildet. Der einzigste Grund für die Investition in einen HW-Raidcontroller trotz ZFS dürfte sein, wenn man mehr als 8 Ports braucht und/oder diesen sehr günstig in der Bucht finden kann. Aber selbst dann macht das Umflashen des Controllers mit einer IT-Firmware seinen Sinn, der Rest nimmt dann halt einfach mehrere HBAs.

[gea]

Nur als kleine Ergänzung, damit es nicht zu arg Off Topic wird

ZFS läuft auch auf Hardwarecontrollern und ohne ECC RAM wie alles andere auch. Es wird dank Daten-Prüfsummen auch weiterhin zuverlässig jeden Plattenfehler melden.

Das Auto-Reparieren (self-healing Dateisystem) ist aber nicht mehr möglich. Dazu braucht ZFS Zugriff auf die Einzelplatten des Raid. Und da muss ich sagen, so billig kann ein Controller bei Ebay gar nicht sein, dass das lohnt. Gerade bei vielen Platten ist da die Option mit mehreren HBAs oder einem Expander mit SAS Platten die bessere Wahl.

[UrsDerBär]

Egal ob es NTFS stand der Technik ist oder nicht, bei keinem anderen Filesystem ist heute wohl die Wahrscheinlichkeit grösser, bei einer Verkettung von unglücklichen Umständen noch mit einigermassen bezahlbarem oder eigenem grösseren Aufwand an die vollständigen Daten zu kommen.


Punkto ZFS lasse ich Dir Deinen Glauben gerne. Wenn ich ZFS ohne USV, ECC, WriteCache bzw. verwendung von RAM-Cache höre, dann kringeln sich mir zumindest die Zehennägel. Innovativ ist gut und recht, aber bitte auch mit den entsprechenden Voraussetzungen betreiben.

Mit Write-Cache meine ich bei ZFS logischerweise nicht einen Controller mit Cache sondern zbsp. gespiegelte SSD's. Write Caches gehören meiner Meinung nach einfach nicht in flüchtige Speicher. Ein ZFS ohne ECC ist imho auch völlig daneben. Wer bei einem solchen System kein ECC einsetzt handelt fahrlässig.


Zu ReFs: Habe ich genügend dazu geschrieben, hier und in anderen Threads. Man wird sehen, wozu es führt. Aktuell hat es einen unsäglich Bug wenn ein Volume voll läuft. Der macht nicht wirklich Spass. Auch Hotspare-Nutzung ist unter dummen Umständen mühsam. Wird aber sicher noch gefixt.


Aber egal welche Technolgie man nutzt, alles was heute innovativ ist, ist vor allem punkto Performance und Preis/Leistung interessant. Punkto Ausfallsicherheit ist man aber noch einiges hinter den stabilen klassischen Lösungen entfernt. Dem muss man einfach Rechnung tragen und entsprechend vorsorgen/Voraussetzungen schaffen. Ein Total-Ausfall ohne Chance auf Wiederherstellung ist deutlich Wahrscheinlicher, also muss man auch das Risiko anders gewichten und die Massnahmen darauf ausrichten. Sei es Hardware, Ersatzsysteme, schnelles Recovery, kleine Backupzeitfenster usw. alles andere ist wie wenn man früher am teuren Hardware-RAID-Controller mit BBU gespart hat.

[gea]

Punkto ZFS lasse ich Dir Deinen Glauben gerne. Wenn ich ZFS ohne USV, ECC, WriteCache bzw. verwendung von RAM-Cache höre, dann kringeln sich mir zumindest die Zehennägel. Innovativ ist gut und recht, aber bitte auch mit den entsprechenden Voraussetzungen betreiben.

Mit Write-Cache meine ich bei ZFS logischerweise nicht einen Controller mit Cache sondern zbsp. gespiegelte SSD's. Write Caches gehören meiner Meinung nach einfach nicht in flüchtige Speicher. Ein ZFS ohne ECC ist imho auch völlig daneben. Wer bei einem solchen System kein ECC einsetzt handelt fahrlässig.
.

Ein letztes Post da es langsam Richtung Glauben abdriftet und Raid und nicht ZFS das Thema war.

- Nur Copy on Write Dateidsysteme vertragen einen Absturz immer ohne dass das Dateisystem Schaden nimmt. Lediglich die Datei, die gerade geschrieben wird ist fehlerhaft - nicht das Dateisystem. NTFS kann das nicht, ZFS sehr wohl. Daher hat ZFS nicht mal sowas wie chkdsk - etwas das ohnehin nur grobe Metafehler und keine Dateifehler entdecken kann. Das ist auch der Grund warum MS die Kerninnovationen von ZFS wie CopyOnWrite und Checksums in ReFS einbaut (oder Oracle und andere in btrfs).

ZFS benutzt den normalen RAM als WriteCache der letzten 5s bei nonsync writes, das aber nur aus Performancegründen damit aus mehreren kleinen random writes ein großes sequentielles write wird.

SSD ZIL devices sind kein write-cache devices sondern log-devices für sync write. Sie werden nur nach einem Absturz gelesen damit die letzten writes nicht verloren sind. Eine Spiegelung ist da als Highend Option möglich um den ganz seltenen Fall eines Absturzes bei gleichzeitigen SSD Ausfall abzufangen, Ansonsten wären aber lediglich die letzten 5s write verloren. (Und das ist was ganz besonderes, kein Hardware Raid hat gespiegelte Caches mit BBU Unterstützung)

ECC: Gehört in jeden Server, egal welches OS oder Dateisystem da jedes neiuere OS jeden RAM (z.B. als Cache) nutzt und niemand Daten trotz Raid wegen eines bit-flop verlieren möchte.