[Sammelthread] ZFS Stammtisch

Illumos und damit OI/OmniOS ist ein Fork von OpenSolaris build 148 (die letzte freie Version).
Es ist damit sowas wie Oracle Solaris 11 Express aber ohne ZFS Verschlüsselung (das wurde später fertig).

Die Handbücher für Solaris 11 Express passen damit perfekt für Illumos/OI/OmniOS.
Dank Internet gibts die unter (auf Download klicken, die Beschreibung geht auf das aktuelle Solaris):
Oracle Solaris 11 Express Information Library 2010.11 Release


ansonsten galt bei Oracle Solaris bisher:
- commercial use nur gegen Geld
- kostenlose Nutzung nur für Demo oder evaluation use
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Höhö, ich habe meine Daten zurzeit auf ZFSonLinux mit Ubuntu unter einer Windows Server Technical Preview 2 Hyper-V VM. Mehr "beta" bzw. "not supported" geht wohl kaum... :-D

Erstaunlicherweise bisher problemlos... (3x auf Holz klopf)...

Aber dafür habe ich mehr Infos gefunden als OmniOS... ;-)

@gea: danke! Das hilft! Habe bisher eher bei Solaris 10 geschaut. Nach dem Urlaub schau ich mir mal die Lizenzen genauer an und installier ich Solaris einfach mal auf einen anderen USB Stick.
 
Zuletzt bearbeitet:
gea: Danke für die Berichtigung, hab hier grad dafür nur auf die schnelle die Wikipedia Grafik für den Beitrag gehabt. s. Hier

Danke für die richtigen Solaris 11 Handbücher :)

Hab damals auch gedacht Oracle ZFS Storage wäre was feines bis ich gelesen habe das denen fast alle ZFS Entwickler weggelaufen sein sollen. Dann war´s damit auch vorbei. :)
 
Zuletzt bearbeitet:
Unterscheiden sich Oracle Solaris und OmniOS irgendwie in der Zuverlässigkeit?
Nach einem ESXi Server Reboot erkennt meine Napp-In-One OmniOS Maschine Platten am durchgereichten Sata C224 Chipsatz Controller nicht mehr, der LSI geht wunderbar. Der Controller selber wird erkannt (laut lspci). Zwei Linux VMs und eine Windows VM erkennen die Platten wenn man denen den Controller durchreicht. Sehr seltsam.
 
Zuletzt bearbeitet:
Die Grundzuverlässigkeit von Solaris und OmniOS sehe ich ähnlich. Da die Entwicklung jetzt getrennt verläuft, kann mal das eine oder das andere einen Fix für ein konkretes Problem enthalten.

Sata habe ich noch nie durchgereicht. Üblicherweise nimmt man Sata für ESXi und den LSI HBA für ZFS und pass-through. Das ist praktisch immer problemfrei. Von Problemen mit Sata pass-through habe ich aber gehört.
 
Info

Es gibt ein Update für OmniOS 151014 LTS
Neben kleineren Bugfixes zu KVM verbessert es die Stabilität des NFS Server bei hoher Last und sehr schnellen Netzwerken.
Discussions on Illumos development

Update mit "pkg update" + reboot
 
Ja kommt noch.
Ab dem heutigen wget Installer (21.7.2015) wird Solaris 11.3 unterstützt.

Ich bin begeistert. Habe einen 4 Jahren alten PC mit 4 1TB Samsungplatten aufgebaut und Solaris 11.3 Beta installiert. Einen Pool als RaidZ1 und ein ZFS Filesystem als SMB 2.1 Freigabe eingerichtet.

Dann Verbindung von einem iMac mit Mac OS X 10.10.4 auf den Share:

1. cifs://share -> lesen und schreiben mit ca. 50 MB/s

2. smb://share -> lesen und schreiben mit ca. 108 MB/s

Dies sieht ja schon sehr gut aus. Die Url cifs://... verwendet scheinbar SMB1, die URL smb://... nun SMB 2.1.
 
Danke für den Vergleich.

Es ist auch das was ich erwartet habe, da OSX mit einem aktuellen Windows Server viel schneller ist als mit einem älteren. Apple hat die eigene SMB Implementierung wohl ausschliesslich auf SMB2+ optimiert.

Ich hoffe ja wirklich dass Illumos bald SMB2+ bietet.
Ich vermute aber dass Nexenta das zurückhält bis Nexentastor 5 mit SMB3 verfügbar ist.

Unabhängig davon.
Oracle is "back in the game" mit Solaris 11.3
 
Seltsames Phänomen

Hallo,

ich hatte heute ein komisches Phänomen:

