Einheit 2.4: Kostenarchitektur und FinOps

Einführung

Die Cloud-Kosten bei IONOS sind kein Abrechnungsproblem, das nachträglich gelöst wird, sondern ein architektonisches Merkmal, das bereits bei der Entwurfungsphase entschieden wird, wenn Sie eine Compute-Klasse, eine Speicherstufe, eine Skalierungsstrategie und eine Verpflichtungsfrist wählen. Jedes davon ist ein Hebel, und sie unterscheiden sich enorm in ihrer Größe: Die Wahl der Compute-Konkurrenz kann die Rechnung mehr beeinflussen als alle Dashboard-Anpassungen zusammen. FinOps ist hier daher hauptsächlich Architektur, mit einer dünnen operativen Schicht für die Zuweisung und Warnung darüber. Diese Einheit behandelt die Hebel in der Reihenfolge ihrer Auswirkung, erläutert, wie Sparpläne den Ausgaben korrekt zugeordnet werden, und endet mit dem Aufbau des einzigen gut dokumentierten Schutzes, einer Kostenvorwarnung, in dem Data Center Designer.

1. Rechenressourcen-Konkurrenz: Der erste Kostenschalter

Die größte einzelne Kostentscheidung ist, wie ein Workload physische CPU teilt. Compute Engine bietet zwei CPU-Nutzungsklassen: Dedicated Core-Server, bei denen der Core exklusiv für die VM ist, und vCPU-Server, bei denen der Core mit anderen Mietern geteilt wird. Geteilte Cores sind billiger und sind korrekt für bursty-, latenztolerante- oder nicht-produktionsbezogene Workloads. Exklusive Cores sind teurer und sind korrekt, wenn die Leistung vorhersehbar sein muss oder wenn die Isolation selbst eine Anforderung ist, was für ein reguliertes Anwesen häufig der Fall ist.

Hier wird eine bewusste Überdimensionierung zu einer gerechtfertigten Kontrollkosten anstelle von Verschwendung. Für FinCorps im Umfang der Regulierung liegende, regulierte Hosts sind Single-Tenancy und vorhersehbare Leistung Compliance- und Risikoeingaben, sodass das Bezahlen für dedizierte Cores (und die Bereitstellung von Reservekapazitäten über dem gemessenen Basiswert) Isolation und Stabilität kauft, die eine geteilte Core-Einsparung untergraben würde. Die Disziplin besteht darin, bewusst zu handeln: Überdimensionieren Sie die Hosts, die Compliance- oder Leistungsverpflichtungen tragen, und verwenden Sie geteilte Cores überall, wo die Workload Konkurrenz toleriert. Beachten Sie auch, dass VM Auto Scaling neue Replikate aus einem Replikate-Vorlagen-Template aus dem Entwurfszeitpunkt erstellt, sodass eine Ebene, die automatisch skaliert werden muss, ihre pro-Replikat-Rechenform und damit ihre pro-Replikat-Kosten zum Entwurfszeitpunkt festgelegt hat, was die Elastizitätsentscheidung in die Kostentscheidung einbezieht.

2. Storage-Tiering zur Zugriffsmuster

Die Speicherkosten werden durch die Zuordnung der Tier zum Zugriffsmuster bestimmt, und die drei Block-Tiers haben wesentlich unterschiedliche Preispunkte. Die veröffentlichten Preise pro GB pro Monat sind:

Zwei Einschränkungen prägen die Wahl über den Preis hinaus. Erstens, die SSD-Leistungsbasis: Sowohl SSD Standard- als auch SSD Premium-Volumes erfordern eine Mindestgröße von 100 GB, um die volle Leistung zu erreichen, sodass ein zu kleines SSD-Volume SSD-Preise zahlt, ohne SSD-Leistung zu liefern, was ein häufiger und vermeidbarer Verschwendung auf Datenbank-Datenträgern ist. Zweitens ist Block Storage nicht der richtige Ort für Massen- oder Archivdaten; Object Storage ist das richtige Tier für Sicherungen, Prüfungsarchiven, Datensätze und kalte Daten, und es ist der Ort, an dem das Object-Lock-Archiv aus Einheit 2.3 gespeichert ist. Das Muster ist, heiße, latenzsensitive Daten auf entsprechend große SSD-Volumes zu legen, Kapazitätsdaten auf HDD und alles, was in Massen oder Archiven gespeichert wird, auf Object Storage.

3. Skalieren nach oben versus Cache-basiertes Skalieren für die Datenebene

