Den idealen Proxmox-Host gibt es natürlich nicht. Ein Rechner, der in einer Studentenbude neben dem Bett steht und zwei LXCs betreibt, hat andere Anforderungen als ein Server mit mehreren virtuellen Maschinen, acht Festplatten, 10-GBit-Ethernet und vielleicht noch einer GPU. Trotzdem gibt es einige Punkte, die man bereits vor dem Kauf bedenken sollte. Insbesondere sollte man nicht den kleinsten Rechner kaufen, der die heutigen Anforderungen gerade noch erfüllt, sondern überlegen, welche Anforderungen in einigen Jahren bestehen könnten. CPU-Leistung ist dabei erstaunlich selten das eigentliche Problem. RAM, Storage und fehlende Erweiterungsmöglichkeiten werden bei einem Virtualisierungshost meistens wesentlich früher knapp. Der wichtigste Punkt wird häufig erst ganz am Ende betrachtet: Wie viel Storage soll der Rechner irgendwann aufnehmen? Eine oder zwei SSDs bekommt man praktisch überall unter. Bei mehreren 3.5"-Festplatten sieht das anders aus. Dann benötigt man nicht nur die entsprechenden Einbauplätze, sondern auch SATA-Anschlüsse, Stromversorgung und vor allem einen vernünftigen Luftstrom durch die Laufwerke. Wer irgendwann sechs oder acht Festplatten einsetzen möchte, sollte deshalb auch ein Gehäuse kaufen, in das sechs oder acht Festplatten passen. Das klingt trivial, wird aber erstaunlich oft anders gemacht. Ein zunächst sehr kleiner und billiger Rechner ist kein Gewinn, wenn später USB-Gehäuse, externe Netzteile oder gleich ein zweiter Rechner danebenstehen müssen. Ein größeres Gehäuse hat darüber hinaus weitere Vorteile: Normale PCIe-Steckplätze, große Lüfter und Standardnetzteile machen das System wesentlich leichter erweiterbar und reparierbar. Mini-PCs haben zweifellos ihre Berechtigung. Sie sind klein, meist relativ leise und mit CPUs wie einem Intel N100 für viele Aufgaben erstaunlich leistungsfähig. Wenn man nur einige Container oder wenige kleine virtuelle Maschinen betreiben möchte, keinen großen lokalen Storage benötigt und der Rechner möglichst wenig Platz beanspruchen soll, kann ein Mini-PC genau die richtige Lösung sein. Man sollte allerdings wissen, welche Nachteile man sich mit der geringen Baugröße einhandelt.

• Fehlende Erweiterungsmöglichkeiten
  Bei vielen Mini-PCs kann man RAM und eine oder zwei SSDs einbauen. Danach ist Schluss. PCIe-Steckplätze für zusätzliche Netzwerkkarten, HBAs, zusätzliche SATA- oder NVMe-Controller oder eine GPU fehlen meistens vollständig. Auch der maximale RAM-Ausbau ist teilweise erheblich eingeschränkt. 16 GByte sind bei manchen Geräten bereits das Maximum, 32 GByte bei anderen.
  
  Für ein paar LXCs reicht das problemlos. Bei mehreren vollständigen virtuellen Maschinen ist man damit aber sehr schnell am Ende. Damit ist ein Mini-PC im Wesentlichen bereits beim Kauf fertig konfiguriert. Das ist kein Problem, wenn die vorhandene Ausstattung auf Dauer genügt. Man sollte sich dessen nur vorher bewusst sein.
• Qualität der Komponenten
  Bei einem Barebone kann man RAM und SSD wenigstens selbst auswählen. Bei fertig bestückten Billigsystemen unbekannter Hersteller wird dagegen gern an Komponenten gespart, die auf dem Datenblatt nicht besonders auffallen: Netzteil, SSD, RAM, Spannungsversorgung und Lüfter.
  
  Gerade bei einem Rechner, der 24 Stunden am Tag laufen soll, sind dies aber keine unwichtigen Bauteile. Eine SSD mit unbekannter Herkunft, ein Netzteil mit schlechtem Wirkungsgrad oder ein Lüfter, für den es nach drei Jahren keinen Ersatz mehr gibt, können wesentlich lästiger werden als fünf Prozent weniger CPU-Leistung.
