Re: Welches Dateisystem direkt für Hardwareserver?
Sven Hartge - 08.01.18, 00:55:
> Martin Steigerwald <martin@lichtvoll.de> wrote:
> > Sven Hartge - 07.01.18, 22:17:
> >> Stefan Krueger <Shadow_7@gmx.net> wrote:
> >>> ich hab hier nen neuen Server 2SSDs und nen RaidController, der aber
> >>> auch die Disks direkt durchreichen kann. Unser Monitoringsystem
> >>> soll da rauf, ist jedoch relativ Datenbanklastig (PostgreSQL), für
> >>> mich stellt sich jetzt die Frage btrfs mit RAID1 und evtl Sub-Vols
> >>> (extra für PostgreSQL) oder mach ich nen RAID1 mit dem
> >>> RAID-Controller und darauf dann ext4?
> >>
> >> Ich würde den RAID-Controller wegwerfen bzw. die SSDs durchreichen
> >> lassen und direkt RAID1 mit dem Kernel machen. Darauf dann LVM und
> >> ext4 oder xfs.
> >>
> >> Ist einfacher zu verwalten und deutlich performanter als wie via
> >> RAID-Kontroller. (Ja, ich habe das gebenchmarkt.)
> >
> > Ich vermute, unterschiedliche Hardware-RAID-Controller liefern
> > unterschiedliche Ergebnisse.
>
> Ja. Interessanterweise alle schlechter wie SoftRAID via Kernel.
> Oder anders ausgedrückt: Um in die Nähe vom SoftRAID zu kommen, brauchte
> ich bei den RAID-Controllern im RAID-Modus mehr manuelles Tuning wie
> wenn ich die Datenträger einfach stumpf durchgereicht habe.
>
> Interessanterweise wurde es noch grauenhafter, wenn als ich die höheren
> RAID-Level getestet habe.
>
> Kurzbeispiel aus den Kopf:
>
> LSI SAS 9750-8i mit 24 Platten (als RAID60), 512MB Cache und BBU.
> Schreibleistung: Mit Achen und Krachen 500MByte/s und viel Bitten,
> testen und Werte anpassen.
>
> Platten auf JBOD umgestellt, Linux-Kernel 2x12 RAID6 via LVM
> zusammegefasst.
> Schreibrate out-of-the-box: 1200MByte/s
>
> Seitdem nie wieder Hardware-RAID, wo ich es vermeiden kann.
>
> Plus: Kein Hampeln mehr mit irgendwelchen proprietären
> RAID-Kontroller-Tools.
Das ist auch für mich ein Grund, weil jeder Hersteller andere Tools hat.
LSI sogar für unterschiedliche Controller-Familien¹. Zudem sind diese
Werkzeuge und die Controller-Firmwares teilweise grottenschlecht.
[1] https://hwraid.le-vert.net/wiki/DebianPackages
> > Ich würde jedoch auch zu SoftRAID 1 tendieren.
> >
> >> btrfs würde ich nicht in der Produktion verwenden.
> >>
> >> Dazu kommt, dass CoW-Dateisysteme unpassend für Datenbank-Systeme sind.
> >> Für btrfs wird für Postgres/MySQL/MariaDB dringend empfohlen, das
> >> CoW-Feature abzuschalten.
> >
> > Auch für SSDs? Copy On Write verringert vor allem bei Datenträgern mit
> > hohen Such-Latenzen in Zusammenhang mit wahlfreiem Schreibzugriffen auf
> > (größere) Dateien die Performance.
>
> Die Aussage las sich eigentlich recht universell.
>
> In 2016 gab es auf der FOSDEM hierzu einen Vortrag:
> https://de.slideshare.net/fuzzycz/postgresql-on-ext4-xfs-btrfs-and-zfs-54525451
Grrrr. Slideshare, die einen das nicht als PDF runter laden lassen, ohne sich
dort anzumelden. Das ist leider eine Unsitte geworden, Folien auf diesen
Anbieter hoch zu laden, der mit hoher Wahrscheinlichkeit wie Google, Facebook
und Co ebenfalls mit den Daten seiner Nutzer handelt. Da suche ich mir auf der
Arbeit ein PDF raus oder frage den Autor danach.
> Die Tests wurden dabei auf einer Intel S3700 SSD durchgeführt, also
> einer SSD für den schreibintensiven Servereinsatz.
>
> Folien 33 und 34 sind recht aussagekräftig. TL;DR: btrfs ohne nodatacow
> ist auch auf SSD nur halb so performant wie der Rest, inklusive ext3.
>
> Die Kurven in Folie 37 zum Verhalten von btrfs ohne nodatacow spricht
> auch Bände: extrem variabel in den TPS.
Okay, whoa. Das ist nicht nett.
> Conclusion in Folie 39 zu btrfs: "bad: rather unstable and inconsistent
> behavior".
>
> Natürlich hat sich seit 2016 viel in btrfs getan, aber ganz ehrlich: Das
> würde mich eher von einem Dateisystem abwenden lassen: Wenn es sich in
> einem Jahr so extrem stark verändert.
Einerseits ja, andererseits nein. Wesentliche Funktionen fehlen da immer noch.
Manchmal frage ich mich, was die Entwickler gerade machen. Seitdem Chris Mason
und andere Entwickler bei Facebook verschwunden ist, hab ich das Gefühl, dass
es im Schneckentempo voran geht. Kein Hot Data Tracking / SSD als Cache, kein
RAID mit variabler Redundanz, immer noch keine In-Band-Deduplizierung. Obwohl
es zu vielen der Dinge seit Jahren, teils mehr als 3 oder gar 5 Jahren,
Patches gibt.
Mein Eindruck ist, dass es BTRFS gar nicht gut getan hat, dass Facebook eine
Reihe BTRFS-Entwickler eingekauft hat.
Vielleicht deutet das auf eine Stabilisierungsphase hin. Das wäre ja gut. Aber
auch da warte ich noch drauf. Die BTRFS-Tools, da sehe ich Einiges. Aber BTRFS
im Kernel? Das langweilt mich ziemlich. Deshalb wäre ja auch nett, wenn so was
wie BCacheFS in den Kernel kommt. Wobei das mehr oder weniger eine Ein-Mann-
Show zu sein scheint. Und Tux3? Naja…
> Ein ältere Blog-Eintrag von 2015 zum Thema Postgres in BTRFS gibt es
> hier:
> https://blog.pgaddict.com/posts/friends-dont-let-friends-use-btrfs-for-oltp
Okay, danke.
Das ist dann Material, was ich für meine Performance-Kurse auswerten kann.
Ciao,
--
Martin
Reply to: