Einheit 4.1: Auswahl der Computeklasse

Einführung

Die Compute-Klasse ist keine Größenentscheidung, sondern eine architektonische Entscheidung, und bei IONOS Cloud wird sie pro Stufe und nicht pro Anwesen getroffen. Die Klasse, die Sie wählen, legt vier Dinge gleichzeitig fest: ob die Workload einen exklusiven physischen Core erhält oder einen teilt, ob Sie die CPU-Familie festlegen können, ob Sie Netzwerk-Block Storage anhängen können und wer das Betriebsmodell trägt. Eine dieser Entscheidungen ist effektiv permanent (ein Cube-Template ist nach der Bereitstellung unveränderlich), daher ist es günstiger, die Klasse bereits bei der Entwurfszeit richtig zu wählen, als später einen Umweg zu gehen. Diese Einheit macht diese Entscheidung über die drei IONOS Cloud-Compute-Klassen explizit und endet mit der Bereitstellung des Dedicated Core-Shells, das die Einheiten 4.2 und 4.3 mit Speicher, cloud-init und Auto-Scaling erweitern.

1. Die Vier-Wege-Compute-Entscheidung

Jede IONOS-Computeklasse beantwortet die gleichen vier Fragen unterschiedlich. Halten Sie diese vier Achsen im Kopf und die Klasse wählt sich fast von selbst aus.

Core-Isolation. Ein Dedicated Core Server erhält einen dedizierten physischen Core, der dem Gast-Betriebssystem als zwei logische Cores (ein physischer Core mit Hyper-Threading wird als zwei Threads dargestellt) präsentiert. Ein vCPU Server teilt physische Cores mit anderen Mandanten. Isolation bietet vorhersehbare Leistung unter Konkurrenzbedingungen; Teilen bietet einen niedrigeren Preis. Dies ist das Konkurrenzmodell, das in Einheit 2.4 als erste Kostenhebelrahmen dargestellt wurde, jetzt jedoch aus der Compute-Perspektive betrachtet.

CPU-Familiensteuerung. Nur Dedicated Core ermöglicht es Ihnen, die CPU-Familie auszuwählen und später zu ändern (z. B. AMD EPYC für ein Workload, das davon profitiert, oder Standardisierung einer Ebene auf Intel Xeon). Auf einem vCPU Server ist die Familie nicht auswählbar. Dies ist wichtig, wenn ein Workload empfindlich auf Unterschiede im Befehlssatz oder pro-Kern-Takt reagiert oder wenn eine Lizenz an eine CPU-Familie gebunden ist.

Block-Speicheranbindung. Dedicated Core- und vCPU-Server binden Netzwerk-Block Storage-Volumen an (die Boot-Disk und alle Daten-Disk befinden sich auf dem iSCSI-Block-Fabric, der in Einheit 4.2 behandelt wird). Ein Cube wird mit einem obligatorischen direkt angebundenen NVMe-Volume geliefert, das Teil seines festen Templates ist. Das Anbindungsmodell entscheidet, wie Sie den Speicherlebenszyklus, Snapshots und die Größe ändern.

Betriebsmodell und SLA. Ein Dedicated Core oder ein vCPU Server ist ein gemanagtes VM mit Live-Vertikalskalierung und einem 99,95% pro Dienst Uptime-SLA. Ein Cube ist eine Instanz mit festem Template und einem 99,9% SLA.

Die folgende Tabelle setzt die drei Klassen gegen die Achsen, die die Entscheidung treffen.

Ein Dedicated Core Server kann bis zu 62 Cores und 230 GB RAM konfiguriert werden. RAM wird in 0,25 GB-Schritten zugewiesen. Diese Obergrenzen binden selten eine einzelne Ebene, aber sie sind wichtig, wenn Sie eine große Monolith-Instanz vor der Entscheidung, ob sie aufgeteilt werden soll, dimensionieren.

1.1 Dedicated Core: Der Standard für Ebenen, die eine Garantie benötigen

Wählen Sie Dedicated Core, wenn die Ebene vorhersehbare Leistung unter Last oder wenn Sie die CPU-Familie festlegen oder ändern müssen. Der exklusive physische Core ist es, der die Leistungsgarantie unter Konkurrenzbedingungen kauft, und die CPU-Familiensteuerung ist einzigartig für diese Klasse. Wenn eine Ebene auch horizontal skaliert, wird ihre Replikate-Computekonfiguration (CPU-Architektur, Cores und RAM) zur Entwurfszeit im VM Auto Scaling-Replikate-Template (Einheit 4.3) festgelegt, sodass die Festlegung der Computekonfiguration der Ebene immer noch von Vorteil ist. Der Preis für den exklusiven Core ist der Preis, den Sie für die Leistungsgarantie zahlen.

