[Sammelthread] ZFS Stammtisch

Ich bräuchte mal allgemeine Beratung bzgl. einer Backupstrategie:
---

Ich hab einen ESXi Server mit einem SSD ZFS (2 SSDs im RAID1) und einem HDD ZFS (4x HDDs im Raid 10 insg. 4TB) Pool. Der SSD Pool wird auf dem HDD Pool gesichert. Der ESXi Server (nur privat genutzt) virtualisiert bei mir zu Hause in der Wohnung sämtliche Sachen (Fileserver, Firewall etc.).

Aktuell liegen bei mir in der Wohnung ein HP N36L (8GB ECC RAM) & ein Raspberry Pi ungenutzt herum. Als Backup für den ESXi Server habe ich 2x 4TB HDDs.

Ich könnte den HP N36L als Backupserver in meiner 2 Zimmer Wohnung umfunktionieren, aber er liegt dann auch nicht in einem anderen Brandabschnitt bzw. ist sicher vor Diebstahl. Ich hätte die Möglichkeit den HP N36L bei meinen Eltern aufzustellen, die Internetleitung ist dort aber recht schwach und ne Firewall, USV etc. gibt es dort auch nicht.

Wie löst Ihr das Backup für zu Hause? Würde gerne so viel wie möglich automatisieren.

Tendiere momentan eher dazu, dass ich eine der 4TB HDD bei meinen Eltern lagere und diese in regelmäßigen Abständen mit der anderen tausche. Die andere soll dann permanent am ESXi Server hängen und zB täglich ein Backup via ZFS send bekommen. Ganz wichtige Daten würde ich dann noch verschlüsselt auf ne Cloud laden.

Den HP N36L Server würde ich dann verkaufen. Ich sehe ehrlich gesagt keinen Sinn dahinter den HP Server zu verwenden, da wie oben schon erwähnt er in der selben Wohnung steht und bei z.B. einem Blitzeinschlag vermutlich beide Server down gehen.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich würde auch mit externen Platten arbeiten.
Am einfachsten geht das, wenn man im Server Platten direkt ein oder abstecken kann.

Ich würde vermutlich den alten HP behalten da es eh kaum Geld gibt und er so geschickte Plattenbays hat und dann wenigstens täglich Daten darauf per ZFS send auf einen Pools sichern. Diesen aktiven Backup Pool (Einzelplatte oder Mirror) dann regelmäßig herausnehmen und woanders lagern und mit einem zweiten Backuppool weitersichern.
 
Mache es ähnlich. Eine Platte mit den Kerndaten liegt "im anderen Brandabschnitt" bei meinen Eltern. Die wird so alle paar Monate ausgetauscht / upgedated.

Zum Schutz vor Sturz, Wasserflaschen, Kindern oder sonstigen Unbill in der häuslichen Umgebung steht ein 2. Server räumlich etwas entfernt der den Primärpool 1x die Woche - und bei Bedarf, in erster Linie vor mehr oder minder geplanten Änderungen / Spielereien am Primärserver - per ZFS send/receive "spiegelt".

Das ist für mich schon sehr komfortabel und genügt meinen Sicherheitsanforderungen für den persönlichen Wohlfühlfaktor. Allerdings finden bei meinen Kerndaten auch nicht soooo viele Änderungen über eine Woche statt, sonst müsste man da etwas kürzere Intervalle wählen.
 
Vielen Dank für Euren Input bzgl. Backup! Werde dann den N36L behalten :)
---

Ich meine gelesen zu haben, dass ZFS doch viele Reads aus dem Arbeitsspeicher bedient. Macht dann ZFS immer den Arbeitsspeicher komplett voll, belässt dort sämtliche Dateien und löscht nur bei Bedarf (also wenn neue Dateien geöffnet werden)? Heißt das auch, dass ein erneuter Read (angenommen es wird ein Bild geöffnet und in 10min nochmal verwendet) dann aus dem Arbeitsspeicher bedient wird?

Falls ja, erkennt dann ZFS auch die Priorität von Dateien (z.B. Datei XY wird am Tag öfters verwendet, deshalb lasse ich es eher im RAM als ein random Bild)?

Vielen Dank.


Angenommen ich öffne eine Datei mit 500MB, wird dieses File dann komplett in den Arbeitsspeicher geladen und steht für spätere Zugriffe zur Verfügung (aus dem Arbeitsspeicher)?
 
ZFS benutzt fast den kompletten freien RAM als Lesecache, gibt ihn aber wieder frei wenn andere Prozesse RAM benötigen. Mit ausreichend RAM werden nach einer Warm-Up Phase die meisten Lesezugriffe (oft über 90%) aus dem RAM bedient.

Der Cache ist dabei einer der besten derzeit. Er arbeitet blockbasiert und dynamisch als Mix aus Last Accessed, Most Acessed und Read Ahead. Der Grund warum man bei ZFS gerne sehr viel RAM einsetzt. Nicht weil ZFS das bräuchte, Solaris 64 bit z.B. braucht 2GB für stabilen Berieb - sondern weil RAM als Lesecache richtig Performance bringt.

