[Sammelthread] ZFS Stammtisch

[CommanderBond]

. Sie haben aber keine Powerloss Protection

Naja so ganz stimmt das nicht. Die mx500 hat PLP für ruhende Daten.
Was sie idr nicht haben sind Kondensatoren.
Ganz schutzlos ner Unterbrechung der Spannungsversorgung sind sie auch nicht ausgeliefert. Da würde selbst im Consumerbereich dann niemand kaufen wenn bei einem Stromausfall ständig die Daten auf der SSD weg wären.
Fürs Slog vielleicht ungeeignet für einen normalen Pool halte ich sie aber durchaus für benutzbar

 

[Trambahner]

Danke gea, jetzt funktioniert das mit 11.4.

Edit: iSCSI auf Basis ZFS-Vols hab ich nun auch hinbekommen. Via Shell. Wenn mans mal ein bissl anschaut, ist das unter Solaris eigentlich recht logisch mit dem Basic Netzwerk und Storage.

Edit 09.02.19: Ich mag die Performance von dem Ding. Muss ich mal vergleichen mit FreeBSD 12 und OmniOS.

 

[AliManali]

Hi

Ich habe echt das Problem, dass wenn ich napp-it mehr als einen Kern zuweise, per DHCP keine Adresse bezogen wird.



Wenn ich zusätzlich noch VMXNET3 aktiviere, findet napp-it glaub ich nicht mal mehr einen Adapter.



Ich glaube, dass wohl die Uhrzeit/Datum von napp-it auch nicht stimmt. Von daher ist das log recht schwer zu analysieren.

Mit 1C und E1000 Adapter funktioniert das napp-it Storage super. VM-Tools sollten laut vSphere Client installiert sein.

Ach ja, und habe ich vor ein paar posts auch schon gefragt: kann ich napp-it an der VM Konsole einfach per shutdown beenden?

 

[CommanderBond]

wie bekommt man am einfachsten noch Daten gesichert von einer einzelnen HDD mit ZFS. Der Pool aus einer HDD wird als Degraded angezeigt, allerdings ist Zugriff weiterhin möglich. Kopieren von manchen Dateien fängt auch an, doch dann auf einmal springt der Kopierdialog auf 100% und schließt sich. Verhält sich so als ob wäre die Datei erfolgreich kopiert worden allerdings ist der Zielordner leer.
Ein Scrub habe ich nicht gemacht da ich mir unsicher bin was dann geschieht. Zumal es auch unnötige Belastung wäre, will nur Dateien runterkopieren.

 

[gea]

Hi
Ich habe echt das Problem, dass wenn ich napp-it mehr als einen Kern zuweise, per DHCP keine Adresse bezogen wird.

Mir ist da nur dieses Problem bekannt das zu einem Netzwerkverlust führt.
Workaround and fix for intermittent Intel X552/X557 10GbE/1GbE network outages on Xeon D-1521/1540 and pre-2018 1567/1587; popular E300-8D/E200-8D 1518/1528 and 1541 never had the issue | TinkerTry IT @ Home

Ich glaube, dass wohl die Uhrzeit/Datum von napp-it auch nicht stimmt. Von daher ist das log recht schwer zu analysieren.

Man kann die Zeit per other Job und ntpdate stellen. Mit vmware tools sollte eh ESXi der Zeitgeber sein. Eventuell sollte man noch auf Europa > De stellen damit man MEZ hat ( System > HW and Localization > Localization )

Mit 1C und E1000 Adapter funktioniert das napp-it Storage super. VM-Tools sollten laut vSphere Client installiert sein.

E1000 würde ich nach Möglichkeit auf den schnelleren vmxnet3 wechseln. 1 Core ist ok. RAM ist wichtiger.

Ach ja, und habe ich vor ein paar posts auch schon gefragt: kann ich napp-it an der VM Konsole einfach per shutdown beenden?

Kein Problem. ZFS verträgt auch einfaches ausschalten ganz gut. NFS ist dann halt weg. Wenn darauf VMs laufen sollte man die vorher runterfahren.

- - - Updated - - -

