Server-Hardware auswählen: CPU, Speicher, Laufwerke, Redundanz

Server-Hardware auswählen ist eine Frage der Abwägung zwischen Leistung, Ausfallsicherheit, Verbrauch und Lebensdauer. Die häufigsten Fehlentscheidungen entstehen nicht bei der CPU, sondern bei Speicher, Redundanz und Wartbarkeit.

CPU: Kerne, Takt und Auswahl

Die entscheidende Frage: Was ist die Arbeitslast?\n\nSINGLE-THREAD-LAST (Webserver, Datenbank mit\n  vielen kleinen Abfragen, Anwendungen mit\n  wenigen parallelen Nutzern)\n  -> hoher TAKT ist wichtiger als viele Kerne\n  -> 8 Kerne mit 4,0 GHz schlagen 32 Kerne mit 2,0 GHz\n\nPARALLELE LAST (Big-Data, Rendering, Kompilierung,\n  viele gleichzeitige Nutzer, Container-Host)\n  -> viele KERNE sind wichtiger\n  -> 32 Kerne mit 2,5 GHz sind besser\n\nKennzahlen, die zaehlen:\n  Basistakt / Boost-Takt      wichtig bei wechselnder Last\n  Kerne / Threads             wichtig bei paralleler Last\n  Cache (L3)                  wichtig bei Datenbanken\n  Speicherbandbreite          wichtig bei Datenanalyse\n  TDP                         wichtig fuer Kuehlung/Strom\n  Speicherkanaele             Mehr Kanaele = mehr Bandbreite!\n\nWICHTIG - die haeufigste Fehlentscheidung:\n  Alle Kerne voll ausgenutzt? Bei den meisten\n  Servern liegt die Auslastung bei 5-25 %.\n  # Bevor man Kerne kauft: AUSLASTUNG MESSEN.\n  # Ein Server mit 32 Kernen bei 8 % Auslastung ist\n  # teuer in Beschaffung, Lizenz (bei Core-Lizenzen!)\n  # und Strom.\n\nKern-Verhaeltnis zur virtuellen Maschine:\n  CPU-Ueberbuchung (overcommit) 2:1 bis 4:1 ist\n  bei vielen kleinen VMs ueblich und sinnvoll\n  # Aber NICHT bei Datenbanken und rechenintensiven\n  # Diensten - dort ist die Reserve echt noetig.\n  # Ein "Steal Time" ueber 5 % bedeutet: Der Host\n  # gibt nicht genug CPU - die VMs warten.\n\nKernlizenzierung beachten:\n  Manche Datenbanken und Anwendungen lizenzieren\n  NACH KERNEN. Ein 64-Kern-Server kann in der\n  Lizenz teurer sein als die Hardware!\n  # Zweimal rechnen: Hardware + Lizenz.

Arbeitsspeicher

Menge: Die Regel "so viel wie noetig" braucht Zahlen:\n  - Datenbank: Der Arbeitspuffer (cache/buffer pool)\n    sollte die Arbeitsdatenmenge fassen\n  - Anwendungsserver: 2-8 GB je Anwendung\n  - Virtualisierung: Summe der VM-Zusagen + 10-20 % Reserve\n  # Praxis: Auslastung ueber 2 Wochen messen.\n  # Ein Server mit 128 GB und 20 % Nutzung ist ein\n  # Kandidat fuer Konsolidierung.\n\nFehlerkorrektur (ECC) - PFLICHT bei Servern!\n  Speicherfehler sind selten, aber wenn sie auftreten,\n  sind sie katastrophal: Sie veraendern Daten\n  unbemerkt. Ein einzelnes gekipptes Bit in einer\n  Datenbank kann einen Datensatz unbrauchbar machen.\n  ECC erkennt und korrigiert Einzelbitfehler.\n  # Ohne ECC laeuft der Server mit einem Risiko,\n  # das niemand messen kann. Server OHNE ECC gehoeren\n  # nicht in die Produktion.\n  # Pruefmöglichkeit: dmidecode -t memory | grep -i ecc\n\nRegistered / Buffered (RDIMM) gegen Unbuffered (UDIMM):\n  RDIMM   fuer Server, groessere Mengen (bis TB),\n          Pufferregister entlasten den Speichercontroller\n  UDIMM   fuer Arbeitsplaetze, kleinere Mengen\n  # NICHT MISCHEN und nicht verwechseln! Ein Server\n  # mit RDIMM-Steckplaetzen laeuft mit UDIMM nicht.\n  # Beim Kauf immer die Kompatibilitaetsliste des\n  # Herstellers pruefen - "passt mechanisch" heisst\n  # nicht "laeuft".\n\nSpeicherkanaele nutzen:\n  # Bei 8 Steckplaetzen und 8 Kanaelen: alle bestuecken.\n  # Falsche Bestueckung (nur ein Kanal) kostet\n  # die Haelfte der Bandbreite - und die merkt man\n  # bei Datenbanken und Analysen deutlich.\n\nBestueckung und Erweiterbarkeit:\n  # Bei der Erstbestellung lieber groessere Module\n  # (weniger Module bestueckt, Platz fuer spaeter).\n  # 4x32GB statt 8x16GB, wenn nur 4 von 8 Bänken\n  # gebraucht werden.\n  # ACHTUNG: Manche Server reduzieren den Takt bei\n  # Vollbestueckung! Pruefen.

