[Gelöst] ESXi 5.1 freeze, automatischer Neustart möglich?

[PatrizioR]

Hallo zusammen, hab einen ESXi 5.1 bei Hetzner (EX4S im Flexi Pack mit IP Subnetz).

Es passiert ab und zu (leider in den letzten Tagen häufiger), dass ich den ESXi nicht mehr erreichen kann. Damit auch alle VMs nicht mehr (kein Netzwerkkontakt mehr). Ich nehme an, dass der ESXi in einen Freeze läuft bzw. Fehler und deshalb nicht mehr arbeiten kann.

Hab in den Logs der VMs den hier bekannten Fehler
Error in the RPC receive loop: RpcIn: Unable to send.
gefunden und direkt darauf das abschalten der VMs (laut Event log) (Hier speziell Windows Server 2012).

Hab schon die Sache mit dem Logfix gemacht:
[logging]
vmusr.level = error
und das abschalten der Protokollierung für die VMs.

Meine generelle Frage ist folgende:
Um das Problem erstmal soweit Herr zu werden, dass wenigstens der ESXi bei einem Fehler automatisch neu startet, müsste ich wissen ob es möglich ist, dem ESXi bei zu bringen bei einem Fehler automatisch neu zu starten. Gibt es da Möglichkeiten?

Ich weiß dass das insgesamt keine Lösung ist, jedoch immerhin ist dann sichergestellt, dass der Server wieder hochfährt.

Werde mir gleich einmal anschauen ob ich aus dem ESXi ein Log hervorzaubern kann bezüglich des Absturzes.

Leider hab ich keinen Zugriff auf die Monitorausgabe sonst würde ich natürlich einen Screenshot beilegen.

Danke für jegliche Hilfe schon einmal.

LG
Patrizio

[Dayworker]

Ich würd mich mal mit Hetzner in Kontakt setzen und den Fehler ergründen.
Selbst wenn du ein Reboot irgendwie gedeichselt bekommst, machen das deine VMs nicht lange mit. Spätestens wenn eine VM einen Schreibzugriff tätigt oder auf deinem W2k12 eine DB läuft und der ESXi dann aussteigt, ist dir mit einer Watchdog-Schaltung nur begrenzt geholfen, da man nach einem solchen Fall erstmal alle Datenträger und vor allem die DB auf Datenkonsistenz überprüfen muß.

Es ist auch höchst ungeschickt, irgendwelche Protokollierung abzuschalten. Das schränkt die Fehlerauswertung extrem ein.



[add]
Falls http://www.hetzner.de/hosting/produkte_rootserver/ex4s deinen Server beschreiben sollte, wünsche ich dir viel Glück mit dieser Auswahl.
Zum Einsatz eines Core_i7-2600 ohne ECC-Support als dauerlaufende VT-CPU mit ihrem Maximalausbau auf 32GB RAM sage ich mal nichts weiter, ausser das an der falschen Stelle gespart wurde. Mit etwas Glück ist bei dir nur ein RAM-Riegel defekt...

[PatrizioR]

@Dayworker

Der Server ist nicht produktiv im Einsatz, er dient mir eher zum Testen. Daher ist es nicht schlimm wenn er ausfällt. Daher ist der EX4S vollkommen ausreichend.

(Und du wirst mir zustimmen das ECC auch nur bis zu einem gewissen Grad korrigieren kann).

Danke auf jeden Fall für den Tipp. Werde das mal anschauen. Glaube jedoch nicht dass es am RAM liegt. Hatte den Server vorher mit ESXi 5.0 am Laufen (für 2 Wochen) und keinerlei Probleme gehabt.

LG
Patrizio

[Dayworker]

