[Sammelthread] ZFS Stammtisch

Hallo Leute,

Habe eine kleine Frage: Habe testweise
-> eine leere 64MB Datei mit dd erzeugt
-> aus dieser ein ZFS pool erzeugt
-> Dann ein JPG Foto reingeschoben
-> Pool exportiert
-> Mit einem Hex Editor die "virtuelle Festplatte" modifiziert, also ein paar Bits in den EXIF-Daten gewürfelt und somit die kosmische Strahlung simuliert ;-)
-> Pool reimportiert

Beim Scrubben erkennt ZFS den Fehler, kann den logischerweise nicht reparieren:
Code:
errors: Permanent errors have been detected in the following files:
        /testPool/picture.jpg

Beim Zugriff auf das Foto kommt
Code:
cp: reading `picture.jpg': Input/output error
cp: failed to extend `asd': Input/output error

Im Grunde sind ja nur ein paar Bits in den EXIF verändert worden. Die Foto ist also größtenteils in Ordnung.

Wie kann ich so eine Datei "retten" oder extrahieren? Ich finde es schön, dass ZFS den Checksummen-Fehler bemerkt, aber ich muss ja irgendwie in der Lage sein auch ohne Backup die Datei zu kopieren (samt Fehler). ZFS scheint den kompletten Zugriff zu blocken bei einem Checksum-Error? Kann man das umgehen?
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hallo Leute,

Habe eine kleine Frage: Habe testweise
-> eine leere 64MB Datei mit dd erzeugt
-> aus dieser ein ZFS pool erzeugt
-> Dann ein JPG Foto reingeschoben
-> Pool exportiert
-> Mit einem Hex Editor die "virtuelle Festplatte" modifiziert, also ein paar Bits in den EXIF-Daten gewürfelt und somit die kosmische Strahlung simuliert ;-)
-> Pool reimportiert

Beim Scrubben erkennt ZFS den Fehler, kann den logischerweise nicht reparieren:
Code:
errors: Permanent errors have been detected in the following files:
        /testPool/picture.jpg

Beim Zugriff auf das Foto kommt
Code:
cp: reading `picture.jpg': Input/output error
cp: failed to extend `asd': Input/output error

Im Grunde sind ja nur ein paar Bits in den EXIF verändert worden. Die Foto ist also größtenteils in Ordnung.

Wie kann ich so eine Datei "retten" oder extrahieren? Ich finde es schön, dass ZFS den Checksummen-Fehler bemerkt, aber ich muss ja irgendwie in der Lage sein auch ohne Backup die Datei zu kopieren (samt Fehler). ZFS scheint den kompletten Zugriff zu blocken bei einem Checksum-Error? Kann man das umgehen?

... na ganz einfach mit Redundanz, wäre der Pool als mirror oder raidz angelegt worden, kann das ZFS den Fehler alleine reparieren. ZFS erspart dir NIE ein funktionierendes Backup/Restore.
 
Zuletzt bearbeitet:
Hi,
das ist mir schon klar und darum ging es bei der Frage nicht.

Meine Frage nochmal knapp zusammengefasst:
Wenn es beim Zugriff auf eine Datei im ZFS Dateisystem einen internen Checksum-Fehler gibt und ZFS nicht reparieren kann/es keine Redundanz gibt, dann sperrt ZFS scheinbar den Zugriff auf diese Datei. Wie kann man dann dennoch auf diese Datei zugreifen, im Wissen, das da irgendwo ein Bit umgekippt ist?

(Ich kann mir nicht vorstellen, dass es ZFS einem dann soo schwer macht, dennoch auf die Datei zuzugreifen? --> Bei meinem Beispiel mit den EXIF Daten in einer JPG wäre das Bild ja noch intakt und könnte weiter benutzt werden. Metadaten waren auch nicht betroffen.)

PS: Bei mir summt seit gestern ein 6xHDD RAIDZ2 im Keller und auch davon habe ich noch einmal ein externen Backup ;-) Die Frage ist theoretischer Natur.
 
Zuletzt bearbeitet:
Die Frage ist theoretischer Natur.

In der Tat.
Denn ZFS wurde ja gerade entwickelt, um Datenfehler beim Lesen oder Scrubben sofort und aktuell zu entdecken und umgehend zu reparieren. Fehlerhafte Daten über die man nach Wochen, Monaten oder Jahren zufällig stolpert ohne zu wssen, ob die Daten gut oder schlecht sind (wie bei herkömmlichen Dateisystemen wie ext4, HFS+, oder NTFS üblich bei denen man es oft nur dadurch merkt, dass die Hälfte eines Bildes fehlt) und bei denen man dann versucht noch etwas sinnvolles aus den korrupten Daten zu interpretieren, sind ja explizit nicht Sinn der Übung. ZFS soll ja im Hintergrund reparieren oder sagen, stop, das ist Schrott, bitte Backup einspielen.

Man könnte eventuell jetzt versuchen, checksum zu deaktivieren oder mit dem ZFS Debugger zdb zu arbeiten. Ergebnis: offen, habe ich noch nicht probiert !
 
Zuletzt bearbeitet:
Hallo zusammen,

hatte bis vor kurzem eine napp-it Appliance 14a unter VMware ESXi 5.5 betrieben und nun letzte Woche alles auf neue Beine gestellt.
- ESXi 5.5u2
- frische OmniOS r151012 Installation + VMware Tools 5.5u2
- Napp-it 0.9f1 (Aug.18.2014)
- netatalk
- 2x vmxnet3
- M1015 crossflashed HBA

Folgende Probleme habe ich:
- Mediatomb lässt sich nicht installieren (zwei logs im Anhang)
Zum Test das Ganze mal auf einer .14b versucht, klappt hier auch nicht, liegt also wohl nicht an OmniOS r151012, sondern ist gerade wieder ein generelles Problem? (AMP wurde nicht installiert!)
- smartd scheint nicht automatisch beim Booten zu starten, musste jedenfalls manuell per /etc/init.d/smartd start aktivieren, um nachts meine geplanten Tasks durchführen zu lassen. Seit dem wird zuverlässig jede Nacht entweder ein short oder long run durchgeführt. Läuft seit dem also stabil.
- sleep der HDDs am HBA klappt nicht (mehr), war aber zum Schluss schon unter meiner vorigen 14a (also r151008) so, nachdem es aber mal ne ganze Zeit lang ohne das jemals Änderungen an der Ecke durchgeführt wurden, funktioniert hatte.
- Des Weiteren erkenne ich üble Schreibwerte des SSD-mirrors (2x Crucial M500 480GB), der als ESXi-Datastore dient (zu weniger als 50% belegt)
bonnie-Werte: SSD-Mirror_bonnie.png

Kann jemand ebenfalls von ähnlichen Erfahrungen berichten, hat eine Lösung parat oder mich sonst bei der Problemfindung unterstützen?

Besten Dank
chres
 

Anhänge

  • logs.zip
    25,5 KB · Aufrufe: 70
Zuletzt bearbeitet:
Folgende Probleme habe ich:
- Mediatomb lässt sich nicht installieren (zwei logs im Anhang)
Zum Test das Ganze mal auf einer .14b versucht, klappt hier auch nicht, liegt also wohl nicht an OmniOS r151012, sondern ist gerade wieder ein generelles Problem? (AMP wurde nicht installiert!)

Schau Dir mal bitte diesen Beitrag vom 22.08.2014 an und prüfe das napp-it-Installationslog dahingehend (wenn Du eine napp-it-Version vom 18.08.2014 verwendet hast, wird diese Version das beschriebene Problem noch aufweisen).

EDIT: gea hat das napp-it-Script seinerzeit angepasst, es sollte mW mit der aktuellen Version daher nicht mehr auftreten.
 
Zuletzt bearbeitet:
- smartd scheint nicht automatisch beim Booten zu starten, musste jedenfalls manuell per /etc/init.d/smartd start aktivieren, um nachts meine geplanten Tasks durchführen zu lassen. Seit dem wird zuverlässig jede Nacht entweder ein short oder long run durchgeführt. Läuft seit dem also stabil.

