[Kaufberatung] Serveraufbau mit ECC-Speicher für Multimedia & Softwareentwicklung
- Ersteller Scyce
- Erstellt am
Scyce
Neuling
Auch hier durfte ich noch ewas dazu lernen..
Ein 9400-HBA hat normalerweise PCIe 3.0 x8 (~7,9 GB/s). In meinem Board läuft er nur mit x4, also ~3,9 GB/s netto.
12 HDDs (7.2k) schaffen realistisch 150–250 MB/s → zusammen max. ~3,0 GB/s sequentiell. Damit bleibt selbst im Worst Case noch Reserve – der PCIe-x4-Slot limitiert die HDDs also praktisch nicht.
Die Anzahl der Lanes ist dabei egal, es wirkt sich nur auf die maximale Geschwindigkeit aus – die Lane-Breite wird beim Link-Training automatisch zwischen HBA und Mainboard ausgehandelt. 👍
Danke nochmal für die Liste.https://geizhals.at/micron-7450-max...t6tfs-1bc1zabyy-a2757794.html?hloc=at&hloc=de sowas?
Festplatten & SSDs Solid State Drives (SSD) Preisvergleich Geizhals Österreich
Preisvergleich für Festplatten & SSDs Solid State Drives (SSD) ✓ Bewertungen ✓ Produktinfos ⇒ Auswahl und Filtern der Produkte nach den besten Eigenschaften und dem billigsten Preisgeizhals.at
Vllt. ist das übertrieben und ne "ordentliche" Read Intensive tuts auch (hat dann immerhin auch 10x so viel TBW wie diese billig-Crucial)...
Mit ner Crucial P310 SSD 2TB (QLC, 220 TBW pro TB) brauchst da imho nicht ankommen, wenn da Proxmox auf ZFS läuft mit 50 Dockern und 2 VMs...
Hier würde ich mich für eine Kingston FURY Renegade SSD 2TB, M.2 2280 / M-Key / PCIe 4.0 x4 oder Seagate FireCuda 530R SSD +Rescue 2TB, M.2 2280 / M-Key / PCIe 4.0 x4 entscheiden. Einzig und alleine wegen dem hohen TBW. Cache haben sie beide.
Hier meine vorläufige Konfiguration
| # | Schnittstelle | Verwendung | 12 Festplatten – Belegung |
|---|---|---|---|
| 1 | PCIe 3.0 x1 | Management | ASUS IPMI Erweiterungskarte (AST2600A3) |
| 2 | PCIe 5.0 x16 | GPU | Reserviert für Grafikkarte |
| 3 | PCIe 5.0 x8 | frei | Frei bei x8 Betrieb der Grafikkarte |
| 4 | PCIe 3.0 x16 (x4 Modus) | Backplane Anbindung | Lenovo 430-16i (LSI 9400-16i) |
| 5 | PCIe 3.0 x16 (x4 Modus) | OS – Optane (Proxmox + 2× Docker Hosts) | Anbindung: 10Gtek U.2 SFF-8639 auf PCIe Adapter, PCIe 3.0 x4 SSD: Intel Optane DC P4800X 750 GB (U.2) |
| 6 | SlimSAS PCIe 4.0 | OS – Optane (Proxmox + 2× Docker Hosts) | Anbindung: InLine® Slim SAS Kabel, SFF-8654 4i → U.2 SFF-8639 + SATA Strom, 24Gb/s, 0,5m SSD: Intel Optane DC P4800X 750 GB (U.2) |
| 7 | M.2 PCIe 4.0 x4 | VMs (Windows- und Linux-VMs) | Option A: Kingston FURY Renegade SSD 2TB Option B: Seagate FireCuda 530R SSD +Rescue 2TB |
| 8 | M.2 PCIe 4.0 x4 | VMs (Windows- und Linux-VMs) | Option A: Kingston FURY Renegade SSD 2TB Option B: Seagate FireCuda 530R SSD +Rescue 2TB |
| 9 | M.2 PCIe 4.0 x4 | Reserve | Reserve / optional zusätzliche 2TB SSD |
| 10 | SATA 3.0 | frei | frei |
| 11 | SATA 3.0 | frei | frei |
| 12 | SATA 3.0 | frei | frei |
| 13 | SATA 3.0 | frei | frei |
Zuletzt bearbeitet:
Scyce
Neuling
Ja das Board habe ich schon vor mir liegen und die Karte ist ebenfalls mit dabei.
Scyce
Neuling
Ich melde mich zurück 
Leider hat mich der CPU Kühler geärgert, denn er war zu groß.. ich hatte vergessen die Einbauhöhe des Mainboards zu berücksichtigen..
Als Ersatz kam der Noctua NH-C14S zum Einsatz. Erpasst im Low-Profile-Mode super rein. 15mm Platz zu den RAMs und nach oben gut 30mm Luft bis zum Deckel.
Ich konnte außerdem noch eine NVIDIA QuADro K4200 vor dem Verwerter retten. Diese hab ich mal mit reingepackt. Wird sicher spannend für mich zu sehen wie sich diese im Vergleich zur iGPU schlägt.
Ich hatte zu Beginn noch Probleme die 2te Optane via SlimSAS zu konfigurieren. Das Mainboard wollte trotz PCIe Mode diese nicht erkennen. Nachdem ich die internen SATA Anschlüsse deaktiviert hatte ging es.. ich hatte mehrere Dinge probiert und dies müste (Gedankenprotokoll, es war spät Nachts), der ausschlaggebene Haken gewesen sein.
BIOS hatte ich vorher noch auf die aktuellste Version hochgezogen und im Anschluss noch die Firmware des HBA aktualisiert (https://gist.github.com/buswedg/f94a7978b07c1976e81e6d456ec37853). Größte Herausforderung für mich war an der Stelle, einen EFI Boot Stick mit FAT32 zu erstellen. Das hatte ich bis dato noch nie machen müssen
Als es an die Installation von Proxmox ging, wollte das BIOS einfach den Stick nicht booten und hatte mich immer mit folgender Fehlermeldung (gekürzt) stehen gelassen: GPT Header corrupt when installing
Ursächlich hierführ war wohl, dass die NVMes schon vorher erkannt wurden und dort der Bootsektor korrupt war(?). Man hätte wohl versuchen können die NVMes auszubauen, aber das wollte ich nicht. Es gab im BIOS eine versteckte (3-4 Ebene) Funktion, bei corrupten GPT Bootsektoren diese automatisch Wiederherzustellen. Siehe da, Problem gelöst und der Installer konnte starten.
Für die Proxmox Installation habe ich die 750GB SSDs als RAIDz Mirror konfiguiert und die Größe auf 50GB (rpool) festgelegt. Die restlichen 700GB (vmdocker) habe ich ebenfalls als RAIDz Mirror angelegt.
Die beiden 2TB SSDs (vmwork) sind ebenfalls als RAIDz Mirror konfiguiert.
Anschließend habe ich ein paar Benchmark Tests durchgeführt. Vielleicht kann der eine oder andere diese bitte Bewerten.
Während den Tests ist die CPU Auslastung auf maximal 18-26% hin und her gesprungen und die Temperatur der einzelnen Kerne hat die 55°C nicht überschritten
NVMe1: 55°C mit Kühler
NVMe2: 80°C (!!) ohne Kühler. Hier habe ich bereits einen Kühler MC1 PRO von be quiet! bestellt.
Ergebnis:
Ergebnis:
Ergebnis:
Ergebnis:
Während den Tests ist die CPU Auslastung auf maximal 13-19% hin und her gesprungen und die Temperatur der einzelnen Kerne hat die 48°C nicht überschritten
Optane1: 45°C in PCIe Karte
Optane2: 53°C unter Gehäuse am Netzteil.
Zu Erwähnen ist hier, dass die Temperatur konstant bleibt. Also sowohl im Idle als auch unter Vollast schwankt diese um wenige °C und ist weitestegehend konstant auf 50-53°C
Ergebnis:
Ergebnis:
Ergebnis:
Ergebnis:
Nachfolg zur Referenz die Synology inkl. aktivem SSD Cache
fio --name=vol3_seq_read --filename=/volume3/fio_testfile --rw=read --bs=128k --ioengine=libaio --iodepth=32 --numjobs=4 --runtime=60 --size=8G --direct=1 --time_based --group_reporting
Ergebnis:
fio --name=vol3_seq_write --filename=/volume3/fio_testfile --rw=write --bs=128k --ioengine=libaio --iodepth=32 --numjobs=4 --size=8G --runtime=60 --direct=1 --time_based --group_reporting
Ergebnis:
fio --name=vol3_rand_rw --filename=/volume3/fio_testfile --rw=randrw --rwmixread=70 --bs=4k --ioengine=libaio --iodepth=32 --numjobs=8 --size=8G --runtime=60 --direct=1 --time_based --group_reporting
Ergebnis:
fio --name=vol3_raw_read --filename=/volume3/fio_testfile --rw=read --bs=128k --ioengine=libaio --iodepth=32 --numjobs=1 --runtime=30 --direct=1 --time_based --group_reporting
Ergebnis:
Da ich mich noch nicht so tief in Proxmox eingelesen habe und den Thread hier auch dafür nicht missbrauchen möchte, dennoch eine kurze Frage. Die Konfiuration/Aufteilung ist soweit in Ordnung?
ISOs (eine wurde Testweise auf rpool geladen), könnte man ja auch auf ein anderen Pool auslagern. Wenn ich die 12TB HDDs umziehe, bin ich aktuell noch nicht ganz schlüssig ob es Sinn macht einen (z.B.) TrueNAS Container laufen zu lassen, der mir die Laufwerke z.B. per NFS Share bereitstellt oder wie ich das am besten Bewerkstellige, dass ich meinen Speicher den anderen Container/VM bereitstelle.
Außerdem gibt es hier auch noch die Anforderung einen Teil zu verschlüsseln und nur wenn dieser Teil/Ordner entschlüsselt ist, darf der Container vm-docker-encryption laufen und versuchen seine Dienste bereit zu stellen.
Bin offen für Tipps und Lektüre.
Leider hat mich der CPU Kühler geärgert, denn er war zu groß.. ich hatte vergessen die Einbauhöhe des Mainboards zu berücksichtigen..
Als Ersatz kam der Noctua NH-C14S zum Einsatz. Erpasst im Low-Profile-Mode super rein. 15mm Platz zu den RAMs und nach oben gut 30mm Luft bis zum Deckel.
Ich konnte außerdem noch eine NVIDIA QuADro K4200 vor dem Verwerter retten. Diese hab ich mal mit reingepackt. Wird sicher spannend für mich zu sehen wie sich diese im Vergleich zur iGPU schlägt.
Ich hatte zu Beginn noch Probleme die 2te Optane via SlimSAS zu konfigurieren. Das Mainboard wollte trotz PCIe Mode diese nicht erkennen. Nachdem ich die internen SATA Anschlüsse deaktiviert hatte ging es.. ich hatte mehrere Dinge probiert und dies müste (Gedankenprotokoll, es war spät Nachts), der ausschlaggebene Haken gewesen sein.
BIOS hatte ich vorher noch auf die aktuellste Version hochgezogen und im Anschluss noch die Firmware des HBA aktualisiert (https://gist.github.com/buswedg/f94a7978b07c1976e81e6d456ec37853). Größte Herausforderung für mich war an der Stelle, einen EFI Boot Stick mit FAT32 zu erstellen. Das hatte ich bis dato noch nie machen müssen
Als es an die Installation von Proxmox ging, wollte das BIOS einfach den Stick nicht booten und hatte mich immer mit folgender Fehlermeldung (gekürzt) stehen gelassen: GPT Header corrupt when installing
Ursächlich hierführ war wohl, dass die NVMes schon vorher erkannt wurden und dort der Bootsektor korrupt war(?). Man hätte wohl versuchen können die NVMes auszubauen, aber das wollte ich nicht. Es gab im BIOS eine versteckte (3-4 Ebene) Funktion, bei corrupten GPT Bootsektoren diese automatisch Wiederherzustellen. Siehe da, Problem gelöst und der Installer konnte starten.
Für die Proxmox Installation habe ich die 750GB SSDs als RAIDz Mirror konfiguiert und die Größe auf 50GB (rpool) festgelegt. Die restlichen 700GB (vmdocker) habe ich ebenfalls als RAIDz Mirror angelegt.
Die beiden 2TB SSDs (vmwork) sind ebenfalls als RAIDz Mirror konfiguiert.
Anschließend habe ich ein paar Benchmark Tests durchgeführt. Vielleicht kann der eine oder andere diese bitte Bewerten.
Während den Tests ist die CPU Auslastung auf maximal 18-26% hin und her gesprungen und die Temperatur der einzelnen Kerne hat die 55°C nicht überschritten
NVMe1: 55°C mit Kühler
NVMe2: 80°C (!!) ohne Kühler. Hier habe ich bereits einen Kühler MC1 PRO von be quiet! bestellt.
1️⃣ Sequentieller Lese-Test (ZFS Pool)
Kommando:
Bash:
fio --name=zfs_seq_read --filename=/vmwork/fio_testfile --rw=read --bs=128k --ioengine=libaio --iodepth=32 --numjobs=4 --runtime=60 --direct=1 --time_based --group_reportingErgebnis:
Code:
READ: bw=2667MiB/s (2796MB/s), IOPS=21.3k, io=156GiB, run=60001msec
lat (avg): 6.0ms, cpu: usr=0.37%, sys=7.30%2️⃣ Sequentieller Schreib-Test (ZFS Pool)
Kommando:
Bash:
fio --name=zfs_seq_write --filename=/vmwork/fio_testfile --rw=write --bs=128k --ioengine=libaio --iodepth=32 --numjobs=4 --size=8G --runtime=60 --direct=1 --time_based --group_reportingErgebnis:
Code:
WRITE: bw=2050MiB/s (2149MB/s), IOPS=16.4k, io=120GiB, run=60002msec
lat (avg): 7.8ms, cpu: usr=1.41%, sys=64.90%3️⃣ Random 4 K Read/Write (70 / 30 Mix, ZFS Pool)
Kommando:
Bash:
fio --name=zfs_rand_rw --filename=/vmwork/fio_testfile --rw=randrw --rwmixread=70 --bs=4k --ioengine=libaio --iodepth=32 --numjobs=8 --size=8G --runtime=60 --direct=1 --time_based --group_reportingErgebnis:
Code:
READ: IOPS=25.5k, BW=99.4MiB/s (104MB/s), io=5966MiB
WRITE: IOPS=10.9k, BW=42.6MiB/s (44.7MB/s), io=2559MiB
avg latency: 7.0ms, cpu: usr=0.63%, sys=10.32%4️⃣ Sequentieller Lese-Test (Raw Device)
Kommando:
Bash:
fio --name=raw_seq_read --filename=/dev/nvme0n1p1 --rw=read --bs=128k --ioengine=libaio --iodepth=32 --numjobs=1 --runtime=30 --direct=1 --time_based --group_reportingErgebnis:
Code:
READ: bw=6864MiB/s (7198MB/s), IOPS=54.9k, io=201GiB, run=30001msec
lat (avg): 0.58ms, cpu: usr=1.76%, sys=32.10%Zusammenfassung der Messungen
| Testname | Szenario | Blockgröße | Jobs | Read/Write | Bandbreite | IOPS | Latenz (Ø) |
|---|---|---|---|---|---|---|---|
| zfs_seq_read | ZFS sequentiell lesen | 128 K | 4 | Read | 2667 MiB/s | 21.3 k | 6.0 ms |
| zfs_seq_write | ZFS sequentiell schreiben | 128 K | 4 | Write | 2050 MiB/s | 16.4 k | 7.8 ms |
| zfs_rand_rw | ZFS Random 4 K 70/30 Mix | 4 K | 8 | 70 / 30 | 142 MiB/s | 36.4 k | 7.0 ms |
| raw_seq_read | Direktes NVMe Device | 128 K | 1 | Read | 6864 MiB/s | 54.9 k | 0.58 ms |
Während den Tests ist die CPU Auslastung auf maximal 13-19% hin und her gesprungen und die Temperatur der einzelnen Kerne hat die 48°C nicht überschritten
Optane1: 45°C in PCIe Karte
Optane2: 53°C unter Gehäuse am Netzteil.
Zu Erwähnen ist hier, dass die Temperatur konstant bleibt. Also sowohl im Idle als auch unter Vollast schwankt diese um wenige °C und ist weitestegehend konstant auf 50-53°C
1️⃣ Sequentieller Lese-Test (ZFS Pool)
Kommando:
Bash:
fio --name=zfs_seq_read --filename=/vmdocker/fio_testfile --rw=read --bs=128k --ioengine=libaio --iodepth=32 --numjobs=4 --runtime=60 --direct=1 --time_based --group_reportingErgebnis:
Code:
READ: bw=4943MiB/s (5183MB/s), IOPS=39.5k, io=290GiB, run=60001msec
lat (avg): 3.2ms, cpu: usr=0.74%, sys=15.43%2️⃣ Sequentieller Schreib-Test (ZFS Pool)
Kommando:
Bash:
fio --name=zfs_seq_write --filename=/vmdocker/fio_testfile --rw=write --bs=128k --ioengine=libaio --iodepth=32 --numjobs=4 --size=8G --runtime=60 --direct=1 --time_based --group_reportingErgebnis:
Code:
WRITE: bw=1821MiB/s (1909MB/s), IOPS=14.6k, io=107GiB, run=60001msec
lat (avg): 8.8ms, cpu: usr=1.24%, sys=57.47%3️⃣ Random 4 K Read/Write (70 / 30 Mix, ZFS Pool)
Kommando:
Bash:
fio --name=zfs_rand_rw --filename=/vmdocker/fio_testfile --rw=randrw --rwmixread=70 --bs=4k --ioengine=libaio --iodepth=32 --numjobs=8 --size=8G --runtime=60 --direct=1 --time_based --group_reportingErgebnis:
Code:
READ: IOPS=20.2k, BW=78.7MiB/s (82.5MB/s), io=4724MiB
WRITE: IOPS=8.6k, BW=33.7MiB/s (35.4MB/s), io=2025MiB
avg latency: 8.9ms, cpu: usr=0.45%, sys=7.8%4️⃣ Sequentieller Lese-Test (Raw Device)
Kommando:
Bash:
fio --name=raw_seq_read --filename=/dev/nvme1n1 --rw=read --bs=128k --ioengine=libaio --iodepth=32 --numjobs=1 --runtime=30 --direct=1 --time_based --group_reportingErgebnis:
Code:
READ: bw=2558MiB/s (2682MB/s), IOPS=20.5k, io=74.9GiB, run=30002msec
lat (avg): 1.56ms, cpu: usr=0.78%, sys=14.45%Zusammenfassung der Messungen
| Testname | Szenario | Blockgröße | Jobs | Read/Write | Bandbreite | IOPS | Latenz (Ø) |
|---|---|---|---|---|---|---|---|
| zfs_seq_read | ZFS sequentiell lesen | 128 K | 4 | Read | 4943 MiB/s | 39.5 k | 3.2 ms |
| zfs_seq_write | ZFS sequentiell schreiben | 128 K | 4 | Write | 1821 MiB/s | 14.6 k | 8.8 ms |
| zfs_rand_rw | ZFS Random 4 K 70/30 Mix | 4 K | 8 | 70 / 30 | 113 MiB/s | 28.9 k | 8.9 ms |
| raw_seq_read | Direktes NVMe Device | 128 K | 1 | Read | 2558 MiB/s | 20.5 k | 1.56 ms |
Nachfolg zur Referenz die Synology inkl. aktivem SSD Cache
🔹 1. Sequentieller Lese-Test
Command:fio --name=vol3_seq_read --filename=/volume3/fio_testfile --rw=read --bs=128k --ioengine=libaio --iodepth=32 --numjobs=4 --runtime=60 --size=8G --direct=1 --time_based --group_reporting
Ergebnis:
- Bandbreite: 413 MB/s
- IOPS: 3.224
- Durchschnittliche Latenz: 39,6 ms
- CPU-Last: 0.45 % usr / 9.77 % sys
🔹 2. Sequentieller Schreib-Test
Command:fio --name=vol3_seq_write --filename=/volume3/fio_testfile --rw=write --bs=128k --ioengine=libaio --iodepth=32 --numjobs=4 --size=8G --runtime=60 --direct=1 --time_based --group_reporting
Ergebnis:
- Bandbreite: 128 MB/s
- IOPS: 1.004
- Durchschnittliche Latenz: 127 ms
- CPU-Last: 1.09 % usr / 4.73 % sys
🔹 3. Random Read/Write Test (70 % Lesen / 30 % Schreiben)
Command:fio --name=vol3_rand_rw --filename=/volume3/fio_testfile --rw=randrw --rwmixread=70 --bs=4k --ioengine=libaio --iodepth=32 --numjobs=8 --size=8G --runtime=60 --direct=1 --time_based --group_reporting
Ergebnis:
- Read: 6.1 MB/s (~1.500 IOPS)
- Write: 2.6 MB/s (~650 IOPS)
- Latenz: Read ~132 ms / Write ~84 ms
- CPU-Last: 0.3 % usr / 2.15 % sys
🔹 4. Reiner Lese-Test (1 Job, 128 kB)
Command:fio --name=vol3_raw_read --filename=/volume3/fio_testfile --rw=read --bs=128k --ioengine=libaio --iodepth=32 --numjobs=1 --runtime=30 --direct=1 --time_based --group_reporting
Ergebnis:
- Bandbreite: 260 MB/s
- IOPS: 2.028
- Durchschnittliche Latenz: 15,7 ms
- CPU-Last: 1.92 % usr / 35.5 % sys
Zusammenfassung
| Testtyp | Blockgröße | Threads | Dauer | Modus | Durchsatz | IOPS | Latenz |
|---|---|---|---|---|---|---|---|
| Sequentiell Lesen | 128 kB | 4 | 60 s | Volume3 | 413 MB/s | 3.224 | 39.6 ms |
| Sequentiell Schreiben | 128 kB | 4 | 60 s | Volume3 | 128 MB/s | 1.004 | 127 ms |
| Random RW (70/30) | 4 kB | 8 | 60 s | Volume3 | 6.1 / 2.6 MB/s | 1.519 / 652 | 132 / 84 ms |
| Raw Read | 128 kB | 1 | 30 s | Volume3 | 260 MB/s | 2.028 | 15.7 ms |
Da ich mich noch nicht so tief in Proxmox eingelesen habe und den Thread hier auch dafür nicht missbrauchen möchte, dennoch eine kurze Frage. Die Konfiuration/Aufteilung ist soweit in Ordnung?
ISOs (eine wurde Testweise auf rpool geladen), könnte man ja auch auf ein anderen Pool auslagern. Wenn ich die 12TB HDDs umziehe, bin ich aktuell noch nicht ganz schlüssig ob es Sinn macht einen (z.B.) TrueNAS Container laufen zu lassen, der mir die Laufwerke z.B. per NFS Share bereitstellt oder wie ich das am besten Bewerkstellige, dass ich meinen Speicher den anderen Container/VM bereitstelle.
Außerdem gibt es hier auch noch die Anforderung einen Teil zu verschlüsseln und nur wenn dieser Teil/Ordner entschlüsselt ist, darf der Container vm-docker-encryption laufen und versuchen seine Dienste bereit zu stellen.
Bin offen für Tipps und Lektüre.
Anhänge
Zuletzt bearbeitet:
generell
- Storage in einer VM und Zugriff via iSCSI,NFS oder SMB über ip ist langsamer als Zugriff einer VM in Proxmox auf lokales ZFS und zvol -
schneller ist daher NAS und ZFS direkt in Proxmox
- ZFS web-guis mit share und acl Verwaltung gibts auch direkt für Proxmox (Cockpit, Poolsman, napp-it cs)
- schnellstes SMB für Linux ist ksmbd, eine Option für Proxmox
- Für VM Storage sollte man sync aktivieren um Gast-Dateisysteme zu schützen.
Encryption + sync ist aber richtig langsam, sollte man vermeiden
- Storage in einer VM und Zugriff via iSCSI,NFS oder SMB über ip ist langsamer als Zugriff einer VM in Proxmox auf lokales ZFS und zvol -
schneller ist daher NAS und ZFS direkt in Proxmox
- ZFS web-guis mit share und acl Verwaltung gibts auch direkt für Proxmox (Cockpit, Poolsman, napp-it cs)
- schnellstes SMB für Linux ist ksmbd, eine Option für Proxmox
- Für VM Storage sollte man sync aktivieren um Gast-Dateisysteme zu schützen.
Encryption + sync ist aber richtig langsam, sollte man vermeiden
Ähnliche Themen
