Selfbuild Storage System

D€NNIS

Pharao
Thread Starter
Mitglied seit
25.12.2003
Beiträge
4.098
Hallo zusammen,

inspiriert durch diesen Artikel und dessen Vorgänger [1,2] möchte ich mich mal im Austausch mit anderen über die Machbarkeit eines "selfbuild" Storage Systems unterhalten.

Da ich in einer Branche arbeite in der wir Unmengen an Speicherkapazität auf unseren Storagesystemen benötigen bin ich darum bemüht, alternative Lösungsansätze zu finden, die eventuell unseren Optionsspielraum zu den üblichen und aus meiner Sicht, teilweise überteuerten Lösungen erweitern könnten.
Bei dem Vorhaben geht es erstmal nur darum, die aktuellen Marktmöglichkeiten zum Aufbau eines Storage Systems zu sondieren und im Gespräch mit euch herauszufinden, welche Hürden genommen werden können und welche möglicherweise eher schwierig zu überwinden sind.

Wichtig ist, das sich die LUNs als FC und iSCSI Target konfigurieren lassen. Als Dateisystem wäre natürlich ZFS naheliegend.
Supermicro hat aus meiner Sicht mit dem SSG-6047R-E1R72L ein interessantes System am Start.
Gibt dazu zwar noch keine ganz genauen Informationen aber ich vermute mal, das die 3xLSI2308 (1x onboard 2x PCIe Card) an den Expandern der Backplanes betrieben werden.
(3xBPN-SAS-846A?)
Allerdings scheint mir da ein latenter Flaschenhals zu bestehen wenn die insgesamt 24 SAS Ports mit einer Gesamtbandbreite von 144Gb/s Bandbreite die 72 Platten versorgen müssen. (2Gb/HD)
Leider ist der LSI SAS 9201-16i auch nur PCIe 2.0 konform.

Als OS könnte man über OpenIndiana nachdenken.
Soweit mir bekannt beherrscht das COMSTAR Framework mit einigen bestimmten FC-HBAs (z.B Qlogic) auch einen FC Target Mode, bin ich da richtig informiert?
Wie wird Multipathing I/O in COMSTAR gehandhabt?
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
SuperMicro Mainboards, LSI HBA Controller und was Solarisartiges mit ZFS ist
eine gängige Basis für high-end Whitebox Storage und geht eigentlich immer recht problemfrei.

Zum Thema Comstar und MPIO ist die Doku von Oracle ein guter Einstieg
Setting Up iSCSI Multipathed Devices in Oracle Solaris - Oracle Solaris Administration: Devices and File Systems
http://docs.oracle.com/cd/E23824_01/html/821-1459/fmvcd.html

Ich selber nehme Sata Platten ohne Expander. Mein aktuelles System
ist ein Chenbro Case mit 50 Bays, 6 x IBM 1015 Controller und SM X9srl-f und 10 GBe.
Heute würde ich eher ein X9SRH-7TF mit 10 Gbe onboard nehmen.
Mit 4 TB Platten geht das bis 200 TB RAW.

Als OS würde ich eher zu OmniOS raten. OI erfährt zwar momentan wieder etwas
Pflege, es ist aber derzeit eher nichts für produktiven Einsatz.
 
Zuletzt bearbeitet:
Danke für dein Feedback gea.
Das Chenbro Case sieht recht interessant aus, hast Du eine Preisinfo und eine Bezugsquelle?
 
Zuletzt bearbeitet:
D€NNIS;20686284 schrieb:
Danke für dein Feedback gea.
Das Chenbro Case sieht recht interessant aus, hast Du eine Preisinfo und eine Bezugsquelle?

Ich hatte es von hier:
http://www.ico.de/details.php/categ..._name/9HE_Servergehäuse_RM_912__eATX__48x_HDD

ca 4000 Euro das Case


Ich habe es gewählt, weil es eben ohne Expander läuft.
Es hat eine Backplane mit 12 x miniSAS + 2 x Sata = 50 disks.