- sleep der HDDs am HBA klappt nicht (mehr), war aber zum Schluss schon unter meiner vorigen 14a (also r151008) so, nachdem es aber mal ne ganze Zeit lang ohne das jemals Änderungen an der Ecke durchgeführt wurden, funktioniert hatte.

- Des Weiteren erkenne ich üble Schreibwerte des SSD-mirrors (2x Crucial M500 480GB), der als ESXi-Datastore dient (zu weniger als 50% belegt)
bonnie-Werte:Anhang anzeigen 299725

1. smartd musste schon immer manuell aktiviert werden
2. mir ist kein generelles Problem bekannt (nutze das aber auch nicht selber)
eventuell mal den Fault Management Service deaktivieren (svcadm disable fmd ) bzw schauen ob sonst etwas regelmäßig auf die Platten zugreift
(z.B. napp-it monitoring und acceleration -> deaktivieren).
3. Die schlechten Schreibraten könnten durch sync=enabled entstehen. Nur sehr gute SSDs können sicheres Schreiben ohne massive Performance-Einbrüche.
Einfach mal den vmware Pool auf sync=disabled stellen und nochmal testen.


ps
Das Mediatomb Problem ist/war übrigens nicht abhängig von der napp-it Version sondern vom wget Installerscript und der Installation von Midnight Commander aus dem pkssrc repository. Der aktuelle Installer sollte das Problem nicht haben.
 
Zuletzt bearbeitet:
wenn Du eine napp-it-Version vom 18.08.2014 verwendet hast, wird diese Version das beschriebene Problem noch aufweisen).
EDIT: gea hat das napp-it-Script seinerzeit angepasst, es sollte mW mit der aktuellen Version daher nicht mehr auftreten.
Habe wget -O - www.napp-it.org/nappit | perl zur Installation ausgeführt. Es sollte also die aktuellste Version, die verfügbar ist, verwendet worden sein. Jedoch dachte ich laut changelog gibt's auch nichts Neueres als napp-it 0.9f1 default vom 18.08?

1. smartd musste schon immer manuell aktiviert werden
Hattest du das in deinen appliances dann schon für uns erledigt gehabt? Da musste ich nämlich nichts ändern. Hab nur die smartdconf angepasst und er hat brav geprüft.

2. mir ist kein generelles Problem bekannt (nutze das aber auch nicht selber)
eventuell mal den Fault Management Service deaktivieren (svcadm disable fmd ) bzw schauen ob sonst etwas regelmäßig auf die Platten zugreift
(z.B. napp-it monitoring und acceleration -> deaktivieren).
OK, danke für den Hinweis. Seh ich mir mal an.

3. Die schlechten Schreibraten könnten durch sync=enabled entstehen.
Ich dachte, dass das nur auftritt wenn "sync writes" gefordert werden, also der ESXi irgendwelche Operationen auf dem Pool ausführt. Bei nem einfachen bonnie bench dürfte sich das doch dann nicht auswirken?

Das Mediatomb Problem ist/war übrigens nicht abhängig von der napp-it Version sondern vom wget Installerscript und der Installation von Midnight Commander aus dem pkssrc repository. Der aktuelle Installer sollte das Problem nicht haben.
Der mediatomb oder der napp-it installer? Aber wie gesagt siehe oben, habe überall die aktuellsten Versionen während der Installation am 23.10 live von deiner Webseite geladen.
 
Hattest du das in deinen appliances dann schon für uns erledigt gehabt? Da musste ich nämlich nichts ändern. Hab nur die smartdconf angepasst und er hat brav geprüft.

Nein, auch bei der appliance läuft nur ein Standardsetup vom smartmontools per wget installer


Ich dachte, dass das nur auftritt wenn "sync writes" gefordert werden, also der ESXi irgendwelche Operationen auf dem Pool ausführt. Bei nem einfachen bonnie bench dürfte sich das doch dann nicht auswirken?

Bei sync=default macht ESXi over NFS sync writes, ein lokales Bonnie nicht.
Bei sync=always wird immer sync write benutzt.

