Stabiles Storagesystem auf Basis von VMware ESXi 6.0 gesucht

Hallo liebe CB´ler,

ich suche ein Storagesystem welches recht unanfällig ist wenn ggf. mal der Strom wegbleibt oder ein Update z.B. des ESXi durchgeführt wird (halt ein ungewollter Ausfall). Durch solch ein Update ist nämlich ein über 21TB großes Volume (per RDM gemappt) welches in Xpenology eingebunden war, gecrashed.

Der Server steht bei meinen Eltern und wird auch von Ihnen verwendet, daher suche ich was robustes und würde gerne auf eure Meinung und Erfahrungswerte zurückgreifen. Monitoring und Plattentausch (bei Ausfall) würden im Idealfall von meinen Eltern durchgeführt werden können. Ein durchreichen des Storages zum ESXi wäre auch erforderlich.

Folgende Systeme habe ich mir mal grob angeschaut und kämen in Frage:

• Napp-it free: ZFS hört sich für mich gut an, Oberfläche sieht mir ggf. was zu professionell aus. Ist trotzdem mein Favorit.
• OpenMediaVault: Ein Arbeitskollege schwärmt davon wie stabil das bei Ihm läuft...
• Rockstor: Btrfs hört sich ebenfalls an. Teilweise liest man etwas in Richtung unstabil.

Was wird momentan auf dem ESXi betrieben und damit auch teilweise auf dem Storage?

• IP-Cams in Xpenology (Storage = HDDs, ca. 3TB)
• Windows Server 2016 (Test, SSD)
• TS (SSD)

Vorhandene Hardware:

• HP ProLiant ML10 v2
• Intel(R) Xeon(R) CPU E3-1220 v3
• 20GB ECC RAM
• ESXi (momentan 6.5, ist aber nicht supported) auf einer 240GB OCZ SSD
• 4x Seagate Archive HDD 8TB momentan RAID5 @ Fujitsu D2616 RAID Controller (LSI SAS2108) + BBU

Der RAID-Controller würde bei den meisten Systemen wenig nützen (u.a. keine SMART-Werte) und da der Server eh nur an Gigabit hängt ist das vermutlich eher der Flaschenhals (momentan ca. 110MB/s RW). Die Platten würde ich daher an den internen Controller hängen. Natürlich könnte man auch alles verkloppen und durch ein System QNAP oder Synology ersetzen. Würde ich aber zunächst vermeiden wollen.

Ich bin auf eure Beiträge gespannt! VG DaRk_T1Ger!

OMV läuft sehr stabil
das kann ich nur bestätigen

Was du brauchst ist eine USV und ne vernünftige Backup Strategie.

Warum per RDM gemapped und nicht direkt den Controller durchgereicht?

sikarr schrieb:

Was du brauchst ist eine USV und ne vernünftige Backup Strategie.

Zum Vergrößern anklicken....

USV ist vorhanden und konfiguriert. Backup der wichtigsten Sachen gehen auf eine externe HDD und teilweise in Google Drive. Das ist nicht mein Problem, sondern eher das Xpenology eine Bastellösung ist.

Fard Dwalling schrieb:

Warum per RDM gemapped und nicht direkt den Controller durchgereicht?

Zum Vergrößern anklicken....

Wurde in DSM 6.1 nicht erkannt und ich habe den Controller per Fujitsu Software auf Windows überwacht.

Da würde ich jetzt einfach mal FreeNAS mit ZFS in den Raum werfen:
http://www.freenas.org/

Effektiv hat man damit etwas zu Qnap/Synology vergleichbares inkl. Plugins.

