Einheit 4.2: Images, Disks und Cloud-Init
Einführung
Eine Server-Shell ist inaktiv, bis sie eine Festplatte zum Hochfahren und eine Möglichkeit zur Konfiguration beim ersten Start besitzt. Zwei Eigenschaften der Festplatte (der Speichertyp und die Verfügbarkeitszone) werden bei der Bereitstellung festgelegt und können danach nicht mehr geändert werden. Dadurch ist die Festplattenstruktur eine Designentscheidung und keine Laufzeitentscheidung. Diese Einheit erweitert den Dedicated Core-Server aus Einheit 4.1: Sie hängt Speicher an, verknüpft ein Boot-Image und stellt Cloud-Init-Benutzerdaten bereit, damit der Server konfiguriert ankommt und nicht im Rohzustand. Die Erstellung des Servers wird nicht wiederholt.
1. Block Storage Tiers and the Performance Floor
IONOS CLOUD Block Storage ist netzwerkgebundenes iSCSI-Block-Storage, das aktiv-aktiv über zwei Storage-Server repliziert wird, wobei innerhalb jedes Servers RAID eingesetzt wird (insgesamt vier physische Kopien) innerhalb einer Region. Es ist in drei Tiers verfügbar, und das Tier ist eine der beiden Datenträger-Eigenschaften, die später nicht geändert werden können, weshalb es vorab pro Datenträger festgelegt wird.
Die dokumentierte Leistung pro Volume bildet die Grundlage für die Zuordnung des Tiers zum Zugriffsmuster:
| Storage Performance | SSD Premium | SSD Standard |
|---|---|---|
| Lese-/Schreibgeschwindigkeit, sequenziell | 1 MiB/s pro GB bei 1 MiB Blockgröße | 0,5 MiB/s pro GB bei 1 MiB Blockgröße |
| Leseleistung, vollständig zufällig | 75 IOPS pro GB bei 4 KiB Blockgröße | 40 IOPS pro GB bei 4 KiB Blockgröße |
| Schreibleistung, vollständig zufällig | 50 IOPS pro GB bei 4 KiB Blockgröße | 30 IOPS pro GB bei 4 KiB Blockgröße |
| Storage Performance | HDD Storage |
|---|---|
| Lese-/Schreibgeschwindigkeit, sequenziell | 200 MiB/s bei 1 MiB Blockgröße |
| Lese-/Schreibgeschwindigkeit, vollständig zufällig, regulär | 1.100 IOPS bei 4 KiB Blockgröße |
| Lese-/Schreibgeschwindigkeit, vollständig zufällig, Burst | 2.500 IOPS bei 4 KiB Blockgröße |
Zwei Fakten steuern die Entscheidung für ein bestimmtes Tier. Erstens ist die HDD-Leistung statisch und unabhängig von der Volume-Größe, während die SSD-Leistung mit der Volume-Größe skaliert: Die oben genannten Raten pro GB bedeuten, dass ein kleines SSD-Volume ein langsames SSD-Volume ist. Zweitens empfiehlt IONOS CLOUD, SSD-Volumes mit mindestens 100 GB zu buchen, um den vollen Nutzen zu erzielen; unterhalb dieser Untergrenze ist die Leistung suboptimal, weshalb SSD-Volumes unter etwa 100 GB für Datenbank-Workloads nicht empfohlen werden. Für ein SSD-Volume prognostiziert das System die Leistung anhand der Größe, und für Volumes über 600 GB sind die Raten pro Volume auf die dokumentierten Maximalwerte begrenzt (ein SSD Premium-Volume erreicht maximal 45.000 Lese-IOPS und 600 MB/s sequenziell pro Volume, vorausgesetzt, die VM verfügt über genügend Kerne und RAM).
Die praktische Layout-Regel folgt direkt daraus. Verwenden Sie HDD für kalte oder sequenzielle Daten (Sicherungen, Archive, für den Export vorbereitete Logs), bei denen die größenunabhängige Durchsatzleistung ausreicht und der Preis von 0,04 EUR pro GB pro Monat am günstigsten ist. Verwenden Sie SSD Standard (0,07 EUR pro GB pro Monat) für allgemeine Workloads und SSD Premium (0,15 EUR pro GB pro Monat) für latenzempfindliche und Datenbank-Datenträger, wobei jedes Datenbank-Volume auf oder über der 100-GB-Untergrenze gehalten wird, damit es im Bereich der vollen Leistung liegt. Volumes reichen von 1 GiB bis zu 4096 GiB (4 TiB); eine VM kann bis zu 24 HDD- oder SSD Standard-Volumes anbinden, aber nur 4 SSD Premium-Volumes, was eine Einschränkung ist, die vor der Ausbreitung eines Hochstufen-Datenlayouts geprüft werden sollte. Tiers können auf einer VM gemischt werden, daher ist ein häufiges Muster ein moderater SSD Premium-Boot-/Datendatenträger plus HDD-Volumes für Massendaten.
2. Images, Unveränderlichkeit und Regionsbindung
Eine Festplatte wird bootfähig, indem ein Image damit verknüpft wird: ein öffentliches Image von IONOS CLOUD (Linux-Distributionen, darunter Alma, Debian, Rocky und Ubuntu, sowie Microsoft-Images) oder ein eigenes privates Image, das per FTPS hochgeladen wird. Private Images und Snapshots sind an eine Region gebunden: Sie sind in der Region nutzbar, in der sie hochgeladen oder erstellt wurden, und IONOS CLOUD erstellt für sie keine Redundanz über Regionen hinweg. Wenn eine Workload in zwei Regionen vorhanden sein muss, wird das Image in jede Region hochgeladen oder kopiert; eine verwaltete Replikation von Images über Regionen hinweg ist nicht verfügbar.
Zwei Speicherattribute sind nach der Bereitstellung unveränderlich und müssen daher von Anfang an korrekt gewählt werden:
- Speichertyp. Nach der Bereitstellung kann ein Volume nicht zwischen HDD, SSD Standard und SSD Premium umgestellt werden. Eine Änderung des Speichertyps erfordert die Erstellung eines neuen Volumes und die Migration der Daten.
- Verfügbarkeitszone. Die Zone des Volumes wird bei der Erstellung festgelegt; die Auswahl von Auto lässt das System die optimale Zone zuweisen. Beachten Sie die Asymmetrie aus Einheit 1.2, die in Modul 5 erneut behandelt wird: Block Storage bietet die Zonen 1, 2, 3 und Auto, während Compute nur die Zonen 1, 2 und Auto anbietet. Block Storage Zone 3 existiert; eine Compute Zone 3 existiert nicht.
Die Volume-Größe kann im Gegensatz dazu nach der Bereitstellung vergrößert werden (auch auf einem laufenden Server, sofern das Betriebssystem dies unterstützt), aber niemals verkleinert. Die sichere Strategie bei der Dimensionierung besteht daher darin, konservativ zu beginnen und zu wachsen, anstatt eine Festplatte zu überdimensionieren, die nicht verkleinert werden kann. Snapshots, der Rollback-Mechanismus auf VM-Ebene, sind ebenfalls regionsspezifisch und nicht inkrementell: Ein Snapshot deckt die gesamte zugewiesene Kapazität des Volumes ab (ein 100-GB-Volume mit 10 GB Daten erzeugt weiterhin einen 100-GB-Snapshot) und ist ein Rollback-Werkzeug, keine Datenbank-Sicherung. Ihre Rolle in der Ebene der Datenkontinuität wird in Modul 5 behandelt.
3. Cloud-Init für die Erststart-Konfiguration
Cloud-init ist der Mechanismus, der einen frisch gestarteten Linux-Server von einem nackten Image in einen konfigurierten Knoten verwandelt, ohne dass ein manueller Login erforderlich ist. Sie geben Benutzerdaten zum Zeitpunkt der Erstellung an, und cloud-init wendet sie während des ersten Starts an. Die Funktionsgrenze ist präzise und sollte klar formuliert werden: cloud-init wird auf allen öffentlichen IONOS CLOUD Linux-Images vollständig unterstützt, und die SSH-Schlüssel-Injektion gilt für öffentliche IONOS CLOUD Linux-Images. Es wird nicht auf Windows unterstützt. Für die Erststart-Konfiguration auf Windows greifen Sie auf einen anderen Mechanismus zurück, nicht auf cloud-init.
Benutzerdaten werden als Shell-Skript oder als cloud-config YAML geschrieben, und IONOS CLOUD cloud-init akzeptiert mehrere Formate, darunter ein user-data-Skript (beginnend mit #! oder Content-Type: text/x-shellscript), cloud-config-Daten (beginnend mit #cloud-config), eine Include-Datei, ein upstart-Job, ein cloud boothook und base64-kodierte Nutzlasten (die cloud-init entschlüsselt und dann als einen der unterstützten Typen verarbeitet). Bei der Volume-Ressource werden die cloud-init-Benutzerdaten bei der Volume-Erstellung festgelegt und sind danach unveränderlich, was mit der Behandlung der Erststart-Konfiguration als Teil der Provisionierung und nicht als spätere Bearbeitung übereinstimmt. Wenn Sie debuggen müssen, was cloud-init ausgeführt hat, befinden sich die Protokolle unter /var/log/cloud-init-output.log und /var/log/cloud-init.log.
Ein minimales cloud-config, das den FinCorp-Anwendungsnutzer erstellt und beim ersten Start ein Paket installiert, veranschaulicht die Struktur; der architektonische Punkt ist, dass dies genau einmal, beim ersten Start, ausgeführt wird und bei der Erstellung auf dem Volume festgelegt ist:
#cloud-config
packages:
- nginx
runcmd:
- systemctl enable --now nginx
DCD-Implementierungsanleitung
Diese Anleitung baut auf dem in Einheit 4.1 bereitgestellten Dedicated Core Server auf. Sie hängt ein Boot-Volume auf der rechten Speicherstufe an, verknüpft ein Linux-Image und stellt cloud-init-Benutzerdaten bereit, damit der Anwendungsserver von FinCorp in einem konfigurierten Zustand bereitsteht. Voraussetzung ist die Serverstruktur aus Einheit 4.1 im FinCorp-VDC. Der Server darf nicht neu erstellt werden.
Bauziel: Speicher anhängen und konfigurieren; cloud-init-Benutzerdaten bereitstellen.
Schritte (im Data Center Designer):
- Wählen Sie im Workspace den Dedicated Core Server aus Einheit 4.1 aus. Ziehen Sie aus der Palette ein Speicherelement (HDD oder SSD) auf den Server, um es zu verbinden; der Server wird erweitert, um einen Speicherbereich anzuzeigen.
- Wählen Sie das neue Speicherelement aus, um den Inspector zu öffnen. Vergeben Sie einen im VDC eindeutigen Namen.
- Wählen Sie den Speichertyp (für die Boot-/Datenscheibe der FinCorp-Anwendung: SSD Premium). Dieser Wert ist nach der Bereitstellung nicht mehr änderbar, daher die Stufe jetzt bestätigen.
- Setzen Sie die Verfügbarkeitszone (Auto lässt das System die optimale Zone zuweisen). Auch dieser Wert ist nach der Bereitstellung nicht mehr änderbar.
- Setzen Sie die Größe und halten Sie ein SSD-Volume bei mindestens ca. 100 GB, um die volle Leistungsfähigkeit zu gewährleisten. Die Größe kann später erhöht, aber nie verkleinert werden.
- Unter Image ein Image verknüpfen: Wählen Sie ein öffentliches Linux-Image von IONOS CLOUD oder wählen Sie Own Images für ein hochgeladenes privates Image. Setzen Sie das Root-/Administrator-Passwort (erforderlich für den Remote-Console-Zugriff) und/oder einen SSH-Schlüssel.
- Markieren Sie das Volume als Boot-Gerät (klicken Sie auf BOOT / Als Boot-Gerät festlegen), damit der Server von diesem startet.
- Falten Sie das Feld für cloud-init / Benutzerdaten auf und fügen Sie das cloud-config- oder Benutzerdaten-Skript ein. Stellen Sie sicher, dass das Image cloud-init-Unterstützung meldet. Klicken Sie auf Änderungen bereitstellen, um die Änderungen anzuwenden.
Häufige Fehler:
- Falsche Auswahl des Speichertyps oder der Zone, da beide Werte nicht änderbar sind. Eine Änderung der Stufe oder der Zone bedeutet, dass das Volume neu erstellt werden muss, nicht bearbeitet.
- Platzierung einer Datenbank auf einem SSD-Volume unter 100 GB. Unterhalb dieses Mindestwerts arbeitet das SSD mit suboptimalen IOPS; halten Sie Datenbank-Volumes bei mindestens 100 GB.
- Erwartung von cloud-init auf Windows. Cloud-init ist für öffentliche Linux-Images bestimmt; die SSH-Schlüssel-Injektion ist auf öffentliche IONOS CLOUD Linux-Images beschränkt.
- Annahme, dass ein Image überall verfügbar ist. Private Images und Snapshots sind regiongebunden; laden Sie sie in jede benötigte Region hoch oder kopieren Sie sie dorthin.
- Überdimensionierung einer Festplatte aus Sicherheitsgründen. Volumes können wachsen, aber nie schrumpfen, daher konservativ beginnen und später vergrößern.
Zusammenfassung
Ein Server wird erst dann nützlich, wenn er über eine Festplatte und eine Erststart-Konfiguration verfügt. Block Storage ist in drei Stufen erhältlich, deren Leistung und Preis unterschiedlich sind. Die SSD-Leistung skaliert mit der Größe, wobei eine Untergrenze von ca. 100 GB besteht, die kleine SSDs (und damit kleine Datenbank-Festplatten) aus dem Bereich der vollen Leistung ausschließt. Der Speichertyp und die Verfügbarkeitszone sind nach der Bereitstellung nicht mehr änderbar, während die Größe zwar vergrößert, aber nie verkleinert werden kann. Daher ist die Festplattenanordnung eine Designentscheidung. Images sind an eine Region gebunden, und es gibt keine verwaltete Replikation über Regionen hinweg. cloud-init konfiguriert öffentliche Linux-Images beim ersten Start (nicht Windows) und wird einmalig beim Erstellen des Volumes festgelegt. Die Schritt-für-Schritt-Anleitung erweitert den Server aus Einheit 4.1 zu einem konfigurierten Anwendungsknoten von FinCorp.
Wichtige Punkte:
- Die HDD-Leistung ist größenunabhängig; die SSD-Leistung skaliert mit der Größe. Daher ist eine kleine SSD eine langsame SSD, und Datenvolumes sollten mindestens ca. 100 GB groß sein.
- Der Speichertyp und die Verfügbarkeitszone sind nach der Bereitstellung nicht mehr änderbar; die Größe kann vergrößert, aber nie verkleinert werden.
- Block Storage bietet die Zonen 1, 2, 3 und Auto; Compute bietet nur die Zonen 1, 2 und Auto.
- Images und Snapshots sind an eine Region gebunden, und es gibt keine verwaltete Replikation über Regionen hinweg.
- cloud-init konfiguriert öffentliche Linux-Images beim ersten Start (SSH-Schlüssel-Injektion auf öffentlichen IONOS CLOUD Linux-Images); es wird auf Windows nicht unterstützt, und die Benutzereinstellungen werden beim Erstellen auf dem Volume festgelegt.
Wichtige Begriffe:
- SSD-Leistungsuntergrenze: die Mindestgröße von ca. 100 GB, unterhalb derer ein SSD-Volumen mit suboptimalen IOPS arbeitet; der Grund, warum kleine Datenbank-Festplatten nicht empfohlen werden.
- cloud-init: der Konfigurationsmechanismus für den ersten Start öffentlicher Linux-Images, der als Benutzereinstellungen bereitgestellt und einmalig beim Start angewendet wird.
- Regiongebundenes Image: ein privates Image oder Snapshot, das nur in der Region verwendet werden kann, in der es hochgeladen oder erstellt wurde.
Weitere Lektüre
- Einheit 4.1: Auswahl der Compute-Klasse (der Server, auf den sich diese Einheit bezieht).
- Einheit 5.7: Datensicherung und Lebenszyklus (Snapshots, Sicherung und PITR, die zu einer Kontinuitätsebene zusammengesetzt werden).
- Einheit 7.3: Performance Engineering (Speicherleistungsuntergrenzen als Hebel für die Latenz).