Mir gehts bei ECC eigentlich weniger ums korrigieren als der Tatsache, daß damit auch Zweibit-Fehler erkannt werden können und dann ist mir ein abschaltendes System lieber, als mit falschen Daten zu hantieren.
Da bei der VT die Gäste immer im gesamten RAM umherschwirren, fallen hier Speicherfehler auch besonders schnell auf. Auch wenn du mit der Version 5.0 bis dato keine Probleme hattest, um das speichertechnisch beurteilen zu können, reichen deine 2 Wochen mit reiner ESXi-Nutzung nicht aus, könntest du unabhängig von deiner momentan laufenden Version auch jetzt noch fehlerhaften Speicher an Bord haben. Über den nutzlosen Einsatz irgendwelcher Memtest-Läufe habe ich hier auch schon zur Genüge geschrieben und auch wesentlich bessere Tools benannt.
Es wäre aber auch genauso gut möglich, daß der 5.1er eine bzw eine neue bzw eine andere Methode zur Adressverwürfelung (Adress Space Layout Randomisation = ASLR) mitbringt, die noch weiterer Anpassung bedarf. Um aber den Fehler isolieren zu können, mußt du soweit wie möglich die Gleichungvariablen auf ein Minimum verringern.
Auch nicht vergessen werden darf dabei, daß einige Intel-Chipsätze anscheinend in Kombination mit deiner CPU und einer e1000-Nic zu Fehlern neigen. Wir hatten dazu bereits zwei Meldungen im Forum gehabt.

[PatrizioR]

Der CPU den Hetzner hier verbaut hat ist nicht der i7-2600 sondern der neue Ivy Bridge Prozessor i7-3770 verbaut. (Nur um das mit der CPU zunächst erstmal nach hinten zu stellen).

Bei den besseren Tools würde ich gerne wissen welche das wären. Ich erinnere mich an ein Gespräch mit einem DELL Mitarbeiter der mir ein Tool bereit stellte (ging damals um DDR2 ECC Ram für einen Hardware RAID Controller). Leider habe ich vergessen wie es hieß.

Werde versuchen die Fehlerquelle ausfindig zu machen (Wird nur durch Ausschlussprinzip für die meisten Komponenten gehen). Im Moment läuft der ESXi ohne Probleme. Evtl. haben die vorher genannten Dinge schon ausgereicht.

Danke dir übrigens für deine Antworten.

[Dayworker]

Welche CPU der Reihen Core_i5 oder i7 verbaut ist, spielt für ECC-Support keine Rolle. Den gibts nur für die Reihen Celeron, Pentium, Core_i3 und natürlich allen mir bekannten Xeons.
Falls Hetzner nicht gerade sein HW-Angebot umgestellt haben sollte, lassen die jetzt verbaute IB-CPU nur die Schlußfolgerung eines älteren Chipsatzes mit per Bios-Update hinzugefügtem IB-Support zu. Das würde das beschriebene Problem also nicht lösen.

Um RAM, CPU und im Endeffekt auch Wirksamkeit der Kühlung maximal zu testen, empfehle ich Programme wie Prime95 oder auch das leichter gestrickte Orthos Multiprime zu nehmen. Bei Primezahlen gibt es kein 'vielleicht' sondern nur 'ja' oder 'nein', sämtliche Abweichungen davon sind also immer ein Fehler. Angesichts der Tatsache, daß Boxed-CPUs ESD-technisch immer besser als jeder RAM-Riegel (vom blanken Riegeln in Blisterfolie über Fingerabdrücke auf den Kontaktflächen bis mit Packpapier an die Paketinnenseite geklebte Riegel habe ich inzwischen alles gesehen) verpackt sind, fallen RAM-Riegel aufgrund dieser ESD-Vorschädigungen weit häufiger und vor allem wesentlich früher aus. Die in der Zwischenzeit gestiegenen RAM-Kapazitäten sorgen zusammen mit dem ebenfalls vergrösserten RAM-Bedarf bei gleichgebliebener Speicherfehlerrate für eine höhere Fehlerhäufigkeit.

Um die Auswirkungen solcher Fehlerraten mal erneut zu verdeutlichen. Für ein System der Top500-Liste ist bekannt, daß es vor einiger Zeit einen weitaus höheren Linpack-Wert hätte erreichen können, wenn nicht alle 17min ( ) ein RAM-Fehler aufgetreten wäre. In diesem Zusammenhang wird auch klar, weshalb nVidia für den GPGPU-Einsatz auch ECC in seine Quadro- und Tesla-Reihen aufgenommen hatte. Für längerandauernde, doppeltgenaue Berechnungen, und nichts anderes sind alle Programme und im Endeffekt somit auch jede VM, sind toggelnde Bits ein No-Go.

[sapro]

Ich würde eher auf eine "Unverträglichkeit" des neuen Hypervisors ESXi 5.1 tippen.

Ich selbst habe einen EX4S der ersten Stunde am laufen - also seit über 6 Monaten im Dauerbetrieb. Bisher ohne irgendwelche Ausfälle oder Anomalien. Bei mir ist übrigens die i7-2600 CPU verbaut - offensichtlich gab es hier ein Hardwareupgrade. Ob das jetzt gut ist, sei dahingestellt.