Hmm ZFS mag generell keine Stromausfälle und abrupten Abschaltungen. Ist zwar ein verdammt stabiles Dateisystem aber wenn z.B. gerade ein Write vom ZIL auf das eigentliche Dataset passiert sollte der Strom tunlichst nicht ausfallen sonst hast halt Datenverlust.
Freenas, die populärste NAS-Distribution auf ZFS-Basis, rät klar davon ab das System virtualisiert zu betreiben, u.a. aus mehreren Gründen. Einer wäre, dass ZFS sehr RAM-hungrig ist und 1 GB Ram pro 1 TB Storage empfiehlt, gerne mehr und bei weniger kann es zu Performance Engpässen kommen. Desweiteren setzt ein ZFS eigentlich immer voraus, dass es alleinigen und absoluten Zugriff auf Festplatten hat. Ein Raid-Controller sollte daher bei ZFS immer als reiner stumpfer HBA arbeiten und ein Virtualisierungslayer wie eben RDMs bei VMware sind da leider auch eher hinderlich.
Dass die Seagate Archive aufgrund der SMR eher weniger als Raid-Disks zu empfehlen sind weißt du hoffentlich und hast dich aktiv dafür entschieden es doch so einzurichten? Bit Rot und die hohe Wahrscheinlichkeit dass bei einem Rebuild die nächste Platte stirbt bei solch großen Volumes sind dir hoffentlich auch bekannt?

BTRFS hat ein paar nette tolle Features wie Snapshots, Sub-Volumes etc aber ja es ist nach wie vor nicht als stable anzusehen daher sollte man es nur einsetzen wenn einem die Daten nicht soo wichtig sind oder man stets aktuelle Backups hat und sich recht gut damit auskennt für den Fehlerfall. Wir haben ein paar VMs mit BTRFS und deren Admins hatten ein bisschen zu tun als mal der darunter liegende Storage Probleme hatte.

Ergo bleibt nur OMV was ne (stark vereinfacht gesagt) eine recht gut und umfangreiche GUI ist um ein Debian mit NFS und SMB Server einzurichten. Ob und wie stabil dies bei einem Stromausfall sind würde ich aber trotzdem testen auch wenn ich persönlich es als recht stabil ansehen würde.

Wieso hat Server denn mit abrupten Abstürzen zu kämpfen? Ich würde ggf. über die Anschaffung einer kleinen USV nachdenken oder den Eltern sagen dass es Server bzw Dateisysteme verdammt uncool finden wenn man ihnen den Strom spontan weg nimmt.

snaxilian schrieb:

Hmm ZFS mag generell keine Stromausfälle und abrupten Abschaltungen. Ist zwar ein verdammt stabiles Dateisystem aber wenn z.B. gerade ein Write vom ZIL auf das eigentliche Dataset passiert sollte der Strom tunlichst nicht ausfallen sonst hast halt Datenverlust.
Freenas, die populärste NAS-Distribution auf ZFS-Basis, rät klar davon ab das System virtualisiert zu betreiben, u.a. aus mehreren Gründen. Einer wäre, dass ZFS sehr RAM-hungrig ist und 1 GB Ram pro 1 TB Storage empfiehlt, gerne mehr und bei weniger kann es zu Performance Engpässen kommen. Desweiteren setzt ein ZFS eigentlich immer voraus, dass es alleinigen und absoluten Zugriff auf Festplatten hat. Ein Raid-Controller sollte daher bei ZFS immer als reiner stumpfer HBA arbeiten und ein Virtualisierungslayer wie eben RDMs bei VMware sind da leider auch eher hinderlich.
Dass die Seagate Archive aufgrund der SMR eher weniger als Raid-Disks zu empfehlen sind weißt du hoffentlich und hast dich aktiv dafür entschieden es doch so einzurichten? Bit Rot und die hohe Wahrscheinlichkeit dass bei einem Rebuild die nächste Platte stirbt bei solch großen Volumes sind dir hoffentlich auch bekannt?

BTRFS hat ein paar nette tolle Features wie Snapshots, Sub-Volumes etc aber ja es ist nach wie vor nicht als stable anzusehen daher sollte man es nur einsetzen wenn einem die Daten nicht soo wichtig sind oder man stets aktuelle Backups hat und sich recht gut damit auskennt für den Fehlerfall. Wir haben ein paar VMs mit BTRFS und deren Admins hatten ein bisschen zu tun als mal der darunter liegende Storage Probleme hatte.

