Einheit 4.1: Auswahl der Compute-Klasse

Einführung

Die Compute class ist keine reine Größenfrage, sondern eine architektonische Entscheidung, die in IONOS CLOUD pro Ebene und nicht pro gesamter Infrastruktur getroffen wird. Die gewählte Klasse legt vier Aspekte gleichzeitig fest: ob die Workload einen exklusiven physischen Kern erhält oder sich einen teilt, ob die CPU-Familie festgelegt werden kann, ob Netzwerk-Block Storage angeschlossen werden kann und wer das operative Modell trägt. Eine dieser Entscheidungen ist faktisch dauerhaft (das Template eines Cube ist nach der Bereitstellung unveränderbar), weshalb die richtige Klassenauswahl im Entwurfsstadium kostengünstiger ist als jede spätere Umgehungslösung. Diese Einheit macht diese Entscheidung für die drei Compute-Klassen in IONOS CLOUD explizit und schließt mit der Bereitstellung der Dedicated Core-Shell, die in den Einheiten 4.2 und 4.3 um Storage, cloud-init und Auto-Scaling erweitert wird.

1. Die vierdimensionale Compute-Entscheidung

Jede IONOS CLOUD Compute-Klasse beantwortet dieselben vier Fragen auf unterschiedliche Weise. Behalten Sie diese vier Achsen im Hinterkopf, und die Klasse wählt sich fast von selbst.

Kernisolierung. Ein Dedicated Core Server erhält einen dedizierten physischen Kern, der dem Gast-Betriebssystem als zwei logische Kerne (ein physischer Kern mit Hyper-Threading erscheint als zwei Threads) bereitgestellt wird. Ein vCPU Server teilt sich physische Kerne mit anderen Mietern. Isolierung erkauft sich eine vorhersehbare Leistung bei Konkurrenz; das Teilen erkauft sich einen niedrigeren Preis. Dies ist das Konkurrenzmodell, das Einheit 2.4 als den ersten Kostentreiber einordnete, nun aus der Compute-Perspektive betrachtet.

Steuerung der CPU-Familie. Nur Dedicated Core ermöglicht es, die CPU-Familie auszuwählen und später zu ändern (zum Beispiel AMD EPYC für eine Workload festzulegen, die davon profitiert, oder eine Stufe auf Intel Xeon zu standardisieren). Auf einem vCPU Server ist die Familie nicht wählbar. Dies ist relevant, wenn eine Workload empfindlich auf Unterschiede im Befehlssatz oder der Taktfrequenz pro Kern reagiert, oder wenn eine Lizenz an eine CPU-Familie gebunden ist.

Anbindung von Block Storage. Dedicated Core und vCPU Server binden Netzwerk-Block Storage Volumes an (die Boot-Disk und alle Datendatenträger befinden sich auf dem iSCSI Block-Netzwerk, behandelt in Einheit 4.2). Ein Cube wird mit einem obligatorischen direkt angebundenen NVMe Volume ausgeliefert, das Teil seiner festen Vorlage ist. Das Anbindungsmodell bestimmt, wie Sie den Speicherlebenszyklus, Snapshots und Größenanpassungen verwalten.

Betriebsmodell und SLA. Ein Dedicated Core oder vCPU Server ist eine verwaltete VM mit Live-Vertikalskalierung und einem 99,95 % pro Dienst verfügbaren SLA. Ein Cube ist eine Instanz mit fester Vorlage und einem 99,9 % SLA.

Die folgende Tabelle stellt die drei Klassen den Achsen gegenüber, die die Entscheidung steuern.

Ein Dedicated Core Server kann mit bis zu 62 Kernen und 230 GB RAM konfiguriert werden. RAM wird in 0,25 GB Schritten zugewiesen. Diese Obergrenzen binden selten eine einzelne Stufe, sind aber relevant, wenn Sie eine große Monolith-Anwendung dimensionieren, bevor Sie entscheiden, ob Sie sie aufteilen.

1.1 Dedicated Core: der Standard für Stufen, die eine Garantie benötigen

Wählen Sie Dedicated Core, wenn die Stufe eine vorhersehbare Leistung unter Last benötigt oder wenn Sie die CPU-Familie festlegen oder ändern müssen. Der exklusive physische Kern ist der Faktor, der die Leistungsgarantie bei Konkurrenz erkauft, und die Steuerung der CPU-Familie ist einzigartig für diese Klasse. Wenn eine Stufe auch horizontal skaliert, wird ihre Replikate-Compute-Konfiguration (CPU-Architektur, Kerne und RAM) zur Designzeit in der VM Auto Scaling Replikate-Vorlage (Einheit 4.3) festgelegt, so dass die frühe Festlegung der Compute-Form der Stufe sich immer noch lohnt. Der Preis des exklusiven Kerns ist der Preis, den Sie für die Leistungsgarantie zahlen.

Die CPU-Familienauswahl bei Dedicated Core ist real, aber nicht kostenlos: Die Änderung der Familie auf einem bestehenden Server erfordert einen Neustart. Behandeln Sie eine Familienänderung als geplante Wartungsoperation mit einem Zeitfenster, nicht als Live-Einstellknopf.

1.2 vCPU: kosteneffizient, wo Konkurrenz akzeptabel ist

Ein vCPU Server wird provisioniert und verhält sich wie jede andere VM, teilt sich aber physische Kerne, weshalb er der kosteneffiziente Standard für Entwicklungs- und Testumgebungen, wesentliche interne Software-Dienste und Stufen ist, bei denen gelegentliche Konkurrenz akzeptabel ist. Er unterstützt Live-Vertikalskalierung wie Dedicated Core, kann aber keine CPU-Familie auswählen. Die Entscheidungsregel ist einfach: Wenn die Stufe weder eine Leistungsgarantie noch die Steuerung der CPU-Familie benötigt, ist ein vCPU Server die günstigere richtige Wahl.

1.3 Cubes: die Instanz mit fester Vorlage, kein Sackgasse für Speicher

Ein Cube ist eine Instanz mit fester Konfiguration: vCPU, RAM und ein direkt angebundenes NVMe Volume kommen als gebündelte Vorlage, und Sie dürfen diese Vorlageneigenschaften nach der Provisionierung nicht ändern. Das NVMe Volume ist über PCI Express am physischen Server angeschlossen und software-RAID ein redundant; es belegt einen der Geräteslots der Instanz und kann nicht abgemountet oder gelöscht werden, solange der Cube existiert. Basisvorlagen reichen von Basic-Cube-XS (1 vCPU, 2 GB RAM, 60 GB NVMe) bis zu Basic-Cube-XL (16 vCPU, 32 GB RAM, 960 GB NVMe); Speicher-Vorlagen tauschen Kerne gegen RAM (zum Beispiel Memory-Cube-XL mit 16 vCPU und 64 GB RAM).

Hier ist die Falle, und sie läuft in die entgegengesetzte Richtung zu einer gängigen Annahme. Ein Cube wird oft als nicht in der Lage abgetan, Block Storage zu nutzen. Das ist falsch: Ein Cube unterstützt bis zu 23 zusätzliche HDD oder SSD (Standard oder Premium) Block Storage Geräte neben seinem obligatorischen NVMe Volume, und diese zusätzlichen Geräte können nach der Provisionierung jederzeit abgemountet und gelöscht werden. Die eigentliche Einschränkung ist anders und spezifischer: Die Vorlage selbst (vCPU, RAM und NVMe-Größe) ist unveränderbar, und das NVMe Volume kann nicht getrennt werden. Das Löschen eines Cubes löscht sein NVMe Volume, daher erstellen Sie zuerst ein Snapshot, wenn die Daten überleben müssen. Die ehrliche Designregel lautet also: Wählen Sie einen Cube, wenn sein festes Bundle zur Workload passt und Sie einen vorhersehbaren einzelnen Posten wünschen, und planen Sie persistente Daten auf zusätzliche Block Storage Volumes, die die Vorlage überleben, nicht auf die unveränderbare NVMe-Festplatte.

2. Class-Per-Tier als Muster

Die Entscheidungseinheit für die Compute-Klasse ist die Schicht (Tier), nicht die Anwendung. Ein schichtbasiertes Enterprise-Design (die Struktur aus Einheit 1.2: Public-L7 zu stateless Compute zu Private-L4 zu Private Data) mischt routinemäßig verschiedene Klassen: Dedicated Core für die Schicht, die skalieren muss und eine Leistungsgarantie erfordert, vCPU für interne oder nicht kritische Schichten und ein Cube, wenn ein festes Bundle eine saubere Passform bietet. Wenn eine Workload eine Single-Tenant verwaltete Plattform benötigt (zum Beispiel ein reguliertes VMware-Umfeld), handelt es sich um die dedizierte VMware Private Cloud, die in Einheit 4.4 behandelt wird, nicht um eine Public Cloud Compute-Klasse. Das Mischen von Klassen nach Schichten ist der Normalfall, kein Kompromiss.

Zwei Designregeln ergeben sich daraus und sind klar zu formulieren, da beide unter Zeitdruck leicht falsch verstanden werden können:

• Die Replikaten-Compute-Konfiguration einer auto-skalierten Schicht wird zum Designzeitpunkt festgelegt. VM Auto Scaling erzeugt neue Replikate aus einer Replikat-Vorlage (CPU-Architektur, Kerne, RAM), und eine Änderung der Vorlage gilt nur für danach erstellte Replikate. Die Replikaten-Form ist daher eine Designzeit-Entscheidung und kein live einstellbarer Parameter (Einheit 4.3).
• Eine Änderung der CPU-Familie ist eine geplante Operation. Sie ist bei Dedicated Core verfügbar, erfordert jedoch einen Neustart und gehört daher in ein Wartungsfenster, nicht in ein Live-Tuning-Runbook.

Für FinCorp, das regulierte deutsche Finanzdienstleistungsunternehmen, das durch diesen Kurs begleitet wird, ist die kundenorientierte Anwendungsschicht diejenige, die am ehesten variabler Last ausgesetzt ist und am stärksten dem öffentlichen Layer 7 Load Balancer ausgesetzt ist. Diese Schicht wird als Dedicated Core provisioniert, um eine vorhersehbare Leistungsgarantie unter Last zu gewährleisten. Dadurch kann ihre CPU-Familie für konsistente Leistung standardisiert werden, und sie ist die Schicht, die später unter einer Metrik-Policy horizontal skaliert (Einheit 4.3). Die interne Batch-Berichtsschicht von FinCorp toleriert dagegen Kontention und wird als vCPU provisioniert, um Kosten zu senken. Der Compliance-Aspekt unterstreicht dies: BSI C5 (die Type 1 Attestation vom 7. November 2023) und IT-Grundschutz (das ISO 27001 Zertifikat vom 14. September 2022) umfassen beide Compute Engine, sodass die standardmäßigen VM-Klassen innerhalb des Attestationsumfangs von FinCorp liegen. Das regulierte VMware-Umfeld ist eine separate Entscheidung, die durch die dedizierte VMware Private Cloud in Einheit 4.4 behandelt wird.

Designüberlegungen

• Kosten. Der exklusive Kern von Dedicated Core ist der Aufpreis, den Sie für eine Leistungsgarantie und die Qualifikation für automatische Skalierung zahlen. Wenn beides nicht erforderlich ist, ist vCPU die kostengünstigere und korrekte Lösung; kaufen Sie keine Isolation, die eine Ebene nicht benötigt.
• Betrieb. Die permanente Entscheidung (die unveränderliche Vorlage eines Cube) verursacht die höchsten Betriebskosten, wenn sie falsch ist, da eine Korrektur einen Wiederaufbau und keine Neukonfiguration erfordert. Widmen Sie hier die größte Sorgfalt beim Design.
• Skalierbarkeit. Vertikale Skalierung (das Wachstum von CPU und RAM bei laufendem Betrieb) ist bei Dedicated Core und vCPU innerhalb der in Einheit 4.3 behandelten Grenzen verfügbar; verwaltete horizontale Skalierung fügt ganze Replikate hinzu und entfernt sie gemäß einer Metrikrichtlinie, wobei die Rechenkonfiguration der Replikate in der Replikatvorlage zum Designzeitpunkt festgelegt ist. Entscheiden Sie, auf welcher Achse eine Ebene skaliert, bevor Sie ihre Klasse auswählen.

