Empfehlung Dateisystem

Probleme mit Samba, NFS, FTP und Co.
Benutzeravatar
Lord_Carlos
Beiträge: 3668
Registriert: 30.04.2006 17:58:52
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Dänemark

Re: Empfehlung Dateisystem

Beitrag von Lord_Carlos » 17.03.2017 16:25:49

r4pt0r hat geschrieben: In keinen Server gehört non-ECC RAM, völlig egal welche aufgaben er erfüllt... Idealerweise nutzt man auch gleich regECC, für Vollbestückung ist das ohnehin fast immer Voraussetzung.
Wenn unterstützt, nutze ich auch auf Desktops mittlerweile nur noch ECC. Der Preisunterschied ist nur noch marginal und die Zeit- und Nervenersparnis wg. defektem/schrottigem Consumer-RAM ist unbezahlbar...
Gerade vor ein paar Tagen die Prise fuer microATX mainboards fuer ein Intel Pentium angeguckt das auch HDMI/DP out hat. Ohne ECC kann man ein gutes fuer ~80 EUR bekommen, mit ECC konnte ich welche ab 220 EUR finden. Ist jetzt nicht gerade Marginal. Ram preise dann garnicht mehr angeguckt.

Durch lesen von anderen Diskussionen habe ich mir sagen lassen das es wahrscheinlicher ist das man selber was loescht, als das ein bit flip eine Datei komplett unleserlich macht.
Wie siehst du das? Wie oft passiert es dir?

Code: Alles auswählen

╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!

r4pt0r
Beiträge: 1139
Registriert: 30.04.2007 13:32:44
Lizenz eigener Beiträge: MIT Lizenz

Re: Empfehlung Dateisystem

Beitrag von r4pt0r » 17.03.2017 17:03:20

Lord_Carlos hat geschrieben: Intel Pentium angeguckt das auch HDMI/DP
Pentium und HDMI hat nix mit Server am hut ;)

Die neuen Xeon D von Supermicro fangen bei <400 eur für die 2-kern Varianten an (1508). Da hat man dann sogar bereits 2x 10GBit onboard im SoC bei 25W TDP und ein vollwertiges IPMI. ASRock kommt mit noch günstigeren Varianten, ohne IPMI und ASRock-typisch eben mit billigkomponenten und vermutlich auch kaputtem UEFI :roll:
Sobald die neuen Atom C3000 kommen dürften die preislich noch etwas drunter liegen, bzw die C2xxx werden noch weiter im preis fallen (sind aber auch ziemliche krücken...).
8GB regECC DDR4-2133 RAM gibts für ~75EUR (Kingston Value), vergleichbarer non-ECC kostet gerade mal 10EUR weniger.

Für <500 EUR (exkl. platten) kann man also schon ne anständige plattform bekommen die wirklich für serverbetrieb konzipiert und geeignet ist. Da braucht man nicht lange mit Desktophardware rumbasteln. Hab das selber leider lange genug für meine Heimserver gemacht und unterm strich meistens mehr draufgezahlt. Bei Gehäusen für storagesysteme kann ich auch nur noch empfehlen nach gebrauchten servergehäusen ausschau zu halten - das ist immer noch zuverlässiger und günstiger als irgendwelche 5.25" Wechselgehäuse. Zudem ist es einfacher ein Servergehäuse, das schon einen sehr optimierten Luftstrom hat, leise zu bekommen als ein umfunktioniertes Desktopgehäuse das plötzlich die Abwärme von 8...14...20... Platten wegschaffen muss... (Bei mir läuft auch noch so eine "jugendsünde" :oops: )

Durch lesen von anderen Diskussionen habe ich mir sagen lassen das es wahrscheinlicher ist das man selber was loescht, als das ein bit flip eine Datei komplett unleserlich macht.
Wie siehst du das? Wie oft passiert es dir?
Festplatten sterben und geben auch falsche daten zurück, speziell wenn daten sehr lange nicht gelesen/geschrieben wurden - da hat ZFS schon mehrfach angeschlagen bevor z.b. bei SATA irgend ein SMART-Wert auffällig gewesen wäre. Meistens reicht es dann die platte mit random i/o zu "thrashen" um fehler zu frovozieren oder sogar endgültig ins jenseits zu befördern.

Mit ZFS lasse ich von entsprechenden datasets (z.b. /usr/home) 10-minütig snapshots erstellen mit Vorhaltezeiten um ~3h (+ längere/long-term snapshots für backup / replication). Dadurch konnte ich schon oft daten die durch dicke user-finger gelöscht oder überschrieben wurden wiederherstellen (über verstecktes .zfs-verzeichniss, da brauchts nichtmal nen rollback). Auch ein cryptlocker-verseuchter client der nen netzwerkshare verschlüsseln wollte konnte aufgehalten werden bzw der letzte snapshot wurde zurückgeholt. Seitdem lasse ich überwachen ob das delta zwischen zwei snapshots einen zu großen anteil der gesamtgröße ausmacht. Dann wird der vorherige snapshot geklont, readonly gemountet und der vermeintlich kompromittierte snapshot bleibt zur analyse erhalten, den kann ich ggf zurückholen oder einfach löschen...

trg2889
Beiträge: 128
Registriert: 01.07.2015 08:45:36

Re: Empfehlung Dateisystem

Beitrag von trg2889 » 17.03.2017 18:15:39

Hallo zusammen,
im Moment ist ein Serverboard mit reg-ECC wie Kanonen auf Spatzen schießen. Es sind keine wichtigen Daten die im NAS verteilt werden Hauptsächlich Musik, Serien und Musikvideos. Also, nichts was man vermissen würde wenn mal eine Platte seinen Dienst versagt Zumal es ja auch noch Backups gibt. Da ich noch Hardware hatte, die ehh hier langsam verstaubt, wollte ich mich mal an das Projekt heranwagen. Zumal das NAS auch nur und einen Teil für die Hausautomation darstellt.

scientific
Beiträge: 2708
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Empfehlung Dateisystem

Beitrag von scientific » 17.03.2017 18:21:34

Weil grub angeblich so kaputt und instabil wäre...
Nun, ich nutze nun seit ein paar Monaten die Fähigkeiten des Linux-Kernels, sie mit UEFI selbst zu booten...
Grub hab ich zwar noch installiert, aber das fliegt bald von der Platte.

Lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

Benutzeravatar
Maik aus MS
Beiträge: 541
Registriert: 19.08.2005 17:01:19
Wohnort: Münster
Kontaktdaten:

Re: Empfehlung Dateisystem

Beitrag von Maik aus MS » 18.03.2017 09:47:15

Bei mir habe ich es so geloest. BS auf SSD mit ext4. Zuruecksetzen eines Systems auf einem Server? Ich weiss nicht.

Die Datenplatten haben BTRFS. Habe dadurch jeweils 2 Platten zu einer Verbunden. Aber auch BTRFS verteilt die Daten so
das in einem Plattenausfall die Daten futsch sind. Also wenn wie gefordert die Platten immer ganze Dateien enthalten sollen
dann muss man es anders machen. Z.B. Platte1 - Musik, Platte2 - Video usw.

Maik
Die mich kennen mögen mich.
Die mich nicht mögen können mich.

DEBIANUNDANDREAS
Beiträge: 842
Registriert: 01.06.2013 10:37:46

Re: Empfehlung Dateisystem

Beitrag von DEBIANUNDANDREAS » 18.03.2017 11:15:36

Hallo ich nutze für ubuntuserver 16.04.2 ext 4, immer nur ext4 das ist ausgereift und kein Dateisystemexot wie btrfs.
Ich verstehe kein English.
Ich mache gerne x-postings
Wenn ich ich das Forum wechsele, entscheide ich das selber.

rendegast
Beiträge: 14272
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: Empfehlung Dateisystem

Beitrag von rendegast » 18.03.2017 12:02:40

Maik aus MS hat geschrieben: Aber auch BTRFS verteilt die Daten so
das in einem Plattenausfall die Daten futsch sind.

Ups, hatte ich oben erwähnt, mir in der Brisanz gar nicht bewußt geworden
rendegast hat geschrieben: Test mit loops,
wird kein '-d raid[1|5] -m raid[1|5]' angegeben,
so wird ein "single"-Data erstellt.
-->> Schalte ich vom Verbund 1 ab, bekomme ich das System nicht mehr gemountet.
Ein mehr-device-btrfs OHNE explizite Option für raid[1|5] entspricht einem hochgefährdeten raid0.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

r4pt0r
Beiträge: 1139
Registriert: 30.04.2007 13:32:44
Lizenz eigener Beiträge: MIT Lizenz

Re: Empfehlung Dateisystem

Beitrag von r4pt0r » 20.03.2017 10:31:54

Maik aus MS hat geschrieben:Zuruecksetzen eines Systems auf einem Server? Ich weiss nicht.
Das kann einem ganz schnell das Wochenende retten. Hier läuft z.B. ein älteres gatewaysystem auf Intel S5000 Basis, das nicht so 100%ig dem PCIe-hotplug Standard folgt. Freitag Nachmittag noch ein Upgrade durchgeführt bei dem auch Code für PCIe-HP aktualisiert und HP per default aktiviert wurde ->system crashte beim booten und startete sofort neu (endlosschleife).
Dank Bootenvironments lief das System nach wenigen Minuten wieder mit Stand vor dem Update (nur OS, userdaten liegen ja nicht auf BE-relevanten datasets), die User haben mir nicht mehr die Ohren vollgejammert und ich konnte in aller ruhe noch kurz über die crashdumps schauen und dann ins Wochenende - das BE mit dem aktualisierten system (und crashdumps) konnte ich dann am Montag analysieren und mit deaktiviertem HP läuft das System seither anstandslos...

Mit BEs kann man größere upgrades auch anderst herum angehen: BE erstellen, in diesen datasets die updates installieren während das system weiterhin im normalen Betrieb weiterläuft, ggf noch configdaten überprüfen/anpassen, BE für nächsten start aktivieren und system neu starten. Hat man eine angepasste Kernelkonfiguration kann man den neuen Kernel im neuen BE auch gleich vorab bauen - im Endeffekt ist die Downtime dann selbst bei sehr umfangreichen updates nur ein einziger Neustart. Ist doch was schiefgelaufen lädt man das alte BE und kann dann ohne Zeitdruck analysieren was nicht passt...

scientific
Beiträge: 2708
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Empfehlung Dateisystem

Beitrag von scientific » 20.03.2017 12:04:41

r4pt0r hat geschrieben:
Maik aus MS hat geschrieben:Zuruecksetzen eines Systems auf einem Server? Ich weiss nicht.
Das kann einem ganz schnell das Wochenende retten. Hier läuft z.B. ein älteres gatewaysystem auf Intel S5000 Basis, das nicht so 100%ig dem PCIe-hotplug Standard folgt. Freitag Nachmittag noch ein Upgrade durchgeführt bei dem auch Code für PCIe-HP aktualisiert und HP per default aktiviert wurde ->system crashte beim booten und startete sofort neu (endlosschleife).
Dank Bootenvironments lief das System nach wenigen Minuten wieder mit Stand vor dem Update (nur OS, userdaten liegen ja nicht auf BE-relevanten datasets), die User haben mir nicht mehr die Ohren vollgejammert und ich konnte in aller ruhe noch kurz über die crashdumps schauen und dann ins Wochenende - das BE mit dem aktualisierten system (und crashdumps) konnte ich dann am Montag analysieren und mit deaktiviertem HP läuft das System seither anstandslos...

Mit BEs kann man größere upgrades auch anderst herum angehen: BE erstellen, in diesen datasets die updates installieren während das system weiterhin im normalen Betrieb weiterläuft, ggf noch configdaten überprüfen/anpassen, BE für nächsten start aktivieren und system neu starten. Hat man eine angepasste Kernelkonfiguration kann man den neuen Kernel im neuen BE auch gleich vorab bauen - im Endeffekt ist die Downtime dann selbst bei sehr umfangreichen updates nur ein einziger Neustart. Ist doch was schiefgelaufen lädt man das alte BE und kann dann ohne Zeitdruck analysieren was nicht passt...
Sorry für die blöde Frage... Bootenvironment? Ich hab mal gegooglet und das im Zusammenhang mit BSD gefunden.

Ist das auch unter Linux vorhanden?

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

r4pt0r
Beiträge: 1139
Registriert: 30.04.2007 13:32:44
Lizenz eigener Beiträge: MIT Lizenz

Re: Empfehlung Dateisystem

Beitrag von r4pt0r » 20.03.2017 17:05:05

Sorry, ich dachte ich hatte das eingangs erwähnt - es handelt sich um FreeBSD systeme. Ich habe mal angefangen/versucht etwas ähnliches mit einem devuan/ZFS system zu bauen, aber da debian bzw linux allgemein systemdaten relativ wild im dateisystem verteilt ist das doch recht umständlich bzw nicht im selben Umfang möglich. BSD hat hier einfach eine _sehr_ saubere trennung von systemdaten, konfiguration, laufzeitdaten und userdaten, die das konzept von BEs begünstigt bzw erst ermöglicht.

Mit etwas Aufwand und Aufräumarbeiten wäre sowas theoretisch auch unter linux mit ZFS möglich - dann bleibt aber immer noch der Kropf namens GRUB der ja schon mit 'einfachem' ZFS oft Schwierigkeiten macht. Dem auch noch das Konzept von BootEnvironments beizubringen endet wohl eher im chaos (u.a. deshalb wurde auch bei illumos GRUB rausgeworfen und der BSD-Loader portiert).


Grundsätzlich kann man aber auch manuell einen snapshot vom gesamten Pool erstellen bevor man ein größeres update durchführt. Man kann dann in grub einfach das '@snapshotname' anhängen um in den snapshot zu booten. Änderungen an userdaten werden dabei natürlich auch zurückgesetzt bzw man müsste die entsprechenden datasets ggf manuell in der neueren variante mounten oder einzelne dateien aus .zfs/snapshot kopieren. (overlay-mounts sollte man dabei erfahrungsgemäß unter linux aber vermeiden, das Konzept ist hier irgendwie nicht ganz fertiggedacht worden und funktioniert nicht wirklich)

scientific
Beiträge: 2708
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Empfehlung Dateisystem

Beitrag von scientific » 20.03.2017 18:50:06

Ach so.
Sowas hab ich mit Linux und btrfs realisiert.
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

Antworten