Ich wollte von meinem Nas4Free (ZFS Mirror 2x 3TB HD) eine Verzeichnis per SMB an eine andere stelle kopieren. Dabei trat ständig ein Lesefehler bei einer ~1,6GB großen Datei auf. Nach einigen Versuchen habe ich dann mal sicherheitshalber "zpool status" aufgerufen, das mir dann folgendes zeigte:

Code:
20150804_121500   INFO  -------------------------------------
20150804_121500   INFO  Starting checking of pools
20150804_121500   ERROR   pool: raid1-hd
20150804_121500   ERROR  state: ONLINE
20150804_121500   ERROR status: One or more devices has experienced an error resulting in data
20150804_121500   ERROR       corruption.  Applications may be affected.
20150804_121500   ERROR action: Restore the file in question if possible.  Otherwise restore the
20150804_121500   ERROR       entire pool from backup.
20150804_121500   ERROR    see: http://illumos.org/msg/ZFS-8000-8A
20150804_121500   ERROR   scan: scrub repaired 0 in 9h29m with 0 errors on Sun Aug  2 10:29:23 2015
20150804_121500   ERROR config:
20150804_121500   ERROR       NAME        STATE     READ WRITE CKSUM
20150804_121500   ERROR       raid1-hd    ONLINE       0     0     1
20150804_121500   ERROR         mirror-0  ONLINE       0     0     2
20150804_121500   ERROR           ada0    ONLINE       0     0     2
20150804_121500   ERROR           ada1    ONLINE       0     0     2
20150804_121500   ERROR errors: 1 data errors, use '-v' for a list

Wie man sieht, lief am Wochenende noch ein SCRUP ohne Fehler durch.

Nach ein paar weiteren Kopierversuchen erhöten sich die Checksum-Fehler auf ein paar Hundert!
Bei "zpool status -v" werden drei Dateien angezeigt, 2 davon liegen in dem Verzeichnis das ich kopieren wollte, die andere irgendwo anderst.

Ich habe nun mal die Kiste komplett runtergefahren und neu gestartet, nun zeigt "zpool status" unter "CKSUM" keine Fehler mehr an (alles auf 0) und auch das Verzeichnis liess sich nun ohne Probleme kopieren und auch danach steht alles noch auf "0" Fehler. Mit "zpool status -v" erscheinen aber immer noch die drei Dateien.

Ich habe die drei betroffenden Dateien auch noch mit denen aus einem Backup von vor 2 Monaten verglichen, das passt auch, keine Unterschiede beim Dateivergleich.

Die SMART-Werte der beiden Platten sind auch ok.

Wie kann es sowas geben?


Zur Hardware: Supermicro Board mit ECC Speicher, Onboard-Controller mit den zwei Platten wird durchgereicht (Proxmox mit PCI-Passthrough) an die Nas4Free-VM.
 
Wie kann es sowas geben?

ZFS versieht die Daten auf beiden Platten des Mirrors mit einer Prüfsumme. Gibt es korrupte Daten auf einer Platte (Silent errors, Radioaktivität, Magnetfelder, Oberflächenfehler, Statistik - whatever) so entsteht beim Lesen ein Checksumerror auf einer Platte. Das wird durch die Redundanz der anderen Platte automatisch durch ZFS repariert.

Hier haben wir Fehler auf beiden Platten (defekte Datei, keine Reparatur möglich). Kopieren von Dateien erzeugt weitere Checksum Fehler.

Hier liegt ein Hardwareproblem vor, im einfachsten Fall ein Problem mit der Verkabelung oder der Stromversorgung im komplizierten Fall ein Problem mit der Elektronik.

Ich würde zunächst den Rechner herunterfahren und alle Steckverbindungen überprüfen. Bei kommerzieller Nutzung würde ich dann den Rechner stillegen (zur weiteren Fehlersuche) und den Pool in einer anderen Hardware importieren/testen.
 
Wie gesagt, die Daten scheinen ja trotz der Fehleranzeige in Ordnung zu sein, ich hatte das mit einem Dateivergleichstool überprüft.
Meine Vermutung ist, dass es evtl. an der Passthrough Geschichte liegt.

Wie bring ich die Fehlermeldung jetzt noch mal weg, "zpool clear raid1-hd" und anschliessend Scrub?
 
In aktuellen c't 17 gibt es zwei Artikel über OpenZFS unter OS X. Hat jemand Erfahrung damit?
OpenZFS unter OS X benutzen | c't

Ich setze es derzeit unter OS X ein. Die aktuelle Version ist rech gut. Bitte passe aber derzeit etwas auf, ZPOOLS zwischen verschiedenen Systemen wie FreeBSD, Debian und OS X zu tauschen. Die verschiedenen ZFS Versionsstände können Probleme bereiten und ggf. sogar zu Dateiverlusten führen. Beim ersten Import also sehr auf die Hinweise achten!

Aktuell versuche ich mit einem OWC Thunderbold Gehäuse einen kleinen ZFS Storage mit einem Mac Mini zu betreiben. Meine mir sehr wichtige iTunes Musiksammlung liegt auf einem dreifach Spiegel auf 3 USB Platten.
 
Tips/Infos/Ratschläge zu meinem Aufbau...

Ich bräuchte mal Eueren Rat.

Bisher sieht mein Aufbau wie folgt aus:

Supermicro-X10SAE Board
OnBoard-Controller-1 (6-Port) -> kleine SSD als Systemplatte und 2x Samsung-SSD-840-Pro
OnBoard-Controller-2 (2-Port) -> 2x Hitachi-3TB HD
Betribssystem -> Proxmox, läuft auf der kleinen SSD
Die beiden Samsung-SSD's laufen direkt unter Proxmox mit ZFSonLinux als Raid-1 und dienen als Datastore für die VM's von Proxmox.
Der OnBoard-Controller-2 mit den beiden Hitachis wird per Passthrough an eine Nas4Free-VM durchgereicht (auch ZFS Raid-1) und dient als NAS für die Daten, Multimedia, etc.
Da ich mit dem Passthrough irgendwie nicht mehr ganz glücklich bin, suche ich nach einer anderen Lösung bzgl. NAS.

Lösung-1:
Ein zweites kleines System das nur als NAS läuft, also die beiden Hitachis raus und dort rein, Nas4Free/Openmediavault als Betriebssystem.
Vorteil: Alles getrennt, nix anfälliges Passthrough, per GUI managebar (Freigaben, etc.)
Nachteil: Kosten zweites Gerät, Kosten Strom, langsamer, noch mehr Hardware im Haus :)

Lösung-2:
Die beiden Hitachis auch direkt unter Proxmox als Raid-1 einbinden und die ganzen Freigaben direkt unter Proxmox (Linux) händisch machen.
Vorteil: Alles in eine Kiste, schnell
Nachteil: Ich muss die ganzen Freigaben (AFP/SMB/NFS/etc.) händisch machen, verwalten -> gefällt mir gar nicht. Ausserdem möchte ich so wenig wie möglich Software/Tools/etc. direkt auf dem Host haben.

Lösung-3:
Die beiden Hitachis auch direkt unter Proxmox als Raid-1 einbinden und ebenfalls als Datastore zur Verfügung stellen, also das NAS incl. Daten (Platten) virtualisieren:
-> Die NAS-VM (Nas4Free/Openmediafault/etc.) awie gehabt auf das SSD-Raid1, die virtuelle(n) Platten davon auf das HD-Raid-1
Vorteil: Alles in einer Kiste, kein Passthrough mehr, schnell, GUI Verwaltung über Nas4Free/Openmediavault, etc.
Nachteil: Noch mal eine Zwischenschicht -> ZFS -> VM mit Filesystem (ext4 oder noch mal ZFS)

Die dritte Variante würde mir eigentlich zusagen, allerdings weiss ich nicht genau, ob das prinzipiell gut ist, noch mal eine Filesystem Schicht dazwischen zu haben. Denn wenn ich die die virtuellen Paltten der NAS-VM wieder mit ZFS laufen lasse, dann läuft ja quasi ZFS auf ZFS. Es heisst ja immer, ZFS sollte immer direkten Zugriff auf die Hardware haben, wie verhält sich dass dann in diesem Fall? Proxmox hätte dann zwar direkten Zugriff auf die physikalischen Platten, Die VM aber nur auf die virtuellen. Und was ist, wenn ich bei den virtuellen NAS-Platten ext4 als Filesystem nehme? Bei einem Absturtz etc. hätte ich ja unter Umständen wieder geschrottete Daten, oder nicht?

Wäre klasse wenn ihr mir da mal ein paar Tips/Infos/Ratschläge geben könntet.
 
Huhu,

Ma ne Frage, ich habe einen 8 Port HBA (RocketRAID 2720SGL) jetzt brächte ich aber noch ne 9 und 10 platte, is das möglich einfach 2 Ports vom mainboard zu nehmen oder müssen alle Drives die in einem Array sind in einen Controller stecken ?
Bringt das Probleme wenn ich einfach 8 Port beim RR und 2 ports vom Mainboard nehme ?
Ich hoffe man versteht was ich meine...


Grüße
 
Müssen nicht, ich zieh das Backup von den 8 Platten am BR10i auch immer über die Onboardcontroller raus auf die entsprechenden Platten. Wenn du allerdings deinen Controller in irgendeiner Virtualisierungsumgebung rüberreichen willst, ist das etwas unpraktisch, wenn gleichzeitig das System am Mobo-Controller hängt.
Sauberer wär ein zusätzlicher oder größerer HBA natürlich schon, aber wer weiß, was du vorhast...
 
In das gehäuse passen eh nicht mehr als 10 Platten + eine SSD fürs OS.
Ich will einfach nur mein System erweitern, ohne Virtualisierung oder sonstiges, einfach Debain + ZFSonLinux.
Sonst müsste ich mir nen 16 Port holen wovon ich dann 6 Ports eh nie nutzen würde......deswegen meine Frage.
 
Vorab: Bin nicht ganz sicher, ob das noch hierher gehört oder ich im Linux-Unterforum besser einen Thread dazu aufmache. Daher bitte ich schonmal um Entschuldigung, sollte ich hier falsch sein.

Das Thema: iSCSI mit ZFS on Linux (Ubuntu)

Ich will gerne (zunächst zu Testzwecken) unter Ubuntu (Server 14.04.02 LTS) mit ZFS on Linux ein iSCSI Target erstellen. Nun findet man im Netz diverse Anleitungen zu Linux-iSCSI, wie man das grundsätzlich machen kann. Dummerweise gibt es offenbar schon 3 Grundmöglichkeiten, wie man das machen kann:

1. SCST
2. iscsitarget
3. LIO (targetcli)

Ein Bruder im Geiste hat alle drei mal ausprobiert mit dem Ergebnis, dass nur LIO wohl wirklich taugt (leuchtet mir grds. ein, ist ja die im Kernel implementierte Variante).

ZFS lüppt bei mir ja bereits und ich kann auch mit Napp-it prima Filesysteme anlegen - nur das "sharen" mit iSCSI geht halt verständlicherweise (leider) nicht so ohne Weiteres, da Linux ja nicht über die "Solaroide"-iSCSI-Funktionalität verfügt.

Jetzt habe ich diese Anleitung gefunden, die sich allerdings primär wohl auf ESXi bezieht. Verstehe ich das richtig, dass ich unter dem Abschnitt "Create iSCSI volumn using Linux SCSI Target(Targetcli)" eigentlich nur noch Schritt 1. und 3. machen muss, angepasst auf mein bereits existierendes Filesytem?

Mich macht etwas stutzig, dass ich unter /dev schon kein Verzeichnis/Gerät "zvol" habe, sondern bloß ein "zfs". Daher habe ich das bisher nicht einfach mal ausprobiert.

Will mir ungern groß etwas zerschießen und obwohl mit Linux nicht ganz unerfahren, fühle ich mich mit iSCSI (und ZFS) noch nicht so wirklich sicher. Feedback ob das grds. so gehen müsste / sonstige Tipps daher gerne willkommen!

EDIT: ich glaub', ich werde es mit dieser anderen Anleitung mal versuchen. Berichte dann...

EDIT 2: ok, ich habe es hinbekommen. Achtung, die Zeilenumbrüche in der Anleitung oben sind ein wenig missverständlich, daher hier mal richtig / ergänzt um die Wechsel in die richtigen Verzeichnisse (für doofe wie mich):
Code:
sudo targetcli
>cd backstores
/backstores> fileio/ create name=iscsi_lun0 file_or_dev=/dstore/iscsi/lun0.bin size=500G

>cd /backstores/fileio/iscsi_lun0
/backstores/fileio/iscsi_lun0> /iscsi create

cd /iscsi/iqn.[DEINE ID - wurde automatisch erzeugt]/tpgt1/luns
/iscsi/iqn.[DEINE ID - wurde automatisch erzeugt]/tpgt1/luns> create /backstores/fileio/iscsi_lun0

cd ..
/iscsi/iqn.20...050ee5c/tpgt1> portals/ create [IP FÜR VERBINDUNG AUF SERVER]

/iscsi/iqn.20...050ee5c/tpgt1> set attribute authentication=0 demo_mode_write_protect=0 generate_node_acls=1 cache_dynamic_acls=1 default_cmdsn_depth=64   // alles ein Befehl!

Diese Anleitung von ThomasKrenn hat mir auch beim Verständnis geholfen.
 
Zuletzt bearbeitet:
Der Vorteil von Linux ist, dass es auf allem läuft das 1 + 1 binär zusammenzählen kann.
Da kommt man auf zwei Handvoll Optionen von einer Kaffeemaschinensteuerung bis zu einem Höchstleistungscomputer.

Da gibt es neben x CPUs auch x Distributionen, x Dateisysteme, x Optionen um Platten zu verwalten, x Optionen für Services oder x Wege um etwas zu realisieren.