• Kühlung
  Leistungsfähige Hardware in einem sehr kleinen Gehäuse hat ein einfaches physikalisches Problem: Die entstehende Wärme muss irgendwo hin.
  
  Deshalb werden häufig sehr kleine Lüfter eingesetzt. Diese müssen entsprechend schnell drehen, sind lauter als große Lüfter und aufgrund ihrer hohen Drehzahl mechanisch stärker belastet. Besonders unangenehm ist, dass es sich häufig um proprietäre Bauformen handelt.
  
  Wenn in einem normalen PC nach fünf Jahren ein 120- oder 140-mm-Lüfter ausfällt, kauft man für wenige Euro einen neuen. Wenn der Speziallüfter eines Mini-PCs ausfällt, beginnt unter Umständen die Suche nach irgendeinem Ersatzteil aus China.
  
  Große, langsam laufende Standardlüfter sind deshalb bei einem Server ein durchaus wichtiges Qualitätsmerkmal. Passiv gekühlte Systeme umgehen das Problem natürlich. Dann muss allerdings die thermische Konstruktion stimmen. Auch das ist bei sehr preiswerten Systemen keineswegs selbstverständlich.
• Power Limits
  Ein weiteres Problem insbesondere billiger Mini-PCs sind teilweise erstaunlich aggressive Power Limits.
  
  Ein gutes Beispiel sind Systeme mit Intel N100. Der Prozessor ist grundsätzlich sehr sparsam. Trotzdem findet man Systeme, bei denen PL1 bzw. PL2 auf 20 oder 25 Watt eingestellt sind, obwohl man einen solchen Rechner problemlos wesentlich sparsamer betreiben kann.
  
  Teilweise lassen sich diese Limits im BIOS noch nicht einmal verändern. Damit erzielt das Gerät zwar etwas bessere Benchmarkwerte, benötigt unter Last aber unnötig viel Strom und produziert entsprechend mehr Wärme.
  
  Für einen Server ist das normalerweise genau die falsche Optimierung.

Aus der TDP einer CPU kann man nur sehr eingeschränkt auf den tatsächlichen Stromverbrauch eines Rechners schließen. Interessanter ist der reale Verbrauch des kompletten Systems an der Steckdose:

• im Idle,
• bei typischer Last,
• unter Volllast.

