10 Min. Lesezeit

Lernziele

Am Ende dieses Moduls werden Sie in der Lage sein:

  • Eine Block Storage-Ebene (HDD, SSD Standard, SSD Premium) einem Zugriffsmuster zuzuordnen und erklären, warum die ~100 GB SSD-Grenze die Berechnung für Boot- und Datenträger ändert.
  • Die Speicherattribute zu identifizieren, die nach der Bereitstellung unveränderlich sind (Speichertyp und Verfügbarkeitszone) und entsprechend planen.
  • Cloud-Init-Benutzerdaten verwenden, um einen Linux-Server beim ersten Start zu konfigurieren, und angeben, wo Cloud-Init anwendbar ist und wo nicht.
  • Speicher an den Server der Einheit 4.1 anhängen und konfigurieren, ein Bild zuweisen und Cloud-Init-Benutzerdaten im Data Center Designer bereitstellen.

Einheit 4.2: Bilder, Datenträger und Cloud-Init

Einführung

Ein Server-Shell ist inaktiv, bis es eine Festplatte zum Booten und eine Möglichkeit zur Konfiguration bei der ersten Boot-Vorgang hat. Zwei der Eigenschaften der Festplatte (ihr Speichertyp und ihre Verfügbarkeitszone) sind bei der Bereitstellung festgelegt und können danach nicht mehr geändert werden, was die Festplatten-Layout-Entscheidung zu einer Design-Entscheidung anstelle einer Laufzeit-Entscheidung macht. Diese Einheit erweitert den Dedicated Core-Server aus Einheit 4.1: es bindet Speicher ein, ordnet ein Boot-Bild zu und liefert cloud-init-Benutzerdaten, sodass der Server konfiguriert ankommt, anstatt unkonfiguriert. Es wiederholt nicht die Server-Erstellung.

1. Block Storage-Ebenen und die Leistungsuntergrenze

IONOS CLOUD Block Storage ist ein netzwerkangebundener iSCSI-Block-Speicher, der aktiv-aktiv über zwei Speicher-Server mit RAID innerhalb einer Region repliziert wird (vier physische Kopien insgesamt). Er kommt in drei Ebenen und die Ebene ist eine der zwei Festplatteneigenschaften, die Sie später nicht ändern können, daher wird sie pro Festplatte im Voraus ausgewählt.

Die dokumentierte Leistung pro Volumen ist die Grundlage für die Zuordnung der Ebene zum Zugriffsmuster:

Speicherleistung 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
Lese-Geschwindigkeit, vollständig zufällig 75 IOPS pro GB bei 4 KiB-Blockgröße 40 IOPS pro GB bei 4 KiB-Blockgröße
Schreib-Geschwindigkeit, vollständig zufällig 50 IOPS pro GB bei 4 KiB-Blockgröße 30 IOPS pro GB bei 4 KiB-Blockgröße
Speicherleistung HDD-Speicher
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 bestimmen die Entscheidung für die Ebene. Erstens ist die HDD-Leistung statisch und unabhängig von der Volumengröße, während die SSD-Leistung mit der Volumengröße skaliert: Die pro-GB-Raten oben bedeuten, dass eine kleine SSD eine langsame SSD ist. Zweitens empfiehlt IONOS CLOUD, SSD-Volumes von mindestens 100 GB zu buchen, um den vollen Nutzen zu erzielen; unter dieser Untergrenze ist die Leistung suboptimal, was der Grund dafür ist, dass SSD-Volumes unter ungefähr 100 GB nicht für Datenbank-Workloads empfohlen werden. Für ein SSD-Volume wird die Leistung vom System aus der Größe vorhergesagt, und für Volumes über 600 GB werden die pro-Volumen-Raten auf die dokumentierten Maxima gedeckelt (ein SSD-Premium-Volume erreicht maximal 45.000 Lese-IOPS und 600 MB/s sequenziell pro Volumen, vorausgesetzt, es gibt genügend Kerne und Arbeitsspeicher auf dem VM).

