FabianX2 schrieb:
"Kurzes Update" Habe angefangen mich intensiver einzulesen ist aber noch ein langer Weg:
Copy-on-write ist ne coole Sache gerade auch was Stromausfälle o.ä. betrifft.
Jain. Kommt drauf an ob du Zugriff auf die Daten async oder sync machst. Bei async + Stromausfall sind die Schreibzugriffe der letzten 5-30 Sekunden weg. Also naja... die Daten sind ggf. noch "da" aber nur noch Datensalat mit dem du nix anfangen kannst.
FabianX2 schrieb:
Snapshots sind super. Werden es mir erleichtern mit VMs rumzuspielen. Gerade dass man eine laufende VM snapen kann
. Ansonsten Schutz vor der eigenen Dummheit etc. Aber noch kein Echtes Back up. Bin in der Praxis gespannt wie praktikabel dass im Bezug auf die größeren Datenmengen ist.
Achtung! Du wirfst hier zwei Arten von Snapshots zusammen.
1) Es gibt Snaphots auf Dataset/ZVol Ebene. Also auf eine SMB/NFS Freigabe (Dataset) oder auf ein iSCSI Volume (ZVol). Betreibst du den NFS-Share als Datastore für VMware/XEN/KVM/Proxmox mit mehreren VMs drin und machst einen Snapshot > Daten in VM inkonsistent. Gleiches gilt für iSCSI wenn dies als LUN für den Hypervisor genutzt wird und nicht direkt als LUN für die VM. (Begriffe, die du nicht kennst > Suchmaschine/Wiki deiner Wahl).
2) Snapshots, die der Hypervisor auf eine VM veranlasst. Dies kann in Zusammenspiel mit dem Storage-System funktionieren, heißt afaik bei VMware z.B. VAAI. Muss dann der Hypervisor UND das Storage-System unterstützen.
Auch frage ich mich: Du willst auf der Hardware Proxmox installieren, FreeNAS als VM und dann mit Snapshots herum spielen. Damit sind wir nur bei o.g. Variante 1. Alles andere macht bei deinem Setup keinen Sinn und erhöht nur unnötig die Komplexität. Tu dir und uns einen Gefallen und halte es so simpel wie nötig.
FabianX2 schrieb:
Das ist die Clonen Funktion richtig? [...]
Ja, du kannst einen Snapshot eines Datasets/ZVols klonen und woanders hin verschieben. ZFS send/receive ist aber performanter und effizienter als ein rsync eines Snapshots. Weiterer Lesestoff, auch der dort verlinkte Talk auf youtube:
https://superuser.com/questions/1287578/backup-zfs-pool-using-rsync
Wobei es da natürlich schwer wird, wenn der Bürorechner mit Klickibunti-Windows läuft, der wird mit ZFS-Befehlen nicht umgehen können aber auch rsync und Windows ist so eine Sache...
FabianX2 schrieb:
RAID-Z: Denke aktuell an ein RAID-Z2. Ich habe gelesen dass man zusätzlich automatisch auf zwei oder mehrere Platten spiegeln kann. Verstehe nicht wie das in dem Kontext gehen soll. Den Vorteil von Raud-Z2 gegenüber einer klassischen Spiegelung ist "nur" dass bei gleicher Nutzdatenmenge (ca. 50%) gleich zwei und nicht nur eine Platte hops gehen kann.
Bitte bitte bitte lies Texte auch zuende oder mehrmals und ggf. nicht nur jede zweite Zeile.
"Spiegeln" von Disks ist vergleichbar mit einem Raid 1, raid--z2 entspricht einem Raid 6. Ja, rein theoretisch kannst du immer zwei Disks spiegeln und über vier solcher Spiegel ein Raid 6 legen. Genau so wie man jedes beliebige andere Raid auch kombinieren kann, zumindest unter Linux und sollte auch mit ZFS unter Unix/BSD funktionieren.
Dein Vorteil mit den 50% ist auch nur eine Momentaufnahme in deinem konkreten Beispiel. Bei einem Mirrir mit 2 Disks -> 50% "Verschnitt", eine kann ausfallen. Mirror mit 3 Disks -> 66% Verschnitt, 2 von 3 können ausfallen. Bei 4 Disks kannst du zwei Mirrors anlegen und darüber den Pool erstellen (quasi ein Raid 10 dann) und du hast wieder nur 50% Verschnitt und pro Mirror darf eine Disk ausfallen. Klassischer Anwendungsfall bei Servern mit hoher IO-Anforderung und Rebuild geht schneller, da 1:1 Kopie und keine Paritäten errechnet werden müssen. Mit 4 Disks kannst aber auch ein Raid-z2 anlegen, hast ebenso 50% Verschnitt und zwei beliebige Disks können ausfallen. Mit 5 Disks und Raid-z2 hast nur noch 40% Verschnitt und weiterhin können zwei beliebige Disks ausfallen.
FabianX2 schrieb:
Deduplication [...] L2ARC [...]
Ein L2ARC ist doch keine Alternative zu Dedup. Je nach Anwendungsfall kann ein L2ARC sogar dein Storage verlangsamen oder gar keinen Einfluss haben. Wenn wir von einer simplen SMB-Freigabe, also Netzlaufwerk, reden wirst du kein L2ARC benötigen. Grob kann man sagen: Solange dein FreeNAS-System nicht mindestens 32GB oder besser 64GB Ram hat bringt dir ein L2ARC absolut gar nichts bzw. ist kontraproduktiv. Auch wenn du ZFS für Proxmox verwenden willst: Zuerst mehr RAM, dann L2ARC.
FabianX2 schrieb:
Bei einem Raid-Z2 brauche ich mindestens 4 Platten. Setze ich 4*8TB (7270GB) ein habe ich laut Rechner noch 13,5TB. Bei 5*8TB (7270GB) sind es 20,8TB. Damit eine bessere Ausbeute klar. Aber Geld ist gerade knapp. Und soweit richtig verstanden kann ich den Speicherpool (VDEVs) ja jederzeit um eine weitere Platte erweitern. Oder geht das im Fall eines Raid-Z2 nicht? Aktuell würden ja erst mal 4 Platten reichen und ich hätte erst mal 230€ "gespart".
Storage ist immer teuer, finde dich damit ab
Nein, eine VDEV kannst du nicht nachträglich erweitern. Sonderfall: Eine bestehende Disk entfernen, größere rein, rebuild, nächste entfernen, größere rein, rebuild, usw. bis alle Disks in der VDEV getauscht sind. Dann Vergrößerung des Pools.
Einen Pool kannst du jederzeit erweitern um weitere VDEVs aber niemals verkleinern. Startest du jetzt mit 4x Disks als raid-z2 und erstellst darauf deinen Pool und kaufst dann in einem Jahr eine einzelne HDD dazu und erweiterst den Pool mit dieser einen Platte dann hast du einen der häufigsten und gefährlichsten Anfängerfehler gemacht. Dein Pool streckt sich jetzt über 2x VDEVs. Einmal dein raid-z2 und eine einzelne Disk. Ein Pool ist immer dann dauerhaft verloren, wenn eine VDEV komplett aussteigt. Steigt also deine nachträglich gekaufte einzelne Disk aus -> alle Daten weg.
ZFS ist toll und hat viele gute Features. Wachstum im Heimanwenderbereich gehört nicht dazu, da dies bei der Entwicklung nie Zielgruppe war oder ist bzw. Redundanz wird auf Ebene der VDEVs festgelegt, nicht auf Poolebene. Einzelne Disk hinzugefügt -> Keine Redundanz vorhanden.
Auch sollte ein Pool bzw. Dataset nicht zu mehr als 80% belegt sein, sonst kann es zu Einbußen bei der Performance kommen. Bei einer simplen SMB-Freigabe natürlich weniger als einem Datastore für VMs.
FabianX2 schrieb:
Ich kann doch genauso die Sataports vom Mobo durchreichen oder? Die würden mir dann zwar unter Proxmox nicht mehr zur Verfügung stehen aber ich hätte in meinem Fall ja dann immer noch 2xM2 die ich nicht mit durchschleife. Oder hab ich da gerade einen Denkfehler? Ich könnte ja in beiden fällen den vollen Funktionsumfang von FreeNAS nutzen oder?
Soweit mir bekannt kann man nur ganze Controller durch reichen, nicht einzelne Ports. Wenn die M.2 Slots per PCIe angebunden sind, können diese für Proxmox verbleiben aber der Onboard-Controller gehört entweder Proxmox oder der FreeNAS-VM.
Wenn du einen günstigen Controller suchst, empfehle ich den IBM M1015. Ist auch "nur" ein LSI9211 aber zigfach bei diversen FreeNAS Installationen im Einsatz und bekommst in der Bucht für 35-40€ mit etwas Glück.
Hot-Swap bzw. Buskapazität sind wieder zwei verschiedene Paar Schuhe. Ersteres heißt ja nur, dass du im laufenden Betrieb Disks abziehen oder hinzustecken kannst aber da sehe ich keinen Anwendungsfall und letzteres ist eher ein Problem bei billigen HBAs, die nur per PCIe x1 oder x2 angebunden sind und du SSDs dran betreiben willst. Ebenso nicht relevant für dich bzw. sehe ich dies nicht.
FabianX2 schrieb:
Die Migration der Daten stellt mich auch noch vor ein Rätzel. Ohne weitere Platten zu kaufen muss ich ja quasi in kauf nehmen dass die Daten kurzzeitig nicht gesichert sind.
Entweder das oder du packst die Daten temporär auf einen passenden Cloudstorage wo du nur pro Nutzung zahlst. Wichtig hierbei: In der Regel zahlst du pro GB pro Zeiteinheit aber auch zusätzlich für jedes herunter gelandene GB. Backblaze B2 oder Wasabi sollten mit die günstigsten Anbieter sein würde ich vermuten. Limitierung wäre hier vermutlich dein Upload. Aber wie schon erwähnt: Storage und/oder Backup kostet halt
