Liste und kurze Beschreibung der Auswahlkriterien
Folgende techn. Mindestanforderungen (Muss-Kriterien) sind zu erbringen / nachzuweisen: Es muss sich um ein Lustre basiertes All-Flash Storagesystem mit NVME Speicher für die Kapazität von mindestens 1.3 PB1 (netto, d.h. für die Benutzermuss mit unkomprimier-baren/zufälligen Daten dieses Volumen stets verfügbar sein) und einer nutzbaren Bandbreite von min. 100 GB/s handeln. Über den gesamten Supportzeitraum müssen aktuell gepflegte RHEL-Kernel verwendbar sein.Das System muss sich flexibel in HPC-Systeme der GWDG integrieren lassen.
Die Abnahme wird mit dem NHR-Cluster „Emmy“ der GWDG durchgeführt und das System soll sich zusätzlich flexibel in ein neues noch zu beschaffendes Cluster integrieren lassen. Daher sind die Systeme einerseits für eine Anbindung an die bestehende 100 Gbit/s Omni-Path Fabric auszustatten und müssen andererseits auch für die Verbindung an andere Netzwerktypen, z.B. 200 Gbit/s RoCE, InfiniBand NDR oder zukünftige Omni-Path Generationen umrüstbar sein. Die Preise für eine eventuell erforderliche Umrüstung auf 200 Gbit/s RoCE oder InfiniBand NDR sind in der Preisliste für die Nachkaufoption (s. Abschnitt 2.3) auszuweisen und dem Angebot beizulegen. Für eine OPA 400 Umrüstung ist eine Preisindikation wünschenswert.Ein Performance Monitoring auf Client- und Benutzerebene muss getrennt nach Metadaten und Nutzdaten (IOPs und Bandbreite) verfügbar sein.
Ein Hochverfügbarkeitslösung mittels automatischem Active-Passive Failover muss verfügbar sein.Die Performance und Kapazität soll sich bei Bedarf skalierbar erweitern lassen, wenigstens um Faktor 5 für Kapazität und Performance.Die Datenablage muss entsprechend den Anforderungen der Benutzer individuell auf Verzeichnisebene konfigurierbar sein (Striping von Nutz- und Metadaten, Chunkgröße).Die Konzepte für die oben aufgeführten Anforderungen sind dem Angebot beizufügen.
Die erweiterte Version des IO500 Benchmarks3 (Branch: phase-concurrent) ist zu kompilieren. Grundsätzlich ist der Benchmark entsprechend der IO500 Richtlinien 4 auszuführen. Folgende Regeln sind darüber hinaus zu verwenden:Die zu verwendende Version ist der phase-concurrent branch anstelle der letzten offiziellen Version. Es ist ausschließlich die POSIX Schnittstelle zu nutzen. Es ist das Argument --mode=extended zu verwenden
In der INI-Datei muss als dataPacketType Random verwendet werden, d.h. die Datei sollte wenigstens enthalten: [global]dataPacketType = random.Der Benchmark ist mit 10 Client-Knoten und 16 Prozessen pro Knoten auszuführen.Die Schreibphasen des Benchmarks müssen min. 5 Min. dauern (stonewalltime=300, damit die Resultate gültig sind. Bei Bedarf sind hierzu die Parameter,die die geschriebene Datenmenge steuern, anzupassen. Für die mdtest Varianten sind dies die Anzahl der Dateien n, für den ior-easy die blockSize und für die anderen ior Varianten der segmentCount.
Folgende techn. Anforderungen (Kann-Kriterien) sind bestmöglich zu erbringen / nachzuweisen:
Nutzbare Speicherkapazität Das Angebot mit der höchsten nutzbaren physikalischen Speicherkapazität (also ohne Verwendung von Datenkompression oder -deduplikation) wird mit der Leistungskennzahl LCap = 1 bewertet, alle weiteren Angebote proportional zur nutzbaren Kapazität mit LCap < 1.
Anwendungsbenchmarks – Leistungszusage
Die Leistungszusagen müssen für OPA 100G gelten, für RoCE und Infiniband muss mindestens die gleiche Performance erzielt werden können.
Anwendungsbenchmarks – IO500
Die erweiterte Version des IO500 Benchmarks (Branch: phase-concurrent) ist auf 10 Knoten (für die Abnahme in der Produktivumgebung ausgestattet mit 1x OPA100G und 2x 48 Cores Cascade Lake) zu verwenden und die dort zu erwartende Gesamtleistung (Ausgabe: ScoreX) als Leistungszusage für PIO500 anzugeben. Das Angebot mit der höchsten Performance Pmax
IO500 für den entsprechend der Beschreibung durchzuführenden Benchmark wird mit der Leistungskennzahl LIO500 = 1 bewertet. Alle weiteren Angebote werden proportional zur Leistungszusage PIO500 bewertet.
Anwendungsbenchmarks – IOR
Das Angebot mit der höchsten zugesagten Streamingbandbreite in GiB/s PmaxIOR für den entsprechend der Beschreibung durchzuführenden Benchmark wird mit der Leistungskennzahl LIOR = 1 bewertet. Alle weiteren Angebote werden proportional zur Leistungszusage PIOR bewertet.
Anwendungsbenchmarks – MD-Workbench
Das Angebot mit der höchsten zugesagten Anzahl an Metadatenoperation pro Sekunde Pmax
MDWB für den entsprechend der Beschreibung durchzuführenden Benchmark wird mit der Leistungskennzahl LMDWB = 1 bewertet. Alle weiteren Angebote werden proportional zur Leistungszusage PMDWB bewertet.
Liefertermin
Positiv bewertet werden ein möglichst früher Liefertermin, eine möglichst vollständige
Lieferung zu diesem Termin und zeitnahe Nachlieferungen eventuell nicht zu diesem Termin lieferbarer Komponenten. Zusätzlich wird die Aufbau und Inbetriebnahmezeit bis zur Abnahme bewertet. Ein vollständiger Zeitplan vom Beginn der Lieferungen bis zur Abnahme ist dem Angebot beizufügen.
Die Bewertung erfolgt auf einer Skala von 1 bis 100 Punkten im Vergleich zu allen zulässigen Angeboten der anderen Anbieter. Die mit 0,01 skalierte Punktzahl definiert die Leistungskennzahl LService dieses Leistungskriteriums.
Preis für die Wartungsverlängerung (WK)
Das Angebot mit dem günstigsten angebotenen Preis WV min für die Wartungsverlängerung
für die Jahre 6 und 7 wird mit der Leistungskennzahl LWV = 1 bewertet. Alle weiteren Angebote werden antiproportional zum PreisWV bewertet:
Supportkonzept
Dem Angebot ist eine ausführliche Darstellung der mit dem System verbundenen Service-Leistungen beizufügen. Für die Bewertung von Bedeutung ist insbesondere die Abwicklung von Support-Anfragen, eventuell dem Projekt zugeteilte, feste Ansprechpartner und vor Ort bereitgestellte Ersatz-Hardware. Insbesondere ist auch die Umsetzung des und die Erfahrung mit dem Lustre-Support darzustellen.