This is the old XigmaNAS forum in read only mode,
it will taken offline by the end of march 2021!
I like to aks Users and Admins to rewrite/take over important post from here into the new fresh main forum!
Its not possible for us to export from here and import it to the main forum!
Hallo zusammen! Dies ist mein erstes Posting hier. Bitte seid nett zu mir!
Ich möchte einen kleinen Fileserver/NAS für 3 Clients aus vorhandenen Komponenten zusammenstellen. Das sind:
- 8x 4TB 3,5" HDDs
- Mainboard mit integrierter Intel Celeron J3160, 4x 1.60GHz, 2MB Cache CPU, Biostar J3160MD, 1x Gigabit LAN
- zusätzlich 1x Gigabit LAN Erweiterungskarte
- 16 GB DDR3 RAM, NON ECC
- und einem etwas älteren Areca ARC-1220 RAID Controller mit 8x SATA II
- das Ganze in einem entprechenden Tower Gehäuse mit 8x 3,5" HDD Einschüben
- evtl. eine 250GB SSD als L2ARC Cache
Meine Frage ist wie ich das Ganze am besten unter NAS4Free aufsetze und konfiguriere. Auf dem Server liegen vorwiegend RAW, TIF, PSD und JPG Bilddateien. Ziel ist es für 3 (Apple MAC) Clients einen zusammenhängenden riesen Speicher zur Verfügung zu stellen auf dem sowohl das Archiv, als auch die laufenden Daten liegen. Toll wäre, wäre der HDD Speicher auch in Zukunft durch Austausch einzelner Platten erweiterbar. Ein Backup der Daten soll zusätzlich auf externe HDDs gemacht werden. Die Clients greifen über Gigabit LAN vorwiegend zur gleichen Zeit auf einige wenige aktuelle Dateien zu. Die RAW Dateien werden mit Capture One Pro entwickelt und in Photoshop weiter verarbeitet.
Gedacht habe ich ursprünglich an eine ZFS Konfiguration mit RAID-Z1 oder Z2. Dabei soll die RAID Karte nur der 8x SATA Anschlüsse wegen gebraucht werden und die Rechenarbeit die CPU erledigen. An ZFS habe ich vorwiegend wegen der Datensicherheit gedacht. Deduplikation ist nicht nötig.
Fragen:
1. Ist der NON ECC RAM ein wirkliches Problem für ZFS in dieser Konfiguration und sind 16GB zu wenig für 8x4TB HDDs ohne Deduplikation?
2. Sollte ich vielleicht doch besser den RAID Kontroller als solchen in RAID 5 oder 6 nutzen und RAID-Z außen vor lassen?
3. Ist die CPU für eine 8x 4TB RAID-Z2 Konfiguartion leistungsfähig genug?
4. Würde ein zusätzlicher L2ARC SSD Cache mit 250GB (500 Gb/s Lesen/Schreiben) an dem SATA III Port des Mainboards wohl spürbar mehr Performance bringen?
Ich habe bisher leider keine Erfahrung in dem Bereich, deshalb erhoffe ich mir Erfahrungen von Euch. Danke!
1. was hilft es Redundanz bezüglich Festplattenausfall zu haben, wenn alle Daten nachher korrupt sind. Ein Fakir benutzt auf seinem Nagelbett auch keinen Airbag.
2. wenn du absolut nichts kaufen willst, wär das besser, mit allen Nachteilen die dazugehören (Controllerabhängigkeit, Treiberproblem, kein tolles ZFS, ewig lange Initialisierung am Anfang bei der Plattenkapazität, und ebenso ewige Rebuilds im Fehlerfall, usw.)
3. Reine Geschmackssache würd ich sagen, der eine fährt Fiat Punto und ist zufrieden, der andere hat als Untergrenze nen Sechszylinder.... Zweckdienlich wirds sein, Spaß ist was anderes
4. 3 Clients, diese Hardware, nein wozu, dient höchstens als zusätzliche Fehlerquelle
Hoffe ich war nett genug Schönes Wochenende!
SuperMicro SuperServer SYS-5019C-M 1U, Intel C246, Intel Xeon E-2136, 64GB Kingston Server Premier DDR4 2666 ECC, 4x8TB Seagate Ironwolf HDD @ZFS1, Intel 82599EN 10GbE SFP+. VMWare ESXi 6.7U3b, Intel Cannon Lake AHCI passthrough to XigmaNAS 12.1.0.4.7091 VM.
ZFS und Non-ECC-RAM schließen sich definitiv aus!! Ich empfehle die Posts von Princo hier zu diesem Thema zu lesen.
defcon999
Für ein produktives System im Firmenumfeld würde ich das unterstützen. Ich habe das aber ein paar Jahre ohne wahrnehmbare Probleme so gemacht. Hab dann aber auf ein Servermainboard umgestellt.
=> mit der Hardware eher Software-Raid, 16 GB dürften dann auch schon luxoriös sein.
Hardware-Raid würde ich nicht machen ohne Reserve-Adapter.
Zu 4. L2ARC benötigt selbst auch RAM, mit 8x4TB HDDS und "nur" 16GB RAM bist Du schon hart an der Grenze
Zu 2. Hardware RAID hat gegenüber SiftRAID oder ZFS einige Nachteile, der wichtigste ist wohl ,dass Du mit Software RAID hardwareunabhängig bist. Wenn der Controller defekt ist, steckst Du Deine Platten einfach an einen anderen Controller und arbeitest weiter. Beim Hardware RAID musst Du wieder exakt den gleichen Controller verwenden.
NAS 1: Milchkuh: Asrock C2550D4I, Intel Avoton C2550 Quad-Core, 16GB DDR3 ECC, 5x3TB WD Red RaidZ1 +60 GB SSD for ZIL/L2ARC, APC-Back UPS 350 CS, NAS4Free 11.0.0.4.3460 embedded NAS 2: Backup: HP N54L, 8 GB ECC RAM, 4x4 TB WD Red, RaidZ1, NAS4Free 11.0.0.4.3460 embedded NAS 3: Office: HP N54L, 8 GB ECC RAM, 2x3 TB WD Red, ZFS Mirror, APC-Back UPS 350 CS NAS4Free 11.0.0.4.3460 embedded
Für ein produktives System im Firmenumfeld würde ich das unterstützen. Ich habe das aber ein paar Jahre ohne wahrnehmbare Probleme so gemacht. Hab dann aber auf ein Servermainboard umgestellt.
Hmmm... nur weil es bei DIR keine Probleme gab, ändert das aber nichts an der Tatsache, dass für ein "sicheres" ZFS ECC-RAM zwingend erwartet wird. Ein NAS macht - aus meiner Sicht - nur Sinn, wenn die gespeicherten Daten auch unverändert erhalten bleiben.
Es gibt ganz viele Abhandlungen über den Themenkomplex "ZFS, ECC und Non-ECC-RAM" ... und auch wenn mein Englisch nicht so gut ist, um Alles haarklein zu verstehen, so ist das Fazit eindeutig!
Eben, bei der Menge an Terabytes werden wohl einigermaßen wichtige Dinge teilweise über lange Zeit aufbewahrt. Das größte Problem sind dann die "nicht wahrnehmbaren Probleme", der schleichende Tod der sich über die Daten entfalten könnte. Das ganze sichert man dann regelmäßig mit auf das Backup, in schon kaputtem Zustand. Einfach nur ärgerlich, und schade um die Daten, die mit rund 250 Euro (dem Preis von 1-2 Festplatten) mit einem vernünftigen Board mit Speicher und CPU noch ewig leben würden.
SuperMicro SuperServer SYS-5019C-M 1U, Intel C246, Intel Xeon E-2136, 64GB Kingston Server Premier DDR4 2666 ECC, 4x8TB Seagate Ironwolf HDD @ZFS1, Intel 82599EN 10GbE SFP+. VMWare ESXi 6.7U3b, Intel Cannon Lake AHCI passthrough to XigmaNAS 12.1.0.4.7091 VM.
Ist das "Bit Rot" Problem mit einem Software oder Hardware RAID ohne ZFS eigentlich ein wirkliches Problem, oder nur akademischer Natur? Es handelt sich hier fast ausschließlich um Bilddaten.
Die Vorposter haben dich ja schon auf die relevanten Dinge hingewiesen.
Zusammenfassend und ergänzend gebe ich gerne meinen eigenen Senf dazu:
ECC-fähige Hardware halte ich tatsächlich für sehr wichtig, gerade wenn es um die Speicherung unersetzlicher Daten geht. An dieser Stelle würde man tatsächlich am falschen Ende sparen, wenn man etwas anderes einsetzt.
Gestatte mir bitte noch ein paar weitere Hinweise:
Du möchtest einen "zusammenhängenden riesen Speicher" für drei Clients bereitstellen. Dazu erwähnst du, daß du dort ein Archiv und aktuelle Bearbeitungsdaten unterbringen möchtest.
Das Ganze soll mit 8x4TB Festplatten im RaidZ1 oder RaidZ2 umgesetzt werden, und die Datensicherung soll mittels externer Festplatten stattfinden.
Dann gibst du noch den Hinweis, daß du keine Erfahrung in dem Bereich hast.
Nun, eine Datenmenge von ~28TB ist ein ganz schöner Hieb, und der administrative Umgang damit, ist durchaus anspruchsvoll.
Es ist nicht damit getan, daß man seinen Rechner "eben mal für ein paar Tage anläßt", damit irgendwelche Kopieraktionen stattfinden können. So ein riesiges Array ist einfach schrecklich unflexibel.
Leider weiß ich nicht, welche Datenmengen bei dir im Ist-Zustand existieren, aber ich versuche mal, dir eine Lösung zu skizzieren, welche leicht zu handhaben, und sehr flexibel ist.
#####
Ich würde zwei Systeme einsetzen. Einen Datenserver, und einen Backup Server.
Der Datenserver (und der Backup-Server) wird mit zwei ZFS-Pools ausgestattet: Archiv und Daten.
Der Archiv-Pool im Datenserver wird immer nur Read-Only gemounted.
Beide Pools werden auch im Backup-Server vorgehalten.
Der Backup-Server befindet sich in einem anderen Brandabschnitt.
Der Backup-Server kann sich auch an einem anderen Ort befinden. Das Backup kann per Netz oder einer Transportfestplatte realisiert werden.
Einmal im Jahr werden die relevanten Daten ins Archiv verschoben.
Das Backup wird mit Hilfe der ZFS-Kommandos "send/receive" durchgeführt.
#####
Das wäre die theoretische Vorgehensweise.
Der Kniff liegt aber in der praktischen Umsetzung.
Ich gehe einfach mal davon aus, daß es sich um ein System für Fotografen und Bildbearbeiter handelt.
Wenn man das jetzt so organisiert, daß man ein Archiv der vergangenen Jahre im Read-Only-Modus, und dazu noch einen aktuellen Arbeits-Bereich hat, dann kann man das recht simpel umsetzen. Dabei gelten folgende Prämissen:
Der Archiv-Bereich wird stetig anwachsen. Es wird dort aber nichts gelöscht, oder verändert. Einmal im Jahr wird er mit zusätzlichen Daten befüllt, und muß dafür ggfs. vorher aufgestockt werden. Der nötige Zuwachs läßt sich aber vorher exakt ermitteln, wenn man sich die neu zu archivierenden Daten anschaut.
Der Arbeits-Bereich (Daten) hat eine andere Charakteristik. Er wird sich, übers Jahr gesehen, füllen, aber dann wieder auf Null fallen, wenn die Daten archiviert wurden. Dieser Bereich muß nur dann erweitert werden, wenn mehr Aufträge reinkommen, oder neue Kameras mit höheren Pixelzahlen eingesetzt werden (größere Datenmenge).
Jetzt kommt der eigentliche Clou an der Sache:
Das Archiv wird zwar sehr groß werden, aber es muß nicht ständig gebackupped werden (nur einmal im Jahr).
Es gibt spezielle Festplatten, genau für diesen Einsatz, z.B. die Archive-Festplatten von Seagate.
Du könntest also z.B. dein aktuelles Archiv auf ein RaidZ-Mirror aus Archive-Festplatten kopieren, dieses Archive dann auf eine einzelne Archive-Festplatte kopieren, und das Mirror in den Safe legen. Die Kopie von dem Mirror packst du in den Arbeits-Server, und damit arbeitest du.
Einmal im Jahr holst du das Archive-Mirror aus dem Safe, verschiebst die abgeschlossenen Arbeitsdaten drauf, und machst einen Abgleich auf die Kopie des Archives, mit dem du dann wieder ein Jahr weiter arbeitest.
Deinen normalen Datenbereich synchronisierst du ganz normal jeden Tag mit dem Backup-Server (per zfs send/receive).
Hhm, das ist jetzt schon etwas detailliert, aber evtl. erkennst du dennoch die Vorteile dieser Vorgehensweise.
Was ist der Nachteil dieser Methode?
Die brauchst ein zweites System.
Was ist der Vorteil dieser Methode?
Du hast ein vollwertiges Ersatzsystem.
Da hast volle ZFS-Integrität in allen Bereichen, also auch im Backup.
Du mußt nur so viele Festplatten einsetzen, wie du tatsächlich benötigst.
Du kannst beim späteren Ausbau von fallenden Preisen und technischen Weiterentwicklungen profitieren.
Dein System läßt sich viel leichter skalieren.
Deine Backup-Zeiten reduzieren sich auf ein Minimum.
Du hast beim Backup eine immens hohe Flexibilität.
Was sind die Nachteile deiner ursprünglichen Idee?
Ein riesiger Pool wird sehr unhandlich, wenn er gefüllt wird.
Erweiterungen des Pools werden entweder sehr zeitaufwändig, oder riskant.
Datensicherungen auf externen Festplatten klingen zwar sehr einfach, sind in der täglichen Praxis aber lästig in der Handhabung. Zudem stellen sie eine potentielle Gefahr für die gesicherten Daten dar, besonders wenn da auf einmal USB-Anschlüsse und nicht-ZFS-Dateisysteme mit ins Spiel kommen.
Die hast zwar eine riesige Kapazität, aber eben auch sehr viel mehr Festplatten, als du anfangs tatsächlich brauchst. Da sich sich aber alle Festplatten im Echtbetrieb befinden, rattern dort auch die Betriebsstunden für alle Platten gleichermaßen hoch.
Hättest du einen Teil der Platten aber in einem eigenen Backup-System untergebracht, würden die nur während des Backups laufen, und dadurch viel länger halten.
Noch ein paar Anmerkungen zur Erweiterung von ZFS-Systemen:
Es ist richtig, daß man ein ZFS-System entweder durch Hinzufügen weiterer Festplatten, oder durch Austausch bestehender Festplatten durch solche mit höherer Kapazität erweitern kann.
Beide Methoden haben aber gewaltige Nachteile, und man muß schon sehr verzweifelt (oder sehr unwissend) sein, wenn man seinen Pool auf diese Weise erweitert.
Ich rate daher DRINGEND davon ab!
Die beste, schnellste und sicherste Methode ist tatsächlich das Umkopieren der Daten auf einen größeren Pool. Mein o.a. Vorschlag beinhaltet genau diese Möglichkeit, da du dafür das Backup-System prima einsetzen kannst.
Ich habe hier nicht alle weiteren Vorteile dieser Methode aufgezählt, da der Artikel sonst noch viel länger und komplexer geworden wäre, aber ich hoffe, daß dir meine Ausführungen bei der Planung deines Systems weiterhelfen.
Ich photographiere selbst viel, und bin sehr froh, daß ich mich für ein ZFS-System entschieden habe, denn gerade für Fotografen ist es das ideale Speichersystem.
Grüße
Princo
Meine Antworten beziehen sich immer auf die englischsprachige GUI. ECC-RAM ist Pflicht beim Einsatz von ZFS.
Princo wrote:Noch ein paar Anmerkungen zur Erweiterung von ZFS-Systemen:
Es ist richtig, daß man ein ZFS-System entweder durch Hinzufügen weiterer Festplatten, oder durch Austausch bestehender Festplatten durch solche mit höherer Kapazität erweitern kann.
Beide Methoden haben aber gewaltige Nachteile, und man muß schon sehr verzweifelt (oder sehr unwissend) sein, wenn man seinen Pool auf diese Weise erweitert.
Ich rate daher DRINGEND davon ab!
Die erste Aussage ist Falsch!
Ein ZFS Pool kann im ggs. zu Hardwareraids (OCE = Online Capacity Expansion) nicht durch das Hinzufügen weiterer HDDs erweitert werden, sondern nur durch das Hinzufügen weiterer VDEVs. Ein VDEV kann natürlich aus einer einzelnen Platte bestehen, ABER (!!!!) - Der Pool bekommt den Redundanzlevel von dem VDEV mt dem geringsten Redundanzlevel, stirbt ein VDEV ist der Pool Geschichte.
Beispiel: du hast ein Pool mit einem VDEV Raidz3 und fügst ein VDEV aus einer HDD zum Pool hinzu und diese Platte stirbt, nützt das Raidz3 auf dem anderen VDEV genau Nichts.
Hallo,
noch ein Problem bei der vorgeschlagenen Lösung:
Seagate und co reden von ca 3 Monaten bei ihren HDDs bevor Datenverlust eintritt, wenn diese ohne Strom im Regal liegen. Man dürfte also die Platten nicht ausbauen, sondern sie müssen mit laufen.
Ich wüßte jetzt nicht, was an meiner Aussage falsch ist, denn in deinen weiteren (guten und richtigen) Ausführungen, schreibst du du ja selber, daß man einen Pool auch mit einer einzelnen Festplatte erweitern kann
Es ist richtig, daß man eine Erweiterung auf diese Art möglichst mit dem gleichen Redundanzlevel des bereits bestehenden Pools machen sollte.
Es gibt durchaus Einsatzszenarien, bei denen diese Erweiterungsmethode sinnvoll ist, aber diese sehe ich hier nicht gegeben, und deshalb habe ich von der Methode abgeraten, und auch nicht näher ausgeführt.
@Eldor1 und @helli
Wahrscheinlich sind Meldungen wie diese oder diese gemeint, und ich ... spare mir jetzt einen Kommentar dazu.
Grüße
Princo
Meine Antworten beziehen sich immer auf die englischsprachige GUI. ECC-RAM ist Pflicht beim Einsatz von ZFS.
http://www.seagate.com/www-content/prod ... 04071b.pdf
Seite 16
2.10.2 Storage
Maximum storage periods are 180 days within original unopened Seagate shipping package or 60 days unpackaged within the
defined non-operating limits (refer to environmental section in this manual). Storage can be extended to 1 year packaged or
unpackaged under optimal environmental conditions (25°C, <40% relative humidity non-condensing, and non-corrosive
environment). During any storage period the drive non-operational temperature, humidity, wet bulb, atmospheric conditions,
shock, vibration, magnetic and electrical field specifications should be followed.
ich habe selbst ein paar alte Platten, die einige Jahre ohne Strom rumlagen ohne Probleme wiederbeleben können.
Jedoch wichtige Daten sind bei mir mittlerweile auf dem NAS und BackupNAS gespeichert und regelmässig wird gescrubbt...
NAS 1: Milchkuh: Asrock C2550D4I, Intel Avoton C2550 Quad-Core, 16GB DDR3 ECC, 5x3TB WD Red RaidZ1 +60 GB SSD for ZIL/L2ARC, APC-Back UPS 350 CS, NAS4Free 11.0.0.4.3460 embedded NAS 2: Backup: HP N54L, 8 GB ECC RAM, 4x4 TB WD Red, RaidZ1, NAS4Free 11.0.0.4.3460 embedded NAS 3: Office: HP N54L, 8 GB ECC RAM, 2x3 TB WD Red, ZFS Mirror, APC-Back UPS 350 CS NAS4Free 11.0.0.4.3460 embedded
Ja es KANN gut gehen. Ein "vielleicht" scheint mir aber im vorliegenden Fall auch zu gefährlich und würde ebenfalls zu 2 ständig laufenden Servern raten. So long!
Eldor1 wrote:Ja es KANN gut gehen. Ein "vielleicht" scheint mir aber im vorliegenden Fall auch zu gefährlich und würde ebenfalls zu 2 ständig laufenden Servern raten. So long!
Gesendet von meinem HUAWEI GRA-L09 mit Tapatalk
Wieso muss das Backupsys ständig laufen?
Meines Läuft nur zu den Zeiten, wo das Backup gezogen wird - kompett automatisiert.
Ich wüßte jetzt nicht, was an meiner Aussage falsch ist, denn in deinen weiteren (guten und richtigen) Ausführungen, schreibst du du ja selber, daß man einen Pool auch mit einer einzelnen Festplatte erweitern kann ....
Grüße
Princo
Weil man im Allgemeinen im Zusammenhang einer Erweiterung davon ausgeht ein bestehendes Raidvolume (bei ZFS ist das ein VDEV) erweitern zu können.
Das ein VDEV auch aus einer einzelnen Festplatte bestehen kann ist zwar richtig aber pratisch nur eine theoretische Möglichkeit ohne Relevanz, da diese die Verwendung von ZFS quasi ad Adsurdum führt. Ohne Redundanz werden wichtige Features von ZFS nicht genutzt.
Du möchtest da eine beachtliche Datenmenge verwalten. Diese Daten sollen offensichtlich kommerziell genutzt werden. Ggf. lebst du und andere sogar davon. Das ist erstmal die Ausgangssituation.
Wie viel geld zur Verfügung steht ist unklar. Ich vermute mal anhand er Hardware-Auswahl, dass gespart werden soll.
Zu diesem Zweck dann so einfache PC Technik einzusetzen halte ich für gewagt. Allein die Frage, wie lange es wohl dauert über die verfügbaren Schnittstellen (Gigabit-LAN, S-ATA) diese Datenmasse überhaupt auf die Internen Platten zu bekommen ist beträchtlich. Ok, man macht das zu beginn nur ein Mal.
Im allgemeinen würde ich bei derlei Anforderungen eher zu "echter" Servertechnik tendieren. Auch diese bekommt man sofern man bereit ist die Daten auf mehrere Rechner zu verteilen inzwischen relativ günstig. Der HP Microserver sei hier als Beispiel erwähnt. Aber auch DELL hat da inzwischen entsprechendes am "start".
Es ist nunmal so, dass eine vergleichsweise schwache CPU wie von dir gewählt mit der Aufgabe wohl arg zu kämpfen hat, so große Datenmengen im Griff zu halten, auch wenn es sich bei der größeren Menge nur um gelegentlich genutzten Storage handelt.
Auch diese Daten müssen gelegentlich mal ins Backup!
Und da ist man schon beim nächsten Thema. Für das Backup könnte sich hier evtl. schon ein LTO Bandstreamer lohnen. Wenn nicht alles für das Finanzamt NEU gekauft werden muss kann man das zb auch mal Gebraucht erwerben. Hierfür gibt es nicht nur die elektrobucht, sondern auch professionelle Servertechnik-Anbieter für Gebrachtes.
Was den HP Microserver angeht steht dir da in der Grundausstattung schon reichhaltig Features zur Verfügung, die du bei Deiner Hardware-Auswahl teuer zukaufen müsstest. Die zwei Braodcom Lan Karten zb. eröffnen dir entweder so etwas wie Link "Link Aggregation" (https://de.wikipedia.org/wiki/Link_Aggregation) oder du stellst eine der Karten für Service und Backup bereit. Für Link Aggregation benötigt man allerdings auch entsprechende Switches.
Wie dem auch sei. Ich halte die Idee, so viele so wichtige Daten auf Technik zu Speichern mit der von Dir genannten Hardware für nicht Optimal, da sie mir zu schwach erscheint. Zudem würde ich wie andere das bereits erwähnten die Daten auf Kleinere Einheiten (Server) verteilen. Bei einer von Dir angestrebten Datenmenge auf einem Server sollte man sonst zu Profi-Server-Technik greifen.
Kreuzberger