wie bekommt man am einfachsten noch Daten gesichert von einer einzelnen HDD mit ZFS. Der Pool aus einer HDD wird als Degraded angezeigt, allerdings ist Zugriff weiterhin möglich. Kopieren von manchen Dateien fängt auch an, doch dann auf einmal springt der Kopierdialog auf 100% und schließt sich. Verhält sich so als ob wäre die Datei erfolgreich kopiert worden allerdings ist der Zielordner leer.
Ein Scrub habe ich nicht gemacht da ich mir unsicher bin was dann geschieht. Zumal es auch unnötige Belastung wäre, will nur Dateien runterkopieren.

Wenn bei einem Pool aus einer Platte ohne Redundanz (copies=1) Degraded angezeigt wird, sind einzelne Dateien korrupt, entweder zufällig als silent error oder wegen bad sectors. Die werden aber erst nach einem Scrub alle gefunden und angezeigt. Eine Reparatur ist wegen fehlender Redundanz nicht möglich. Da die Metadaten doppelt vorhanden sind ist ein Scrub ziemlich unkritisch, belastet aber natürlich die Platte.

 

[CommanderBond]

Will sie nicht reparieren nur die intakten Dateien kopieren. Die Frage ist nur wie am besten. Der Windows Explorer ist da nicht zu gebrauchen zu, da er den kompletten Kopiervorgang manchmal auch abbricht nur weil eine Datei sich nicht kopieren lässt.

 

[asche77]

@36AliManali: OmniOS unter ESXi 6.5 kann auch mit zwei vcores (auf einem vSockel) DHCP. Ich hatte aber auch schon Probleme, zB wenn ich mehr als eine vNIC haben wollte, ab dann ging nur statisch. -> bei mir hat eine Neuinstallation geholfen. VMXNet 3 empfohlen.

Zeit: NTP / ntpsec deinstallieren(!), open-vm-tools installieren und im ESXi (1) NTP einstellen und (2) bei der VM auch einstellen, dass ESXI die Zeit der VM mit dem ESXI-Host synchronisiert ...

 

[gea]

Ich würde robocopy versuchen, z.B.

robocopy e:\ f:\ /w:1 /r:1

kopiert von e:\ nach f:\ und überspringt Dateien nach dem ersten Fehl-Versuch.
Man kann Fehler auch protokollieren, robocopy | Microsoft Docs

 

[negotiator]

Frage zum Thema "inkrementelle Backups":
Ich mache per Script von ein meiner Pools (nennen wir ihn "data") tägliche Snapshots, die dann mit einem anderem Script wöchentlich per ZFS SEND inkrementell auf einen anderen Pool (nennen wir ihn "dataBackup") gesichert werden. Von den täglichen Snapshots in "data" halte ich vier Wochen, "dataBackup" hat eine Historie von einem Jahr.
Dummerweise ist aber durch einen Fehler Script-2 seit Anfang des Jahres nicht gelaufen, so dass mir nun für ein inkrementelles Backup die Basis fehlt. Wie bekomme ich nun den aktuellen Stand des Pools "data" nach "dataBackup", ohne dass ich die Snapshots von Pool "dataBackup" verliere? ZFS SEND in einen existierenden Pool geht ja nur inkrementell...

 

[Trambahner]

?? Natürlich kannst Du mehrere Stände in einem Pool haben.
Mit ZFS send/recv kannst Du doch ein Snap von der Quelle jederzeit als neues Dataset am Ziel anlegen lassen und damit ein Full Snap schicken?
Ein "dataBackup2" (oder auch "dataBackup3", "dataBackup4", etc) ist daher doch kein Problem und "dataBackup" mit seinen Snaps lässt Du einfach unangetastet.
Die Grenze setzt da nur der verfügbare Platz im Pool.

Ich lege Backups grundsätzlich in einem eigenen Dataset und nicht direkt auf dem Pool der Backupmaschine an; normal als Name mit dem Datum des Basis-Snaps.
d.h. aus "zhgst\setname\..." auf der Quelle wird dann z.B. "red\20190217\setname\..." auf der Backupmaschine.

 

[negotiator]

Danke für das schnelle Feedback, Trambahner.
Habe "natürlich" mal wieder nicht sauber formuliert... Ich meinte nicht "Pool", sondern ein Filesystem, also "pool/data" wird auf "poolBackup/dataBackup" repliziert.
Das ändert natürlich an deiner grundsätzlichen Aussage nichts, dass ich natürlich einfach ein neues Filesystem im Pool anlegen kann. Übersichtlicher - und das möchte ich mir bewahren - wäre es aber, die Snapshots nicht über mehrere Datasets verteilt liegen zu haben. Der Zugriff über die "Previous Versions" bei Windows wäre dann nicht mehr so elegant möglich.


Spricht denn etwas grundsätzlich dagegen, das Filesystem per rsync ins Ziel-Filesystem zu spiegeln und dann manuell einen Snapshot zu machen. Darauf aufbauend könnte ich doch wieder inkrementell sichern. Oder handele ich mir damit im Zweifel Probleme mit Inkonsistenzen ein?

 

[Bzzz]

Will sie nicht reparieren nur die intakten Dateien kopieren.

Platte extern duplizieren und dann eine davon scrubben? Oder du scrubbst deine einzige Platte direkt, denn wie gea schon sagt, erst danach weiß ZFS, was alles unlesbar ist. Kommt halt drauf an, wie sehr du an deinen nicht redundant gespeicherten Daten hängst, "nicht sehr" wär jetzt meine Vermutung. Dann direkt scrubben...

 

[gea]

Spricht denn etwas grundsätzlich dagegen, das Filesystem per rsync ins Ziel-Filesystem zu spiegeln und dann manuell einen Snapshot zu machen. Darauf aufbauend könnte ich doch wieder inkrementell sichern. Oder handele ich mir damit im Zweifel Probleme mit Inkonsistenzen ein?

Prinzipiell kann man mit rsync und replikation zwei Dateisysteme syncron halten und beidesmal mit Snaps auf dem Backupsystem Versionen halten. Wenn man bei rsync als Quelle einen Snap nimmt sogar auch da mit offenen Dateien.

Replikation erzeugt einen einfachen sequentiellen Datenstrom während rsync auf Dateivergleichen aufbaut und damit viel random io Last erzeugt. Beim erstmaligen Lauf ist der Geschwindigkeitsunterschied eventuell verkraftbar. Replikation kann da aber auch gerne mal doppelt so schnell sein oder noch besser.

Beim inkrementellen Lauf kann der Unterschied dann extrem sein. Inkrementelle Replikation die häufiger läuft dauert wenige Sekunden für ein Update bei minimaler Last. Rsync muss erneut alle Dateien lesen und vergleichen, erzeugt also erheblich mehr Last und kann gerne mal hundertmal mehr Zeit brauchen. Auch kann nur Replikation ZFS Eigenschaften wie z.B. ACL beibehalten.

Besser also das Dateisystem erneut komplett replizieren und dann weiter inkrementell. Dazu das Ziel Dateisystem vorher löschen oder umbenennen um die Struktur beizubehalten.

 

[negotiator]

Danke, gea, die Vorzüge der ZFS Replikation sind wohlbekannt...
Dann muss ich wohl den Weg gehen und ein neues Dateisystem anlegen.

Ich hatte gehofft, es gibt eine Möglichkeit, beide Seiten auf den aktuellen Stand zu bringen (rsync?), dann auf beiden Seiten einen Snapshot anzulegen und darauf aufbauend dann wieder eine inkrementelle Replikation zu starten - geht aber anscheinend nicht, oder?

 

[gea]

Nein, geht nicht da man auf beiden Seiten den exakt identischen Basis-Snap braucht. Auf der send Seite wird dann ein Snap erzeugt der alle Änderungen zum Basis-Snap enthält. Auf der receive Seite wird dann vor dem Empfang das Dateisystem auf den gemeinsamen Basissnap zurückgesetzt. Der übertragende Snap aktualisiert dann die geänderten Datenblöcke.

ZFS Replikation ist da wie eine Radiosendung bei der man den ersten Teil eines Liedes bereits aufgenommen hat und dann der zweite Teil gesendet wird. Das klappt nur wenn der Empfänger genau weiß wann das Lied fortgesetzt wird und da auf Aufnahme geht um den Rest ohne Unterbrechung aufzunehmen. Fehlt der erste Teil der Aufnahme wird das nichts.

 

[sch4kal]