Das ist aber genau der Grund, warum ich (zumindest bisher) bei Multimedia auf OSX gesetzt habe und bei Storage eben auf Solaris oder die freien Forks wie OmniOS. Da gibt es genau einen Hersteller oder eine Distribution (Bei Solaris/Illumos zerfasert das leider gerade), eine Option SMB, NFS oder iSCSI bereitzustellen, eine Option Festplatten zu organisieren (WWN) oder eine Option für vlan/Netzwerkvirtualisierung. Der OS-Hersteller legt das fest und die Sachen funktionieren einfach out of the box.

Das ist für mich der Hauptunterschied zu Linux und "mach doch was du willst"
 
Zuletzt bearbeitet:
Jupp... das ist bei Solaris schon echt gut aufeinander abgestimmt. Prinzipiell nur halt doof, dass Solaris-CIFS/SMB nur SMB1 kann.

Man müsste mal einen Direktvergleich Solaris-CIFS vs. Samba@OmniOS machen, ob es sich lohnt, Samba zu nehmen... wobei Samba ja von SMB3 auch noch nicht alle Funktionen implementiert hat und Windows10 jetzt schon mit SMB3.1 um die Ecke kommt...
 
Solaris 11.3 und Nexentastor CE 4 haben SMB 2.1 (beide als freier Download verfügbar)
Nexenta arbeitet an SMB3 (ich weiss noch nicht ob das in der aktuellen NexentaStor5 preview bereits drin ist.)
 
Solaris 11.3 wollte ich eh mal ausprobieren. Das kann ich ja mal schnell auf einen Stick im HP installieren (und bei der Gelegenheit mal lernen, wie man einen bestehenden ZFS-pool "überträgt" bzw. einbindet. :)

Schiete, meine ToDo-Liste wird immer länger statt kürzer ...
 
Rentiert sich das Upgrade von Solaris 11.2 auf 11.3 denn? Performance via NFS find ich okay, Einbindung dauert halt immer ein wenig, liegt aber wohl am Client. Wurde irgendwas wichtiges gefixt oder erweitert? Ein richtiges Changelog gibts ja nicht. Und Oracle listet sie als Beta, "for development and evaluation purposes only"...
 
Die 11.3 beta gibts seit Juli. Bisher kam die Final wenige Monate später.
Die für mich wichtigsten Erweiterungen sind LZ4 Komprimierung und SMB 2.1.
Daneben gibt es einiges rund um Zonen und Virtualisierung.

"for development and evaluation purposes only" bezieht sich auf den freien Download
von Solaris 11. Für andere Nutzung ist eine Subscription fällig (1000$/Jahr),
Die enthält dann auch aktuelle Bugfixes die im freien Download nicht dabei sind.
 
Ich habe ein Problem mit einer Replicate und finde den Fehler/Problem nicht.
Active Job 1424890615 error:
error; time: 2015.08.11.23.11.07 line: 1725; my_log end 1551: error, next destination snap was not created
snap: pool_ripley/a_aio/aio_vmfs@1424890615_repli_zfs_ripley_nr_57 error, job-replicate 849: next destination snap error
pool_ripley/a_aio/aio_vmfs@1424890615_repli_zfs_ripley_nr_57 was not created, check network, systemlog, poolstate, capacity, timeouts and (hidden) snaps
on recursive transfers check if newest snappairs on source target are consistent - optional delete incomplete newest pairs error, job-replicate 849: next destination snap error
pool_ripley/a_aio/aio_vmfs@1424890615_repli_zfs_ripley_nr_57 was not created, check network, systemlog, poolstate, capacity, timeouts and (hidden) snaps
on recursive transfers check if newest snappairs on source target are consistent - optional delete incomplete newest pairs

Nr. 56 ist sowohl auf aio/Quelle als auch auf ripley/Ziel vorhanden
aio hat noch 1,6T Platz, ripley noch 14,9T
Netzwerk funktioniert auch, da die anderen replicates alle laufen.

Ursprünglich war noch Nr. 57 vorhanden, Diesen habe ich, auf Quelle und Ziel, gelöscht in der Hoffnung, dass eventl. darin ein Fehler war. Nur 56 darf ich jetzt nicht mehr löschen, da es der Letzte ist.

Das gleiche Problem hatte ich auch noch mit einem weiteren repli-job.
Da konnte ich es nur so lösen, indem ich den Job, alle Snap auf Quelle und Ziel gelöscht hatte. Ferner musste ich auf den Zielserver natürlich das Ziel-FS (pool_ripley/a_aio/daten_praxis) auch löschen.
Active Job 1424890556 error:
error; time: 2015.08.07.22.00.18 line: 1703; my_log end 1551: error, job-replicate 578: new destination snap
pool_ripley/a_aio/daten_praxis@1424890556_repli_zfs_ripley_nr_56 was not created, check network, systemlog, poolstate, capacity, timeouts and (hidden) snaps
on recursive transfers check if newest snappairs on source target are consistent - optional delete incomplete newest pairs error, job-replicate 578: new destination snap
pool_ripley/a_aio/daten_praxis@1424890556_repli_zfs_ripley_nr_56 was not created, check network, systemlog, poolstate, capacity, timeouts and (hidden) snaps
on recursive transfers check if newest snappairs on source target are consistent - optional delete incomplete newest pairs error, job-replicate 578: new destination snap
pool_ripley/a_aio/daten_praxis@1424890556_repli_zfs_ripley_nr_56 was not created, check network, systemlog, poolstate, capacity, timeouts and (hidden) snaps
on recursive transfers check if newest snappairs on source target are consistent - optional delete incomplete newest pairs

