[Sammelthread] Proxmox Stammtisch
- Ersteller GrafikTreiber
- Erstellt am
Ich geb einfach ein ZFS Dataset per mount bind in ein LXC hoch, der macht dann NFS und CIFS Server...
Backup läuft direkt auf dem Proxmox (von einem Mirror auf einen anderen)...den Rest steuer ich aus den Containern heraus. Bei Samba/ZFS/LXC bitte beachten
Backup läuft direkt auf dem Proxmox (von einem Mirror auf einen anderen)...den Rest steuer ich aus den Containern heraus. Bei Samba/ZFS/LXC bitte beachten
Zuletzt bearbeitet:
luckyspiff
Experte
- Mitglied seit
- 09.08.2015
- Beiträge
- 140
Ok, nur wie machst Du das dann mit dem Storage für die VMs, die "neben" OMV liegen? Geht ja dann nur im Proxmox-Filesystem oder reichst Du das per NFS / iSCSI weiter?
Ich geb einfach ein ZFS Dataset per mount bind in ein LXC hoch, der macht dann NFS und CIFS Server...
Backup läuft direkt auf dem Proxmox (von einem Mirror auf einen anderen)...den Rest steuer ich aus den Containern heraus. Bei Samba/ZFS/LXC bitte beachten
Von dem ZFS/CIFS/ACL-Bug hab ich schon gehört, ich wusste gar nicht, dass es einen Workaround gibt, cool!
So werde ich es wohl auch machen. Ich nehme an Backup lässt sich nicht in den LXC verlagern, weil "zfs send/receive" nur auf der Proxmox-Ebene funktionieren...
Wie ist es mit solchen Sachen wie S.M.A.R.T.-Monitoring der HDDs, das geht vermutlich auch nur auf Proxmox-Ebene? Würde mir gerne per E-Mail berichte schicken lassen, dazu muss ich dann ja auch ssmtp einrichten, oder hat Proxmox da schon was? Die Reports könnte man natürlich auch alle in einem Directory ablegen und den EMail-Send-Job in einem Container, aber ist es die Mühe wert? Oder macht man das inzwischen alles mit Nagios oder Icinga? Kommt mir für ein NAS reichlich Overkill vor...
Danke Euch! Gibt's noch mehr "sinnvolle" Setups oder vielleicht Tipps, die die Einrichtung erleichtern? Vielleicht so ein "webmin für Proxmox"?
tobis72
Experte
Hab mal mit Virtualbox und Proxmox rumexperimentiert. Virtual in Virtual, bizarr. Hab mir per CLI einen pool angelgt eine XP-VM drauf und dann in der Virtualbox eine Platte weg und wieder eine angelegt. Von DEGRADED über replace hat alles super geklappt. Hoffe das lüpt beim "real" Server auch so. Meine Frage ist nur wie bekomme ich raus ohne das ich es händisch über zpool status abfage, daß ein pool DEGRADED ist? Gibts da ein Scipt, oder wie löst ihr das
luckyspiff
Experte
- Mitglied seit
- 09.08.2015
- Beiträge
- 140
Ist mir mal mit FreeNAS "in echt" passiert, das hat er mir dann per E-Mail gesagt, sehr praktisch (kann einem aber auch das Frühstück versau'n, wenn der Tag mit einer kaputten Platte anfängt ;-)
Mit ZFS on Linux geht das aber auch, macht der ZED (ZFS Event Daemon), Du musst Deine E-Mail in /etc/zfs/zed.d/zed.rc eintragen und natürlich so konfigurieren, dass er auch "raus kommt" (z.B. mit ssmtp).
Benutze eine SSD im System die Bootet und darauf liegen auch alle VM´s.
tobis72
Experte
Hi Folks,
hab mich mal der Email-notification angenommen. Hab ssmtp nachinstalliert und konfiguriert. Die Testmail über ssmtp geht super durch. Nur die übergabe vom ZFS Event Deamon funzt net. Platte raus Zpool DEGRADED aber keine Email. Hab in /etc/zfs/zed.d/zed.rc
ZED_EMAIL_ADRR="meine@email.de"
und
ZED_EMAIL_PROG="ssmtp"
eingetragen. Leider kommt nix an, any suggestions?
Zuletzt bearbeitet:
luckyspiff
Experte
- Mitglied seit
- 09.08.2015
- Beiträge
- 140
Ich kann nur raten... liegt ssmtp im Standard-Pfad? Ggf. mal absoluten Pfad eintragen. Soweit ich weiß, muss man bei ssmtp für alle User die E-Mail separat konfigurieren, vielleicht benutzt ZED nur den falschen User?
Einfach mal ein Skript als ZED_EMAIL_PROG eintragen was die Argumente mit User-ID und Zeitstempel in ein logfile schreibt, dann weißt Du schon mal, ob ZED überhaupt was aufruft und es ggf. an den Parametern liegt.
ZED-Email hab ich selbst selbst noch nicht eingerichtet, aber so in etwa würd' ich das Problem wohl eingrenzen...
Zuletzt bearbeitet:
tobis72
Experte
...das ist für euch Linuxianer wohl kein Problem, aber da hängt das bei mir schon
Code:
vi /usr/local/bin/test.sh
Code:
i drücken
das script aus dem nächsten Block unten einfügen
:wq tippen
Code:
#!/bin/bash
echo "$(date): $USER called script with parameters $@" >> /tmp/test.log
Code:
chmod +x /usr/local/bin/test.sh
Code:
...
ZED_EMAIL_PROG="/usr/local/bin/test.sh"
...Dann kannst du mit
Code:
tail -f /tmp/test.logschauen, was und ob und wie aufgerufen wird.
tobis72
Experte
Hi morph, danke! Das ist ja ein Service. Da muss ich nur noch rein-Guttenbergen.
Hab schonmal ein email-Script als Programm in die Zed.rc eingetragen und da passierte auch nichts. Ich hab das alles nach Deinen Vorgaben gemacht, jedoch bleibt die /tmp/test.log leer bzw. wird nix angelegt.
Mein pool ist über "zpool list" DEGRADED und ich hab in der Zed.rc
"ZED_NOTIFY_INTERVAL_SECS" auskommentiert und auf 60 gestellt.
Das script sollte also alle 60 sekunden aufgerufen werden. Ich dachte mir schon, dass da einfach nix angestossen wird aber warum? Wie kann ich den ZED status abfragen?
Mein
Hab schonmal ein email-Script als Programm in die Zed.rc eingetragen und da passierte auch nichts. Ich hab das alles nach Deinen Vorgaben gemacht, jedoch bleibt die /tmp/test.log leer bzw. wird nix angelegt.
Mein pool ist über "zpool list" DEGRADED und ich hab in der Zed.rc
"ZED_NOTIFY_INTERVAL_SECS" auskommentiert und auf 60 gestellt.
Das script sollte also alle 60 sekunden aufgerufen werden. Ich dachte mir schon, dass da einfach nix angestossen wird aber warum? Wie kann ich den ZED status abfragen?
Mein
luckyspiff
Experte
- Mitglied seit
- 09.08.2015
- Beiträge
- 140
Mach doch mal ein "ps auxww" und schau, ob ein Prozess "zed", "zeventd" oder so läuft ("ps auxww | grep ze" ist Dein Freund). Vielleicht muss man den ZED erst starten (oder "systemd enablen"). Ich hab kein System zur Hand, schau bei Gelegenheit mal nach, wie das bei mir ist, hab mich bisher noch nicht damit beschäftigt...
Zuletzt bearbeitet:
luckyspiff
Experte
- Mitglied seit
- 09.08.2015
- Beiträge
- 140
Ok, ich schau mir das gerade mal bei mir an, ist genau das gleiche (kein Wunder, sind ja auch im Proxmox-Fred).
Wenn der zed läuft, sollte er auch arbeiten. In der Manual-Page ("man zed") ist aber von E-Mail gar nichts erwähnt, evtl. hat sich das Verhalten mit einer neuen Version auch geändert. Da gibt's jetzt Skripte, die bei bestimmten Events ausgeführt werden, die ZEDLETS. Die aktiven ZEDLETS sind in /etc/zfs/zed.d.
Die E-Mail Funktion wurde offenbar im Februar in das Skript generic-notify.sh gesteckt, für das (bei mir) aber kein symbolischer Link in /etc/zfs/zed.d erstellt ist. Möglicherweise reicht es in diesem Verzeichnis "ln -s /usr/lib/x86_64-linux-gnu/zfs/zed.d/generic-notify.sh ." einzugeben, damit der Link erstellt wird. Vielleicht ist auch mehr nötig, hab gerade keine Zeit das auszuprobieren, vielleicht schau ich später nach...
Hier der Kommentar des entsprechenden Git-Commits (Open-Source ist was schönes
):
Wenn der zed läuft, sollte er auch arbeiten. In der Manual-Page ("man zed") ist aber von E-Mail gar nichts erwähnt, evtl. hat sich das Verhalten mit einer neuen Version auch geändert. Da gibt's jetzt Skripte, die bei bestimmten Events ausgeführt werden, die ZEDLETS. Die aktiven ZEDLETS sind in /etc/zfs/zed.d.
Die E-Mail Funktion wurde offenbar im Februar in das Skript generic-notify.sh gesteckt, für das (bei mir) aber kein symbolischer Link in /etc/zfs/zed.d erstellt ist. Möglicherweise reicht es in diesem Verzeichnis "ln -s /usr/lib/x86_64-linux-gnu/zfs/zed.d/generic-notify.sh ." einzugeben, damit der Link erstellt wird. Vielleicht ist auch mehr nötig, hab gerade keine Zeit das auszuprobieren, vielleicht schau ich später nach...
Hier der Kommentar des entsprechenden Git-Commits (Open-Source ist was schönes
):
Code:
Replace "email" ZEDLETs with "notify" ZEDLETs
Several ZEDLETs already exist for sending email in reponse to a
particular zevent. While email is ubiquitous, alternative methods may
be better suited for some configurations. Instead of duplicating the
"email" ZEDLETs for every future notification method, it is preferable
to abstract the notification method into a function. This has the
added benefit of reducing the amount of code duplicated between
ZEDLETs, and allowing related bugs to be fixed in a single location.
This commit replaces the existing "email" ZEDLETs with corresponding
"notify" ZEDLETs. In addition, the ZEDLET code for sending an
email message has been moved into the zed_notify_email() function.
And this zed_notify_email() has been added to a generic zed_notify()
function for sending notifications via all available methods that
have been configured.
This commit also changes a couple of related zed.rc variables.
ZED_EMAIL_INTERVAL_SECS is changed to ZED_NOTIFY_INTERVAL_SECS,
and ZED_EMAIL_VERBOSE is changed to ZED_NOTIFY_VERBOSE. Note that
ZED_EMAIL remains unchanged as its use is solely for the email
notification method.
Signed-off-by: Chris Dunlap <cdunlap@llnl.gov>
Zuletzt bearbeitet:
luckyspiff
Experte
- Mitglied seit
- 09.08.2015
- Beiträge
- 140
So, ich hab gerade noch mal die Manual-Page (man zed) überflogen und ein wenig herumgespielt. Ergebnis:
- muss man nach Änderungen in den /etc/zfs/zed.d Skripten ein "systemctl restart zfs-zed" eingeben, damit diese ohne Neustart wirksam wird
- Ein Skript mit dem Namen des Events anfangen, z.B. scrub.start-notify.sh für den Event scrub.start (den Symlink also entsprechend benennen)
- Es gibt einen "Pseudo-Event" "all", der immer zieht, das Skript all-syslog.sh schreibt die Events ins Syslog (nach) /var/log/syslog, dort kann man also die Event-Namen finden
- Für die wichtigsten Events sind schon Skripten hinterlegt, die etwas sinnvolles tun (diverse Fehler, Scrub/Resilvern fertig, etc.) Bei einem im Pool vorhandenem Hot-Spare-Drive, wird dieses automatisch eine defekte HDD ersetzen, wenn ein Fehler erkannt wird
- Es wird nicht nur eine E-Mail generiert sondern ein Popup-Notify abgesetzt, natürlich nicht in Proxmox sondern bei entsprechenden Desktop-Environments.
Ich hoffe das hilft und es klappt jetzt mit der E-Mail!
- muss man nach Änderungen in den /etc/zfs/zed.d Skripten ein "systemctl restart zfs-zed" eingeben, damit diese ohne Neustart wirksam wird
- Ein Skript mit dem Namen des Events anfangen, z.B. scrub.start-notify.sh für den Event scrub.start (den Symlink also entsprechend benennen)
- Es gibt einen "Pseudo-Event" "all", der immer zieht, das Skript all-syslog.sh schreibt die Events ins Syslog (nach) /var/log/syslog, dort kann man also die Event-Namen finden
- Für die wichtigsten Events sind schon Skripten hinterlegt, die etwas sinnvolles tun (diverse Fehler, Scrub/Resilvern fertig, etc.) Bei einem im Pool vorhandenem Hot-Spare-Drive, wird dieses automatisch eine defekte HDD ersetzen, wenn ein Fehler erkannt wird
- Es wird nicht nur eine E-Mail generiert sondern ein Popup-Notify abgesetzt, natürlich nicht in Proxmox sondern bei entsprechenden Desktop-Environments.
Ich hoffe das hilft und es klappt jetzt mit der E-Mail!
tobis72
Experte
Hi luckyspiff, danke für Deine Antwort. Das mit dem Neustart wusste ich. Kannte den Befehl nicht "systemctl restart zfs-zed", gut zu wissen. Hab einfach nach Änderungen in der zed.rs die VM neu gestartet.
Leider steig ich beim Rest aus
luckyspiff
Experte
- Mitglied seit
- 09.08.2015
- Beiträge
- 140
Im Grunde ist es ganz einfach: In /etc/zfs/zed.d liegen Skripten, die bei gewissen ZFS-Ereignissen ausgeführt werden, wenn sie mit dem Ereignis-Namen anfangen, z.B. wird "resilver.finish-notify.sh" ausgeführt, wenn das "resilver.finish" Ereignis eintritt, ZFS also nach dem Tausch einer Platte aus einem Mirror/RaidZ die neue Platte fertig befüllt hat. Wichtig ist nur, dass der Name des Skriptes mit dem Ereignis-Namen beginnt und dann soll ein Nicht-Buchstaben-Zeichen kommen, das Skript könnte also auch resilver.finish_foobar heißen, die Endung "-notify.sh" ist nur eine sinnvolle Konvention.
Diese Skripten nennen sich ZEDLETS und Du kannst sie natürlich komplett selbst schreiben. Aber wenn es nur um die Meldung eines Ereignisses als E-Mail geht, kannst Du das fertige Skript /usr/lib/x86_64-linux-gnu/zfs/zed.d/generic-notify.sh nehmen. Im Prinzip kannst Du es unter dem richtigen Namen in das /etc/zfs/zed.d Verzeichnis kopieren, aber besser ist es, man macht einen symbolischen Link (sowas wie eine Windows-Verknüpfung), die dann den richtigen Namen trägt. Die Verknüpfung legst Du mit "ln -s <quelle> <ziel>" an, also konkret z.B. "ln -s /usr/lib/x86_64-linux-gnu/zfs/zed.d/generic-notify.sh scrub.start-notify.sh", wenn Du eine Meldung bei dem "scrub.start" Ereignis verschickt haben willst. Ein symbolischer Link ist besser als eine Verknüpfung wenn man keine Anpassungen in den Skripten machen muss, da dann bei Updates vom System das Skript aktualisiert wird.
Und nach jeder Änderung musst Du eben "systemctl restart zfs-zed" eingeben, dasmit der ZED-Dämon durchgestartet wird und die Änderungen an den Skripten mitbekommt, aber das weißt Du ja schon.
Diese Skripten nennen sich ZEDLETS und Du kannst sie natürlich komplett selbst schreiben. Aber wenn es nur um die Meldung eines Ereignisses als E-Mail geht, kannst Du das fertige Skript /usr/lib/x86_64-linux-gnu/zfs/zed.d/generic-notify.sh nehmen. Im Prinzip kannst Du es unter dem richtigen Namen in das /etc/zfs/zed.d Verzeichnis kopieren, aber besser ist es, man macht einen symbolischen Link (sowas wie eine Windows-Verknüpfung), die dann den richtigen Namen trägt. Die Verknüpfung legst Du mit "ln -s <quelle> <ziel>" an, also konkret z.B. "ln -s /usr/lib/x86_64-linux-gnu/zfs/zed.d/generic-notify.sh scrub.start-notify.sh", wenn Du eine Meldung bei dem "scrub.start" Ereignis verschickt haben willst. Ein symbolischer Link ist besser als eine Verknüpfung wenn man keine Anpassungen in den Skripten machen muss, da dann bei Updates vom System das Skript aktualisiert wird.
Und nach jeder Änderung musst Du eben "systemctl restart zfs-zed" eingeben, dasmit der ZED-Dämon durchgestartet wird und die Änderungen an den Skripten mitbekommt, aber das weißt Du ja schon.
tobis72
Experte
Hi luckyspiff.
Danke für die Einführungen in Linux ;-). Also ich könnte mir selbst ein Script schreiben mit z.B. schick mir eine Email mit Betreff X an die Adresse y. Ich muss es "srcub.start-notify.sh" nennen in das Verzeichnis /etc/zfs/zed.d legen und den ZED neu starten. Hört sich in der Tat simpel an. Wenns funktioniert ist das super aber warum gibts dann die zed.rc mit der dem Part wo die Emailadresse eingetragen werden muss?
Welches Ereignis steckt den hinter scrub.start eigentlich, was wird denn da geschrubbt?
Danke für die Einführungen in Linux ;-). Also ich könnte mir selbst ein Script schreiben mit z.B. schick mir eine Email mit Betreff X an die Adresse y. Ich muss es "srcub.start-notify.sh" nennen in das Verzeichnis /etc/zfs/zed.d legen und den ZED neu starten. Hört sich in der Tat simpel an. Wenns funktioniert ist das super aber warum gibts dann die zed.rc mit der dem Part wo die Emailadresse eingetragen werden muss?
Welches Ereignis steckt den hinter scrub.start eigentlich, was wird denn da geschrubbt?
Zuletzt bearbeitet:
luckyspiff
Experte
- Mitglied seit
- 09.08.2015
- Beiträge
- 140
Du kannst Dir beliebige Skripten schreiben die auf Ereignisse reagieren und allem mögliche machen. Damit aber für die Standard-Use-Cases (Notify) nicht jeder selbst ein Skript erstellen muss, gibt es ein generisches Skript, was genau das macht. Das benutzt dann natürlich die E-Mail-Adresse und auch das Mail-Programm, was Du in zed.rc eingetragen hast. Damit reduziert sich der Aufwand für Dich auf die erstellung eines symbolischen Links mit passendem Namen.
Übrigens ist es bei korrekter Konfiguration von ssmtp gar nicht erforderlich als Mail-Programm "ssmtp" anzugeben, weil ssmtp sich in die E-Mail-Infrastruktur so einklinkt, dass E-Mails ganz normal mit dem Unix "mail" Kommando versendet werden was vom ZED auch benutzt wird, wenn Du kein Mail-Programm angibst.
Da man bei ssmtp das Passwort von dem E-Mail Account im Klartext in der Konfiguration eintragen muss, sollte man ein paar Hinweise beachten, einerseits diese hier (ist zwar für Arch-Linux, aber auf Debian übertragbar). Darüber hinaus würde ich zu einem E-Mail Konto raten, bei dem mit dem Passwort nicht alles aus der Hand gegeben ist. Google-Mail mit Zwei-Wege Authentifizierung z.B. bietet es neue Passworter für Apps anzulegen. Auf diese Weise muss man das "Haupt-Passwort" für den Account nicht rausgeben und kann bei Missbrauch einfach das App-Passwort ändern. (Ob man natürlich Google seine Handy-Nummer und E-Mails mit Details zu seiner Infrastrukur anvertrauen will, muss jeder selbst wissen).
ZFS speichert zu allen Nutzdaten eine 256-Bit Prüfsumme ab, um Bit-Kipper zu erkennen (die berüchtigte "Bit-Erosion" oder "Bitfäule"). Die werden aber nur überprüft, wenn Daten tatsächlich gelesen werden. Mit dem Scrub eines Pools werden die alle Daten einmal gelesen und die Prüfsummen geprüft, so dass Du Dir hinterher sicher sein kannst, die böse Weltraumstrahlung keine Bits auf Deiner Festplatte kipen hat lassen und die Datenintegrität gewährleistet ist.
Das hat auch nichts mit RAID oder Mirror zu tun, denn ein "klassisches" RAID-System hat keinen Schutz gegen "Bitfäule", nur gegen den Ausfall von ganzen Platten oder unlesbaren Blöcken. Die Wahrscheinlichkeit ist zwar sehr gering (irgendwo bei 10^-14), aber mit den heutigen Festplatten-Kapazitäten und Datenvolumen ist das dann gar nicht mehr so gering.
Wenn die Daten redundant vorliegen (also in einem Mirror oder RaidZ), werden solche Fehler automatisch repariert ("Selbstheilung"). Ohne Redundanz kannst Du defekte Daten nur erkennen und die Daten ggf. löschen.
Der Scrub-Lauf beschäftigt die Platten natürlich auch eine Weile, wird bei großen Pools schon ein paar Stunden dauern. Üblicherweise wird die Empfehlung gegeben ihn 1x pro Monat zu machen.
Gute Sache dieses ZFS!
Zuletzt bearbeitet:
luckyspiff
Experte
- Mitglied seit
- 09.08.2015
- Beiträge
- 140
Ich probier gerade aus ein ZFS-Dataset mit Samba zu freizugeben. Wenn ich das mit "zfs set sharesmb=on tank/misc" versuche, passiert leider gar nichts (außer dass das Attribut gesetzt wird, aber kein Fehler). Trage das Verzeichnis von Hand ("klassisch") in die smb.conf ein, funktioniert es. Mit "net share list" taucht es auch nur dann auf, wenn das Share in der smb.conf eingetragen ist. Die Posix-ACL Attribute sind auf dem Dataset gesetzt, sollte aber vermutlich ein anderes Thema sein.
In /etc/default/zfs ist ZFS_SHARE='yes' gesetzt, langsam fällt mir nichts mehr ein, wo ich suchen könnte...
Hat jemand einen Tipp für mich? Funktioniert das bei Euch?
In /etc/default/zfs ist ZFS_SHARE='yes' gesetzt, langsam fällt mir nichts mehr ein, wo ich suchen könnte...
Hat jemand einen Tipp für mich? Funktioniert das bei Euch?
tobis72
Experte
Hi und danke nochmal für eure Erläuterungen. Ist denn "scrub" für mich das richtige Ereignis um einen Festplattenausfall im pool (mirror) melden zu lassen?
luckyspiff
Experte
- Mitglied seit
- 09.08.2015
- Beiträge
- 140
Je nach Fehler würde eine defekte Platte auch ohne Scrub auffallen und gemeldet werden, aber durch das Scrubben werden alle gespeicherten Daten einmal überprüft, so dass Du Bit-Kipper erkennst, die sonst erst auffallen, wenn man auf genau diese Daten zugreift (und mit fast allen anderen Filesytemen überhaupt nicht auffallen sondern einfach in kaputten Dateien resultieren). Solche Bit-Kipper sind zwar sehr unwahrscheinlich (10^-14..10^-15) und haben nicht zwangsläufig etwas mit Verschleiß der Platte zu tun sondern können viele Ursachen haben (Weltraumstrahlung, Spannungsschwankungen, elektromagnetische Störfelder). Die Wahrscheinlichkeit ist zwar "fast null", aber bei den riesigen Datenmangen im Terrabyte-Bereich doch nicht mehr so selten...
Festplattenfehler gibt es viele verschiedene. Magnetplatten sterben meist langsam durch Verschleiß und die Sterbewahrscheinlichkeit kann man an gewissen S.M.A.R.T.-Parametern abschätzen um die Platte ggf. vorzeitig austauschen (oder wenigstens rechtzeitig Ersatz zu beschaffen). SSD-Festplatten verschleißen auch, bei ihnen ist ein "plötzlicher Tod" aber häufiger als bei Magnetplatten. Das liegt bei SSDs daran, dass die Flasch-Zellen nur eine begrenzte Anzahl von Lösch/Schreib-Zyklen vertragen. Für SSDs sind bei den S.M.A.R.T.-Daten vor allem die geschriebenen Blöcke und der Wear-Level-Count relevant um abzuschätzen, wie hoch die Ausfallwahrscheinlichkeit ist. Bei Magnetplatten ist es die Anzahl der Lesefehler und defekter Sektoren und die Anzahl der Betriebsstunden ein Indikator.
Ich weiß jetzt auch nicht exakt, wie diese Fehlerwahrscheinlichkeit von 10^-14 zu interpretieren ist, aber auf einer 4TB Platte sind ca. 3,2 * 10^13 Bits gespeichert, d.h. die Wahrscheinlichkeit liegt schon um die 30%, dass beim Lesen, Schreiben oder umkopieren von 4TB ein Bit kippt... das Problem ist erst in den letzten Jahren relevant geworden, da es mit Festplatten im GB-Bereich so selten passiert ist, aber heute sind "kippende Bits" allgegenwärtig und eigentlich ist es der Hammer, dass abgesehen von ZFS fast kein Filesystem dafür sorge trägt, dass so etwas erkannt wird. Ich weiß eigentlich nur von ZFS, BTRFS und dem neuen Microsoft-NTFS-Nachfolge-Filesystem, dass sie das prüfen sollen. Selbst Storage-Appliances wie NetApps WAFL oder EMC haben das meines Wissens nicht. Man kann die Daten natürlich in einer höheren Schicht sichern, indem man selbst kryptografische Prüfsummen auf die Dateien legt oder in die Fileformate (FLAC hat z.B. im Gegensatz zu MP3 eine Quersumme), aber am besten ist es im Filesystem, denn da kann man es sehr effizient machen und nicht umgehen.
tobis72
Experte
Hallo Leude,
bin nun mal von der virtuellen Umgebung auf einen PC umgezogen. Hab nen alten Dualcore E5500 2.80GHz mit drei SATA platten 1x250; 2x160 zusammengespaxt. Hab mir Proxmox 4.0 drauf (auf die 250GB) und hab mit den beiden 160GB Platten einen Zpool (mirror) erstellt. Hab mal testweise ein Windows Xp auf dem pool installiert. Bin mit der Performance leider nicht so ganz zufrieden. Was sagen denn die Werte aus wenn ich "pveperf " abfrage.
bin nun mal von der virtuellen Umgebung auf einen PC umgezogen. Hab nen alten Dualcore E5500 2.80GHz mit drei SATA platten 1x250; 2x160 zusammengespaxt. Hab mir Proxmox 4.0 drauf (auf die 250GB) und hab mit den beiden 160GB Platten einen Zpool (mirror) erstellt. Hab mal testweise ein Windows Xp auf dem pool installiert. Bin mit der Performance leider nicht so ganz zufrieden. Was sagen denn die Werte aus wenn ich "pveperf " abfrage.
Bei pveperf sind die File Operationen/s wichtig vor allem wenn viele VM´s laufen.Wette die sind übelst schlecht bei dir ZFS halt.Was kommt bei dir raus ?
tobis72
Experte
Hi, heir die ausgabe:
CPU BOGOMIPS: 11198.84
REGEX/SECOND: 980987
HD SIZE: 123.71 GB (raid)
FSYNCS/SECOND: 58.53
DNS EXT: 1070.48 ms
DNS INT: 21.33 ms (my-domain.com)
- - - Updated - - -
Hab mal ein bisschen gegoogelt und hab mal im pool:
zfs set sync=disabled raid
eingestellt. Weiss nicht genau, was das wohl macht aber es beeinflusst
den Wert FFSYNCS/SECOND: 16176.09
CPU BOGOMIPS: 11198.84
REGEX/SECOND: 980987
HD SIZE: 123.71 GB (raid)
FSYNCS/SECOND: 58.53
DNS EXT: 1070.48 ms
DNS INT: 21.33 ms (my-domain.com)
- - - Updated - - -
Hab mal ein bisschen gegoogelt und hab mal im pool:
zfs set sync=disabled raid
eingestellt. Weiss nicht genau, was das wohl macht aber es beeinflusst
den Wert FFSYNCS/SECOND: 16176.09
Zuletzt bearbeitet:
Miserable Werte typisch ZFS ohne SSD als Cache und dazu nur zwei Spindeln.Wette unter ext3/ext4 auf / hast du bessere Werte.
Das hast das Filesystem asynchron gesetzt das sollte man nur mit Controller mit Batterie Cache und Write Cache SSD machen.
Das hast das Filesystem asynchron gesetzt das sollte man nur mit Controller mit Batterie Cache und Write Cache SSD machen.
Hier gehen zuviel Dinge durcheinander.
Ext4 oder ntfs haben keine Prüfsummen, schreiben damit minimal weniger Daten. Da kein CopyOnWrite (jeder Block neu) sondern Datenupdates in der Filestruktur vorgenommen werden, könnte man eine gering bessere Performance annehmen. Ist aber durch den intelligenten Arc Cache von ZFS oder den Schreibcache mit der Wandlung kleiner wahlfreier Writes zu einem großen Sequentiellen Write nicht der Fall. ZFS ist dank dieser Cache Mechanismen bei ausreichend RAM schneller.
(Jetzt mal die erheblich bessere Datensicherheit von ZFS mit online filechecks, Reparatur aufgrund der Prüfsummen, Snaps, Crashsicherheit mal aussen vor gelassen)
Sync Write ist ein komplett anderes Thema. Für ZFS ist das zunächst vollig belanglos. Dank CopyOnWrite ist ZFS immer konsistent. Das gilt aber nicht für Schreibvorgänge auf Applikationsebene z.B. mit Transaktionen bei denen entweder mehrere oder keine Schreiaktion durchgeführt werden müssen, andernfalls ist eine Datenbank oder ein ext/ntfs Dateisystem eventuell korrupt.
Cache + BBU ist dazu das Mittel der Wahl bei Hardware Raid. Hardware Raid führt aber bei ZFS dazu, Auto-Repair zu verlieren. Bei ZFS muss man lediglich sync aktivieren. Das hat aber heftige Auswirkung auf die Schreibperformance wenn man das auf einem langsamen Pool macht. Bei ZFS nutzt man dann ein extra ZIL Laufwerk z.B. eine schnelle RAM oder SLC SSD oder eine Enterprise SSD wie z.B. eine Intel S37x0.
btw
ZIL ist kein Cache sondern ein Logging Device das nur im Crashfall gelesen wird -
wie der BBU gepufferte Cache eines Raidcontrollers.
Zuletzt bearbeitet:
Sage nicht das ZFS schlecht ist eher das Gegenteil.Aber nix für 0815 Standard Hardware.Wir hatten auf der Arbeit mal ein Nexenta Storage zum Testen.Server 96 GB RAM per SAS HBA Controller mit einem DELL MD Storage verbunden.Leider nur 6 Spindeln drin.Man war das Teil langsam.Über NFS gemountet konnten wir mit einfachen Bash scripten gerade mal 30 kleine Files/s erzeugen. Ein Umschalten auf sync=disabled brachte ca. 1000 Files/s was ich local auf einem RAID 1 auch schaffte.Nexenta sagte alle 10s würde der Cache weg geschrieben werden.Ohne SSD zum Puffern wäre sync=disabled sehr gefährlich.Meine Erfahrung war RAM alleine bringt gar nichts bei kleinen Dateien. Wenn ZFS dann richtig mit SSD,vielen HD´s etc. sonst hat man nur ein langsames System.
