besterino
Legende
Merci, probiere ich die Tage mal aus!
besterino
Legende
Update: das Setzen von d3d0 für die SSDs hilft leider nicht. Hätte mich auch gewundert, da es ja mit Hyper-V problemlos läuft.
Vielleicht liegt's ja an der konkreten Kombination AMD-Plattform + Bifurcation (jeweils 4x4) + ESXi + Solaris. Hab aber wenig Lust, da jetzt tiefer einzusteigen - ich probiere ggf. noch mal weitere OS. Vielleicht finde ich ja eins mit Support sowohl für ZFS, die ConnectX als auch NVME-PCIe-Passthrough.
Vielleicht liegt's ja an der konkreten Kombination AMD-Plattform + Bifurcation (jeweils 4x4) + ESXi + Solaris. Hab aber wenig Lust, da jetzt tiefer einzusteigen - ich probiere ggf. noch mal weitere OS. Vielleicht finde ich ja eins mit Support sowohl für ZFS, die ConnectX als auch NVME-PCIe-Passthrough.
Oder die NVMe unter ESXi nutzen und per vdisk bereitstellen. Bringt Flexibilität was Partitionen angeht und kostet normalerweise kaum Performance. ZFS Trim gibts aber nicht und ESXi kann kein Trim. Das könnte etwas Performanance vor allem bei Desktop NVMe kosten.
Trambahner
Urgestein
Habt ihr da schon Erfahrung/rumprobiert mit der PM9A3, speziell wg. Passthrough-Fähigkeit ? Mich würden da zwei 7.68 U.2 als Mirror anlachen.
besterino
Legende
Also für mich ist das alles etwas ernüchternd.
Hab mal TrueNAS installiert - da läuft zumindest gerade mal die ConnectX-4 nach Setzen ein paar loader Tunables - allerdings schmeisst DMESG da immer noch lustige Fehlermeldungen. Vertrauenserweckend für einen Filer ist das irgendwie nicht. Und ob da RDMA laufen wird... naja.
Immerhin sind die NVME-Disks in TrueNAS da, da spricht wirklich doch alles für ein "Solaris-Thema" mit den NVME-SSDs:
Hab jetzt noch keinen Pool gebaut, aber bin da grds. zuversichtlich. Mich nervt aber schon kollossal, dass das mit Solaris (bei mir? noch?) nicht will.
Das Traurige ist, dass das alles mit Microsoft total easy geht. Aber wer überlässt MS schon seine Daten...?
Hab mal TrueNAS installiert - da läuft zumindest gerade mal die ConnectX-4 nach Setzen ein paar loader Tunables - allerdings schmeisst DMESG da immer noch lustige Fehlermeldungen. Vertrauenserweckend für einen Filer ist das irgendwie nicht. Und ob da RDMA laufen wird... naja.
Code:
# dmesg | grep mlx
mlx5en: Mellanox Ethernet driver 3.5.2 (September 2019)
mlx5_core0: <mlx5_core> mem 0xe7800000-0xe79fffff at device 0.0 on pci5
mlx5_core0: ERR: mlx5_init_once:939:(pid 0): Unable to find vendor specific capabilities
mlx5_core0: WARN: mlx5_fwdump_prep:76:(pid 0): Failed to find vendor-specific capability, error 2Immerhin sind die NVME-Disks in TrueNAS da, da spricht wirklich doch alles für ein "Solaris-Thema" mit den NVME-SSDs:
Das Traurige ist, dass das alles mit Microsoft total easy geht. Aber wer überlässt MS schon seine Daten...?
Zuletzt bearbeitet:
Hi
Kann man da auf OmniOS/Solarish/napp-it Anwendungen installieren? Gibt es da einen Paketmanager? Allerdings hat mein napp-it kein Internet.
z.B. nano, XServer, baobab, oder so was.
Kann man da auf OmniOS/Solarish/napp-it Anwendungen installieren? Gibt es da einen Paketmanager? Allerdings hat mein napp-it kein Internet.
z.B. nano, XServer, baobab, oder so was.
OmniOS hat von Solaris den ips Packetmanager geerbt
Die OmniOS Repositories (pkg install "Applikation"). Die gibts je für jede OmniOS stable und bloody Version
weiteres ips Repository für OmniOS und Solaris:
Deneben gibt es pksrc:, https://napp-it.org/downloads/binaries.html mit den Anwendungen (Q4 ist immer LTS):
Dazu folgender netter Blog
Auch Oracle hat ein Repository
Das ist aber nur für zahlende Kunden zugänglich (ca 1000 Euro/Jahr)
Grafische Oberfläche:
Könnte man aus pksrc installieren. Ist aber mit etwas Aufwand verbunden.
Da wäre OpenIndiana GUI mit Mate einfacher.
Ohne Internet müsste man ein lokales Repository haben
oder die pksr Files lokal herunterladen
Microsoft ist halt Mainstream und Windows das wichtigste OS für VMware. Die Performance von Windows unter ESXi ist auch im Vergleich immer führend. Vmware kümmert sich selber darum dass es geht. Bei Unix gab es in der Vergangenheit sowohl bei BSD wie bei Illumos immer wieder Treiberanpassungen um NVMe Passthrough an eine ESXi Version anzupassen oder workarounds wie die passthrough.map. Hält leider oft nur bis zum nächsten ESXi Update. Auch Oracle liefert Anpassungen (kostet und man kann es daher nicht vorab testen).
Im Einzelfall kann es hilfreich sein, eine Mail an Illumos-Discuss zu schicken. Manchmal gibt es da noch einen Tipp der Treiberentwickler oder eine Anpassung, https://illumos.topicbox.com/groups/discuss (da auch nach ESXi suchen)
Die OmniOS Repositories (pkg install "Applikation"). Die gibts je für jede OmniOS stable und bloody Version
weiteres ips Repository für OmniOS und Solaris:
Deneben gibt es pksrc:, https://napp-it.org/downloads/binaries.html mit den Anwendungen (Q4 ist immer LTS):
Dazu folgender netter Blog
Auch Oracle hat ein Repository
Das ist aber nur für zahlende Kunden zugänglich (ca 1000 Euro/Jahr)
Grafische Oberfläche:
Könnte man aus pksrc installieren. Ist aber mit etwas Aufwand verbunden.
Da wäre OpenIndiana GUI mit Mate einfacher.
Ohne Internet müsste man ein lokales Repository haben
oder die pksr Files lokal herunterladen
Beitrag automatisch zusammengeführt:
Microsoft ist halt Mainstream und Windows das wichtigste OS für VMware. Die Performance von Windows unter ESXi ist auch im Vergleich immer führend. Vmware kümmert sich selber darum dass es geht. Bei Unix gab es in der Vergangenheit sowohl bei BSD wie bei Illumos immer wieder Treiberanpassungen um NVMe Passthrough an eine ESXi Version anzupassen oder workarounds wie die passthrough.map. Hält leider oft nur bis zum nächsten ESXi Update. Auch Oracle liefert Anpassungen (kostet und man kann es daher nicht vorab testen).
Im Einzelfall kann es hilfreich sein, eine Mail an Illumos-Discuss zu schicken. Manchmal gibt es da noch einen Tipp der Treiberentwickler oder eine Anpassung, https://illumos.topicbox.com/groups/discuss (da auch nach ESXi suchen)
Zuletzt bearbeitet:
Luckysh0t
Enthusiast
D.h ich habe in Solaris keine Möglichkeit ein verschlüsseltes Dataset auch verschlüsselt zu replizieren ?
Managing ZFS File Systems in Oracle Solaris 11.4
docs.oracle.com
Example 37 Sending and Receiving an Encrypted ZFS File System
In the following example, the tank/home/megr@snap1 snapshot is created from the encrypted /tank/home/megr file system. Then, the snapshot is sent to bpool/snaps, with the encryption property enabled so the resulting received data is encrypted. However, the tank/home/megr@snap1 stream is not encrypted during the send process.
Code:
$ zfs get encryption tank/home/megr
NAME PROPERTY VALUE SOURCE
tank/home/megr encryption on local
$ zfs snapshot tank/home/megr@snap1
$ zfs get encryption bpool/snaps
NAME PROPERTY VALUE SOURCE
bpool/snaps encryption on inherited from bpool
$ zfs send tank/home/megr@snap1 | zfs receive bpool/snaps/megr
$ zfs get encryption bpool/snaps/megr
NAME PROPERTY VALUE SOURCE
bpool/snaps/megr encryption on inherited from bpoolMan kann verschlüsselte Dateisysteme replizieren (das Ziel ist mit dem Zielpool Schlüssel verschlüsselt). Im Gegensatz zu Open-ZFS raw send ist die Übertragung selbst aber nicht verschlüsselt und es wird nicht mehr der Quellschlüssel benutzt. Ist für größere Einrichtungen passender da damit nicht plötzlich Dateisysteme mit unerwartet "fremden" Schlüsseln entstehen sondern der Schlüssel des Zielpools alle enthaltene Dateisysteme aufmachen kann.
Zuletzt bearbeitet:
Absolute Sicherheit gibts nicht. Wenn das Zielsystem nicht vertrauenswürdig ist, hat man eh keine Chance, inbesondere wenn jemand dann auch noch Zugriff auf die SSH Keys hat.
In einem geswitchten Netz ist es aber schon recht aufwendig, einen Stream abzuhören. Dann muss man entweder das Netz fluten damit die Switche alle Daten an allen Ports liefern oder einen Switch kompromittieren oder bei WAN die Fernverbindung abhören können. Fällt meist auf oder ist für nicht NSA Angreifer nicht so einfach.
Ich habe eine Platte mit einem Backup-Pool. Die Platte war bisher im Hot-Swap Rahmen, soll aber nicht dauerhaft laufen, sondern nur, wenn ein Backup ansteht. Daher soll die Platte in ein externes Gehäuse wandern, das über USB-C angebunden ist. Ich habe dazu eine separate USB-Controller Karte beschafft und ein USB Festplattengehäuse. Der USB Controller ist in ESXi in die Napp-It VM durchgereicht, wird dort auch erkannt. Wenn ich die Backup-Platte ins USB-Gehäuse packe und anschließe, wird sie auch erkannt und ich kann den Backup Pool importieren. Allerdings schlägt jeder weitere Zugriff fehl und der Pool geht auf UNAVAILABLE mit I/O Error. Kann es sein, dass der USB-Adapter im USB-Gehäuse hier dazwischen funkt? Muss ich die Platte im USB Gehäuse neu initialiseren?
Ein paar Details, falls es hilft:
Danke vorab für die Unterstützung!
Ein paar Details, falls es hilft:
- RaidSonic ICY BOX USB 3.2 Karte IB-PCI1901-C32
- Inateck FE3001 Festplattengehäuse
Danke vorab für die Unterstützung!
Hallo, ich lese hier sehr oft mit und habe mal eine Frage.
Es wird behauptet das Solaris schneller ist als der Rest, OmniOS so zweit schnellster im einem ZFS Storage Szenario sein soll.
Wie groß sind denn die unterschiede 5% 10% usw. bei gleicher HW Ausstattung und wo liegen die Vorteile im vergleich Solaris<>OmniOS.
zb. HW
Dell T40
Xeon E-2224G
16 GB RAM,
2 x SSD Micron 7300 PRO 3,84 TB
Viele Grüße
Joerg
Es wird behauptet das Solaris schneller ist als der Rest, OmniOS so zweit schnellster im einem ZFS Storage Szenario sein soll.
Wie groß sind denn die unterschiede 5% 10% usw. bei gleicher HW Ausstattung und wo liegen die Vorteile im vergleich Solaris<>OmniOS.
zb. HW
Dell T40
Xeon E-2224G
16 GB RAM,
2 x SSD Micron 7300 PRO 3,84 TB
Viele Grüße
Joerg
Hotswap erfordert
- Hot Swap Rahmen oder Backplane (wegen Stromversorgung)
- hotplug fähiger Storage Controller/ Treiber.
Mit einem SAS HBA geht zweiteres out of the Box.
Mit AHCI Sata muss man das teils im Bios oder OS aktivieren (z.B. /etc/system) oder es geht manchmal garnicht. Dann erfordert das ein Reboot.
bei meinen früheren Tests war Solaris bis zu 30% schneller bei den Pools, bei SMB sogar mehr. OmniOS oder besser Illumos hat aber viel aufgeholt. Ursprünglich war Illumos und damit Open-ZFS ein Fork von OpenSolaris (eines frühen Solaris 11, ca 2010). Inzwischen ist aber auch Open-ZFS deutlich besser geworden. Auch der Solaris SMB Server in OmniOS ist besser geworden und auch in der Version 3.1.1. Ganz aktuelle Tests mit neuestem Solaris 11.4 habe ich aber nicht (dürfte die auch nicht veröffentlichen wg Solaris Lizenzbedingungen)
Vorteil von Oracle Solaris ist der garantierte Support bis mindestens 2034. Ist aber nur für Großfirman relevant. Ohne Subscription (ab 1000 Euro/Jahr) ist Solaris zwischenzeitlich nicht mehr einsetzbar da keine Updates und Fixes frei verfügbar sind. Dies liegt daran dass es kein neueres frei zugängliches Solaris 12 geben wird. Wie bei Windows 10 gibts nur rollierende Updates für Solaris 11.4. Die sind nur mit bezahltem Supportvertrag zugänglich.
OmniOS ist da viel offener. Es ist Opensource, hat aber auch ein stable/long term stable, dazu optional kommerzieller Support und teils zweimal im Monat neueste Security/Bugfixes und die sogar frei.
Die ZFS Performance unterschiede innerhalb Open-ZFS sollten relativ gering sein. Solaris hat noch den Vorteil dass die ZFS interne Speicherverwaltung an Solaris angelehnt ist. Der RAM Bedarf von Solaris und OmniOS ist daher oft geringer oder es bleibt mehr für den ZFS Cache. Die minimalistischen Versionen wie OmniOS oder OpenIndiana/Solaris text edition tun ein übriges, das OS schlank und schnell zu halten.
Zuletzt bearbeitet:
In /etc/system steht
Code:
* napp-it_tuning_begin:
* set base tuning option
enable sata hotplug
set sata:sata_auto_online=1D.h. m.E. eigeschaltet, korrekt? Die Backplane ist ebenfalls Hot-Swap fähig. Der SATA-Controller ist der Onboard Controller meines Mainboards (siehe Systembeschreibung). Der ist laut Handbuch Hot-Swap fähig. Einstellung im Bios muss ich nochmal schauen, aber ich meine, das hätte ich schon getan. Müsste aktiv sein...
Gibt's Stellen in den Logs, wo man ggf. was dazu erkennen könnte?
Hot-Swap bringt mir allerdings nichts bei meiner Zielstellung, die Backup-Platte nur laufen zu lassen, wenn auch ein Backup ansteht. Im Hot-Swap Rahmen würde die Platte ja durchlaufen (nicht erwünscht). Ich würde sie lieber als USB-Platte eventgesteuert ein- und ausschalten (schaltbare Steckdosenleiste ist da, schalten ist durch simplen HTTP-Request möglich und damit punktgenau realisierbar).
Insofern nochmal die Frage nach dem Problem, dass der Pool wegen I/O Fehler degradiert bzw. auf unavailable geht, wenn ich die Platte im USB Gehäuse betreibe. Danke!
Zuletzt bearbeitet:
Wenn in einem Raid eine Platte i/oR Fehler hat, fliegt die Platte aus dem Raid, der Pool ist degraded, Bei einem Basic vdev (einzelne Platte ohne Raid ist der Pool blockiert. Man kann nichtmal exportieren oder löschen,
Ich vermute es gibt Probleme mit dem USB Chipsatz. Was passiert wenn man einen USB Port via ESXi nutzt.
Ich vermute es gibt Probleme mit dem USB Chipsatz. Was passiert wenn man einen USB Port via ESXi nutzt.
Das habe ich mit dem neuen Controller noch nicht probiert. Vom Onboard USB Controller habe ich schon über ESXi eingebunden (also kein passthrough). Das ging zwar, war aber extrem langsam. Also wirklich langsam. Ich vermute, dass es mit dem neuen Controller auch nicht wirklich besser wäre, ESXi hat da ja offenbar so seine Probleme. Auch die Kombination USB Gehäuse und Backup-Platte mit eingerichtetem Pool hatte ich noch nicht über Nicht-Passthrough angebunden. Ich bin ab heute unterwegs, werde aber das USB Gehäuse und die Backup-Platte mitnehmen und kann an einem anderem Server, der als Offsite Backup fungiert, mal testen, ob es da auch zu I/O Fehlern in der Kombination führt.
Thermitkühlung
Profi
- Mitglied seit
- 24.09.2021
- Beiträge
- 29
Hat ZFS einen Mechanismus dafür, selten benötigte Daten auf bestimmte Platten auszulagern, wobei diese Platten dann heruntergefahren werden können? Immerhin scheint ZFS ja SSD-Caches zu ermöglichen.
Luckysh0t
Enthusiast
@Thermitkühlung
Was du möchtest ist, sind wohl eher Storage-Tiers - caching ist etwas anderes.
Und das kann zfs meines Wissens nicht.
Was du möchtest ist, sind wohl eher Storage-Tiers - caching ist etwas anderes.
Und das kann zfs meines Wissens nicht.
Thermitkühlung
Profi
- Mitglied seit
- 24.09.2021
- Beiträge
- 29
Ich weiß nicht, was Storage-Tiers sind, aber so wie sich das anhört, ist das tatsächlich, was ich will. Ich habe mir auch überlegt, ob ich mir vielleicht verschiedene Cluster-Dateisysteme ansehen sollte, um so etwas zu erreichen. Nur das ich das ganze lokal mit verschiedenen Datenträgern, statt Rechnerknoten im Netzwerk haben will.
Stößt da ZFS tatsächlich an seine Grenzen? Es ist doch sonst auch die eierlegende Wollmilchsau. Ein SSD-Cache geht meiner Meinung nach trotzdem tendenziell in diese Richtung, aber ZFS hat sicher nur Performance als Ziel, wogegen ich gerne Zugriffe auf bestimmte Platten durch großzügiges Prefetching und Balancieren von Daten vermeiden will.
Stößt da ZFS tatsächlich an seine Grenzen? Es ist doch sonst auch die eierlegende Wollmilchsau. Ein SSD-Cache geht meiner Meinung nach trotzdem tendenziell in diese Richtung, aber ZFS hat sicher nur Performance als Ziel, wogegen ich gerne Zugriffe auf bestimmte Platten durch großzügiges Prefetching und Balancieren von Daten vermeiden will.
Im Prinzip geht es immer darum dass jeder schnelles, großes und günstiges Storage will. Leider ist es so dass wenn man zwei dieser Forderungen festlegt, die dritte eine Folge ist. Meist legt man Preis und Kapazität fest und Performance ist dann suboptimal. Man kann sich dann Gedanken machen, wie man einzelne Daten wie temp Files, Datenformate wie Datenbankfiles oder Datenarten wie kleine io Packete beschleunigt.
Ein erster Ansatz ist ein SSD Schreib-Lesecache. Arbeitet der aber filebasiert ist er schnell voll. Ein Absturz beim Schreiben darf zudem keinen Datenverlust oder korrupte Dateisysteme zur Folge haben. Mit Copy on Write oder BBU/ Flashsicherung zu realisieren. Ein weiterer Ansatz ist Tiering. Dabei nutzt man ein Speichersystem das aus einem großen, billigen, langsamen (Platten) und kleinerem, schnellem und teurem SSD Teil besteht. Man kann dann ktitische oder "hot" Daten auf den schnelleren Teil legen. Ändern sich die Anforderungen aber, ist Umkopieren angesagt. Das kostet Zeit und Performance.
ZFS bietet hier eine ganze Reihe von Ansätzen, die immer noch "State of the Art" sind.
Erster Ansatz ist der, dass ein ZFS Pool sequentiell immer schnell genug ist (viel schneller als Netz). Probleme hat man üblicherweise bei kleinen Datenpaketen insbesondere < 64k. Wenn man sich einen Atto Plattentest anschaut wird das sehr anschaulich. Beim Schreiben von 8k hat man gerne ein paar KB/s, bei 512k dann hunderte MB/s. ZFS tut daher alles um das Lesen und Schreiben kleiner Blöcke zu vermeiden.
Erster ZFS Ansatz ist der rambasierte Schreib/Lesecache Arc (z.B. 4GB Schreibcache, Lesecache ca 80% vom freien RAM). Der vermeidet wirkungsvoll das Schreiben kleiner Blöcke und beschleunigt wiederholtes Lesen. Da er auf ZFS Blöcken basiert und mit Read Last + Read Most arbeitet, ist er auch nicht voll wenn man mal ein Video liest.
Erweitern kann man den RAM Lesecache durch eine SSD/NVMe L2Arc (max 5x RAM). Kann für viele Nutzer/kleine Daten sehr viel bringen zumal er persistent ist (überlebt Reboot). Bei ausreichend RAM und für wenige Nutzer oder übliche Office Filernutzung meist wirkungslos.
Benötigt man sicheres Schreiben, darf der Inhalt des rambasierten Schreibcaches nicht verloren gehen. ZFS kann daher sync write bei dem jeder bestätigte Schreibvorgang sofort auf dem Pool landet. Das sind aber meist besonders kleine sehr langsame Writes. ZFS bietet da mit Slog die Möglichkeit diese auf eine extra Platte auszulagern, die dafür besonders ausgelegt ist, z.B. Intel Optane oder WD SS530/540.
Ein weiterer Ansatz sind special vdev - eine Intel Entwicklung. Das schreibt wie Tiering besondere Datenarten auf einen schnelleren Bereich, arbeitet aber dynamischer indem es gezielt lediglich besonders zeitkritische Datenarten darauf ablegt, z.B. Metadaten, small io oder Deduptabellen.
Insgesamt erreicht man durch diese ZFS Möglichkeiten meist eine Performance die auch kritische Vorgaben abdeckt wie sicheres sync write oder Verschlüssellung mit 10G Netzen - trotz all der Performance kostenden ZFS Sicherheitsmaßnahmen wie Copy on Write (höhere Fragmentierung, kein korruptes Dateisystem nach Absturz), Prüfsummen auf Daten und Metadaten (immer verifizierte Daten, selbstheilendes Dateisystem) und Raid Arrays bei denen Daten gleichmäßig im Pool verteilt werden und nicht sequentiell auf einzelnen Platten (konstante Performance).
Ein erster Ansatz ist ein SSD Schreib-Lesecache. Arbeitet der aber filebasiert ist er schnell voll. Ein Absturz beim Schreiben darf zudem keinen Datenverlust oder korrupte Dateisysteme zur Folge haben. Mit Copy on Write oder BBU/ Flashsicherung zu realisieren. Ein weiterer Ansatz ist Tiering. Dabei nutzt man ein Speichersystem das aus einem großen, billigen, langsamen (Platten) und kleinerem, schnellem und teurem SSD Teil besteht. Man kann dann ktitische oder "hot" Daten auf den schnelleren Teil legen. Ändern sich die Anforderungen aber, ist Umkopieren angesagt. Das kostet Zeit und Performance.
ZFS bietet hier eine ganze Reihe von Ansätzen, die immer noch "State of the Art" sind.
Erster Ansatz ist der, dass ein ZFS Pool sequentiell immer schnell genug ist (viel schneller als Netz). Probleme hat man üblicherweise bei kleinen Datenpaketen insbesondere < 64k. Wenn man sich einen Atto Plattentest anschaut wird das sehr anschaulich. Beim Schreiben von 8k hat man gerne ein paar KB/s, bei 512k dann hunderte MB/s. ZFS tut daher alles um das Lesen und Schreiben kleiner Blöcke zu vermeiden.
Erster ZFS Ansatz ist der rambasierte Schreib/Lesecache Arc (z.B. 4GB Schreibcache, Lesecache ca 80% vom freien RAM). Der vermeidet wirkungsvoll das Schreiben kleiner Blöcke und beschleunigt wiederholtes Lesen. Da er auf ZFS Blöcken basiert und mit Read Last + Read Most arbeitet, ist er auch nicht voll wenn man mal ein Video liest.
Erweitern kann man den RAM Lesecache durch eine SSD/NVMe L2Arc (max 5x RAM). Kann für viele Nutzer/kleine Daten sehr viel bringen zumal er persistent ist (überlebt Reboot). Bei ausreichend RAM und für wenige Nutzer oder übliche Office Filernutzung meist wirkungslos.
Benötigt man sicheres Schreiben, darf der Inhalt des rambasierten Schreibcaches nicht verloren gehen. ZFS kann daher sync write bei dem jeder bestätigte Schreibvorgang sofort auf dem Pool landet. Das sind aber meist besonders kleine sehr langsame Writes. ZFS bietet da mit Slog die Möglichkeit diese auf eine extra Platte auszulagern, die dafür besonders ausgelegt ist, z.B. Intel Optane oder WD SS530/540.
Ein weiterer Ansatz sind special vdev - eine Intel Entwicklung. Das schreibt wie Tiering besondere Datenarten auf einen schnelleren Bereich, arbeitet aber dynamischer indem es gezielt lediglich besonders zeitkritische Datenarten darauf ablegt, z.B. Metadaten, small io oder Deduptabellen.
Insgesamt erreicht man durch diese ZFS Möglichkeiten meist eine Performance die auch kritische Vorgaben abdeckt wie sicheres sync write oder Verschlüssellung mit 10G Netzen - trotz all der Performance kostenden ZFS Sicherheitsmaßnahmen wie Copy on Write (höhere Fragmentierung, kein korruptes Dateisystem nach Absturz), Prüfsummen auf Daten und Metadaten (immer verifizierte Daten, selbstheilendes Dateisystem) und Raid Arrays bei denen Daten gleichmäßig im Pool verteilt werden und nicht sequentiell auf einzelnen Platten (konstante Performance).
Zuletzt bearbeitet:
Dann bleib besser bei UnRaid.
CommanderBond
Enthusiast
- Mitglied seit
- 16.04.2012
- Beiträge
- 703
ZFS ist nicht für alles das perfekte Dateisystem. Unraid ist vorallem auf die Speicherung von Medien ausgelegt für den Heimgebrauch. Da macht der Ansatz in meinen Augen auch viel Sinn zB dass man flexibler bei der Plattengröße ist. Und bei einem Crash im Worst Case immer noch die Daten auf den einzelnen Platten ausgelesen werden können da es kein Striping der Daten gibt.
Ceiber3
Urgestein
Da kann er auch WIndows nutzen mit Drivepool und als Datensicherheit Snapraid. So läuft es bei mir.
Wie bei UnRaid, hast du zwar nur die Perfomance von einer Platte aber man hat halt noch Prüfsummen dank Snapraid die man mit UnRaid nicht hat und auch nicht bekommen kann.
Zusätzlich kann er ähnlich wie bei UnRaid, noch auf alle Daten der anderen Platten zugreifen wenn eine ausfallen sollte. Bei UnRaid braucht er sogar bestimmte Tools, da Windows kein XFS lesen kann.
Fällt eine Platte aus, sind die Daten erstmal weg. Er kann sie aber dank Parity wiederherstellen. SSD Cache geht auch wie bei UnRaid einzurichten.
SnapRAID
A backup program for disk arrays. It stores parity information of your data and it recovers from up to six disk failures
www.snapraid.it
Zuletzt bearbeitet:
Thermitkühlung
Profi
- Mitglied seit
- 24.09.2021
- Beiträge
- 29
ZFS macht ja weit mehr als ein traditionelles Dateisystem. Es hat mich immer wieder damit überrascht, was es alles konnte. Es verletzt auch die traditionelle Abgrenzung zwischen Dateisystem und Block-Layer. Es hätte Sinn gemacht, wenn es eine Storage-Hierarchy (jenseits von SSD-Cache) unterstützt hätte. Deshalb hab ich lieber mal nachgefragt.
SnapRAID sieht sehr interessant aus. Damit beschäftige ich mich mal näher. Closed Source oder Windows kommen nicht in Frage, jedenfalls nicht in diesem Fall.
Entschuldigung, dass es doch Offtopic gegangen ist, und Danke für die Vorschläge.
SnapRAID sieht sehr interessant aus. Damit beschäftige ich mich mal näher. Closed Source oder Windows kommen nicht in Frage, jedenfalls nicht in diesem Fall.
Entschuldigung, dass es doch Offtopic gegangen ist, und Danke für die Vorschläge.
Trambahner
Urgestein
Tut es ja mit dem Special Vdev. Durch die passende Einstellung von Blockgrößen (max Recordsize und Special vdev Blocksize) werden Datenblöcke dann z.B. dynamisch auf den langsamen Pool (z.B. HDD) geschrieben, kleine Blöcke wie z.B. von VM Betriebssystem-Disks oder Datenbanken gehen dann auf das schnelle Vdev. Die Bedingungen kannst Du wie gesagt über die Blockgrößen einstellen. Und zwar dataset-fein, nicht nur für den gesamten Pool ! . Damit hast Du eine sehr feine Steuerungsmöglichkeit.
Willst Du harte Zuordnungen, mei, dann legst halt zwei Pools an; einen HDD-Pool für Dinge wie Medienfiles, Backups, OS-Images, etc. und einen SSD-Pool für VMs, ständig genutzte Files mit kleinteiligen Zugriffsmustern, etc.
Was es nicht out-of-the-box kann ist, cold-storage Blöcke selbsttätig z.B. vom SSD auf den HDD Pool zu schubsen. Es hält aber niemanden ab, per Script in einem Job Dateien von Pool A nach Pool B zu verschieben.
Theoretisch sollte sowas eigentlich funktionieren, sofern "atime=on" gesetzt ist (was ich aus performancegründen grundsätzlich deaktiviere).
Btw, merkt sich ZFS eigentlich wann ein Block das letzte mal lesend zugegriffen wurde? Ich meine "atime" wirkt ja auf Files, nicht auf Blöcke.
OmniOS LTS und stable security Updates wegen eines neuen Bugs in OpenSSH + weitere Verbesserungen und Sicherheitsupdates
https://github.com/omniosorg/omnios-build/blob/r151038/doc/ReleaseNotes.md
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41617
ps OmniOS is ultra fix mit den Sicherheitsupdates. Das OpenSSH Problem ist vom 26.9.2021
https://github.com/omniosorg/omnios-build/blob/r151038/doc/ReleaseNotes.md
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41617
ps OmniOS is ultra fix mit den Sicherheitsupdates. Das OpenSSH Problem ist vom 26.9.2021
Bzzz
Enthusiast
gea, zwei Fragen zur napp-it-Installation unter Ubuntu (vergeblich 21.04 wegen Blackscreen-Bug mit der Aspeed-Graka, evtl. installier ich nochmal neu die LTS):
a) Da du eh diverse Abhängigkeiten prüfst, wäre nfs-kernel-server nicht auch ein lohnender Kandidat? NFS-Shares gingen nicht, es kam aber auch keine Fehlermeldung. NFS ist jenseits von solarish halt extern.
b) Der Autostart von napp-it klappt nicht und das vorgeschlagene Miniskript in /etc/init.d will auch nicht so. Stell mich wahrscheinlich doof an...?
a) Da du eh diverse Abhängigkeiten prüfst, wäre nfs-kernel-server nicht auch ein lohnender Kandidat? NFS-Shares gingen nicht, es kam aber auch keine Fehlermeldung. NFS ist jenseits von solarish halt extern.
b) Der Autostart von napp-it klappt nicht und das vorgeschlagene Miniskript in /etc/init.d will auch nicht so. Stell mich wahrscheinlich doof an...?
Nun ja, die Linux Version von napp-it gibts eigentlich nur weil ich Proxmox Kunden habe, die damit ZFS Management und Netz Replikation machen wollen und die napp-it Replikations Snap Historie haben wollten (aktueller Tag 24 stündl Snaps, aktuelle Woche 7 Tagessnaps, akt. Monat.. usw). Ansonsten hat die Linux Version nur minimale Priorität. Meine eigenen Installationen und die Installationen die ich selber supporte sind ca 90% OmniOS, 9% Solaris und weniger als 1% Linux.
Das schöne an Solaris ist ja gerade dass NFS und SMB perfekt in ZFS integriert ist (Sun hatte ja NFS erfunden). Auch ist die Integration von Windows Rechten und ntfs artigen ACL im Solaris SMB Server unerreicht. Ich sehe daher keinen Grund Linux zu forcieren. Die Unterstützung mehrerer Solarish Versionen reicht schon. In letzter Konsequenz ist und bleibt napp-it aber ein Spin-Off meiner täglichen Arbeit mit ZFS Storage.
Autostart unter Linux.
In der ersten Version von napp-it habe ich noch autostart unter Ubuntu und Debian unterstützt. Beim ersten größeren Linux Update lief das aber nicht mehr bzw jeweils anders. Aktuell gibt es daher nur ein start/stop Script. Autostart muss selber implementiert werden. Das alte init läuft nicht mehr.
siehe auch meinen kürzlichen Vortrag bei der Opensolaris User Group Frankfurt zu napp-it
Das schöne an Solaris ist ja gerade dass NFS und SMB perfekt in ZFS integriert ist (Sun hatte ja NFS erfunden). Auch ist die Integration von Windows Rechten und ntfs artigen ACL im Solaris SMB Server unerreicht. Ich sehe daher keinen Grund Linux zu forcieren. Die Unterstützung mehrerer Solarish Versionen reicht schon. In letzter Konsequenz ist und bleibt napp-it aber ein Spin-Off meiner täglichen Arbeit mit ZFS Storage.
Autostart unter Linux.
In der ersten Version von napp-it habe ich noch autostart unter Ubuntu und Debian unterstützt. Beim ersten größeren Linux Update lief das aber nicht mehr bzw jeweils anders. Aktuell gibt es daher nur ein start/stop Script. Autostart muss selber implementiert werden. Das alte init läuft nicht mehr.
siehe auch meinen kürzlichen Vortrag bei der Opensolaris User Group Frankfurt zu napp-it
Zuletzt bearbeitet:
