Hallo,
ich habe 2 Hosts mit jeweils RAID10 far 2 Layout. Darauf Volumes per LVM2 und diese per DRBD mit dem anderen Host verbunden.
Wenn ich die Konfigurationen in DRBD "no-disk-barrier; no-disk-flush; no-md-flush" setzen ist die Performance in Ordnung. Ich schaffe damit die Schreibgeschwindigkeit der Gigabit NICs.
Wenn ich allerdings nur eine dieser Optionen weglasse und somit DRBD "flush" oder "barrier" nutzen darf sinkt die Geschwindigkeit unter 20 MegaByte/s.
Das Systeme sind Ubuntu 12.04 LTS. In einer alten Debian-Lenny Installation hatte ich diese Probleme nicht. Dabei waren die Platten in der alten Konfiguration sogar langsamer als die neuen.
Ich habe nun schon einige Nächte im Netz recherchiert und herausgefunden, dass scheinbar in Debian Lenny LVM noch keine "barrier" unterstützt hat und somit die Geschwindigkeit dadurch höher war, die Sicherheit der Schreiboperationen aber eben auch nicht wirklich gegeben war.
In neueren Distributionen soll LVM nun die barrier weitereichen/unterstützen und somit die Sicherheit erhöhen.
Die Schreibgeschwindigkeit bei großen Blöcken (also ca 20MB/s) ist nicht so extrem kritisch. Die Geschwindigkeit mit kleinen Blöcken (1024B) ist mit ca. 20KB/s aber einfach katastrophal. Hat man da ne SQLite-DB in SYNC-Modus mit vielen Updates ist die Anwendung nicht zu verwenden.
Schallte ich barrier und flush aus, habe ich bei diesen kleinen Blockgrößen ca. 400-500kb/s was der Geschwindigkeit der Debian Lenny Konfiguration entspricht.
/proc/drbd zeigt übrigens auch mit aktivierten "barrier" nur "wo:f" an, was ja auf "flush" hinweist. Einen Logeintrag, warum aber flush verwendet wird und nicht barrier finde ich nicht.
barrier=0 oder barrier=1 im ext4 der Dateisystems auf dem DRBD-Device hat übrigens keinen Einfluss auf die Geschwindigkeit. Ein Anpassen der "max-buffers" und "max-epoch-size" brachte auch keine spürbaren Veränderungen.
Jetzt meine Fragen:
Ist dieser Performance-Verlust durch die Verwendung von barrier wirklich so extrem und es liegt somit nicht an meiner Konfig?
Warum war Debian Lenny mit DRBD und "flush" schneller und es reicht nicht nur "no-disk-barrier" in meiner aktuellen Installation aus um die gleiche Performance zu erreichen?
Warum zeigt /proc/drbd "wo:f" an, auch wenn die "no-disk-barrier" Option nicht angegeben ist (wie geschrieben, kein Eintrag im Log, dass barrier nicht verwendet werden)?
Jede Website zu diesem Thema warnt davor, barrier und flush in DRBD abzuschalten, wenn man kein Batterie gepufferten Controller verwendet. Da ich diesen nicht haben (und auch nicht einbauen kann, da Hetzner Server), mit aktivierten barrier und/oder flush aber das System nicht verwendbar ist, ist die Frage: Was kann ich tun?
Ist es wirklich so gefährlich, diese Optionen einfach aus zu lassen? Ich kann damit leben, wenn die letzten Schreibvorgänge evtl. verloren sind. Ein komplett zerschossenen Dateisystem ist aber fatal. Kann das passieren?
Ist ein gewisser Grad an Sicherheit gegen, wenn im ext4 "barrier=1" gesetzt ist aber im darunterliegenden DRBD barrier und flush deaktiviert sind?
Konfigdateien und irgendwelche gewünschten Tests kann ich natürlich nachreichen. Es ist aber alles nach Anleitung der DRBD-Website gemacht und auch die Tuning-Tipps wurden angewendet. Es sind alles Standard-Pakete von Ubuntu. Also nix selbst kompiliertes.
Ich bin für jede Hilfe bzw. Aufklärung dankbar.
apairon
ich habe 2 Hosts mit jeweils RAID10 far 2 Layout. Darauf Volumes per LVM2 und diese per DRBD mit dem anderen Host verbunden.
Wenn ich die Konfigurationen in DRBD "no-disk-barrier; no-disk-flush; no-md-flush" setzen ist die Performance in Ordnung. Ich schaffe damit die Schreibgeschwindigkeit der Gigabit NICs.
Wenn ich allerdings nur eine dieser Optionen weglasse und somit DRBD "flush" oder "barrier" nutzen darf sinkt die Geschwindigkeit unter 20 MegaByte/s.
Das Systeme sind Ubuntu 12.04 LTS. In einer alten Debian-Lenny Installation hatte ich diese Probleme nicht. Dabei waren die Platten in der alten Konfiguration sogar langsamer als die neuen.
Ich habe nun schon einige Nächte im Netz recherchiert und herausgefunden, dass scheinbar in Debian Lenny LVM noch keine "barrier" unterstützt hat und somit die Geschwindigkeit dadurch höher war, die Sicherheit der Schreiboperationen aber eben auch nicht wirklich gegeben war.
In neueren Distributionen soll LVM nun die barrier weitereichen/unterstützen und somit die Sicherheit erhöhen.
Die Schreibgeschwindigkeit bei großen Blöcken (also ca 20MB/s) ist nicht so extrem kritisch. Die Geschwindigkeit mit kleinen Blöcken (1024B) ist mit ca. 20KB/s aber einfach katastrophal. Hat man da ne SQLite-DB in SYNC-Modus mit vielen Updates ist die Anwendung nicht zu verwenden.
Schallte ich barrier und flush aus, habe ich bei diesen kleinen Blockgrößen ca. 400-500kb/s was der Geschwindigkeit der Debian Lenny Konfiguration entspricht.
/proc/drbd zeigt übrigens auch mit aktivierten "barrier" nur "wo:f" an, was ja auf "flush" hinweist. Einen Logeintrag, warum aber flush verwendet wird und nicht barrier finde ich nicht.
barrier=0 oder barrier=1 im ext4 der Dateisystems auf dem DRBD-Device hat übrigens keinen Einfluss auf die Geschwindigkeit. Ein Anpassen der "max-buffers" und "max-epoch-size" brachte auch keine spürbaren Veränderungen.
Jetzt meine Fragen:
Ist dieser Performance-Verlust durch die Verwendung von barrier wirklich so extrem und es liegt somit nicht an meiner Konfig?
Warum war Debian Lenny mit DRBD und "flush" schneller und es reicht nicht nur "no-disk-barrier" in meiner aktuellen Installation aus um die gleiche Performance zu erreichen?
Warum zeigt /proc/drbd "wo:f" an, auch wenn die "no-disk-barrier" Option nicht angegeben ist (wie geschrieben, kein Eintrag im Log, dass barrier nicht verwendet werden)?
Jede Website zu diesem Thema warnt davor, barrier und flush in DRBD abzuschalten, wenn man kein Batterie gepufferten Controller verwendet. Da ich diesen nicht haben (und auch nicht einbauen kann, da Hetzner Server), mit aktivierten barrier und/oder flush aber das System nicht verwendbar ist, ist die Frage: Was kann ich tun?
Ist es wirklich so gefährlich, diese Optionen einfach aus zu lassen? Ich kann damit leben, wenn die letzten Schreibvorgänge evtl. verloren sind. Ein komplett zerschossenen Dateisystem ist aber fatal. Kann das passieren?
Ist ein gewisser Grad an Sicherheit gegen, wenn im ext4 "barrier=1" gesetzt ist aber im darunterliegenden DRBD barrier und flush deaktiviert sind?
Konfigdateien und irgendwelche gewünschten Tests kann ich natürlich nachreichen. Es ist aber alles nach Anleitung der DRBD-Website gemacht und auch die Tuning-Tipps wurden angewendet. Es sind alles Standard-Pakete von Ubuntu. Also nix selbst kompiliertes.
Ich bin für jede Hilfe bzw. Aufklärung dankbar.
apairon