Speicher: NVMe, SSD, HDD

TECHNOLOGIE     ZUGRIFFSZEIT   DURCHSATZ      EINSATZ\nNVMe            20-100 us      3-14 GB/s      Datenbanken,\n                                               virtuelle Maschinen,\n                                               Zwischenspeicher\nSATA-SSD        100-200 us     500-550 MB/s   Betriebssystem,\n                                               Anwendungen\nSAS-HDD (10-15k) 5-10 ms      200-300 MB/s   gemischte Last\nSATA-HDD (7,2k)  8-15 ms      150-250 MB/s   Archive, Sicherungen\n\nENTSCHEIDENDE KENNZAHLEN (nicht nur Kapazitaet!):\n  IOPS (Eingabe/Ausgabe pro Sekunde)   <- das Wichtigste\n  Durchsatz (MB/s)                     <- nur bei grossen Dateien\n  Schreibausdauer (TBW, DWPD)          <- Lebensdauer!\n  Latenz                               <- bei Datenbanken entscheidend\n  Ausfallschutz (Stromausfallschutz im Laufwerk)\n\n  # Ein Datenbankproblem ist fast immer ein IOPS-Problem,\n  # nicht ein Kapazitaetsproblem.\n\nLebensdauer:\n  TBW = insgesamt beschreibbare Datenmenge\n  DWPD = Schreibvorgaenge je Tag (bezogen auf Kapazitaet)\n  # Eine SSD mit 1 DWPD und 1 TB haelt 1 TB Schreiben\n  # pro Tag ueber 5 Jahre = 1825 TB\n  # Eine "Consumer"-SSD mit 0,3 DWPD haelt nur 550 TB -\n  # bei Datenbanklast ist sie in Monaten verschlissen!\n  # Pruefen: smartctl -a /dev/nvme0 | grep -i wear\n  #         Available Spare, Percentage Used\n\nRAID-Ebene:\n  RAID 1   Spiegelung, 50 % Nutzung - einfach, sicher\n  RAID 5   Paritaet, (n-1)/n - ACHTUNG: Wiederherstellung\n           kann bei grossen Platten Tage dauern, und\n           ein zweiter Ausfall in der Zeit = Totalverlust\n  RAID 6   Zwei Paritaeten, (n-2)/n - fuer Archive\n  RAID 10  Spiegelung + Streifen, 50 % - beste Leistung\n           und schnelle Wiederherstellung, hoher Preis\n  # Fuer Datenbanken: RAID 10.\n  # Bei NVMe: RAID 5 meiden (Wiederherstellungszeit!)\n  # Empfehlung heute: NVMe im RAID 1 oder RAID 10.\n\nWICHTIG: RAID ist KEINE Sicherung!\n  # Ein RAID schuetzt vor dem Ausfall einer Platte,\n  # nicht vor Loeschen, Verschluesselung, Versehen\n  # oder einem Ausfall des Servers.\n  # RAID + Datensicherung, nicht statt.

Redundanz: Strom, Netzwerk, Kühlung