Wenn man sich den RAM-Preissturz der letzten Monate so anschaut...wird einem Warm ums Nerd-Herz

Ich glaube, ich geh dieses Jahr noch auf 256 GB RAM, da macht ZFS gleich noch viel mehr Spaß

 

[negotiator]

@gea: Danke, ich hatte es befürchtet.
Wie immer wieder exzellent auf den Punkt gebracht und gut erklärt - echt top, was du hier leistet (und alle anderen erfahrenen Leute hier natürlich auch)!

 

[VLB]

Hallo, ich hab einige Verständnisfragen:

1. Wenn ich ZFS mit compression habe und davon inkrementelle Snapshots an einen Backup-Server sende (zfs send) - werden die Daten entpackt, bevor sie über das Netzwerk gehen?

2. Ich arbeite mit OmniOS CE, "zpool get version tank" gibt mir nur "-" aus. Welche ZFS-Version ist das dann? Da war doch mal was, bestimmte OS konnten nur bestimmte ZFS-Versionen. Oder spielt das mittlerweile keine Rolle mehr?

 

[AliManali]

Hi

Habe mal eine Frage. Habe ein E5 XEON mit napp-it (1C, 14 GB) per DELL PERC 310 im IT Mode. Daran hängt eine 2 TB SSD (850 EVO, oder so; sicher keine 840 EVO mit dem FW Bug) per NFS an vSphere für die VM's, und eine 6 TB WD Gold für Backups, die nicht als Speicher an vSphere geht.

Wenn ich am napp-it per midnight commander über putty von SSD zu HDD kopiere, geht das mit 120-180 MB/s. Wenn ich aber von HDD auf SSD kopiere, bricht der Vorgang irgendwann ein auf 40 MB/s. Allerdings laufen da auch 10-15 Gäste an der SSD, wobei das sollte sich meiner Meinung nach aber grösstenteils im RAM abspielen. Paar FW, VPN Gateways, Linux Server, NAS und 5 Windows VM's.

Ich vermute da ist die SSD der Flaschenhals, kann das sein?

 

[sch4kal]

@gea, habe ein Problem beim Erzeugen eines BE-Replication Jobs:

Ich glaube er hat ein Problem mit den Leerzeichen in "rpool/ROOT/BEsolaris NR / 4.67G static 2019-01-18 17:26"

root@nas:~# perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/job-replicate.pl run_4711
too many arguments
For more info, run: zfs help snapshot
cannot open 'rpool/ROOT/BEsolaris': filesystem does not exist
cannot open 'NR': filesystem does not exist
cannot open '4.66G': filesystem does not exist
cannot open 'static': filesystem does not exist
cannot open '2019-01-18': filesystem does not exist
cannot open '17:26': filesystem does not exist
too many arguments
For more info, run: zfs help send
too many arguments
For more info, run: zfs help destroy
cannot open 'saspool/backup/solaris/21022019-BE': filesystem does not exist

Solaris 11.4 mit napp-it v.19 dev 06.feb.2019

 

[gea]

Hallo, ich hab einige Verständnisfragen:

1. Wenn ich ZFS mit compression habe und davon inkrementelle Snapshots an einen Backup-Server sende (zfs send) - werden die Daten entpackt, bevor sie über das Netzwerk gehen?

2. Ich arbeite mit OmniOS CE, "zpool get version tank" gibt mir nur "-" aus. Welche ZFS-Version ist das dann? Da war doch mal was, bestimmte OS konnten nur bestimmte ZFS-Versionen. Oder spielt das mittlerweile keine Rolle mehr?

1.
Ja

2.
Original Oracle Solaris ZFS arbeitet nach wie vor mit ZFS Versionen z.B. v44
Open-ZFS nutzt keine Versionen (setzt intern Version 5000 um Probleme mit Oracle Solaris zu vermeiden) und macht Unterschiede mit "Features" Ein Pool ist dann kompatibel, wenn das Zielsystem aktivierte Features unterstützt. In napp-it kann man mit Pools > Features diese anzeigen oder aktivieren. Auch kann man einen Pool anlegen der keine Features aktiviert. Dieser ist dann auf jedem Open-ZFS System importierbar (hat aber keine neuen ZFS Bonbons)

- - - Updated - - -

Hi