Ansonsten mal iostat auf den Platten auf Auffälligkeiten/ Unterschiede beider SSDs beobachten.

Der mediatomb oder der napp-it installer? Aber wie gesagt siehe oben, habe überall die aktuellsten Versionen während der Installation am 23.10 live von deiner Webseite geladen.

Das Problem war der napp-it Installer beim Installieren von Midnight Commander.
Wenn es aktuell aber nicht geht, so gibt es eine andere Unverträglichkeit aufgrund der Abhängigkeiten von Mediatomb. Eventuell kann zos vielleicht was dazu sagen.

Als Alternative gibt es noch den servioo Mediaserver
napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana, Solaris and Linux : Extensions
 
Nein, auch bei der appliance läuft nur ein Standardsetup vom smartmontools per wget installer
ok, dann einfach ein startscript unter /etc/rc3.d/ oder?

Bei sync=default macht ESXi over NFS sync writes, ein lokales Bonnie nicht.
Bei sync=always wird immer sync write benutzt.
Habe hier die default setting sync=standard, dann dürfte sich das also nicht so extrem darstellen. Werde mal schauen was ich mit iostat sehe.


mediatomb oder eine Alternative packe ich im schlimmsten Fall dann halt in ne VM.
 
Nutzt jemand OmniOS in Verbindung mit Offline Dateien unter Windows? Spricht irgendwas dagegen oder gibt es schlechte Erfahrungen damit?
 
Ich versteh die Berechnung der Kapazität eines RaidZ2 nicht: Ich habe 6 x 1,5 TB unter ZFS Guru laufen: 8,12TB, es sollten aber nur 6TB sein, das Raid ist jetzt auch mit 7,86TB belegt, compression ist an aber bei 1,04.
 
Wie ist denn die Ausgabe von

zpool status
zfs list poolname
 
zfsguru.bsd$ zpool status
pool: bigtank
state: ONLINE
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 Tue Nov 4 18:48:01 2014
5.92T scanned out of 7.77T at 66.2M/s, 8h10m to go
1007G resilvered, 76.10% done
config:

NAME STATE READ WRITE CKSUM
bigtank ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
gpt/zfs2 ONLINE 0 0 0
gpt/zfs5 ONLINE 0 0 0
gpt/zfs3 ONLINE 0 0 0
gpt/zfs6 ONLINE 0 0 0
replacing-4 ONLINE 0 0 0
gpt/zfs1 ONLINE 0 0 0
label/tank1 ONLINE 0 0 0 (resilvering)
gpt/zfs4 ONLINE 0 0 0
logs
gpt/btl ONLINE 0 0 0
cache
gpt/btc ONLINE 0 0 0

errors: No known data errors

zfsguru.bsd$ zpool list bigtank
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
bigtank 8.12T 8.00T 130G 98% 1.00x ONLINE -
 
Es ist ein Z2
das passt!

Ein
zpool list
zeigt die Kapazität (in TiB) ohne Redundanz
(also einfach die Summe der Einzelplatten, sowas wie 6 x 1,5TB = 9 TB = 8,1 TiB = 8,1 T in ZFS)
das passt!

Ein
zfs list -o used,available bigtank
sollte nun als Summe die tatsächlich nutzbare Kapazität (in TiB) zeigen.
(ohne Compress oder Dedup)

Was zeigt dieser Befehl?
Zu erwarten wären 6 TB (9 TB - 3 TB Redundanz) = 5,4 TiB = 5,4T in ZFS
 
Zuletzt bearbeitet:
Hallo!
Ich hätte mal eine konkrete Frage zu einem ZFS Setup und wollte dafür keinen eigenen Thread beginnen, weil die Thematik wie ich finde hier besser aufgehoben ist, aber bitte korrigiert mich, wenn ich falsch liege.
Die Empfehlungen sagen ja für RAIDZ-1 (2 + 1, 4 + 1, 8 + 1), RAIDZ-2 (2 + 2, 4 + 2, 8 + 2, 16 + 2), RAIDZ-3 (2 + 3, 4 + 3, 8 + 3, 16 + 3).
Jeder sagt verschiedenes was die Sicherheit/Parität angeht und ich bin mir mittlerweile nicht wirklich sicher was sinnvoll ist.