Netzteile:\n  Zwei Netzteile an ZWEI UNABHAENGIGEN Stromkreisen\n  # Haengen beide an derselben USV oder demselben\n  # Stromkreis, ist es keine Redundanz - nur\n  # ein zweiter Stecker.\n  # Pruefen: Nach dem Ziehen eines Netzsteckers\n  # muss der Server ohne Meldung weiterlaufen.\n  # Und: Ein Netzteil im Leerlauf kann ueber Jahre\n  # unbemerkt ausfallen! Regel: einmal jaehrlich\n  # abwechselnd je ein Netzteil ziehen (im\n  # Wartungsfenster).\n\nNetzwerk:\n  Zwei Netzwerkkarten, Bonding/Teaming\n  Modus 1 (aktiv/passiv): funktioniert immer\n  Modus 4 (LACP): braucht Switch-Unterstuetzung,\n    Lastverteilung, aber pro Verbindung keine\n    doppelte Geschwindigkeit\n  # Zwei Karten im selben Switch: schuetzt nur\n  # gegen Kartenausfall, nicht gegen Switchausfall.\n  # Zwei Switches = zwei Karten. Bonding ueber\n  # zwei Switches (MLAG/VPC) braucht Konfiguration.\n\nLuefter:\n  Redundante Luefter sind Standard. WICHTIG:\n  Pruefen, dass die Drehzahlueberwachung wirklich\n  alarmiert. Ein Luefterausfall im Sommer kann\n  zum Heruntertakten oder Ausfall fuehren.\n  # Ueberwachung: ipmitool sdr | grep -i fan\n\nManagement (BMC/IPMI/iDRAC/iLO):\n  Immer vorhanden bei Servern - und absolut\n  notwendig fuer den Betrieb.\n  # WICHTIG: Das Management-Interface gehoert in\n  # ein EIGENES Verwaltungsnetz, NICHT ins Internet!\n  # Standardkennwoerter aendern, Benutzer anlegen,\n  # Firmware aktuell halten (Sicherheitsluecken\n  # im BMC sind ein bekannter Angriffsweg).\n  # Ausstattung: Konsolenumleitung (KVM ueber Netz),\n  # virtuelles Laufwerk (ISO einbinden!), Berichte\n  # und Zustaende.

Prüfliste

Ist die Auslastung des Vorgängers gemessen (Kerne, Speicher, IOPS)?
Ist ECC-Speicher vorhanden?
Sind alle Speicherkanäle korrekt bestückt?
Sind RDIMM/UDIMM korrekt und nicht gemischt?
Sind IOPS und Schreibausdauer der Laufwerke ausreichend (nicht nur Kapazität)?
Sind Netzteile an unabhängigen Stromkreisen?
Sind Netzwerkkarten redundant (bei kritischen Servern)?
Ist das Management-Interface in einem eigenen Netz?
Sind die Standardzugangsdaten des BMC geändert?
Ist die BMC-Firmware aktuell?
Sind Rahmenvertrag und Ersatzteilverfügbarkeit geklärt (Lieferzeit!)?
Ist der Server im Inventar mit Lebenszyklusdatum erfasst?

Häufige Fehler

Speicher ohne ECC. Bei Servern unverzeihlich. Datenfehler können unbemerkt bleiben.
IOPS nicht geplant. Eine Datenbank kann an 500 IOPS scheitern, während 10 TB Kapazität ungenutzt sind.
Consumer-SSD im Server. Nach Monaten Schreiblast verschlissen – mit Datenverlust.
RAID 5 bei großen NVMe. Die Wiederherstellung dauert lange und kann scheitern. RAID 10 oder RAID 6.
„Redundante“ Stromversorgung an einer USV. Kein Schutz gegen den Ausfall der USV.
Zweite Netzwerkkarte nicht benutzt. Sie liegt brach, bis sie im Notfall – mit veralteter Konfiguration – gebraucht wird.
Speicherkanaele nicht genutzt. Falsche Bestückung kostet die halbe Bandbreite bei gleichen Kosten.
BMC im Internet mit Standardpasswort. Ein bekannter, schwerwiegender Fehler. Das Management gehört ins Verwaltungsnetz.
Lüfterausfall ohne Alarm. Im Sommer führt das zum Heruntertakten oder Abschalten.
RAID mit Sicherung verwechselt. RAID schützt vor Plattenausfall, nicht vor Versehen.
Kernlizenzen übersehen. Ein 64-Kern-Server kann in der Lizenz mehr kosten als die Hardware.

Verwandte Grundlagen: NVMe-SSDs, ECC-Speicher, RAID-Verbünde, IPMI und Redfish.

Hardware: Server