XigmaNAS

Hi.

Ich habe leider ein problem mit meinem Nas4Free.
Ich habe auf einem ZFS Mirror mehrere Datasets als Samba Freigabe.
In mehreren Ordnern sind extrem viele Dateien - in dem größten/wichtigsten aktuell über 100000 - eine Änderung ist vom Chef nicht gewünscht.
Bis jetzt habe ich ein normales Debian System als Dateiserver/Sambafreigabe benutzt und da lief auch alles einwandfrei.
Das einzige langsame war, wenn man mit dem Explorer (oder anderen Dateimanager) versucht hat das große Verzeichniss zu öffnen - das ging je nach dem 7-10 Sekunden.
War aber eigentlich egal, da man das Verzeichniss nie geöffnet hat - in userem CAD System werden die Daten quasi nur über Kommandozeile mit Load bzw. Save geöffnet und gespeichert - da lief bis jetzt unter Debian alles schnell und flüssig.

Im Normalfall ist das jetzt unter N4F auch so aber das System hat immer wieder "Hänger". D.h. nach nem "Load Datei1" passiert erstmal 5-10 sekunden gar nichts, nach nem Save entsprechend auch erstmal Gedenkpause.
Am System ist mir soweit mal nichts groß aufgefallen, der entsprechenden Samba Prozess geht mal auf bis 20% hoch und ich hab schon sämtliche Einstellungen AIO, Buffer usw. durchprobiert - erst dachte ich juhu ich habs und nach zwei Stunden war das System wieder unbedienbar...

Ich hasse es, wenn ein Fehler nur ab und zu vorkommt - macht die Fehlerdiagnose zum Geduldspiel...

Hat jemand einen Ansatz wo ich noch schauen kann?

Danke

Ich gehe mal davon aus, daß du genügend RAM im NAS hast. Je mehr, desto besser. Ich rüste immer auf das Maximum auf (hier 16GB).

1. Nimm den Haken bei System|Advanced Tuning raus. Reboot. Test.

2. Installiere zfskerntune, und richte es ein. Reboot. Test.

3. Sollte das nichts helfen, dann nimm eine schnelle SSD als ZFS-Cache in den Pool auf.

Allerspätestens mit Punkt 3. sollte dein Problem verschwunden sein.

Noch ein paar Hinweise:
Besonders bei deinem Szenario ist es immens wichtig, daß du immer genug freien Speicher im Pool hast (~20% sollten immer frei sein). Ansonsten fragmentieren deine Daten wie Hölle.

Richte dir unbedingt ein Backup-NAS ein. Komm nicht auf die verwegene Idee, deine Daten mit USB-Festplatten sichern zu wollen. Das geht schief (auch wenn du das evtl. schon jahrelang so praktiziert hast).

Grüße
Princo

Dank dir für die Antworten.

Ram ist für den Zweck genug drin (8GB). Sind nur 2* 2TB die als Mirror laufen. Benutzt werden davon ~600GB
Backup ist auch kein Thema. Intern werden die Daten per Rsync an einen Debian Server geschickt, der im Notfall die Datenfreigabe übernimmt.
Zusätzlich wird per Rsync jede Nacht ein Abgleich an zwei weitere Standorte gemacht (die Oracle Datenbank stündlich).

Sobald hier mal alles sauber läuft, werd ich mich um ZFS Send kümmern und dann mal den Wechsel weg vom Rsync wagen.

Übrige schnelle 128GB SSD's hätte ich noch hier - könnte ich so oder so da einbinden - muss mal schauen wie das funktioniert.

Dann werd ich mal deine Punkte abarbeiten - der "Fehler" tritt wie gesagt leider nur ab und zu auf. Seh ich dann jeweils am Ende des Arbeitstages ob er fehlerfrei durchlief.

Princo wrote: 3. Sollte das nichts helfen, dann nimm eine schnelle SSD als ZFS-Cache in den Pool auf.

Hallo,
wie konfiguriert man das ?

Gruß
apollo