Die CPU-Familienauswahl auf 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: Kosteneffektiv, wo Konkurrenz akzeptabel ist

Ein vCPU Server stellt und verhält sich wie jeder andere VM, teilt jedoch physische Cores, was der Grund dafür ist, dass es der kosteneffektive Standard für Entwicklung- und Testumgebungen, wesentliche interne Software-Dienste und Ebenen ist, bei denen gelegentliche Konkurrenz akzeptabel ist. Es unterstützt Live-Vertikalskalierung wie Dedicated Core, kann jedoch keine CPU-Familie auswählen. Die Entscheidungsregel ist einfach: Wenn die Ebene weder eine Leistungsgarantie noch eine CPU-Familiensteuerung benötigt, ist ein vCPU Server die günstigere richtige Wahl.

1.3 Cubes: Die Instanz mit festem Template, kein Speicher-Totalschaden

Ein Cube ist eine Instanz mit festem Template: vCPU, RAM und ein direkt angebundenes NVMe-Volume kommen als gebündeltes Template und können nach der Bereitstellung nicht geändert werden. Das NVMe-Volume ist über PCI Express im physischen Server verbunden und ist software-RAID-einfach redundant; es belegt einen der Geräteschlitze der Instanz und kann nicht abgemountet oder gelöscht werden, solange der Cube existiert. Grundlegende Templates reichen von Basic-Cube-XS (1 vCPU, 2 GB RAM, 60 GB NVMe) bis hin zu Basic-Cube-XL (16 vCPU, 32 GB RAM, 960 GB NVMe); Speicher-Template tauschen Cores gegen RAM (z. B. Memory-Cube-XL bei 16 vCPU und 64 GB RAM).

Hier ist die Falle, und sie läuft entgegengesetzt zu einer häufigen Annahme. Ein Cube wird oft abgelehnt, weil er angeblich kein Block Storage verwenden kann. Das ist falsch: Ein Cube unterstützt bis zu 23 Add-on-HDD- oder SSD-Geräte (Standard oder Premium) Block Storage-Geräte zusätzlich zu seinem obligatorischen NVMe-Volume, und diese Add-on-Geräte können nach der Bereitstellung abgemountet und gelöscht werden. Die eigentliche Einschränkung ist anders und spezifischer: Das Template selbst (vCPU, RAM und NVMe-Größe) ist unveränderlich, und das NVMe-Volume kann nicht abgetrennt werden. Das Löschen eines Cubes löscht sein NVMe-Volume, also nehmen Sie zuerst ein Snapshot, wenn die Daten überleben müssen. Die ehrliche Entwurfsregel lautet also: Wählen Sie einen Cube, wenn sein festes Bündel mit dem Workload übereinstimmt und Sie eine vorhersehbare einzelne Position wünschen, und planen Sie persistente Daten auf Add-on-Block Storage-Volumen, die das Template überleben, nicht auf die unveränderliche NVMe-Disk.

2. Class-Per-Tier als Muster

Die Einheit der Compute-Klasse-Entscheidung ist die Ebene, nicht die Anwendung. Ein geschichteter Unternehmensdesign (die öffentliche L7-zu-zustandslose-Compute-zu-private-L4-zu-private-Daten-Form aus Einheit 1.2) mischt Routine-Klassen: Dedicated Core für die Ebene, die skaliert und eine Leistungsgarantie halten muss, vCPU für interne oder nicht-kritische Ebenen, und ein Cube, wo ein festes Bündel eine saubere Passung ist. Wo ein Workload eine single-tenant-gemanagte Plattform benötigt (zum Beispiel ein regulierter VMware-Besitz), ist das die dedizierte VMware Private Cloud, die in Einheit 4.4 behandelt wird, nicht eine Public Cloud-Compute-Klasse. Das Mischen von Klassen nach Ebene ist die Norm, nicht ein Kompromiss.

Zwei Designregeln ergeben sich aus diesem und sind es wert, einfach auszudrücken, da beide leicht unter Zeitdruck falsch interpretiert werden können:

• Die Replikate-Konfiguration einer auto-skalierten Ebene wird zur Entwurfszeit festgelegt. VM Auto Scaling erstellt neue Replikate aus einem Replikat-Vorlage (CPU-Architektur, Kerne, RAM), und eine Vorlage-Änderung gilt nur für nachfolgend erstellte Replikate, sodass die Replikat-Form eine Entwurfszeit-Entscheidung und nicht ein Live-Knob (Einheit 4.3) ist.
• Eine CPU-Familien-Änderung ist ein geplanter Vorgang. Sie ist auf Dedicated Core verfügbar, benötigt jedoch einen Neustart, sodass sie in einem Wartungsfenster und nicht in einem Live-Tuning-Runbook durchgeführt werden sollte.

Für FinCorp, das regulierte deutsche Finanzdienstleistungsunternehmen, das in diesem Kurs durchgeführt wird, ist die kundenorientierte Anwendungsebene diejenige, die am ehesten einer variablen Last ausgesetzt ist und die am stärksten dem öffentlichen Layer-7-Lastverteiler ausgesetzt ist. Diese Ebene wird als Dedicated Core für eine vorhersehbare Leistungsgarantie unter Last bereitgestellt, sodass ihre CPU-Familie für eine konsistente Leistung standardisiert werden kann, und sie ist die Ebene, die später horizontal unter einer Metrik-Policy skaliert (Einheit 4.3). FinCorps interne Batch-Reporting-Ebene hingegen toleriert Konkurrenz und wird als vCPU bereitgestellt, um Kosten zu sparen. Der Compliance-Aspekt verstärkt dies: BSI C5 (die Typ-1-Bescheinigung vom 7. November 2023) und IT-Grundschutz (das ISO 27001-Zertifikat vom 14. September 2022) umfassen beide Compute Engine, sodass die Standard-VM-Klassen innerhalb von FinCorps Bescheinigungsumfang liegen. Der regulierte VMware-Besitz ist eine separate Entscheidung, die von der dedizierten 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 Eignung für Auto-Scaling zahlen. Wenn keines von beiden erforderlich ist, ist vCPU die günstigere richtige Antwort; kaufen Sie keine Isolation, die ein Tier nicht benötigt.
• Betrieb. Die dauerhafte Entscheidung (ein unveränderliches Cube-Template) trägt die höchsten operativen Kosten, wenn sie falsch ist, da die Korrektur ein Neuaufbau anstelle einer Neukonfiguration bedeutet. Verwenden Sie hier die meiste Designsorgfalt.
• Skalierbarkeit. Vertikales Scaling (lebendiges Wachstum von CPU und RAM) ist auf Dedicated Core und vCPU innerhalb der in Einheit 4.3 beschriebenen Grenzen verfügbar; gemanagtes horizontales Scaling fügt und entfernt ganze Repliken unter einer metrischen Richtlinie hinzu, wobei die Replik-Rechenkonfiguration im Replik-Template zur Entwurfszeit festgelegt ist. Entscheiden Sie, auf welcher Achse ein Tier skaliert, bevor Sie seine Klasse auswählen.

DCD Implementierung Schritt-für-Schritt

Diese Schritt-für-Schritt-Anleitung bereitstellt die Dedicated Core Server-Hülle, die die REST des Moduls 4 erweitert. Sie realisiert die oben genannte Designentscheidung für FinCorps kundenorientierte Ebene: Eine Dedicated-Core-Klasse für eine vorhersehbare Leistungsgarantie und somit ist ihre CPU-Familie unter unserer Kontrolle. Die Voraussetzung ist das virtuelle Rechenzentrum von FinCorp, das in Einheit 3.1 erstellt wurde, in das dieser Server eingeordnet wird. Speicher- und Bild-details werden absichtlich auf Einheit 4.2 verschoben, sodass wir hier nur den Server erstellen und dessen Kern, RAM, CPU-Familie und Anmeldeinformationen festlegen.

Ziel: Bereitstellen einer Dedicated Core Server-Hülle (Klasse, Kerne/RAM, Anmeldeinformationen).

Schritte (in der Data Center Designer):

1. Öffnen Sie das virtuelle Rechenzentrum von FinCorp aus Einheit 3.1 im Arbeitsbereich. Das folgende Verfahren gilt für den Canvas-Modus; wenn noch kein Rechenzentrum existiert, erstellen Sie eines zuerst.
2. Ziehen Sie aus der Palette ein Dedicated-Core-Server-Element auf den Canvas, um es dem virtuellen Rechenzentrum hinzuzufügen.
3. Wählen Sie den neuen Server aus, um das Inspector-Fenster auf der rechten Seite zu öffnen, und geben Sie ihm einen eindeutigen Namen innerhalb des virtuellen Rechenzentrums (dies ist seine Identität für die REST des Moduls).
4. Legen Sie die CPU-Architektur / -Familie fest. Bei Dedicated Core ist dies auswählbar; fixieren Sie die Familie, auf die die Ebene standardisiert ist. Beachten Sie, dass eine Änderung der Familie später einen Neustart erfordert, also wählen Sie 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 Basislast der Ebene, nicht für die Spitzenlast, da die horizontale Skalierung in Einheit 4.3 die Spitzen handhaben wird.
6. Unter Authentifizierung, legen Sie das Root-/Administratorkennwort fest und/oder fügen Sie einen SSH-Schlüssel hinzu (wählen Sie einen aus dem SSH Key Manager aus oder fügen Sie einen ad-hoc-öffentlichen Schlüssel hinzu). Dies ist die Methode, mit der Sie den Server erreichen, sobald er gestartet wird.
7. Lassen Sie Speicher und Bild für Einheit 4.2; booten Sie noch nicht von einem Bild. Klicken Sie auf Änderungen bereitstellen, um sie anzuwenden, was den Server-Shell-Commit ausführt.

Häufige Fehler:

• Die automatische Skalierung der Replikatform als Laufzeitregler behandeln. Die Replikavorgabe-Computekonfiguration (CPU-Architektur, Kerne, RAM) wird zur Entwurfszeit festgelegt und gilt nur für neue Replikate, also dimensionieren und formen Sie die Replikate bewusst, bevor die Gruppe ausgeführt wird (Einheit 4.3).
• Die CPU-Familie als Laufzeitregler behandeln. Eine Änderung auf Dedicated Core erfordert einen Neustart; planen Sie dies als geplante Wartung.
• Die Hülle auf die Spitzenlast zu groß dimensionieren. Dimensionieren Sie die Dedicated-Core-Basis für die Dauerlast und lassen Sie die horizontale Skalierung (Einheit 4.3) die Spitzen aufnehmen, anstatt für eine dauerhaft große einzelne VM zu zahlen.
• Vergessen, dass ein neu bereitgestellter Server mit mehr als 8 GB RAM möglicherweise nicht sauber startet, bis der Arbeitsspeicher verarbeitet wurde; dies ist erwartetes Verhalten, kein Fehler.

Der architektonische Punkt, dass ein unveränderlicher Attribut sichtbar ist, selbst in einer einzeiligen CLI-Erstellung: Die CPU-Familie und -Klasse werden bei der Erstellung festgelegt, und die Änderung der Familie später ist ein Neustart-tragendes Verfahren, kein kostenloser Editierprozess.

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

Zusammenfassung

Die Compute-Klasse auf IONOS Cloud ist eine architektonische Entscheidung pro Tier, die von vier Achsen getrieben wird: Core-Isolation, CPU-Familiensteuerung, Block Storage-Anbindung und Betriebsmodell. Dedicated Core ist der Standard, wenn ein Tier eine Leistungsgarantie, CPU-Familiensteuerung oder die Eignung für gemanagtes Auto-Scaling benötigt; vCPU ist die günstigere Wahl, wenn Konkurrenz akzeptabel ist; und ein Cube ist eine Instanz mit einem festen Template, dessen vCPU/RAM/NVMe-Paket unveränderlich ist, aber immer noch Add-on-Block Storage-Geräte anbinden kann. Entscheiden Sie die Klasse vor der Größenbestimmung, da die folgenschwersten Einschränkungen die permanenten sind, und bereitstellen Sie die Dedicated Core-Shell als Grundlage, auf der die REST des Moduls 4 aufbaut.

Wichtige Punkte:

• Führen Sie die vierwegige Entscheidung (Isolation, CPU-Familie, Block-Storage-Anbindung, Betriebsmodell) pro Tier und nicht pro Anwesen durch.
• VM Auto Scaling ist horizontal-only: es fügt und entfernt ganze Repliken unter einer Metrikpolitik, und die Replik-Compute-Konfiguration ist im Replik-Template zur Entwurfszeit festgelegt.
• Ein Cube-Template (vCPU, RAM, NVMe) ist unveränderlich, und sein NVMe kann nicht abgetrennt werden, aber ein Cube kann immer noch bis zu 23 Add-on-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 auf Dedicated Core erfordert einen Neustart; behandeln Sie sie als geplante Wartung.

Wichtige Begriffe:

• Dedicated Core Server: ein VM, das einen exklusiven physischen Core (zwei logische Cores) erhält, mit wählbarer CPU-Familie.
• vCPU Server: ein VM, das physische Cores teilt; kosteneffektiv, keine CPU-Familiensteuerung.
• Cube: eine Instanz mit einem festen Template und einem obligatorischen direkt angebundenen NVMe Volume; Template-Eigenschaften sind nach der Bereitstellung unveränderlich.
• Live-Vertikales-Skalieren (LVS): das Wachsen oder Schrumpfen einer laufenden VM-Ressourcen, das in der Einheit 4.3 ausführlich behandelt wird.

Weiterführende Literatur

• Einheit 4.2: Bilder, Datenträger und Cloud-Init (erweitert diese Server-Shell).
• Einheit 4.3: Elastizität und VM Auto Scaling (wie sich diese Ebene horizontal skalieren lässt).
• Einheit 2.4: Kostenarchitektur und FinOps (das Konfliktmodell als erster Kostenschalter).