Habe mal eine Frage. Habe ein E5 XEON mit napp-it (1C, 14 GB) per DELL PERC 310 im IT Mode. Daran hängt eine 2 TB SSD (850 EVO, oder so; sicher keine 840 EVO mit dem FW Bug) per NFS an vSphere für die VM's, und eine 6 TB WD Gold für Backups, die nicht als Speicher an vSphere geht.

Wenn ich am napp-it per midnight commander über putty von SSD zu HDD kopiere, geht das mit 120-180 MB/s. Wenn ich aber von HDD auf SSD kopiere, bricht der Vorgang irgendwann ein auf 40 MB/s. Allerdings laufen da auch 10-15 Gäste an der SSD, wobei das sollte sich meiner Meinung nach aber grösstenteils im RAM abspielen. Paar FW, VPN Gateways, Linux Server, NAS und 5 Windows VM's.

Ich vermute da ist die SSD der Flaschenhals, kann das sein?

Desktop SSDs brechen in der Schreibleistung bei dauerhaftem Schreiben nach einiger Zeit massiv ein. (Server SSD haben das nicht). Ich denke auch, die EVO SSD ist das Problem (vor allem wenn sie voller wird)

- - - Updated - - -

@gea, habe ein Problem beim Erzeugen eines BE-Replication Jobs:
Anhang anzeigen 459619
Ich glaube er hat ein Problem mit den Leerzeichen in "rpool/ROOT/BEsolaris NR / 4.67G static 2019-01-18 17:26"
Solaris 11.4 mit napp-it v.19 dev 06.feb.2019

Leerzeichen in BE, Dateinamen, Pfadnamen, Dateisystem- oder Poolnamen kann man unter Unix machen, aber nur wenn man Probleme entdecken möchte. Manchmal geht das, irgenwann halt nicht weil irgendein Dienst das nicht erwartet/unterstützt.

Lösung
- ein neues BE anlegen (ohne Leerzeichen), aktivieren und neu starten
- dann nochmal versuchen

 

[dogma2k]

Ich hatte mit gea per PM gesprochen weil ich dachte es passt nicht hier so wirklich rein. Er hat mir aber gesagt das dem nicht so ist, deshalb Poste ich die PM's hier nochmal und mache dann hier weiter.

Die neueste ova (151028) ist auf ESXi 6.7 ausgelegt (wegen neuen Features). Alle älteren Templates laufen ab ESXi 5.5. Ich würde mir aber (sofern die CPU neu genug ist) ein Update auf ESXi 6.7 u1 überlegen. Dazu ESXi 6.7u1 iso downloaden und davon booten (oder per Rufus daraus einen USB Bootstick machen) und dann ESXi updaten wählen. ESXi Einstellungen bleiben dabei erhalten.

Grüße

Gea

Ein ova Template kann einfach bereitgestellt/ importiert werden. Die VM ist direkt lauffähig.

Eine neue VM muss man dann manuell anlegen, wenn man ein OS selbst von einer Installations ISO installieren möchte (mit der iso kann man das OS in einer VM oder auch auf Hardware installieren). Ist die VM dann fertig konfiguriert kann man sie als ova exportieren und wieder importieren/bereitstellen.

viele Grüße


Gea

Hallo,

ich bin gerade dabei mit dem Thema zfs erneut auseinander zu setzten. Dabei habe ich festgestellt das ich keine *.ova finde die mit meinen ESXi 5.5 passen würde.
Gibt es eine einigermaßen "aktuelle" OmniOS version für 5.5 noch wo anders zum Download?

Gruß
Dogma

Hallo Dogma
Auf den Downloadservern gibt es in /old fürhere Versionen (lts und 151026) die auf 5.5 laufen.

Man kann aber einfach eine neue VM (Solaris 64, 30GB) anlegen und OmniOS 151028 von der iso installieren. Dann napp-it per wget installieren und die Open-VM Tools mit pkg install open-vm-zools dazu. Damit hat man eine funktionierende Basisinstallation.

Grüße

Gea

Danke erstmsl für die Antwort,

jetzt bin ich allerdings verwirrt... wenn ich die Vers. napp-it-san024-jan2018 herunterlade muss ich doch eine neue Solaris VM erstellen oder? Oder liegt es daran dass das andere eine *.iso ist und erst komplett installiert werden muss und die *.ova schon eine fertige VM ist?

Gruß
Dogma

Ah ok ich verstehe...
würde denn napp-it-san024-jan2018 mit dem ESXi 5.5 funktionieren. Die habe ich beim Download Ordner gefunden und old

Gruß

1.
ESXi 5.5 > 6.7 sollte ok sein

2.
Die VMware Site ist übel
Manchmal muss man ein neueres Produkt dem Account extra hinzufügen. Am Angang auch nur für Pro Kunden.

3.
ZFS läßt alles zu und für jede Konfig gibt es Gründe

im Regelfall skaliert die sequentielle Performance mit der Anzahl der Datenplatten im Raid, die iops (damit bis auf Solaris auch das Resilver) mit der Anzahl der vdevs

Mehr als ca 10 Platten pro Z2 vdev und 16 Platten pro Z3 sollte man nicht nehmen.

Der Rest is Optimierung aif Preis, Kapazität oder Performance

ps
Das interessiert auch andere, ist nicht so speziell
Bitte Fragen dann im Forum posten

Grüße


Gea

Die neueste ova (151028) ist auf ESXi 6.7 ausgelegt (wegen neuen Features). Alle älteren Templates laufen ab ESXi 5.5. Ich würde mir aber (sofern die CPU neu genug ist) ein Update auf ESXi 6.7 u1 überlegen. Dazu ESXi 6.7u1 iso downloaden und davon booten (oder per Rufus daraus einen USB Bootstick machen) und dann ESXi updaten wählen. ESXi Einstellungen bleiben dabei erhalten.

Grüße

Gea

Hat da zwei "Probleme" und eine frage zur ZFS Auslegung

1. Ich wollte eigentlich ESXi nicht updaten da es wohl in mehreren Stufen gemacht werden muss. Glaube 5.5 -> 6.0->6.5->6.7u1. Habe das bis jetzt noch nicht gemacht weil ich viel gelesen habe das da eine menge bei schief gehen kann. Oder kann mn bei der 6.7U1 einfach die alten 5.5 VM dem ESXi 6.7U1 zuweisen (ging bei 5.5 als mein USB Stick im a.... war brauchte nur neu installieren und die VM nur hinzufügen)

2. Die 6.7U1 ist für mich nicht downloadbar (DL Button bleibt grau). Ich kann nur die 6.7 laden, warum

3. Habe mir eine excel Tabelle gemacht mit den möglichen Kapazitäten bei den verschiedenen RaidZ's. Ziel war 24-32 TB. Habe meine engere Auswahl grün makiert... nur welche ist die "bessere/optimalste" in hinsicht der HDD größen (weil um so größer um so länger das rebuild desto höher die wahrscheinlichkeit das noch eine HDD derweil hops geht). Könntest du mal rein schauen? Tabelle

Gruß
Dogma

Kann ich denn wie in der Tabelle die Optane 800p als ZIL und L2ARC benutzten?

P.S. Ich versuche gerade mit meinen Ersatzsystem ein update 5.5 auf 6.7 zu probieren. Was soll ich sagen schon zweimal nicht geklappt einmal von 5.5 auf 6.0 (beim zweiten mal hats geklappt) und das selbe bei 6.0 zu 6.5 . Mal sehen was bei 6.5 zu 6.7 passiert. Doof ist nur das jedesmal der stick im eimer wäre und man eine komplet neuen Hyperv aufsetzten muss. Ist das immer so?

 

[gea]

Eine Optane kann man problemlos als vdisk für beides nehmen. Pass-through und Partitionieren in der VM macht gerne Probleme. Die gleichzeitige Schreib/ Leselast ist für Optane im Gegensatz zu Flash SSD unkritisch.

Ich nehme keine USB Sticks, da kann es eventuell wegen Platzmangel Probleme beim Update geben. Mit einer größeren Sata SSD "sollte" ein direktes Update problemlos laufen wenn man ein neueres ESXi bootet. Ich hatte da jedenfalls noch nie Probleme.

 

[dogma2k]

Bringt es denn was den ZIL aus 2x Optane als mirror zu konfigurieren oder ist bei einer schon der write sync gut genug?

