Archiv/Backup Speicher Designempfehlung

[coolblue81]

Hallo,
ich bin neu hier und auch neu in der ZFS Welt. Habe mich aber bereits in vielen Dokus über das Thema eingelesen. Als letzte Verifikation wollte ich in der nächsten Zeit hier einige Ideen posten und eure Meinung und natürlich Tipps dazu hören.

Ich würde gern fürs Rechenzentrum (geht um Geschäftsdaten!) eine FreeNAS Appliance als Backup-Ziel zusammenstellen.

Anforderungen:
- Zugriff via iSCSI/NFS oder CIFS vom Backup Server aus. Bisher habe ich immer iSCSI bevorzugt um ein NTFS Filesystem, passend zur Windows Welt zu bekommen. Bin da aber offen.
- Genug I/O bzw. Durchsatz für Backup-Schreiboperationen (Gigabit mit 100MB/s sollte reichen)
- Zugriff via FTP/SFTP/CIFS/NFS für fremde (Offsite) Backups
- ggf. getrennter zPool für Archiv-Daten (welcher dann auf den Backup zPool gesichert wird)
- Replikationsziel für Produktions FreeNAS/TrueNAS Appliance, für "schnelle" Storage basierte Backups/Restore Vorgänge, falls mal der zPool im Produktivsystem crashed.

Umgebung:
- VMware ESXi 6.0
- Veeam Backup & Replication in einer Windows VM

Vorschlag:
- Supermicro Barebone Server mit genug Festplatteneinschübe und LSI IT-Mode Controller
- "kosteneffiziente" Seagate Archiv HDD 3,5" mit 6TB mit 3 Jahre Garantie
- Dual-CPU ?
- 64 GB ECC RAM (mehr?)
- Kompression
- Deduplication
- zVol mit RAIDz2 mit 6 HDDs für bis zu 2 Plattenausfälle
- Enterprise SSD als ZIL SLOG
- "Consumer" SSD als L2ARC (notwendig?)
- SAS oder SATA Version der jeweiligen HDDs/SSDs ?

Fragen & Anmerkungen:
a) Deduplikation
Ich weiß das Dedup bei ZFS viel RAM braucht. Da das System nicht besonders "schnell" sein muss, kann man da auch eine L2ARC SSD nutzen, um mehr Dedup Indizes zu halten oder MUSS alles im RAM stattfinden?

Warum Dedup?
Wenn ich mit Veeam auf das System die Backups speichere, kann ich Veeam anweisen, dies ohne Kompression zu tun (Dedupe friendly heißt die Option). Wenn parallel das Hauptsystem via ZFS Replication auf das Backupsystem gespiegelt wird, liegen die Daten 2x vor und sollten damit 2:1 dedupliziert werden können. Plus natürlich noch die ganzen zusätzlichen Backuptage, wo es ja auch überschneidungen beim Fullbackup gibt.

b) RAIDz2
RAIDz2 ist beim schreiben nicht schneller als 1 Festplatte pro zVol, wenn ich das richtig verstanden habe. Entsprechend schlage ich eine entsprechende SSD als SLOG vor. Reicht das für obige Anforderungen?

c) Statistiken in FreeNAS
Kann man bezüglich ZIL, L2ARC und L1ARC RAM Dimensionierung auch klein anfangen und dann nach einer Weile dann im FreeNAS sehen, was man nachrüsten sollte für eine bessere Performance? Hab irgendwo gelesen das das möglich sei oder war das nur bei Nexenta so?

 

[MrToddsFriends]

- "Consumer" SSD als ZIL

Keine gute Idee.
https://forums.freenas.org/index.php?threads/zfs-primer.38927/
https://forums.freenas.org/index.php?threads/some-insights-into-slog-zil-with-zfs-on-freenas.13633/

 

[coolblue81]