Ich selbst bin am überlegen ob ich auf die 5.1er upgrade. Werde aber nach den Erfahrungen zuerst mal auf dem aktuellen Patch der 5.0er bleiben. Läuft ja alles Prima bis auf ein paar Ereignisse zur HDD E/A-Latzen, aber das ist bei den verbauten Platten im Dauerbetrieb auch nicht verwunderlich

Daher meine Empfehlung. Zurück zur 5.0er und einfach mal abwarten.

Ich für mein Fall habe z.B. eine Supportanfrage an Hetzner gestellt, ob die Hardware vom EX4S für den ESXi 5.1 ausreichend ist und stabil läuft. Mal schauen, was als Antwort kommt.

[continuum]

Daher meine Empfehlung. Zurück zur 5.0er und einfach mal abwarten.

Kann ich nur unterschreiben ...

[sapro]

Hier die Antwort von Hetzner zu meiner Anfrage:

ESXi5.1 haben wir nicht auf unseren Servern getestet, daher können wir leider
nicht garantieren ob dies voll unterstützt wird.

[Tschoergez]

gut zu wissen
Dann warte ich auch mal mit dem Upgrade...

[PatrizioR]

So habe letzte Woche nachdem mich die Abstürze doch geärgert haben den EX4S neu bestellt. Diesmal aber mit Hardware RAID und einer KVM so dass ich jederzeit auf die Bildschirmausgabe schauen kann.

Bin im Moment dabei alle VMs zu transferieren was leider etwas länger dauert.

Sobald alles steht und länger läuft gebe ich mal Auskunft wie die 5.1 läuft und im Falle eines Absturzes kann ich auch berichten welche Fehlermeldung kommt.

LG
Patrizio

[sapro]

Prima. Schreibst Du auch bei Deiner Antwort - wenn der EX4S stabil läuft - welche Hardware verbaut wurde, es gibt scheinbar bereits unterschiedliche EX4S'er

[PatrizioR]

So nachdem wirklich einige Wochen Ruhe war:
neuer EX4S + KVM + RAID Controller heute ein neuer Absturz, nun weiss ich zumindest auch welche Maschine dafür verantwortlich ist KVM sei dank.

Exception 14 heißt es (siehe Anhang)

Die weißen Felder bezeichnen den Maschinennamen, also einfach ignorieren.

Werde nun erstmal Google bemühen und mal schauen was da für eine Lösung zu existiert.

Vielleicht noch der Umstand bei dem es passiert ist: Starke Netzwerklast (Income)

LG
Patrizio

P.S. da ich keine Anhänge angängen darf:
http://imageshack.us/photo/my-images/708/vmware02.png/

[Dayworker]

Exception 14 hatten wir hier im Forum auch schon öfter mal gehabt und VMware hat dazu auch einen KB-Eintrag veröffentlicht.

[PatrizioR]

Hier die Lösung um den ESXi 5.1 automatisch Neustarten zu lassen:

Per SSH anmelden, und folgenden Befehl absetzen

esxcfg-advcfg -s X /Misc/BlueScreenTimeout

Wobei X die Anzahl an Sekunden sind die gewartet werden sollen.

Bsp.:
esxcfg-advcfg -s 5 /Misc/BlueScreenTimeout

Um fünf Sekunden zu warten nach einem Absturz, bis das System neugestartet wird.

Danke an diese Quelle:
http://sparrowangelstechnology.blogspot ... start.html

[wolf_hh]

Hallo,
ich muss das Thema nochmal eröffnen - Sorry. Habe exakt den gleichen Server (Bei Hetzner, Modell, Prozessor) und - natürlich - auch das Problem!
Manchmal freezt der ESXi, manchmal PSOD mit Exception 14. Wie hast Du das Problem nun endgültig gelöst?


Danke und Gruß!

[Dayworker]

Verlinke doch bitte mal deinen PSOD.

[wolf_hh]

Moin,
sorry, hab leider keine Mail über Deinen Post bekommen.
Hier ein Screenshot. Der PSOD war einmal und zweimal ein Freeze...

Echt ärgerlich. Woran liegt das?


Danke schonmal


http://wolfst.webcomsult.de/cim/vmware.png

[Dayworker]