Ergo bleibt nur OMV was ne (stark vereinfacht gesagt) eine recht gut und umfangreiche GUI ist um ein Debian mit NFS und SMB Server einzurichten. Ob und wie stabil dies bei einem Stromausfall sind würde ich aber trotzdem testen auch wenn ich persönlich es als recht stabil ansehen würde.

Wieso hat Server denn mit abrupten Abstürzen zu kämpfen? Ich würde ggf. über die Anschaffung einer kleinen USV nachdenken oder den Eltern sagen dass es Server bzw Dateisysteme verdammt uncool finden wenn man ihnen den Strom spontan weg nimmt.

Zum Vergrößern anklicken....

Danke für diese umfangreiche Antwort! Ich werde mal OMV testen. Die Plattenproblematik ist bekannt und es waren damals halt die einzig lieferbaren 8tb. Das Problem Stromausfall war eher ein Beispiel und eine kleine apc usv ist vorhanden. Die XPEnology Variante ist einfach zu anfällig und selbst Sicherheitsupdates sind ein Problem...

Womit arbeitet OMV am besten kein HBA, HBA im IT-Mode oder einfach direkt an den internen intel Controller?

Da hat OMV soweit mir bekannt keine Präferenz, das wäre wie zu Fragen womit arbeitet Linux im Storage-Umfeld lieber? Genau, die Antwort wäre: Kommt drauf an was du vor hast, wie deine Anforderungen sind usw. Linux lässt dir relativ viele Freiheiten und bietet eine Menge nützlicher Tools an. Mit vielen davon kannst du dir wunderbar selbst in den Fuß schießen aber ob du dies machst bleibt dir überlassen

Machen wir einen kurzen Ausflug zum Thema Begrifflichkeiten, denn die passen nicht so ganz wie du sie verwendest. Ein HBA ist erst einmal nix anderes als ein Adapter, der interne oder externe Komponenten an das Bus-System des Hosts anbindet. Das kann SATA/SAS sein oder aber auch iSCSI, FC und FCoE. Streng genommen ist auch eine Netzwerkkarte ein HBA
Bleiben wir aber im Storage-Umfeld. Ein reiner HBA reicht Platten 1:1 durch, arbeitet also direkt im "IT-mode". Hat der HBA einen Chip drauf der auch verschiedene Raid-Modi unterstützt so muss/kann dieser Raid-HBA-Kombi-Controller in den o.g. Modus angepasst werden, idR durch eine andere Firmware. Dabei wird dann mehr oder weniger nur der Raid-Chip deaktiviert. Ob du also Platten an den onboard-Controller oder einen reinen SATA/SAS-HBA anschließt macht so erst einmal keinen Unterschied außer ggf. in der Performance.

Wenn du also das Raid per Controllerkarte und am ESXi verwalten willst dann lasse die Platten da dran, erstelle ein RDM oder Datastore da drauf und gib das der OMV-VM.
Willst du das Raid per Controller in der VM verwalten so gib den Controller per PCIe Passthrough an die MV durch.
Willst du die Platten einzeln nutzen oder ein Software-Raid mittels OMV betreiben: Controller in IT-Mode und Platten durchreichen. Platten einzeln als RMD/Datastore an VM würde ich nicht machen, das ist nur ein unnötiger weiterer Layer der vieles komplizierter macht. Lass dich auch nicht von dem Wort Software-Raid unter Linux abschrecken. Im Gegensatz zu den Raid-Funktionalitäten die Windows so bietet oder was man gern als Fake-Raid bezeichnet (Raid per Intel Treiber am Onboard-Chip) ist damit absolut nicht zu vergleichen. Der Linux Raid Code ist recht performant, stabil und bietet viele Features.