Ansonsten: Es ist so schwer, dass man es am besten zu viert (hat Extra Griffe) wegträgt.
Es ist lauter als 4 Staubsauger der billig-China-Turbo Klasse.

Was mir sonst auffiel:
Die roten Warn-LED müssen extra vom Controller angesprochen werden. Der Controller muss dazu Anschlüsse haben. Sonst hat man nur Connect/Activity.


Zu deiner Frage wegen dem X9SRH-7TF .
Das hat 3 x pci-e, damit lassen sich drei HBA einbauen (z.B. 8/16 Kanal LSI). Dual 10 GbE ist ja onboard.

Wird FC zusätzlich benötigt,
hat man max 2 x 16 Kanal HBA + onboard 8 Kanal HBA + onboard 6 Kanal Sata=
max 46 Platten sofern von USB gebootet wird. OmniOS läuft prima von gespiegelten USB Sticks.
 
Zuletzt bearbeitet:
Das hat 3 x pci-e, damit lassen sich drei HBA einbauen

Dann würde allerdings entweder der FC-HBA oder LSI SAS Controller nicht mit den vollen 8x Lanes Anbindung laufen, was zumindest suboptimal ist, wenn man ansonsten, wie Du
richtigerweise sagst, beim Chassi ohne Expander auskommt und deshalb der ganze Aufbau möglichst kompromisslos sein soll.

Die Lautstärke macht mir ein wenig Angst, so wie Du das beschreibst ^^

Die roten Warn-LED müssen extra vom Controller angesprochen werden. Der Controller muss dazu Anschlüsse haben. Sonst hat man nur Connect/Activity.

Danke für den Hinweis, das ist gut zu wissen.

---------

Kannst Du mal aufzeigen wie Du deine zpools/vdevs bei Verwendung von 48 Platten organisiert hast?
Hast Du zu deinem Storage System vielleicht ein paar Benchmarkwerte zur Hand?
 
D€NNIS;20688345 schrieb:
Dann würde allerdings entweder der FC-HBA oder LSI SAS Controller nicht mit den vollen 8x Lanes Anbindung laufen, was zumindest suboptimal ist, wenn man ansonsten, wie Du
richtigerweise sagst, beim Chassi ohne Expander auskommt und deshalb der ganze Aufbau möglichst kompromisslos sein soll.

---------

Kannst Du mal aufzeigen wie Du deine zpools/vdevs bei Verwendung von 48 Platten organisiert hast?
Hast Du zu deinem Storage System vielleicht ein paar Benchmarkwerte zur Hand?

4 lanes bei PCI-e v2 bringen etwa 2 GByte/s Datenrate, das reicht also locker für 2 x 10GbE oder FC.
Insgesamt bringen die Platten ohnehin mehr Daten als durch den Rechner durchgeht.

Performance ist mir aber gar nicht so wichtig. Ich nutze die Teile für Backups. Da sind mir große und günstige Sata Platten wichtiger. (Expander + Sata mag ich nicht nehmen).

Momentan habe ich nur 28 Platten (langsame sparsame WD RE4) im System mit Raid-Z2 vdevs.
Eine gute Fileserver-Konfiguration für 48 Platten wäre 4-5 Raid-Z2, ideal mit 4 x 10 Platten + 1 x 6 Platten pro vdev= 46 Platten + 2 hotspares = 36 nutzbare Datenplatten.

Ich habe sogar ein paar aktuelle Benchmarks zur Hand -
nicht zum zeigen wie schnell der Server ist, sondern eher um ein paar ZFS Grundprinzipien aufzuzeigen:
http://napp-it.org/doc/manuals/benchmarks_5_2013.pdf
 
Zuletzt bearbeitet:
Danke nochmal nachträglich für deine Erfahrungswerte.
 