Ein einzelnes File würde daher nicht komplett im Cache landen und diesen blockieren. Es ist eher so dass wahlfreies Lesen z.B. Metadaten vor gr0ßen sequentiellen Daten wie z.B. Videostreams bevorzugt wird.

Mit einem zusätzlichen großen L2Arc kann man aber auch sequentielle Daten wie Videos cachen lassen (einstellbar).
 
Zuletzt bearbeitet:
Vielleicht kann mir einer von Euch helfen.

Ich habe einen nagelneuen Server, mit 4-Kern-Xeon und 3,4GHz. Dazu 32GB RAM und 6x8TB Storage Festplatten (die langsamen Archive von Seagate) - dazu habe ich 2x Samsung 950 PRO und einen DOM auf dem Mainboard.
Darauf wurde das letzte Stable Release von OmniOS installiert, dann Napp-IT installiert und ein Pool/Storage mit den 6 Seagate 8TB Festplatten zzgl. einem Lese Cache (als Partition 2x einzeln mit je 32GB) - dazu dann noch die restlichen Partitionen der 950 Pro als LOG-Mirror. Das Raid wurde als Raid-Z2 erstellt. Dedup ist aus, nur Komprimierung mit LZ4 ist an.

Anschließend habe ich ein iSCSI Device angelegt (500G) und darauf eine vorhandene VHD von unserem Hyper-V Host genommen. Die Wartenschlangenlänge auf dem Host ist dauerhaft, quasi bei jeder Aktion, sehr hoch (auf dem ISCSI Device unter Windows) und ich hätte mir von der Config deutlich mehr erhofft. Zeil ist es mit dem ZUFS einen Storage für virtuelle Maschinen zu stellen.

Ich habe von anderen bereits gehört, dass ein iSCSI nicht optimal für einen HYPER-V Host ist, aber wie macht ihr das? Was ist an der Config falsch? Was kann ich tun um die Performance deutlich zu erhöhen?

danke
sash
 
Zuletzt bearbeitet:
Spontan würde ich sagen, dass es an den Archiv Platten liegt. Diese sind für sequenziellen Zugriff und nicht für random Zugriff ausgelegt.

Zudem was ist bei dir in der Warteschlange hoch? Wie hast du gemessen? Ist das Raid vollständig fertig mit der Initialisierung? Wie ist das System angebunden? 1 x 1 GBe? x x 1 GBe? 10 GBe, 25? 40?

iSCSI passt schon bei Hyper-V. Besser wird es mit MPIO. Am besten allerdings mit SMB3.1 Multichannel (meine gelesen zu haben, dass das OmniOS nicht kann).
 
ZFS benutzt fast den kompletten freien RAM als Lesecache, gibt ihn aber wieder frei wenn andere Prozesse RAM benötigen. Mit ausreichend RAM werden nach einer Warm-Up Phase die meisten Lesezugriffe (oft über 90%) aus dem RAM bedient.

Der Cache ist dabei einer der besten derzeit. Er arbeitet blockbasiert und dynamisch als Mix aus Last Accessed, Most Acessed und Read Ahead. Der Grund warum man bei ZFS gerne sehr viel RAM einsetzt. Nicht weil ZFS das bräuchte, Solaris 64 bit z.B. braucht 2GB für stabilen Berieb - sondern weil RAM als Lesecache richtig Performance bringt.

Ein einzelnes File würde daher nicht komplett im Cache landen und diesen blockieren. Es ist eher so dass wahlfreies Lesen z.B. Metadaten vor gr0ßen sequentiellen Daten wie z.B. Videostreams bevorzugt wird.

Mit einem zusätzlichen großen L2Arc kann man aber auch sequentielle Daten wie Videos cachen lassen (einstellbar).

Danke :-)
 
Vielleicht kann mir einer von Euch helfen.

Ich habe einen nagelneuen Server, mit 4-Kern-Xeon und 3,4GHz. Dazu 32GB RAM und 6x8TB Storage Festplatten (die langsamen Archive von Seagate) - dazu habe ich 2x Samsung 950 PRO und einen DOM auf dem Mainboard.
Darauf wurde das letzte Stable Release von OmniOS installiert, dann Napp-IT installiert und ein Pool/Storage mit den 6 Seagate 8TB Festplatten zzgl. einem Lese Cache (als Partition 2x einzeln mit je 32GB) - dazu dann noch die restlichen Partitionen der 950 Pro als LOG-Mirror. Das Raid wurde als Raid-Z2 erstellt. Dedup ist aus, nur Komprimierung mit LZ4 ist an.

Anschließend habe ich ein iSCSI Device angelegt (500G) und darauf eine vorhandene VHD von unserem Hyper-V Host genommen. Die Wartenschlangenlänge auf dem Host ist dauerhaft, quasi bei jeder Aktion, sehr hoch (auf dem ISCSI Device unter Windows) und ich hätte mir von der Config deutlich mehr erhofft. Zeil ist es mit dem ZUFS einen Storage für virtuelle Maschinen zu stellen.

Ich habe von anderen bereits gehört, dass ein iSCSI nicht optimal für einen HYPER-V Host ist, aber wie macht ihr das? Was ist an der Config falsch? Was kann ich tun um die Performance deutlich zu erhöhen?

danke
sash

Die Archive Platten sind für Raid oder als VM Storage komplett untauglich.
Auch die Samsung ist als Log Device nicht optimal (kein Powerloss Protection, zu geringe iops unter konstanter Schreiblast)

Ich würde einfach mal einen Mirror aus den Samsungs anlegen und mit sync=always und sync=disabled bzw bei iSCSI writeback cache=enabled einen Performancevergleich machen (ohne Log oder L2Arc)

Spielraum für Optimierung bietet dann noch: größere ip Buffer und MTU 9000
 
Ich hab bereits in einem anderen Thread eine Kaufberatung bzgl. HDD Wahl & Raid Level gestellt, ich denke aber das es hier besser aufgehoben ist:

Vorhandener Server: 4 Kern Xeon, 16GB ECC, 2x Consumer SSDs, geflashter HP Dell H200 (IT Mode) Controller
Einsatzzweck des Servers: Alles unter ZFS ==> Fileserver für 3 User (parallele Zugriffe eher selten, wenn dann nur für ein paar Stunden am Abend), Time-Machine Backup Server (für 2 Macbooks), Downloadserver (50Mbit Leitung, downloads primär in der Nacht), Server für Videoüberwachung (konstant werden von 2 Kameras HD Bilder alle paar Sekunden gemacht) und in Zukunft evtl. noch kleinere Dienste wie private Webseite etc.)

Raid1 bzw. Mirror ZFS SSD Pool für die Betriebssysteme ist wie oben schon erwähnt vorhanden, ich bräuchte noch eine Kaufberatung bzgl. Festplatten des HDD Pools & welches Raid Level verwendet werden soll. Stromverbrauch (24/7) & Lautstärke (Server im Wohnzimmer) spielen auch eine Rolle.

Als Speicherplatz werden aktuell 1TB verwendet, vermutlich wird in den nächsten Jahren wenig hinzukommen. 2TB sollten erst einmal ausreichen, wobei ein späteres Upgrade auf z.B. 4TB nice to have wäre.

Gedacht habe ich an einen 2x 2TB Raid1 Pool (mit Seagate NAS 5.900rpm od. WD Red 5.400rpm). Von der Lautstärke wären die Platten optimal, bin mir nur unsicher, ob die Performance reicht, da der Download & der Videoüberwachungsserver konstant Last erzeugen. Ebenfalls kann es auch mal sein, dass 2 User ihr Time-Machine Backup machen und der 3. Videos streamt.

Eine Alternative wäre etwas in Raid5 (schlecht wegen den Rebuild Zeiten) oder Raid10 (z.B. mit 4x 1TB Platten) Richtung. Obwohl, wie oben schon angesprochen, eine Erweiterung auf 4TB in Zukunft nice to have wäre. Stromverbrauch bei mehreren Platten ist natürlich auch ein Thema.

Welche HDDs (evtl. auch 7.200er) und welches Raid Level könnt ihr mir empfehlen?


Vielen Dank :-)
 
M.E. fährst du mit Raid5 bzw. RaidZ gar nicht so verkehrt. Bei 4x1TB ohnehin. Mach ich auch, sogar mit 4TB Platten. Klar, rebuild dauert etwas (habs inzwischen 3x getestet), aber du kannst der Verbund ja währenddessen weiterlaufen lassen. Im Übrigen dauert der Rebuild beim Mirror auch... In beiden Fällen limitiert m.E. eh die Platte, die neu hinzukommt, so dass es primär auf die Datenmenge ankommt.

Bleibt die Frage nach der Performance. Sequenziell liefert mein RaidZ +/- ca. 350MB lesend/schreibend. Zu random-Werten bei 4 parallelen Zugriffen musst Du die Profis fragen.

Zu Platten: ich würde wohl eher zu 7200ern greifen, wenn Du Zweifel bei der Performance hast.
 
Spontan würde ich sagen, dass es an den Archiv Platten liegt. Diese sind für sequenziellen Zugriff und nicht für random Zugriff ausgelegt.

Zudem was ist bei dir in der Warteschlange hoch? Wie hast du gemessen? Ist das Raid vollständig fertig mit der Initialisierung? Wie ist das System angebunden? 1 x 1 GBe? x x 1 GBe? 10 GBe, 25? 40?

iSCSI passt schon bei Hyper-V. Besser wird es mit MPIO. Am besten allerdings mit SMB3.1 Multichannel (meine gelesen zu haben, dass das OmniOS nicht kann).

