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

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.
Fabian, Du verstehst meinen Ansatz nicht.

1. SSD
Proxmox BS Boot/EFI/ZFS 30GB + L2ARC 200GB + Special Devices

2. SSD
Proxmox BS Boot/EFI/ZFS 30GB + L2ARC 200GB + Special Devices

z.B. 6x HDD im ZFS Stripe Mirror

Die 2x L2ARC im Stripe, die 2x Special Devices im Mirror

Was soll bitte passieren? Wenn eine SSD ausfällt? Der L2ARC stirbt, mehr nicht! Die Special Devices sind wie das PBS System im Spiegel. Wie gesagt, meine EVO's haben nach einem Jahr Abnutzungen unter 10% beim L2ARC.
 
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.
Nicht wenn Du das partitionierst.
 
Ich sehe nicht, weshalb für das Special Device nicht auch ein normaler Mirror reichen sollte.
Und wenn du so hohe Anforderungen an deinen Pool hast, dass du sowohl ZIL als auch L2ARC als auch ein Special Device benötigst, solltest du eventuell darüber nachdenken, den gleich aus SSDs zu basteln.
 
Ich sehe nicht, weshalb für das Special Device nicht auch ein normaler Mirror reichen sollte.
Und wenn du so hohe Anforderungen an deinen Pool hast, dass du sowohl ZIL als auch L2ARC als auch ein Special Device benötigst, solltest du eventuell darüber nachdenken, den gleich aus SSDs zu basteln.
Der Punkt war nur (bei mir) Raidz2 (2 Redundanzen). Dies wollte ich nicht verkleinern, deshalb 3 SSD's. Klar geht auch mit 2x SSD. Man hat aber dann nur eine Redundanz, braucht auch dann nur ein Raidz1. Und bei mir sind 120TB pro PBS nicht wirtschaftlich mit SSD's zu haben.

Also wie gesagt, kleinstes Setup mit 2 SSD's, partioniert reicht auch (siehe oben). Danke H4R0 für den Hinweis. Siehe hier
 
Nicht wenn Du das partitionierst.
Davon wurde ja aber meist auch abgeraten. Einmal weil sich dann L2ARC, SLOG und Special Device gegenseitig die Leistung klauen und dann die Latenz sinkt die man ja eigentlich möglichst hoch haben möchte. Und dann vorallem weil ein SLOG ja ganz schnell die SSDs killt und man da nicht unbedingt dann noch die wichtigen Metadaten draufhaben möchte wenn sie dann ausfällt.
Ich sehe nicht, weshalb für das Special Device nicht auch ein normaler Mirror reichen sollte.
Und wenn du so hohe Anforderungen an deinen Pool hast, dass du sowohl ZIL als auch L2ARC als auch ein Special Device benötigst, solltest du eventuell darüber nachdenken, den gleich aus SSDs zu basteln.
So habe ich das aktuell auch. Einen Pool als Datengrab nur aus HDDs und dann halt Pools nur aus SSDs für VMs, DBs, kleine Dateien. SLOG und L2ARC würde bei mir auch wohl nicht so Sinn machen, da meine HDDs eher als Datengrab dienen wo die Dateien eh zu selten abgerufen werden und wenn sie mal abgerufen werden dann viel zu groß zum Cachen sind. Und NFS/SMB profitieren ja auch nicht wirklich von schnelleren Sync Writes. Special Devices wäre da aber vielleicht trotzdem interessant, dass da das Scrubing nicht ganz so lange dauert und SMB/NFS vielleicht besser mit vielen kleineren Dateien klarkommt.
Normaler Mirror ist dann ja wieder so eine Sache bei Raidz2. Dann könnte man auch gleich Raidz1 nehmen, wenn die Special Devices als normaler Mirror sonst eh das schwächste Glied sind.
 
Davon wurde ja aber meist auch abgeraten. Einmal weil sich dann L2ARC, SLOG und Special Device gegenseitig die Leistung klauen und dann die Latenz sinkt die man ja eigentlich möglichst hoch haben möchte. Und dann vorallem weil ein SLOG ja ganz schnell die SSDs killt und man da nicht unbedingt dann noch die wichtigen Metadaten draufhaben möchte wenn sie dann ausfällt.

So habe ich das aktuell auch. Einen Pool als Datengrab nur aus HDDs und dann halt Pools nur aus SSDs für VMs, DBs, kleine Dateien. SLOG und L2ARC würde bei mir auch wohl nicht so Sinn machen, da meine HDDs eher als Datengrab dienen wo die Dateien eh zu selten abgerufen werden und wenn sie mal abgerufen werden dann viel zu groß zum Cachen sind. Und NFS/SMB profitieren ja auch nicht wirklich von schnelleren Sync Writes. Special Devices wäre da aber vielleicht trotzdem interessant, dass da das Scrubing nicht ganz so lange dauert und SMB/NFS vielleicht besser mit vielen kleineren Dateien klarkommt.
Normaler Mirror ist dann ja wieder so eine Sache bei Raidz2. Dann könnte man auch gleich Raidz1 nehmen, wenn die Special Devices als normaler Mirror sonst eh das schwächste Glied sind.
Ich habe keinen SLOG im Einsatz weil ich keine Sync writes habe.
 