Implementierungsanleitung für DCD

In dieser Anleitung wird die Serverhülle des Dedicated Core bereitgestellt, die der Rest von Modul 4 erweitert. Sie setzt die oben beschriebene Designentscheidung für die kundenorientierte Ebene von FinCorp um: eine Dedicated Core-Klasse für eine vorhersehbare Leistungsgarantie, sodass die CPU-Familie unter unserer Kontrolle liegt. Voraussetzung ist das in Einheit 3.1 erstellte FinCorp Virtual Data Center, in das dieser Server platziert wird. Details zu Speicher und Image werden bewusst auf Einheit 4.2 verschoben. Hier wird daher nur der Server erstellt und seine Kerne, der RAM, die CPU-Familie sowie die Zugangsdaten festgelegt.

Ziel der Erstellung: Bereitstellung einer Dedicated Core-Serverhülle (Klasse, Kerne/RAM, Zugangsdaten).

Schritte (im Data Center Designer):

1. Öffnen Sie das FinCorp VDC aus Einheit 3.1 im Workspace. Die folgende Anleitung gilt für den Canvas-Modus; falls noch kein Rechenzentrum existiert, erstellen Sie zuerst eines.
2. Ziehen Sie aus der Palette ein Dedicated Core-Server-Element auf den Canvas, um es dem VDC hinzuzufügen.
3. Wählen Sie den neuen Server aus, um das Inspector-Feld auf der rechten Seite zu öffnen, und vergeben Sie einen Namen, der innerhalb des VDC eindeutig ist (dies ist seine Identität für den Rest des Moduls).
4. Legen Sie die CPU-Architektur / -Familie fest. Bei Dedicated Core ist diese wählbar; fixieren Sie die Familie, auf die die Ebene standardisiert ist. Beachten Sie, dass eine spätere Änderung der Familie einen Neustart erfordert, wählen Sie daher bewusst.
5. Legen Sie Kerne und RAM fest. Bleiben Sie innerhalb der Grenzen von Dedicated Core (bis zu 62 Kerne, bis zu 230 GB RAM; RAM wird in 0,25-GB-Schritten zugewiesen). Dimensionieren Sie für die Baseline der Ebene, nicht für ihren Spitzenwert, da horizontale Skalierung Spitzen in Einheit 4.3 abfängt.
6. Unter Authentifizierung setzen Sie das Root- bzw. Administratorpasswort und/oder fügen Sie einen SSH-Schlüssel hinzu (wählen Sie einen aus dem SSH Key Manager oder fügen Sie einen ad-hoc öffentlichen Schlüssel ein). So erreichen Sie den Server, nachdem er hochgefahren ist.
7. Lassen Sie Speicher und Image für Einheit 4.2; starten Sie noch nicht von einem Image. Klicken Sie auf Provision Changes, um die Änderungen anzuwenden, wodurch die Serverhülle festgelegt wird.

Häufige Fehler:

• Die Replikat-Form der Auto-Scaling-Gruppe als Laufzeitparameter zu behandeln. Die Compute-Konfiguration der Replikat-Vorlage (CPU-Architektur, Kerne, RAM) wird zur Designzeit festgelegt und gilt nur für neue Replikate. Dimensionieren und formen Sie das Replikat daher bewusst, bevor die Gruppe ausgeführt wird (Einheit 4.3).
• Die CPU-Familie als Laufzeitparameter zu behandeln. Eine Änderung bei Dedicated Core erfordert einen Neustart; planen Sie sie als geplante Wartung ein.
• Die Hülle auf ihren Spitzenwert zu dimensionieren. Dimensionieren Sie die Dedicated Core-Baseline für die Dauerlast und lassen Sie die horizontale Skalierung (Einheit 4.3) Spitzen absorbieren, anstatt für eine dauerhaft große einzelne VM zu zahlen.
• Zu vergessen, dass ein neu bereitgestellter Server mit mehr als 8 GB RAM beim allerersten Hochfahren möglicherweise nicht sauber startet, bis der Arbeitsverabeitert Speicher verarbeitet wurde; dies ist erwartetes Verhalten und kein Fehler.

