Hallo an alle MD-Raid-Experten
Ich verwende Centos 8 (mit allen neuesten Updates, Kernel 4.18.0-240.1.1.el8_3.x86_64), wo ich 3x2T Samsung SSD 860 QVO 2TB in RAID5 habe (als Basis für einige KVM-VMs) und wenn ich etwas mache, das Verwerfen beinhaltet, ist es nicht nur langsam, sondern viel zu unbrauchbar. Ich habe ein 1,5T LV erstellt und dann „mkfs.ext4“ ausgeführt. Nach 4 Stunden sagte mir die Verwerfungsphase „Geräteblöcke werden verworfen: 10489856/409148416“ und zuerst dachte ich „4 Stunden für 25 %, das ist Mist“, aber dann wurde mir klar, dass es nur 2,5 % sind, also reden wir von einer Woche!
Ich habe den Raid aufgelöst und auf den drei einzelnen Laufwerken „blkdiscard“ ausgeführt, was jeweils etwa 18 Sekunden gedauert hat.
Die Hardware ist ein HP Proliant DL380p Gen8 mit einem Smart Array P420i-Controller (keine speziellen Treiber, alles verwendet Standard-Centos-Treiber), den ich für den HBA-Modus konfiguriert habe, sodass es sich nur um ein Passthrough handeln sollte (Verwerfen wird bei Verwendung von Hardware-RAID überhaupt nicht unterstützt).
Nachdem ich die Geräte verworfen hatte, erstellte ich den Raid erneut mit
mdadm --create /dev/md20 --level=5 --raid-devices=3 --chunk=64 /dev/sd{b,d,e}1
Ich habe es über Nacht synchronisieren lassen. Dann habe ich ein VG erstellt und die LV-Erstellung getestet. Es dauerte 7 Minuten, um 100 M zu verwerfen.
root@terrok:~ # lvcreate -nDELME -L100M vgssd2 && date && time mkfs.ext4 /dev/vgssd2/DELME && date && time lvremove -f /dev/vgssd2/DELME;date
Logical volume "DELME" created.
Mon Dec 21 12:47:42 EST 2020
mke2fs 1.45.6 (20-Mar-2020)
Discarding device blocks: done
Creating filesystem with 102400 1k blocks and 25688 inodes
Filesystem UUID: f7cf3bb6-2764-4eea-9381-c774312f463b
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729
Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
real 7m20.095s
user 0m0.004s
sys 0m0.195s
Mon Dec 21 12:55:02 EST 2020
Logical volume "DELME" successfully removed
real 7m17.881s
user 0m0.018s
sys 0m0.120s
Mon Dec 21 13:02:20 EST 2020
root@terrok:~ #
Zum Vergleich: Ich habe auf dem gleichen System auch zwei WDC WDS100T2B0A-00SM50 (1T SSD) im Raid1 und dort funktioniert das Verwerfen viel schneller, 4 Sekunden für 10G.
Ich habe dann zwei der Samsung-SSDs genommen und daraus ein Raid1 gemacht, mit voller Geschwindigkeit beim Verwerfen. Das habe ich für die anderen beiden Laufwerkskombinationen wiederholt und es gab keine Probleme. Für mich deutet das auf ein Problem mit Raid5 hin. Im Moment habe ich zwei der SSDs in Raid1 mit einem Hotspare und das funktioniert zumindest, aber es sind natürlich 2 TB weniger Speicherplatz, als ich erwartet hatte.
Irgendwelche Vorschläge, was ich tun kann, um dies mit RAID 5 nutzbar zu machen?
Antwort1
Wie Ihre Tests gezeigt haben, erfordert RAID5 tatsächlich mehr Operationen als ein einfaches RAID 1-Array. Denn RAID 1 ist im wahrsten Sinne des Wortes nur die Synchronisierung zwischen zwei Festplatten, das ist alles.
RAID 5 hingegen muss alle Berechnungen auf drei Festplatten durchführenUndparitätisch zu gestalten. Das ist eine Menge Arbeit, zumindest im Vergleich zu einem „einfachen“ RAID-1-Array.
Außerdem sind QVO-Laufwerke nicht ideal für Lasten wie die Wartung von VMs, bei denen die Aktivitäten der Laufwerke normalerweise sehr hoch sind. Das Gleiche gilt für Paritätsarrays wie RAID 5 usw. Angesichts dessen und der Situation mit RAID5 selbst sollten Sie Ihre Bereitstellungsstrategien überdenken.
Antwort2
Ich habe mich gerade auch mit diesem Problem befasst. Ich habe mich mit dem Treiber von raid5 befasst und festgestellt, dass raid5 die eingehenden Discard-Anfragen in 4k-Discard-Anfragen an die zugrunde liegenden Geräte aufteilt. Außerdem ist es schon seit einiger Zeit defekt, sodass devices_handle_discard_safely praktisch ignoriert wird. Infolgedessen werden alle 4k-Discards synchron zum zugrunde liegenden Gerät ausgeführt, was den Vorgang insgesamt noch langsamer macht. Randbemerkung: Ich werde es bald in LKML einbinden, also können Sie dort dranbleiben. Ich kenne keine Problemumgehung, die mit vorhandenen Kerneln verfügbar ist.