Proxmox Backup Server mit hochkapazitiven Toshiba Festplatten

Ein häufiger Kritikpunkt an großen HDD-Pools – insbesondere im Zusammenhang mit ZFS unter PBS – ist jedoch die Performance. Der Pferdefuß: PBS speichert jegliche Daten in 4 MB großen Chunks. Die Priorität beim Speicherzugriff liegt bei der Proxmox-Backup-Lösung auf hohe IOPS und nicht wie üblich im Backup-Sektor auf sequenziellen Lese-/ und Schreibvorgängen. 

Also gut für SSDs und schlecht für HDDs.

Und genau hier kommt der Metadaten Cache – auch special device oder special vdev genannt – zum Einsatz: Dieser Cache besteht aus NVMe Datenträgern, die bekanntlich opulente IOPS-Werte erreichen. Sie übernehmen ab Erstellung die komplette Speicherung der Metadaten des ZFS-Pools. Normalerweise befinden sich diese Daten auf den Daten-vdevs, werden mit diesem aber ausgelagert. 

Dies erhöht deutlich die Zugriffszeiten und dadurch die Verify, Prune und Garbage-Collection Jobs des PBS. Grundsätzlich gilt: Ein Metadaten-Cache ist ab mehreren Terabytes unter Einsatz von HDDs bei PBS ein Muss! Als Folge bleiben allerdings Backup-Jobs sehr großen Datensätzen performant, während die eigentlichen Nutzdaten kosteneffizient auf den Toshiba-HDDs gespeichert werden.

Allerdings birgt der Metadaten-Cache auch ein Risiko. Dadurch, dass sich dort alle Metadaten des Pools befinden, würde bei einem Ausfall des special vdevs, der ganze Pool verloren gehen. Daher sichert ihn Starline grundsätzlich im 3-Wege-Spiegel ab. Optimalerweise besteht dieses special vdev aus NVMes, wobei es egal ist, ob es sich um M.2 oder U.2 Gehäusevarianten handelt. 

Um die Ausfallsicherheit weiter zu maximieren, sollten unterschiedliche Hersteller für den 3-Wege-Spiegel verwendet werden. Beispielsweise 2x Kioxia SSDs und 1x Samsung SSD. Als sehr platzsparend für M.2 Modelle haben sich AOC-Adapterkarten herausgestellt. 

Bezüglich Skalierung gilt die Faustregel: 

Ca. 3 GB special vdev pro Terabyte an Speicher.

Natürlich müssen auch die Festplatten untereinander redundant abgesichert werden. Zwei Varianten eignen sich für das Projekt mit dem 36-Bay-Gehäuse:

RAIDZ2: Min 4, Max 10 ⇾ Kapazität: Terabyte der kleinsten Festplatte * (Anzahl - 2)

RAIDZ3: Min 5, Max 12 ⇾ Kapazität: Terabyte der kleinsten Festplatte * (Anzahl - 3)

Beispiel – Daten-vdev unter RAIDZ3 mit 12 HDDs bei einer Kapazität von jeweils 20 TB ergibt:

20 TB * (12-3) = 20 TB * 9 = 180 TB Nutzkapazität pro vdev

Wir empfehlen generell, mehrere kleine vdevs statt weniger großer zu erstellen. RAIDZ1 verwenden wir in diesem Fall überhaupt nicht. Schließlich steht man im Falle eines Ausfalles ohne jegliche Redundanz da. Sollte also während des Resilverings etwas schiefgehen, haben wir einen Datenverlust: Der Datenbestand des gesamten vdev ist dann verloren.

Das Limit pro vdev ist als "weiches" Kriterium festgelegt, sollte aber dennoch nicht überschritten werden. Der Hintergedanke dazu betrifft den Prozess des Resilverings: Bei einem Plattenaustausch werden jegliche Daten von den anderen Platten gelesen, um die Daten auf den neuen Platten zu verteilen. Und gerade hier ist es recht wahrscheinlich, wenn Platten gleichen Alters, Laufzeit oder Auslastung betroffen sind, dass weitere Platten ausfallen könnten. Das Risiko steigt also mit der Anzahl der Platten in einem vdev.