[Sammelthread] ZFS Stammtisch

converted 'https://api.pushover.net/1/messages' (646) -> 'https://api.pushover.net/1/messages' (UTF-8) --2016-06-23 10:30:37-- https://api.pushover.net/1/messages Resolving api.pushover.net (api.pushover.net)... 108.59.13.232, 2604:9a00:2010:a017:2::2 Connecting to api.pushover.net (api.pushover.net)|108.59.13.232|:443... connected. HTTP request sent, awaiting response... 400 Bad Request 2016-06-23 10:30:38 ERROR 400: Bad Request. push message ..

Geht bei euch push?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hoi gea, ich hätte mal wieder eine doofe Frage - diesmal zu Performance-Anforderungen.

Ich überlege, einen (reinen) Filer mit einem Pentium G2120 (noch Sockel 1155) als Basis aufzubauen. Immerhin unterstützt der ECC. Hätte diese CPU aus Deiner Sicht für Fileserver-Dienste (Solaris 11.3 ZFS mit napp-it) genug Power, um max. 2x10Gbit plus max 2x1Gbit im LAN zu befeuern? Mehr muss der eigentlich gar nicht tun - auch das diese theoretisch möglichen 22Gbit irgendwann mal wirklich angefordert würden, ist eher total unwahrscheinlich (gäbe das Storage eh zurzeit nicht her).

Ich habe jetzt keine Benchmarks dazu gemacht.
Bei Verzicht auf dedup und compress sollte der Unterschied zu einer schnelleren CPU auch mit 10G nicht zu groß ausfallen.
 
Danke! Deduplication und Kompression sind kein Thema. Ich probiere mal mein Glück

Danke!
 
Moin zusammen,

ich hatte ja weiter vorne bereits mal geschrieben, dass die Napp-IT Replikationserweiterung bei mir nicht so zuverlässig läuft und ich oft einen nicht erledigten Job stehen habe daraus.
Mittlerweile ist eine ganze Zeit des Probierens vergangen ich habe denke ich zumindest einen Ansatzpunkt gefunden.
Wollte das gerne teilen, falls es andere betrifft und evtl. gibt es dafür ja auch eine Lösung, bzw. mag @gea da was zu sagen. Gibt ja offiziell keinen Support ;)

Ausgangssituation:
Mein ML10v2 ist die Quelle, mein N40L der Replikationsserver.
Der ML10 startet morgens um 7:00 und ist um ca. 7:13 mit dem kompletten Bootvorgang fertig. Darauf läuft eine W7-VM, die den N40L dann um 7:30 zuverlässig startet (Bootzeit ca. 2 Minuten). Bis hier keine Probleme. Ab 7:45 beginnt der N40L mit dem Replizieren verschiedner ZFS-Dateisysteme (jeweils nicht länger als 5 Minuten) und fährt um 9:00 per init5 wieder runter. Bis 9:00 haben alle Replikationsjobs mehr als genug Zeit um erfolgreiche zum Ende zu kommen.
Der ML10v2 fährt um 02:00 runter (Geizhals wollte 5 Stunden Strom sparen, da schläft eh jeder)

Die Zeiten passen und das rechtzeitige hochfahren / runterfahren passt auch zeitlich.

Trotzdem hatte der N40L immer die Jobs als fehlerhaft. Die von @gea genannten Logs haben für mich nichts offenbart, was mir eine Lösung aufgezeigt hätte. Bis mir dann kurz zusammengafsst folgendes aufgefallen ist:

Solange ich mich auf dem Quellserver ML10v2 vorher einmal auf der Napp-IT Weboberfläche angemeldet hatte, liefen die Repli-Jobs sauber durch. Aber nach jedem nächtlichen shutdown gab es wieder die Probleme morgens bei der nächsten Runde.
Solange ich mich also einmal anmelde klappt danach alles. Nun läuft der ML10v2 seit 7 Tagen 24/7 und auch die Repli-Jobs laufen sauber. Natürlich loge ich mich aktuell nicht mehr extra morgens nochmal ein. Aber es klappt. Woran kann das liegen? Gibt es da vll. eine Fehlerquelle bzgl. appliance-group was ich falsch eingerichtet haben könnte? Eigentlich sehe ich da keine große mgl. Fehlerquelle.

