Fehlersuche bei Hetzner-AX162-Ausfällen mit powerstat, sensors und dmidecode

 (ubicloud.com)
1 Punkte von GN⁺ 2025-02-21 | 1 Kommentare | Auf WhatsApp teilen
  • Ubicloud führte Hetzners neuen AX162 ein, weil er im Vergleich zum AX161 bei Leistung und Preis besser wirkte, hatte im Betrieb jedoch ein Zuverlässigkeitsproblem mit 16-mal häufigeren Ausfällen
  • Die Ursachenanalyse begann mit Systemlogs, in denen NULL-Bytes verblieben waren, und schloss dann nacheinander Last, Temperatur, Komponenteninformationen und Stromverbrauch aus; sensors, dmidecode und powerstat waren dabei die zentralen Werkzeuge
  • In den ersten Daten kam der AX161 auf 11 Ausfälle in 3.784 Betriebstagen und damit auf eine AFR von 1,06, während der AX162 auf 34 Ausfälle in 737 Tagen und eine AFR von 16,84 kam
  • 80 % der Server, die einmal ausgefallen waren, erlebten innerhalb von 24 Stunden einen zweiten Ausfall, und Hetzner meldete einen Fehler in einer Mainboard-Charge, ohne eine mögliche Strombegrenzung zu bestätigen oder auszuschließen
  • Der AX162 -v3 mit dem neuesten Mainboard sank nach mehrmonatigem Monitoring auf eine AFR von 0,39; neue Hardware sollte zunächst schrittweise mit nicht kritischen Workloads validiert werden

Wiederholte Abstürze nach der Einführung des AX162

  • Ubicloud entwickelt Software, die Bare-Metal-Anbieter in eine Cloud-Plattform verwandelt, und nutzte Hetzner bislang als günstigen und zuverlässigen Serveranbieter
  • Hetzners Serverlinie AX162 bot gegenüber dem Vorgängermodell AX161 bessere Leistung und einen niedrigeren Preis und wurde deshalb schnell eingeführt
  • Drei Wochen nach dem Kauf des ersten AX162 stürzte ein Server ab, und in den Systemlogs blieben NULL-Bytes zurück
    • Das wurde als Signal eines plötzlichen Fehlers interpretiert, bei dem Schreibvorgänge nicht sauber abgeschlossen wurden, ähnlich wie bei einem Stromverlust
  • Bei Hetzners erster Hardwareprüfung wurde zunächst nichts Auffälliges gefunden, doch eine Woche später trat ein weiterer Absturz auf, und in den folgenden Tagen wiederholten sich die Ausfälle

Wie sich die Ausfälle zeigten

  • Alle Abstürze traten ausschließlich auf AX162-Servern auf
  • Die Ausfälle ließen sich in zwei Formen einteilen
    • Der Server kam nach einem manuellen Neustart wieder online
    • Der Server reagierte weder auf Neustartanforderungen noch auf den Diagnosecode der Hetzner-Ingenieure und musste ersetzt werden
  • Die Server liefen meist lange Zeit normal, doch nach dem ersten Absturz stieg die Wahrscheinlichkeit weiterer Abstürze deutlich
  • Es zeigte sich ein Muster, bei dem sich der erste Absturztyp mehrfach wiederholte und schließlich in den zweiten Typ überging, sodass der Server ersetzt werden musste

Zuerst Last und Temperatur ausschließen

  • Der AX162 bot 96 vCPU, und bei Ubicloud gab es Workloads, die alle vCPU gleichzeitig nutzten
  • Es wurde die Hypothese geprüft, dass hohe Last zu steigenden Temperaturen oder unerwarteten Problemen führen könnte, doch Ausfälle traten auch bei niedriger Last oder ganz ohne Last auf
  • Um die Korrelation zwischen Temperatur und Ausfällen zu prüfen, wurden mit dem Befehl sensors die Temperaturen der Systemkomponenten erfasst
  • Die Temperaturdaten wurden mit einem einfachen Cron-Job gesammelt; bei der erneuten Prüfung nach weiteren Abstürzen lagen die Werte nicht deutlich über dem Durchschnitt

Untersuchung von Komponenteninformationen und Stromverbrauch

  • Mit lshw und dmidecode wurden Modell- und Seriennummern der Hardwarekomponenten geprüft
  • Die Komponenten abgestürzter AX162-Server wurden mit denen stabiler Server verglichen, doch es wurde kein signifikanter Unterschied gefunden
  • Weil ältere Komponenten möglicherweise häufiger ausfallen, wurde auch der Verlauf steigender Seriennummern betrachtet, doch Abstürze traten auch bei Servern mit den neuesten Seriennummern auf
  • Beim Ausbau von Rechenzentren ist häufig Strom und nicht Platz der begrenzende Faktor, und Betreiber können den Stromverbrauch pro Maschine begrenzen
    • Ubicloud wusste nicht, ob Hetzner den Stromverbrauch begrenzte, hielt die Symptome — lange stabile Laufzeiten gefolgt von wiederholten Abstürzen — aber für vereinbar mit Hardwareverschleiß
    • Nachdem andere Hypothesen eine nach der anderen ausgeschlossen worden waren, blieb eine Strombegrenzung als starke Hypothese übrig
  • Mit powerstat -R wurde der maximale Stromverbrauch über längere Zeit gemessen und mit den beworbenen Werten verglichen
    • AX161: beworbene maximale Leistungsaufnahme 147 W, gemessene maximale Leistungsaufnahme 168 W
    • AX162: beworbene maximale Leistungsaufnahme 408 W, gemessene maximale Leistungsaufnahme 266 W
  • Wegen dieser Differenz entstand der Verdacht, dass Hetzner den tatsächlichen Stromverbrauch begrenzen könnte

Ausfallrate anhand der AFR

  • Zum Vergleich der Hardwarezuverlässigkeit wurde die Annualized Failure Rate (AFR) verwendet
  • AFR hat zwar Grenzen, war aber als einfacher Ausgangspunkt für den Vergleich der Ausfallraten ausreichend
  • Die ersten Messungen zeigten, dass die Ausfallrate des AX162 deutlich höher war als die des AX161
    • AX161: 11 Ausfälle, insgesamt 3.784 Betriebstage, AFR 1,06
    • AX162: 34 Ausfälle, insgesamt 737 Betriebstage, AFR 16,84
  • Diese Daten stützten die Beobachtung, dass der AX162 16-mal häufiger Ausfälle erlebte als andere Modelle
  • Server, die einmal abgestürzt waren, hatten eine sehr hohe Wahrscheinlichkeit für einen weiteren Absturz; 80 % dieser Server erlitten innerhalb von 24 Stunden einen zweiten Absturz

Mainboard-Tausch und die Grenzen von v2

  • Ubicloud reichte bei Hetzner ein detailliertes Support-Ticket ein, einschließlich des Verdachts auf Strombegrenzung und der AFR-Daten
  • Hetzner bestätigte oder verneinte die Möglichkeit einer Strombegrenzung nicht, teilte aber mit, dass ein Fehler in einer Mainboard-Charge festgestellt worden sei
  • Hetzner erhielt Mainboards aus einer neuen Charge und empfahl den Austausch der Mainboards in den betroffenen Servern
  • Ein groß angelegter Serveraustausch hätte Kunden-Workloads beeinträchtigen können, aber wegen der wiederholten Abstürze waren die meisten wichtigen Aufgaben bereits vom AX162 wegmigriert worden, sodass der Austausch möglich war
  • Auch nach dem Tausch auf neue Mainboards wurden kritische Workloads nicht wieder auf den AX162 zurückgelegt, sondern das Langzeit-Monitoring fortgesetzt
  • Zunächst traten keine Abstürze auf, doch zwei Wochen später kam es auch auf Servern mit den neuen Mainboards wieder zu Abstürzen
    • AX162 -v2: 11 Ausfälle, insgesamt 758 Betriebstage, AFR 5,30
  • v2 stürzte zwar seltener ab als der ursprüngliche AX162, die Ausfallrate blieb aber weiterhin hoch