Das Fs daten_praxis hab ich noch gespiegelt auf meinem lokalen PC, daher hab ich da nicht lange gefackelt und das Ziel-FS gelöscht und neu aufgebaut. Das Neuanlegen von daten_praxis ging ratz fatz, da es sich nur um 460Gb handelt.
aio_vmfs sind aber 1,7T und das dauert dann doch etwas länger und hier hab ich kein doppeltes Sicherungsseil. Deshalb suche ich hier noch eine Lösung.

Kann mir wer weiterhelfen und mir sagen, wo der Fehler sein könnte oder wo ich noch suchen kann? Und vorallem, wie bring ich Job 1424890615 wieder zum Laufen.
 
Inkrementelle Replication benötigt auf dem Quellserver und dem Zielserver einen identischen Snapshot. Napp-it nummeriert die fortlaufend und erkennt daran einen gleichen Basissnap.

Bei einem Replikationslauf werden beide Dateisysteme auf die neueste Snapnummer des Backupservers zurückgesetzt, dann auf dem Quellsystem ein Snap angelegt und die damit verbundenen Änderungen übertragen. Ist das erfolgreich wird ein neuer Snap auf dem Backupserver angelegt. Dieser hat eine identische Nummer wie der neue Snap auf dem Quellserver.

Fehler bedeuten, dass etwas die Datenübertragung unterbrochen hat, das Quellsystem nicht sauber mit den senden begonnen hat oder das die beiden Basissnaps trotz gleicher Nummer nicht identisch sind. Letzteres kann vor allem dann passieren, wenn andere Snaps erstellt werden (Probleme machen da z.B. Snaps mit size=0) oder mehrere Replikationen auf dem gleichen Quellsystem laufen. Probleme konnten bis 0.9f5 manchmal auch auftauchen, wenn mehrere Replikationen auf einem Quellsystem gleichzeitig gestartet wurden.

Probleme kann man am besten dadurch feststellen, indem man auf in der Jobübersicht auf das Datum klickt. Dann wird ein detailliertes Log gezeigt. Auf dem Quellsystem wird mit Jobs-remote ein Log des Quellsystems angezeigt. Das habe ich in der 0.9f6 nochmal verbessert. Da kann man das Log nach jobid oder Funktion z.B. "send" anzeigen lassen.

Wenn eine Replikation Probleme macht,
- nochmal manuell starten
- das neueste Snap auf dem Backupserver löschen, sofern auf beiden noch ein älteres Snap-paar vorhanden ist Das löst üblicherweise Probleme, falls die Basissnaps eben nicht identisch sind

Wenn die Replikation auch mit dem ältesten Snap-paar nicht geht
- Das Ziel-Dateisystem umbenennen und Replikation neu starten
Es wird eine neue Basisreplikation gestartet. Ist die erfolgreich, das alte Dateisystem löschen.

Manche Probleme werden von einem neueren napp-it besser kontrolliert.
In napp-it 0.9f5 (letzte stable) und 0.9f6 (Preversion der nächsten stable, ist frei downloadbar) ist vor allem das Errorhandling und Logging umfangreicher geworden.
 
Zuletzt bearbeitet:
Danke @gea dass du mir antwortest.

Inkrementelle Replication benötigt auf dem Quellserver und dem Zielserver einen identischen Snapshot. Napp-it nummeriert die fortlaufend und erkennt daran einen gleichen Basissnap.
Quelle: pool_aio/aio_vmfs pool_aio/aio_vmfs@1424890615_repli_zfs_ripley_nr_56 Tue Jun 30 22:10 2015 442M - 208G
Ziel: pool_ripley/a_aio/aio_vmfs pool_ripley/a_aio/aio_vmfs@1424890615_repli_zfs_ripley_nr_56 Tue Jun 30 22:10 2015 442M - 208G
Wie ich geschrieben hatte, sind alle älteren Snaps gelöscht und nur noch Nr. 56 übrig.

Bei einem Replikationslauf werden beide Dateisysteme auf die neueste Snapnummer des Backupservers zurückgesetzt, dann auf dem Quellsystem ein Snap angelegt und die damit verbundenen Änderungen übertragen. Ist das erfolgreich wird ein neuer Snap auf dem Backupserver angelegt. Dieser hat eine identische Nummer wie der neue Snap auf dem Quellserver.

Fehler bedeuten, dass etwas die Datenübertragung unterbrochen hat, das Quellsystem nicht sauber mit den senden begonnen hat oder das die beiden Basissnaps trotz gleicher Nummer nicht identisch sind. Letzteres kann vor allem dann passieren, wenn andere Snaps erstellt werden (Probleme machen da z.B. Snaps mit size=0) oder mehrere Replikationen auf dem gleichen Quellsystem laufen. Probleme konnten bis 0.9f5 manchmal auch auftauchen, wenn mehrere Replikationen auf einem Quellsystem gleichzeitig gestartet wurden.
Ich mache auf aio selbst noch tägliche Snaps um 22:00 Uhr. Dort gibts aber keine mit size=0
Alle Replikationen ausgehend von ripley laufen täglich, aber immer im 5 Minuten Abstand.
Joblog Text1 Opt1/ from Text2 Opt2/ to Opt3 Month Day Hour Min ID/ edit Status Last Jobstate Execute Job

replicate aio 192.168.2.210 pool_aio/daten_ve nc -I pool_ripley/a_aio/da.. port 51111 every every 22 5 1424890585 active 12.Aug 22:05 - run now delete
replicate aio 192.168.2.210 pool_aio/aio_vmfs nc -I pool_ripley/a_aio/ai.. port 51135 every every 22 10 1424890615 active 12.Aug 23:10 - run now delete
replicate aio 192.168.2.210 pool_aio/privat/a nc -I pool_ripley/a_aio/al.. port 53272 every every 22 15 1425312756 active 12.Aug 22:15 - run now delete
replicate aio 192.168.2.210 pool_aio/privat/al nc -I pool_ripley/a_aio/al.. port 53328 every every 22 20 1425312820 active 12.Aug 22:21 - run now delete
replicate aio 192.168.2.210 pool_aio/privat/g nc -I pool_ripley/a_aio/ge.. port 53419 every every 22 25 1425312906 active 12.Aug 22:25 - run now delete
replicate aio 192.168.2.210 pool_aio/privat/m nc -I pool_ripley/a_aio/ma.. port 53440 every every 22 30 1425312930 active 12.Aug 22:30 - run now delete
replicate aio 192.168.2.210 pool_aio/privat/w nc -I pool_ripley/a_aio/we.. port 53513 every every 22 35 1425312989 active 12.Aug 22:36 - run now delete
replicate aio 192.168.2.210 pool_aio/daten_p nc -I pool_ripley/a_aio/da.. port 52267 every every 22 0 1439051751 active 12.Aug 22:00 - run now delete

Probleme kann man am besten dadurch feststellen, indem man auf in der Jobübersicht auf das Datum klickt. Dann wird ein detailliertes Log gezeigt. Auf dem Quellsystem wird mit Jobs-remote ein Log des Quellsystems angezeigt. Das habe ich in der 0.9f6 nochmal verbessert. Da kann man das Log nach jobid oder Funktion z.B. "send" anzeigen lassen.
Bei Jobs-remote welche Eingaben werden da alles akzeptiert, außer JobID und send?

Das Quell-Log sieht so aus:
## 2015.08.12.23.10.38 repli-send.pl id 1424890615
remote send finished after 3633 s
zfs send: ok

Das Ziel-Log sieht so aus:
Log: Last run of Job 1424890615 (newest first)
2015.08.12.23.10.50 &my_log_last line 1726
<- &my_log line 1488
<- &my_end_all line 1457
<- &my_fast_end line 866
<- &my_remote_delta_replication line 331 error;
2015.08.12.23.10.49 &my_log_last line 864
<- &my_remote_delta_replication line 331
<- &my_run line 125 error;, next destination snap was not created
snap: pool_ripley/a_aio/aio_vmfs@1424890615_repli_zfs_ripley_nr_57
2015.08.12.23.10.46 &my_log_last line 1898
<- &my_postreplication line 825
<- &my_remote_delta_replication line 331
<- &my_run line 125 end my postreplication
2015.08.12.23.10.46 &my_log_last line 1896
<- &my_postreplication line 825
<- &my_remote_delta_replication line 331
<- &my_run line 125 my postreplication, zfs set readonly=on pool_ripley/a_aio/aio_vmfs

2015.08.12.23.10.46 &my_log_last line 1855
<- &my_postreplication line 825
<- &my_remote_delta_replication line 331
<- &my_run line 125 zfs set nfs/smb shares=off pool_ripley/a_aio/aio_vmfs