Bin für sachdienliche Hinweise dankbar und hoffe das lesen war nicht zu wirr oder langweilig.
 
Ich sehe da im Moment noch keinen Zusammenhang,
werde das aber morgen mal testen.
 
Wundert mich auch. Klappt aber so zumindest mit 2 Quellen verlässlich


Gesendet von iPhone mit Tapatalk
 
e016e633e3b5f3c78040f30cea01e21b.jpg


Lmao
Hat Amazon echt verschickt

SLOG check

Gesendet von meinem Xperia Z1 Compact mit Tapatalk
 
Zuletzt bearbeitet:
@MaxRink: Gratuliere, klingt ja nicht schlecht. Dann lass mal hören wie die läuft ;)

Ich habe seit einigen Tagen (oder länger) evtl. nachdem ich 151018 drauf habe immer mal wieder, das omniOS mit einem Kernel Panic rebootet.
Das macht sich natürlich dann auch schlecht für die NFS-Datastores, so dass mit einem Mal die VM´s weg sind. In der Konsole der Storage-VM taucht dann so etwas auf:
kernelp.JPG

Selbst wenn ich die Storage VM danach nochmal boote, kommen die NFS-Storage nicht wieder online. Nur ein kompletter Server reboot hilft. pkg update hatte ich vor einigen Tagen erst laufen lassen, in der Hoffnung das da ein Bug schuld sei. Aber gerade ist es wieder passiert. Sehr unschön, gerade wenn es ein 24/7 sein soll. Der ESXI darunter läuft stabil weiter, aber es bleibt unschön.

Mit der Fehlermeldung in der Konsole stehe ich wie der sprichwörtliche Ochse vorm Scheunentor.
Kann da jemand helfen? :wut:
 
Ich würde erst mal den mDNS Dienst deaktivieren.
(z.B. napp-it Menü Services > Bonjour und Autostart)

Der mDNS wird hauptsächlich benutzt um auf Mac Rechnern Dienste bekanntzugeben (Heißt dort Bonjour).
 
