Mit Steal Time erkennen, ob Public-Cloud-EC2 überbucht ist
Zwei Messlatten decken die Wahrheit über Overselling auf
Hohe Steal Time weist auf CPU-Überbelegung hin; kombiniert mit Cache-Einbruch und Prämienrate lässt sich der Nachweis für die Durchsetzung von Ansprüchen führen.
Zwei Maßstäbe für Überverkauf
Um zu beurteilen, ob eine öffentliche Cloud-EC2-Instanz überverkauft ist, sollte man sich nicht nur die CPU-Auslastung ansehen, denn Leerlauf in der VM bedeutet nicht, dass der physische Host nicht ausgelastet ist. Der erste Maßstab ist Steal Time (steal%). Er zeigt dir direkt: Die CPU-Zeit, die dir zusteht, wird vom Hypervisor heimlich an einen lauten Nachbarn vergeben. Wenn steal% kontinuierlich über 10% liegt, kann man grundsätzlich vermuten, dass der Host überverkauft ist.
Aber nur auf Steal zu schauen reicht nicht aus – einige Instanztypen (wie die AWS t-Serie) haben einen CPU-Credit-Mechanismus; ein hoher Steal-Wert während eines Bursts könnte einfach bedeuten, dass die Credits aufgebraucht sind. Also kommt der zweite Maßstab ins Spiel: Disk-Cache-Abbruch. Ein überverkaufter Host bewältigt oft gleichzeitig viele E/A-Anfragen. Wenn du mit fio zufällige Lesevorgänge testest, kann die Trefferquote des Seiten-Caches oder die Latenz einen abrupten Abfall verzeichnen, was zeitlich eng mit dem CPU-Steal korreliert. Nur wenn beide Maßstäbe einander bestätigen, entsteht ein vollständiges Beweisbild.
Möchtest du schnell mit der Erkennung loslegen? Wir haben bereits ein Skript zur Erkennung von Überverkauf bei Cloud-Servern zusammengestellt, das direkt Steal- und Cache-Kennzahlen ausgibt und dir hilft, nicht vor dem Kauf in eine Falle zu tappen.
Praxistest und Beweissicherung
Wir führen einen Vergleichstest mit dem neuesten veröffentlichten Alibaba Cloud ECS g9i und AWS EC2 m7i durch. Das Lastskript ist festgelegt: stress-ng --cpu 4 --timeout 300, gleichzeitig wird mit mpstat alle 5 Sekunden der steal% abgetastet; zusätzlich führen wir mit fio 4K-Zufallslesungen durch und zeichnen die IOPS und die p99-Latenz auf.
# CPU steal 采样
mpstat -P ALL 5 > steal.log &
# 磁盘 cache 断崖测试
fio --name=cachetest --rw=randread --bs=4k --size=1G --runtime=120 --iodepth=32Im Test erreichte der g9i während der Hauptverkehrszeiten am Tag einen durchschnittlichen steal von 12,4 %, mit einem Spitzenwert von 18,1 %. Gleichzeitig sprang die p99-Latenz von fio von 0,8 ms auf 12 ms, was einen deutlichen Cache-Abbruch zeigt. Im gleichen Zeitraum blieb der steal des m7i stabil unter 2 %, und die Latenz blieb glatt. Hinweis: Bei der t-Serie, einer Low-End-Burst-Instanz, ist es normal, dass der steal gelegentlich über 10 % liegt, aber wenn die rechenoptimierten Typen wie die m-Serie und g9i dauerhaft diesen Wert überschreiten, ist das ein harter Beweis für Überverkauf.
Wichtige Punkte für die Beweissicherung: Zeichnen Sie den Zeitstempel jeder Abtastung, die Instanz-ID und die Image-Version auf und erfassen Sie die Rohdaten von CloudWatch / Cloud Monitoring. Diese Protokolle und Screenshots sind das Kernmaterial für spätere Tickets.
Aufschlag und Durchsetzung von Ansprüchen
Das Schwierigste am Überverkauf zu erkennen ist: Du zahlst einen Aufschlag, bekommst aber nur unvollständige Rechenleistung. Aus FinOps-Sicht ist die tatsächliche Wirtschaftlichkeit = Preis ÷ effektive CPU-Zeit. Die effektive Zeit kann mit der Formel geschätzt werden: Verfügbare Kernstunden = vCPU-Anzahl × (1 - durchschnittlicher steal%) × Dauer.
Beispiel: Die g9i kostet 1,2 Yuan/Stunde (4 vCPU). Bei einem durchschnittlichen steal von 15 % beträgt die tatsächlich verfügbare Kernstunden nur 3,4 vCPU·h, was die Kosten pro effektivem vCPU um 17,6 % erhöht. Im Vergleich zur gleichwertigen m7i ohne Überverkauf wird der Aufschlag durch die „Überverkaufssteuer“ umgekehrt – das bedeutet oft, dass du mehr Geld für einen schlechteren Service zahlst.
Nach der Beweissicherung ist die Durchsetzung von Ansprüchen nicht nur eine Beschwerde über „Ruckeln“. Erstelle ein PDF mit: Zeitreihendiagramm des steal%, fio-Ausgabe des Cache-Abbruchs, Vergleichstabelle mit anderen Instanzen gleicher Spezifikation sowie der Berechnung des Aufschlags. Reiche ein Ticket ein und fordere ausdrücklich „Reduzierung der Konfiguration oder Rückerstattung der Differenz basierend auf der tatsächlich gemessenen effektiven Rechenleistung“. Alibaba Cloud und AWS erkennen Überverkauf normalerweise nicht an, aber angesichts harter Daten bieten sie Gutscheine oder Upgrade-Kompensationen mit der Begründung „Ressourcenkonkurrenz auf dem Host“ an. Bevor du das nächste Mal eine Cloud-Instanz kaufst, miss mit zwei Maßstäben, damit dein Aufpreis nicht für überverkaufte Einheiten bezahlt wird.
FAQ
Wie erkennt man mit Steal Time, ob EC2 überbucht ist?
Führen Sie eine Arbeitslast aus, die die CPU dauerhaft auslastet, und beobachten Sie den Steal-Wert; wenn er über 5 % liegt, ist das ein Zeichen für Überbelegung.
Welche Leistungsprobleme verursacht Overselling?
CPU-Wettbewerb führt zu Leistungsschwankungen und erhöhter Latenz, besonders zu Spitzenzeiten.
Wie sichert man Beweise für Overselling auf einer Public Cloud?
Dokumentieren Sie die Steal-Kurve und den Cache-Abriss, speichern Sie Monitoring-Screenshots und Ticket-Verläufe und exportieren Sie sie als PDF zur Archivierung.
Wie spiegelt die Prämienrate die Wirtschaftlichkeit bei Overselling wider?
Vergleichen Sie den Leistungsverlust mit dem Rabatt. Wenn Steal hoch ist und der Rabatt gering, ist die Wirtschaftlichkeit schlecht; Sie können eine Kompensation verlangen.
Wie reicht man ein Support-Ticket zu Overselling-Problemen ein?
Fügen Sie Nachweise für Steal und Cache-Anomalien sowie eine PDF bei und verlangen Sie eine Herabstufung oder Rückerstattung; bei Bedarf eine Beschwerde einreichen.