Erfahrungen mit OMV und bcache ?

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Erfahrungen mit OMV und bcache ?

    Hallo,

    hat hier jemand eigentlich schon Erfahrungen mit bcache gesammelt ? Ich überlege gerade, dass bei meinem NAS einzusetzen, um den Schreibdurchsatz zu erhöhen (gerade bei Backups). Die bisherige GBit-Netzwerkanbindung des NAS wurde schon während Backups (viele kleine Dateien) nur ausgelastet bis der RAM voll war, da ich jetzt aber relativ bald vollständig auf 10 GBit umstelle, wäre das tatsächlich eine Überlegung wert, z.b. 400 GB der PCIe-NVM SSD für bcache abzustellen. Von vorne beginnen möchte ich eigentlich nichts, bin bisher auf "blocks" gestoßen, mit dem ich scheinbar den RAID als backing device umändern kann, ohne alle Daten zu verlieren. Hat das jemand hier schon einmal gemacht ?
  • Re,

    cvb schrieb:

    hat hier jemand eigentlich schon Erfahrungen mit bcache gesammelt ?
    (Ich) Nicht im privaten Umfeld und auch nicht im "produktiven" Einsatz ... ich halte das auch im privaten bzw. SOHO- Umfeld nicht für nötig.

    Desweiteren sollte man die Komplexität von Cache-Piplines einigermaßen verstanden haben, um sie wirklich effektiv einsetzen zu können:
    - 400GiB sind dann der Puffer, der mit maximaler Geschwindigkeit einer NMVe-SSD beschrieben werden kann (und zwar gilt hier nicht der synthetische Wert, sondern der Anwendungsspezifische)
    - die SSD wird dann überproportional benutzt - es muss also eine wirklich gute und besonders langlebige SSD sein ... "Servergrade"
    - OS und "bcache" auf einem (phys.) Datenträger zu haben ist ein schlechtes Konzept - so verliert man im Fehlerfall Beides (und alle Daten)

    Und dann ist immer noch die Frage, was dein Speichersubsystem überhaupt leisten kann!
    Denn die wichtigsten Fragen hast du (dir) bisher nicht gestellt:
    - wo befindet sich der Flaschenhals jetzt?
    - wo befindet sich der Flaschenhals dann bei 10GBE-LAN?

    Sc0rp
  • Der derzeitige Flaschenhals (auch bei GBit) ist das RAID5 bestehend aus 4x4TB WD RED. Bei ca. 100MB/s schreibend ist Schluss, auch bei 10 GBit, da gehts manchmal noch auf 120-130 MB/s hoch. Wenn die Backups meines Desktops oder der Workstation (haben beide nur SSDs) laufen, wird es viel viel schlimmer, da fällt die Schreibrate unter 20 MB/s (da sehr viele kleine Dateien, knapp 1 TB davon). Das Backup, sowohl voll als auch inkrementell, dauert dann ewig. CPU Last von NAS und Clients etc. ist dabei niedrig (< 10%). Daher war der Gedanke, das mittels caching zu beschleunigen - das die Backups möglichst zügig durchlaufen (das NAS darf dann ruhig noch vom Cache auf das RAID schreiben, alles notstromversorgt etc.).

    Haltbarkeit der SSD ist natürlich auch ein Punkt, eine Samsung 960 Pro wird bei meinem Volumen aber auf Jahre weg keine Probleme bekommen, da ich nur zweimal pro Monat voll sichere, der Rest ist inkrementell, bislang waren es so ca. 3 TB pro Monat. Bei 4 TB / Monat würde die TBW nach 100 Monaten aka 8,3 Jahren erreicht werden, und da ist ja normalerweise die SSD auch nicht sofort tot. An die Auftrennung habe ich deswegen noch nicht so gedacht. Zumindest war das so mein Gedanke, deswegen ist der Thread hier erst auch einmal theoretischer Natur. Das NAS bekommt in den nächsten Wochen ein massives Hardware-Upgrade, von daher war der Gedanke da, das mit dem Cache ggf. gleich mit zu erledigen.

    So ganz grob skizziert:
    NAS derzeit:
    Pentium G3460, 2 Threads
    2x 4GB DDR3-ECC RAM
    4x WD RED 4TB
    1x Sandisk SSD (OMV)
    1x Asus XG-XC100C 10 GBit NIC

    Nutzung: Medienspeicher und Datengrab

    NAS neu:
    Xeon 1230v6, 8 Threads
    Supermicro X11SSH-F
    2x 16GB DDR4-ECC RAM
    6x WD RED 4TB
    1x WD Purple (Videoüberwachung)
    1x Samsung 960 Pro 512 GB (OMV + ggf. bcache + VirtualBox)
    1x Asus XG-XC100C 10 GBit NIC

    Nutzung:
    Medienspeicher, Datengrab, Netzlaufwerk, Backupziel
    1x Virtualbox VM (Win 10, 2 Threads, 4 GB RAM, meist inaktiv)
    Unifi Controller
    Unifi Video
  • Re,

    cvb schrieb:

    Der derzeitige Flaschenhals (auch bei GBit) ist das RAID5 bestehend aus 4x4TB WD RED. Bei ca. 100MB/s schreibend ist Schluss, auch bei 10 GBit, da gehts manchmal noch auf 120-130 MB/s hoch.
    Ist trotzdem zu wenig bzw. liegt nicht nur an den WD Red - CPU + Speicher sind dafür auch zu gering bemessen, ggf. auch die Anbindung der jeweilgigen HBA aneinander.

    cvb schrieb:

    Wenn die Backups meines Desktops oder der Workstation (haben beide nur SSDs) laufen, wird es viel viel schlimmer, da fällt die Schreibrate unter 20 MB/s (da sehr viele kleine Dateien, knapp 1 TB davon).
    Das ist ein Mischproblem. Hier spielt nicht nur die Quelle und das Ziel eine Rolle, sondern auch der Übertrgungsweg (im logischen wie im physikalischen Sinne). Die Daten auf Senderseite in IP-Pakete zu verpacken kostet, wie auch auspacken oder anderweitig zu "prozessieren".

    Ich würde heut zu Tage auch kein RAID mehr einsetzen, und erst recht nicht mit deiner Hardware (neu). Da würde ich auf ZFS gehen, Komprimierung und Dedup reduzieren schon mal die Schreiblast, ggf. lässt ZFS auch höhere Prozessorlast zu (higher process priority).

    cvb schrieb:

    eine Samsung 960 Pro wird bei meinem Volumen aber auf Jahre weg keine Probleme bekommen,
    Damit wäre ich sehr vorsichtig, schon mal was von "write amplification" gehört? Besonders bei vielen kleinen Dateien kann das schnell nach hinten losgehen. Und wie schon geschrieben - OS und Cache auf einer SSD ist immer noch ein absolutes NoGo. Da würde ich dem Gesamtkonzept lieber noch eine kleine "normale" SSD spendieren und das OS darauf machen, als das gesamte System durch eine Misskonfig per SE zu gefährden ...

    cvb schrieb:

    NAS neu:
    Ich hoffe du hast die USV nur nicht aufgeführt, weil du es vergessen hast :D

    Sc0rp
  • Hi,

    ZFS geistert mir auch schon etwas länger im Kopf herum, allerdings scheue ich noch etwas den Aufwand - empfohlen wird ja komplett neu zu beginnen, d.h. alle Daten runter, alles neu machen, Daten wieder rauf ... <X
    Aber, schon gute Einwände von dir - gegen die Hardware an sich spricht ja nichts, und ich denke es wäre am einfachsten das ganze erst einmal mit der neuen Hardware zu testen. Bzgl. Netz-I/O-Last wären Jumboframes noch eine Option, aber nachdem die verwendete Netzwerkhardware durchgängig LRO/LSO unterstützt, wird das vermutlich auch nicht so viel bringen. Von der "write amplification" habe ich tatsächlich schon einmal gehört, allerdings nicht daran gedacht. Daher, als SSD für MVS verwende ich dann einfach die jetzige weiter, die m.2 und bcache lasse ich dann erst einmal weg. Erst einmal schauen, wie das neue NAS läuft - mein jetziges ist ja ein "Frankenstein-NAS", welches ich mit Ausnahme der WD REDs aus alter, nicht mehr gebrauchter Hardware zusammengestöpselt habe, um in Ruhe OMV zu testen. ^^

    Sc0rp schrieb:

    Ich hoffe du hast die USV nur nicht aufgeführt, weil du es vergessen hast

    Der geht es gut, ich hatte oben im Text ein kurzes "notstromversorgt" eingestreut :D

    Aber auch vielen Dank für die tollen, kompetenten Antworten !
  • Re,

    cvb schrieb:

    ZFS geistert mir auch schon etwas länger im Kopf herum, allerdings scheue ich noch etwas den Aufwand
    Ja, ZFS ist aufwändig und man muss sich zwingend damit beschäftigen und zwar intensiv!
    Auch ich mit über 20 Jahren RAID-Erfahrung muss umdenken. Aber an ZFS führt kein Weg vorbei, solange BTRFS nicht fertig und ausgiebig getestet ist - das gehört eben dazu, wenn man solche Systeme betreiben möchte ...

    cvb schrieb:

    Bzgl. Netz-I/O-Last wären Jumboframes noch eine Option,
    Jumbo-Frames sind dann eine Option, wenn du eine SAN-Infrastruktur über dein Ethernet betreibst ... oder viele große Blöcke transportieren möchtest (also "Dateien" oder Daten mit knapp unter 9.000 Byte :P) damit der Effekt des gesparten IP-Overhead zum Tragen kommt ... die Theorie kann man hier nachlesen. Auch hier gilt, das der gesamte Pfad (logisch wie auch physikalisch) das unterstützen muss - das ist nicht trivial!

    Sc0rp