"TLB invalidate" klingt nicht gut. Da der TLB in der CPU sitzt, hast du entweder einen Bug gefunden, was die Frage nach der genauen CPU-HW ergibt, oder die CPU ist defekt.
Poste mal bitte mehr Details zu deiner HW.

[wolf_hh]

Hey,
super das Du dafür Zeit hast...

Im Grund ist es dieses System:
http://www.hetzner.de/hosting/produkte_rootserver/ex4

Nur mit Intel® Core™ i7-3770 Quad-Core Prozessor @3.40 GHz

Du meinst das liegt an der CPU?

[Dayworker]

Vermutlich, allerdings kommt bei erneuter Betrachtung auch ein Bios/Firmware-Fehler oder auch nur ein ausgefallener CPU-Lüfter sprich CPU-Temp zu hoch in Betracht...
Reine Desktop-HW ist halt manchmal problematisch, wenn man sie mit einem Server-OS und in diesem Fall sogar noch mit einem professionellen Virtualisierungssystem unter Druck setzt. Desktop-HW wird halt nicht für den Dauerlauf sondern üblichen 9-til-5-Office-Betrieb konzipiert. Daher kann der 24/7-Betrieb mit Desktop-HW wie bei meinem Dell-Altsystem Dimension E520 auch fast 7 Jahre unter Volllast beim "Distributed Computing" gutgehen, muß es aber nicht und ist zudem von einigen Bedingungen hinsichtlich Pflege wie jährlicher Wechsel der Kühlpaste, spätestens quartalsweise Reinigung des PC-Gehäuses etc abhängig.

[wolf_hh]

EDIT:
Ich hab nochmal die Coredumps hochgeladen.
Also 2x PSOD mit TLB. Ich lass nun eine Sichtkontrolle machen (vielleicht ist der Lüfter nicht dran.) Danach wird die HW getauscht.
%%

Okay.
Ich habe schon Deine Kommentare zu EEC und Server-Hardware gelesen. Momentan laufen zwei andere Maschinen mit genau diesen HW-Daten einwandfrei. Wir wechseln allerdings nach zwei Jahren immer wieder den Host.

Ich werd mal dem Lüfter Prob aufn Grund gehen... Das klingt plausibel, vorallem mit dem Freeze...
Ich meine auch, dass die Server unter Volllast standen...

Was hälst Du eigentlich von diesen Geräten:
http://www.hetzner.de/hosting/produkte_rootserver/ex6


Vielen Dank!

[Dayworker]

Ob ihr nun alle 2 Jahre den Host wechselt oder nicht, spielt für dessen Zuverlässigkeit bzw genauer dessen Datenintegrität keine Rolle. Dazu haben sich die Grössen von RAM oder Datenträgern weit schneller entwickelt, als die Fehlerraten sich verändert haben. Im Allgemeinen sind die Fehlerraten sogar nur gleich geblieben.
Dazu mal ein Rechenbeispiel anhand einer normalen SATA-HDD. Diese werden meist mit einer BER von 10^14 angegeben. Das entspricht einem Fehler auf 100,000,000,000,000 Billion (D) bzw Trillion (US) Bits oder kurz ~11.37 Terabyte. Das klingt erstmal nach unendlichen Weiten, ist aber wiederum doch nicht so weit entfernt, wenn man die momentan maximal verkauften Datenträgergrössen von 4 Terabyte in Betracht zieht und für Ende des Jahres sind bereits Laufwerke mit 5 Terabyte avisiert. Da sich aber niemand einen so grossen Datenträger zulegt, wenn er diesen nicht in absehbarer Zeit auch zu nutzen gedenkt, und man meistens auch kein Geld sinnlos verschenken will, sind diese ~11.37 TB dann doch recht zügig erreicht.



Kommen wir mal zu beiden Hetzner-Angeboten:
Beide haben in dieser Config nur ein SW-Raid1 (auch als Fake-Raid bekannt, da die Raid-Funktionalität ausschließlich per Treiber abgebildet wird), ohne HW-Controller sieht der ESXi dadurch nur zwei Einzellaufwerke und die Funktion "VNC-Installation" ersetzt vermutlich auch kein BMC.
Da der ESXi von Hause aus keine NAT-Funktionalität mitbringt, bist du auf eine entsprechende VM angewiesen, die die VM-IPs auf die eine externe IPv4-Adresse umsetzt. Wenn du mehrere VMs von aussen unter derselben Portnummer erreichbar machen willst, reicht dir die eine extrerne IPv4-Adresse also bei weitem nicht aus. Wie der ESXi zu IPv6 steht, kann ich dir leider nicht sagen.
In jedem Fall würe ich aber das vmk-Netzwerk des ESXi immer von allen sonstigen Netzwerken trennen, das impliziert zumindest eine zweite Nic, da du dich ansonsten selbst vom Zugriff auf den Host behinderst, wenn deine Gäste starken Traffic verzeichnen.
Bei der ganzen ESXi-Geschichte auf einem Root-Server sollte man auch im Hinterkopf haben, daß ohne weitere Vorkehrungen dessen Console ziemlich ungeschützt im Web steht. Angriffe darauf sind also nur eine Frage der Zeit. Selbst eine kleine HW-Firewall ist als der ESXi-HW vorgeschaltetes Gerät jedem SW-Produkt überlegen.

Alles in allem betrachtet, könnte man bei den sich durch meine Einwände ergebenden Aufpreise die HW auch gleich bei sich vor Ort hinstellen. Die 30tägige Kündigungsfrist ohne Mindestlaufzeit nutzt ihr ja eh nicht und von daher laufen die verlinkten, jetzigen Angebote von 49 bzw 69 Euro pro Monat nach einem Jahr bereits auf 588 bzw 828 Euro raus. Wenn ich dagegen den zugegebenermaßen nicht ganz optimalen Einstiegsserver in meiner Sig nehme (nur lahmer H200-Controller ohne WB-Cache, nur 8GB RAM, nur eine Nic) und dessen Kaufpreis von unter 700 Euro in Relation setze, bin ich bereits im zweiten Jahr günstiger (EX4) bzw sogar deutlich günstiger (EX6). Momentan werden mir mit zwei Kernen unter Volllast laut Energiemeßgerät 70W oder 1.68kWh inklu mitlaufender FritzBox angezeigt. Die zusätzlichen monatlichen Stromkosten kannst du dir selbst ausrechnen.
Wenn ich also überhaupt über die Auslagerung von HW nachdenke, würde ich solche Root-Server nur kurzzeitig als Verstärkung der vorhandenen Kapazitäten in Betrieb nehmen. Sowas kann zum Beispiel erforderlich werden, wenn man saisonale Überhänge abfedern muß und die Investition in die eigene HW-Aufrüstung mit Verlusten im Unterhalt und der allgemeinen HW-Auslastung verbunden ist.

[wolf_hh]

Hi nochmal,
erstmal das wichtigste vorweg: Ich habe ein BIOS-Update durchführen lassen und seit dem keinen PSODs mehr gehabt.
Die Wahrscheinlichkeit ist sehr hoch, dass das Problem damit behoben ist. Wichtige Erkenntnis: Auch die BIOS-Firmware sollte als Fehlerquelle in Betracht gezogen werden. Bei Hetzner war das Update übrigens mit einem einfachen Supportticket veranlasst.

Jetzt noch kurz zu Daywalker:
Mit EEC Speicher hast du grundsätzlich natürlich vollkommen Recht.
Allerdings verstehe ich das Festplatten Beispiel nicht. Wo ist dort der Zusammenhang zu Speicherkorrekturverfahren?
Bzgl. Datenintegrität hat Du auch vollkommen Recht, allerdings muss man hier die Speichernutzung differenzierter betrachten. Wird der Speicher vorwiegend für Daten verwendet, beispielsweise bei einer Datenbank, ist die Datenintigrität wesentlich gefährdeter, als bei Anwendungsnutzung. Beispiel hier: Terminal Server, bei dem ein Großteil des Speichers für Anwendungen verwendet wird. (Stichwort: Von-Neumann-Architektur) Dabei macht sich ein Speicherfehler als Absturz / Bluescreen (PAGE_FAULT_IN_NON_PAGED_AREA) bemerkbar.