Danke. Die Anbindung ist noch über 1GBe, da unsere 10GBe Netzwrkkarten noch nicht da sind...
Die Warteschlangenlänge habe ich auf dem HYPER-V Host ermittelt (auf dem iSCSI Device bzw. Laufwerk.

Die Archive Platten sind für Raid oder als VM Storage komplett untauglich.
Auch die Samsung ist als Log Device nicht optimal (kein Powerloss Protection, zu geringe iops unter konstanter Schreiblast)

Ich würde einfach mal einen Mirror aus den Samsungs anlegen und mit sync=always und sync=disabled bzw bei iSCSI writeback cache=enabled einen Performancevergleich machen (ohne Log oder L2Arc)

Spielraum für Optimierung bietet dann noch: größere ip Buffer und MTU 9000

Das werde ich testen. Welche Optionen für einen großen Storage habe ich denn um mit SSDs die Performance zu erhöhen, mit anderen Worten: welche Festplatten würdest Du empfehlen?
 
Beim Schreiben hilft eigentlich nur rohe Gewalt wenn man top-io-Werte möchte, also eigentlich heutzutage SSD only Pools. Früher nahm man sehr viele Mirrors (Multi-Raid-10) aus kleineren Platten. Ich würde mir auch überlegen ob man high performance und high capacity auf zwei Pools trennen kann. Sehr schnelles und sehr großes Storage geht richtig ins Geld. Für Kapazität kann man sowas wie eine HGST Ultrastar 8TB HE nehmen. Die ist grad recht günstig und hat auch keine Probleme mit wahlfreiem Schreiben oder Schreib-IO wie Archive Platten.

Beim Lesen hilft ein Lesechache. Der schnellste ist der ARC Ramcache. Die schnellste Option ist daher mehr RAM für ZFS. Geht das nicht oder wird das zu teuer, kann man eine SSD als L2Arc nehmen um den Lesecache zu vergrößern. Das ist aber erheblich langsamer als mehr RAM.

Wenn man das Storage OS nicht virtualisiert, kann man auch PCI-e NVMe nehmen, z.B. Intel P7500, P3600 oder P3608. Die sind erheblich schneller als Satas/SAS SSDs.
 
Zuletzt bearbeitet:
Wo liegen eigentlich die Probleme bei NVME-Passthrough?

Gesendet von meinem Redmi Note 2 mit Tapatalk
 
Mal zwei Anfängerfragen:

- Bietet die Storage VM auch den Netzwerkshares für die User an oder dient sie einzig und allein zur Bereitstellung von Storage für ESX(i)? Heist das im zweiten Fall, dass ich auch eine extra VM anlegen muss (z.B. mit OpenMediaVault) die den Fileserver bzw. die Netzwerkshares für die User bereitstellt?

- So wie ich es verstanden habe, lege ich meine *.vmdk Dateien auf den ZFS Pool. Angenommen ich spiel ein neues Update in ein Betriebssystem ein und dieses geht schief. Wie kann ich das Betriebssystem sichern? Momentan mache ich das ganze mit VEEAM. Bei ZFS mache ich doch Snapshots, richtig? Kann ich dann auch einstellen, dass ich nur von einer bestimmten *.vmdk den Snapshot wiederherstellen will, oder wird dann der gesamte Pool wiederhergestellt?
 
Wo liegen eigentlich die Probleme bei NVME-Passthrough?

Gesendet von meinem Redmi Note 2 mit Tapatalk

Die NVMe wird erkannt, beim Zugriff z.B. mit format hängt das System.
Man kann es nur bei ESXi Updates erneut versuchen.

- - - Updated - - -

Mal zwei Anfängerfragen:

- Bietet die Storage VM auch den Netzwerkshares für die User an oder dient sie einzig und allein zur Bereitstellung von Storage für ESX(i)? Heist das im zweiten Fall, dass ich auch eine extra VM anlegen muss (z.B. mit OpenMediaVault) die den Fileserver bzw. die Netzwerkshares für die User bereitstellt?

- So wie ich es verstanden habe, lege ich meine *.vmdk Dateien auf den ZFS Pool. Angenommen ich spiel ein neues Update in ein Betriebssystem ein und dieses geht schief. Wie kann ich das Betriebssystem sichern? Momentan mache ich das ganze mit VEEAM. Bei ZFS mache ich doch Snapshots, richtig? Kann ich dann auch einstellen, dass ich nur von einer bestimmten *.vmdk den Snapshot wiederherstellen will, oder wird dann der gesamte Pool wiederhergestellt?

Die Storage VM bietet alle SAN/NAS Features.
Nur weil das OS virtuaalisiert wird, gehen ja keine Funktionen verloren.

Meist ist das Problem eher so gelagert, dass man im allgemeinen/unsicheren Netz keine NFS/iSCSI Shares haben möchte auf die nicht nur ESXi und Management Rechner sondern jeder zugreifen könnte. iSCSI, NFS und SMB lauschen ja an allen Netzwerkkarten. Abhilfe schafft dann die Firewall die z.B. NFS Zugriffe nur aus dem sicheren Netz (z.B. ein SAN vlan) erlaubt.

Üblicherweise gibt dis Storage VM ein ZFS Dateisystem als NFS share frei. Das wird in ESXi gemounted um darauf VMs abzulegen. Die Snapshots bei ZFS gehen immer per Dateisystem. Auf einem Pool kann man aber praktisch beliebig viele Dateisystems anlegen, z.B. eines für NFS, eines für iSCSI oder eines per User. Damit kann man dann unterschiedlich häufig Snaps anlegen lassen. Man muss bei Solarish SMB/NFS nur wissen, dass hier ein Share eine Eigenschaft eines ZFS Dateisystems ist - im Gegensatz z.B. zu SAMBA das Shares beliebig im Dateisystem anlegen kann. Das hat nicht ganz die Flexibilität von SAMBA, dafür gibt es keine Konfigurationsdatei sondern nur SMB=an/aus (besonders einfach). Alles andere wie Rechte oder weitere Eigenschaften steckt im Dateisystem als ZFS Eigenschaft, inkl den Windows "prvevious Versions" hie hier deshalb besonders einfach funktionieren da sie ja auch eine Eigenschaft eines Dateisystems sind.

Zugriff auf die Snaps geht per Windows "vorherige Version", per rollback oder per clone. Das ist ein beschreibbares Dateisystem das aus einem Snap erzeugt wird.
 
Die NVMe wird erkannt, beim Zugriff z.B. mit format hängt das System.
Man kann es nur bei ESXi Updates erneut versuchen.

- - - Updated - - -



Die Storage VM bietet alle SAN/NAS Features.
Nur weil das OS virtuaalisiert wird, gehen ja keine Funktionen verloren.

Meist ist das Problem eher so gelagert, dass man im allgemeinen/unsicheren Netz keine NFS/iSCSI Shares haben möchte auf die nicht nur ESXi und Management Rechner sondern jeder zugreifen könnte. iSCSI, NFS und SMB lauschen ja an allen Netzwerkkarten. Abhilfe schafft dann die Firewall die z.B. NFS Zugriffe nur aus dem sicheren Netz (z.B. ein SAN vlan) erlaubt.

Üblicherweise gibt dis Storage VM ein ZFS Dateisystem als NFS share frei. Das wird in ESXi gemounted um darauf VMs abzulegen. Die Snapshots bei ZFS gehen immer per Dateisystem. Auf einem Pool kann man aber praktisch beliebig viele Dateisystems anlegen, z.B. eines für NFS, eines für iSCSI oder eines per User. Damit kann man dann unterschiedlich häufig Snaps anlegen lassen. Man muss bei Solarish SMB/NFS nur wissen, dass hier ein Share eine Eigenschaft eines ZFS Dateisystems ist - im Gegensatz z.B. zu SAMBA das Shares beliebig im Dateisystem anlegen kann. Das hat nicht ganz die Flexibilität von SAMBA, dafür gibt es keine Konfigurationsdatei sondern nur SMB=an/aus (besonders einfach). Alles andere wie Rechte oder weitere Eigenschaften steckt im Dateisystem als ZFS Eigenschaft, inkl den Windows "prvevious Versions" hie hier deshalb besonders einfach funktionieren da sie ja auch eine Eigenschaft eines Dateisystems sind.

Zugriff auf die Snaps geht per Windows "vorherige Version", per rollback oder per clone. Das ist ein beschreibbares Dateisystem das aus einem Snap erzeugt wird.

Vielen Dank gea. Wenn ich aber ehrlich bin, habe ich zum Teil nur Bahnhof verstanden. Das liegt nicht an dir, sondern an meinem (nicht) vorhandenem Wissen :-).

Also noch kurz gesagt:

- Ich erstelle eine VM mit einem Betriebssystem das die Samba Shares für die User freigibt. Die Storage VM stellt NFS Share NUR für ESXi bereit.

- Ein Backup Tool wie zB Veeam benötige ich nicht mehr, weil ich eine einzelne*.vmdk Datei (bzw. eine gesamte Virtuelle Maschine) wiederherstellen kann, wenn ein Snapshot vorhanden ist.

Habe alles so richtig verstanden?
 
Vielen Dank gea. Wenn ich aber ehrlich bin, habe ich zum Teil nur Bahnhof verstanden. Das liegt nicht an dir, sondern an meinem (nicht) vorhandenem Wissen :-).

Also noch kurz gesagt:

- Ich erstelle eine VM mit einem Betriebssystem das die Samba Shares für die User freigibt. Die Storage VM stellt NFS Share NUR für ESXi bereit.
Könnte man so machen, wäre aber wie ein Auto mit 5 Rädern, unnötig und ultrakompliziert.
Man nimmt natürlich nur eine Storage VM für alle Shares, egal ob iSCSI, NFS oder SMB.

Wenn man als Storage VM etwas auf Basis von BSD oder Linux nimmt, gibt es SAMBA (das ist ein Produktname, der Dateidienst heißt SMB) als SMB Server. Eine ZFS Appliance auf Basis von Solaris oder OmniOS bietet alternativ den Solaris eigenen SMB Server. Der ist in ZFS und den OS-Kernel integriert, einfacher und oft schneller als SAMBA, auf jeden Fall mit der besseren Unterstützung für Windows vorherige Version, Windows SMB Gruppen und Windows ntfs artigen ACL Rechten.

Siehe mein HowTo für eine Solarisbasierte NAS/SAN appliance
http://www.napp-it.org/doc/downloads/napp-in-one.pdf


- Ein Backup Tool wie zB Veeam benötige ich nicht mehr, weil ich eine einzelne*.vmdk Datei (bzw. eine gesamte Virtuelle Maschine) wiederherstellen kann, wenn ein Snapshot vorhanden ist.

Habe alles so richtig verstanden?