Die Datenebene hat eine besondere Kostenstruktur, da die Plattform keine Lese-Replikate (Einheit 1.3 und Modul 5) hat. Die zwei Möglichkeiten, um mit der zunehmenden Lesebelastung umzugehen, haben sehr unterschiedliche Ökonomien. Das Skalieren nach oben bedeutet, ein größeres Datenbank-Instanz zu kaufen, was einen vorhersehbaren, immer aktivierten Kostenanstieg verursacht und schließlich an Grenzen stößt. Das Skalieren der Lesevorgänge bedeutet, einen In-Memory-Cache vor der relationalen Ebene zu platzieren und den Lese-Datenverkehr dort aufzunehmen, was in der Regel viel günstiger pro serviertem Lesevorgang ist und die Datenbank vor einer Überdimensionierung schützt, um rein Lese-Spitzen zu bewältigen. Für die meisten leseintensiven FinCorp-Workloads kostet eine richtig dimensionierte Datenbank plus eine Cache-Ebene weniger als eine permanent skalierte Datenbank und ist auch der einzige horizontale Lese-Skalierpfad, den die Plattform bietet. Die Kostenregel lautet, die Datenbank für ihre Schreib- und Arbeitsmenge zu dimensionieren und das Wachstum der Lesevorgänge durch den Cache und nicht durch eine größere Instanz aufzunehmen.

4. Sparpläne: Die Untergrenze korrekt festlegen

Ein Sparplan ist ein ressourcenbasiertes Engagement, das eine feste Laufzeit gegen einen Rabatt auf Compute Engine Dedicated Core-Server, Managed Kubernetes Dedicated Core Node Pools und Nextcloud Workspace eintauscht, wobei die Kerne und RAM (GB)-Dimensionen abgedeckt werden. Die Wirtschaftlichkeit ist präzise:

Mehrere Regeln machen dies nur sicher, wenn Sie sie respektieren. Ein Plan reserviert die Abrechnung, nicht die physische Kapazität, daher blockiert er nie die Bereitstellung. Überläufe werden elegant gehandhabt: Die Nutzung über die verpflichtete Menge hinaus wird zum Standard-PAYG-Satz abgerechnet, sodass Überengagement das einzige echte Risiko darstellt. Wenn mehrere Pläne das gleiche Produkt abdecken, werden sie in der Reihenfolge ihrer Erstellung (chronologisch) angewendet, und innerhalb eines Produkts wird der Rabatt in der Reihenfolge der Erstellung (älteste zuerst) angewendet. Die AMD-Opteron-CPU-Familie ist ausgeschlossen. Ein Plan verlängert sich nicht automatisch, und nur ein Vertragsinhaber kann einen kaufen.

Die wichtigste operationale Tatsache ist, dass ein Sparplan nach der Aktivierung nicht bearbeitet werden kann; das einzige bearbeitbare Feld ist der Planname, und er kann nach dem Kauf nicht storniert werden. Das macht das Engagement zu einer einseitigen Entscheidung und diktiert die Disziplin: die Untergrenze festlegen. Legen Sie nur die Basislinie des stabilen Zustands fest, von der Sie sicher sind, dass Sie sie für die gesamte Laufzeit ausführen, nehmen Sie den PAYG-Überlauf für alles, was darüber liegt, und verlängern Sie die Laufzeit nur für die Kapazität, von der Sie sicher sind, dass sie drei Jahre lang besteht. Ein optimistisches Engagement für den Spitzenverbrauch sperrt Ausgaben, die Sie nicht bearbeiten können; das Festlegen der Untergrenze erfasst den Rabatt für die garantierte Nutzung, während die variable Last auf flexible PAYG bleibt.

5. Allokation, Showback und Chargeback

Die Kostenallokation basiert auf der Struktur aus Einheit 2.1. Da jedes virtuelle Rechenzentrum bereits seinen eigenen Abschnitt auf der monatlichen Rechnung produziert, ist die Vertrags- und virtuelles-Rechenzentrum-Hierarchie die primäre Allokationsachse: ein Vertrag gruppiert einen Governance- und Abrechnungsbereich, und virtuelle Rechenzentren innerhalb davon trennen Umgebungen oder Projekte in separate Rechnungslinien. Die Kosten- und Nutzungsansicht in dem DCD ist die Analyseoberfläche für dies, und ein Kosten- und Nutzung-API existiert, um Abrechnungsworkflows programmatisch zu speisen.