Gerade der Idle-Verbrauch ist bei einem PVE-Host wichtig, weil ein Homeserver normalerweise einen erheblichen Teil seines Lebens mit geringer CPU-Last verbringt. Bei modernen Prozessoren steigt die Leistungsaufnahme mit zunehmender Taktrate außerdem nicht proportional zur zusätzlichen Rechenleistung. Für die höchsten Taktstufen muss üblicherweise auch die Betriebsspannung angehoben werden. Da die elektrische Leistungsaufnahme stark von dieser Spannung abhängt, werden die letzten Taktstufen energetisch besonders teuer. Die letzten fünf oder zehn Prozent Rechenleistung können deshalb durchaus zwanzig Prozent oder noch mehr zusätzliche elektrische Leistung kosten. Für einen Server ist das meistens ein schlechter Tausch. Ob eine Berechnung in zehn oder elf Sekunden abgeschlossen ist, spielt normalerweise keine Rolle. Ob der Rechner dafür jahrelang zwanzig Watt mehr aus der Steckdose zieht, dagegen schon. Ich würde deshalb bei einem PVE-Host vernünftige Power Limits einstellen, nicht den letzten möglichen Turbo-Takt erzwingen und gegebenenfalls undervolten. Anschließend sollte man die Stabilität natürlich gründlich testen. Bei einem Virtualisierungshost ist Performance pro Watt normalerweise interessanter als die letzte Benchmark-Zahl. Beim Stromverbrauch muss man ausdrücklich zwischen Idle und Maximallast unterscheiden. Nach meinen Erfahrungen sind Intel-Systeme im Idle derzeit teilweise erheblich sparsamer als vergleichbare AMD-Systeme. Das bedeutet ausdrücklich nicht, dass Intel-CPUs unter Volllast grundsätzlich weniger verbrauchen. Ich habe gerade ein Desktop-System von einem AMD Ryzen 5900X auf einen Intel Core i7-14700K umgebaut. Der Rechner benötigt seitdem im Idle etwa 55 Watt weniger, jeweils direkt an der Steckdose gemessen. Ein Teil davon hat allerdings einen anderen Grund. In dem Rechner steckt eine RTX 3080. Solange der Monitor an dieser Grafikkarte angeschlossen war, benötigte sie im Idle etwa 35 Watt. Seit der Monitor an der integrierten Intel-GPU hängt, fällt die RTX 3080 auf etwa 5 Watt zurück. Etwa 30 Watt der Einsparung stammen also von der Grafikkarte. Es bleiben trotzdem noch ungefähr 25 Watt für CPU und Plattform. Einen ähnlichen Effekt hatte ich bereits bei meinem PVE-Server, den ich von einem Ryzen 5700G auf einen Core i5-14600K umgebaut habe. Dort gab es keine RTX 3080 als zusätzliche Erklärung. Gerade bei einem 24/7-Server halte ich den Idle-Verbrauch deshalb für wesentlich wichtiger als irgendwelche TDP-Angaben. Interessant sind bei Intel außerdem die sehr gut einstellbaren Power Limits. Ein Core i7-14700K kann mit Werkseinstellungen ein ausgesprochen durstiger Prozessor sein. Das muss man aber nicht so betreiben. PL1 und PL2 lassen sich auf einen sinnvollen Wert begrenzen, ohne dass dadurch im Alltag viel Leistung verloren geht. Interessanterweise können gerade die nominell leistungsfähigeren K-Modelle für einen Server attraktiv sein. Sie sind für höhere Taktraten spezifiziert und freigeschaltet. Es handelt sich also um entsprechend selektierte CPUs, bei denen man zudem mehr Möglichkeiten zur Einstellung von Takt und Spannung hat. Ich kaufe eine K-CPU für einen Server natürlich nicht, um sie zu übertakten. Eher im Gegenteil: Sie lässt sich häufig besonders gut begrenzen und undervolten. Damit kann ausgerechnet ein nominell als 125-Watt-Prozessor verkauftes Modell im realen Serverbetrieb ausgesprochen sparsam sein. Die Zahl auf der Packung ist dafür wesentlich weniger interessant als der tatsächliche Idle-Verbrauch und die Frage, wie gut sich die CPU unter Last konfigurieren lässt. 10 Watt klingen zunächst nach nichts. Ein Server läuft aber 24 Stunden am Tag und 365 Tage im Jahr: 10 Watt × 8.760 Stunden = 87,6 kWh pro Jahr. Bei einem Strompreis von ungefähr 0,23 Euro/kWh sind das rund 20 Euro jährlich. Bei 0,30 Euro/kWh wären es bereits gut 26 Euro. Zwanzig oder dreißig Watt Unterschied summieren sich über fünf Jahre damit durchaus zu einem Betrag, über den man bei der Anschaffung einer Hardwarekomponente nachdenken würde. RAM ist bei einem Virtualisierungshost meistens wichtiger als besonders viele CPU-Kerne. 16 GByte reichen für Proxmox selbst und einige kleine LXCs problemlos aus. Bei vollständigen virtuellen Maschinen sieht die Sache schnell anders aus. Eine Windows-VM bekommt vielleicht 8 oder 16 GByte, eine Docker-VM weitere 8 GByte und dazu kommen das Hostsystem, ZFS ARC und weitere Dienste. Damit sind 16 GByte sehr schnell verbraucht. Für einen neuen PVE-Host würde ich deshalb heute mindestens 64 GByte RAM vorsehen. 128 GByte sind keineswegs übertrieben, wenn mehrere größere virtuelle Maschinen laufen sollen. Genau hier werden viele Mini-PCs problematisch: Nicht die CPU-Leistung, sondern der maximal mögliche RAM-Ausbau setzt dem System die Grenze.

• DDR4 oder DDR5?
  Für einen typischen PVE-Host bringt DDR5 häufig relativ wenig. Die zusätzliche Speicherbandbreite ist bei vielen Serveranwendungen schlicht nicht der Engpass.
  
  DDR4 ist dagegen ausgereift und inzwischen sehr preiswert. Große Speicherausbauten lassen sich damit teilweise für ungefähr die Hälfte dessen realisieren, was vergleichbarer DDR5-Speicher kostet.
  
  Für Virtualisierung würde ich deshalb eher 128 GByte DDR4 als 64 GByte DDR5 nehmen, wenn die Plattform ansonsten die gleichen Anforderungen erfüllt. Mehr RAM bringt in diesem Fall wesentlich mehr als zusätzliche Speicherbandbreite.
• ECC
  ECC ist besser als kein ECC. Bei einem Server und insbesondere bei großen Datenmengen ist zusätzlicher Schutz gegen Speicherfehler natürlich willkommen.
  
  Zwingend erforderlich ist ECC aber nicht. Insbesondere die gelegentlich zu lesende Behauptung, ZFS dürfe nur mit ECC-RAM betrieben werden, ist falsch.
  
  Wenn sich ECC ohne erheblichen Aufpreis realisieren lässt, würde ich es verwenden. Für einen privaten PVE-Host würde ich dafür aber weder massiv höhere Kosten noch eine deutlich ineffizientere Plattform akzeptieren.
  
  Ein funktionierendes Backup ist erheblich wichtiger.

Beim Storage gilt das gleiche wie beim RAM: Was bei der Installation riesig aussieht, ist einige Jahre später erstaunlich klein. Eine 256- oder 512-GByte-SSD reicht natürlich für Proxmox selbst problemlos aus. Dann kommen aber virtuelle Maschinen, Container, ISO-Images, Templates, Snapshots und möglicherweise lokale Backups hinzu. Ich würde für einen neuen PVE-Host deshalb mindestens 1 TByte für den rpool vorsehen. Bei zwei SSDs bietet sich ein ZFS-Mirror an. Bei drei oder mehr Laufwerken würde ich für einen rpool in vielen Fällen RAIDZ1 bevorzugen, wenn die zusätzliche Kapazität wichtiger ist als die höhere Random-I/O-Leistung eines Mirrors. Ein paar virtuelle Maschinen können einen zunächst groß wirkenden Pool erstaunlich schnell füllen. Ich würde auf einem PVE-Host grundsätzlich ZFS einsetzen. ZFS bietet unter anderem Checksummen, Snapshots, Scrubs, integrierte Redundanz, Replikation und eine sehr gute Integration in Proxmox. Wichtig ist allerdings: Redundanz ist kein Backup. Ein ZFS-Pool schützt gegen den Ausfall von Laufwerken und erkennt Datenfehler. Er schützt nicht gegen versehentliches Löschen, Malware, einen zerstörten Rechner oder Feuer. Ein separates Backup gehört deshalb trotzdem dazu. Bei SSDs wird häufig hauptsächlich auf die maximale Transferrate geschaut. Für einen Server sind andere Eigenschaften oft erheblich interessanter:

• TBW
  Gerade bei ZFS sollte man auf die TBW-Angabe achten. Copy-on-Write, Metadaten und virtuelle Maschinen erzeugen eine erhebliche Zahl kleiner Schreibzugriffe. Damit kann die tatsächlich geschriebene Datenmenge deutlich größer sein, als man anhand der Nutzdaten zunächst vermuten würde.
  
  Eine SSD mit besonders niedriger spezifizierter Schreibmenge würde ich deshalb nicht für einen stark genutzten ZFS-VM-Storage einsetzen.
• DRAM-Cache
  Für ZFS würde ich möglichst SSDs mit eigenem DRAM-Cache verwenden. Gerade virtuelle Maschinen und ZFS erzeugen viele kleine und teilweise zufällige Schreibzugriffe.
  
  Der DRAM einer SSD hält unter anderem Mapping- und Verwaltungsinformationen schnell verfügbar und kann bei solchen Zugriffsmustern einen erheblichen Unterschied machen.
  
  DRAM-lose SSDs können in normalen Benchmarks trotzdem hervorragend aussehen, weil dort häufig große sequentielle Transfers gemessen werden. Das ist aber nicht unbedingt das Lastprofil eines PVE-Hosts.
  
  Einige NVMe-SSDs verwenden HMB und benutzen dafür einen kleinen Teil des Hauptspeichers des Rechners. Das reduziert den Nachteil, ist aber nicht dasselbe wie eigener DRAM auf der SSD.
• SLC-Cache
  Nicht verwechseln sollte man DRAM-Cache und SLC-Cache.
  
  Viele Consumer-SSDs verwenden einen Teil ihres NAND zunächst im SLC-Modus und erreichen damit sehr hohe Schreibraten. Ist dieser Bereich voll, kann die Schreibleistung teilweise drastisch einbrechen.
  
  Für einen Server ist deshalb nicht nur interessant, welche Geschwindigkeit in den ersten Sekunden eines Benchmarks erreicht wird, sondern auch, was nach mehreren zehn oder hundert GByte Dauerwrite noch übrig bleibt.
• NAND-Typ
  QLC würde ich für einen schreibintensiven VM-Storage vermeiden. Für ein weitgehend nur lesendes Archiv kann QLC völlig ausreichend sein. Bei vielen kleinen ZFS- und VM-Writes ist TLC normalerweise die bessere Wahl.
• Stromverbrauch und Temperatur
  Auch SSDs unterscheiden sich erheblich beim Idle-Verbrauch und bei der Abwärme. Gerade mehrere schnelle NVMe-SSDs können zusammen einige Watt dauerhaft verbrauchen und benötigen unter Last unter Umständen eine vernünftige Kühlung.
• Power-Loss-Protection
  Wenn man günstig an Enterprise-SSDs mit echter Power-Loss-Protection kommt, ist das für einen Server natürlich ein Vorteil. Zwingend erforderlich ist sie für einen normalen Homeserver aber nicht.