Stabilisierung mit v3

  • Nach einer erneuten Kontaktaufnahme mit Hetzner stellte sich heraus, dass es eine neueste Mainboard-Version mit weiter verbesserter Zuverlässigkeit gab
  • Die Server wurden auf diese neueste Version migriert, und die Zuverlässigkeit wurde weiter überwacht
  • Nach mehreren Monaten Beobachtung der neuen Server kam Ubicloud zu dem Schluss, dass das Absturzproblem des AX162 behoben sei
  • Der finale AFR-Vergleich sah wie folgt aus
    • AX161: 11 Ausfälle, insgesamt 3.784 Betriebstage, AFR 1,06
    • AX162: 34 Ausfälle, insgesamt 737 Betriebstage, AFR 16,84
    • AX162 -v2: 11 Ausfälle, insgesamt 758 Betriebstage, AFR 5,30
    • AX162 -v3: 4 Ausfälle, insgesamt 3.738 Betriebstage, AFR 0,39
  • Die AFR des AX162 -v3 lag sogar unter der des AX161

Verbesserungen im Betriebsprozess

  • Bei der frühen Einführung neuer Serverlinien können unerwartete Probleme auftreten
  • Die Spezifikationen des AX162 waren attraktiv, und dass Hetzner den AX161 eingestellt hatte, wirkte wie ein Signal, dass die neue Linie produktionsreif sei
  • Rückblickend hätten sich viele Probleme wohl vermeiden lassen, wenn man sechs Monate gewartet hätte
  • Künftig gelten folgende Änderungen
    • Für neue Servermodelle wird eine gründlichere Validierung durchgeführt
    • Neue Hardware wird schrittweise eingeführt, beginnend mit nicht kritischen Workloads
    • Zur Risikostreuung werden weitere Bare-Metal-Anbieter hinzugefügt
  • Ubicloud unterstützt bereits die beiden zusätzlichen Bare-Metal-Anbieter Leaseweb und Latitude; ein vierter Anbieter befindet sich ebenfalls in Arbeit

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-02-21
Meinungen auf Hacker News

  • Auch andere AX-Modelle (AX42, AX52, AX102) haben gravierende Zuverlässigkeitsprobleme und fallen nach einigen Monaten aus.
    Sie basieren auf einem fehlerhaften Mainboard, daher wird Hetzner in den nächsten 12 Monaten die Mainboards von Servern, die vor einem bestimmten Datum gebaut wurden, größtenteils, vielleicht sogar vollständig, austauschen müssen [0]
    [0] https://docs.hetzner.com/robot/dedicated-server/general-info...

    • Ich betreibe zwei AX42; einer ist seit dem Erhalt während der Eurocup-Rabattaktion stabil, der andere wurde bisher zweimal ersetzt.
      Der neueste Ersatz scheint durchzuhalten, daher sieht es auf Basis dieser kleinen Stichprobe nach einer Ausfallrate von 50 % aus. Die tatsächlichen Zahlen kennen wohl nur Hetzner und ASRock.

  • In einer früheren Firma hat DevOps bei Hetzner-Hardware häufig CPU-Lüfterausfälle entdeckt.
    Das war unabhängig von den üblicherweise zu erwartenden HDD-/SSD-Ausfällen und musste selbst überwacht werden. Das ist einer der Gründe, warum nicht gemanagte Server günstiger sind als Cloud-Instanzen.

    • Auch bei Azure habe ich häufig defekte Kühleinheiten gesehen, und als ich bei Google arbeitete, war das ebenfalls ein niedriges, aber stetiges Ärgernis.
      An meinem ersten Tag bei Dropbox sagte ich dem Team: „Ich kann in der Fleet Maschinen finden, die mit 400 MHz laufen“, und das stimmte tatsächlich. Ein fehlerhafter redundanter PSU-Controller löste PROCHOT aus. Wenn man viele Maschinen hat, passiert so etwas.
    • Nicht gemanagt zu sein bedeutet, dass man Zugriff auf Siliziumebene und Remote-KVM bekommt, nicht dass die Verantwortung für die physische Hardware auf den Kunden übergeht.
      Physische Geräte ordnungsgemäß zu besitzen, zu warten und zu reparieren, bleibt weiterhin die Verantwortung des Hosting-Unternehmens, inklusive Monitoring. Früher musste man Skripte oder Pakete installieren, um sie ans Monitoring anzubinden, aber da IPMI und Ähnliches heute Standard sind, geht das auch ohne Mithilfe des Kunden.
      Wenn nicht nur Rackspace, Strom und Netzwerk bereitgestellt werden, ist es eine Vertragsfrage, was genau übernommen wird. Wenn Hetzner nicht einmal CPU-Lüfterausfälle der eigenen Hardware erkennt und neue Systeme ohne ausreichende Tests ausrollt, wirkt das wie ein Beleg dafür, dass sie weiter abrutschen.
    • Ich bin sowohl entschieden dagegen, sich auf kostenlose Abhängigkeiten zu verlassen, als auch dagegen, immer nur die billigste Option zu wählen.
      Wenn man bei einer Kaufentscheidung nicht einmal kurz die Perspektive der Gegenseite einnimmt und nur Kosten senken und Umsatz steigern will, hält das auf Dauer nicht, außer vielleicht in zwielichtigen Vertriebsbranchen.
      Serverhardware ist wirklich billig, und ein halbwegs kompetenter Programmierer kann die meisten Programme auf einem einzelnen Server oder einer einzigen virtuellen Maschine bewältigen. Statt 25 Dollar im Monat sollte man 50 Dollar im Monat zahlen und etwas Marge lassen. Trotzdem gibt es keine Garantie, dass diese Firma nicht pleitegeht oder dich als wertvollen Kunden betrachtet; letztlich verlässt man sich darauf, dass das Ganze dank Großkunden profitabel ist.
      Wenn das Geschäft in den USA sitzt, sollte man einen US-Hosting-Anbieter nutzen.

  • Der Rat „Hätte man 6 Monate gewartet, hätte man viele Probleme vermeiden können; Early Adopter finden die Probleme meist zuerst, die später behoben werden“ lässt sich auf alle Systeme anwenden, die Stabilität brauchen.
    Wenn es keine Sicherheitsprobleme gibt, wartet man ein paar Monate oder bleibt ein bis zwei Versionen zurück.

    • GitHub will diese Funktion in dependabot ergänzen: https://github.com/dependabot/dependabot-core/issues/3651
    • Auch in der Natur ist das ein seit Langem erfolgreiches Muster: Ältere Individuen nutzen junge, unerfahrene Individuen als eifrige Testeinheiten.
      Zum Beispiel geben alte Wildschweine im Wald ein Sicherheitssignal, um die Jungen zuerst auf eine wenig vertrauenerweckende Lichtung zu schicken. Technisch gesehen ist das ähnlich wie Blogposts, die eine noch nicht produktionsreife Technologie überhöhen.
    • Ich bin der Autor des Blogposts. Im Großen und Ganzen ist das eine gute Praxis.
      Immerhin ist es ein kleiner Trost, dass unsere Mühen geholfen haben, die eigentliche Ursache schneller offenzulegen.
      Im Artikel habe ich es nicht geschrieben, aber für die Zukunft haben wir auch erwogen, Server entgegenzunehmen und sie ohne echte Kunden-Workloads etwa einen Monat lang im Leerlauf zu lassen. Das kostet mehr, kann aber helfen, latente Probleme zu finden, ohne Nutzer zu beeinträchtigen. In unserem Fall begannen die Crashes 3 Wochen nach dem Deployment des ersten AX162-Servers, also braucht es mindestens einen Monat, vielleicht sogar eine längere Pufferzeit.
    • Das hängt vom System ab. Kelly Johnson von Skunk Works nannte als eine der wichtigsten Regeln, dass das aktuelle Inspektionssystem dem Sinn der militärischen Anforderungen entspricht und auch für neue Projekte verwendet werden sollte; außerdem sollten mehr grundlegende Inspektionsverantwortung an Subunternehmer und Anbieter abgegeben und Inspektionen nicht doppelt durchgeführt werden.
      Allerdings wird es für Ubicloud wohl das erste und letzte Mal gewesen sein, ein neues Modell oder eine neue Einkaufstranche ohne Burn-in zu verwenden. Ich arbeite dort und bin Mitgründer.

  • Auch Dell hat gelegentlich solche Probleme. Als wir die erste Charge eines früheren Servers erhielten, verlor der Server nach einiger Zeit Geräte am hinteren I/O-Bereich, sodass der hintere I/O-Abschnitt des Mainboards ersetzt werden musste.
    Zum Beispiel verschwanden der Ethernet-Controller, iDRAC und gelegentlich sogar das BIOS. Nachdem dieses Problem beseitigt war, liefen sie fast 10 Jahre lang gut.
    Kürzlich haben wir sie außer Betrieb genommen, weil alles von RAID-Karten bis zu Spannungsreglern verschlissen war. Es ist eine sehr ernüchternde Erfahrung, einen ansonsten problemlos laufenden Server wegen einer Konfigurationsänderung neu zu starten und dann die RAID-Karte endgültig zu verlieren, weil Elektromigration interne Leiterbahnen des RAID-Prozessors erodiert hat.

    • Dell hat wirklich viele Probleme. Eine einzelne fehlerhafte Mini-Platine für die Front-LEDs kann verhindern, dass ein Server überhaupt bootet oder läuft, und in diesem Fall ist auch DRAC tot.

  • Hetzner habe die Möglichkeit einer Leistungsbegrenzung weder bestätigt noch dementiert; ich frage mich, was die Folgen einer Leistungsbegrenzung wären.
    Im Artikel heißt es, die Hardware könne dadurch schneller altern, aber ich verstehe nicht, warum.
    Wenn man Hetzners ausbleibende Antwort und die Messwerte von UbiCloud betrachtet, scheint es tatsächlich so, als würde die Leistung begrenzt. Wenn nicht, hätten sie es wohl gesagt.

    • Ich habe Ähnliches schon bei mehreren Cloud-Angeboten gesehen: Der CPU-Scaling-Governor ist auf einen „grünen“ Wert gesetzt, der nur dem Cloud-Anbieter nützt, den Nutzern aber gar nichts bringt und lediglich die maximale CPU-Leistung deutlich reduziert.
      Prüfen kann man das mit cat /sys/devices/system/cpu/cpu/cpufreq/scaling_governor. Der Wert sollte performance sein.
      Falls nicht, lässt er sich mit echo performance | sudo tee /sys/devices/system/cpu/cpu/cpufreq/scaling_governor setzen. Bei CPU-lastigen Workloads hilft das. Nach einem Reboot wird es zurückgesetzt, daher kann man es etwa per cron/systemd dauerhaft setzen.
      Natürlich sollte man den Scaling-Governor selbst abwägen, wenn man die Stromrechnung direkt bezahlt oder es die eigene Hardware ist. Bei gemieteten Bare-Metal-Servern ist performance aber richtig.

  • Dass ein Rechenzentrumsbetreiber den Stromverbrauch pro Server begrenzt, um innerhalb der Strombeschränkungen mehr Maschinen unterzubringen, und dass dies die Alterung des Mainboards beschleunigen könne, widerspricht meiner Intuition.
    Nach kurzer Recherche schien Leistungsbegrenzung eher die effektive Lebensdauer verschiedener Komponenten zu verlängern.
    Suchergebnisse, die das Gegenteil behaupteten, drehten sich nur darum, dass hohe Betriebstemperaturen beim Thermal Throttling Bauteile wie Kondensatoren schneller altern lassen können. Im Artikel wurden aber mehrere Temperatursensoren betrachtet, und dieser Fall wurde ausdrücklich ausgeschlossen.

    • Bei der Recherche hatte ich ein paar Artikel gefunden, die sagten, dass Leistungsbegrenzung Hardwarealterung verursachen könne, aber die genauen Quellen habe ich jetzt nicht mehr.
      Die Antwort unten hat ein Beispiel geteilt, und beim Suchen sind noch ein paar weitere Quellen aufgetaucht [1], [2].
      Allerdings bin ich kein Elektroniker, daher ist mein Verständnis vielleicht nicht ganz korrekt. Vielleicht lag die Alterung nicht an der Leistungsbegrenzung selbst, sondern an Leistungsschwankungen, oder es gab andere Faktoren.
      [1] https://electronics.stackexchange.com/questions/65837/can-el...
      [2] https://superuser.com/questions/1202062/what-happens-when-ha...
    • Leistung = Spannung × Strom.
      Die Spannung wird vom Stromversorger geliefert, der Strom wird pro Rack überwacht. Die übliche Reaktion in einem Rechenzentrum, wenn ein Stromlimit überschritten wird, ist, dass eine Sicherung auslöst oder mehr Geld verlangt wird.
      Die einzige Möglichkeit, den Stromverbrauch eines Servers zu senken, ist, die CPU zu drosseln. Üblicherweise drosselt man die CPU über das Betriebssystem, wofür Kooperation nötig ist.
      Ich vermute, dass es eventuell auch ohne OS-Beteiligung über einen Lights-out-Baseboard-Controller möglich ist, aber dann würde ich erwarten, dass es in /sys sichtbar ist.
    • Seltsam. Ich habe immer gelesen, dass dauerhaft hohe Leistung und Temperatur Elektronik deutlich schneller altern lassen. Kann das ein Elektroniker erklären?
    • Jedes Rack in einem Rechenzentrum hat ein Leistungsbudget, und in der Praxis ist es eher durch die Wärmemenge begrenzt, die die Klimatisierung aus dem Rechenzentrum abführen kann, als durch die verfügbare elektrische Leistung.
      Trotzdem wird pro Rack begrenzt, damit ein paar Hochleistungsserver nicht einen größeren Bereich des Rechenzentrums lahmlegen.
      Ich weiß nicht genau, wie die Begrenzung umgesetzt wird, aber ein einfacher Schutzschalter wie zu Hause wäre eine naheliegende Lösung. Dann würde beim Auslösen allerdings das Rack stromlos, was das gesamte Rack und mehrere Kunden betrifft, also nicht ideal ist.
      Eine andere Option wäre ein Strom-/Leistungsbegrenzer[0], aber wegen P = U * I kann das noch mehr Probleme verursachen. Die Spannung (U) fällt ab, das ganze System gerät in einen Unterspannungszustand, und es entstehen merkwürdige Glitches. Das ist auch eine gängige Methode, um verschiedene Schutzmechanismen von Chips zu umgehen. Raspberry Pi hat ebenfalls eine Challenge[1] veranstaltet, um solche Bugs zu finden und zu testen, wie widerstandsfähig der Chip gegen Angriffe einschließlich Spannungsangriffe ist.
      [0] - https://en.m.wikipedia.org/wiki/Current_limiting
      [1] - https://www.raspberrypi.com/news/security-through-transparen...
    • Eine Möglichkeit ist, dass die CPU bei niedrigerer Leistungseinstellung weniger heiß wird, die Lüfter deshalb langsamer laufen und andere Komponenten dadurch weniger Luftstrom abbekommen und paradoxerweise heißer werden.
      Die übliche Lösung ist, auch die Temperaturen dieser anderen Komponenten zu überwachen und in den Lüfterregelalgorithmus einfließen zu lassen. Ob das hier tatsächlich passiert ist, weiß ich nicht.

  • Man kann es nicht wissen, aber es könnte auch ein Problem mit Stromversorgung, Signalen oder dem VRM sein.
    Dass die CPU nicht heiß ist, bedeutet nicht, dass nicht etwas anderes auf dem Board außerhalb der Spezifikation läuft und in einen kritischen Fehlerzustand gerät.
    Mainboard-Probleme rund um Stromversorgung und Signale sind fies zu diagnostizieren. Nach außen äußern sie sich in allen möglichen Symptomen, die wie Probleme anderer Komponenten aussehen; meiner Erfahrung nach sind fehlgeschlagene RAM-Initialisierung und zufällige Neustarts sehr häufig. Am Ende tauscht man alles aus, bis man tatsächlich das Mainboard ersetzt.

  • Bei meinem aktuellen AX102 gab es etwas Ähnliches, und es sah so aus, als seien die Crashes durch ein Problem mit der Netzwerkkarte verursacht worden.
    Zum Glück hat der Hetzner-Support den Hardwaretausch gut abgewickelt. Es war ziemlich mühsam, aber eine gute Gelegenheit, Hardware-Fehlersuche zu lernen, und für mich persönlich war es das wert.

    • Bei mir war es genauso. Der AX102 crashte trotz fast keiner Last, in den Logs stand nichts, und er ließ sich auch nicht wieder einschalten.
      Hetzner hat mehrfach nachgesehen, konnte aber nichts finden oder hat nur die CPU-Wärmeleitpaste und PSU-Stecker getauscht. Ich bin auf einen AX162 umgezogen, und bisher ist alles in Ordnung.

  • Kann jemand mit Rechenzentrums-Erfahrung einschätzen, welche kommerzielle Lösung Hetzner hier mit dem Mainboard-Lieferanten gefunden haben könnte?
    Muss man davon ausgehen, dass sie alle Mainboards kostenlos ersetzt bekommen haben, plus Entschädigung?

    • Wenn man Server einer bekannten Marke kauft, bekommt man defekte Hardware definitiv ersetzt.
      Eine Entschädigung gibt es nur, wenn sie vorab ausgehandelt wurde, und in diesem Fall muss man dafür zusätzlich bezahlen. Wahrscheinlich ist es sinnvoller, so etwas wie eine Betriebsunterbrechungsversicherung abzuschließen, statt zu versuchen, Ausfallkosten vom Anbieter ersetzt zu bekommen. Das gilt selbst dann, wenn der Anbieter schuld ist.
      Hetzner ist kein normaler Kunde. Im Rahmen extremer Kostenoptimierung kaufen sie vermutlich die billigsten Komponenten und haben möglicherweise ohne Garantie einen niedrigeren Preis ausgehandelt. Dann hätten sie die Ersatz-Mainboards selbst kaufen müssen.
    • Ich vermute, dass sie diese Stückzahlen von Anfang an sehr günstig bekommen haben. Diese Server wurden anfangs nämlich ohne Einrichtungsgebühr angeboten.
      Das war zur Zeit der Fußball-WM in Deutschland.

  • Dass ein Rechenzentrumsbetreiber wegen Strombeschränkungen den Stromverbrauch pro Server begrenzt und dass dies die Alterung des Mainboards beschleunigen kann, hatte ich zum ersten Mal gehört und fand es ziemlich überraschend.