Angenommen ich habe 12 Festplatten (in einem entsprechenden 4H Case wäre folglich für 2 VDEVs Platz) als Ausgangsbasis, dann wäre vermutlich unter Berücksichtigung möglicher Ausfälle beim Resilver-Prozess RAIDZ-3 mit 11 Festplatten am sinnvollsten.
Das klingt für mich grundsätzlich auch ganz okay, aber wenn ich dann berücksichtige, dass ich den Pool irgendwann erweitern möchte, dann muss ich 11 Festplatten auf einmal austauschen, was zeitaufwendig und teuer ist (kurzer Zeitraum für Anschaffung).
Zusätzlich um mal von der aktuellen Situation auszugehen sind im Moment 6TB Laufwerke durchaus attraktiv was die Sicht auf den Preis/Kapazität betrifft. Bei diesen Größen steigt doch auch die Wahrscheinlichkeit, dass in der Zeit eine weitere Festplatte ausfällt, zumal die Geschwindigkeit nicht linear zur Kapazität bzw. in den letzten Jahren marginal, wenn überhaupt, gestiegen ist.

Das bringt mich wieder weg von der Idee auf ein RAIDZ-3 mit 2x 11 Festplatten zu setzen und stellt mich vor die Frage ob nicht z.B. 4x RAIDZ2 mit je 6 Festplatten sinnvoller, ist hinsichtlich Erweiterbarkeit/Anschaffung.
Meine Angst bei dem 4x RAIDZ2 ist dann eher, dass mir eines davon (beim Resilvern) ausfällt und der ganze Pool mit allesamt den Daten flöten geht. Parität ersetzt kein Backup, ich weis, das möchte ich allerdings hier nicht näher diskutieren, mir geht es eher um die Verfügbarkeit auf diesem System.

Ich wäre euch um eure Meinungen, Empfehlungen und Sicht auf die Sache dankbar.
 
zfsguru.bsd$ zfs list -o used,available bigtank
USED AVAIL
5.33T 9.62M

passt, danke an gea

@Macer89: Genau aus diesen Überlegungen heraus habe ich mich für 6 Platten a 3TB als RaidZ2 entschieden. Zum Testen arbeite ich momentan mit 6 Partitionen a 1,5 TB (da will ich jetzt nicht näher drauf eingehen), der Austausch einer Platte hat jetzt bei mir 33h gedauert. Kannst ja mal grob überschlagen was der Austausch von 12 Platten an Zeit kostet. Vorteil ZFS (unter BSD/ZFSGuru, solllte aber generell gelten): Das Raid ist während des resilverns voll benutzbar, ich habe sogar weiter befüllt, ohne Probleme, ZFS ist echt rocksolid. Respekt!
 
Zuletzt bearbeitet:
Macer, vielleicht wirfst du uns mal ne Ziel-Kapazität vor die Füße, das würde helfen. 2x11x6TB ist für den Privatgebrauch recht pervers, ist das denn geschäftlich, und wenn ja, wie schauts mit den Performanceanforderungen aus? Gehäuse vorhanden (welches?) oder wird noch gekauft?
Ich würd mal gestripte Z2/3 aus 6/7 Festplatten vorschlagen - halbweg akzeptabler Verbrauch für Parität, relativ fix reihum tauschbar, und wenn du wirklich mit 6TB bestücken willst, immerhin noch ne erklärbare Nutzkapazität von 24TB pro Stripe.

Da gabs doch mal ne Simulation, wo rauskam, dass ein Z3 quasi nicht totzukriegen ist...WENN die Ausfälle statistisch unabhängig voneinander sind. Da wir das eh nicht erreichen, sollte deine zweite Frage nach der Plattenkonfiguration sein: Wo kaufe ich ein Rudel Festplatten, das aus möglichst vielen verschiedenen Fabriken unterschiedlicher Hersteller an unterschiedlichen Zeiten im Jahr kam?
 