Die praktische Layoutregel folgt direkt daraus. Verwenden Sie HDD für kalte oder sequenzielle Daten (Sicherungen, Archive, Logs, die für den Export vorbereitet sind), wo dessen größenunabhängige Durchsatzrate ausreichend ist und dessen Preis von 0,04 EUR pro GB pro Monat der günstigste 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 latenzsensitive und Datenbank-Festplatten, wobei Sie jedes Datenbank-Volume auf oder über der 100-GB-Schwelle halten sollten, damit es in der Vollleistungsbandbreite liegt. Volumes reichen von 1 GiB bis hin zu 4096 GiB (4 TiB); ein VM kann bis zu 24 HDD- oder SSD-Standard-Volumes anhängen, aber nur vier SSD-Premium-Volumes, was eine Einschränkung ist, die Sie vor dem Aufbau einer hochwertigen Datenverteilung überprüfen sollten. Ebenen können auf einem VM gemischt werden, sodass ein häufiges Muster ein bescheidenes SSD-Premium-Boot-/Daten-Volume plus HDD-Volumes für den Massenspeicher ist.

2. Bilder, Unveränderlichkeit und Regionsverankerung

Eine Festplatte wird bootfähig, indem ein Bild mit ihr verknüpft wird: ein von IONOS CLOUD bereitgestelltes öffentliches Bild (Linux-Distributionen, einschließlich Alma, Debian, Rocky und Ubuntu, sowie Microsoft-Bilder) oder Ihr eigenes privates Bild, das über FTPS hochgeladen wird. Private Bilder und Snapshots sind regionsverankert: sie sind in der Region verwendbar, in der sie hochgeladen oder erstellt wurden, und IONOS CLOUD erstellt keine redundante Kopie über Regionen hinweg. Wenn eine Arbeitslast in zwei Regionen existieren muss, wird das Bild in jede Region hochgeladen oder kopiert; es gibt keine gemanagte Replikation von Bildern über Regionen hinweg, auf die man zurückgreifen kann.

Zwei Speicher-Eigenschaften sind nach der Bereitstellung unveränderlich und müssen von Anfang an richtig sein:

  • Speichertyp. Sie können einen Volume nicht zwischen HDD, SSD Standard und SSD Premium ändern, nachdem er bereitgestellt wurde. Eine Änderung der Ebene bedeutet die Erstellung eines neuen Volumes und die Migration von Daten.
  • Verfügbarkeitszone. Die Zone des Volumes ist bei der Erstellung festgelegt; die Auswahl von "Auto" ermöglicht es dem System, die optimale Zone zuzuweisen. Beachten Sie die Asymmetrie, die von Einheit 1.2 übernommen und in Modul 5 wiederholt wird: Block Storage bietet Zonen 1, 2, 3 und Auto, während Compute nur Zonen 1, 2 und Auto bietet. Block Storage Zone 3 existiert; Compute Zone 3 existiert nicht.

Die Größe des Volumes kann im Gegensatz dazu nach der Bereitstellung erhöht werden (auch auf einem laufenden Server, wenn das Betriebssystem dies unterstützt), aber nie verringert. Die sichere Größenstrategie besteht also darin, konservativ zu beginnen und zu wachsen, anstatt einen Datenträger zu überdimensionieren, den man nicht verkleinern kann. Snapshots, das Rollback-Mechanismus auf VM-Ebene, sind auch regionslokal und nicht inkrementell: ein Snapshot umfasst die gesamte zugewiesene Kapazität des Volumes (ein Volume mit 100 GB Kapazität, das 10 GB Daten enthält, erzeugt immer noch einen 100-GB-Snapshot) und ist ein Rollback-Tool und kein Datenbank-Backup. Ihre Rolle in der Datenkontinuitätsebene wird in Modul 5 behandelt.

3. Cloud-Init für die Konfiguration beim ersten Boot

