Storageserver für kleinen MPI-Cluster

flxmmr

Experte
Thread Starter
Mitglied seit
15.01.2015
Beiträge
3.623
Hallo zusammen,

in der Arbeit (=Uni) ist nun endlich Geld+Wille da, die bestehende "Cluster"-Infrastruktur (~200 Kerne, die stückweise angeschafft wurden) aufzurüsten. Die Rechennodes traue ich mir auch zu auszuschreiben, sodass wir da bekommen, was wir brauchen (Kerne für DFT und GPUs für ML), bei einem Storageserver leider nicht. Grundsätzlich brauchen wir in allen Fällen auf Dauer wohl eh einen Administrationsverantwortlichen (Software), an sich könnte man also auch qualifiziert basteln, aber grundsätzlich ist ein All-in-one-Angebot mit möglichst langer Wartung (10a wird es nicht zu vertretbaren Preisen geben :fresse2::sleep:) zumindest für den Speicher erstrebenswert. Wenn man das jetzt unqualifiziert ausschreibt, kommen halt vmtl. Systemhäuser, die uns das verkaufen, was wir bisher eingekauft haben, was imho reichlich am Ziel vorbeiging...

Ausgangssituation: 5 Server mit jeweils 5TB im RAID5 (5x1TB@3.5 Zoll/7200rpm) in einem Rack an einem Gigabit-Switch. Früher alle einzeln betrieben, jetzt als SLURM-"Cluster" (das Netzwerk reicht allerdings nicht für wirkliches Clustering aus). Als shared-fs wurde dann irgendwann ein Gluster eingerichtet, da man so immerhin auf unterschiedlichen Maschinen Dinge starten kann, ohne lange per rsync zu synchronisieren (und außerdem bei Server-Ausfall (aus diversen Gründen...) alle Daten da sind...). Die Crux daran ist, dass das einfach furchtbar lahm ist, git funktioniert kaum (was auf allen Cluster-FS wohl so ist) und wenn man 1min rechnet, braucht man erstmal 30s um die 500MB Ergebnisdaten auf die Festplatte zu schreiben (auf dem lokalen RAID5 um den Faktor ~10 schneller).

Anforderungen: Fileserver und geeignetes Storage-Netzwerk, um mittelfristig 20-30 Clients zu bedienen.
- Verfügbarkeit des ganzen: ich sage mal Ausfallzeit < 2 Werktage, die Daten sollten allerdings dann bei Wiederinbetriebnahme noch da sein.
- Speicherplatz: während der Simulationen können auch mal ein paar dutzend GB an Daten anfallen, effektiv aufgehoben werden im Moment so ~1-2 TB. Grundsätzlich denke ich, dass man so 5-6TB netto für Nutzer bereitstellen können sollte (Backup muss man auch noch extra regeln...)
- Use-Case: 3-4 User, die gleichzeitig mittelgroße Projekte (~10 Threads) kompilieren (zu diesem Zweck mglw. auch einmal 3-4 CI-VMs) können (dabei Performance wie am Desktop mit 0815-SSD), damit ist dann im wesentlichen vermutlich auch die "Hurra, ich verarbeite Daten-Phase" der selbstentwickelten Software gut abgedeckt (aus dem Teil der Gruppe gibt es leider keine genauen Specs). Parallel dazu sollte es möglich sein, Simulationsergebnisse mit ~300-400MB/s+ aggregiert für 2-3 Clients zu schreiben (oder einzulesen). User-Logins und Log-Files sollten daneben auch noch bedient werden können, mir wäre es am liebsten, auch die Betriebssystemimages auf dem Server liegen zu haben, das dürfte aber jetzt nicht das Performance-Bottleneck sein. /tmp könnte man evtl. auf eine günstige SSD packen im Server packen?!
- Netzwerk: reicht 10GBit?-Ethernet, ansonsten FC oder Infiniband – ich denke, da könnte man dann auch den MPI-Traffic drüber laufen lassen.
- Budget: ich sage einfach <30000€, je größer die Differenz zur oberen Schranke ausfällt, desto besser - jetzt ist zwar recht viel Geld da, aber je nachdem, wie erfolgreich man nach 5-10a war, sollte man immer die Möglichkeit haben, die Hardware auch einmal zu ersetzen. Für einen 20k€-Speicher findet man da schon mal das nötige Kleingeld, für 80-90k€ wird das dann schon deutlich problematischer.

