[Sammelthread] ZFS Stammtisch

Ist eigentlich noch damit zu rechnen dass irgendwann endlich mal der Bug gefixt wird dass man auch von USB2/3 booten kann?
Bei meinem Microserver G7 war dies damals noch kein Problem, da dieser eh nur USB2 hatte. Mein nächster Server hatte dann USB2 und USB3 und obwohl es einzelne USB2 only Ports gab ließ sich das Problem nur dadurch lösen indem man USB3 im Bios gänzlich abgeschaltet hat.
Mein neuestes System bietet diese Option nun nicht mehr. Es besitzt zwar einen USB2 Port, hat aber auch einen Controller der USB3 kann.


Andere Systeme schaffen es irgendwie auch von USB zu booten

Ich fahre auch schon seit Jahren sehr gut damit Sata nur noch für Datenplatten herzunehmen, aber dieser nervige Bug der nicht gefixt wird lässt mich dann doch so langsam irgendwie in Richtung eines anderen OS schielen. M.2, U.2 und Sata Ports sind in meinen Augen Verschwendung wenn man einen "relativ einfachen" Server aufsetzen will, weil dann fehlen mir auf der Datenseite die "highperformance" Schnittstellen wieder
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Entspannte und schöne Feiertage euch allen.
Danke, möchte mich anschließen

Warum kann ich mit min. 1Gbit/s verschlüsselt schreiben, aber mit gerademal ~400-500MBit/s verschlüsselt lesen? Ich hätte angenommen, dass die Leserate bei einem Raidz2 im Optimalfall bei etwa dem fünfachen einer einzigen Platte sein kann?

Die Grundannahme ist richtig. Es gibt aber keinen rein sequentiellen Betrieb im (ZFS) Raid da die Daten hier nie sequentiell gelesen werden sondern ziemlich gleichmäßig über das Raid verteilt liegen. Bei Random Access ist es dann eher so dass man eher bei 100 MB/s pro Platte landet als bei den 250 MB/s aus dem Datenblatt. Beim Lesen mit Benchmarks tritt das besonders zutage da hier der Lesecache kaum hilft da der keine sequentiellen Daten puffert sondern nur Metadaten und random io. Iops Leistung ist dann entscheidender als rein sequentielle Leistung - gerade da haperts bei einem Z2 Pool bei dem der gesamte Pool nur ca 100 iops kann - wie eine einzelne Platte.

Beim Schreiben ist der Ram-Cache hilfreicher da hier die kleinen IO gesammelt werden und als ein großes Write auf den Pool gehen. Beim Lesen muss man dann aber wieder die kleinen Blöcke einzeln ansprechen.
Beitrag automatisch zusammengeführt:

Andere Systeme schaffen es irgendwie auch von USB zu booten

Es hat nicht nur Vorteile wie ZFS Integration und den Kernel-SMB Server statt Linux oder Windows ein Unix wie Solaris zu nutzen. Einer der Nachteile ist dass Sun/Oracle nie für den Heimbereich entwickelt haben sondern für die Top 500 Firmen. Auch die Entwicklung des freien Solaris wird von Firmen getragen die das selber professionell nutzen. Eine Folge ist, dass professionelle Server Hardware gut unterstützt wird, eher "exotische" Home-Optionen weniger. Wenn der Boot von einer USB-2 Platte (wie in dem OmniOS Beitrag genannt) auch nicht geht, dann muss man USB Boot aktuell vermeiden (Was ich eh jedem anraten würde).

Es ist ja ohnehin so, dass ein guter USB Stick nicht billiger kommt als eine erheblich zuverlässigere und schnellere Sata SSD oder M.2 Bootdevice. Angesichts der Bootenvironments (bei denen man auf einen früheren OS Stand gehen kann), des benötigten Platzes für ein OS Upgrade und der Swappartition sollte die Bootplatte ohnehin ab ca 40 GB haben, auch wenn OmniOS nur ca 15 GB wirklich nutzt. Mit viel RAM sogar erheblich mehr. Da ist eine 80GB+ Bootdevice eher angeraten damit die Swap und Dump Partition auch Platz hat.

Ich fahre auch schon seit Jahren sehr gut damit Sata nur noch für Datenplatten herzunehmen, aber dieser nervige Bug der nicht gefixt wird lässt mich dann doch so langsam irgendwie in Richtung eines anderen OS schielen. M.2, U.2 und Sata Ports sind in meinen Augen Verschwendung wenn man einen "relativ einfachen" Server aufsetzen will, weil dann fehlen mir auf der Datenseite die "highperformance" Schnittstellen wieder

Wenn man den Stand genau wissen will, könnte eine Mail an Illumos-discuss oder Illumos-dev die einzige Option sein
 
Zuletzt bearbeitet:
Es war nicht allzulange her da hast du dich aber auch noch für USB Bootsticks ausgesprochen ala "kann man zuhause schonmal so machen" in deinen How2 zB.
Selbst wenn der USB Stick ein wenig teurer wäre so muss man immer noch die gesamten Kosten sehen wie zB auch den Sata Port der Wegfällt für Speichermedien oder M.2/U.2 die man alternative ebenfalls als Storage oder zum Beschleunigen eines Pools hätte nehmen können. Von daher finde ich USB boot jetzt nicht sooo abwegig.
Dass ich jetzt nen PCIe Slot hernehmen muss für ein Bootmedien lässt mich leicht darüber schmunzeln wenn du sagst USB wäre ja gar nicht billiger. Von daher denke ich ist das keine allgemein gültige Aussage mit dem "USB ist auch nicht billiger". Obendrein gibts auch USB Sticks und SSD mit Wear Leveling etc. Auch bei solchen Sachen ist die technologische Entwicklung ja nicht stehen geblieben. Dass man das System ne Nummer größer nehmen muss nur wegen eines Software Bugs, da fällt es mir schwer den "Vorteil" zu sehen;)

Aktuell spuckt mir OmniOS sogar ständig Fehlermeldungen raus wegen dem USB EHCI Hostcontroller obwohl ich testweise mal das System auf eine SATA SSD installiert habe im Sata Port...
 
Zuletzt bearbeitet:
Ich hatte selber mal gespiegelte USB Sticks bei meinem ersten HP Microserver im Einsatz. Zuverlässigkeit und Platzprobleme beim Update waren aber nicht so, das ich das als gute Lösung sehen würde sondern als Workaround wegen der wenigen Platteneinschübe des Microservers.

ESXi und SmartOS (auch ein Solaris Fork) sind Beispiele die normalerweise auf USB Sticks als Bootdevice setzen. Beides sind aber keine Full Featured Betriebs-Systeme sondern reine Bootumgebungen für VMs. Für einen üblichen Storageserver bleibe ich bei meiner Empfehlung für ein Sata oder M.2 Bootdevice. Wenn man einen PCI-Slot frei hat kann man auch einfach und billig weitere M.2 nachrüsten.

ps
natürlich sollten möglichst viele USB Chipsets funktionieren. Ist aber nicht ganz so standardisiert wie z.B. AHCA/Sata.
Aktuelle Fixes, siehe https://www.illumos.org/search?utf8=✓&scope=&issues=1&q=usb
 
Zuletzt bearbeitet:
Wenn man einen PCI-Slot frei hat kann man auch einfach und billig weitere M.2 nachrüsten
So einfach ist das in der Praxis nicht. Wenn der Port kein Bifurcation kann dann kannst du im Worstcase nen ganzen PCIex16 Slot für eine M.2/U.2 SSD opfern. Da brauchen wir über preiswert ja nicht wirklich zu sprechen, das ist einfach totale Verschwendung. Alternativ muss ich wieder zu nicht ganz so billigen Karten greifen mit PCIe Switch drauf, sind teuer und brauchen Strom. Auch da ist nix mehr mit "billig".

Ich persönlich sehe es anders, ich hatte an meinem Microserver nie Probleme mit einem guten zuverlässigen USB Stick (dieser war intern allerdings wohl eher ne SSD, Crystaldiskinfo hat ihn als µSSD erkannt). Geh ich von USB als Bootmedium weg muss ich oftmals aber hohe Opfer bringen wie Sata Ports was mir dann direkt wieder Optionen beim Storage verbaut, oder PCIe Slots verschwenden was mir dann eventuell wieder die Möglichkeit nimmt schnellere Nics einzubauen.
Von daher kann ich deinem "ist doch eh billig" in keinster Weise nachvollziehen. Billig ist es nur wenn man den Server eh 1-2 Nummern größer gewählt hat sodass die besagten Anschlüsse eh sonst nicht benutzt werden würden.

Also soweit ich weiß stellt jetzt auch mein PCIe x16 Slot der nur x16 oder x8x8x kann vor ein Problem. Wieviele M.2s kann ich darauf jetzt betreiben? Eine oder maximal 2? Afaik würde eine auf jeden fall gehen der Rest ist wieder ausprobieren....


Das Problem gibt es in illumos schon recht lange. Von daher hab ich wenig Hoffnung dass man es mal fixt. Wie gesagt bei meinem letzten Server konnte ich USB3 komplett deaktivieren noch, etwas was bei dem neueren System jetzt nicht mehr geht. Ob der Stick USB2 oder USB3 ist spielt dabei keine Rolle. Beim Microserver G7 war eh kein Problem da dieser noch gar kein USB3 hatte.

Sind hier denn irgendwelche Leute welche OmniOS erfolgreich mit einem USB3 Controller booten können? Ansonsten müsste man wohl sagen dass von USB booten nicht nur keine Empfehlung ist sondern schlicht und ergreifend mit OmniOS und Co aktuell gar nicht möglich bei aktuellen Systemen.
 
Zuletzt bearbeitet:
Die Grundannahme ist richtig. Es gibt aber keinen rein sequentiellen Betrieb im (ZFS) Raid da die Daten hier nie sequentiell gelesen werden sondern ziemlich gleichmäßig über das Raid verteilt liegen. Bei Random Access ist es dann eher so dass man eher bei 100 MB/s pro Platte landet als bei den 250 MB/s aus dem Datenblatt. Beim Lesen mit Benchmarks tritt das besonders zutage da hier der Lesecache kaum hilft da der keine sequentiellen Daten puffert sondern nur Metadaten und random io. Iops Leistung ist dann entscheidender als rein sequentielle Leistung - gerade da haperts bei einem Z2 Pool bei dem der gesamte Pool nur ca 100 iops kann - wie eine einzelne Platte.

Beim Schreiben ist der Ram-Cache hilfreicher da hier die kleinen IO gesammelt werden und als ein großes Write auf den Pool gehen. Beim Lesen muss man dann aber wieder die kleinen Blöcke einzeln ansprechen.

Dass bei einem randomisierten Benchmark mit noch dazu kleinen Leseoperationen auf einem rein HDD-basierten System keine Wunder verbringt ist klar.

Auch dass beim Schreibzugriff die Daten erstmal in den Cache wandern und das System dann optimiert den Cacheinhalt wegschreiben kann leuchtet ebenfalls ein.

Was ich aber nicht verstehe ist, warum der Lesezugriff nicht nahe an 1Gbit/s ist, wenn ich keinen zufälligen Lesezugriff habe, sondern wenn ich eine 10GByte große Datei vom NAS über SMB auf einen Client kopiere, genau genommen auf eine flinke PCIe4.0x4 SSD die je nach Füllstand mindestens 2GByte/s linear wegschreiben kann. Das Clientsystem fordert ja eine große Datei an und das NAS weiß ja auch, wie die Blöcke zu dieser Datei auf den sieben Festplatten zu finden ist. Wieso schafft es das System nicht, diese eine Datei mit annähernd 1Gbit zu liefern? Es kann doch in diesem ziemlich idealen Szenario genauso optimiert die Festplatten auslesen und mittels Prefetch und Cache die Leserate steigern?

Ich hab übrigens nochmal ein bisschen rumprobiert. Die oben genannten 50-60MB/s die ich mit FreeFileSync erzielt habe, konnte ich durch eine einfache Kopieroperation einer 10GB-Datei auf 83MB/s (ca. 666Mbit) steigern. Es fehlen dann aber trotzdem noch gut 200-300Mbit und die Vorzüge eines 10Gbit-Netzes kann ich damit auch nicht wirklich ausnutzen.

Ich werde aber noch weitere Tests fahren um auszuschließen, dass der Flaschenhals das aktuelle 1Gbit-Netz ist oder doch die Clients ein Problem haben.
 
Also soweit ich weiß stellt jetzt auch mein PCIe x16 Slot der nur x16 oder x8x8x kann vor ein Problem. Wieviele M.2s kann ich darauf jetzt betreiben? Eine oder maximal 2? Afaik würde eine auf jeden fall gehen der Rest ist wieder ausprobieren....
Wenn das Board x8x8 Bifurcation kann, dann kann man damit 2 x M.2 NVMe mit einer passiven billigen Adapterkarte betreiben. Jede nutzt dabei 4x.

An den teuren Karten mit PLX Chip gingen 4 x NVMe.
 
Tja, so kann man sich täuschen. Der Grund warum senden/empfangen unterschiedlich schnell ist liegt wohl am Netzwerk. Muss ich noch genauer untersuchen ob es am Kabel, Switch oder dem Übergang aus der ESXi-Umgebung ins physische Netz liegt. Jedenfalls liefert und empfängt Napp-IT in der virtuellen Umgebung deutlich schneller als 83MB/s. Der Test sah so aus: Habe ne 100GByte große Datei zwischen einer Win10-VM und dem SMB-Share der Napp-IT-VM hin und her kopiert. Der Traffic ging dabei über ein vmnet (alle VMs mit vmxnet 3-NICs).


Von Win10-VM -> Napp-IT-VM (verschlüsseltes NFS Filesystem) = Im Schnitt 357MB/s oder 2,9Gbit

1609009617727.png


1609009646787.png




Von Napp-IT-VM (verschlüsseltes NFS Filesystem) -> Win10-VM = Im Schnitt 303MB/s oder 2,4Gbit

1609009659101.png


1609009891790.png


Hab dann auch gleich noch ein unverschlüsseltes Dateisystem angelegt um zu sehen, wie sich das System ohne Verschlüsselung verhält.



Von Win10-VM -> Napp-IT-VM (unverschlüsseltes NFS Filesystem) = Im Schnitt 400MB/s oder 3,2Gbit

1609010189057.png


1609010334315.png


Von Napp-IT-VM (unverschlüsseltes NFS Filesystem) -> Win10-VM = Im Schnitt 303MB/s oder 2,4Gbit

1609010720325.png


1609010660762.png



Somit bleibt erstmal festzustellen, dass sequentielle Lese/Schreiboperationen sich gar nicht mal so arg zwischen verschlüsselten / unverschlüsselten Datasets unterscheidet.



Und zum Abschluss noch die Performance der NVMe die in die Win10-VM verbunden wurde (natürlich in der VM gemessen):

1609011333508.png
 

Anhänge

  • 1609011309354.png
    1609011309354.png
    193,3 KB · Aufrufe: 70