Eine SSD, die im Benchmark 7 GByte/s erreicht, ist deshalb nicht automatisch eine gute Server-SSD. Bei Geizhals kann man viele dieser Eigenschaften sehr bequem filtern und vergleichen. Bei mechanischen Festplatten gibt es für mich eine einfache Regel: Kein SMR für ZFS. Shingled Magnetic Recording erhöht die Speicherdichte, erkauft dies aber mit erheblichen Nachteilen bei überschreibenden Schreibzugriffen. Spätestens bei einem ZFS-Resilver kann das ausgesprochen unangenehm werden. Man sollte deshalb CMR-Festplatten verwenden. Bei mehreren Laufwerken muss außerdem auf eine vernünftige Kühlung geachtet werden. Sechs oder acht dicht nebeneinander montierte Festplatten produzieren eine erhebliche Menge Wärme. Hier zeigt sich wieder, weshalb die Gehäusegröße zur geplanten Storage-Kapazität passen sollte. Beim Mainboard würde ich zuerst darauf achten, dass die tatsächlich benötigten Funktionen vorhanden sind: genügend SATA-Ports, genügend M.2-Slots bzw. NVMe-Anbindung, ausreichend RAM-Slots und vor allem genügend sinnvoll angebundene PCIe-Steckplätze. Weniger interessant ist der übliche Consumer-Firlefanz, den man bei einem Server meistens überhaupt nicht benötigt: WLAN, besonders aufwendiger Onboard-Sound, Thunderbolt, serielle oder parallele Schnittstellen und ähnliche Zusatzfunktionen. Solche Komponenten sind nicht nur unnötig, sie können auch Strom verbrauchen, zusätzliche Treiber benötigen oder schlicht weitere Fehlerquellen darstellen. Gut ist deshalb ein BIOS, in dem sich nicht benötigte Onboard-Komponenten einzeln abschalten lassen. Was ich nicht brauche, deaktiviere ich dort auch. Bei der Auswahl des Mainboards sollte man außerdem nicht nur zählen, wie viele Steckplätze sichtbar vorhanden sind. Viele Consumer-Boards teilen sich PCIe-Lanes zwischen M.2-Slots, SATA-Ports und PCIe-Steckplätzen. Dann kann das Einsetzen einer zusätzlichen NVMe dazu führen, dass plötzlich zwei SATA-Ports deaktiviert werden oder ein PCIe-Slot nur noch mit weniger Lanes angebunden ist. Das steht normalerweise im Handbuch des Mainboards und sollte vor dem Kauf geprüft werden. Gerade bei einem Server halte ich freie und ausreichend breit angebundene PCIe-Steckplätze für ausgesprochen wertvoll. Ein heute unbenutzter Slot kann später einen HBA, eine 10-GBit-Netzwerkkarte oder irgendeine andere Erweiterung aufnehmen, an die man beim Kauf noch gar nicht gedacht hat. Wenn die SATA-Ports des Mainboards nicht ausreichen, sollte man für ZFS einen HBA verwenden. Bewährt sind beispielsweise LSI-/Broadcom-Controller im IT-Mode. Von klassischen Hardware-RAID-Controllern würde ich bei ZFS abraten. ZFS soll die einzelnen Festplatten direkt sehen und Redundanz, Checksummen und Fehlerbehandlung selbst übernehmen. Beim Netzwerk gilt im Grunde das gleiche wie beim Storage: Entweder das Mainboard bringt die benötigten Interfaces bereits mit, oder man muss sie nachrüsten. Wenn man beispielsweise später auf 10 GBit/s wechseln möchte, sollte das Mainboard dafür einen geeigneten freien PCIe-Slot besitzen. Dabei reicht nicht in jedem Fall irgendein mechanischer x1-Slot. Je nach Karte und gewünschter Geschwindigkeit werden x4 oder mehr PCIe-Lanes benötigt. Auch deshalb sollte man bei einem Server nicht nur auf die Anzahl, sondern auf die elektrische Anbindung der Slots achten. Beim Controller selbst würde ich nach Möglichkeit etablierte Chips verwenden. Intel-NICs haben seit Jahren eine sehr gute Treiberunterstützung. Auch Realtek funktioniert inzwischen in vielen Fällen problemlos. Bei schnellen Interfaces sollte man aber zusätzlich auf Treiber, Stromverbrauch und Temperatur achten. 10GBASE-T kann pro Port mehrere Watt zusätzlich benötigen. Wenn SFP+ möglich ist, sind DAC-Kabel für kurze Entfernungen häufig nicht nur günstiger, sondern auch sparsamer. Nicht benötigte Onboard-Netzwerkcontroller würde ich im BIOS deaktivieren. Das gleiche gilt für zusätzliche Karten, die irgendwann nicht mehr benötigt werden: Ausbauen oder abschalten, statt sie jahrelang ungenutzt mitlaufen zu lassen. Ein häufiger Fehler bei sparsamen Servern besteht darin, auch das Netzteil möglichst knapp dimensionieren zu wollen. Das würde ich nicht machen. In ein normales System würde ich nichts einbauen, das weniger als ungefähr 300 Watt liefern kann. Man benötigt Reserve für CPU, Chipsatz, Erweiterungskarten und insbesondere zusätzliche Festplatten. Mechanische Festplatten benötigen beim Hochlaufen kurzfristig erheblich mehr Leistung als im normalen Betrieb. Wichtig ist nicht, ein möglichst kleines Netzteil einzubauen, sondern eines, das im Niedriglastbereich effizient arbeitet. Ein PVE-Host, der im Idle 30 oder 40 Watt benötigt, betreibt ein 400- oder 500-Watt-Netzteil nur mit einem sehr kleinen Teil seiner Nennleistung. Gerade in diesem Bereich unterscheiden sich Netzteile erheblich. Geeignete Modelle findet man häufig im SFX- oder TFX-Format für kleinere Gehäuse. Es gibt aber auch ganz normale ATX-Netzteile, die bereits bei sehr niedriger Last einen guten Wirkungsgrad erreichen. Im Web gibt es verschiedene Seiten, die solche Netzteile speziell im Niedriglastbereich vermessen und vergleichen, beispielsweise:  PicoPSUs und kleine ATX-Netzteile im Effizienz-Test Solche Messungen halte ich für einen Homeserver häufig für aussagekräftiger als die reine 80-PLUS-Klassifizierung. Ein 700-Watt-Netzteil kann bei 30 Watt Last durchaus schlechter abschneiden als ein gutes 300- oder 400-Watt-Netzteil. Daraus folgt aber eben nicht, dass man das Netzteil möglichst knapp dimensionieren sollte. Bei einem Server sollte man auch darüber nachdenken, was passiert, wenn nach fünf Jahren etwas kaputtgeht. Bei einem normalen PC sind praktisch alle relevanten Teile standardisiert:

• ATX-, SFX- oder TFX-Netzteile,
• normale DIMMs,
• SATA- bzw. NVMe-SSDs,
• PCIe-Karten,
• 120- oder 140-mm-Lüfter.

Wenn etwas kaputtgeht, kauft man Ersatz. Bei einem Mini-PC bilden Mainboard, Gehäuse, Kühler, Lüfter und teilweise auch die Stromversorgung dagegen häufig eine sehr spezifische Einheit. Fällt davon eine Komponente aus, kann ein ansonsten völlig brauchbarer Rechner wirtschaftlich zum Totalschaden werden. Für einen Server, der möglichst viele Jahre laufen soll, ist Reparierbarkeit deshalb durchaus ein Qualitätsmerkmal. Damit soll keineswegs gesagt sein, dass Mini-PCs grundsätzlich ungeeignet wären. Wenn die Anforderungen lauten:

• wenige Container oder VMs,
• kein großer lokaler Storage,
• keine PCIe-Erweiterungen,
• wenig Platz,
• möglichst wenig Geräusch,
• geringer Anschaffungspreis,

kann ein Mini-PC die beste Lösung sein. Ein kleiner N100-Rechner mit ausreichend RAM kann beispielsweise ein hervorragender kleiner PVE-Host sein. Man sollte nur nicht erwarten, daraus später einen großen Storage- und Virtualisierungsserver machen zu können. Ein großer Tower wäre andererseits reichlich albern, wenn darin eine einzelne SSD steckt und der Rechner in einer Studentenwohnung direkt neben dem Bett steht. Die Hardware muss eben zum Einsatzzweck passen. Bei der Planung eines PVE-Hosts würde ich nicht versuchen, möglichst viel CPU-Leistung auf möglichst kleinem Raum unterzubringen. Wichtiger sind:

• niedriger Idle-Verbrauch,
• vernünftig einstellbare Power Limits,
• ausreichend RAM,
• ausreichend großer und zuverlässiger Storage,
• genügend sinnvoll angebundene PCIe-Steckplätze,
• gute Kühlung,
• Standardkomponenten,
• Reparierbarkeit.

CPU-Leistung ist bei vielen Homeservern erstaunlich selten der eigentliche Engpass. RAM, Storage und Erweiterungsmöglichkeiten werden meistens wesentlich früher knapp. Ein System mit sechs oder acht vernünftigen CPU-Kernen, 64 oder 128 GByte RAM und ausreichend Storage ist deshalb häufig erheblich brauchbarer als ein Rechner mit maximaler CPU-Leistung, 16 GByte RAM und einer 512-GByte-SSD. Der wichtigste Grundsatz ist eigentlich einfach: Man sollte nicht den kleinsten Rechner kaufen, der die heutigen Anforderungen gerade noch erfüllt, sondern den kleinsten Rechner, der auch die absehbaren Anforderungen der nächsten Jahre noch sinnvoll erfüllen kann.