CommanderBond
Enthusiast
- Mitglied seit
- 16.04.2012
- Beiträge
- 703
Der OmniOS Installer hat doch mittlerweile ein Menü um Netzwerk einzurichten sodass man sich das CLI sparen kann dafür.
Ich habe auch mal auf Solaris direkt eingeschränkt, gibt trotzdem weiterhin nur den einen Treffer, das ganze fällt unter Oracle ZFS Storage Appliance Software 2013.1.7.19 und ist Teil von vielen Oracle-Produkten, z.B. der ExaLogic.
Turboschnecke
Enthusiast
Hab ich alles so gemacht. Schon mehrfach...
In der resolv.conf steht halt mein lokaler DNS (Fritzbox), aber auch mit 8.8.8.8 (was vorher ne Zeitlang drin stand) hatte ich das gleiche Problem
Es gibt sowohl eine nsswitch.dns und nsswitch.conf dabei, in denen beiden dasselbe drinsteht.
Hab dein Setup-PDF immer offen
hoppel118
Neuling
- Mitglied seit
- 07.04.2012
- Beiträge
- 232
Sagt mal, meint ihr nicht, dass Napp-it langsam mal einen eigenen Support-Thread bzw. Stammtisch bekommen könnte? [emoji6]
Ich habe diesen Thread abonniert, weil ich ZFS nutze. In letzter Zeit werden hier aber alle möglichen Themen zu Napp-it besprochen. Das interessiert mich reichlich wenig. [emoji6]
Gruß Hoppel
Ich habe diesen Thread abonniert, weil ich ZFS nutze. In letzter Zeit werden hier aber alle möglichen Themen zu Napp-it besprochen. Das interessiert mich reichlich wenig. [emoji6]
Gruß Hoppel
Zuletzt bearbeitet:
the_pi_man
Enthusiast
Bestimmt keine schlechte Idee.
Luckysh0t
Enthusiast
Dann dürfte der hier aber ziemlich schnell verarmen, da Fragen zu Napp-it meist auch gleich Fragen zu ZFS beinhalten.
Und Gea, "sollte" dann eine Intro Seite machen - ist ja sein Meisterstück
Und Gea, "sollte" dann eine Intro Seite machen - ist ja sein Meisterstück
hoppel118
Neuling
- Mitglied seit
- 07.04.2012
- Beiträge
- 232
Ich denke nicht, dass der Thread hier verarmen wird. Das Thema Napp-it ist anfangs nicht so intensiv in diesem Thread diskutiert worden. In letzter Zeit ist es mir vermehrt aufgefallen.
ZFS-Themen aus Napp-it können ja gern hier weiter diskutiert werden, aber Probleme mit der Netzwerkverbindung oder irgendwelche anderen Napp-it Bugs gehören hier meiner Ansicht nach einfach nicht her.
ZFS-Themen aus Napp-it können ja gern hier weiter diskutiert werden, aber Probleme mit der Netzwerkverbindung oder irgendwelche anderen Napp-it Bugs gehören hier meiner Ansicht nach einfach nicht her.
besterino
Legende
Das hier ist de facto der Solarish/ZFS Sammler. Nappit ist als „nur ne GUI“ da eben auch mit dabei. Und da nappit de facto das „Must have Admin-Tool“ - insbesondere für solche Dummies wie mich - für Solarish, genauer: die ZFS-Funktionen unter Solarish, ist, versteht man auch, warum hier häufig nappit und Solarish (und manchmal auch ZFS) synonym verwendet werden.
Wenn, wäre also ein Solarish-Sammler (denn für ZFS on Linux ist nappit eh nur Solala) passend. Da Solarish aber hier 99,99% der User (mich übrigens eingeschlossen) nur und ausschließlich als Filer eben wegen ZFS benutzen, macht es dann m.E. irgendwie auch keinen Sinn mehr, zu „sonstigem Solarish-Gedöns“ und/oder nappit nen eigenen Sammler zu machen. Das ist halt das blöde, wenn ein Dateisystem so verdammt gut zum OS passt und dort integriert ist, wie‘n A auf‘m E...
Womit ich aber konform gehen würde: für spezifische Probleme sollte man einen neuen Fred mit sinnvollem Titel (z.B. „OmniOS+nappit: netzwerkprobleme mit IP-Adresse per DHCP“) aufmachen.
Wenn, wäre also ein Solarish-Sammler (denn für ZFS on Linux ist nappit eh nur Solala) passend. Da Solarish aber hier 99,99% der User (mich übrigens eingeschlossen) nur und ausschließlich als Filer eben wegen ZFS benutzen, macht es dann m.E. irgendwie auch keinen Sinn mehr, zu „sonstigem Solarish-Gedöns“ und/oder nappit nen eigenen Sammler zu machen. Das ist halt das blöde, wenn ein Dateisystem so verdammt gut zum OS passt und dort integriert ist, wie‘n A auf‘m E...
Womit ich aber konform gehen würde: für spezifische Probleme sollte man einen neuen Fred mit sinnvollem Titel (z.B. „OmniOS+nappit: netzwerkprobleme mit IP-Adresse per DHCP“) aufmachen.
Zuletzt bearbeitet:
Einen Sammelthread "ZFS" der nur das Dateisystem abdeckt, halte ich nicht für sinnvoll.
Man käme auch nicht auf die Idee sowas für ext4 oder ntfs zu machen. Als Sun ZFS für sein neues OpenSolaris entwickelte, war ZFS aber von Anbeginn als hochintegrierte Lösung gedacht die tief in das Betriebssystem eingebettet ist und neben dem reinen Dateisystem auch Volumemanagement Raidmanagement und iSCS//NFS/SMB (mit AD ACL) Sharemanagement abdeckt. Fragen zu ZFS lassen sich von Anbeginn nicht immer vom Betriebssystem abkoppeln.
Man kann jetzt natürlich diskutieren ob Fragen zur Solaris Netzwerkkonfiguration (und das ist es ja aktuell, hat nichts mit dem Management Tool napp-it zu tun) in diesen Thread gehört da es User von BSD oder Linux nicht interessiert. Historisch ist ZFS wie dieser Thread aber Solaris + ZFS insofern gehören Solarish Fragen durchaus in diesen Thread (wohin auch sonst). Ich habe aber auch kein Problem damit wenn hier Fragen auftauchen die eher als Systemfragen zu BSD oder Linux zählen und nur hier landen weil eben auch ZFS benutzt wird und sich hier die Leute tummeln die was dazu sagen könnten. Wenn es ganz weit weg geht von ZFS kann man einen separaten Thread als Option sehen.
Insgesamt sehe ich diesen Sammler als DIE deutschsprachige Anlaufstelle für alle die was mit ZFS machen wollen. Einen separaten BSD+ZFS, Linux+ZFS und Solarish+ZFS Thread sehe ich nicht als sinnvoll (da viel zu wenig Traffic). Dann noch zu unterscheiden ob man FreeNAS, Nas4Free, ZFSGuru (Free-BSD), OMV (Linux) oder eben napp-it (OI, OmniOS/Illumos, Solaris oder Linux) oder NexentaStor (Illumos) als Web-Management-Tool auf einem der drei Betriebssysteme nutzt, würde nur zu 10 bedeutungslosen Threads führen.
In USA mag das anders sein. Da macht ein Spezialforum zu ZFS unter Solarish mit napp-it schon Sinn.
OpenSolaris derived ZFS NAS/ SAN (OmniOS, OpenIndiana, Solaris and napp-it) | [H]ard|Forum hat 8000 Antworten und 1.7 Millionen Hits
Solaris, Nexenta, OpenIndiana, and napp-it | ServeTheHome and ServeThe.Biz Forums hat die meisten Hits und Antworten im Bereich "Software Platforms" und schlägt da noch BSD, Linux oder Windows.
Als englischsprachige Foren haben die aber eine ganz andere (weltweite) Reichweite.
Man käme auch nicht auf die Idee sowas für ext4 oder ntfs zu machen. Als Sun ZFS für sein neues OpenSolaris entwickelte, war ZFS aber von Anbeginn als hochintegrierte Lösung gedacht die tief in das Betriebssystem eingebettet ist und neben dem reinen Dateisystem auch Volumemanagement Raidmanagement und iSCS//NFS/SMB (mit AD ACL) Sharemanagement abdeckt. Fragen zu ZFS lassen sich von Anbeginn nicht immer vom Betriebssystem abkoppeln.
Man kann jetzt natürlich diskutieren ob Fragen zur Solaris Netzwerkkonfiguration (und das ist es ja aktuell, hat nichts mit dem Management Tool napp-it zu tun) in diesen Thread gehört da es User von BSD oder Linux nicht interessiert. Historisch ist ZFS wie dieser Thread aber Solaris + ZFS insofern gehören Solarish Fragen durchaus in diesen Thread (wohin auch sonst). Ich habe aber auch kein Problem damit wenn hier Fragen auftauchen die eher als Systemfragen zu BSD oder Linux zählen und nur hier landen weil eben auch ZFS benutzt wird und sich hier die Leute tummeln die was dazu sagen könnten. Wenn es ganz weit weg geht von ZFS kann man einen separaten Thread als Option sehen.
Insgesamt sehe ich diesen Sammler als DIE deutschsprachige Anlaufstelle für alle die was mit ZFS machen wollen. Einen separaten BSD+ZFS, Linux+ZFS und Solarish+ZFS Thread sehe ich nicht als sinnvoll (da viel zu wenig Traffic). Dann noch zu unterscheiden ob man FreeNAS, Nas4Free, ZFSGuru (Free-BSD), OMV (Linux) oder eben napp-it (OI, OmniOS/Illumos, Solaris oder Linux) oder NexentaStor (Illumos) als Web-Management-Tool auf einem der drei Betriebssysteme nutzt, würde nur zu 10 bedeutungslosen Threads führen.
In USA mag das anders sein. Da macht ein Spezialforum zu ZFS unter Solarish mit napp-it schon Sinn.
OpenSolaris derived ZFS NAS/ SAN (OmniOS, OpenIndiana, Solaris and napp-it) | [H]ard|Forum hat 8000 Antworten und 1.7 Millionen Hits
Solaris, Nexenta, OpenIndiana, and napp-it | ServeTheHome and ServeThe.Biz Forums hat die meisten Hits und Antworten im Bereich "Software Platforms" und schlägt da noch BSD, Linux oder Windows.
Als englischsprachige Foren haben die aber eine ganz andere (weltweite) Reichweite.
hoppel118
Neuling
- Mitglied seit
- 07.04.2012
- Beiträge
- 232
Ok, dann haben wir es eigentlich geklärt.
Alles was mit ZFS zu tun hat, bleibt in diesem Thread. Alles was nicht damit zu tun hat, wird freundlich darum gebeten zu dem konkreten Thema einen eigenen Thread aufzumachen.
Ich sehe es auch nicht als sinnvoll an, für die verschiedenen „ZFS-Betriebssysteme“ (Linux, Solaris, what ever) eigene Threads zu erstellen, zumal sich die CLI-Befehle nur selten (oder gar nicht?) unterscheiden. Und wenn’s um die Bedienung der verschiedenen WebUIs oder irgendwelches Fehlverhalten in diesen geht, soll dies meinetwegen auch gern hier diskutiert werden. Aber wie man in einem bestimmten OS bspw. die Netzwerkverbindung konfiguriert, gehört hier nicht hin, auch wenn man dich @gea hier sehr gut erreichen kann. [emoji6]
Das was wir hier gerade abstimmen, ist für mich die normale Vorgehensweise in Foren. Spezifische Openmediavault-Probleme spreche ich sowieso nur im OMV Forum an. Für generelle ZFS/ZoL-Themen nutze ich diesen Thread sehr gerne, da ich hier in Landessprache schreiben kann. [emoji4]
Gruß Hoppel
Alles was mit ZFS zu tun hat, bleibt in diesem Thread. Alles was nicht damit zu tun hat, wird freundlich darum gebeten zu dem konkreten Thema einen eigenen Thread aufzumachen.
Ich sehe es auch nicht als sinnvoll an, für die verschiedenen „ZFS-Betriebssysteme“ (Linux, Solaris, what ever) eigene Threads zu erstellen, zumal sich die CLI-Befehle nur selten (oder gar nicht?) unterscheiden. Und wenn’s um die Bedienung der verschiedenen WebUIs oder irgendwelches Fehlverhalten in diesen geht, soll dies meinetwegen auch gern hier diskutiert werden. Aber wie man in einem bestimmten OS bspw. die Netzwerkverbindung konfiguriert, gehört hier nicht hin, auch wenn man dich @gea hier sehr gut erreichen kann. [emoji6]
Das was wir hier gerade abstimmen, ist für mich die normale Vorgehensweise in Foren. Spezifische Openmediavault-Probleme spreche ich sowieso nur im OMV Forum an. Für generelle ZFS/ZoL-Themen nutze ich diesen Thread sehr gerne, da ich hier in Landessprache schreiben kann. [emoji4]
Gruß Hoppel
Zuletzt bearbeitet:
Gibt es irgendwo Benchmarks der ZFS Verschlüsselung unter Solaris? Bisher hat mir Google da nur Ergebnisse zu alten Solarisversionen mit sehr alter Hardware geliefert. Ich plane gerade ein NAS und weiß noch nicht, ob Verschlüsselung für mich denkbar ist und welche CPU ich da bräuchte. Falls es nichts konkretes gibt, würde es schon helfen zu wissen ob die Verschlüsselung bei einer modernen CPU mit AES NI ähnlichen Durchsatz erreicht wie zB TrueCrypt oder BitLocker.
Oder ganz konkret, falls das zufällig jemand beantworten kann: Kriege ich mit einem Xeon 4108/4110 1,25GB/s hin? Was für IOPS darf man erwarten?
Oder ganz konkret, falls das zufällig jemand beantworten kann: Kriege ich mit einem Xeon 4108/4110 1,25GB/s hin? Was für IOPS darf man erwarten?
Ich kenne keine aktuellen Vergleichszahlen.
Als Solaris ZFS Verschlüssellung herauskam gabs ein paar Tests im Vergleich zur Device-Verschlüssellung unter BSD. Das Ergebnis damals war dass AES NI unterstützt wird, Solaris aber nicht ganz so schnell war wie Geli. Oracle hat das in der Zwischenzeit aber sicher verbessert.
1.25 Gbit/s ist sicher kein Problem mit einem aktuellen Xeon. 1.25 Gbyte/s schon eher (auch unverschlüsselt).
Iops dürfte eher vom Storage denn der Verschlüssellung abhängig sein.
Als Solaris ZFS Verschlüssellung herauskam gabs ein paar Tests im Vergleich zur Device-Verschlüssellung unter BSD. Das Ergebnis damals war dass AES NI unterstützt wird, Solaris aber nicht ganz so schnell war wie Geli. Oracle hat das in der Zwischenzeit aber sicher verbessert.
1.25 Gbit/s ist sicher kein Problem mit einem aktuellen Xeon. 1.25 Gbyte/s schon eher (auch unverschlüsselt).
Iops dürfte eher vom Storage denn der Verschlüssellung abhängig sein.
Ein Vergleich Solaris vs Geli wäre auch interessant, da ich zumindest zu FreeNAS ein bisschen was gefunden habe. hier erreicht jemand storage limitiert ~300 MB/s und sein i5-4570 hat dabei 10% Auslastung unverschlüsselt und 20% Auslastung verschlüsselt.
Wenn man das stumpf hochrechnen würde, ich habe keine Ahnung wie realitätsfremd das ist, könnte sein System locker 10 GBit/s verschlüsselt liefern. Bei einem lokalen Test mit dd ohne Netzwerkprotokolle wohlgemerkt.
Da der Xeon 4110 ~66% schneller als der i5-4570 ist, bleibt für mich die Frage, ist Geli mehr als 60% schneller als die Solaris Lösung?
Inwiefern sind 10 Gbit/s bzw. 1.25 GByte/s unverschlüsselt ein Problem? Nur vom Storage her? Gehen wir hier einfach mal von einer RAM Disk oder meinetwegen einem 4 x 6 RAIDZ2 über NVMe SSDs aus(, auch wenn die CPU nicht so viele Lanes hat).
Soll da die CPU schon Schwierigkeiten kriegen, oder gehts um die Netzwerk- und Freigabeprotokolle?
Wenn man das stumpf hochrechnen würde, ich habe keine Ahnung wie realitätsfremd das ist, könnte sein System locker 10 GBit/s verschlüsselt liefern. Bei einem lokalen Test mit dd ohne Netzwerkprotokolle wohlgemerkt.
Da der Xeon 4110 ~66% schneller als der i5-4570 ist, bleibt für mich die Frage, ist Geli mehr als 60% schneller als die Solaris Lösung?
Inwiefern sind 10 Gbit/s bzw. 1.25 GByte/s unverschlüsselt ein Problem? Nur vom Storage her? Gehen wir hier einfach mal von einer RAM Disk oder meinetwegen einem 4 x 6 RAIDZ2 über NVMe SSDs aus(, auch wenn die CPU nicht so viele Lanes hat).
Soll da die CPU schon Schwierigkeiten kriegen, oder gehts um die Netzwerk- und Freigabeprotokolle?
Luckysh0t
Enthusiast
In wie fern nehme ich mir eigentlich die Selbstheilungsfähigkeiten etc. von ZFS, wenn ich einen Pool bzw. Filesystem als Read only markiere ?
Zuletzt bearbeitet:
CommanderBond
Enthusiast
- Mitglied seit
- 16.04.2012
- Beiträge
- 703
kann zumindest sagen dass Snapshots zu erstellen sind selbst wenn das Dataset auf ReadOnly gesetzt ist in Nappit.
moinsen
hab napp-it schon länger im hintergrund am laufen, bis jetzt alles TOP als VM mit esxi6.5
was ich aber bis jetzt nie hinbekommen habe ist der hostname.
den habe ich damals unter:
System- Network- Eth- hostname
vergeben.
und dann habe ich in der hosts auch die IP und den Hostnamen eingetragen aber trotzdem zeigt mein Lancom Router den hostnamen nicht an, das selbe wenn ich einen L3 switch nehme.
andere vms werden korrekt erkannt. habe ich irgend etwas vergessen ?
hab napp-it schon länger im hintergrund am laufen, bis jetzt alles TOP als VM mit esxi6.5
was ich aber bis jetzt nie hinbekommen habe ist der hostname.
den habe ich damals unter:
System- Network- Eth- hostname
vergeben.
und dann habe ich in der hosts auch die IP und den Hostnamen eingetragen aber trotzdem zeigt mein Lancom Router den hostnamen nicht an, das selbe wenn ich einen L3 switch nehme.
andere vms werden korrekt erkannt. habe ich irgend etwas vergessen ?
Bzzz
Enthusiast
1,25GB/s schiebst du sehr sicher via AES-NI durch die Kerne. Die Frage wäre da eher, wo die Geschwindigkeit plattenseitig herkommt, und wie du sie zum Client kriegst. IOPS sind rein von deinem Storage abhängig.
Wenn du mir sagst, was ich genau messen soll, kann ich mal ein Ründchen den Filer anwerfen. Und wo du einen (zugegebenermaßen recht langsam getakteten) 8C16T Skylake planst, hechelt bei mir ein 3M6T Vishera, der FX-6300, um genau zu sein. Wenn der dem Skylake da auch nur die Reste vom Teller zieht, läuft irgendwas verkehrt. lz4 ist bei mir auch noch an...
CommanderBond
Enthusiast
- Mitglied seit
- 16.04.2012
- Beiträge
- 703
Habe unter "day" manuell nun "tue-sun" eingetragen. Allerdings führt er dann den Job dennoch auch am "mon" aus. Kann man das auch irgendwie unter 18.01 so hinbekommen dass es funktioniert?
eigentlich hätte er diesen job heute nicht ausführen dürfen.
Zuletzt bearbeitet:
@Bzzz: Danke, das war die Info die ich haben wollte. Das klingt für mich danach, als wäre eine Messung nicht notwendig. Oder hast du die Möglichkeit ein schnellen SSD Pool oder eine RAMDisk einmal mit und einmal ohne Verschlüsslung auf Latenz zu testen? Das wäre das einzige was mich noch interessiert. Allerdings glaube ich nicht, dass das meine Wahl der CPU ändern würde, da die besseren Optionen einfach zu teuer sind.
Die 10GBit/s sollte mein Storage liefern können. Es werden 2 Pools:
Einmal 24 HDDs als 4x6 Z2, wobei ich für den Anfang nicht alle HDDs kaufen werde, wahrscheinlich nur 12 oder 18.
Der zweite Pool ist noch nicht fertig geplant und wird auch erst später gekauft, aber wird aus SSDs bestehen. Da ist das Thema IOPS und Latenzen relevant, da ich Daten die ich aktuell lokal auf SSDs habe aufs NAS verlagern möchte.
Die 10GBit/s sollte mein Storage liefern können. Es werden 2 Pools:
Einmal 24 HDDs als 4x6 Z2, wobei ich für den Anfang nicht alle HDDs kaufen werde, wahrscheinlich nur 12 oder 18.
Der zweite Pool ist noch nicht fertig geplant und wird auch erst später gekauft, aber wird aus SSDs bestehen. Da ist das Thema IOPS und Latenzen relevant, da ich Daten die ich aktuell lokal auf SSDs habe aufs NAS verlagern möchte.
Eine Angabe wie tue-sun wird nicht unterstützt und könnte man allenfalls selber (Zeile ca 200) integrieren in
/var/web-gui/data/napp-it/zfsos/_lib/scripts/auto.pl
Ansonsten werden in 18.01 nur gravierende Sachen rückportiert (wie die Unterstützung von Solaris 11.4 oder OmniOS 151026 die später kamen). Alles andere ist nicht machbar da napp-it mit OmniOS, OpenIndiana und Solaris drei Betriebssysteme unterstützt, die sich laufend weiterentwickeln, ihr Verhalten leicht ändern oder neue Features integrieren. Anpassungen daran und kleinere Bugfixes gibts nur in der aktuellen dev Version und dann mit Verzögerung in der jeweiligen Pro oder Free Version.
danielmayer
Enthusiast
- Mitglied seit
- 30.03.2005
- Beiträge
- 1.010
Liebe Gemeinde,
zig-Stunden Frust und Erkenntnisse möchte ich dann doch mal hier teilen bzw. los werden.
Die "Ideal-Lösung" für ein Napp-IT/ZFS-full-featured lautet ja Solaris11.4+Napp-It. Wahlweise innerhalb ESXi oder Bare-Metal.
Nun zum Denverton C3578, anhand Supermicro A2SDi-H-TF:
1) ESXI 6.50, 6.5U2, 6.7: Es gibt immer noch keine Unterstützung für die Onboard-10GBase-T-NIC. Spanndenderweise ist der Kernel von 6.5u2 "neuer" als der von 6.7 - hilft nur nix. Erneut zeigt sich, wie eingeschränkt eine ITX-Wahl ist, wenn man eine zusätzliche NIC benötigt UND einen SAS-Adapter. Ich hatte über alle Internetquellen hin versucht, einen Treiber zu bekommen. Jedoch ist mangels offener Quellen für ESXi auch ein Eigenbau mithilfe Toolchain nicht möglich - ich habe zumindest nichts dazu gefunden für 6.5u2/6.7. Ein angebotener Treiber im Netz von Privat verursacht in allen drei getesteten Versionen einen Absturz und scheint damit inkompatibel. Der Versuch, die onboard-NIC zum Laufen zu bekommen hat mich zwei volle Wochenendtage gekostet. Weder Supermicro noch VMWare fühlen sich für die Treiber zuständig (nach Support-Kontakt...).
2) Bare-Metal-Solaris: Kein NIC, keine Installation möglich.
3) Proxmox V5.2: Installiert sich problemlos, die Hardware wird vollständig erkannt und ist nutzbar.
3a) Proxmox + Solaris: Leider ist es immer noch unmöglich, PCIe-Passthrough mit Solaris (und OI) zu betreiben. Leider gehen sowohl VirtIO als auch der SCSI-Treiber mit simuliertem SCSI-Adapter in Solaris nicht - es gibt keine nutzbaren HDDs. IDE/SATA möchte ich aufgrund der zu erwartenden Leistungsprobleme nicht.
3b) Proxmox + OI 18.04 Hipster: OI hat im Gegensatz zum Original-Solaris eine anscheinend funktionierende Unterstützung für VirtIO-Geräte, so dass man wenigstens per HDD-Passthrough (PCIe-PT geht hier auch nicht) die HDD-devies (by-id) durchreichen kann. Auch die NIC-Bridge kann per VirtIO bereitgestellt werden und läuft. Nachteil: "nur" HDD-Passthrough = suboptimal.
Da mich eigentlich das ZRaid-Grow und die embedded Verschlüsselung interessieren wollte ich das original-Solaris. Nur leider ist das Mainboard bis auf Weiteres inkompatibel. Die "OI"-Lösung ist daher schon per-se eine second-best-solution. Die aktuell teilweise als alpha/beta erhältlichen ZFSoL-Pakete sind für einen Fileserver mit 50TB eher nicht so mein Ding...
Gibt es noch Tipps? Gea?
zig-Stunden Frust und Erkenntnisse möchte ich dann doch mal hier teilen bzw. los werden.
Die "Ideal-Lösung" für ein Napp-IT/ZFS-full-featured lautet ja Solaris11.4+Napp-It. Wahlweise innerhalb ESXi oder Bare-Metal.
Nun zum Denverton C3578, anhand Supermicro A2SDi-H-TF:
1) ESXI 6.50, 6.5U2, 6.7: Es gibt immer noch keine Unterstützung für die Onboard-10GBase-T-NIC. Spanndenderweise ist der Kernel von 6.5u2 "neuer" als der von 6.7 - hilft nur nix. Erneut zeigt sich, wie eingeschränkt eine ITX-Wahl ist, wenn man eine zusätzliche NIC benötigt UND einen SAS-Adapter. Ich hatte über alle Internetquellen hin versucht, einen Treiber zu bekommen. Jedoch ist mangels offener Quellen für ESXi auch ein Eigenbau mithilfe Toolchain nicht möglich - ich habe zumindest nichts dazu gefunden für 6.5u2/6.7. Ein angebotener Treiber im Netz von Privat verursacht in allen drei getesteten Versionen einen Absturz und scheint damit inkompatibel. Der Versuch, die onboard-NIC zum Laufen zu bekommen hat mich zwei volle Wochenendtage gekostet. Weder Supermicro noch VMWare fühlen sich für die Treiber zuständig (nach Support-Kontakt...).
2) Bare-Metal-Solaris: Kein NIC, keine Installation möglich.
3) Proxmox V5.2: Installiert sich problemlos, die Hardware wird vollständig erkannt und ist nutzbar.
3a) Proxmox + Solaris: Leider ist es immer noch unmöglich, PCIe-Passthrough mit Solaris (und OI) zu betreiben. Leider gehen sowohl VirtIO als auch der SCSI-Treiber mit simuliertem SCSI-Adapter in Solaris nicht - es gibt keine nutzbaren HDDs. IDE/SATA möchte ich aufgrund der zu erwartenden Leistungsprobleme nicht.
3b) Proxmox + OI 18.04 Hipster: OI hat im Gegensatz zum Original-Solaris eine anscheinend funktionierende Unterstützung für VirtIO-Geräte, so dass man wenigstens per HDD-Passthrough (PCIe-PT geht hier auch nicht) die HDD-devies (by-id) durchreichen kann. Auch die NIC-Bridge kann per VirtIO bereitgestellt werden und läuft. Nachteil: "nur" HDD-Passthrough = suboptimal.
Da mich eigentlich das ZRaid-Grow und die embedded Verschlüsselung interessieren wollte ich das original-Solaris. Nur leider ist das Mainboard bis auf Weiteres inkompatibel. Die "OI"-Lösung ist daher schon per-se eine second-best-solution. Die aktuell teilweise als alpha/beta erhältlichen ZFSoL-Pakete sind für einen Fileserver mit 50TB eher nicht so mein Ding...
Gibt es noch Tipps? Gea?
Es gibt eine eherne Regel
Sobald man von Windows und schon mit Einschränkungen Linux weggeht
hin zu Unix (BSD, OSX, Solarish) oder ESXi so sollte man nur das nehmen was
1.) üblich und erprobt ist
2.) nicht das neueste ist
Da die Probleme meist im Breich Netzwerk- und Plattentreiber liegen, so kann man üblicherweise alternativ einen PCI-e Adapter einstecken bis ein Treiber für Onboardgeräte verfügbar ist. Bei iTX ist das verwehrt. Ich würde daher immer ITX meiden und wenigstens Flex-ATX oder uATX nehmen.
Für ein AiO System ist die Idealkonfiguration immer Sata für ESXI (ESXi boot + local datastore) und ein BroadCom/LSI SAS HBA. Diesen SAS HBA kann man problemfrei komplett an eine Storage VM durchreichen oder daran angeschlossene Sata/SAS Platten einzeln in den VM-Einstellungen per Disk > Add: Raw einer beliebigen VM hinzufügen (sogar mehreren für HA Setups).
Mit einem M.2 Port könnte man zwar versuchen, ESXi + local datastore auf die M.2 zu legen um Sata an die Storage VM durchzureichen, das ist aber außerhalb dessen was immer und sofort funktioniert.
Das Board ist also für das Vorhaben eher ungeeignet oder zumindest "suboptimal".
Das Einzige was geht (bis ESXi einen Treiber hat, sollte mittelfristig der Fall sein) ist eine PCI-e Netzwerkkarte und physical RDM der Sata Platten oder Booten von M.2 und Pass-through von Sata (sofern das nicht zickt.)
Sobald man von Windows und schon mit Einschränkungen Linux weggeht
hin zu Unix (BSD, OSX, Solarish) oder ESXi so sollte man nur das nehmen was
1.) üblich und erprobt ist
2.) nicht das neueste ist
Da die Probleme meist im Breich Netzwerk- und Plattentreiber liegen, so kann man üblicherweise alternativ einen PCI-e Adapter einstecken bis ein Treiber für Onboardgeräte verfügbar ist. Bei iTX ist das verwehrt. Ich würde daher immer ITX meiden und wenigstens Flex-ATX oder uATX nehmen.
Für ein AiO System ist die Idealkonfiguration immer Sata für ESXI (ESXi boot + local datastore) und ein BroadCom/LSI SAS HBA. Diesen SAS HBA kann man problemfrei komplett an eine Storage VM durchreichen oder daran angeschlossene Sata/SAS Platten einzeln in den VM-Einstellungen per Disk > Add: Raw einer beliebigen VM hinzufügen (sogar mehreren für HA Setups).
Mit einem M.2 Port könnte man zwar versuchen, ESXi + local datastore auf die M.2 zu legen um Sata an die Storage VM durchzureichen, das ist aber außerhalb dessen was immer und sofort funktioniert.
Das Board ist also für das Vorhaben eher ungeeignet oder zumindest "suboptimal".
Das Einzige was geht (bis ESXi einen Treiber hat, sollte mittelfristig der Fall sein) ist eine PCI-e Netzwerkkarte und physical RDM der Sata Platten oder Booten von M.2 und Pass-through von Sata (sofern das nicht zickt.)
Da mir in "meinem" Thread (Tipps zu Homeserver Virtualisierung / Strukturierung - Seite 3) bislang noch niemand einen Tipp geben konnte bzgl. einer sinnvollen Strategie, mit meinen vorhandenen Platten einen ZFS Pool aufzusetzen, versuche ich mein Glück mal hier. Andernorts sind Doppelposts verpönt / nicht gewünscht und falls das hier auch so sein sollte, dann bitte ich vielmals um Entschuldigung - dann dürfen die Moderatoren diesen Beitrag hier gerne löschen
Vorgeschichte: Ich baue einen per ESXi virtualisierten Server neu auf, als Storage VM kommt napp-it zum Einsatz. Da bin ich noch recht weit am Anfang. ESXi läuft im Wesentlichen, napp-it ist installiert. Einige der verfügbaren Platten sind noch in Benutzung, andere nicht. Ziel ist es, eine Storage VM bereitzustellen und wieder eine Backup-Platte (möglichst extern) zu haben. Auf dem NAS schlummern überschaubare rd. 950GB an Daten, weitere knapp 500 GB liegen auf dem abzulösenden VDR. Insgesamt stehen folgende Platten zur Verfügung:
* 4x 500GB (Western Digital)
** 2x stecken schon im Server
** 1x noch im alten NAS, könnte dort raus und in den Server
** 1x noch im alten VDR, sollte da möglichst noch verbleiben
* 2x 2TB (Hitachi)
** 1x noch im alten NAS => Da sind derzeit sämtliche Daten drauf. Ist somit zunächst einmal die Quelle für die Initialbetankung des neuen Servers und steht erst danach zur Verfügung
** 1x als Backup Platte. Backup aus Gründen nicht ganz aktuell, aber das Delta seit dem letzten erfolgreichen Backup ist gering.
Frage: Macht es überhaupt Sinn, mit diesen Platten loszulegen? Ich bin durchaus bereit, bei Gelegenheit nochmal in neue Platten zu investieren. Dann werden es auch ausreichend große und viele gleichartige Platten werden. Aber ob ich den Tausender noch in diesem Jahr springen lasse... weiß nicht.
Welche Konfiguration bzw. Vorgehensweise wäre aus Eurer Sicht sinnvoll, um mit den vorhandenen Platten einen neuen Pool anzulgegen, die Daten vom NAS (und später vom VDR) rüber zu migrieren und anschließend beide 2GB Platten mit zu nutzen (eine davon als Backup Platte im externen USB Gehäuse)? Wie ich gelesen habe, muss ich mich von vornherein entschließen, ob ich einen Basic Pool, ein RAIDZ1 oder ein RAIDZ2 haben möchte. Außerdem ist es wohl ungünstig (no go?) im Nachhinein eine einzelne Platte zum Pool hinzuzufügen. Ist das richtig?
Meine Überlegung war, jetzt einen Pool mit den 500 GB Platten (drei?) anzulegen, wegen mir noch die 2TB Backup Platte mitzunutzen, die Daten vom NAS zu migrieren und nach erfolgreicher Migration die bislang produktive 2TB Platte aus dem NAS als Backup Platte weiter zu nutzen. Ist diese Vorgehensweise sinnvoll? Und kann ich die drei 500GB Platte sinnvoll mit einer 2TB Platte kombinieren, oder bleiben da von vornherein 1,5 TB auf der 2TB Platte ungenutzt? Hmm, da sind bei mir noch viele Fragezeichen...
Wäre nett, wenn mir jemand hier möglichst konkrete Tipps, auch zur Vorgehensweise geben könnte.
Und wie gesagt: dieser Beitrag kann gerne wieder raus genommen werden, es ist immer noch mein Originalthread mit der gleichen Frage offen und wartet auf Rückmeldungen Thanx,folks!
Vorgeschichte: Ich baue einen per ESXi virtualisierten Server neu auf, als Storage VM kommt napp-it zum Einsatz. Da bin ich noch recht weit am Anfang. ESXi läuft im Wesentlichen, napp-it ist installiert. Einige der verfügbaren Platten sind noch in Benutzung, andere nicht. Ziel ist es, eine Storage VM bereitzustellen und wieder eine Backup-Platte (möglichst extern) zu haben. Auf dem NAS schlummern überschaubare rd. 950GB an Daten, weitere knapp 500 GB liegen auf dem abzulösenden VDR. Insgesamt stehen folgende Platten zur Verfügung:
* 4x 500GB (Western Digital)
** 2x stecken schon im Server
** 1x noch im alten NAS, könnte dort raus und in den Server
** 1x noch im alten VDR, sollte da möglichst noch verbleiben
* 2x 2TB (Hitachi)
** 1x noch im alten NAS => Da sind derzeit sämtliche Daten drauf. Ist somit zunächst einmal die Quelle für die Initialbetankung des neuen Servers und steht erst danach zur Verfügung
** 1x als Backup Platte. Backup aus Gründen nicht ganz aktuell, aber das Delta seit dem letzten erfolgreichen Backup ist gering.
Frage: Macht es überhaupt Sinn, mit diesen Platten loszulegen? Ich bin durchaus bereit, bei Gelegenheit nochmal in neue Platten zu investieren. Dann werden es auch ausreichend große und viele gleichartige Platten werden. Aber ob ich den Tausender noch in diesem Jahr springen lasse... weiß nicht.
Welche Konfiguration bzw. Vorgehensweise wäre aus Eurer Sicht sinnvoll, um mit den vorhandenen Platten einen neuen Pool anzulgegen, die Daten vom NAS (und später vom VDR) rüber zu migrieren und anschließend beide 2GB Platten mit zu nutzen (eine davon als Backup Platte im externen USB Gehäuse)? Wie ich gelesen habe, muss ich mich von vornherein entschließen, ob ich einen Basic Pool, ein RAIDZ1 oder ein RAIDZ2 haben möchte. Außerdem ist es wohl ungünstig (no go?) im Nachhinein eine einzelne Platte zum Pool hinzuzufügen. Ist das richtig?
Meine Überlegung war, jetzt einen Pool mit den 500 GB Platten (drei?) anzulegen, wegen mir noch die 2TB Backup Platte mitzunutzen, die Daten vom NAS zu migrieren und nach erfolgreicher Migration die bislang produktive 2TB Platte aus dem NAS als Backup Platte weiter zu nutzen. Ist diese Vorgehensweise sinnvoll? Und kann ich die drei 500GB Platte sinnvoll mit einer 2TB Platte kombinieren, oder bleiben da von vornherein 1,5 TB auf der 2TB Platte ungenutzt? Hmm, da sind bei mir noch viele Fragezeichen...
Wäre nett, wenn mir jemand hier möglichst konkrete Tipps, auch zur Vorgehensweise geben könnte.
Und wie gesagt: dieser Beitrag kann gerne wieder raus genommen werden, es ist immer noch mein Originalthread mit der gleichen Frage offen und wartet auf Rückmeldungen
Thanx,folks!danielmayer
Enthusiast
- Mitglied seit
- 30.03.2005
- Beiträge
- 1.010
@gea: Ich nutze in der Tat Linux seit über 15 Jahren und hatte seit fast genauso lange keine Probleme mehr mit NIC-Treibern... Da hatte ich schlicht nicht dran gedacht. Ansonsten alles nach bewährter Methode: H310 auf IT geflasht, besterinos SAS-Expander (ohne PCIe-Slot-Notwendigkeit), XCase 16-Hotswap 19"-3U-Gehäuse und 48GB RegECC RAM. Es sah so gut aus ;(
In OpenIndiana/Proxmox ist das Napp-IT saaaaauuu langsam (2h für "processing" bis - vermutlich - alle Menüpunkte da sin...).
Ich steige wohl doch mit diesem Board wieder auf mein altbewährtes Ubuntu inkl. ZFS@LUKS...
Also liebe Leute: "NappIT || Denverton"
edit: btw, OI mit GUI bare-metal kommt bei Installations-Booten nicht über die ersten drei Zeilen hinaus... :/
In OpenIndiana/Proxmox ist das Napp-IT saaaaauuu langsam (2h für "processing" bis - vermutlich - alle Menüpunkte da sin...).
Ich steige wohl doch mit diesem Board wieder auf mein altbewährtes Ubuntu inkl. ZFS@LUKS...
Also liebe Leute: "NappIT || Denverton"
edit: btw, OI mit GUI bare-metal kommt bei Installations-Booten nicht über die ersten drei Zeilen hinaus... :/
Zuletzt bearbeitet:
Der beste Rat wird wohl der sein, den Pool strukturell so anzulegen wie man ihn später mal haben möchte. Wenn man also auf einen Raid-Z2 Pool möchte, dann z.B. eine Pool aus 6 Platten aufbauen (wobei die kleinste Platte aktuell die Kapazität vorgibt) oder aber einen Raid-10 Pool aus 4 bzw 6 Platten erstellen. Wenn man dann später die kleinen Platten ersetzt wird die volle Kapazität genutzt. Bei Raid-10 kann der Pool einfach jeweils mit zwei Platten als Mirro wachsen.
Einen Pool umzustrukturieren ist momentan noch nicht so einfach. Lediglich das neue Solaris 11.4 beherrscht das Entfernen beliebiger vdevs und das Erweitern eines vdevs um einzelne Platten kommt frühestens Ende des Jahres bei Open-ZFS.
- - - Updated - - -
Für neue Intel Nics kommen angepasste Treiber für Unix und ESXi meist "relativ" zeitnah. Da sollte eine Lösung absehbar sein. Die Unterstützung von Unix unter Proxmox dürfte bei weitem nicht so gut sein wie unter ESXi (da wird ja von BSD über Linux, OSX, Solaris bis Windows alles bestens unterstützt, man muss sich aber an die HCL halten)
Wenn OI beim Installieren hier hängt, liegt es meist an nicht gefiúndener Hardware (warten bis zum Timeout, kann auch mal 10Minuten dauern) oder aber an USB Problemen. Wenn das Board unterschiedliche USB (v2/v3) hat, mal USB2 versuchen. Eine andere Option ist es, im Bios nach den USB Einstellungen zu schauen, vgl SuperMicro X11 SPH-nCTPF/ nCTF on OmniOS/OI/Solaris | ServeTheHome and ServeThe.Biz Forums
Teilweise ist auch OmniOS das den BSD Loader nutzt beim Booten etwas unkritischer als OI bei neuer Hardware. Auch unterstützt OmniOS LX/Linux Zonen (Linux Virtualisierung unter Solaris, übernommen aus SmartOS/Joyent). Da gibt es aber dafür keine Desktop Version
Danke, @gea! D.h. also, dass mit Raid-Z2 oder Raid-Z1 ein schrittweiser Aufbau nicht wirklich möglich sein wird, also z.B. zu einem späteren Zeitpunkt noch eine der 500GB Platten dazu zu nehmen, richtig? Und bei einem Raid10 halbiere ich den Plattenplatz im Vergleich zu den eingesetzten Platten. Dafür könnte ich aber immer zwei Platten ergänzen, die für sich als Mirror arbeiten und den vorhandenen Pool per Striping erweitern. Auch richtig?
Würde denn folgende Konfiguration möglich und sinnvoll sein? Zunächst ein Stripeset aus 4x 500GB = 2TB, welches dann mit einer der 2TB Platten einen Mirror bildet? Das wäre dann ein RAID01? Damit hätte ich 2TB Speicherplatz zur Verfügung bei einfacher Ausfallsicherheit (wann immer eine Platte, egal welche ausfällt, federt der Mirror den Ausfall dieser einen Platte ab). So richtig bildet das meine Wunschkonfiguration nicht ab, aber ich könnte zunächst das Stripeset aus den 500GB Platten bilden, die Daten von der produktiven 2TB Platte via NFS rüber kopieren und anschließend meine 2TB Backup Platte umwidmen als Mirror zum Stripeset. Sobald der Mirror aktiv ist, wären die Daten dreimal vorhanden (Stripeset, Mirror und ursprüngliches Original). Ab dann könnte ich die dann ehemals produktive 2TB Platte zur Backup Platte umwidmen und hätte zu keiner Zeit die Gefahr von Datenverlust wegen Plattenausfall. Aber ich fürchte, das klappt so nicht, oder?
Klappt in der Tat so nicht (ZFS unterstützt das so nicht ohne Umwege).
Ein ZFS Pool besteht aus vdevs. Das sind quasi eigenständige Raid Arrays aus Basic (Raid-0), Mirror oder Raid-Zn. Diese vdevs werden grundsätzlich als Raid-0 verknüpft. Zwei vdevs lassen sich nicht spiegeln.
Die einzige Möglichkeit das doch zu erreichen wäre etwas komplizierter.
Man könnte einen Raid-0 Pool aus den 4 x 500G Platten machen und den komplett als iSCSI Target freigeben.
Dieses Target könnte man dann als 2 TB Platte mounten und mit einer physikalischen 2TB Platte spiegeln um daraus ein raid-1 vdev bauen. Das wäre über Umwege das Spiegeln der 2TB Platte mit einem 4x500 MB Array.
Das widerspricht aber dem KISS Prinzip für problemfreie Technik.
Sollte man allenfalls als Übergangslösung machen bis man eine zweite 2TB Platte hat um das iSCSI Target damit zu ersetzen.
gea, gibt es noch eine Möglichkeit napp-it 0.8 zu installieren? Ich habe einen alten opensolaris Server den ich gerne damit versorgen möchte. Das Kommando wget -O - http://www.napp-it.org/nappit08 führt zu einem download Fehler für das File napp-it-0.8l3.zip
Zuletzt bearbeitet:
