Welches NAS/Storage-OS

Und ich werfe mal Open-E ins gemetzel...
Basiert auf ZoL und ist hinkt immer noch deutlich hinter nativen ZFS hinterher.

Interessant ist es natürlich, daß es sich hier um einen Kommerziellen Anbieter handelt, was die Schlussfolgerung zuläßt, daß hier evtl. die Weiterentwicklung forciert wird. In wie weit das allerdings der Community zu Gute kommt ist zuminest fraglich.
- z.B. fehlt immer noch SSD-TRIM
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Powerloss protection hat die SSd natürlich nciht, ABER das System ist ja ein Homeserver und kein Produktivsystem @ Work Würde die Virtuelle Disk auf der SSD was bringen, oder ist das von vorne herein vergebene Liebesmüh?

Gruß Rocker

Wenn man sync = disabled setzt ist alles maximal schnell aber ziemlich unsicher da bei einem Crash/ Stromausfall mehrere Sekunden der letzten Schreibaktionen verloren sind, eventuell ist das Dateisysten korrupt.

Wenn man bei NFS sync = default/always setzt ist alles maximal langsam (ohne highend Slog). Bei einem Crash/ Stromausfall sind ohne Powerloss Protection eventuell die letzten Schreibvorgänge verloren, insgesamt ist es aber deutlich sicherer. Ein korruptes Dateisystem ist aber möglich.

Kann man sich jetzt raussuchen.
Oder eben eine kleine Intel S3700 oder Samsung SM863 als Slog nehmen.
Alternativ ausreichen Snapshots/ Backups machen. Blöd halt dass man nicht sofort erkennt wenn eine VM eine Macke hat.
 
Kann würde es hier helfen ein RaidZ1 aus 3 SSD´s zu generieren, hier sollte doch kein direkter Sync Vorhandensein, oder denke ich da falsch.
Bzw. ist ja eine Platte dann Parity und sollte doch Fehler ausgleichen können.

mein Frage Quasi, ist der RaidZ1 aus 3 SSD grundlegend deutlich performanter als der Mirror da dieser syncen muss?

Gruß Rocker
 
Sync Write bedeutet daß der Schreibvorgang erst als erfolgt an das OS gemeldet wird, wenn die Daten tatsächlich auf dem Datenträger geschrieben sind, damit sind sämtliche Cachemechanismen effektiv deaktiviert (auch kein Write Through).
Ein "normaler" Async-Write wird committed, wenn die Daten an das Speichersubsystem übergeben sind.

Das hat nichts mit Einzel HDD oder Raid zu tun
 
Ich wollte mich mal einhängen und Leute mit praktischer Erfahrung bzw. Übersicht über die aktuell möglichen Lösungen um Rat fragen:

Was ich gerne hätte:

- Ein großes, logisches Volume, das einzelne NFS- und SMB-Freigaben bereitstellt.
- Dieses große Volume soll aus 2 Teilen zusammengesetzt werden, einmal 4 HDDs (äquivalent zu RAID6 konfiguriert), dazu 2 SSDs (mit Power Loss Protection), die für sich selbst wie RAID1 betrieben werden sollen. Nutzbar ist also die Kapazität von 2 HDDs + 1 SSD.
- Häufig angefragte Daten sollen - sofern der Platz ausreichend ist - auf dem SSD-Teil landen (ähnlich wie das "Fusion Drive" unter macOS, wenn es jemand kennt).
- Ein Anteil des SSD-Speicherplatzes soll für SLOG/Cache verwendet werden (?)
- Möglichkeit von Snapshots und vollständige Datenträger-Verschlüsselung ist gewünscht

Ist das möglich? Als Host wäre bereits ein Kaby Lake Xeon (4C/8T) mit 32 GiB ECC vorhanden. HDDs WD Red 6 TB, SSDs werden noch besorgt, entweder Intel oder Samsung.
Lässt sich das sachgerecht mit der Anzahl an Laufwerken umsetzen?
Vielen Dank für jegliche Tipps!
 