Ok. Danke! Ich denke ich habe es verstanden. Auf die SLOG SSD wird nur geschrieben und nur im Notfall gelesen. Entsprechend wäre so eine SSD schnell defekt und soweit ich weiß bricht die Geschwindigkeit der günstigen SSDs beim schreiben auch schnell ein. Da habe ich nicht mehr dran gedacht.

 

[snaptec]

Günstige ssds im Sinne von 850evo brechen nicht ein. Werden bei den vielen Zugriffen aber nicht lange halten. Such mal nach tbw werten.

Schnelle restores und dann nur gbit? Über welche Datenmengen reden wir hier?
Wenn iscsi und Performance gewünscht ist dann nur mirrored vdevs und pool nicht über 50% füllen.
Mit nfs ist das nicht so kritisch.

Dedup bei Backup ist ok, bzgl Performance schließt sich das mit nur 64gb RAM aber aus.
Kompression ist immer an!

L2arc ist die Frage, da sehr viel geschrieben wird aber wenig gelesen im Normalfall könnte die sinnhaftigkeit nicht gegeben sein.

Für Backups 24/7 sata habe ich gute Erfahrung mit gemacht. Hgst als Beispiel ist gut.

Dedup macht eigentlich Sinn bei deinem anwendungsfall, was Performance angeht könnte es aber kritisch werden.

Wenn ich das richtig sehe sollen es "nur" 6x6tb im raidz2 werden?
Sprich ca 22tb brutto, bei iscsi 11tb netto nutzbar?
Dann kannst bei 64gb dedup auch austesten. Gbit solltest mit ausgelastet kriegen.

Aber dennoch, wenn iscsi und bissl Performance solltest du mirrors bevorzugen. Sprich ca 16-17tb brutto und für iscsi dann 8tb netto bei 50%

Zwar etwas durcheinander geschrieben, hoffe aber es hilft dir.


Gesendet von iPhone mit Tapatalk

 

[coolblue81]

Hallo Snaptec,

danke dir für deine ausführliche Antwort.

Bezüglich SSDs schau ich mal nach den TBW Werten und such mal was raus.

Die Nutzung des L2ARCs bezog sich auf die Dedup Indizes. Oder nutzt ZFS ausschließlich das RAM um diese zu halten. Was passiert wenn die 64 GB "voll" sind, weil zu viele Terrabytes an Dedup Daten verwaltet werden müssen? Stellt das System dann seinen Dienst ein.. oder wird irgendwo zwischen geswapped?

raidz2:
Gedacht waren erstmal 6 Platten + 1-2 Spares um das erste raidz2 zu erstellen. 6TB liegen im P/L. Soviel brauch ich insg. (4 * 6 = 24tb) überhaupt (noch) nicht, erst recht nicht weil ja dedupliziert wird. Das könnte sich aber in den nächsten 5 Jahren (geplante Betriebszeit) schlagartig ändern.

Das Supermicro Board ist ein Dual-Core und bietet Platz für 512GB+ RAM.. die ich bei wachsendem Datenvolumen kontinuiierlich erweitern kann. 64GB ist erstmal der Start um die Kosten niedrig zu halten.

Interessant das du für Backup/Archiv ebenfalls Mirrors empfiehlst.. genau wie andere dies für die Produktiv-NAS tun. Hat RaidZ(x) überhaupt irgendeine Berechtigung?

Zur Auswahl (bei 6 HDDs) stehen ja:
1) RaidZ2 4x Nutzdaten, 2x Parität > I/O Speed = 1 HDD (langsam, ich weiß.. aber wie langsam in der gefühlten Praxis mit SLOG?)
2) Mirror 3x Nutzdaten, 3x Mirror > I/O Speed = 3 HDDs (korrekt?)
3) 3-Fach Mirror 2x Nutzdaten, 4x Mirror > I/O Speed = 2 HDDs

