Hardwareempfehlung für PBS (Restore bis jetzt nicht brauchbar) 10-40Gbit

fireon

Distinguished Member
Oct 25, 2010
4,484
466
153
Austria/Graz
deepdoc.at
Hallo Leute,

wir verwenden nun schon bei einigen Kunden PBS. Großer Vorteil: "Der Sicherungsprozess selbs geht super schnell von statten, weil es eben nicht die großen Änderungen gibt." Nun ganz anders sieht es mit dem zurück sicheren aus. Da muss natürlich immer alles kopiert werden. Hier schafften wir bis jetzt maximal zwischen 15 und 55MB/s. Wobei die 15MB/s bei einem ZFS RaidZ10 mit 6HDD's erreicht wurden, und die 55MB/s bei einem ZFS Raid10 mit 8HDD's. Einen Backupserver mit "nur" SSD's haben wir noch nicht im Einsatz. Den Artikel zum Special Device habe ich schon gelesen. Bei dem RaidZ10 haben wir ne I/O wait von 25 bis 30 wenn wir 3 Maschinen zur gleichen Zeit zurück spielen. Der Durchsatz wenn wir einen Recoveryprozess anstarten, lag hier beim RaidZ10 bei ca 15MB/s.

Nun wir verbauen jetzt nur mehr 10 und 40Gbit Netzwerk und Server. Natürlich hilft das wenig, wenn der Recovery Prozess des Backups ewig dauert. Meine Frage:
  • Hat wer schon Erfahrung, bringt das Special Device wirklich so viel damit man auch ein Recovery mit 10Gbit normal durchführen kann. Z.B. 8xHDD + zpool Raid1 Special Device? Oder bringt das nur was beim Schreiben von Backups.
  • Oder müssen wir nun die Backupserver auch mit SSD's Raids ausstatten? Wenn ja, was für ein ZFS Raidlevel? Genügt ein RaidZ10 oder muss es ein Raid10 sein?
Vielen Dank und glg
Fireon
 
Also ich hab hier einen PBS mit 5 5400er Spindeln im RAIDz2 und 2 SATA-SSDs als Special Device.
Habe gerade mit 125 MB/s über 10G zurückgespielt.
 
Also ich hab hier einen PBS mit 5 5400er Spindeln im RAIDz2 und 2 SATA-SSDs als Special Device.
Habe gerade mit 125 MB/s über 10G zurückgespielt.
Das ist jetzt ne interessante Aussage. Weil das widerspricht alles was wir bis jetzt hier erlebt hatten. Die Backupserver hier sind alle bis jetzt mit "nur Gigabit" angebunden. Aber das kann ja nicht soviel Overhead produzieren. Aber gut, ich kanns mit 10G testen.
 
Ich denke, dass der Speedup eher durch das Special Device kommt. :)
Da wirst du vermutlich Recht haben. So wie es in der Doku steht, wenn man das einmal hinzufügt, muss es auch bleiben.

Verständnisfrage: Das Specialdevice ist nicht das gleiche wie logs und cache bei einem Zpool, aber ist es eine Verbesserung im allgemeinen, sprich wenn ich ein Special Device verwende benötige ich kein log/cache mehr. Oder wie ist das zu verstehen.
 
Da wirst du vermutlich Recht haben. So wie es in der Doku steht, wenn man das einmal hinzufügt, muss es auch bleiben.

Verständnisfrage: Das Specialdevice ist nicht das gleiche wie logs und cache bei einem Zpool, aber ist es eine Verbesserung im allgemeinen, sprich wenn ich ein Special Device verwende benötige ich kein log/cache mehr. Oder wie ist das zu verstehen.

das special device (bzw. die devices, sollte immer redundant ausgefuehrt sein, s.u.!) speichert im default setup statt den anderen vdevs die metadaten. zusaetzlich laesst sich auch noch ein grenzwert einstellen, unter dem auch daten-nodes auf die special devices geschrieben werden (dann muessen die allerdings entsprechend groesser sein damit sie nicht gefahr laufen voll zu werden).

da die special vdevs STATT anderen vdevs genutzt werden und nicht (wie bei log/cache) zusaetzlich, koennen sie auch nicht (raidz) bzw. nicht ohne performance einbussen (rest) entfernt werden, und ein ausfall aller special vdevs fuehrt dazu dass der pool nicht mehr importierbar/lesbar ist!

bei einem spinning pool ist bei PBS die seek time das bottle neck, dadurch das mit einem special vdev die metadaten requests nicht mehr auf die spinning disks gehen bleibt quasi das ganze budget fuers chunk/index daten lesen uebrig. das wird schon spuerbar sein, aber wunder darfst du dir keine davon erwarten - sh. README fuer ein paar "bierdeckelrechnungen" bzgl verschiedener plattenarten und chunk groessen.

ahja, und den benefit von special vdevs hast du erst wenn ALLE daten neu geschrieben worden sind (z.b. mit send/recv), sonst liegen die metadaten ja nach wie vor auf den spinning disks ;)
 
ein log (bei PBS eher weniger) / cache (je nach restore/sync workload) device macht unter umstaenden trotzdem sinn. wenn dein cache vdev gross genug ist (und das access pattern entsprechend) dass deine letzten backups immer (auch) im cache liegen, dann ist ein restore davon bzw. ein sync sicher schneller als ohne. ist halt schwer da ne allgemeingueltige aussage zu treffen..
 
Einfaches aber gutes Setup
  1. Installiere pbs auf 2x 500GB SSD's mit ZFS Mirror, aber nur 2x30GB Partitionen (gpt Layout, nicht mbr)
  2. installiere folder2ram um die SSD's langlebiger zu machen (bei NICHT Enterprise SSD's)
  3. lege mit fdisk auf jeder SSD weitere Partitionen an, z.B. 1x 200GB Type ZFS und 1x Rest 200GB ZFS, den Rest lasse frei (Reserve Sektoren)
  4. die ersten Partitionen schalte als Stripe für L2ARC (kein Problem wenn die ausfallen)
  5. die letzten Partitionen als Special Device Mirror
  6. ZIL brauchst Du nicht

Das sollte rennen und ist günstig.
 
special und l2arc und regulaere vdevs auf dieselben SSDs zu packen macht wenig sinn.. log, cache und special vdevs muessen immer performanter als die "normalen" vdevs sein damit die performance besser werden kann..
 
Schönen Guten Morgen wünsche ich, und vielen Dank für die Nachrichten. Ich geh jetzt mal Hardware einkaufen :cool: .
 
ahja, und den benefit von special vdevs hast du erst wenn ALLE daten neu geschrieben worden sind (z.b. mit send/recv), sonst liegen die metadaten ja nach wie vor auf den spinning disks ;)
Bedeutet das nun das ich mal alle Backups komplett löschen muss? Oder wie ist das gemeint.
 
special und l2arc und regulaere vdevs auf dieselben SSDs zu packen macht wenig sinn.. log, cache und special vdevs muessen immer performanter als die "normalen" vdevs sein damit die Performance besser werden kann..
Hi, Fabian. Du hast es nicht richtig verstanden. Auf der SSD ist nur das ZFS vom BS, kein DATASTORE, deshalb nur 30GB. Und dann ist die Option

ZFS Mirror für Proxmox OS + Strip L2ARC für DATASTORE + Special Device Mirror für DATASTORE - genau das Richtige. Der Datastore ist ja hier ein Festplattenverbund.
 
  • Like
Reactions: birdy
Hi, Fabian. Du hast es nicht richtig verstanden. Auf der SSD ist nur das ZFS vom BS, kein DATASTORE, deshalb nur 30GB. Und dann ist die Option

ZFS Mirror für Proxmox OS + Strip L2ARC für DATASTORE + Special Device Mirror für DATASTORE - genau das Richtige. Der Datastore ist ja hier ein Festplattenverbund.
das geht natuerlich (aber l2arc wuerde ich bei consumer SSDs nicht nehmen :)) - davon stand aber nix im post ;)
 
Hi, Fabian. Du hast es nicht richtig verstanden. Auf der SSD ist nur das ZFS vom BS, kein DATASTORE, deshalb nur 30GB. Und dann ist die Option

ZFS Mirror für Proxmox OS + Strip L2ARC für DATASTORE + Special Device Mirror für DATASTORE - genau das Richtige bei 2x500GB SSD's. Der Datastore ist ja hier ein Festplattenverbund und hat nichts mit den beiden SSD's zu tun.
 
Bedeutet das nun das ich mal alle Backups komplett löschen muss? Oder wie ist das gemeint.
nein - du kannst sie entweder lassen (dann ist es halt schwer zu beurteilen wieviel die SSDs bringen, weil erstmal nur komplett neu geschriebene chunks davon profitieren), oder wenn du noch genug platz hast, mittels zfs send/recv oder rsync den bestehenden datastore kopieren und dann mit der kopie weiter arbeiten (ist vll sogar spannend zwecks direktem vergleich zwischen alt und neu).
 
  • Like
Reactions: fireon
Auch consumer SSD sind beim L2ARC (nicht ZIL) möglich. Nach einem Jahr habe ich eine Abnutzung bei Samsung EVO 860 von 4%.
natuerlich ist es moeglich. die SSD kann halt unter umstaenden schnell den geist aufgeben wenn am spinning pool entsprechender durchsatz ist. wenn dann auch noch die special vdevs auf derselben SSDs sind (/waren), sind alle daten futsch.
 
Wie ist das inzwischen mit dem SLOG? Ich lese da öfter das man früher das SLOG als Mirror brauchte aber heute nicht mehr unbedingt weil ZFS irgendwas geändert hat und dann halt die Daten aus dem RAM genommen werden wenn der SLOG ausfällt. Problem wäre dann nur wenn ein Stromausfall/Kernelcrash stattfindet und beim Reboot dann gleichzeitig auch der SLOG ausfällt.

Wenn ich das richtig sehe bräuchte man dann ja mindestens 6 SSDs wenn man einen Raidz2 Pool aus HDDs beschleunigen möchte. Also 3x SSDs als Dreifach-Mirror für das Special-Device, 2x SSDs als als Mirror für SLOG und 1x SSD als L2ARC.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!