Zuletzt bearbeitet:
Wenn Du Tiering zwischen den HDDs und den SSDs haben willst, fällt ZFS schonmal aus.
Btw, 4 HDD mit Raid6/Raidz2? Das wird auch sequentiell eher unperfomant, wenn 50% der Kapa für Parität draufgehen.

Im Falle von ZFS willst Du keine normalen SSDs als SLOG (z.B. für NFS-Protokoll); selbst 850er Pro haben da einfach zu hohe Latenzen und wirklich wirksam zu sein. Ein vdev für einen Readcache (L2ARC) muss sequentiell deutlich schneller sein als der Pool, sonst limitiert man sich dadurch. Bedenke: ein L2ARC-Readcache braucht selber Ram zur Verwaltung und ist daher erst wirklich sinnvoll, wenn mit Ramausbau nix mehr geht.

Für Snapshots ist ZFS natürlich perfekt.
 
Zuletzt bearbeitet:
Ich wollte mich mal einhängen und Leute mit praktischer Erfahrung bzw. Übersicht über die aktuell möglichen Lösungen um Rat fragen:

Was soll denn damit passieren?
Sonst ist es wie: Ich brauch einen fahrbaren Untersatz - Empfehlungen gehen dann von Bobbycar über Porsche bis 40t LKW.
 
Ist die Fragestellung nicht konkret genug?

Es soll ein möglichst stromsparendes 24/7-System für 2-3 1 GbE-Klienten sein. Dabei haben die Datenverfügbarkeit und -integrität höhere Priorität als die Leistung, daher auch bewusst das RAID 6-Äquivalent. Die 4 Festplatten im RAID 6 kenne ich bereits von einem LSI 9361 als Hardware-RAID (etwas unter RAID 0 mit 2 HDDs), es erfüllt die Anforderungen, aber bei manchen Geschichten wäre eben ein automatisches Tierung (und Cachen) mit begrenztem SSD-Speicher ganz nett im neuen System, das aber nur über PCH-SATA laufen soll.

Da die Hardware ja bereits vorhanden ist (bis auf SSDs), wolte ich eben nachfragen, welches NAS-OS/Dateisystem & Co. vielleicht alle Punkte erfüllen könnte, da dies mein erstes Eigenbau-NAS wird.
 
Zuletzt bearbeitet:
Ich hätte eher gedacht an

- nichtkommerziell/ kommerziell
- eher Lese oder Schreiblast
- eher kleine oder große Dateien z.B. Datenbank/ Webserver vs Bild/Videobearbeitung
- Vorkenntnisse

Ansonsten
Wenn Datenverfügbarkeit/ Integrität erste Priorität ist, dann ein neues Dateisystem wir btrfs, ReFS oder ZFS wählen. Das ausgereifteste, flexibelste und schnellste ist ZFS.

Echtes Tieren meint Kopieren aktueller Daten auf schnelle Storage Bereiche. ZFS macht das nicht sondern hat massiven Cache-Einsatz als Ansatz, also z.B. 4GB RAM-Schreibcache + freien Restram als Lesecache. Dazu optional eine SSD als erweiterten Lesecache oder Write Ahead Cache.

Raid-6 mit 4 Platten ist eher ungewöhnlich. Es dürfen zwar dabei zwei beliebige Platten ausfallen, ein Raid 10 aud 4 Platten hat aber die doppelte Schreib-iops und die vierfache Lese-iops Leistung.

Echte Verschlüssellung gibt es für ZFS nur bei Oracle Solaris (als ZFS Eigenschaft, kann man je Dateisystem einschalten und mit unterschiedlichen keys verwalten). Das ist auch das schnellste ZFS System. Für kommerziellen Einsatz kostet es aber und ist auch nicht kompatibel zu Open-ZFS.