@ zotty
Danke für die ungefähren Zahlen! 33h für eine Platte ist schon ein ordentlicher Wert, da machen mehrere kleine VDEVs durchaus Sinn.
Die Info mit dem Weiterbenutzen während des Resilverns ist auch nicht schlecht ;)

@ Bzzz
Wider deiner Vermutung ist es doch für den Privatgebrauch ;)
Eine konkrete Zielkapazität schwebt mir nicht vor, aktuell schaffe ich es immer wieder mich mehr schlecht als recht mit meinen 2 RAID 6 mit ~ 10TB Nettokapazität durchzuschlagen. Die Grenzen dieses Systems sind bald erreicht und ich überlege eh schon seit einiger Zeit eine sinnvolle Ablöse zu finden die dann halt auch wieder für längere Zeit vorhält bzw. leicht erweiterbar ist. Beim alten System habe ich leider zu wenig auf diese Aspekte geachtet :(
Ich denke eine doppelte Kapazität des jetzigen Systems wäre schon toll, dann hätte ich die nächsten Jahre genug Reserven (auch hinsichtlich 4K etc).

Gehäuse ist nur ein alter Desktop-Tower vorhanden, mir würde aber ein Inter-Tech 4U-4324L in den Sinn kommen. Performance ist nicht so wichtig, wenn es für sag ich mal 1-5 Leute die Daten übers Netz bereitstellen kann ist es okay. Aber gerade weil es für den Privatgebrauch ist möchte ich halt auch die größtmögliche Kapazität mit einem vertretbaren Verbrauch für Parität haben.

Die Frage mit dem Kaufen ist natürlich auch sehr interessant, das wird eine Herausforderung bzw. werde ich da wohl eher dem Zufall vertrauen müssen.
 
Ich hatte vor einiger Zeit sogar nach der Praxisrelevanz von 16+3 Raidz3 gefragt, auch sowas wird nach Auskunft vom Gea eingesetzt.
So ein System wird dann auch nicht mehr erweitert sondern ggf ersetzt, wenn mehr Kapazität erforderlich wird - würde ich zumindest mal behaupten.
Ich hätte jedenfalls ein ungutes Gefühl dabei über mehrere Wochen nacheinander 19 Platten auszutauschen, um die Kapazität zu vergrössern.

Ich bin gegenwärtig dabei so ein System aufzubauen - dauert aber noch.
X-Case RM 424 -Gen II ist schon da
Silence Rack kommt wohl in KW 49
Im Dezember wird dann die Hardware (Mainboard etc) gekauft und zusammen gebaut
Im Januar kommen dann 24 x 5 TB (oder 6 TB) Platten rein (kommt ein wenig auf die Preisentwicklung bis dahin an)
Das ganze wird dann 16+3 Raidz3 als Datenarchiv (reines Datengrab für nicht zu sichernde Daten) und 4+1 Raidz1 als Backup für ein weiteres NAS (ebenfalls 4+1 Raidz1 für persönliche Daten, Fotos, Videoaufnahmen etc.)
Laufen wird das System nur bei Bedarf.

Sollte das Raidz3 tatsächlich entgegen der statistischen Wahrscheinlichkeit für Datenverlust auf Grund von Festplattenausfällen hops gehen, brauch ich zwar ein grosses Beisholz, aber es wäre letztendlich nicht gar sooo schlimm.
Die Wahrscheinlichkeit von Blitzschlag, Hochwasser, Feuer sehe ich im obrigen deutlich niedriger als die Wahrscheinlichkeit, daß eine Festplatte ausfällt, die liegt nämlich bei 100 % über einen unbekannten Zeitraum.
Das einzige Netzteilproblem hatte ich bislang mit einem BeQuiet, das ist zwar mit einem Kurzschluss hochgegangen, hat aber keine dranhängende Hardware mitgerissen, daher bewerte ich auch dies Wahrscheinlichkeit niedriger als den Festplattenausfall.


Achja, Festplatten wollte ich eigentlich gerne die HGST NAS Platten (7200er) reinhängen, nachdem diese aber laut technischen Daten schon 7,3 Watt im IDLE verbrauchen sollen und die WD-Reds (5400er) da bei 3,4 Watt liegen und dazu günstiger sind bin ich am Schwanken. Performancetechnisch erwarte ich da keinen Unterschied via GBit-LAN - beim Scrubbing oder Resilvern allerdings schon.
24x7,3 Watt = 175,2 Watt
24x3,4 Watt = 81,6 Watt
 
Zuletzt bearbeitet:
Die Wahrscheinlichkeit von Blitzschlag, Hochwasser, Feuer sehe ich im obrigen deutlich niedriger als die Wahrscheinlichkeit, daß eine Festplatte ausfällt, die liegt nämlich bei 100 % über einen unbekannten Zeitraum.

Abgesehen vom Hochwasser an geeigneten Standorten (dafür: Rohrbruch, Loch im Dach) ist das bei den anderen auch bei 100%, und seis erst, wenn uns die Sonne netterweise entgegen kommt ;)