2015.08.12.23.10.46 &my_log_last line 1838
<- &my_postreplication line 825
<- &my_remote_delta_replication line 331
<- &my_run line 125 zfs set readonly=off pool_ripley/a_aio/aio_vmfs

2015.08.12.23.10.46 &my_log_last line 1810
<- &my_postreplication line 825
<- &my_remote_delta_replication line 331
<- &my_run line 125 1522 update id.par: last=12.aug_23_10
2015.08.12.23.10.46 &my_log_last line 1790
<- &my_postreplication line 825
<- &my_remote_delta_replication line 331
<- &my_run line 125 next_src_snap from host aio
pool_aio/aio_vmfs@1424890615_repli_zfs_ripley_nr_57 77.5M - 208G
2015.08.12.23.10.39 &my_log_last line 1778
<- &my_postreplication line 825
<- &my_remote_delta_replication line 331
<- &my_run line 125 begin my_postreplication
2015.08.12.23.10.38 &my_log_last line 791
<- &my_remote_delta_replication line 331
<- &my_run line 125 error;, receiver message
cannot restore to pool_ripley/a_aio/aio_vmfs@1424970809_repli_zfs_arche_nr_4: destination already exists
2015.08.12.22.10.08 &my_log_last line 207
<- &my_monitor line 974
<- &my_remote_delta_replication line 331
<- &my_run line 125 Monitor: Remote proc:
689 /var/web-gui/data/tools/rsync/rsync --daemon --config /var/web-gui/_log/rsyncd.conf
25614 sh -c /usr/sbin/zfs send -I pool_aio/aio_vmfs@1424890615_repli_zfs_ripley_nr_56
25615 /usr/sbin/zfs send -I pool_aio/aio_vmfs@1424890615_repli_zfs_ripley_nr_56 pool_
25616 /var/web-gui/data/tools/nc/nc -b 262144 -w 30 192.168.2.220 51135
2015.08.12.22.10.05 &my_log_last line 945
<- &my_remote_delta_replication line 331
<- &my_run line 125 source snap1,2: size=442M,0
2015.08.12.22.10.04 &my_log_last line 931
<- &my_remote_delta_replication line 331
<- &my_run line 125 start sender
id=1424890615
src_interface=/usr/bin/nc -w 20 192.168.2.220 51135
src_interface2=/var/web-gui/data/tools/nc/nc -b 262144 -w 20 192.168.2.220 51135
snap_name1=pool_aio/aio_vmfs@1424890615_repli_zfs_ripley_nr_56
snap_name2=pool_aio/aio_vmfs@1424890615_repli_zfs_ripley_nr_57
send_inc=-i
snap_rec=
send_rec=
send_dedup=
send_i=-I
transfer_zero=

2015.08.12.22.10.03 &my_log_last line 780
<- &my_remote_delta_replication line 331
<- &my_run line 125 start receiver
/var/web-gui/data/tools/nc/nc -b 262144 -d -l -p 51135 | /usr/sbin/zfs receive -F pool_ripley/a_aio/aio_vmfs 2>&1
2015.08.12.22.10.02 &my_log_last line 615
<- &my_remote_delta_replication line 331
<- &my_run line 125 start remote incremental replication
2015.08.12.22.10.02 main line 76 start job-replicate with parameter:
id=1424890615, action=run, par='run_1424890615

Wenn eine Replikation Probleme macht,
- nochmal manuell starten
- das neueste Snap auf dem Backupserver löschen, sofern auf beiden noch ein älteres Snap-paar vorhanden ist Das löst üblicherweise Probleme, falls die Basissnaps eben nicht identisch sind
Ersteres hab ich schon mehrfach gemacht, aber immer mit dem gleichen Ergebnis, dass es zu dem Fehler kommt.
Zweiteres auch schon gemacht, es ist ja jetzt nur noch ein Snap-paar vorhanden.

Wenn die Replikation auch mit dem ältesten Snap-paar nicht geht
- Das Ziel-Dateisystem umbenennen und Replikation neu starten
Es wird eine neue Basisreplikation gestartet. Ist die erfolgreich, das alte Dateisystem löschen.
Sehr guter Vorschlag, wenn du aber damit einverstanden bist, lass uns zuerst den Fehler eingrenzen und möglichst finden und lösen.
Den Neuaufbau kann ich dann immer noch machen.

Manche Probleme werden von einem neueren napp-it besser kontrolliert.
In napp-it 0.9f5 (letzte stable) und 0.9f6 (Preversion der nächsten stable, ist frei downloadbar) ist vor allem das Errorhandling und Logging umfangreicher geworden.

Sorry, Asche auf mein Haupt, ich hatte gestern vergessen anzugeben, mit welcher napp-it Version ich arbeite.
Alle meine Server arbeiten mit napp-it 0.9f5 vom Aug. 05. 2015.
 
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