D€NNIS;20684299 schrieb:
Wichtig ist, das sich die LUNs als FC und iSCSI Target konfigurieren lassen. Als Dateisystem wäre natürlich ZFS naheliegend.
Supermicro hat aus meiner Sicht mit dem SSG-6047R-E1R72L ein interessantes System am Start.
Gibt dazu zwar noch keine ganz genauen Informationen aber ich vermute mal, das die 3xLSI2308 (1x onboard 2x PCIe Card) an den Expandern der Backplanes betrieben werden.
Ich halte das System für schlecht konfiguriert. Ein nackter LSI 2308 ist zwar in einer Workstation ganz nett, aber in einem Storage Server bringt er nur geringe Leistung, weil er keinen WriteBackCache hat. Daher lieber dedizierte LSI 2208/2308 Karten mit CacheVault einsetzen. Mehr als zwei Karten ergibt bei einem Server mit einem oder zwei 10GbE Ports keinen Sinn, da die Netzwerkanbindung ohnehin der Flaschenhals ist. Wenn es schneller sein soll, muß es schon 40GbE oder Infiniband sein. Aber wahrscheinlich ist in so einem Fall ein Clusterfilesystem ohnehin schneller.
 
Ich halte das System für schlecht konfiguriert. Ein nackter LSI 2308 ist zwar in einer Workstation ganz nett, aber in einem Storage Server bringt er nur geringe Leistung, weil er keinen WriteBackCache hat.

Das trifft für Hardware-Raid und die herkömmlichen Dateisystem zu.
Software-Raid mit ZFS hat aber andere Anforderungen. Es verlagert die kompletten Raidfunktionen zur CPU und möchte am liebsten ganz dumme HBA Kontroller ohne Raidfunktion und jedweden Cache.

Am liebsten hat ZFS Controller folgende simple HBA Controller mit IT Firmware (und nicht mit IR Raid-Firmware):
Host Bus Adapters

Grund:
Beim Lesen wird der freie Hauptspeicher, ergänzt um eine oder mehrere SSDs als Lesecache benutzt. Da ZFS ein CopyOnWrite Dateisystem ist, bei dem ja keine Datenblöcke aktualisiert sondern immer neu geschrieben werden, wird der Arbeitsspeicher auch beim Schreiben als Cache benutzt. ZFS sammelt dazu alle kleinen Writes für 5s und schreibt die als einen großen sequentiellen Write auf die Platten. Geht dabei etwas schief, bleibt der alte Datenbestand erhalten. Daher ist ZFS auch immer konsistent (kein Filecheck nötig).

Wird aus Gründen der Datensicherheit syncrones Schreiben benötigt (z.B. Datenbanken oder ESXi datastore), protokolliert ZFS zusätzlich alle Schreibaktionen in einem ZIL-Logdevice. ZFS muss dabei immer wissen, ob Daten auf der Platte sind oder nicht. Ein Controller-Cache hätte da im Problemfall eventuell einen Datenverlust als Folge.

Insgesamt:
Controllercache + ZFS ist nicht schneller sondern nur unsicher. Normaler Arbeitsspeicher ist ohnehin immer schneller und größer als Controllerspeicher. ZFS Storage arbeitet daher immer mit diesen einfachen Controllern. Sicherer und schneller Speicher bis in den Petabyte-Bereich mit mehreren Hundert Platten wird bei ZFS genau damit gemacht. Performance ist da nicht vom Controller abhängig sondern von der CPU und der Menge an RAM für den Lesecache.

nur als Beispiel (geht heute billiger und schneller)
http://www.tomshardware.com/picturestory/582-12-petarack-petabyte-sas.html
 
Zuletzt bearbeitet:
Das trifft für Hardware-Raid und die herkömmlichen Dateisystem zu.
Software-Raid mit ZFS hat aber andere Anforderungen. Es verlagert die kompletten Raidfunktionen zur CPU und möchte am liebsten ganz dumme HBA Kontroller ohne Raidfunktion und jedweden Cache.
Das mag ja sein, aber dann kann man das Produkt gleich als ZFS Server anpreisen, denn für alle anderen FS trifft das nicht zu.
Und danke für die Erklärung.
 