Die Allokation unterstützt zwei Betriebsmodelle. Showback-Berichte zeigen jedem Team oder Projekt seinen Anteil an den Kosten für Transparenz und Rechenschaftspflicht ohne Geld zu bewegen. Chargeback fakturiert die Kosten tatsächlich an die konsumierende Einheit zurück. Showback ist der leichtgewichtigere Startpunkt und ist normalerweise ausreichend, um das Verhalten zu ändern; Chargeback fügt finanzielle Durchsetzung bei erhöhter Abrechnungsapparatur hinzu. Für FinCorp ermöglicht die Zuordnung von virtuellen Rechenzentren zu Projekten, sodass jedes auf seiner eigenen Rechnungslinie landet, eine saubere Showback sofort, mit Chargeback, das später hinzugefügt werden kann, wenn die Finanzabteilung es erfordert. (Behandeln Sie das Dashboard und die Allokationsnavigation als Analyseebene; der Build darunter ist die Kostenwarn-Schutzbarriere, die der gut dokumentierte Erstellpfad ist.)

DCD Implementierungs-Walkthrough

Sie erstellen eine Kostennachricht, die einen Empfänger per E-Mail benachrichtigt, wenn die Vertragsausgaben einen Budget-Schwellenwert überschreiten. Dies ist die einzige gut dokumentierte Kostenumsetzung. Sie ist die betriebliche Schutzvorkehrung, die die architektonischen Hebel oben unterstützt. Die Voraussetzung ist Vertragsinhaber- oder Administrator-Zugriff, da nur diese Rollen Kostennachrichten erstellen können. Beachten Sie, dass die Nachricht auf Vertragsebene festgelegt wird (ein Betrag und eine E-Mail-Adresse), sodass die Zuweisung über virtuelle Rechenzentren ein Berichtsproblem ist, das im Bereich Kosten und Nutzung und nicht in der Nachricht selbst behandelt wird.

Ziel der Umsetzung: Erstellen einer Kostennachricht gegen einen Budget-Schwellenwert.

Schritte (im Data Center Designer):

1. Gehen Sie zu Menü > Verwaltung > Kostennachricht. Das Fenster Kostennachricht öffnet sich. In diesem Bereich werden auch alle vorhandenen Nachrichten aufgelistet.
2. Wählen Sie Kostennachricht erstellen.
3. Geben Sie im Dialog den Betrag (den Ausgaben-Schwellenwert für den Vertrag) und die E-Mail-Adresse ein, die benachrichtigt werden soll.
4. Wählen Sie Kostennachricht erstellen, um zu bestätigen. Die Nachricht ist jetzt aktiv und wird den Empfänger per E-Mail benachrichtigen, sobald die Vertragsausgaben den Schwellenwert überschreiten.

Häufige Fehler:

• Die Erwartung, dass die Nachricht die Ausgaben begrenzt oder stoppt. Sie benachrichtigt nur. Sie ist ein Warnsignal, keine harte Budgetdurchsetzung. Die Ausgaben gehen über den Schwellenwert hinaus.
• Die Festlegung pro virtuellem Rechenzentrum. Die Kostennachricht ist auf Vertragsebene (Betrag plus E-Mail-Adresse) festgelegt. Verwenden Sie den Bereich Kosten und Nutzung für die Analyse und Zuweisung pro virtuellem Rechenzentrum.
• Die alleinige Verlässlichkeit auf Nachrichten anstelle von Architektur. Die Nachricht erfängt Abweichungen. Die Entscheidungen über die Rechenklasse, den Speichertyp und den Sparplan sind es, die die Rechnung tatsächlich festlegen.
• Die Ausrichtung der Nachricht auf ein persönliches Postfach. Senden Sie sie an eine überwachte Finanz- oder Betriebsadresse, damit die Benachrichtigung gesehen und bearbeitet wird.

Architekturmuster

Eine verteidigbare FinCorp-Kostenarchitektur schichtet die Hebel nach Auswirkung. Am Basis liegt die Wahl der Compute-Klasse pro Tier: dedizierte Kerne für die regulierten und auto-skalierten Tier (mit bewusstem Spielraum als gerechtfertigter Kontrollkosten), gemeinsame Kerne für tolerante und nicht-produktive Workloads. Der Speicher ist nach dem Zugriffsmuster gestaffelt, wobei SSD-Volumen bei oder über der 100-GB-Grenze gehalten werden und Bulk-/Archivdaten auf Object Storage gespeichert werden. Die Datenebene ist für Schreibvorgänge und Arbeitsmenge dimensioniert, wobei ein In-Memory-Cache das Lesenwachstum absorbiert, anstatt eine übergroße Datenbank. Darüber hinaus verpflichtet ein Sparplan nur die festen, dedizierten Kerne und die RAM-Basis auf eine Laufzeit, die der echten Persistenz entspricht, und nimmt PAYG-Überläufe darüber hinaus. Oben liegt die Zuweisungskarte, die virtuelle Rechenzentren (VDCs) Projekten zuweist, und eine vertragsbezogene Kostenwarnung dient als Drift-Auslöser. Als berechnetes Beispiel würde ein Tier, das konstant 32 dedizierte Kerne ausführt, bei PAYG etwa 1,28 Euro pro Stunde kosten (32 x 0,04 Euro); die Verpflichtung dieser Basis auf einem 3-Jahres-Plan bringt die Kerngebühr auf etwa 0,77 Euro pro Stunde (32 x 0,024 Euro), was einer 40-prozentigen Reduzierung auf der garantierten Basislinie entspricht, während jeder Burst über 32 Kerne immer noch nach PAYG abgerechnet wird.