Das einzige Netzteilproblem hatte ich bislang mit einem BeQuiet, das ist zwar mit einem Kurzschluss hochgegangen, hat aber keine dranhängende Hardware mitgerissen, daher bewerte ich auch dies Wahrscheinlichkeit niedriger als den Festplattenausfall.
Seh ich ähnlich. Nur: Ein defektes NT kann auch ein "unzerstörbares" System aus 42 Spiegelplatten mitnehmen, und zwar komplett und vollständig und instantan. Mir fällt zwar auch keine Gegenmaßnahme außer einem hochwertigen NT und Hoffen auf montagsfreie Verarbeitung ein, aber hey: Wer allein für einen mittleren vierstelligen Betrag Festplatten einkauft und dann nen Zehner beim NT spart, dem gehörts auch irgendwie nicht anders.
 
Man könnte sich natürlich, wenn man denn schon soviel Geld in die Hand nimmt und sich dann Gedanken über Netzteilausfälle macht, auch bei Server-Netzteilen umsehen. Dort ist Redundanz oder sogar doppelte Redundanz ja Standard.
 
Gegen Ausfälle, sprich für Uptime, ja. Aber wenn eins Harakiri begeht und dir 230V auf die 12V-Leitung legt, wird das andere das nicht kompensieren können. Ähnlich wie Digi-Quick betreib ich meinen Kram auch nur on-demand im Einzeluserbetrieb, wenns halt wegen kaputtem NT mal nicht geht...so what. Es sind keine Geschäftsdaten drauf, deren Nichtverfügbarkeit mir zehntausende € am Tag kostet. Wir möchten nur eine möglichst hohe MTTBR - Mean Time To Backup Restore ;)
 
wie schon gesagt, das wichtige wird auf 2 System gesichert, die beide nur laufen wenn sie gebraucht werden.
"Arbeitsdaten" liegen zusätzlich auf dem jeweiligem PC Lokal, zumindestens bei Videosschnittprojekten sinnvoll - hier wäre das GBit-LAN ein Flaschenhals.

Das Datenarchiv selbst würde zum grössten Teil wiederbeschaffbar sein....

Achja, 100%ige Sicherheit gibt es nicht, man kann sich ihr nur immer weiter Annähern zu entsprechend immer höheren Kosten
 
Zuletzt bearbeitet:
Das Problem war der napp-it Installer beim Installieren von Midnight Commander.
Wenn es aktuell aber nicht geht, so gibt es eine andere Unverträglichkeit aufgrund der Abhängigkeiten von Mediatomb. Eventuell kann zos vielleicht was dazu sagen.

Habe heute eine neue VM aufgebaut:
(1) OmniOS r151012 installiert
(2) napp-it 0.9f1 installiert
(3) Mediatomb installiert und unter <serverip>:50500 erfolgreich aufgerufen

@ces: Mediatomb konnte ich auch nach allen unten stehenden Schritten (a)-(f) weiterhin erfolgreich aufrufen, daher kann ich leider nicht abschätzen, was genau bei Dir schief gelaufen ist.

Außerdem aktualisiert und ohne Fehler getestet
(a) AMP (pkgsrc 2014Q3, Apache 2.4.10, mySQL 5.6.20, PHP 5.5.18, phpMyAdmin 4.2.11)
(b) VirtualBox (Oracle VirtualBox 4.3.18, phpVirtualBox 4.3-1)
(c) ownCloud 7.0.2
(d) Pydio 5.2.5

Nicht aktualisiert (da keine neuen Versionen vorhanden) aber ebenfalls in o.a. VM ohne Fehler getestet:
(e) Baikal CalDAV/CardDAV-Server 0.2.7
(f) Serviio UPnP/DLNA-Server 1.4.1.2 (WebUI 1.4)

@gea: Du kannst die aktualisierten Scripte (a)-(d) gern auf napp-it.org online stellen.
 
Zuletzt bearbeitet:
@ces: Mediatomb konnte ich auch nach allen unten stehenden Schritten (a)-(f) weiterhin erfolgreich aufrufen, daher kann ich leider nicht abschätzen, was genau bei Dir schief gelaufen ist.
Ok, dann werd ich's mir nochmal in einer neuen VM angucken.
Gab's irgendwelche Besonderheiten zu beachten bei der OmniOS r151012 Installation?

Hab sowieso ein Problem mit meiner aktuellen Installation. Ist nicht stable bei IO-Last auf dem Netzwerkinterface. Bei nem zfs-send an ne weitere Büchse (native OmniOS + napp-it-Installation auf nem HP Microserver G8), die als reine ZFS-Backup-Maschine gedacht ist.
Bekomme hier ne kernel panic auf dem VM-System (Basis: Supermicro X10SLH-F, IT-flashed M1015, Crucial DDR-1600L). Hatte bislang noch keine Zeit, dem Ganzen auf den Grund zu gehen. Die VM läuft, wie weiter oben beschrieben unter ESXi 5.5u2 und wurde mit gepatchten VMware Tools ausgestattet, so dass die Solaris 11 vmxnet3-Treiber verwendet verwenden und Jumboframes wurden aktiviert. Das Ganze allerdings nur auf der 2ten rein virtuellen Netzwerk-Schnittstelle, die per NFS den Datastore dem darunterliegenden ESXi zur Verfügung stellt. Sollte sich also eigentlich nicht auf die physikalische Verbindung auswirken?!

Wie haben sich den die damals schon genannten und aufgetretenen Probleme mit vmxnet3 geäußert? War das "Ergebnis" auch ne kernel panic?
Bei der vorigen ESXi 5.5u1 Installation mit gea's 14a appliance hatte ich noch nie ne kernal panic, jedoch hatte ich damit auch noch kein zfs-send an ne andere Maschine versucht, was schon ordentlich traffic erzeugt. Dummerweise habe ich an zu vielen Stellen parallel geschraubt und kann nun schlecht einschätzen, wo's wirklich klemmt.

Wie gehe ich am Besten vor um den kernel dump zu analysieren und den Verantwortlichen zu finden?
 
Wie gehe ich am Besten vor um den kernel dump zu analysieren und den Verantwortlichen zu finden?

Ausgehend von einer Minimalkonfiguration (keine Tools, e1000, keine Jumbo Frames etc)
eine Replication (wenn da das Problem auftritt) laufen lassen.

Dann einzelne Features hinzufügen und schauen wann es Probleme gibt.
 
Ich möchte mir für meine Backups eine externe 3TB USB-3 Platte zulegen, die dann unter ZFS laufen soll (ein Pool, ein Dataset mit Komprimierung). Jetzt hab ich gelesen, dass manche USB-3 Controller der externen Festplatten eine 4K Emulation machen, was wohl problematisch sein kann. User haben berichtet, dass wenn sie die gefüllten Platten aus dem externen Gehäuse ausgebaut haben und intern weiter betreiben wollten, sie keinen zugriff mehr auf die Daten hatten.

Frage: Muss ich da auf etwas achten beim Kauf, gerade in bezug auf den Einsatz mit ZFS? Oder hat jemand Erfahrung in dem Bereich und kann mir hierzu etwas genaueres sagen?
 
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