Es wird vorrausschtlich Backups geben, welche > 1 Jahr zurück liegen, daher wollte ich hier ein wenig auf "Sicherheit" setzen, ohne jedoch gleich das Geld in die Hand nehmen zu müssen, die Backups nochmalig auf nen zweites Storage zu replizieren. (Kosten / Nutzen Faktor)
Ich denke da kommt nur 1 oder 3 in Frage, oder?

Performance / Datenmenge:
Produktiv sind aktuell 3 TB an Daten. Tendenz (+1TB pro Jahr) steigend. Hinzu kommen noch externe Backups (die müssen aber nicht schnell zurück, da begrenzt das Internet die Geschwindigkeit)

Das Storage wird 10Gbit Interfaces haben. Die Switche haben das aber noch nicht. Kommt später.

 

[MrToddsFriends]

Ok. Danke! Ich denke ich habe es verstanden. Auf die SLOG SSD wird nur geschrieben und nur im Notfall gelesen. Entsprechend wäre so eine SSD schnell defekt und soweit ich weiß bricht die Geschwindigkeit der günstigen SSDs beim schreiben auch schnell ein. Da habe ich nicht mehr dran gedacht.

Worauf ich mit den beiden Links hinweisen wollte, war die Empfehlung von SSDs mit speziellen Pufferkondensatoren für SLOG devices, welche sicherstellen, dass es bei einem Ausfall der Stromversorgung zu keinem Datenverlust kommt.

O.k., sollte im Rechenzentrum nicht passieren, aber im Fall der Fälle wäre eine Unterbrechung der Erreichbarkeit sicher leichter zu verschmerzen als ein Datenverlust.

 

[coolblue81]

Habe mal geschaut und folgendes hat sich heraus kristallisiert:
- Samsung SSD SM863 240/480GB SATA mit TBW 1.54PB / 3.08PB und 20K / 26K IOPS für 160 € / 290 €
oder
- SanDisk Optimus Ultra 150GB SAS mit TBW 6.843PB und 40 K IOPS für 370 €

Es gibt noch eine SanDisk mit 200 GB und 16 PB TBW für 410 €

Aufgrund dessen das SSDs rapide günstiger und besser werden, würde ich die Samsung SM863 240 GB mit 1.54PB für 160 € im Backup Storage am sinnvollsten sehen.

Beide Varianten haben einen Power-Loss Schutz.

 

[MrToddsFriends]

c) Statistiken in FreeNAS
Kann man bezüglich ZIL, L2ARC und L1ARC RAM Dimensionierung auch klein anfangen und dann nach einer Weile dann im FreeNAS sehen, was man nachrüsten sollte für eine bessere Performance? Hab irgendwo gelesen das das möglich sei oder war das nur bei Nexenta so?

Um auf die eingangs gestellte Frage zurück zu kommen:

Wie im ZFS Primer beschrieben kann zilstat dabei helfen, die Frage zu klären, ob ein SLOG device Vorteile bringen würde. Letztendlich kommt dadurch eine zusätzliche potentielle Fehlerquelle ins Spiel, auf die man ohne echten Bedarf besser verzichtet.

Beim ARC/L2ARC helfen die Tools arcstat.py und arc_summary.py, sowie das Reporting an der FreeNAS GUI.
http://doc.freenas.org/9.10/reporting.html
Sowie auch wieder der ZFS Primer: "RAM is always faster than disks, so always add as much RAM as possible before determining if the system would benefit from a L2ARC device."

 

[snaptec]

Nur kurz:
Für backup macht raidz2/3 natürlich mehr Sinn als mirrors.
Die mirror Empfehlung geht auf i/o lastige Sachen, vm Speicher etc.. Und erst recht bei Nutzung von iscsi.

Wenn wirklich nur Backup und am besten nicht per iscsi dann aufjedenfall raidz2/3.
das hab ich wohl doof formuliert.


Gesendet von iPhone mit Tapatalk

 

[coolblue81]

OK. Danke für die beiden letzten Antworten. Wenn Zeit ist stell ich mal was konkretes zusammen.