Alle anderen aus dem Open-ZFS Lager (BSD, Illumos=freies Solaris, Linux) verschlüsseln Devices/ Platten unterhalb von ZFS. Mein OS der Wahl sind die freien Solaris Varianten. Die Verschlüssellung arbeitet da aber auf Files. Sehr gut für Backup geeignet aber nicht so schnell wie Platten Verschlüssellung unter BSD oder Linux.

Windows + ReFS wäre eine Alternative, aber recht komplex und langsam (und kostet auch, Verschlüssellung unter ReFS wird auch ein Problem sein).
Linux + btrfs ist was Raid 5/6 angeht buggy/ nicht fertid
 
Danke für Deine ausführliche Antwort - etwas der Wunschliste muss also gestrichen werden, wenn ich das richtig sehe.

- Es ist ein nichtkommerzielle Heimlösung, es wird aber wie gesagt großer Wert auf Datenverfügbarkeit und -integrität gelegt (Backup ist separat), da viele Dateien einen hohen sentimentalen Wert haben, daher auch der Wunsch nach einem lahmen RAID 6-Äquivalent, damit eben erst beim Ausfall einer dritten Platte es tatsächlich zu einem Datenverlust kommt.
- Kleinste Dateien, die verschoben werden sollen, sind etwa 10 MB, die größten um die 100 GB.
- Keine Datenbanknutzung, eventuell gewünscht, dass VM-Images ebenfalls auf dem Volume liegen, hier wäre es schön gewesen, wenn diese eben in einen SSD-Teil "verschoben" werden würden.
- Bin selber nur einfacher Benutzer von macOS und Windows und habe wie gesagt nur Erfahrungen mit Hardware-RAIDs und das wäre mein erstes NAS-System - habe aber keine Probleme damit, mich an Guides entlangzuhangeln, um die vorhandene Hardware möglichst effektiv zu nutzen.

Hier mal ein Leistungsbeispiel von 4 x WD Red 6 TB als RAID 6 (leer, mit 1 GB-Controller-Cache):

red6tb-lsir6.PNG

Dies geht schon in Ordnung, mit SSDs wollte ich eben v. a. gleichzeitige Schreibvorgänge etwas abfangen, da die gefühlte Leistung der recht langsamen Reds dadurch schnell in die Knie geht, dachte da an etwa 2 x 1 TB.
Perfekt wäre es gewesen, wenn man die 1 TB (2 SSDs als RAID 1-Pendant) zu den 12 TB der HDDs aufaddieren könnte und Daten automatisch entsprechend verteilt werden - wenn dies jedoch nicht (einfach) möglich ist, wäre es auch OK, wenn der SSD-Platz "nur" als unsichtbarer Cache genutzt werden würde, es also bei 12 TB ingesamt nutzbaren Platz bleibt. Wäre das relativ einfach umsetzbar?
 
Zuletzt bearbeitet:
@Gea
Write Ahead funktioniert wie genau?
Das Dateisystem erahnt, welche Daten demnächst geschrieben werden könnten?
Ich denke du meinest Read Ahead (vorausschauendes Lesen) - damit wird dann nicht Sektorweise gelesen, sondern gleich alle Sektoren einer (oder mehr) Spur(en) - unabhängig davon, ob diese alle zur betreffenden Datei.gehören
*scnr*:)

@Topic
denn machste halt einen SSD Pool für die VMs und einen HDD-Pool für die Daten - Auf zwei 500er SSDs als Mirror (Raid 1) bekommst du "locker" 4-10 VMs rauf....
Der Unterschied von Raidz2/Raid6 zu striped Mirror /Raid 10 liegt tatsächlich in dem kleinen Wort "beliebig" und natürlich der Performance.
 
Zuletzt bearbeitet:
Write-ahead müsste tatsächlich erst noch erfunden werden - ist natürlich read ahead...

Ansonsten stimme ich dir voll zu. Das Mittel der Wahl ist ein High-Performance Pool aus einem SSD Mirror für VMs und ein normaler Pool aus Platten als Filer und fürs Backup. Diese ganzem Mixed Konstrukte aus kleiner SSD und Platte (Apple, Seagate, Intel Cache) kommen in keinster Weise an einen echten SSD Pool heran.

Die typischen Lösungen für den Pool wenn man es ganz sicher haben möchte
- 3 way Mirror (halt 3 größere Platten nehmen)
- Raid Z2 aus 6 Platten (bessere Ausbeute)
 
Schon klar, dass eine reine SSD-Lösung performanter wäre - mal eben 12 TB in SSDs ist jedoch budgetmäßig nicht drin und die mechanischen Festplatten sind wie gesagt bereits vorhanden.
Dazu sollten 1 TB-SSD-RAID 1 als Cache, besonders wenn die Lese-Leistung wie bei einem ordentlichen RAID 1-Controller das doppelte der einfachen Laufwerkswerte wäre, die mechanischen Festplatten deutlich entlasten - zumindest dachte ich mir das als Laie mit Erfahrungswerten mit einem Fusion Drive (128 GB SSD + 1 TB HDD) in der Hoffnung, dass man dies auch in einem eigentständigen NAS mit zusätzlicher Ausfallsicherheit einzelner Laufwerke umsetzen könnte.
 
Zuletzt bearbeitet:
Hybridlaufwerke wie Seagate wie auch die Apple Lösung sehe ich eher als Marketingag. Es ist ein bischen schneller wie eine Festplatte aber viel langsamer als echte SSDs. Dazu kommt dass echtes Tiering (nicht nur Lesecache) immer ein Umkopieren von Daten bedeutet. Das kostet auch Performance und man hat das Problem dass Daten verloren gehen oder das Dateisystem korrupt sein kann wenn das System beim Tieren crasht.

Nur High-End Storagesysteme fangen das ab, entweder über Batterie und Cache oder über spezielle Logdevices.

Wenn es um schnelles Schreiben und schnelles Lesen geht, ist der ZFS Ansatz nahezu immer schneller indem der RAM als Schreibcache und zusätzlich mit einer optionalen SSD als Lesecache genutzt wird. Ein gutes ZFS System bedient fast alles aus dem RAM und das ist 100x schneller als eine SSD.

Tiering lohnt aktuell nur wenn man tatsächlich mehrere Hundert GB in schnellerem SSD haben möchte während der Rest auf lahmen Disks liegt da der entsprechende RAM noch teuer ist. Da aber aktuelle Servermainboards bis 1TB RAM gehen ist Tiering selbst bei High-End Systemen eher Schnee von Gestern zumal ja auch SSD immer größer und schneller werden.

Für @home ohne Highend Tiering Systeme ist ZFS schneller und vor allem viel sicherer sofern man ausreichend RAM hat.
 
