Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Indem sie den Schreibcache einfach aktivieren, auch ohne Absicherung. Das geht halt so lange gut bis man beim Schreiben mal den Stecker zieht. Anschließend gibts erst mal fschk und die unvollständigen Daten werden aus dem Dateisystem gekratzt.
Man kann sich jetzt streiten ob MS so eine Option auch anbieten sollte oder lieber auf Nummer Sicher geht und sowas gar nicht erst erlaubt.
Die ganze Diskussion drückt mich jetzt immer mehr Richtung HP MicroServer, die anscheinend auch ECC-RAM hat, und FreeNAS mit RAID-Z. Das muss wohl ne gute Performance bringen. Da muss ich mal schauen, wie es bei FreeNAS mit der Installation von weitere Software aussieht. Vllt. kann man ja sogar Windows virtualisiert laufen lassen, wenn man noch bestimmte Programme laufen lassen will, die unter BSD nicht funktionieren.
Zur Win-Virtu kann ich leider nichts sagen, hab ich noch nichts dazu probiert. Aber wenn bhyve Windows unterstützt dann sollte da (in Zukunft) nichts dagegen sprechen. Ich würde da einfach mal googlen oder im Forum von FreeNAS rumfragen
Was wichtig ist, du brauchst relativ viel RAM. Empfohlen werden mindestens 8 GB, besser 16 GB. Es geht natürlich auch mit weniger, aber falls es dann zu Problemen kommt wird die erste Antwort im Forum sein "benutz mehr RAM"
Je nach Anwendungsgebiet musst dir dann auch überlegen welches raid-z (oder mirror) du benutzt und ob du einen SLOG bzw. L2ARC brauchst. Ersteres ist eine Art Schreibcache, der aber nur unter bestimmten Bedinungen notwendig ist (Stichwort synchronous writes), letzteres ein Lese-Cache der aber auch nur in bestimmten Situationen Vorteile bringt.
ZFS bietet viele Möglichkeiten und mindestens genauso viele Stolpersteine, wenn du das also wirklich in Erwägung ziehst wäre es wichtig wofür du das nutzen willst und welche Hardware du hast
Generell kann man sagen: Für ein Media-NAS reichen 8 GB RAM und du brauchst weder SLOG noch L2ARC. Für Virtualisierung sieht die Sache wieder anders aus, da ist ein SLOG wieder sinnvoll(er)
ZFS hat damit keine Probleme da jede Schreiboperation, egal wie klein, immer atomar also abgeschlossen ist. Dadurch kann man sich den Cache komplett sparen.
Dafür brauchst du allerdings zum Halten der Metadaten recht viel RAM (pro TB Speicher 1GB RAM als Richtwert) und Software auf einem FreeNAS nachinstallieren kannst du fast vergessen. Selbst wenn es die Software für BSD gibt erfordert das wohl ziemlich gute Kenntnisse dieses Systems. Windows darauf virtualisieren kannst du komplett vergessen.
Anders sieht es mit der ZFS Integration in Ubuntu aus denn auf dessen Linux Basis kannst du leicht zusätzliche Software installieren und über KVM auch Windows virtualisieren. Allerdings kenne ich aktuell noch keine fertige NAS Distribution die auf diese Kombination setzt. Das heißt es ist wieder viel Handarbeit und Know-How im Linux Bereich nötig. Mal ganz davon abgesehen das ZFS einzurichten auch nicht einfach ist und man wissen sollte welche Parameter man setzt und welche Features wie nutzt.
Wenn Virtualisierung für dich ein Thema ist wäre es grundsätzlich noch möglich einen Hypervisor zu nutzen und darauf zwei VMs laufen zu lassen: Einmal FreeNAS mit Zugriff auf die Platten und einmal ein Windows für deine restliche Software. Damit hättest du das beste als beiden Welten, musst dich aber noch mit dem Hypervisor z.B. ESXi befassen.
Ich habe mir jetzt nochmal nen schönen Abend mit der Windows 2016 TP5 in VirtualBox gemacht, und bin da auf was vllt. ganz spannendes gestoßen. Die VM besteht dabei aus ner 64GB SSD und 3 25GB HDDs. Das OS habe ich auf eine 40 GB Partition der SSD installiert. Die HDDs habe ich gemeinsam mit den restlichen 23 GB der SSD in einen Storage Pool gepackt. Erstaunlicherweise ging das, den nicht partitionierten Platz der SSD mit in den Pool zu nehmen. Dann habe ich über die Konsole die MediaTypes der Laufwerke jeweils korrekt auf HDD und SSD festgelegt.
Nun habe ich begonnen einen virtuellen Datenträger anzulegen. Dabei konnte ich die Speicherebenen aktivieren. Im nächsten Schritt kann ich dann einzeln für SSDs und HDDs den Modus auswählen. Die SSD habe ich auf DImple gelegt, ist ja nur eine. Die HDDs auf Parity.
Die Größe habe ich jeweils auf maximal gesetzt. Was hier mit Lesecache gemeint ist, weiss ich nicht.
Leider schlägt am Ende das Anlegen fehl.
Ich frage mich, ob die Konfiguration so das wäre, was ich suche. Ein Schreib-Cache auf einer SSD (ohne Parity), dessen Inhalt dann auf die HDDs (mit Parity) übertragen wird.
Was du hier (fast) angelegt hat ist ein Tiered-Storage bei dem es einen SSD Pool und einen HDD Pool gibt und die Daten je nach Zugriffshäufigkeit auf die HDDs oder SSDs gelegt werden. Aber auch hier gilt: Für Simple brauchst du mindestens zwei SSDs.
Ah okay. Weiter vorn war mal von Write Caches die Rede. Wie kann ich das denn anlegen? Ich hatte es auch mal mit zwei virtuellen SSDs und 3 HDDs versucht sowas zu realisieren, ist mir aber im Assistenten nicht begegnet.
Ich habe nochmal ein bisschen "rumgeschnüffelt" und jetzt habe ich über folgende Konfiguration nachgedacht. WBC ist ja nichts, was grundsätzlich nur auf SSDs beschränkt ist. Was passiert jetzt also, wenn ich einen Parity Pool anlege, der beispielsweise aus 1x256GB SSD und 3x8TB HDD besteht? AFAIK müssen hier die Platten anders als bei RAID5 wohl nicht gleich groß sein. Wenn ich das jetzt mit beispielsweise 30GB WBC konfiguriere, lässt sich dann die Performance steigern? Evtl kann man auch die ganze Platte als Journal einrichten, das haben ich aber noch nichtnicht ganz durchschaut. Wobei ich glaube bei den Journals muss ich dann wieder zwei SSDs haben, nicht wahr?
In dem Fall schon, normale HDDs lassen sich nicht als Cache nutzen.
Die ganze Platte als Journal zu nutzen macht auch wenig Sinn, denn darin sollen ja nur kleine Zugriffe zusammengefasst werden. Sobald ein Stripe komplett ist wird er auf die Platten migriert.
Ich werde es auf jeden Fall mal lesen, vllt. bringt mir das etwas mehr Klarheit. Die ZFS Idee habe ich nun endgültig verworfen, da es hier nicht möglich ist mit 3x 8TB zu starten und dann sukzessiv bei Bedarf jeweils eine weitere Platte hinzuzufügen. Anscheinend müsste ich dann direkt wieder 3 Stück hinzufügen bei RAIDZ.
Ergänzung ()
Nach der Durchsicht des Papiers komme ich zu dem Schluss entweder aus Kostenersparnis einfach mit der langsamen Schreibperformance des Parity zu leben, oder aber sowas hier* als Journal WBC hinzuzufügen. Das ganze würde ich dann wie in dem auf Seite 13 des Fujitsu Paper beschriebenen Szenarios einrichten:
Erstellt man ein Space und hat HDDs und SSDs im Storage Pool, wird zwar ein automatisch ein WBC
angelegt, aber zusätzlich zu dem WBC wird die Kapazität der SSDs gemeinsam mit den HDDs genutzt um
die Virtual Disk zu erstellen. Das wird vermutlich in den meisten Fällen nicht gewünscht sein. Um die SSD-Speicherkapazität
ausschließlich für den WBC zu nutzen, müssen die SSDs im betroffenen Pool mit dem
folgenden PowerShell-Befehl als „Journal“-Laufwerk markiert werden.
Ich würde den restlichen Platz frei lassen um der SSD immer genug freie Zellen zu lassen, dann sinkt die Performance auch nicht ab wenn die SSD einmal voll war.
Ich hab bis jetzt keinen Weg gefunden die SSDs später hinzuzufügen aber habs selbst auch noch nicht getestet. Würde mich auch mal interessieren.