Für solche Anwendungen finde ich ja immernoch den storage pod von Backblaze höchstinteressant: Backblaze Blog » 180TB of Good Vibrations – Storage Pod 3.0 Vorallem stellen die alle Konstruktionsdaten zur Verfügung und das Ganze sollte auch noch deutlich preiswerter als fertige Systeme sein, wenn ich mich nicht irre.
 
Wobei die Backblaze eher nicht auf Speed sondern nur auf Kapazität hin optimiert sind. Durch die ganzen Expander verlieren die doch massig Speed, oder?
 
Denke auch, allerdings muss man hier auch den Einsatzzweck beachten. Fürs reine Storage z.B. als Backup mehr als ausreichen in vielen Fällen. Und mit Kosten von <2000$ eigentlich auch preislich unschlagbar. Da kommen ja schon fast einige der großen Qnap NAS preislich ran. Ich finde nur den Zugriff von oben nicht ganz so gelungen, das ist aber auch dem Preis geschuldet. Im Fall einer defekten HDD muss man das Ding dann erst aus dem Schrank wuchten, während man z.B. an der Supermicro Lösung einfach die Trays ziehen kann. Obwohl ich in dem Fall nicht sicher bin, was dann mit der anderen Platte passiert, da dort ja immer 2 Platten pro Tray verbaut sind.

Je nach Firma sind das trotzdem immer noch alles nur Bastellösungen. Es kommt auf den Einsatzzweck und die Verfügbarkeitanforderungen an. In kritischen Umgebungen muss man da schon mal erheblich tiefer in die Tasche greifen um ordentlichen Support zu bekommen. Oder wer bietet Support, wenn in den (beiden) günstigen Lösungen mal das Mainboard hopps geht. Da steht die Kiste wahrscheinlich erheblich länger, als wenn man was "richtiges" von HP, Dell, etc. nimmt.
 
Hallo,

versuche seit einiger Zeit eine OmniOS/napp-it storage als SAS Target zum laufen zu bekommen.
Hat da jemand Erfahrung mit?
Habe dazu bisher nur sehr wenig Infos gefunden.
 
Ich kann mir bei diesen Blechschachteln voller Platten nicht wirklich vorstellen, dass die für halbwegs professionelle Anwendungen schnell und stabil genug sind. Ich mein 40 oder 50 Sata-Platten in so einem Stapel? Ich mag mir gar nicht vorstellen was da los ist wenn mal ein Raid rebuild ansteht...
Als Bastelprojekt sicher nicht uninteressant, aber wenns ums Geld verdienen geht würde ich doch was anderes nehmen.
 
Update:

SAS Target ist installiert und läuft.
Leider stürzt das Target ab sobald sich der Initiator versucht zu verbinden.
Wenn auf dem Initiator der SAS Controller startet und nach Festplatten sucht kommt auf dem Target kurz eine Liste/Tabelle (so kurz das man nichts lesen kann) auf dem Monitor und der komplette Rechner bootet neu.
Jemand eine Idee?
 
Update:

SAS Target ist installiert und läuft.
Leider stürzt das Target ab sobald sich der Initiator versucht zu verbinden.
Wenn auf dem Initiator der SAS Controller startet und nach Festplatten sucht kommt auf dem Target kurz eine Liste/Tabelle (so kurz das man nichts lesen kann) auf dem Monitor und der komplette Rechner bootet neu.
Jemand eine Idee?

Ich kann jetzt nicht sagen, dass "SAS Target" bei mir gleich eine bestimmte Konfiguration bedeutet.

Folgende Info wäre gut:
- Welche Software
- welche Hardware/Konfiguration
- welches Konfigurationsziel - was soll erreicht werden
 
Software:
"https://blogs.oracle.com/dhollister/entry/comstar_sas_port_provider_it" - (SAS Target Treiber - mptt)
OmniOS + napp-it

Hardware/Konfiguration:
Target (Storage)
LSI SAS Controller mit 1068e (zwei verschiedene um die Hardware als Problem aus zu schließen)

Initiator (Server)
LSI SAS Raid Controller mit 1078 oder LSI SAS Controller mit 1068e (auch hier wieder um die Hardware aus zu schließen)

welches Konfigurationsziel - was soll erreicht werden:
Storage mit ZFS, deduplication, snapshots
an Server angebunden per SAS

Zwischenstand ist der das die Storage soweit läuft und auch der mptt (SAS Target Treiber) an den Controller gebunden ist, das ganze aber abstürzt sobald auf dem Server/Initiator der Controller initialisiert wird/die Laufwerke erkennt.
 
Ich versteh das Ziel leider immer noch nicht.

Sollen zwei eigenständige OmniOS Server mit je einem SAS Controller per SAS verbunden werden, wobei der erste auf die SAS Platten des zweiten "RAW" zugreifen kann (Die also als SAS Platten sieht)?

Vereinfacht, soll der zweite Server quasi SAS Expander für den ersten spielen?

Gibt es keine andere Lösung als einen 4 Jahre alte OpenSolaris Spezialtreiber zu nehmen?
Das kann doch nur nicht funktionieren.
 
fast...
Server 1 (Storage) mit OmniOS und SAS Target Treiber soll software-Raid (ZFS) machen und dann das Raid (also eine große virtuelle Festplatte) per SAS an Server 2 zur Verfügung stellen.
So hatte ich mir das vorgestellt und dafür war der Treiber damals wohl auch entwickelt worden.

>Gibt es keine andere Lösung als einen 4 Jahre alte OpenSolaris Spezialtreiber zu nehmen?
>Das kann doch nur nicht funktionieren.

Ich wünschte es gäbe da etwas einfacheres/moderneres, aber leider habe ich nichts gefunden.
Bzw. nicht ganz richtig, es gibt was für Linux "http://scst.sourceforge.net/". Dafür gibt es auch einen SAS Target Treiber. Der scheint mir aber noch viel mehr Bastellösung zu sein.
Die Solaris basierende Geschichte schien mir daher erfolgversprechender zu sein.
 
Ich dachte dafür nutzt man iSCSI? (es ist natürlich kein Hardwarecontroller mehr im Spiel)
 
ISCSI wäre die einfache variante, allerdings mit weniger Bandbreite bei 1gbe (ansonsten bräuchte man 10gbe und das ist extrem teuer) und höherer Latenz.
 
ISCSI wäre die einfache variante, allerdings mit weniger Bandbreite bei 1gbe (ansonsten bräuchte man 10gbe und das ist extrem teuer) und höherer Latenz.

Die einfachste Variante ist es, ein Case mit genügend SAS Controllern und Plattenslots zu nehmen.
Das ist schnell und problemfrei - auch mit Sata Platten. Ich mach das so bis 50 Platten in einem Chenbro 9 HE case.

Alternativ weitere JBODS Cases per Expander anschließen.
Da sollte man aber auf SAS Platten achten. Damit gehen auch mehrere Hundert Platten und Petabyte Storage

iSCSI um Storage zusammenzufassen macht eigentlich nur Sinn wenn man z.B. übers Netzwerk Mirrors machen will.
 
ISCSI wäre die einfache variante, allerdings mit weniger Bandbreite bei 1gbe (ansonsten bräuchte man 10gbe und das ist extrem teuer) und höherer Latenz.
10 GBE erscheint mir allerdings tatsächlich die ausgereiftere Variante zu sein!
Es gäbe auch noch die Möglichkeit Infiniband zu nutzen.
Alles in Allem durchdachter als einem Harware Controller eine Emulierte Hardware vorzugaukeln
 
Zuletzt bearbeitet:
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