Schon klar, dass eine reine SSD-Lösung performanter wäre - mal eben 12 TB in SSDs ist jedoch budgetmäßig nicht drin...
wer hat denn was davon gesagt, daß du den Kompletten Speicherplatz als SSD Pool einrichten sollst?
SSD Pool für die VMs : 2x500 GB als Mirror reichen dafür i.d.R. aus - oder hast du mehr als 10 VMs am Start? ('ne klien Linux oder BSD VM braucht nornmalerweise selten mehr als 32 GB eher deutlich weniger, und selbst eine Windows-VM kommt meist gut mit 60-80GB aus)

HDD Pool für die Nutz-Daten
 
Sorry, bei der Antwort mit alles als SSD hatte ich den roten Faden verloren, da ich gerade x Suchergebnisse geöffnet hatte und es bei ähnlichen Fragestellungen mehrfach hieß man solle doch voll auf SSD-Technik setzen.

Dass "Fusion Drive" nur ein Marketing-Gedöns ist, kann ich nicht bestätigen, da ich den Unterschied am gleichen System kennengelernt habe - bei dem Beispiel 128 GB + 1TB ist das gesamte OS und Programme im SSD-Bereich (sogar eine kleine Windows VM unter VMware Fusion passte noch rein) und da ist (fast) kein Unterschied zu regulären SATA-SSD-Systemen zu spüren, sofern man (wenn ich mich richtig erinnere) nicht mehr als 8 GB in einem Rutsch ändert. Dass der RAM hier viel zur Seite steht, kann ich ausschließen, da es ein popeliger Office-iMac mit 8 GB insgesamt ist und alleine 4 GB von der VM verwendet werden. Besonders heftig ist der Unterschied, wenn man bespielsweise eine Vanilla-Windows-VM (7/8.1) startet und die großen WinFuture-Windows-Update-Pakete durchlaufen lässt, das ist sonst mit 4 GB RAM und 'ner mechanischen 5400 RPM-Platte, die zwei OSe parallel ausführt, weniger angenehm.

Meiner Meinung nach kommt es auf das Verhältnis von SSD zu HDD an - und natürlich eine gewisse Mindestmenge, dass die Optane-Geschichte in der Ausführung <100 GB (32 GB?) gegenwärtig für'n Popo ist, finde ich ebenfalls, wobei ich es nur von Reviews her kenne und keine persönlichen Erfahrungswerte anders als wie geschildert beim Fusion Drive habe. Daher dachte ich eben auch wohlwollend an etwa 1 TB-SSD-Anteil für die 12 TB HDD-Platz. Was beim Fusion Drive etwas mulmig ist, ist, dass es ja aufaddierte Ausfallwahrscheinlichkeiten von zwei physischen Datenträgern hat.

Aber gut, die Hoffnung habe ich jetzt erst einmal beerdigt und sehe die SSDs als reine Cache-Lösung ohne Erweiterung des Speicherplatzes an.
 
Zuletzt bearbeitet:
Es ist ja nicht so dass es nichts bringt. Es ist aber schon so, dass es dann am meisten bringt wenn man es am wenigsten braucht bzw. wenn es mit einem reinen mittelgroßen 256 GB SSD Laufwerk deutlich bessere Ergebnisse hätte. Das ist dann der Fall, wenn die aktuellen Daten relativ statisch sind deutlich kleiner sind als die SSD Größe. Also OSX + Internet + ein bisschen Office. Bild oder Videobearbeitung sollte man tunlichst lassen.

Das Fusion Drive war in den Einstiegs Macs bisher eine 24GB SSD, aktuell hat es eine 32 GB SSD. Lediglich das Top Modell hat 128G SSD, Darin liegt immer OSX und ziemlich sicher die Auslagerungsdatei (so groß wie der RAM zum Schlafengehen). Da bleibt nicht viel übrig. Sobald man mit mehr unterschiedlichen Daten arbeitet, fängt das System an zu tieren. Die mechanische Platte liefert bei großen Dateien ca 200 MB/s und bei vielen kleinen lediglich vielleicht 60MB/s. Das Tieren einer 8GB Datei dauert ca 40s. Das geht massiv auf die Gesamtperformance da in der Zeit sowohl die SSD wie die Platte langsamer wird. Stürzt das System in der Zeit ab ist mangels CopyOnWrite und Powerloss Protection sogar die Datenintegrität gefährdet (zumindest bei HFS+, APFS ist da etwas unkritischer wenn auch noch nicht auf ZFS Niveau).

Fazit:
Eine günstige 256+ GB SSD ist in nahezu allen Fällen die bessere weil schnellere und sichere Lösung. Wenn man wirklich 1-3 TB oder mehr braucht, ist ein ordentliches ZFS NAS mit Snapshots die bessere Alternative. Früher konnte man bei Apple wenigstens noch eine SSD und eine Platte in die iMacs einbauen. Dass SSD bei Apple so extrem teuer sind und es größere SSD nur in teureren Modellen gibt ist eine anderes Thema, macht aber Fusion nicht gut sondern allenfalls manchmal etwas besser manchmal schlechter als mit einer reinen Platte. Für ein NAS bei dem mehrere Personen arbeiten und die aktuellen Daten sich häufiger ändern ist Tiering nur was für die "ganz dicken Storage-Eisen wie Hitachi". Aber in deren Preisregion wird SSD only auch immer attraktiver.
 
Zuletzt bearbeitet:
Beim kleinen iMac Late 2013 war beim Fusion Drive der SSD-Teil noch 128 GB: Storage Fusion Drive - 21.5-inch iMac (Late 2013) Review: Iris Pro Driving an Accurate Display

Erst später wurde der SSD-Teil zusammengestrichen, ich vermute, es hat zu gut funktioniert, also zu viele Käufer haben sich dafür entschieden (was im einfachen Office-Aufgaben ja auch völlig ausreichend ist), anstatt die perversen Margen auf Apples Flash-Speicher zu bezahlen - so wurde es soweit kastriert, bis es nicht mehr ordentlich funktioniert und die Käufer wieder vemehrt reine SSD-Lösungen ordern.

Der Grund weshalb ich mich darauf eingeschossen hatte, ist auch, dass ich es gut finde, dass kein Speicherplatz eines Typs "verschwendet" wird. Bei getrennten Pools mit SSD und regulären Platten ist das ja zwangsläufig der Fall: Nicht jede Datei eines VM-Images muss (unbedingt) auf SSD-Speicher liegen und umgekehrt ist es nett, wenn häufig nachgefragte, aber für den RAM zu große Dateien im SSD-Bereich liegen würden.

Hat eigentluch der L2ARC-Bereich eine technisch bedingte Größenbeschränkung à la x mal verfügbarer RAM?
Mit ZFS Hybrid Storage Pools Potentiale von HDD, SSD und DRAM nutzen | storageconsortium.de
 
Zuletzt bearbeitet:
Hat eigentluch der L2ARC-Bereich eine technisch bedingte Größenbeschränkung à la x mal verfügbarer RAM?
Mit ZFS Hybrid Storage Pools Potentiale von HDD, SSD und DRAM nutzen | storageconsortium.de

Zum Organisieren des L2ARC werden ca 5% dessen Größe im RAM benötigt. Ein sehr großes L2ARC kostet also einfach irgendwann zu viel RAM der ja als Cache viel schneller ist und das ganze dann ineffektiv macht. Als Faustregel würde ich sagen man meist erst versuchen sollte maximal viel RAM bereitzustellen. Dann kann man per Arcstat ermitteln, wie hoch die Trefferquote aus dem Cache ist. Steht da 80%+ macht ein L2ARC kaum Sinn, es sei denn man möchte den zusätzlichen Read Ahead des L2ARC nutzen.

Ein L2ARC sollte ca 5x bis aller, allerhöchstens 10x so groß wie der RAM sein. Bei 32 GB RAM und 320GB L2ARC gingen dann aber bereits 16GB des wervollen und schneller RAM fürs Verwalten des L2RC drauf. Kaum ein Anwendungsfall würde davon profitieren.
 
Bin gerade noch auf eine Idee gekommen, um ZFS und Tiering zu kombinieren - ich hoffe, dafür werde ich nicht abgewatscht:

Host mit ESXi:

Gast 1 ZFS-NAS-VM (beispielsweise FreeNAS 11), das 2 getrennte "normale" ZFS-Pools mit Verschlüsselung bereitstellt, 1 x SSD-Pool - 1 x HDD-Pool, PCH-SATA wird per VT-d bereitgestellt
Gast 2: Anderes NAS-OS, das über eine virtuelle Netzwerkkarte mit Gast 1 verbunden ist, und uber iSCSI (?) die beiden Pools getrennt voneinander erhalt und dieses OS beschäftigt sich dann nur mit dem Tiering, erhält mittels VT-d die physischen Netzwerkkarten und stellt letztendlich den aufsummierten Speicherplatz für die Klienten.

Würde den RAM hierfür auf 64 GB aufstocken - wäre der genannte 4C/8T-Xeon für eine solche Kombinationslösung leistungsfähig genug (3,9 GHZ All Core-Turbo, 4,1 GHz Single Core-Turbo).
 
Zuletzt bearbeitet:
Gehen würde das. Ob das Sinn macht, welche ZFS-Features du ggf. dabei einbüßt und wie performant das Ganze dann ist, keine Ahnung. Ich könnte mir vorstellen, dass Du dann einen Großteil der Datenintegritäts-/-schutzmechanismen von ZFS und verbundener Funktionen aushebelst, weil Du am Ende davon abhängig bist, dass Dein Windows-System das Tiering vernünftig managed.

Nur mal ein Beispiel: Schon bei Snapshots (auf ZFS-Pool-Ebene) kannst Du nicht mehr 100%ig sicherstellen, dass die Snaps auf dem SSD- und dem HDD-Pool auch auf Datenebene uneingeschränkt zusammenpassen, einfach weil da vielleicht eine Millisekunden-Zeitdifferenz zwischen den Snaps auf Pool A und Pool B ist. Und dann kommt evtl. die Tiering-Logik durcheinander und die Kacke ist am dampfen. :d

Habe aber keine Peilung, wie Tiering im Detail funktioniert, nur mal laut rumgedacht.

Ich könnte die Tage sowas mal testweise aufsetzen aus einer Consumer SSD und einem HDD-RaidZ Pool, auf dem noch Platz wäre für ein kleines iSCSI-Share.
 
Die Snapshot-Funktionalität müsste dann wohl zur Sicherheit das Gast 2-Tiering-OS machen und Gast 1 ist ausschließlich für die physikalische Datenintegrität zuständig. Da das wie gesagt mein erstes Heim-NAS-System ist, bin ich für jegliche praktischen Erfahrungswerte dankbar - es ist für mich ja auch noch völlig unklar, ob es überhaupt passendes NAS-OS für Heimanwender gibt, das Tiering "gut" unterstützt.
 
Mit so einem "Tiering-Gast" pumpt man sich mutmasslich nur den ARC im Hauptspeicher und das Netzwerk durch die Umlagerei voll.
Und für den Fall des Arguments "soviel verschiebt sich nicht dauernd zwischen den beiden ZPool": dann braucht man auch kein Tiering weil dann ist so wenig Dynamik in den Daten, dass man einfach auch zwei Shares (langsam und schnell) haben kann.

So eine Lösung ist IMO daher, sagen wir diplomatisch, "suboptimal".
 
Danke für den Hinweis mit Server 2016, da wäre sogar eine Lizenz durch MS Imagine vorhanden.

@Trambahner: Es ist ja nicht so, dass diese Frankensteins Monster-Gast-Kombination nun sakrosankt feststehen würde, es wäre aber eventuell ein Experiment wert. Wenn's nichts taugt, dann wird eben umkonfiguriert. Die Netzwerklast wäre wohl weniger relevant, da in meinem skizzierten Aufbau die Kommunikation Gast 1-Gast 2 ja über einen virtuellen Adapter stattfindet und nach außen hin separate getrennte physikalische Netzwerkkarten verwendet werden würden.
 
Zuletzt bearbeitet:
Müllt Dir dann aber den vSwitch zu und v.a. nach wie vor den Ram-Cache. Der ist dann nicht mit dem gefüllt, was am meisten genutzt wird, sondern mit Umlagerungsdaten. "Viel Spaß" mit der Performance dann.

Musst Du wissen, aber ich halte es nach wie vor für Zeitverschwendung das zu probieren.
 
Eigentlich konzeptioneller Unfug

Entweder man nimmt Windows Pur mit Tiering, sollte dann aber ein Hardware Raid mit Batteriepuffer einrechnen oder man versucht Storage Spaces mit ReFS und CopyOnWrite - in beiden Fällen würde trotz tiering eher schlechtere Ergebisse erwarten als mit ZFS ohne Tiering aber mit dessen massivem Cache Einsatz. Window gilt nicht als sonderlich performant im Vergleich.

Die Lösung Windows Tiering auf ZFS Zvols läuft eher darauf hinaus dass man nicht jeweils die positiven Eigenschaften addiert sondern die Summer der negativen Eigenschaften erhält. Da die beiden ZFS Pools nicht syncron arbeiten werden alle CopyOnWrite Sicherheitsmerkmale auf Ebene von Windows ausgehebelt. Dazu gibt es statt ZFS Snaps nur Windows Shadow Copies. Im Hintergrund tiert dann Windows während ZFS beim Lesen eh fast alles aus dem Cache bedienen möchte. Beim Schreiben das gleiche über den ZFS RAM Schreibcache - alles ausgebremst durch Background Tiering Disklast und relativ unsicher ohne Batteriepuffer auf Windows Ebene..
 
Es könnte sein, dass eine Größenordnung zu groß geplant wird - es ist ja kein System, das dutzende VMs ausführt, die alle unter großer L/S-Last stehen - jedes MB der vorhandenen 6 Datenträger (2 SSDs, 4 HDDs) soll optimal genutzt werden, dabei gehen durch drei GbE-Karten vielleicht maximal 340 MB/s von außen durch das System. Die diversen ZFS-Funktionen sind bei mir natürlich Perlen vor die Säue, Hauptgrund waren ja lediglich die Datenintegritätsvorteile und eine Art Software-RAID 6, das etwa auf der Höhe von einem LSI-9361-RAID-Controller mit 1 GB Cache ist.

Aber dass es hier wieder zu einem erhöhten Risiko bei eventuellem Stromunterbrechungen kommt, habe ich außer Acht gelassen, alleine das war's dann sowieso als Ausschlusskriterium.
Danke für diesen Hinweis!
 
Zuletzt bearbeitet:
Wobei man das mit den Stromunterbrechungen ja mit ner gescheiten USV gut abfangen kann ... ;)
 