Cloud-Init ist der Mechanismus, der einen frisch gestarteten Linux-Server von einem leeren Bild in einen konfigurierten Knoten ohne manuellen Login verwandelt. Sie liefern Benutzerdaten bei der Erstellung und Cloud-Init wendet sie während des ersten Boots an. Die Fähigkeitsgrenze ist genau und lohnt sich, genannt zu werden: Cloud-Init wird vollständig auf allen öffentlichen IONOS CLOUD Linux-Bildern unterstützt und die SSH-Schlüsselinjektion gilt für öffentliche IONOS CLOUD Linux-Bilder. Es wird nicht auf Windows unterstützt. Für die Konfiguration beim ersten Boot von 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, einschließlich eines Benutzerdatenskripts (beginnend mit #! oder Content-Type: text/x-shellscript), Cloud-Config-Daten (beginnend mit #cloud-config), einer Include-Datei, eines Upstart-Jobs, eines Cloud-Boothooks und Base64-codierter Payloads (die Cloud-Init decodiert und dann als einen der unterstützten Typen behandelt). Auf der Volume-Ressource werden die Cloud-Init-Benutzerdaten bei der Volume-Erstellung festgelegt und sind danach unveränderlich, was konsistent ist mit der Behandlung der Konfiguration beim ersten Boot als Teil der Bereitstellung und nicht als spätere Bearbeitung. Wenn Sie debuggen müssen, was Cloud-Init getan hat, befinden sich die Protokolle unter /var/log/cloud-init-output.log und /var/log/cloud-init.log.

Eine minimale Cloud-Config, die den FinCorp-Anwendungsbenutzer erstellt und ein Paket beim ersten Boot installiert, veranschaulicht die Form; der architektonische Punkt ist, dass dies genau einmal läuft, beim ersten Boot, und auf dem Volume bei der Erstellung festgelegt ist:

#cloud-config
packages:
  - nginx
runcmd:
  - systemctl enable --now nginx

DCD-Implementierung Schritt-für-Schritt

Diese Implementierung erweitert den Dedicated Core-Server, der in Einheit 4.1 bereitgestellt wurde. Sie bindet ein Boot-Volumen an die richtige Speicherstufe, ordnet ein Linux-Image zu und liefert cloud-init-Benutzerdaten, damit der FinCorp-Anwendungsserver konfiguriert wird. Die Voraussetzung ist die Server-Shell von Einheit 4.1 im FinCorp-VDC. Erstellen Sie den Server nicht neu.

Ziel: Speicher anhängen und konfigurieren; cloud-init-Benutzerdaten liefern.

Schritte (im Data Center Designer):

  1. Im Arbeitsbereich wählen Sie den Dedicated Core-Server von Einheit 4.1 aus. Ziehen Sie aus der Palette ein Speicherelement (HDD oder SSD) auf den Server, um es zu verbinden; der Server erweitert sich, um einen Speicherbereich anzuzeigen.
  2. Wählen Sie das neue Speicherelement aus, um den Inspector zu öffnen. Geben Sie ihm einen VDC-einzigartigen Namen.
  3. Wählen Sie den Speichertyp (für die FinCorp-App-Boot-/Datendiskette, SSD Premium). Dieser ist nach der Bereitstellung nicht mehr änderbar, daher bestätigen Sie die Stufe jetzt.
  4. Legen Sie die Verfügbarkeitszone fest (Auto lässt das System die optimale Zone zuweisen). Dies ist auch nach der Bereitstellung nicht mehr änderbar.
  5. Legen Sie die Größe fest und halten Sie ein SSD-Volume bei oder über der ~100-GB-Grenze für volle Leistung. Die Größe kann später erhöht, aber nie verringert werden.
  6. Unter Image ordnen Sie ein Image zu: Wählen Sie ein öffentliches IONOS CLOUD-Linux-Image oder wählen Sie eigene Images für ein privates hochgeladenes Image aus. Legen Sie das Root-/Administrator-Passwort (erforderlich für Remote-Konsole-Zugriff) und/oder einen SSH-Schlüssel fest.
  7. Markieren Sie das Volume als Boot-Gerät (klicken Sie auf BOOT / Boot-Gerät festlegen), damit der Server von diesem startet.
  8. Erweitern Sie das cloud-init-/Benutzerdaten-Feld und fügen Sie das cloud-config- oder Benutzerdatenskript ein. Bestätigen Sie, dass das Image cloud-init-Unterstützung meldet. Klicken Sie auf Änderungen bereitstellen, um sie anzuwenden.

Häufige Fehler:

  • Auswahl des falschen Speichertyps oder der falschen Zone, beides ist nach der Bereitstellung nicht mehr änderbar. Eine Änderung der Stufe oder ein Wechsel der Zone bedeutet, dass das Volume neu erstellt werden muss, nicht bearbeitet.
  • Platzieren einer Datenbank auf einem SSD-Volume mit weniger als 100 GB. Unterhalb der Grenze läuft das SSD mit suboptimalen IOPS; halten Sie Datenbank-Volumes bei oder über 100 GB.
  • Erwartung von cloud-init unter Windows. Cloud-init ist für öffentliche Linux-Images; SSH-Schlüsselinjektion ist auf öffentliche IONOS CLOUD-Linux-Images beschränkt.
  • Annahme, dass ein Image überall verfügbar ist. Private Images und Snapshots sind regionsspezifisch gesperrt; laden Sie sie in jede Region hoch oder kopieren Sie sie, in der sie benötigt werden.
  • Überdimensionierung einer Festplatte, um auf der sicheren Seite zu sein. Volumes können wachsen, aber nie schrumpfen, daher beginnen Sie konservativ und erhöhen sie später.

Zusammenfassung

Ein Server wird erst nützlich, wenn er eine Festplatte und eine Erstkonfiguration nach dem ersten Booten hat. Block Storage ist in drei Leistungsstufen unterteilt, deren Leistung und Preis sich unterscheiden, wobei die SSD-Leistung mit der Größe skaliert und eine Mindestgröße von etwa 100 GB vorhanden ist, die kleine SSDs (und daher kleine Datenbank-Festplatten) aus dem Vollleistungsband herausführt. Der Speichertyp und die Verfügbarkeitszone sind nach der Bereitstellung unveränderlich, während die Größe wachsen kann, aber nie schrumpfen kann, sodass die Festplatten-Layout-Entscheidung ein Design-Entscheid ist. Bilder sind regionsspezifisch gesperrt, mit keiner gemanagten Cross-Region-Replikation, und cloud-init konfiguriert öffentliche Linux-Bilder beim ersten Boot (nicht Windows), das einmal auf dem Volume bei der Erstellung festgelegt wird. Der Walkthrough erweitert den Server der Einheit 4.1 zu einem konfigurierten FinCorp-Anwendungs-Node.

Wichtige Punkte:

  • Die Leistung von HDD ist von der Größe unabhängig; die SSD-Leistung skaliert mit der Größe, sodass eine kleine SSD eine langsame SSD ist und DB-Volumes bei oder über etwa 100 GB liegen sollten.
  • Der Speichertyp und die Verfügbarkeitszone sind nach der Bereitstellung unveränderlich; die Größe kann wachsen, aber nie schrumpfen.
  • Block Storage hat Zonen 1, 2, 3 und Auto; Compute hat nur Zonen 1, 2 und Auto.
  • Bilder und Snapshots sind regionsspezifisch gesperrt, mit keiner gemanagten Cross-Region-Replikation.
  • Cloud-init konfiguriert öffentliche Linux-Bilder beim ersten Boot (SSH-Schlüssel-Injektion auf öffentlichen IONOS CLOUD Linux-Bildern); es wird nicht auf Windows unterstützt, und die Benutzerdaten sind auf dem Volume bei der Erstellung festgelegt.

Wichtige Begriffe:

  • SSD-Leistungsboden: die Mindestgröße von etwa 100 GB, unterhalb derer ein SSD-Volume mit suboptimalen IOPS läuft; der Grund, warum kleine DB-Festplatten nicht empfohlen werden.
  • Cloud-init: der Mechanismus für die Erstkonfiguration nach dem ersten Booten für öffentliche Linux-Bilder, als Benutzerdaten bereitgestellt und einmal beim Booten angewendet.
  • Regionsspezifisches Bild: ein privates Bild 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, den diese Einheit erweitert).
  • Einheit 5.7: DatenSchutz und Lebenszyklus (Schnappschüsse, Sicherung und PITR zu einer Kontinuitätsebene zusammengesetzt).
  • Einheit 7.3: LeistungsTechnik (SpeicherLeistungsMindestAnforderungen als LatenzHebel).