ESXi Snapshots arbeiten per VM. ZFS Snaps arbeiten per Dateisystem.
Mit ZFS macht man am Einfachsten ein Dateisysten, gibt das per NFS frei und legt dann in ESXi alle VMs bis auf die Storage VM (die liegt auf der lokalen Sata Platte mit vmfs) darauf ab.

Ein ZFS Snapshot sichert dann alle VMs.
Einzelne VMs stellt man dann aus dem Dateisystem wieder her (Windows vorherige Version oder über ein clone). Beliebig viele Vorversionen einer VM sind wiederherstellbar. Es gibt nicht die Beschränkungen auf wenige Kurzzeitsnaps wie bei ESXi.

Man könnte zwar ein ZFs Dateisystem mit NFS oder iSCSI per VM machen, wäre aber das Gegenteil von "keep it simple"
 
Zuletzt bearbeitet:
Könnte man so machen, wäre aber wie ein Auto mit 5 Rädern, unnötig und ultrakompliziert.
Man nimmt natürlich nur eine Storage VM für alle Shares, egal ob iSCSI, NFS oder SMB.

Wenn man als Storage VM etwas auf Basis von BSD oder Linux nimmt, gibt es SAMBA (das ist ein Produktname, der Dateidienst heißt SMB) als SMB Server. Eine ZFS Appliance auf Basis von Solaris oder OmniOS bietet alternativ den Solaris eigenen SMB Server. Der ist in ZFS und den OS-Kernel integriert, einfacher und oft schneller als SAMBA, auf jeden Fall mit der besseren Unterstützung für Windows vorherige Version, Windows SMB Gruppen und Windows ntfs artigen ACL Rechten.

Siehe mein HowTo für eine Solarisbasierte NAS/SAN appliance
http://www.napp-it.org/doc/downloads/napp-in-one.pdf




ESXi Snapshots arbeiten per VM. ZFS Snaps arbeiten per Dateisystem.
Mit ZFS macht man am Einfachsten ein Dateisysten, gibt das per NFS frei und legt dann in ESXi alle VMs bis auf die Storage VM (die liegt auf der lokalen Sata Platte mit vmfs) darauf ab.

Ein ZFS Snapshot sichert dann alle VMs.
Einzelne VMs stellt man dann aus dem Dateisystem wieder her (Windows vorherige Version oder über ein clone). Beliebig viele Vorversionen einer VM sind wiederherstellbar. Es gibt nicht die Beschränkungen auf wenige Kurzzeitsnaps wie bei ESXi.

Man könnte zwar ein ZFs Dateisystem mit NFS oder iSCSI per VM machen, wäre aber das Gegenteil von "keep it simple"

Alles klar. Und Danke für deine Bemühungen :-)

Mit wie viel mehr Speicherplatz - nach regelmäßiger Erstellung von Snapshots - muss man rechnen, wenn ich effektiv ca. 500GB Daten habe (ca. 250GB Fotos & Videos, der Rest Programme etc.)? Sind 1TB zu wenig bei täglichen Snapshots? Ich bin ein ganz normaler User, der ab und an seine Urlaubsbilder bearbeitet, ansonsten mache ich kaum etwas mit dem lokalen Storage.

Ich kenn es nur von TimeMachine Backups, dort wurde der Speicherplatz bei täglichem Backup doch Recht schnell voll. Natürlich kann ich weiterarbeiten und alte Snapshots werden gelöscht.

Mir geht es nur darum, mit wie viel mehr Speicherplatz ich rechnen soll, damit ich ein recht vernünftige Snapshot History habe. Nutzt mir ja kaum was, wenn ich nur 2,3 Snapshots speichern kann :-)
 
Zuletzt bearbeitet:
Die Snapshots verbrauchen nur "zusätzlichen" Speicherplatz, wenn sich Deine Daten ändern. Wenn Du also z.B. 100GB Fotos ablegst, die du zwar anschaust aber nicht bearbeitest, verbraucht ein Snap quasi nichts.

Wenn Du die Fotos zum Beispiel bearbeitest, zum Beispiel aus 10GB Raw Daten (Zeitpunkt Snap1) 100MB JPEG werden, so dass Du die raw-Datei gelöscht hast und dafür eine JPEG entstanden ist (Zeitpunkt Snap2), verbraucht der Snap2 nur die 100MB für die JPEGs. Du gewinnst aber die 10GB nicht zurück, weil diese eben in Snap1 konserviert sind, bis dieser Snapshot Snap1 gelöscht wird.

Der Speicherbedarf hängt also davon ab, wie volatil deine Daten sind, wie oft Du Snaps machst und wie lange du diese dann aufbewahrst.
 
Zuletzt bearbeitet:
Hey bräuchte mal fix Hilfe.

Möchte von Freenas nach Freebsd umsteigen.

Habe es am Freitag erfolgreich geschafft mein Pool zu importieren *yay* :P . Heute gelingt es mir nicht mehr.

Es ist ein Raidz1 Platten sind verschlüsselt.

geli attach -p -k /root/geli.key /dev/ada0p2
geli attach -p -k /root/geli.key /dev/ada1p2
geli attach -p -k /root/geli.key /dev/ada2p2

freebsd% geli status
Name Status Components
ada3p4.eli ACTIVE ada3p4
ada0p2.eli ACTIVE ada0p2
ada1p2.eli ACTIVE ada1p2
ada2p2.eli ACTIVE ada2p2


Was nun ?

Update:

Erledigt :-)
 
Zuletzt bearbeitet:
Hallo ich hätte schon wiedermal eine Frage,

ich habe napp-it neu installiert, nanchdem ich es irgendwie zerschossen habe mit Apache und Owncloudinstallationsversuchen.

Es funktioniert, eigentlich alles wieder super ausser die LLTD Abfarge funktioniert nicht, mein napp-it wird einfach nicht mehr in der Netzwerkumgebung angezeigt.

Napp-it läuft auf nem ESXI ist zu einem AD Server verbunden und auch mit dem AD verbunden.

Ich kann jederzeit über den \\napp.. auf mein napp-it zugreifen, er merkt sich auch alle eingerichteteten Verbindungen, es werden auch alle Userverzeichnisse richtig gemappt.

Ich ahbe mein napp-it auch wie immer eingerichtet, der einzige Unterschied ich habe beide Netzwerkkarten in gea's napp-in-on drinnen gelassen und die E1000 nur deaktiviert. Bis jetzt habe ich sie immer rausgenommen und nur die VMXNET3 drinnen gelassen.

Wie immer Danke für die Hilfe.
 
Zuletzt bearbeitet:
Nutzt hier jemand ZFS mit Freebsd 10.3 ? Habe meinen Pool nun importiert , aber I/O Performance geht überhaupt nicht.

Bekomme in einem RAIDZ1 ( 3x4TB )8MByte/s pro Platte, also so ca. 20-25MByte/s . Das ist ja ein Witz. Hab gerade keine Idee mehr was ich sonst noch troubleshooten könnte.

Mit FreeNAS lief es wesentlich besser , nen Gig Link auszulasten war damit kein Problem.
 
Zuletzt bearbeitet:
Moin,

ich wollte nur mal mitteilen, das ich eine Samsung SM951 NVMe in meinem bar-metal-OmniOS v11 r151019 (vorerst) erfolgreich integriert hab.
Blöderweise hab ich die Karte ausgerechnet in den einzigen PCIe 2.0-Slot meines Mobos X10SLL-F gesteckt.:wall:
Dennoch sieht ein erster dd-Benchmark schonmal gut aus :bigok::
Code:
Memory size: 32726 Megabytes

write 40.96 GB via dd, please wait...
time dd if=/dev/zero of=/test1/dd.tst bs=2048000 count=20000

20000+0 records in
20000+0 records out
40960000000 bytes transferred in 30.961950 secs (1322914114 bytes/sec)

real       30.9
user        0.0
sys         6.6

40.96 GB in 30.9s = 1325.57 MB/s Write

wait 40 s
read 40.96 GB via dd, please wait...
time dd if=/test1/dd.tst of=/dev/null bs=2048000

20000+0 records in
20000+0 records out
40960000000 bytes transferred in 36.192227 secs (1131734729 bytes/sec)

real       36.2
user        0.0
sys         6.3

40.96 GB in 36.2s = 1131.49 MB/s Read

Weitere Tests konnte ich noch nicht durchführen. Die sind wohl aber notwendig, da ich irgendwo irgendwas von möglichen Checksummen-Fehlern gelesen habe.

Zur Vorgehensweise:
- Installation des Treiberpakets vom Repo:
Code:
pkg install nvme
- da gestestete Unterstützung nur für Intel-NVME bis v1.0 of the NVMe spec muß Unterstützung für aktuellere spec (hier nvme v1.1) aktiviert werden:
hier "strict-version=0" aktivieren (d.h. Auskommentierung # entfernen)
Code:
vi /kernel/drv/nvme.conf
- dem System Geräte dieser PCI-Klasse "beibringen"
Code:
update_drv -a -i '"pciclass,010802"' nvme
- conf neu einlesen
Code:
update_drv -vf nvme

@gea
Hattest du nur Intel in ESXi-Passthrough getestet oder auch andere NVME's?
Hattest du schon mit der neuesten ESXi-Version oder mit 5.5 getestet?

bis denne
 
Ich brauche noch einmal eure Hilfe, nachdem das Expiremtn mit den Seagate Archive hinsichtlich Performance "missglückt" ;-) ist möchten wir nun folgenden machen:

Server:
CPU
2x Intel Xeon E5-2630 v4 (Broadwell-EP) 10-Core CPU
128GB RAM (sind noch 8 RAM-Slots frei...)

Langsames Storagepool, für VMs ohne große Performanceanforderungen und langsame Datenablage als RaidZ
4 x HGST Ultrastar He8 8TB, 512e SE, SAS 12Gb/s (HUH728080AL5204/0F23657)

Schneller Storagepool für VMs (durch SSDcache beschleunigt als RaidZ)
4 x HGST Ultrastar C10K1800 512e SED 1.8TB, SAS 12Gb/s (HUC101818CS4200/0B27978)