Noch kurz (3*kurz = 1* lang zum Platform-as-a-Service-Gedanken:
Natürlich ist die HW entsprechend ausgestattet. RAID-Controller ist drin, Firewall-VM läuft. Kein Zugriff von außen möglich.
Entscheidende Vorteile: 1. Rechenzentrum mit 100 Mbit Up- & Downstream. Garantierte Verfügbarkeiten und - vorallem - kostenloser Hardware-Tausch. Wir haben auch schonmal den ganzen Server tauschen lassen, an Sylvester, innerhalb von 30 Minuten. Klar im 2. Jahr bist Du günstiger... Wenn Dein Raidcontroller aber abraucht, ist der Server 1 Woche down. Wir versenden grad mal eine Mail und das Ding ist getauscht (insbesondere exakt das gleiche Gerät).
Letztlich hängt es von den Anforderungen ab. Wir / unsere Kunden haben solche Anforderungen, Du / Deine Kunden sicherlich andere.

Trotzdem danke für Deine Einwände (die eigenen Infrastruktur zu hinterfragen lohnt sich ja immer mal) und Deine Engagement in diesem Forum.

Gruß

[Dayworker]

Das Festplattenbeispiel war nur dazu da, die Bedeutung von angegebene Bitfehlerraten einiger HW verständlich zu machen und wie man Angaben zu Bitfehlern in der IT allgemein mal gegenrechnen kann. Die Festplatte habe ich auch gewählt, da sich deren Fehlerraten je nach Anschluß (SATA, NL-SAS und SAS) nicht bzw kaum verändert haben und die Daten somit als stabil gelten können. Das einige HDD-Hersteller inzwischen für ihre SATA-Laufwerke auch eine BER von 10^15 angeben, sei hier nur der Vollständigkeit erwähnt, das Gros ist aber weiterhin bei 10^14 geblieben.


Bezüglich der Datenintegrität habe ich nur die Studie: DRAM-Fehler sind weit häufiger als bisher bekannt von 2009 gefunden. In dieser wird aber nur DDR1-, DDR2- und FB-RAM betrachtet.
Einige Seiten dieser Zeit (2009) gehen als Richtwert aber von 1 umkippendes Bit pro 1GB Ram pro 24h aus. Wenn das umgekippte Bit in einem ungenutzten Bereich auftritt, kann das natürlich keine Auswirkungen auf laufende Programme haben. Zum einen lassen sich solche Bitfehler aber nur feststellen, wenn man das HW-technisch verifizieren kann und das ist ohne ECC oder einen seiner Nachfolger nicht möglich und zum anderen läßt sich auch aufgrund der Adressverwürfelung (ASLR) vieler Betriebssysteme nicht mehr erkennen, welche Speicherbereiche ungenutzt sein werden.
Deiner differenzierten Betrachtung zwischen Daten einer Datenbank und der Anwendungsnutzung kann ich, nicht nur in der Virtualisierung betrachtet, nicht zustimmen. Eine Datenbank ist im Grunde auch nur eine Anwendung, mit einem anderen Einsatzgebiet als das Rechnen in einer Tabellenkalkulation. Jene verrechnet sich vielleicht nur oder stürzt ab, das Ergebnis ist aber datenintegritätstechnisch derselbe Müll. Eine VM ist ebenfalls eine Anwendung und wenn diese einen Bitfehler hat, pflanzt sich der Fehler zwangsweise in der VM fort.


Beim PaaS-Gedanken sind einige Punkte natürlich aus deiner Sicht wie der 100MBit Up- & Downstream, die Variabilität bei sich ändernden Leistungsanforderungen oder der kostenlose HW-Tausch einfacher. Aber hinterfrage doch mal die garantierten Verfügbarkeiten und rechne diese runter. 99% Verfügbarkeit findest du an jeder Ecke und ergeben für ein System, das 24 Stunden am Tag, an 365 Kalendertagen (24 × 365) zur Verfügung steht (8760 Stunden) volle 87,6 Stunden bzw 5256 Minuten an zulässiger Ausfallzeit. Da in meinem Serverpaket eigentlich auch Techniker am nächsten Arbeitstag angekreuzt war, bleibt mir selbst mit einem WE dazwischen immer noch die Verfügbarkeit erhalten. Interessant wird es jedoch erst bei Hochverfügbaren Systemen und davon spricht man ab 99,99%, wobei jede weitere 9 hinter dem Komma ebenfalls zwei weitere Nullen hinter dem Komma auf der dazu nötigen HW-Investition bedeuten und diese läßt sich auch für Hetzner mit Mengenrabatt nicht zu den dort aufgerufenen Preisen erreichen.
Wie du bereits sagtest, es hängt von den einzelnen Anforderungen ab und manchmal kommt es wirklich nur drauf an, daß man eine Leistung unproblematisch mieten bzw leasen kann und sich dafür nicht mit ansonsten ungenutzter Mietfläche belasten muß.