Anstelle von ZFS-Kerntune kannst du auch diese Werte direkt eintragen:
Ich habe einfach die Werte für 8GB RAM übernommen.

Einen SSD-Cache richtet man so ein:
Über Disk|Management die SSD hinzufügen. Nicht wundern, falls sich dabei die adaX-Bezeichnungen der anderen Platten ändern sollten, das ist normal und unschädlich.
Über Disks|Format die SSD mit ZFS formatieren.
Über Disks|ZFS|Pools|Virtual device die SSD als Type Cache hinzufügen (dazu muß die SSD in der Devices-Auswahl angeklickt werden).
Über Disks|ZFS|Pools|Tools das Commando "Cache add" mit dem Pool und der SSD ausführen.
Fertig.

Zum Backup: zfs send/receive ist besser als rsync. Bei Bedarf kann ich dir dazu was schreiben.

Hi Princo,

danke für die ausführlichen guten Erklärungen - inzwischen läuft alles wie es soll aber ironischerweise erst als ich dem System ein anderes Mainboard gegönnt habe - da war wohl irgendwo der Schuss drin... naja, man lernt ja dazu *g*

Die ZFS Send/Receive Sache würde mich dann trotzdem extrem interessieren. Auswärts sichere ich auf ein Synology Nas und auf einen Debian Server mit Rsync, das wird dann wohl auch so bleiben aber intern wollte noch ein zweites Nas4Free aufsetzen, auf das ich im Notfall direkt umswitchen kann.

Wenn du mal Muse hast, kannst du gerne was dazu schreiben

Hi mahlzeit,

bevor ich die zfs send/receive Sache erkläre, möchte ich dich um ein Experiment bitten, und das betrifft deine externe Sicherung per rsync auf die Synology und den Debian Server:

Mache einen ganz normalen Abgleich, und führe gleich danach einen neuen Abgleich durch. Bei dem zweiten Abgleich fügst du beim sendenden rsync den Parameter -c hinzu, und schaltest das Logging ein (--log-file=FILE).

Für mich ist dabei von Interesse, ob bei dir durch den Parameter -c auf einmal zusätzliche Dateien übertragen werden (deswegen die Logdatei).
Solltest du bei deiner normalen Übertragung schon den Parameter -c verwenden, dann brauchst du den Test natürlich nicht durchführen.
Der Parameter -c bewirkt eine zusätzliche Überprüfung der Dateien, weil der rsync bestimmte Dateikonstellationen nicht überträgt. Der zusätzliche Parameter kann allerdings die Übertragungszeit erheblich verlängern.

Nun zum zfs send/receive. Ich hatte das letztens jemanden per Mail geschickt, und kopiere das hier einfach mal rein (daher die kurzen Zeilenumbrüche).

### Erstabgleich ###
Beide Maschinen haben bei mir den gleichen Poolnamen "Daten" (nicht
zwingend nötig).

