Hallo,
folgende Hardware: HPE DL380 Gen10, 6 * 8TB HDD, 2 * 500MB SSD für Daten, zusätzlich 2* 240MB SSD fürs Betriebssystem, 512 GB RAM, 2* CPU Xeon Gold <irgendwas>
Der Server kann die Datenplatten entweder als HW-RAID ansprechen oder als HBA ansprechen. Ich wollte ZFS einsetzen.
Meine Tests sind weit fortgeschritten, ich erhiellt keine einzige brauchbare Konfiguration. Alles Müll....
Egal ob ich einen ZFS Verbund der 6 HDD als RAID-Z1, RAID-Z2 oder RAID-10 aufsetzte, egal ob ich die SSD als L2ARC oder fürs Journal einsetzte oder nicht, egal ob ich sync=Standard oder sync=always nutze, erhielt ich folgende Symptomatik: Schreibvorgänge sind unerträglich langsam.
Es sollten z.B. während der Versuche vzdump-Dateien aus dem Produktivsystem auf die neuen Server per NFS übertragen werden. Alter und neuer Server sind mit 10 GB/s miteinander verbunden, der alte Server kann die vzdump-Dateien mit ca 300 MB/s von seiner Platte lesen, und mit diesen Werten kommen sie auch beim neuen Server an. Hat der alte Server diese bereits in seinem Cache, so kommen die Daten mit mehr als 1 GB/s an. OK soweit für den LAN-Anteil.
Dann beginnt das Trauerspiel: Mache ich auf dem neuen Server ein Restore, so werden zuerst die Prozentzahlen relativ schnell hochgezählt, aber nach einigen Prozentpunkten verlangsamt sich der Restoreprozeß bis zur völligen Untauglichkeit. Lagen (fiktive Werte, aber es lag in diesen Bereichen) zwischen 1% und vielleicht 7% Zeitabstände von 60 Sekunden zwischen den Prozentpunkten, so verlangsamt sich das danach auf Werte von bis zu Stunden zwischen den einzelnen Prozentpunkten. Wir reden hierbei vom Restore einer VM mit etwas weniger als 1 TB an Platten und einer vzdump-Datei von ca 400 GB. Bei kleineren VM kommt der beschriebene Effekt eben etwas später, aber er kommt. Teilweise werden 100% erreicht, aber dann folgt eine Gedenkstunde bis "Task OK" erscheint.
Was ich herausfand: Mittels "cat /proc/meminfo" sah ich, daß der "Dirty"-Wert abstrus hohe Werte annimmt. Während die Prozentzahlen noch schnell ansteigen, steigt der "Dirty"-Wert ebenfalls und kann durchaus Werte von 90 GB erreichen. Er sinkt -auch wenn keine Schreibzugriife mehr erfolgen- nur extrem langsam wieder ab. Es dauert somit wiederum Stunden, bis der Linux-Schreibcache auf die Platten gekommen ist. Ein "sync" verharrt dann ebenfalls diese Zeit.
iostat wirft Werte von in der Regel 8000 kB/s für die Schreibvorgänge auf die einzelnen Platten des ZFS-Verbunds aus, was natürlich unterirdisch schlecht ist. Gleichzeitig liegt die Utilization der Platten bei für diese mickrige Schreibrate bei Werten von ca 80-90%.
Eine Möglichkeit, eine Festplatte so dermaßen langsam zu bekommen, wäre die wahllose Verteilung der Daten auf die Platte mit unzähligen Kopfbewegungen. Ich wage zu hoffen, daß ZFS das nicht in dieser Form macht. Eine weitere Möglichkeit wäre, sich tot zu administrieren. Die CPU-Auslastungen sind aber relativ gering.
Nutze ich die Platten als HW-RAID, dann erhalte ich "vernünftige" und der Hardware entsprechende Werte: Die beschriebene VM ist in weniger als 1 Stunde auf dem neuen Server lauffähig, der Dirty-Wert erreicht während des Restore kaum mal 1 GB (meist sehr viel weniger, und er sinkt auch sehr schnell wieder ab), die Schreibrate auf das Array -wiederum mit iostat ermittelt- liegt bei 6-stelligen Werten, oftmals hat das HW-RAID sogar Zeit für Pausen, und Writeback-SSD ist da noch nicht einmal im Spiel.
Was mir noch auffiel: Bei den ZFS-Versuchen erhielt ich 7-stellige Prozeß-ID, obwohl der Server erst seit ein paar Tagen lief und noch nichts Produktives geleistet hatte. Beim Versuch mit HW-RAID blieben die Prozeß-ID im üblichen 5-stelligen Bereich. Das könnte (wilde Spekulation) darauf hindeuten, daß ZFS für jeden mickrigen Schreibvorgang einen eigenen Prozeß mit erheblichem Overhead erzeugt.
Verbleibt noch zu erwähnen, daß ich nach wie vor ZFS u.A. aufgrund der Replikationsmöglichkeiten einsetzen will.
folgende Hardware: HPE DL380 Gen10, 6 * 8TB HDD, 2 * 500MB SSD für Daten, zusätzlich 2* 240MB SSD fürs Betriebssystem, 512 GB RAM, 2* CPU Xeon Gold <irgendwas>
Der Server kann die Datenplatten entweder als HW-RAID ansprechen oder als HBA ansprechen. Ich wollte ZFS einsetzen.
Meine Tests sind weit fortgeschritten, ich erhiellt keine einzige brauchbare Konfiguration. Alles Müll....
Egal ob ich einen ZFS Verbund der 6 HDD als RAID-Z1, RAID-Z2 oder RAID-10 aufsetzte, egal ob ich die SSD als L2ARC oder fürs Journal einsetzte oder nicht, egal ob ich sync=Standard oder sync=always nutze, erhielt ich folgende Symptomatik: Schreibvorgänge sind unerträglich langsam.
Es sollten z.B. während der Versuche vzdump-Dateien aus dem Produktivsystem auf die neuen Server per NFS übertragen werden. Alter und neuer Server sind mit 10 GB/s miteinander verbunden, der alte Server kann die vzdump-Dateien mit ca 300 MB/s von seiner Platte lesen, und mit diesen Werten kommen sie auch beim neuen Server an. Hat der alte Server diese bereits in seinem Cache, so kommen die Daten mit mehr als 1 GB/s an. OK soweit für den LAN-Anteil.
Dann beginnt das Trauerspiel: Mache ich auf dem neuen Server ein Restore, so werden zuerst die Prozentzahlen relativ schnell hochgezählt, aber nach einigen Prozentpunkten verlangsamt sich der Restoreprozeß bis zur völligen Untauglichkeit. Lagen (fiktive Werte, aber es lag in diesen Bereichen) zwischen 1% und vielleicht 7% Zeitabstände von 60 Sekunden zwischen den Prozentpunkten, so verlangsamt sich das danach auf Werte von bis zu Stunden zwischen den einzelnen Prozentpunkten. Wir reden hierbei vom Restore einer VM mit etwas weniger als 1 TB an Platten und einer vzdump-Datei von ca 400 GB. Bei kleineren VM kommt der beschriebene Effekt eben etwas später, aber er kommt. Teilweise werden 100% erreicht, aber dann folgt eine Gedenkstunde bis "Task OK" erscheint.
Was ich herausfand: Mittels "cat /proc/meminfo" sah ich, daß der "Dirty"-Wert abstrus hohe Werte annimmt. Während die Prozentzahlen noch schnell ansteigen, steigt der "Dirty"-Wert ebenfalls und kann durchaus Werte von 90 GB erreichen. Er sinkt -auch wenn keine Schreibzugriife mehr erfolgen- nur extrem langsam wieder ab. Es dauert somit wiederum Stunden, bis der Linux-Schreibcache auf die Platten gekommen ist. Ein "sync" verharrt dann ebenfalls diese Zeit.
iostat wirft Werte von in der Regel 8000 kB/s für die Schreibvorgänge auf die einzelnen Platten des ZFS-Verbunds aus, was natürlich unterirdisch schlecht ist. Gleichzeitig liegt die Utilization der Platten bei für diese mickrige Schreibrate bei Werten von ca 80-90%.
Eine Möglichkeit, eine Festplatte so dermaßen langsam zu bekommen, wäre die wahllose Verteilung der Daten auf die Platte mit unzähligen Kopfbewegungen. Ich wage zu hoffen, daß ZFS das nicht in dieser Form macht. Eine weitere Möglichkeit wäre, sich tot zu administrieren. Die CPU-Auslastungen sind aber relativ gering.
Nutze ich die Platten als HW-RAID, dann erhalte ich "vernünftige" und der Hardware entsprechende Werte: Die beschriebene VM ist in weniger als 1 Stunde auf dem neuen Server lauffähig, der Dirty-Wert erreicht während des Restore kaum mal 1 GB (meist sehr viel weniger, und er sinkt auch sehr schnell wieder ab), die Schreibrate auf das Array -wiederum mit iostat ermittelt- liegt bei 6-stelligen Werten, oftmals hat das HW-RAID sogar Zeit für Pausen, und Writeback-SSD ist da noch nicht einmal im Spiel.
Was mir noch auffiel: Bei den ZFS-Versuchen erhielt ich 7-stellige Prozeß-ID, obwohl der Server erst seit ein paar Tagen lief und noch nichts Produktives geleistet hatte. Beim Versuch mit HW-RAID blieben die Prozeß-ID im üblichen 5-stelligen Bereich. Das könnte (wilde Spekulation) darauf hindeuten, daß ZFS für jeden mickrigen Schreibvorgang einen eigenen Prozeß mit erheblichem Overhead erzeugt.
Verbleibt noch zu erwähnen, daß ich nach wie vor ZFS u.A. aufgrund der Replikationsmöglichkeiten einsetzen will.