Deutliche Unterschiede zwischen Lesen/Schreiben können am Kabel liegen. Schneller wird es auch mit Jumbo Frames. Auch der Treiber unter Windows kann entscheiden. Bei Intel Karten hatte ich schon deutliche Verbesserungen mit dem aktuellen Treiber von der Intel Homepage vs dem Standard Treiber. Auch Treiber Einstellungen wie Int Throtteling auf Windows oder tcp Puffer erhöhen unter OmniOS können die 10G Performance deutlich beeinflussen.
 
Ich teste grade etwas einen Gen10Plus. Was ich probiert habe ist aus 3 14TB CMRs Basic und RaidZ1. Jeweils immer mit LZ4 compress bei den Datasets einmal mit Verschlüsselung 256Bit CCM und einmal ohne. Lande bei Windows beim Schreiben über SMB immer bei um die 80MB/s (bei 1Gbit Netzwerk). Die Poolconfig und ob Verschlüsselung scheint nahezu keinen Einfluss zu haben. Frage mich ob eine schnellere CPU aktuell Pentium Gold 3,8Ghz DualCore hier noch etwas mehr bringen wird oder ob der Flaschenhals eher beim Pool liegt. Bin etwas verwundert weil ich dachte dass zumindest bei Basic aber irgendwie auch bei RaidZ1 eher das 1Gbit Ethernet limitieren sollte, zumal eine Platte alleine ca. 1,5x bis 2x so schnell wie Gbit ist.

wobei ich mit etwas Nachdenken nicht garantieren kann ob das an einem 16x auf 8x8x Bifurcation funktioniert. Idealerweise sollte das Mainboard da 4x4x4x4x unterstützen. Wenn es nicht geht, wird nur die erste M.2 erkannt.
Ich würde mal blind behaupten bei 8x8x brauch man eine Karte mit 4 M.2 Anschlüssen und dann würde der 1. und 3. benutzbar sein. Ist aber nur ne Vermutung.
Bei der genannten Karte wird ganz sicher nur der erste Funktionieren bei 8x8x

Habe übrigens immer noch Performanceprobleme mit dem RaidZ2 Pool aus den 4 14TB Platten. Nach dem ich das System nochmal neu aufgesetzt habe liegt die Schreibrate über SMB bei 10-20MB/s. iostat meldet 100% auslastung. Kann mir das aber beim besten Willen nicht vorstellen das dies "normal" ist. Selbst für meine "schlechte" CPU 2x3,1Ghz. Das sind grade mal 10% der Leistung von EINER Platte alleine...
 
Zuletzt bearbeitet:
Ich teste grade etwas einen Gen10Plus. Was ich probiert habe ist aus 3 14TB CMRs Basic und RaidZ1. Jeweils immer mit LZ4 compress bei den Datasets einmal mit Verschlüsselung 256Bit CCM und einmal ohne. Lande bei Windows beim Schreiben über SMB immer bei um die 80MB/s (bei 1Gbit Netzwerk). Die Poolconfig und ob Verschlüsselung scheint nahezu keinen Einfluss zu haben. Frage mich ob eine schnellere CPU aktuell Pentium Gold 3,8Ghz DualCore hier noch etwas mehr bringen wird oder ob der Flaschenhals eher beim Pool liegt. Bin etwas verwundert weil ich dachte dass zumindest bei Basic aber irgendwie auch bei RaidZ1 eher das 1Gbit Ethernet limitieren sollte, zumal eine Platte alleine ca. 1,5x bis 2x so schnell wie Gbit ist.

wenn der Pool selber sehr viel schneller ist als 100 MB/s, dann kann das Problem am Netzwerk/ Kabel, SMB oder an den Windows NIC/Treibern liegen. Mit iperf kann man den Netzwerkdurchsatz zwischen Windows und dem Server testen. OmniOS hat das als Server und Client dabei.

Da Verschlüssellung nicht langsamer ist, dürfte das Problem eher nicht die CPU sein.

Ich würde mal blind behaupten bei 8x8x brauch man eine Karte mit 4 M.2 Anschlüssen und dann würde der 1. und 3. benutzbar sein. Ist aber nur ne Vermutung.
Bei der genannten Karte wird ganz sicher nur der erste Funktionieren bei 8x8x

Ich tendiere auch zu der Ansicht da bei 8x8x Bifurcation des 16x Slots wohl nur die ersten 8x auf der 8x Adapterkarte landen und die zweiten 8x Lanes des 16x Slots quasi "in der Luft" hängen. Man könnte allenfalls schauen ob es ein Biosupdate des Mainboards gibt das 4x4x4x4x unterstützt. Für reines 8x8x sehe ich keinen richtigen Anwendungsfall.

Eine eventuell funktionierende 16x Adapter (4x M.2) wäre dann

Bei den Bioseinstellungen 8x8x könnte es aber auch sein, dass damit nicht Bifurcation eingestellt wird sondern man für 2 pci-e Slots festlegen kann ob die beiden 16x/0 arbeiten oder 8x/8x.

Habe übrigens immer noch Performanceprobleme mit dem RaidZ2 Pool aus den 4 14TB Platten. Nach dem ich das System nochmal neu aufgesetzt habe liegt die Schreibrate über SMB bei 10-20MB/s. iostat meldet 100% auslastung. Kann mir das aber beim besten Willen nicht vorstellen das dies "normal" ist. Selbst für meine "schlechte" CPU 2x3,1Ghz. Das sind grade mal 10% der Leistung von EINER Platte alleine...