Der Punkt war nur (bei mir) Raidz2 (2 Redundanzen). Dies wollte ich nicht verkleinern, deshalb 3 SSD's. Klar geht auch mit 2x SSD. Man hat aber dann nur eine Redundanz, braucht auch dann nur ein Raidz1. Und bei mir sind 120TB pro PBS nicht wirtschaftlich mit SSD's zu haben.
Ich sehe keinen kausalen Zusammenhang zwischen der Anzahl der Redundanzen. Nur weil ich im Bulk notfalls auf zwei Platten verzichten können will, muss das im Sepcial Device nicht zwingend auch der Fall sein. Wem das wichtig ist, okay, aber einen Zusammenhang halte ich hier nicht für gegeben.

Aber ich glaube, wir schweifen etwas vom Thema ab.
 
Ich sehe keinen kausalen Zusammenhang zwischen der Anzahl der Redundanzen. Nur weil ich im Bulk notfalls auf zwei Platten verzichten können will, muss das im Sepcial Device nicht zwingend auch der Fall sein. Wem das wichtig ist, okay, aber einen Zusammenhang halte ich hier nicht für gegeben.

Aber ich glaube, wir schweifen etwas vom Thema ab.
Ja Du hast Recht. Das Thema verliert sich. Sorry.
 
So, heute läuft das erste Backup...
Code:
NAME        SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
stytank01  26.3T  25.0M  26.3T        -         -     0%     0%  1.00x    ONLINE  -

Code:
zpool status
  pool: rpool
 state: ONLINE
  scan: scrub repaired 0B in 00:00:43 with 0 errors on Sun May  9 00:24:44 2021
config:

        NAME                                                     STATE     READ WRITE CKSUM
        rpool                                                    ONLINE       0     0     0
          mirror-0                                               ONLINE       0     0     0
            ata-SAMSUNG_MZ7KM240HAGR-00005_S2HRNX0J401976-part3  ONLINE       0     0     0
            ata-SAMSUNG_MZ7KM240HAGR-00005_S2HRNX0J401757-part3  ONLINE       0     0     0

errors: No known data errors

  pool: stytank01
 state: ONLINE
config:

        NAME                                                   STATE     READ WRITE CKSUM
        stytank01                                              ONLINE       0     0     0
          raidz1-0                                             ONLINE       0     0     0
            ata-WDC_WD2001FFSX-68JNUN0_WD-WMC5C0D1LZD5         ONLINE       0     0     0
            ata-WDC_WD2001FFSX-68JNUN0_WD-WMC5C0D3404L         ONLINE       0     0     0
            ata-WDC_WD2001FFSX-68JNUN0_WD-WMC5C0D6U08D         ONLINE       0     0     0
            ata-WDC_WD2001FFSX-68JNUN0_WD-WMC5C0D78NCJ         ONLINE       0     0     0
            ata-WDC_WD2001FFSX-68JNUN0_WD-WMC5C0D9CNRT         ONLINE       0     0     0
            ata-WDC_WD3001FFSX-68JNUN0_WD-WCC135VUVDFE         ONLINE       0     0     0
            ata-WDC_WD3001FFSX-68JNUN0_WD-WCC135EH34AX         ONLINE       0     0     0
          raidz1-3                                             ONLINE       0     0     0
            ata-WDC_WD2001FFSX-68JNUN0_WD-WMC5C0DA95YF         ONLINE       0     0     0
            ata-WDC_WD2002FFSX-68PF8N0_WD-WMC6N0E6U9RS         ONLINE       0     0     0
            ata-WDC_WD2002FFSX-68PF8N0_WD-WMC6N0EAUML4         ONLINE       0     0     0
            ata-WDC_WD2002FFSX-68PF8N0_WD-WMC6N0L72SEN         ONLINE       0     0     0
            ata-WDC_WD2002FFSX-68PF8N0_WD-WMC6N0R83MCV         ONLINE       0     0     0
            ata-WDC_WD3001FFSX-68JNUN0_WD-WCC130HASY0L         ONLINE       0     0     0
            ata-WDC_WD3001FFSX-68JNUN0_WD-WCC132JTTADE         ONLINE       0     0     0
        special
          mirror-2                                             ONLINE       0     0     0
            nvme-Force_MP510_20098263000129531306              ONLINE       0     0     0
            nvme-Force_MP510_20098263000129531542              ONLINE       0     0     0
        logs
          ata-SAMSUNG_MZ7KM240HAGR-00005_S2HRNX0HB00643-part1  ONLINE       0     0     0
        cache
          ata-SAMSUNG_MZ7KM240HAGR-00005_S2HRNX0HB00643-part2  ONLINE       0     0     0