Kann ich denn meinen vorhandenen USB stick durch eine kleine ssd ersetzten oder mit welchen tool kann ich den vorhandenen Stick 1:1 auf einen größeren Stick kopieren?

 

[sch4kal]

Leerzeichen in BE, Dateinamen, Pfadnamen, Dateisystem- oder Poolnamen kann man unter Unix machen, aber nur wenn man Probleme entdecken möchte. Manchmal geht das, irgenwann halt nicht weil irgendein Dienst das nicht erwartet/unterstützt.

Lösung
- ein neues BE anlegen (ohne Leerzeichen), aktivieren und neu starten
- dann nochmal versuchen

Hab ich gemacht, leider findet sich bei der Erstellung eines Replication Jobs in der Dropdown Liste wieder der Pfad inkl. Leerzeichen:

Folglich bleibt es bei dem Fehler :/

Mir ist auch aufgefallen, das es nicht möglich ist ein BE mit dem aktuellen Datum als Namen zu erstellen, und es danach in der GUI zu löschen. Ein manuelles beadm destroy <NAME> funktioniert.
Er findet wohl die Option "-s" nicht. In den Manpages zu beadm unter Solaris 11.4 ist diese Option auch nicht vorhanden.

 

[gea]

Bringt es denn was den ZIL aus 2x Optane als mirror zu konfigurieren oder ist bei einer schon der write sync gut genug?

Nein. Ein Mirror is genauso schnell wie eine Optane. Man macht mirrors damit beim Ausfall einer Platte der Pool unverändert schnell bleibt. Zudem verbessert er etwas die Siecherheit damit bei einem Absturz mit gleichzeitigem Slog Ausfall keine Daten verloren gehen. Ein Slog Ausfall im normalen Betire ist unktitisch. ZFS nutzt dann den onpool ZIL. Genauso sicher (wenn der Pool PLP kann) nur viel langsamer

Kann ich denn meinen vorhandenen USB stick durch eine kleine ssd ersetzten oder mit welchen tool kann ich den vorhandenen Stick 1:1 auf einen größeren Stick kopieren?

Clonezilla oder andere Clone Tools. Die Partition bleibt aber zunächst gleich groß. Die Partition vergrößern kann recht aufwändig werden. Da OmniOS in 10 Minuten neu installiert ist und man ja idealerweise nichts kompliziertes installieren soll ist das der schnellste Weg.

- - - Updated - - -

Hab ich gemacht, leider findet sich bei der Erstellung eines Replication Jobs in der Dropdown Liste wieder der Pfad inkl. Leerzeichen:
Anhang anzeigen 459679
Folglich bleibt es bei dem Fehler :/

Mir ist auch aufgefallen, das es nicht möglich ist ein BE mit dem aktuellen Datum als Namen zu erstellen, und es danach in der GUI zu löschen. Ein manuelles beadm destroy <NAME> funktioniert.
Er findet wohl die Option "-s" nicht. In den Manpages zu beadm unter Solaris 11.4 ist diese Option auch nicht vorhanden.

Ich werde mir das unter Solaris nochmal ansehen (Meine Installationen sind alle OmniOS, habe BE Replikation mit Solaris noch nicht getestet - ich hätte aber kein Problem erwartet)

 

[dogma2k]

1.
ESXi 5.5 > 6.7 sollte ok sein

2.
Die VMware Site ist übel
Manchmal muss man ein neueres Produkt dem Account extra hinzufügen. Am Angang auch nur für Pro Kunden.

3.
ZFS läßt alles zu und für jede Konfig gibt es Gründe

im Regelfall skaliert die sequentielle Performance mit der Anzahl der Datenplatten im Raid, die iops (damit bis auf Solaris auch das Resilver) mit der Anzahl der vdevs

Mehr als ca 10 Platten pro Z2 vdev und 16 Platten pro Z3 sollte man nicht nehmen.

Der Rest is Optimierung aif Preis, Kapazität oder Performance

Nur was ist Sicherer wärend eines rebuilds?

RaidZ2 Variante
Ein RaidZ2 mit 6x6TB Platten oder ein RaidZ2 mit 10x3TB Platten

RaidZ3 Variante
Ein RaidZ3 mit 7x6TB Platten oder ein RaidZ3 mit 11x3TB Platten

Alle Kombinationen haben ja 24TB nur sind die wenigeren großen Festplatten (6TB) im vergleich zu den mehreren kleinen Festplatten (3TB) besser beim rebuild, oder nimmt sich das nix. Weil auf der napp-it Homepage ja steht das es nicht gut ist eine lange rebuild zeit zu haben (was ja bei größeren Festplatten der Fall wäre)

Backup ist natürlich vorhanden... wäre nur ärgerlich wenn mann noch mehr arbeit nach einem fehlgeschlagenen rebuild hat.

 

[MisterY]

Ich würde striped mirrors nehmen. Hier wird nur der mirror wiederhergestellt, der betroffen ist

 

[sch4kal]

Ich würde striped mirrors nehmen. Hier wird nur der mirror wiederhergestellt, der betroffen ist

Verschwendet zu viel Kapazität und ist afaik bei HDDs nicht mehr sinnvoll, seit es bezahlbare SSDs gibt. Z2 mit 6-9x6TB oder Z3 mit 9-12x6TB Platten. Alles andere verschenkt zuviel Platz und ist aus heutiger Sicht mit anständigen Platten einfach unwirtschaftlich.

 

[gea]

Nur was ist Sicherer wärend eines rebuilds?

RaidZ2 Variante
Ein RaidZ2 mit 6x6TB Platten oder ein RaidZ2 mit 10x3TB Platten

RaidZ3 Variante
Ein RaidZ3 mit 7x6TB Platten oder ein RaidZ3 mit 11x3TB Platten

Alle Kombinationen haben ja 24TB nur sind die wenigeren großen Festplatten (6TB) im vergleich zu den mehreren kleinen Festplatten (3TB) besser beim rebuild, oder nimmt sich das nix. Weil auf der napp-it Homepage ja steht das es nicht gut ist eine lange rebuild zeit zu haben (was ja bei größeren Festplatten der Fall wäre)

Backup ist natürlich vorhanden... wäre nur ärgerlich wenn mann noch mehr arbeit nach einem fehlgeschlagenen rebuild hat.

Prinzipiell gilt
- sequentiell skaliert ein Pool mit der Anzahl der Datenplatten
- iops (wahlfreier Zugriff) skaliert mit Anzahl der vdevs, für Resilver besonders wichtig
- mehr Platten - mehr Ausfälle

Sicher bei resilver bedeutet dass bei einem Plattenausfall möglichst schnell der vorherige Online Zustand wiederhergestellt wird. Der Pool wird während des Resilver ja auch langsamer. Bei einem Produktiv-System ein extra Aspekt.

Ein Pool aus zwei vdevs (2 x Z2 vdevs) hat doppelt soviel iops wie ein Pool aus einem Z2 so dass klar die 2 x Z2 Variante besser ist. Z3 aus 6 Platten ist Unsinn da nur 50% Nutzkapazität. Dass bei 6 Platten 4 Platten ausfallen (Pool lost) ist ja statistsch viel unwahrscheinlicher als ein Lotto 6er mit Zusatzzahl (sofern nicht gerade ein Blitz einschlägt).

Es gibt auch keinen Grund viele 3TB statt wenig 6 TB Platten zu nehmen. Sequentiell ist man beidesmal jenseits von Gut und Böse und bei Z2/3 hat man keine Verbesserung der Iops. Wäre anders bei Striped -Mirror/Raid-10. Da bringt jeder Extra Mirror ca 100 iops.

Ich würde 2 vdev mit je 6disks nehmen.

- - - Updated - - -

Ich würde striped mirrors nehmen. Hier wird nur der mirror wiederhergestellt, der betroffen ist

Das trifft nur bei Hardware Raid zu.
ZFS hat ja seine Daten und damit die Prüfsummen über den ganzen Pool verteilt. Ein einfaches Kopieren müßte dann ohne Prüfsummen erfolgen. ZFS muss und soll sowas vermeiden. Es müssen also alle Metadaten gelesen werden. Die Daten die auf die defekte Platte zeigen werden dann wiederhergestellt.

Schnelleres Resilver gäbe es mit sequenteillem Resilveríng. Ist momentan aber leider nur in Oracle Solaris drin.