Ich würde mal die 4 Platten einzeln testen z.B. mit 4x basic Pools. Der Z2 Pool kann durch eine langsame Platte ausgebremst werden.
 
Zuletzt bearbeitet:
Moin,

Hatte bisher nicht viel mit ZFS zu tun - Das haben immer die Kollegen übernommen.
Jetzt brauch ich aber selbst mal Storage.

Plan: 4x 6TB HDDs als Datengrab / Archiv. Die Platten sollen jeweils im Zweierverbund gespiegelt laufen (also zwei Zweiergruppen). Eine dieser Zweiergruppen wird dauerhaft offline sein (physisch getrennt) als Backup für den Fall eines Blitzschlags / Ransomware / Whatever und nur eingesetzt, um das Backup auf diesem Verbund zu aktualisieren.

Ich würde das gerne so halten, dass auf den Backup Platten jeweils bei Ausführung des Backups (bspw. wöchentlich) ein neuer Snapshot erstellt wird und dann die letzten 4 Snapshots behalten.
Zusätzlich würde ich gerne alles verschlüsseln und dann beim Start des Systems via Passwort / Keyfile unlocken.

Geht das alles mit ZFS so wie ich mir das gedacht habe? Dann werde ich mich nämlich mal in ZFS reinarbeiten, um mir dieses Setup aufzusetzen.
Wenn es nicht geht, dann müsste ich mich nach Alternativen umschauen...
 

hi

Hatte bisher nicht viel mit ZFS zu tun - Das haben immer die Kollegen übernommen.
Jetzt brauch ich aber selbst mal Storage.

Plan: 4x 6TB HDDs als Datengrab / Archiv. Die Platten sollen jeweils im Zweierverbund gespiegelt laufen (also zwei Zweiergruppen). Eine dieser Zweiergruppen wird dauerhaft offline sein (physisch getrennt) als Backup für den Fall eines Blitzschlags / Ransomware / Whatever und nur eingesetzt, um das Backup auf diesem Verbund zu aktualisieren.

Das wären 2 x Mirrors. Einer fest verbaut und der zweite idealerweise über eine Hotplug Backplane bzw Wechselplazzeneinschübe, zur Not extern über USB Gehäuse.

Ich würde das gerne so halten, dass auf den Backup Platten jeweils bei Ausführung des Backups (bspw. wöchentlich) ein neuer Snapshot erstellt wird und dann die letzten 4 Snapshots behalten.
Zusätzlich würde ich gerne alles verschlüsseln und dann beim Start des Systems via Passwort / Keyfile unlocken.

Mit ZFS Replikation kann man beide Pools syncron halten. Für die Snapshot-Historie müsste das Replikationsscript sorgen. Da Snaps nur den Platz geänderter Datenblöcke beanspruchen kann man gerne auch mehr Snaps halten.

Zusätzlich würde ich auch auf dem Primärstorage Snaps erstellen, z.b. stündlich/täglich aktuelle Woche, wenn Platz da auch mehr.

Geht das alles mit ZFS so wie ich mir das gedacht habe? Dann werde ich mich nämlich mal in ZFS reinarbeiten, um mir dieses Setup aufzusetzen.
Wenn es nicht geht, dann müsste ich mich nach Alternativen umschauen...

kein Problem, ZFS kann das perfekt (perfekter als alle anderen Optionen)

Für erste Überlegungen kannst du ja meine Manuals für ZFS Design Principles und erste Schritte mal anschauen.
 
Zuletzt bearbeitet:

mir ist da ein Fehler aufgefallen. Kann es sein dass oben rechts Send/Receive bzw Write/Read vertauscht ist?
Wieso ist das Wording überhaupt so wie es ist, finde Write und Read bei ner Netzwerkkarte irgendwie ein wenig unpassend.
 
Hallo zusammen,

ich hardere im Moment ein wenig, bei dem Vorhaben meine Daten vom Haupsystem auf das Backupsystem zu replizieren.
So richtig deuten kann ich die unteschiedlichen Ergebnisse meines Vorhabens noch nicht so richtig, eventuell habt ihr 'ne
Idee oder einen Denkanstoss für mich, warum das Ganze sich offenbar nicht so verhält, wie ich es eigentlich erwarten würde.


Ausgangsbasis
Code:
System A:                        Vorhaben                    System B:

Quellpool mit:                                                Zielpool mit:

- filesytem 1 (no enc.)            Replikation >>>        
- filesytem 2 (enc.)            Replikation >>>                    
- filesyste 3 (enc.)            Replikation >>>                    


Test1)
Anlage von Replikationsjob 1 auf dem Backupsystem B
Quellpool/fs1                    --->                        Zielpool/            OK


Test 2)
Anlage von Replikationsjob 2 auf dem Backupsystem B
Quellpool/fs2                    --->                        Zielpool/            OK, Verschlüsselung auf Zielpool aber nicht mehr vorhanden?


Test 3)
Anlage von Replikationsjob 3 auf dem Backupsystem B
Quellpool/fs2                    --->                        Zielpool/            Fehler, zfs send Option -p im Job mit angegeben


Fehlermeldung
receive finished        time: 2020.12.29.09.59.01 line: 597        time 4 s
cannot        create 'backup/replitest2_enc': key not found        cannot        receive: crypto key operation failure


Test 4)
Anlage von Replikationsjob 4 auf dem Backupsystem B
Quellpool/fs2                    --->                        Zielpool/fs2        Fehler, gleichnamiges verschlüsseltes fs2 vorher manuell angelegt, lässt sich offenbar
                                                                                nicht gezielt als Ziel für die Replikations verwenden?

Fehlermeldung bei Anlage des Replikationsjobs
Destination Filesystem [backup/replitest2_enc] existsIf you do not want to manually continue a replication, you must delete or rename


Test 5)
Anlage von Replikationsjob 4 auf dem Backupsystem B
Quellpool/fs2                    --->                        Zielpool/enc_fs/    OK, Verschlüsselung bleibt offenbar erhalten, zusätzliches verschachteltes filesystem
                                                                                fs2 wird dann unterhalb von Zielpool/enc_fs/ angelegt, Verschlüsselung laut Gui auf 'auto'


Wie schon oben geschrieben, geht es eigentlich darum, eine handvoll filesysteme von System A nach B zu replizieren, idealerweise 1:1. Dabei sind einige
der filesysteme verschlüsselt andere wiederum nicht. Der Gedanke war nun eigentlich für jedes filesystem einen individuellen Replikationsjob zu erstellen
und diesen zunächst einmal on demand auszuführen, da das Backupsystem nicht permanent laufen sollen.

Sowei so gut, für ein unverschlüsseltes filesystem funktioniert das Ganze auch noch soweit wie erwartet, abgesehen davon, dass properties zum Teil
nicht mit repliziert werden, Vermutlihch müsste hier mit dem Paramenter -p bei der Jobanlage via nappit für den zfs_send-Teil gearbeitet werden?
Ist aber auch erst mal nicht so dramatisch.

Interessant wird es dann bei den Versuchen mit verschlüsselten filesystemen, siehe oben. Hier gelingt es mir irgendwie nicht, einfach eine Replikation
in ein verschlüsseltes filesystem zu erzeugen. Einzig bei einer Verschachtelung in ein bereits vorhandenes, verschlüsseltes filesystem auf dem Zielsystem B
scheint das Ganze irgendwie zu funktionieren. Aber genauso eine Verschachtelung bei der dann mehrer filesysteme unterhalb eines anderen liegen wollte
ich eigentlich vermeiden.

Habt ihr eventuell Ideen warum es nicht so klappt wie gedacht, ist die Herangehensweise falsch oder müssten die Replikationsjobs anders designed werden?
Bekomme das gerade im Kopf nicht so 1:1 auseinander dividiert.
 
Ganz allgemein
Eine erstmalige Replikation legt das Dateisystem neu an. Es darf also nicht vorher manuell angelegt werden.

Um ein unverschlüsseltes Dateisystem unter OmniOS in ein verschlüsseltes zu wandeln kann man folgendes machen (oder alternativ einfach z.B. per mc kopieren):

Code:
# zfs send tank/test@snap1 | zfs recv -o encryption=on -o keyformat=passphrase -o keylocation=file:///path/to/keyfile

Ansonsten sind die beiden Normalfälle:
Quelle unverschlüsselt, Parent Ziel verschlüsselt (erbt Parent Schlüssel, Ziel muss unlocked sein)

Quelle verschlüsselt, Übertragung Raw (Parameter -w), Parent Ziel unverschlüsselt
Quelle kann locked sein, Ziel ist locked und kann mit Quellkey geöffnet werden.

ps
Ich sehe gerade es ist Solaris. Da geht raw send (-w) nicht und die receive key Optionen lauten anders.
 
Zuletzt bearbeitet:
sowas in der Art

wobei ich mit etwas Nachdenken nicht garantieren kann ob das an einem 16x auf 8x8x Bifurcation funktioniert. Idealerweise sollte das Mainboard da 4x4x4x4x unterstützen. Wenn es nicht geht, wird nur die erste M.2 erkannt.
Ich denke auf 4x4x4x4x kann man lange warten


PCI Express Configurations ‡ 1x16,2x8,1x8+2x4
die CPU scheint es nicht zu unterstützen, wieso auch immer.

Aber ich werde mal testen ob ich den 8x8x Modus mit einer 4fach Karte wenigstens für 2 M.2s benutzen kann.
Wenn man einen PCIe x16 Port splittet kann man dann eigentlich beide Geräte jeweils einzelnt in eine VM durchreichen, sprich jedes einzelne unabhängig voneinander?
 
...

Ansonsten sind die beiden Normalfälle:
Quelle unverschlüsselt, Parent Ziel verschlüsselt (erbt Parent Schlüssel, Ziel muss unlocked sein)

Quelle verschlüsselt, Übertragung Raw (Parameter -w), Parent Ziel unverschlüsselt
Quelle kann locked sein, Ziel ist locked und kann mit Quellkey geöffnet werden.