Hm, dann finden die Mac´s aber ihre TimeMachine Shares nicht. Das wäre wirklich unschön, wenn es daran liegen sollte :(
Bekommt man den nicht evtl. irgendwie fehlerfrei hingebogen? Ich meine ich hab die beiden Dienste jetzt mal testweise ausgeschaltet ... aber schön ist anders.
 
Ich habe netatalk und AFP schon lange nicht mehr im Einsatz.
Ich habe daher da keinen Tipp.
 
Wir haben nun unser OMNIOS + Napp-it Storage erfolgreich in Betrieb genommen. Die Performance ist sehr gut. In Kürze soll das Storage noch erweitert werden. Der nächste Schritt, wäre eiin Ausfallszenario darzustellen,. Wie läuft dies bei Euch? Wie/Was habt ihr eingerichtet (Stichwort HA Cluster?) Wie sind die Erfahrungen damit?
 
Hm, dann finden die Mac´s aber ihre TimeMachine Shares nicht. Das wäre wirklich unschön, wenn es daran liegen sollte :(
Bekommt man den nicht evtl. irgendwie fehlerfrei hingebogen? Ich meine ich hab die beiden Dienste jetzt mal testweise ausgeschaltet ... aber schön ist anders.

Für TimeMachine-Backup's brauchst Du aber nicht unbedingt netatalk/afp. Es geht mit etwas Handarbeit auch über smb-Freigaben.

Die c't bspw. hatte in der Ausgabe 8/2016 einen Artikel, wo beschrieben ist, wie man es einrichtet. Außerdem sollte googlen nach "Timemachine" und "smb" brauchbare Resultate bringen.
 
Ah danke für den Hinweis. Dachte das geht nur mit Bonjour. Schaue ich mir mal an.


Gesendet von iPhone mit Tapatalk
 
Wir haben nun unser OMNIOS + Napp-it Storage erfolgreich in Betrieb genommen. Die Performance ist sehr gut. In Kürze soll das Storage noch erweitert werden. Der nächste Schritt, wäre eiin Ausfallszenario darzustellen,. Wie läuft dies bei Euch? Wie/Was habt ihr eingerichtet (Stichwort HA Cluster?) Wie sind die Erfahrungen damit?

ZFS ist kein Cluster Dateisystem.
Für die höhere Verfügbarkeit von ZFS Storage oder Diensten gibt es im Wesentlichen folgende Methoden (Ohne banale Sachen wie redundante HBAs in einem System das den Ausfall eines HBA erlaubt, extrem selten nötig)

1. Asyncrone Replikation mit zfs send
Damit wird ein Dateisystem mit einem Dateisystem auf einem anderen Server syncronisiert.
Das erfolgt mit Snapshots und einem Zeitverzug zwischen Original und Kopie bis herunter zu einer Minute - auch bei einem Hochlastserver im Petabyte Bereich.

Beim Ausfall des Hauptsystems stellt das Backupsystem die Daten und Dienste bereit.
Das erlaubt den Ausfall eines Storagesystems (jedoch Zeitverzug und manuelles Umschalten)

2. Dual Head + ein Jbod mit Multipath SAS
Dabei hat man zwei Server die per Multipath auf das gleiche SAS Jbod gehen.
Beim Ausfall eines Heads kann der andere den Pool manuell mounten

Das erlaubt den Ausfall eines Heads

3. Dual Server + Dual Storage mit Mirror übers Netz oder zwei Multipath SAS Jbods
Dabei wird jeweils ein Zvol von zwei Servern per iSCSI Target freigegeben. Ein iSCSI Initator auf einem der Server oder einem separaten Head baut daraus übers Netz einen Mirror.

Mit dual SAS Jbod hat jeder Head Zugriff auf Mirrors über beide Jbod .
Fällt ein Server aus, kann der andere den Pool manuell mounten (im degraded state)

Dies erlaubt den Ausfall eines Heads und/oder eines Jbod


Möchte man das manuell in 2. oder 3. automatisieren braucht man eine active/active HA Software
die automatisch den Storage auf dem zweiten Head mounted und/oder einen Dienst wie NFS oder iSCSI auf dem zweiten Head startet und unter der gleichen IP wie zuvor bereitstellt.

Die professionelle Lösung dazu ist
HA Plugin for ZFS Open Storage Appliance


zfsconfig.jpg
 
Zuletzt bearbeitet:
Apple APFS

Neben den etablierten New Generation Dateisystemen wie netApp Wafl oder ZFS sowie den daraus inspirierten wie btrfs order ReFS gesellt sich jetzt ein weiteres Dateisystem von Apple: APFS, das einige ZFS Aspekte wie CopyOnWrite aufgreift, jedoch auf einiges wie Prüfsummen auf Daten verzichtet - ähnlich wie ReFS in der Default Einstellung, da kann man es aber wenigstens aktivieren.

Adam Leventhal, einer der Entwickler von Dtrace bei Sun hat dazu eine sehr lesenswerte Blogserie verfasst,
in der es auch um Filecheck, Datenintegrität (auf Ebene des Dateisystems wie auf Ebene der RAM oder einzelner Platten), Snapshot und Backup geht.

Adam Leventhal's blog » APFS in Detail: Data Integrity
 
Hallo ich habe schon wiedermal eine Frage,

mir ist mein napp-t gecrashed, also mein pool konnte nicht mehr erreicht werden.

nach neuboot des ESXI Servers sehe ich leider momentan folgende Fehler im Pool.

pool: Data
state: UNAVAIL
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scan: resilver in progress since Sun Jul 3 08:12:26 2016
14.5G scanned out of 12.9T at 639K/s, (scan is slow, no estimated time)
14.5M resilvered, 0.11% done
config:

NAME STATE READ WRITE CKSUM CAP Product /napp-it IOstat mess
Data UNAVAIL 66 0 4.85K insufficient replicas
raidz2-0 UNAVAIL 127 0 9.71K insufficient replicas
c3t5000C50049807259d0 DEGRADED 0 0 0 too many errors 3 TB ST3000DM001-9YN1 S:0 H:0 T:0
c3t5000C50049F749AEd0 DEGRADED 0 0 0 too many errors 3 TB ST3000DM001-9YN1 S:0 H:0 T:0
c3t5000C50049FF9F65d0 DEGRADED 0 0 0 too many errors 3 TB ST3000DM001-9YN1 S:0 H:0 T:0
c3t5000C5004E9247FBd0 DEGRADED 0 0 0 too many errors 3 TB ST3000DM001-9YN1 S:0 H:0 T:0
c3t5000C5004E94E28Fd0 DEGRADED 0 0 0 too many errors 3 TB ST3000DM001-9YN1 S:0 H:0 T:0
c3t5000C5004E94EC17d0 DEGRADED 0 0 0 too many errors 3 TB ST3000DM001-9YN1 S:0 H:0 T:0
c3t5000C5004E96106Ed0 DEGRADED 0 0 0 too many errors 3 TB ST3000DM001-9YN1 S:0 H:0 T:0
c3t5000C5004F401AD1d0 REMOVED 0 0 0 (resilvering) 3 TB ST3000DM001-1CH1 S:0 H:0 T:0
c3t5000C5005241B1A8d0 DEGRADED 0 0 0 too many errors 3 TB ST3000DM001-9YN1 S:0 H:0 T:0
c3t5000C5005DB2217Fd0 DEGRADED 0 0 0 too many errors 3 TB ST3000DM001-9YN1 S:0 H:0 T:0
c3t5000C5005DB256E7d0 REMOVED 0 0 0 3 TB ST3000DM001-9YN1 S:0 H:1 T:8
c3t5000C5005DB282B2d0 REMOVED 0 0 0 (resilvering) 3 TB ST3000DM001-9YN1 S:0 H:1 T:2

errors: 89987 data errors, use '-v' for a list

Da ich leider ein absoulter Laie bin und dies nur ein homeserver ist, nun meine Frage, ist der pool zerstoert? oder kann der wieder aufgebaut werden?

Ich habe leider absolut keine Idee was da los war.

Meine Platten werden als ok angezeigt in der Diskliste.

id part identify stat diskcap partcap error vendor product sn
c2t0d0 (!parted) via dd ok 37.6 GB S:0 H:0 T:0 VMware Virtual disk 6000C2997E5A5A0
c3t5000C50049807259d0 (!parted) via dd ok 3 TB S:0 H:0 T:0 ATA ST3000DM001-9YN1 W1F0FGX8
c3t5000C50049F749AEd0 (!parted) via dd ok 3 TB S:0 H:0 T:0 ATA ST3000DM001-9YN1 W1F0JBNW
c3t5000C50049FF9F65d0 (!parted) via dd ok 3 TB S:0 H:0 T:0 ATA ST3000DM001-9YN1 W1F0LC6N
c3t5000C5004E9247FBd0 (!parted) via dd ok 3 TB S:0 H:0 T:0 ATA ST3000DM001-9YN1 Z1F1BW0D
c3t5000C5004E94E28Fd0 (!parted) via dd ok 3 TB S:0 H:0 T:0 ATA ST3000DM001-9YN1 Z1F1CN5W
c3t5000C5004E94EC17d0 (!parted) via dd ok 3 TB S:0 H:0 T:0 ATA ST3000DM001-9YN1 Z1F1CMNZ
c3t5000C5004E96106Ed0 (!parted) via dd ok 3 TB S:0 H:0 T:0 ATA ST3000DM001-9YN1 Z1F1CFPS
c3t5000C5004F401AD1d0 (!parted) via dd ok 3 TB S:0 H:1 T:3 ATA ST3000DM001-1CH1 Z1F1XHYP
c3t5000C5005241B1A8d0 (!parted) via dd ok 3 TB S:0 H:0 T:0 ATA ST3000DM001-9YN1 W1F0M1X0
c3t5000C5005DB2217Fd0 (!parted) via dd ok 3 TB S:0 H:0 T:0 ATA ST3000DM001-9YN1 W1F1V9W8
c3t5000C5005DB256E7d0 (!parted) via dd ok 3 TB S:0 H:0 T:0 ATA ST3000DM001-9YN1 W1F1S58L
c3t5000C5005DB282B2d0 (!parted) via dd ok 3 TB S:0 H:0 T:0 ATA ST3000DM001-9YN1 W1F1VD6B
c3t50014EE20C2343FEd0 (!parted) via dd ok 4 TB S:0 H:0 T:0 ATA WDC WD40EFRX-68W WDWCC4E2ZPCJT9
c3t50014EE2B6F75416d0 (!parted) via dd ok 4 TB S:0 H:0 T:0 ATA WDC WD40EFRX-68W WDWCC4E6SDR5ZN

Wie immer Dank für eure Hilfe.

LG
 
Zuletzt bearbeitet:
Der ist schon dabei,das bedeutet das resilvern. Aber du solltest rausfinden,warum er das tut. Also wo die Fehler da herkommen.
Betrifft ja scheinbar mehrere Platten.
 
Zuletzt bearbeitet:
Hmm der hängt seit mehr als einer Stunde bei 0,11% done.

ich warte mal ab und lasse das über Nacht mal durchlaufen.

Wie gesgat ich habe leider keien Ahnung warum mir der Pool abgeraucht ist, was für Möglichkeiten hätte ich denn, dies herauszufinden.

Thx für Infos
 
Bei einem ZFS Raid-Z2 passiert folgendes:
- wenn ein oder zwei Platten ausfallen, geht der Pool auf "degraded - egal ob man einfach eine Platte zieht, diese kaputtgeht oder ZFS die Platte wegen "too many errors" aus dem Pool schmeisst. Dabei bleibt der Pool voll funktionsfähig

- Fallen mehr als zwei Platten aus, ist der Pool offline - man hat also keinen Zugriff mehr auf die Daten - der Pool ist verloren.

Das Gute an ZFS Raid. Sobald genügend Platten wieder verfügbar sind, kann man auf den Pool wieder zugreifen. Es ist also kein Problem, wenn mal Platten kurzzeitig weg sind. Ein Pool > Clear Erros und gut.

In diesem Fall, in dem alle Platte Fehler melden, würde ich ein Problem in der Stromversorgung, im HBA oder der Backplane vermuten. Sobald das Problem beseitigt ist, sind alle Daten wieder verfügbar.
 
soll ich napp it nochmals runter fahren und versuchen einen Hardwarefehler zu finden, denn es steht noch immer bei 0,11% reslivering?

Die Diskliste hängt momentan wenn ich sie versuche zu öffnen. Vor 10min wurden noch alle Disks als ok angezeigt.

Thx für die Hilfe
 
Zuletzt bearbeitet:
Wenn die Platten hängen muss man wohl herunterfahren und/oder komplett ausschalte/einschaltenn.
Ich würde vorher noch in System > Log and System > Faults nachschauen ob es da einen Anhaltspunkt gibt.

Eventuell noch auf der Console format aufrufen. Das listet alle Platten und hängt eventuell bei einer.
Fomat nach dem Auflisten der Platten mit ctrl-c beenden.

Wenn dann wieder alles hängt, alle Poolplatten vor dem Neustart ziehen, dann einzeln zustecken und schauen ob sie sich sauber meldet und einen short smartcheck zulässt.
 
Zuletzt bearbeitet:
Du hast also 14 HDD's in einem Gehäuse, davon 12 Desktop HDDs (Seagate Barracuda) und 2 WD-Reds.

Ich verlinke mal
http://www.hardwareluxx.de/communit...tte-fritzbox-6490-a-1122780.html#post24653485

Fazit: die Seagates sind nicht dafür geeignet mit mehr als 1 oder 2 HDDs in einem Gehäuse zu laufen - deswegen heissen sie auch "Desktop-HDD".
Sie sind auch nur für 8h an 5 Tagen die Woche (2400h/Year) gedacht und haben ein relativ geringes workload Rating.
Die Reds sind für 8 HDDs in einem Gehäuse zugelassen

Das nur mal als Anmerkung falls du dich wunderst, daß dein Raidz2 ausgestiegen ist.

Was sagen denn die Smart-Werte der HDDs?
 
Die Seagate Platten sind ja auch schätze ich mal 20-24 Std am Tag im Spin Down Modus, auf dem Pool liegt "nur" meine Emby/Plex Bibliothek.

Die 2 WD Platten sind dagegen fast den ganzen Tag oben.
 
Was sagen denn die Smart-Werte der HDDs?

Du hast recht eine Seagate zeigt mir Smart Errors an.

id diskcap pool vdev state error smart_model smart_type smart_health temp smart_sn smart_selftest smart_check
c2t0d0 rpool basic ONLINE S:0 H:0 T:0 - - - - - -
c3t5000C50049807259d0 Data raidz2-0 DEGRADED S:0 H:0 T:0 ST3000DM001-9YN166 sat,12 PASSED 35 °C W1F0FGX8 without error short long abort log
c3t5000C50049F749AEd0 Data raidz2-0 DEGRADED S:0 H:0 T:0 ST3000DM001-9YN166 sat,12 PASSED 35 °C W1F0JBNW without error short long abort log
c3t5000C50049FF9F65d0 Data raidz2-0 DEGRADED S:0 H:0 T:0 ST3000DM001-9YN166 sat,12 PASSED 36 °C W1F0LC6N without error short long abort log
c3t5000C5004E9247FBd0 Data raidz2-0 DEGRADED S:0 H:0 T:0 ST3000DM001-9YN166 sat,12 PASSED 38 °C Z1F1BW0D without error short long abort log
c3t5000C5004E94E28Fd0 Data raidz2-0 DEGRADED S:0 H:0 T:0 ST3000DM001-9YN166 sat,12 PASSED 36 °C Z1F1CN5W without error short long abort log
c3t5000C5004E94EC17d0 Data raidz2-0 DEGRADED S:0 H:0 T:0 ST3000DM001-9YN166 sat,12 PASSED 37 °C Z1F1CMNZ without error short long abort log
c3t5000C5004E96106Ed0 Data raidz2-0 DEGRADED S:0 H:0 T:0 ST3000DM001-9YN166 sat,12 PASSED 36 °C Z1F1CFPS without error short long abort log
c3t5000C5004F401AD1d0 Data raidz2-0 ONLINE S:0 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 31 °C Z1F1XHYP without error short long abort log
c3t5000C5005241B1A8d0 Data raidz2-0 DEGRADED S:0 H:0 T:0 ST3000DM001-9YN166 sat,12 PASSED 36 °C W1F0M1X0 ERROR short long abort log
c3t5000C5005DB2217Fd0 Data raidz2-0 DEGRADED S:0 H:0 T:0 ST3000DM001-9YN166 sat,12 PASSED 28 °C W1F1V9W8 -- short long abort log
c3t5000C5005DB256E7d0 Data raidz2-0 ONLINE S:0 H:0 T:0 ST3000DM001-9YN166 sat,12 PASSED 31 °C W1F1S58L without error short long abort log
c3t5000C5005DB282B2d0 Data raidz2-0 ONLINE S:0 H:0 T:0 ST3000DM001-9YN166 sat,12 PASSED 30 °C W1F1VD6B without error short long abort log
c3t50014EE20C2343FEd0 Users mirror-0 UNAVAIL - - - - - -
c3t50014EE2B6F75416d0 Users mirror-0 UNAVAIL - - - - - -


id diskcap pool vdev state error smart_model smart_type health temp smart_sn smart_selftest smart_check

Ich habe es so wie gea es emfohlen hat Server neu gestartertet und jede Platte einzeln wieder zurückgesteckt.

Er resilvered jetzt 3 Platten, die anderen im Pool sind momentan noch Degraded.

Soll ich falls der Pool wieder vollständig ist, die eine HDD austauschen, nehme ich mal an, oder?
 
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