Erstabgleich zwischen NAS4FreeA und NAS4FreeB (vorzugsweise per
direkter Konsoleneingabe auf den NAS'sen):

NAS4FreeB ist der Empfänger:
NAS4FreeA ist der Sender:
### Ende Erstabgleich ###

## Nachfolgende Abgleiche ##

Auf der Empfängerseite der gleiche Befehl wie oben.

Auf der Senderseite
(-RI ist ein großes R und ein großes Ihh)

### Ende nachfolgende Abgleiche ###

### Wissenswertes ###

Bei dieser Methode wird der ganze Pool übertragen. Dabei werden sogar
die Eigenschaften der Datasets mit transferiert (z.B. Kompression).
Das wird durch den Parameter -R erreicht.

Auf der Senderseite können die übertragenen Snapshots BIS AUF DEN
LETZTEN gelöscht werden (zfs destroy -r Daten@...). Der letzte
Snapshot muß behalten werden.

Wenn man auf der Senderseite einen neuen rekursiven Snapshot anlegt,
sollte man danach keine alten Snapshots mehr löschen. Alte Snapshots
sollte vorher gelöscht werden.

Bei den nachfolgenden Abgleichen kann es auf der Empfängerseite am
Ende eine Fehlermeldung geben ("failed to read from zfs-Stream" oder
so). Das scheint normal zu sein. Nachzählen der Daten ergibt
identische Werte.

Wenn man auf der Senderseite ein neues Dataset anlegt, sollte man dort
gleich einen rekursiven Snapshot für den Pool anlegen, solange das
neue Dataset noch leer ist. Ansonsten kann es beim Abgleich ein
Problem geben (Dataset könnte ohne Daten übertragen werden). Das
scheint ein Bug zu sein.

Der Grund, warum ich auf beiden Systemen den gleichen Poolnamen
verwende: Wenn mir NAS4FreeA komplett abrauchen würde, dann mache ich
einfach NAS4FreeB zu NAS4FreeA, übertrage die Konfig, und kann ohne
weitere Änderungen weiterarbeiten.

### Wichtig ###
Meinen Beobachtungen nach, überträgt zfs send/receive nicht wirklich
blockweise, sondern orientiert sich am Filesystem. Wenn man z.B. ein
komprimiertes Dataset überträgt, werden die Daten zur Übertragung
dekomprimiert, übertragen, und dann auf Empfängerseite wieder
komprimiert. Erkennbar ist das an den unterschiedlichen
Übertragungsraten bei komprimierten Datasets. Das gilt wohl für alle
Kompressionsarten bis auf zle (zle wird vermutlich unverändert
übertragen). Dabei gilt übrigens nicht, ob die Daten tatsächlich
komprimiert sind, sondern wie die Einstellung des Datasets ist. Auf
die Art kann man Datasets per Übertragung quasi nachträglich komprimieren.

### Ende der Mail ###

Noch ein paar Anmerkungen dazu:
Die beschriebene Methode überträgt die Daten unverschlüsselt, und ist auf Geschwindigkeit ausgelegt, damit ideal für den Einsatz im eigenen Netz, und für den Erstabgleich von Offsite-Systemen geeignet.

Die nachfolgenden Abgleiche können auch anders gestaltet werden. Man kann den Backup-Datenstream auch in eine Datei umleiten, diese Datei dann auf eine kleine Transportfestplatte kopieren, die Transportfestplatte an das Zielsystem anschließen, und den Datenstrom auf das Zielsystem einspielen. Damit kann man Szenarien realisieren, bei denen Quell- und Zielsystem nicht miteinander verbunden sind.
Natürlich kann man die Abgleichdaten auch per ssh-Verschlüsselung und mit Komprimierung übertragen.

Worin liegen die Unterschiede zwischen "rsync" und "zfs send/receive"?
rsync ist für die Übertragung zwischen unterschiedlichen (OS) Systemen geeignet. Es ist aber sehr langsam, wenn man auf exakte Datenübertragung Wert legt (dazu dient der obige Test).

zfs send/receive funktioniert nur zwischen ZFS-fähigen Systemen. Es ist extrem schnell und exakt in der Datenübertragung. Zudem kann man OffSite-Szenarien realisieren, was mit rsync nicht geht.
Da mit Snapshots gearbeitet wird, kann während der Übertragung mit dem System weitergearbeitet werden.

Wenn du jetzt schon Daten auswärts lagerst, scheinst du sehr viel Wert auf Datensicherheit (physikalisch) zu legen. Daher solltest du dich intensiv mit den ZFS-Snapshots beschäftigen, denn damit lassen sich viele Fälle abdecken, für die man "früher" Backups verwendet hat. Dazu muß man zwar in einigen Dingen etwas umdenken, aber es ergeben sich völlig neue Möglichkeiten im Vergleich zu den "klassischen" Methoden des Datenmanagements.

Grüße
Princo

Und wieder mal Danke für deine Mühe!
Werde aufgrund akuten Zeitmangels wohl ne weile fürs testen und umsetzen brauchen aber ich gebe dann wieder meinen Status ab