ps
Ich sehe gerade es ist Solaris. Da geht raw send (-w) nicht

Hallo gea,

danke für die Rückmeldung, also grundsätzlich ist 'ne Umwandlung von unverschlüsselt nach verschlüsselt oder umgekehrt nicht gewünscht. Eigentlich nur eine 1:1 Übernahme des status quo vom Hauptsystem. Bin jetzt etwas irritiert, dass du schreibst, die beiden Normalfälle wären die oben genannten, weil dies ja immer eine Umwandlung implzieren würde?

Wie du schon schreibst, raw send (-w) scheidet aus, da Solaris. Ich versuche mal ob in den erstellen Replikationsjob so anpassen kann, dass er das gewünschte tut. Wenn doch die Verschlüsselung eigentlich nur eine zfs filesystem property ist, ist dann zu kurz gedacht, dass er diese bei 'nem zfs send -p einfach mitübernimmt?


Die Versuche, dass testweise mit an den Job zu übergeben scheinen nicht von Erfolg gekrönt zu sein.

1609247163622.png


Das Ergebnis bleibt aber letztlich ein nicht verschlüsseltes zfs filesystem im Ziel.
1609247409210.png


Das log zeigt zwar keine Fehler, aber die -o Parameter scheinen beim zfs receiver nicht mit übernommen worden zu sein?
1609247513058.png


Editiert man den Job, sieht es nachher irgendwie unvollständig aus, im Vergleich zun den obigen Angaben beim Anlegen des Replikations-Job?
1609247632359.png
 
Zuletzt bearbeitet:
So wie ich das sehe, schickt Solaris die Daten immer unverschlüsselt. Für ein verschlüsseltes Backup mus daher das Zielparent verschlüsselt sein. Senden der verschlüsselten Daten (raw) ist ein neues Feature in Open-ZFS.
Beitrag automatisch zusammengeführt:



Ich denke auf 4x4x4x4x kann man lange warten
schade, wird bei meinem X11 SPH angeboten

Wenn man einen PCIe x16 Port splittet kann man dann eigentlich beide Geräte jeweils einzelnt in eine VM durchreichen, sprich jedes einzelne unabhängig voneinander?

Bifurcation sollte nicht das Problem sein. NVMe Pass-through ist aber generell kritisch, teils geht es nur mit einer NVMe. Muss man testen.
 
Zuletzt bearbeitet:
So wie ich das sehe, schickt Solaris die Daten immer unverschlüsselt. Für ein verschlüsseltes Backup mus daher das Zielparent verschlüsselt sein. Senden der verschlüsselten Daten (raw) ist ein neues Feature in Open-ZFS.
Beitrag automatisch zusammengeführt:

Das würde dann zu meiner Beobachtung unter Test 5) passen, dass man quasi nur das gewünschte erreicht, wenn es bereits ein verschlüsseltes zfs filesystem auf der Zielmaschine gibt, unter welchem der Replikationsjob dann quasi verschachltet sein Replikations-filesystem anlegen kann. Dieses "erbt" dann quasi vom Parent die Verschlüsselung, was vermutlich auch die Bedeutung des Wertes "auto" bezüglich Verschlüsselung in der GUI erklären würde?

Hätte solch ein verschachteltest Konstrukt denn irgendwelche Nachteile, wenn auf diesen letztlich eh nicht gearbeitet werden soll, sondern diese rein als Backup fungieren soll?
Dann würde ein ja ein verschlüsseltes filesystem zum Aufnehmen von verschlüsselten Replikationen auf der Zielmaschiene ausreichen, bei unverschlüsselten besteht ja kein Problem,
da diese eh problemlos direkt unterm dem Backup Pool angelegt werden.
 
Ich denke auf 4x4x4x4x kann man lange warten



die CPU scheint es nicht zu unterstützen, wieso auch immer.

Aber ich werde mal testen ob ich den 8x8x Modus mit einer 4fach Karte wenigstens für 2 M.2s benutzen kann.
Wenn man einen PCIe x16 Port splittet kann man dann eigentlich beide Geräte jeweils einzelnt in eine VM durchreichen, sprich jedes einzelne unabhängig voneinander?

Bin gespannt, hab seit kurzem auch die CPU und suche noch nach Karten. Mit den PLX oder Marvell 88NR2241 PCI Switches sollte alles möglich sein, die sind aber noch rel. teuer.
 
Hätte solch ein verschachteltest Konstrukt denn irgendwelche Nachteile, wenn auf diesen letztlich eh nicht gearbeitet werden soll, sondern diese rein als Backup fungieren soll?
Dann würde ein ja ein verschlüsseltes filesystem zum Aufnehmen von verschlüsselten Replikationen auf der Zielmaschiene ausreichen, bei unverschlüsselten besteht ja kein Problem, da diese eh problemlos direkt unterm dem Backup Pool angelegt werden.

Verschachtelte verschlüsselte Dateisysteme sind an sich kein Problem. Aus Sicht von ZFS ist das auch nichts anderes als Dateisysteme direkt unter dem Pool (Ist ja nur ein Mountpoint und der Pool selber ist ja auch ein ZFS Dateisystem). Man sollte die halt immer gemeinsam über das Parent-Dateisystemen auf/zumachen. Wenn man SMB Shares freigeben will, dann unter Solaris nur die Dateisysteme und nicht den Parent freigeben.
 