Hallo,

ich habe mich in der Zwischenzeit weiter durchgewurschtelt und bin nun recht zufrieden.

Ich habe FreeNas11 noch einmal installiert und damit gespielt.
Der Spinndown der Platten läuft 1a, aber erst nach einem ganzen Eck tüfteln :)
Denn FreeNas schreibt auf das System Dataset andauernd irgend einen LOG, hierdurch gehen die Platten eig. nie in den Spindown oder Idle.
Somit habe ich eine kleine virtuelle Platte im Proxmox erzeugt, und darauf das System Dataset gelegt, hier kann nun bunt herumgeschrieben werden und der große Pool geht sauber in den Spinndown.
Die NFS Freigabe an den Proxmox-Host für die VM funktioniert tadelos.
(15W/h gespart wenn der Pool schläft!)

Das einzige das mich noch nervt ist die Benutzer-Verwaltung, denn so wie ich das sehe kann ich ein Dataset nicht gleichzeitig über SMB und NFS freigeben :(
bzw. ist die Frage kann man User auch zentral in einem System verwalten und die anderen Systeme greifen darauf zu, denn ich muss für jede VM die User einzeln anlegen und das nervt! :)
(Active Directory ist mir bekannt, aber gibt es hier auch etwas brauchbares aus der Linux-Ecke, wo sich die Nextcloud usw, die User ziehen kann? evtl. der DC von XPEnology?)

Gruß Rocker
 
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