SSD-Cache (Mirror)
2 x Intel SSD DC P3700 800GB, PCIe 3.0 x4 (SSDPEDMD800G401)

SSD-Only Storagepool für "Ultra Performance"
2 x Micron S650DC 800GB, SAS (MTFDJAK800MBS-2AN1ZABYY)

Insbesondere die Micron sind als Test zu verstehen. Gibt es 'Anmerkungen? Die CPU habe ich gewählt, da der Aufpreis von 200€ auf einen 10 Kerner so gering war.
Angebunden werden 2 Virtualisierungshosts je mit 10Gbit
 
Ich brauche noch einmal eure Hilfe, nachdem das Expiremtn mit den Seagate Archive hinsichtlich Performance "missglückt" ;-) ist ...
Da du ja nun die "alte" HW aus dem Experiment nicht mehr brauchst, erkläre ich mich bereit, diese kostenfrei zu übernehmen! ;)

2x Intel Xeon E5-2630 v4 (Broadwell-EP) 10-Core CPU
Bedenke, daß für manche Anwendungen (single-threaded) eine hohe Taktfrequenz günstig wäre. 3,4GHz<->2,2GHz ist schon ein Unterschied...
Wenn die Kiste als reines Storage laufen soll, dann weiß ich nicht, was besser ist - mal abwarten, was andere schreiben...

128GB RAM (sind noch 8 RAM-Slots frei...)
Viel RAM ist immer gut!

Langsames Storagepool, für VMs ohne große Performanceanforderungen und langsame Datenablage als RaidZ
4 x HGST Ultrastar He8 8TB, 512e SE, SAS 12Gb/s (HUH728080AL5204/0F23657)
Bei Raidz1 denke ich sind 5 von den Teilen cleverer.

Schneller Storagepool für VMs (durch SSDcache beschleunigt als RaidZ)
4 x HGST Ultrastar C10K1800 512e SED 1.8TB, SAS 12Gb/s (HUC101818CS4200/0B27978)
wie oben - nimm 5

SSD-Cache (Mirror)
2 x Intel SSD DC P3700 800GB, PCIe 3.0 x4 (SSDPEDMD800G401)
Als L2ARC zu schnell, als ZIL zu groß...

SSD-Only Storagepool für "Ultra Performance"
2 x Micron S650DC 800GB, SAS (MTFDJAK800MBS-2AN1ZABYY)
Warum die? Teuer und nicht mal NVMe...

Ich glaub, die SSD/Cache-Konfiguration muss nochmal überdacht werden.
Ich hab ja ähnliche Wünsche (aber nicht das Budget) und hoffe ebenso auf gute Tipps.
 
Ich würde notfalls auch die Entsorgung deiner missglückten Teile übernehmen ^^ ... umweltgerecht natürlich
... nur Spass


aber hab ich verpasst wo dein problem lag
 
Zuletzt bearbeitet:
Da du ja nun die "alte" HW aus dem Experiment nicht mehr brauchst, erkläre ich mich bereit, diese kostenfrei zu übernehmen! ;)
*lach* - die 8x8TB werden als Backup Storage gebraucht, ich habe diese nur für das Experiment ZFS genutzt bevor das Ding in den Produktivbetrieb ging.

Bedenke, daß für manche Anwendungen (single-threaded) eine hohe Taktfrequenz günstig wäre. 3,4GHz<->2,2GHz ist schon ein Unterschied...
Wenn die Kiste als reines Storage laufen soll, dann weiß ich nicht, was besser ist - mal abwarten, was andere schreiben...
Ich auch nicht, Preilich fand ich das nur ganz gut und nehme an, dass die Komprimierung (LZ4) Multithreaded ist.


Bei Raidz1 denke ich sind 5 von den Teilen cleverer.
ich wollte mit den 7.200er Festplatten einmal testen wie es läuft, entweder ein RaidZ1 oder ein Striped Mirror - ich weiß nicht wie es bei ZFS heißt, aber möglich ist das ja mit

Code:
zpool create -f -m <mount> <pool> mirror <id1> <id2> mirror <id3> <id4>

Als L2ARC zu schnell, als ZIL zu groß...
Zum Verständnis - kannst Du das bitte noch einmal ausführen? Warum hilft hier nicht viel? Die Entdausbaustufe sieht noch 4 langsame 7.2er vor, sowie 8 schnelle 1,8TB mit 10k.



Ich glaub, die SSD/Cache-Konfiguration muss nochmal überdacht werden.
Ich hab ja ähnliche Wünsche (aber nicht das Budget) und hoffe ebenso auf gute Tipps.


Die Microns mit 5 DWPD sind die günstigsten verfügbaren momentan.... daher viel die Wahl auf die. Zunächst nur 2 stück, da wir damit testen wollen.

- - - Updated - - -

Ich würde notfalls auch die Entsorgung deiner missglückten Teile übernehmen ^^ ... umweltgerecht natürlich
... nur Spass


aber hab ich verpasst wo dein problem lag

:-) :-) :-)

Performance im Rand Writes waren mit den Archive-Platten ein Problem... siehe hieR:
http://www.hardwareluxx.de/community/f101/zfs-stammtisch-570052-271.html#post24630440
 
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