Das klingt ja erstmal gut. So lässt sich das ja in Verbindung mit dem Keyserver noch ganz geschickt mit dem Hauptsystem nutzen.

Mir ist gerade noch aufgefallen, dass offenbar das aktivieren des "SMB share destination as" für das Replikationsziel offenbar nicht funktioniert?
Das erstellte fs wird trotzdem nicht via smb geshared oder muss noch mehr berücksichtigt werden?
 
Da fällt mir grad noch ne Frage zu ZFS ein. Was passiert eigentlich wenn man einen Snapshot/Dataset auf einen anderen Pool sendet und während der Übertragung versucht beispielsweise ein Scrip den Snapshot zu löschen. Endet das dann in Chaos? Oder wir der Snapshot dann gelockt oder wie läuft das genau?
Also mal angenommen ich sende einen Snap den ich in Nappit über einen Job erstellt habe und während ich den Sende erstellt der Job nen neuen Snap und will den alten löschen sei es weil Size=0 oder andere Bedingungen erfüllt sind zum löschen.

Oder muss man sich da keine Gedanken machen um sowas?

schade, wird bei meinem X11 SPH angeboten

Ist wohl CPU abhängig bzw auch davon ob die Lanes von der CPU kommen oder vom Chipsatz.
Versteh nur nicht die Einschränkung weil 4x4x4x4x sicherlich sinnvoller ist als 8x4x4x

Mit den PLX oder Marvell 88NR2241 PCI Switches sollte alles möglich sein, die sind aber noch rel. teuer.

Und der höhere Stromverbrauch kommt auch hinzu. Ich frage mich auch wie das technisch funktioniert mit so einem Switch. habe mal irgendwo gelesen jedes Gerät bekommt dann nen bestimmten Zeitschlitz den es für die Übertragung nutzen darf.

Mal abwarten hab nur einen x16 Slot, vielleicht kommen irgendwann auch noch mehr "Kombikarten" mit 10Gbit und M.2 Slots auf dem selben PCB. Werde wohl erstmal die 4x4x4x4x Karte aus China bestellen für 30eus. Theoretisch sollten damit dann wie gesagt zumindest sich 2 M.2s betreiben lassen an 8x8x.

Wer Esxi nutzt hat neuerdings auch die Möglichkeit USB Ethernetkarten anzuschließen. Für 2,5 und 5Gbe ist das interesant. Wäre vielleicht auch eine Alternative für diejenigen die keinen Slot mehr frei haben. Müsste man mal austesten ob das läuft zusammen mit ner OmniOS VM.
 
Zuletzt bearbeitet:
Das klingt ja erstmal gut. So lässt sich das ja in Verbindung mit dem Keyserver noch ganz geschickt mit dem Hauptsystem nutzen.

Mir ist gerade noch aufgefallen, dass offenbar das aktivieren des "SMB share destination as" für das Replikationsziel offenbar nicht funktioniert?
Das erstellte fs wird trotzdem nicht via smb geshared oder muss noch mehr berücksichtigt werden?

Diese Funktion ist nicht an Solaris 11.4 angepasst und läuft nur in Illumos/älterem Solaris.
Beitrag automatisch zusammengeführt:

Da fällt mir grad noch ne Frage zu ZFS ein. Was passiert eigentlich wenn man einen Snapshot/Dataset auf einen anderen Pool sendet und während der Übertragung versucht beispielsweise ein Scrip den Snapshot zu löschen. Endet das dann in Chaos? Oder wir der Snapshot dann gelockt oder wie läuft das genau?
Also mal angenommen ich sende einen Snap den ich in Nappit über einen Job erstellt habe und während ich den Sende erstellt der Job nen neuen Snap und will den alten löschen sei es weil Size=0 oder andere Bedingungen erfüllt sind zum löschen.

Oder muss man sich da keine Gedanken machen um sowas?

Einen Replikationssnap kann man nicht mehrfach starten. Die Snaps werden zwar nicht per hold geblockt, werden aufgrund der Namensgebung aber von normalen Snaps unterschieden so dass autosnap die nicht löscht. Size=0 kann nur Probleme bereiten da nach einer Replikation der neueste Snap immer size=0 hat. Legt man per autosnap weitere Snaps an die size=0 haben (keine geänderten Daten) und löscht die, kann sich der letzte Replikationssnap verändern. Da er dann nicht mehr identisch zum letzten Quellsnap ist kann die Replikation erst dann weiterlaufen wenn man diesen Snap löscht und die Replikation auf Basis der vorherigen Nummer neu startet.

Man muss sich da aber keine Gedanken machen.

Wer Esxi nutzt hat neuerdings auch die Möglichkeit USB Ethernetkarten anzuschließen. Für 2,5 und 5Gbe ist das interesant. Wäre vielleicht auch eine Alternative für diejenigen die keinen Slot mehr frei haben. Müsste man mal austesten ob das läuft zusammen mit ner OmniOS VM.

Da wird es wohl Treiberprobleme geben.
 
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