errors: No known data errors
Bin schon gespannt wie sich das dann in den nächsten Tagen verhält. Die Netzanbindung zum Cephcluster ist hier mit 2x 10Gigabit.
 
  • Like
Reactions: ph0x
Moin,

@fireon :

wie sehen denn Deine Erfahrungen aus? Wir stehen jetzt auch davor für den PBS neue Hardware anzuschaffen.

Das Setup wird mit 12 HDDS und mirrored Spezial-Devices geplant.
Wie verhält es sich beim den Restore raten?

Grüße

Gregor
 
Ja, ich bin hier noch am Daten sammeln. Grundsätzlich ist es bis jetzt sehr enttäuschend. Komm bei der Maschine nicht über 120MB/s hinaus, ab und zu gibt es Spitzen. Aber grundsätzlich wars das. Ich poste es noch genauer. Und beim Recover nicht über 40-60MB/s. Die Last am Server ist gleich 0.
 
Bei einer Chunk-Größe von 4 MB sind das immernoch 10-16 IOPS, ob HDDs bei der Art von Zugriff wirklich merklich schneller sein können, weiß ich nicht so recht.
 
Hier nun die genauen Zahlen für den Wochendurchschnitt:
Screenshot_20210622_092841.jpg
Screenshot_20210622_092901.jpg
Screenshot_20210622_092915.jpg
Screenshot_20210622_092930.jpg
Screenshot_20210622_092942.jpg

Und nun die Spitzen:
Die Spitzen mit 1G/s zeigt meinen Kopiertest mit "cp" Backupserver <--> Cephcluster.

Screenshot_20210622_093028.jpg
Screenshot_20210622_093041.jpg
Screenshot_20210622_093107.jpg
Screenshot_20210622_093125.jpg
Screenshot_20210622_093135.jpg

Fazit:
Das hinzufügen des Specialdevice reduzierte die Gesamtlast am Server gewaltig. Wir hatten teilweise ein I/O wait von über 80% und das über einen längeren Zeitraum. Somit wird die Datenautobahn wo man parallele Prozesse starten kann viel breiter. Bei der Geschwindigkeit selbst hat sich leider nicht viel geändert. Wenn ich nen total Crash hätte und viele TB's an Daten recovern müsste, hätte ich nicht viel zu Lachen. Es würde viel zu lange dauern. Bedeutet das man muss den Backupserver tatsächlich mit SSD-Only ausstatten? Das wäre nämlich ne ziemliche Investition, bei uns so wie auch bei den Kunden.
 
  • Like
Reactions: Dunuin
Wenn ich es richtig verstanden habe, wirken die Spezial Devices ja nur für neu geschriebene Daten?
War das in diesem Thread oder in einem anderen wo ich das gelesen habe?

Die Metadaten für den bisherigen Bestand liegen also noch auf den Spindeln.
 
Bedeutet das man muss den Backupserver tatsächlich mit SSD-Only ausstatten? Das wäre nämlich ne ziemliche Investition, bei uns so wie auch bei den Kunden.
Da hätte ich eine Idee! :D
Stell dir einen kleineren Datastore auf SSDs vor, auf dem nur die aktuellsten X Sicherungen lagern. Tiered Storage, wenn man so will. :D
Du könntest auf die SSDs sichern, was deine Backups beschleunigt und auch im Falle eines Falls die aktuellsten Sachen von den SSDs restoren, was dann entsprechend zackig geht. GC, Verify etc. sollte ja für die SSDs dann ohnehin entspannt sein.
Die älteren Sicherungen synchronisierst du lokal auf den HDD Datastore und lässt den in Ruhe rödeln.

Natürlich muss auf dem SSD Datastore genug Platz da sein für das Initialbackup... das muss aber nicht so furchtbar viel sein, wenn man Komprimierung und Deduplizierung von PBS berücksichtigt.

Die Micron 5210 ION 7.68TB kosten bspw. aktuell ~720€ netto. Immer noch ne Menge Holz, aber 2 davon sind deutlich günstiger als 20.
Davon abgesehen kann man das ja mal im kleineren Rahmen ausprobieren, evtl. mit Consumer Platten um einfach mal ein Proof of Concept davon zu kriegen.

Ich hab bei mir aufm PBS gute Erfahrungen gemacht mit einer ZFS recordsize von 4M, musste den Parameter zfs_max_recordsize entsprechend anheben. Mit LZ4 & ZSTD komme ich jeweils auf ca. 1.30x Compress Ratio, bei div. VMs im Datastore.
Das wäre ja auch nochmal ein erheblicher Speichergewinn.
 
Last edited:
Wenn ich es richtig verstanden habe, wirken die Spezial Devices ja nur für neu geschriebene Daten?
War das in diesem Thread oder in einem anderen wo ich das gelesen habe?

Die Metadaten für den bisherigen Bestand liegen also noch auf den Spindeln.
Der Datenbestand wurde komplett gelöscht (neue Backuppool) und die Sicherung wurde neu befüllt.
 

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!