Der architektonische Aspekt, den ein unveränderliches Attribut mit sich bringt, ist selbst in einer einzeiligen CLI-Erstellung sichtbar: Die CPU-Familie und die Klasse werden bei der Erstellung festgelegt, und eine spätere Änderung der Familie ist eine Operation mit Neustart, keine freie Bearbeitung.

ionosctl server create --datacenter-id "$FINCORP_VDC" \
  --name fincorp-app-01 --cpu-family INTEL_SKYLAKE --cores 4 --ram 8192

Zusammenfassung

Die Compute-Klasse in IONOS CLOUD ist eine architektonische Entscheidung pro Ebene, die von vier Aspekten gesteuert wird: Kernisolierung, Steuerung der CPU-Familie, Anbindung von Block Storage und operatives Modell. Dedicated Core ist die Standardwahl, wenn eine Ebene eine Leistungsgarantie, die Steuerung der CPU-Familie oder die Eignung für verwaltetes Auto-Scaling benötigt; vCPU ist die kostengünstigere Option, wenn Kontention akzeptabel ist; und ein Cube ist eine Instanz mit festem Template, deren vCPU/RAM/NVMe-Bundle unveränderlich ist, die jedoch weiterhin zusätzliche Block Storage-Geräte anbinden kann. Die Klasse sollte vor der Dimensionierung festgelegt werden, da die entscheidendsten Einschränkungen die permanenten sind, und die Dedicated Core-Schale als Grundlage bereitgestellt werden sollte, auf der der Rest von Modul 4 aufbaut.

Wichtige Punkte:

• Die vierdimensionale Entscheidung (Isolierung, CPU-Familie, Block-Storage-Anbindung, operatives Modell) wird pro Ebene getroffen, nicht pro Gesamtumgebung.
• VM Auto Scaling ist ausschließlich horizontal: Es fügt ganze Replikate unter einer Metrikrichtlinie hinzu und entfernt sie, und die Compute-Konfiguration der Replikate ist im Replikat-Template zum Designzeitpunkt festgelegt.
• Das Template eines Cubes (vCPU, RAM, NVMe) ist unveränderlich und sein NVMe kann nicht getrennt werden, aber ein Cube kann weiterhin bis zu 23 zusätzliche Block Storage-Geräte anbinden; die Einschränkung ist das feste Template, nicht die Unfähigkeit, Block Storage zu verwenden.
• Eine Änderung der CPU-Familie bei Dedicated Core erfordert einen Neustart; behandeln Sie dies als geplante Wartung.

Wichtige Begriffe:

• Dedicated Core-Server: eine VM mit einem exklusiven physischen Kern (zwei logische Kerne) und wählbarer CPU-Familie.
• vCPU-Server: eine VM, die physische Kerne teilt; kosteneffizient, ohne Steuerung der CPU-Familie.
• Cube: eine Instanz mit festem Template und einem obligatorisch direkt angebundenen NVMe-Volumen; die Template-Eigenschaften sind nach der Bereitstellung unveränderlich.
• Live Vertical Scaling (LVS): Vergrößern oder Verkleinern der Ressourcen einer laufenden VM, ausführlich in Einheit 4.3 behandelt.

Weitere Lektüre

• Einheit 4.2: Images, Disks und Cloud-Init (erweitert diese Server-Shell).
• Einheit 4.3: Elastizität und VM Auto Scaling (wie diese Ebene horizontal skaliert).
• Einheit 2.4: Kostenarchitektur und FinOps (das Wettbewerbsmodell als erster Kostentreiber).