Zusammenfassung

Die Cloud-Kosten bei IONOS sind architektonisch gestaltet und nicht nur überwacht. Die Compute-Kontentionsklasse ist der größte Hebel, wobei eine bewusste Überprovisionierung der im Umfang enthaltenen Hosts als Kontrollkosten gerechtfertigt ist; der Speicher ist in Ebenen unterteilt, um auf das Zugriffsmuster innerhalb der SSD-Leistungsbasis zuzugreifen; und die Datenebene skaliert die Lesevorgänge durch einen Cache und nicht durch eine überdimensionierte Instanz. Sparpläne erfassen die Terminrabatte von 15% (1-Jahr) und 40% (3-Jahr) auf dedizierte Kerne und RAM, aber können nach der Aktivierung nicht bearbeitet werden, was bedeutet, dass nur der bestimmte Boden verpflichtet werden kann und der PAYG-Überlauf genommen wird. Die Zuweisung folgt der Vertrags- und VDC-Struktur für Showback oder Chargeback, und eine vertragsbezogene Kostenwarnung bietet die operationale Auslösevorrichtung, die in die DCD integriert ist.

Wichtige Punkte:

• Die Compute-Kontention ist der erste Kostenhebel: gemeinsam genutzte Kerne sind billiger, exklusive (dedizierte) Kerne bieten Vorhersehbarkeit und Isolation; die Auto-Skalierung legt jeden Replikats-Computeschema zur Entwurfszeit fest und integriert die Elastizität in die Kostentscheidung.
• Speicher in Ebenen unterteilen, um auf das Zugriffsmuster zuzugreifen: HDD 0,04, SSD Standard 0,07, SSD Premium 0,15 EUR/GB/Monat; SSD-Volumen sollten auf oder über der 100-GB-Vollleistungsgrundlage liegen; Bulk und Archiv sollten auf Object Storage gespeichert werden.
• Skalieren der Datenebene-Lesevorgänge mit einem In-Memory-Cache und nicht mit einer überdimensionierten Datenbank, da es keine Lese-Replikate gibt.
• Sparpläne bieten 15% (1-Jahr) und 40% (3-Jahr) Rabatte auf dedizierte Kerne und RAM, Überlauf wird nach PAYG berechnet, Pläne werden oldest-first angewendet und können nach der Aktivierung nicht bearbeitet werden, daher sollte nur der bestimmte Boden verpflichtet werden.
• Zuweisung nach Vertrag und VDC (jeder VDC wird bereits als eigene Zeile berechnet); Showback oder Chargeback wählen; eine vertragsbezogene Kostenwarnung (Betrag plus E-Mail) ist die Build-Time-Sicherung und benachrichtigt nur, sie begrenzt den Ausgaben nicht.

Wichtige Begriffe:

• CPU-Nutzungsklasse: Ob ein Servers Kern exklusiv (Dedicated Core) oder gemeinsam genutzt (vCPU) ist; der primäre Compute-Kosten- und Leistungshebel.
• Sparplan: Ein ressourcenbasierter 1-Jahr- oder 3-Jahr-Abrechnungsverpflichtung auf dedizierte Kerne und RAM, mit PAYG-Überlauf, nicht bearbeitbar nach der Aktivierung, nur vom Vertragsinhaber käuflich.
• Showback / Chargeback: Bericht einer Mannschaft über ihre Kostenbeteiligung für Rechenschaftspflicht (Showback) versus tatsächliche Abrechnung der Kosten an sie (Chargeback).
• Kostenwarnung: Ein vertragsbezogener Schwellenwert (Betrag plus E-Mail), der bei Ausgabenüberschreitung benachrichtigt; er warnt, aber begrenzt den Ausgaben nicht.