Insgesamt wohl ähnlich zu diesem Thread (@Fr@ddy) hier – wie dort von @konfetti angemerkt, wäre wohl ein modernes, fertiges Hybrid-Storage das Mittel der Wahl, doch was fragt man da an - die Diskussion gleitet irgendwann in das spezifische Ausschreiben von RAID-Controllern ab, was ich persönlich über die gesamte Lebensdauer des ganzen für etwas kritisch halte (dann braucht man einfach an Tag 1 nach mir jemanden, der sich mit dem verwendeten System auskennt. Das ist unwahrscheinlich.)

P.S.: mit dem lokalen RZ habe ich schon gesprochen, da kriegt man deren 40-Kern-Cluster-Standard-Modell im Attended-Housing zum Listenpreis (GPUs verbauen sie nur paarweise Tesla V100@10k€ p. Stück...). Das Storageangebot ist auch nicht optimal (und die Software muss man auch managen, insofern fällt das raus.
P.P.S.: mir geht es wirklich darum, ein paar Bericht aus der Praxis zu bekommen und vllt. ein paar Namen/Dinge, mit denen man feststellen kann, ob das Systemhaus gerade (nicht) die "die dumme Behörde kauft bei uns im Rahmenvertrag"-Masche abzieht... (nicht anders würde ich es bezeichnen, wenn im "Rahmenvertragsshop" ein Standarddesktop mit 1 Jahr Bring-In 70% mehr als auf der Website des OEM kostet....)
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Moin, also ich betreute bei uns den Arbeitskreisinternen HPC Cluster mit, Hauptsächlich für DFT, aber auch CCSD(T) Rechnungen (Chemie).
Bevor du über das Storage nähre Gedanke machst, überlege was du genau brauchst und für wie viele nodes.
Zudem soll viel über (viele) Nodes gerechnet oder max über eine Handvoll.

Bei uns wurde/wird (corona hat das upgrade gestört), das einfach mit zwei HDD (16TB raw) Storage Servern gelöst, wobei einer Aktiv und der zweite als Backup war. Gluster lief auch mal war aber eher mittel und wurde dann abgeschafft.

Denke für kleinere HPC Cluster sind einzelserver besser. Je nach Workload ist dann halt in der Betriebsgröße auch ein SSD-Only möglich.
Micron 5200 in 4TB oder 8TB sind überraschend günstig gewesen und hier ausreichend.


PS. Kannst mir auch gerne ne PM schicken für genaueres.
 
Ich würde da zwei Storage Optionen sehen:

Option1: Es gibt sicher einen Rahmenvertrag für netApp (RZ fragen ) und schauen was es da gibt. Das ist der serviceorientierte Ansatz. Da muss man lediglich schauen ob das Geld reicht und bei Problemen zum Telefon greifen.

Option2: Ein eher technikorientierter preissensitiver Ansatz mit "keep it simple"
und zwar

-Gute Standard Serverhardware von SuperMicro, Dell, HP oder Lenovo nehmen. Die Komplexität reduziert sich erheblich, wenn man auf ZFS und Softwareraid setzt. Da gibt es genug "best of" die meist darauf hinauslaufen, ein Intelsystem mit BroadCom/LSI HBA und einer gut unterstützten Netzwerkkarte zu nehmen, z.B. sowas von der Stange das man auch noch nach Jahren reparieren/ersetzen/aufrüsten kann https://www.supermicro.com/en/products/system/2U/5029/SSG-5029P-E1CTR12L.cfm

Dazu eine Xeon Silver mit möglichst viel Takt und 64-128GB RAM und SAS Platten wie die WD Ultrastar 530SS, https://geizhals.de/?fs=wd+ss530&hloc=de&in= in einem Raid-Z2 (Redundanz wie Raid-6)

Alternativ: normale Datacenter SSD (Intel, Micron), sind etwas günstiger als die elitären (und besonders schnellen WD) oder ein "mixed Pool" aus SAS Festplatten und einem special vdev aus WD SS für performancesensitive Dateisysteme.

Dazu ein zweites identisches System (Backup) mit weniger RAM und normalen WD Ultrastar SAS Festplatten. Backup mit ZFS Replikation (kann beide Systeme bis herunter zu 1 Min syncron halten).


So etwas läuft mit jedem ZFS fähigen Storage optimiertem Betriebssystem
Die komfortabelsten Lösungen haben einfaches Webmanagement.

z.B. Oracle Solaris (Original ZFS) oder mit Open-ZFS:
Illumos (freie Solaris Forks), z.B. OmniOS (made in Schweiz/Uk, https://omniosce.org/) oder Free-BSD oder Linux

neueste ZFS Features gibts unter einem aktuellen Linux oder Illumos/OmniOS.
Free-BSD hingt aktuell ein Jahr hinterher. ZFS Pools sind innerhalb Open-ZFS austauschbar.

Lösungen mit Web-Management
NexentaStor (Illumosbasierte Appliance vom Systemhaus mit zertifizierter Hardware, z.B. zstor.de o.ä.)
Solaris/OmniOS mit meinem napp-it
FreeBSD mit FreeNAS

Linux: aktuell keine vergleichbares Management Tool (CLI Management).
Auch hat man bei Linux bei weitem nicht das "ZFS tut einfach" wie besonders bei Solaris und OmniOS oder in etwas geringerem Umfang Free-BSD.

In jedem Fall ist man mit Standard Server Hardware unabhängig von der Software. Für ein Standard Server OS kann man aber auch Support haben, z.B. Oracle Solaris bis 2034 oder OmniOS. ZFS ist aber extrem hardware unkritisch.
 
Zuletzt bearbeitet:
vielen Dank euch beiden! Ich denke auch, dass es dann tatsächlich ein einfacher Storage-Server wird (zumindest ist das meine bevorzugte Option) - mit Backup sollte dann der*diejenige, der*die die Software pflegen wird auch in der Lage sein, den Basisbetrieb sicherzustellen. Den Vorteil von Gluster/BeeGFS/... sehe ich auch nicht so ganz, im wesentlichen gibt es da halt bessere Bandbreitenskalierung, WENN man viele Server anschafft (oder man kann hässliche Sachen basteln, so wie im Moment.) - bei Budget für zwei bis drei Server ist das glaube ich eher Spielerei. Und heute ist ja so ein SSD-Raid wirklich nicht teuer, d.h. imho sollte man da erstmal die gegebenen Möglichkeiten ausschöpfen.

In so einem ZFS-Setup könnte man quasi einen zweiten Server als Hotspare verwenden. Ist natürlich auch nett, allerdings zwei Server mit SSDs vorhalten ist den Beschaffenden mglw. zu teuer ;) - oder meinst du, dass man auch einen SSD-Storage mit einem HDD-Server syncen kann (und ich glaube für IOPS wären SSDs vom P/L-Verhältnis schon empfehlenswert)

Vllt. schreiben wir das auch als Appliance aus, dann muss ich aber noch sehr genau überlegen, wie man die Anforderung definiert, dass man dann auch ein FreeNAS/...-bekommt (100TB Brutto für 25k€) und kein NetAPP (die ja wohl gerne mal 20TB für 25k€ liefern und ohne Wartung wohl unbenutzbar sein könnten).
 
Also, bei uns soll das werden: Storage A SSD only, Storage B HDD only. Es spricht eigentlich nix dagegen, den HDD wird man ja hoffentlich eh nie brauchen.
Bei uns läuft da einfach ein OpenSUSE, wie auf allen nodes und eigentlich reicht da auch einfach ein NFS share.
Da ist ne apliance meist doch Perlen vor dir Säu.

Wenn ich den Chef doch von ZFS überzeugen kann dann auf ZFS sonst MD-Raid und Rsync.

Man kann auch mal zu Synology oder Qnap schauen, je nachdem wo euer zeug steht. Da ist die Bedienung super easy dann, der sync auch.
 
Ich wuerde davon abraten Seite A mit SSDs und Seite B mit konventionellen HDDs zu bestücken.
Im Falle eines Schwenks faehrt man die HDD Moehre mit großer Warscheinlichkeit an die Wand, dann kann man sie sich auch direkt sparen.
 
Ich wuerde davon abraten Seite A mit SSDs und Seite B mit konventionellen HDDs zu bestücken.
Im Falle eines Schwenks faehrt man die HDD Moehre mit großer Warscheinlichkeit an die Wand, dann kann man sie sich auch direkt sparen.
Das halte ich für Unfug, dem Server ist es doch total egal, ob HDD oder SSD nur halt etwas langsamer. Selbst den umstieg von 1G auf 10G hat man nicht wirklich gemerkt bei uns, was Storage angeht.
Zumal ich fast Denke, man merkt bei bis 5 User nicht mal ob HDD oder SSD, bei nem kleinen (bis 30 nodes) HPC Cluster, solange man keinen Netzwerk Scratch benutzt. Zumindest dem was ich Chemie kenne wird da viel sequenziell geschrieben, das können HDDs und das was gelesen wird, wird ganz ordentlich gecached.

s
 
Du vergleichst in IOPS Welten David gegen Goliath.
Egal ob 1G oder 10G.

Kleines Beispiel: DB Server auf SSDs laeuft an nem GBIT Port.
Nun geht das Ding auf nen HDD Filer, von mir aus auch nen 10GB Port. Je nach Workload ist der Server nun bereits unbenutzbar.

Ich kenne die Anforderungen des TE nicht, wollte lediglich darauf hinweisen dass man hier unter Umständen Geld verbrennt.

Grueße
 
Ich kenne die Anforderungen des TE nicht, wollte lediglich darauf hinweisen dass man hier unter Umständen Geld verbrennt.

Grueße

Dann ist ja gut. Glaube etwas Ahnung zu haben was bei flxmmr laufen könnte, va wenn da grade so ein Gluster-Konstrukt läuft.
Und IOps sind hier nicht so entscheiden wie bei nem DB Server. Teilweise ist Durchsatz auch nicht super wichtig, aber das hängt halt doch alles von der Software ab was wichtiger ist.

Wichtiger sind hier meist die Nodes an sich was die können, Storage sollte einfach gehen und nicht zu sehr eine Krücke sein.
Bei vielen Nodes und vielen usersn oder sehr großen Datenmengen sieht die welt anders aus.

Uni ist glaube ich eh was spezielles, da gibts teilweise sehr komische Entscheidungen, aus noch seltsameren Gründen und gewachsene Strukturen sowieso. Das ist aber ein ganz anderes Thema.
 
Zuletzt bearbeitet:
Ich wuerde davon abraten Seite A mit SSDs und Seite B mit konventionellen HDDs zu bestücken.
Im Falle eines Schwenks faehrt man die HDD Moehre mit großer Warscheinlichkeit an die Wand, dann kann man sie sich auch direkt sparen.
Ähm, es geht wirklich nur darum, dass - sollte A ausfallen - B noch halbwegs aktuell da ist (Backup - wenn minutengenau, warum nicht) UND der, der gerade eben noch eine wichtige Deadline hat, weiterarbeiten kann. Für die Mehrheit der Nutzertage dürfte ein Ausfall im Tagebereich verkraftbar sein.

Wichtiger sind hier meist die Nodes an sich was die können, Storage sollte einfach gehen und nicht zu sehr eine Krücke sein.
Bei vielen Nodes und vielen usersn oder sehr großen Datenmengen sieht die welt anders aus.
So ist es, und die jetzige Lösung ist eine Krücke :fresse:.
 
So, nochmal vielen Dank für Eure Anregungen, wir haben mittlerweile (hat doch eine Zeit gedauert und dann jetzt noch 2 Monate Lieferzeit...) ein ZFS-NAS für NFS mit Micron9300 gekauft und lassen das ganze über das MPI-Netz (mit 40/56GBit/s) laufen. Funktioniert zwar mit Debian-Buster (kein RDMA, weil Bug und kein nconnect weil alter Kernel) nicht optimal, schlägt aber in fio-Benchmarkskripten, die man so findet das bisherige lokale HDD-RAID um den Faktor 5-10 und die lokalen, als "scratch" dienenden SATA-SSDs auch um 20-30%. Ich denke, das reicht für unsere Zwecke und ist auch von der Konfiguration her sehr überschaubar und wartbar. Werde dann im ZFS-Thread nochmal nach Config-Tips fragen.
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh