Wir haben einen zentralen Speicherserver (PowerEdge R720), der freigegebene Dateien an einen HPC-Cluster bereitstellt, und an den zwei Hardware-RAID-Controller angeschlossen sind (PERC H810, die jeweils zwei MD1200-Gehäuse mit 4-TB-Festplatten mit 7200 U/min antreiben). Wie bei einer typischen HPC-Arbeitslast wird erwartet, dass das Zugriffsmuster hochparallele sequentielle Lese-/Schreibvorgänge sind. Ich nehme an, dass das Striping von Dateien auf die beiden Arrays einen besseren Gesamtdurchsatz ergeben würde, aber die Idee von Software-RAID 0 auf Hardware-RAID klingt für mich verrückt.
Mir sind zwei Möglichkeiten eingefallen:
- NFS auf XFS auf Software-RAID 0 auf Hardware-RAID 6
- Glanz auf jedem Hardware-RAID 6
Vorteile von XFS: Projektkontingent.
Nachteile von XFS: NFS auf XFS zeigte eine sehr schlechte Metadatenleistung (würde sich bei großem Durchsatz bis nahezu unbrauchbar verschlechtern, habe ich es falsch eingestellt?).
Vorteile von Lustre: deutlich bessere Metadatenleistung.
Nachteile von Lustre(?): Wir haben kein dediziertes Metadatengerät, müssen ein Array partitionieren. Klingt nicht nach einer empfohlenen Vorgehensweise.
Wir haben die Metadatenleistung berücksichtigt, da zwar sequentielles Lesen und Schreiben die Hauptarbeitslast darstellt, einige unserer Programme jedoch mit Dateien von ca. 40.000 1 GB arbeiten. Die interaktive Verwaltung dieser Dateien erfordert eine akzeptable Metadatenleistung.
Und zum Schluss noch eine Frage: Welche Streifengrößen sollen auf der Hardware und der Software verwendet werden?
Antwort1
Wir haben uns für dieses Setup entschieden:
- Hardware-RAID-6 in jedem MD1200-Gehäuse
- Zwei LVM LVs auf den vier Hardware-Arrays, die jeweils die beiden Arrays auf den beiden Karten kombinieren, ohne Striping
- XFS auf den beiden LVs, Striping-Optionen dieselben wie für Bare-Hardware-Arrays
- Ein Gluster-Volumen auf den beiden Ziegeln, ohne Streifen
Wir haben alle Anwendungen unserer Benutzer untersucht und festgestellt, dass sie alle mit vielen Dateien arbeiten. Es ist also nicht die Situation, in der viele Clients auf eine einzige große Datei zugreifen, bei der Striping auf Gluster-Ebene erwünscht ist; stattdessen reicht schon die zufällige Verteilung der Dateien auf die Bricks aus, um einen ausreichenden Gesamtdurchsatz zu erzielen.
Obwohl die Metadatenleistung dieses Setups schlechter ist als die von Lustre (etwa halb so hoch), verschlechtert sie sich bei hohem Durchsatz nicht. Es hat sich als akzeptabel erwiesen.
Gluster konfiguriert Kontingente für Verzeichnisse und ist zudem viel einfacher einzurichten als Lustre, sodass der Verwaltungsaufwand deutlich geringer ist. In meinen (groben) Tests ist der sequentielle Durchsatz dieses Setups mit dem von Lustre vergleichbar, daher haben wir uns entschieden, diesen Teil der Metadatenleistung gegen eine einfachere Verwaltung einzutauschen.