Seminar Cloud&Heat Titan / SecuStack – Speicherbetrieb mit Cinder, Glance und Objektspeicher

Inhaltsübersicht

• Seminarprofil
• Lernziele
• Zielgruppe und Voraussetzungen
• Seminarinhalte
• Praxislabor
• Methoden und Arbeitsweise

Seminarprofil

Das Seminar behandelt Block-, Image- und Objektspeicher als unterschiedliche Datenservices. Serviceklassen, Volume-Lifecycle, Image-Freigabe, Verschlüsselung, Backup, Restore und Performance-Diagnose werden in einem gemeinsamen Datenklassensystem verbunden.

Lernziele

• Datenklassen den passenden Storage-Diensten zuordnen
• Cinder-Volumes, Typen, Snapshots und Attachments sicher betreiben
• Glance-Images kontrolliert aufnehmen, freigeben und ausmustern
• Objektspeicher mit Lebenszyklus- und Berechtigungskonzept planen
• Storage-Engpässe und Restore-Fälle schichtweise bearbeiten

Zielgruppe und Voraussetzungen

Zielgruppe: OpenStack-Administration, Storagebetrieb, Cloud Operations, Backup-Verantwortung und technische Anwendungsbetreuung.

Voraussetzungen: Grundkenntnisse in OpenStack, Linux-Dateisystemen und Storage-Konzepten. Netzwerkgrundlagen werden vorausgesetzt.

Seminarinhalte

Tag 1: Storage-Architektur, Cinder und Glance

Die Themen werden in einer festen Reihenfolge aus Einordnung, technischer Umsetzung, Kontrolle und dokumentierter Prüfung bearbeitet.

Storage-Architektur und Datenklassen

Block-, Image-, Objekt- und lokale Speicherfunktionen werden nach Persistenz, Leistung, Schutzbedarf und Wiederherstellbarkeit eingeordnet.

1. Schritt 1 – Datenarten klassifizieren: Betriebssystem-Images, Boot-Volumes, Anwendungsdaten, Backups, Protokolle und temporäre Daten werden getrennt betrachtet.
2. Schritt 2 – Dienstzuordnung treffen: Glance, Cinder, Objektspeicher und lokale Ephemeral-Datenträger werden nach Lebenszyklus und Zugriffsmuster ausgewählt.
3. Schritt 3 – Leistungsziele definieren: Kapazität, IOPS, Latenz, Durchsatz und Wiederherstellungsanforderungen werden pro Datenklasse festgelegt.
4. Schritt 4 – Fehlerdomänen prüfen: Knoten-, Datenträger-, Rack- und Standortausfälle werden gegen Replikation und Backupstrategie bewertet.

Praxisbezug: Erstellung einer Datenklassenmatrix mit passendem Storage-Dienst, Schutz und Wiederherstellungsziel.

Cinder-Volumes und Snapshots

Cinder stellt persistente Blockspeicher bereit und steuert Typen, Backends, Anhängen, Snapshots und Migrationen.

1. Schritt 1 – Volume-Typen definieren: Leistung, Redundanz, Verschlüsselung und Backend-Merkmale werden in verständliche Serviceklassen übersetzt.
2. Schritt 2 – Volume-Lifecycle durchführen: Erzeugung, Anhängen, Dateisystemnutzung, Trennen, Erweitern und Löschen werden kontrolliert ausgeführt.
3. Schritt 3 – Snapshots bewerten: Konsistenz, Abhängigkeit vom Quellvolume, Aufbewahrung und Eignung für Wiederherstellung werden geprüft.
4. Schritt 4 – Fehler analysieren: Status, Attachments, Backend-Meldungen und Hostzustand werden bei festhängenden Volumes korreliert.

Praxisbezug: Bereitstellung, Erweiterung, Snapshot und Wiederherstellung eines verschlüsselten Testvolumes.

Glance und Image-Lifecycle

Glance verwaltet Images, Metadaten und Freigaben als zentrale Grundlage für standardisierte Workloads.

1. Schritt 1 – Image aufnehmen: Dateiformat, Containerformat, Prüfsumme, Signatur und Mindestanforderungen werden validiert.
2. Schritt 2 – Metadaten pflegen: Betriebssystem, Version, Architektur, Treiber, Härtungsstand und Auslaufdatum werden eindeutig beschrieben.
3. Schritt 3 – Zugriff steuern: Private, geteilte, Community- oder öffentliche Sichtbarkeit wird entsprechend dem Freigabemodell gewählt.
4. Schritt 4 – Versionen bereinigen: Ersetzte Images werden gesperrt, Abhängigkeiten geprüft und nach definierter Frist entfernt.

Praxisbezug: Durchführung eines kontrollierten Image-Updates mit paralleler Altversion und dokumentierter Rücknahme.

Tag 2: Objektspeicher, Verschlüsselung und Sicherung

Die Themen werden in einer festen Reihenfolge aus Einordnung, technischer Umsetzung, Kontrolle und dokumentierter Prüfung bearbeitet.

Objektspeicher und unveränderbare Ablagen

Objektspeicher eignet sich für große, unstrukturierte Datenbestände, Artefakte und je nach Auslegung für Backup- oder Archivzwecke.

1. Schritt 1 – Namespace planen: Container beziehungsweise Buckets, Objektpfade, Mandantentrennung und Namenskonventionen werden festgelegt.
2. Schritt 2 – Zugriff absichern: Rollen, temporäre Zugriffe, Netzwerkpfade und Verschlüsselungsanforderungen werden definiert.
3. Schritt 3 – Lebenszyklus steuern: Versionierung, Aufbewahrung, Ablaufregeln und gegebenenfalls Unveränderbarkeit werden nach Datenklasse eingerichtet.
4. Schritt 4 – Integrität prüfen: Prüfsummen, Stichproben, Kapazitätsentwicklung und Wiederlesbarkeit werden regelmäßig kontrolliert.

Praxisbezug: Entwurf einer Objektablage für Artefakte und Backups mit Aufbewahrungs- und Berechtigungskonzept.

Verschlüsselung ruhender Daten

Verschlüsselung ruhender Daten wird für Volumes, Backups, Objektablagen, Datenbanken und administrative Endgeräte differenziert umgesetzt.

1. Schritt 1 – Datenorte erfassen: Produktivdaten, Replikate, Snapshots, Backups, temporäre Dateien und Logs werden berücksichtigt.
2. Schritt 2 – Verschlüsselungsebene wählen: Datenträger-, Backend-, Volume- oder Anwendungsebene wird nach Bedrohungsmodell ausgewählt.
3. Schritt 3 – Schlüsselzuordnung prüfen: Mandantentrennung, Rotation, Backup und Wiederherstellung des Schlüsselmaterials werden sichergestellt.
4. Schritt 4 – Wirksamkeit testen: Unberechtigter Direktzugriff, Restore und Schlüsselwechsel werden kontrolliert geprüft.

Praxisbezug: Bewertung mehrerer Datenklassen und Auswahl einer passenden Verschlüsselungsebene.

Sicherung von Plattform- und Mandantendaten

OpenStack-Steuerungsdaten und Mandantenressourcen benötigen unterschiedliche Sicherungsverfahren und Verantwortlichkeiten.

1. Schritt 1 – Plattformdaten sichern: Datenbanken, Schlüsselkonfigurationen, Zertifikate, Custom Resources und betriebliche Konfiguration werden konsistent erfasst.
2. Schritt 2 – Mandantendaten sichern: Volumes, Objekte, Images und anwendungseigene Daten werden nach Serviceklasse und Verantwortungsmodell behandelt.
3. Schritt 3 – Sicherungsjobs überwachen: Laufzeit, Datenmenge, Erfolgsstatus, Fehler, Aufbewahrung und Replikationsstand werden zentral kontrolliert.
4. Schritt 4 – Wiederlesbarkeit prüfen: Stichproben und automatisierte Integritätsprüfungen bestätigen, dass Sicherungen vollständig und entschlüsselbar sind.

Praxisbezug: Planung eines Sicherungslaufs für Steuerungsdaten und ein mandantenseitiges Anwendungsvolume.

Tag 3: Diagnose, Wiederherstellung und Notfallbezug

Die Themen werden in einer festen Reihenfolge aus Einordnung, technischer Umsetzung, Kontrolle und dokumentierter Prüfung bearbeitet.

Storage-Diagnose und Engpassanalyse

Storage-Probleme werden zwischen OpenStack-Dienst, Backend, Netzwerk, Host und Gastbetriebssystem abgegrenzt.

1. Schritt 1 – Messwerte sichern: Latenz, IOPS, Durchsatz, Queue-Tiefe, Fehlerstatus und betroffener Zeitraum werden erfasst.
2. Schritt 2 – Steuerungspfad prüfen: Cinder- und Glance-Status, Scheduler-Entscheidung, Backend-Zuordnung und Attachments werden kontrolliert.
3. Schritt 3 – Datenpfad untersuchen: Storage-Netz, Multipath, Host-Geräte und Gastbetriebssystem werden auf Fehler und Sättigung geprüft.
4. Schritt 4 – Ursache bestätigen: Gezielte Gegenprobe, Lastreduktion oder Komponentenwechsel belegt die vermutete Engpassursache.

Praxisbezug: Analyse eines langsamen Volumes mit Trennung von Backend-, Netzwerk- und Gastursachen.

Restore-Verfahren und Wiederanlaufreihenfolge

Wiederherstellung wird als abhängige Reihenfolge von Basisinfrastruktur, Plattformdiensten, Konfiguration und Nutzdaten geplant.

1. Schritt 1 – Wiederherstellungsziel bestimmen: Einzelobjekt, Dienst, Cluster, Standort oder vollständige Plattform werden klar voneinander abgegrenzt.
2. Schritt 2 – Abhängigkeiten ordnen: Identität, Datenbanken, Message Queue, Kubernetes, Operatoren, OpenStack-Dienste und Mandantendaten werden in eine Reihenfolge gebracht.
3. Schritt 3 – Restore isoliert ausführen: Zieldomäne, Netzwerkzugriff, Schlüsselmaterial und Konflikte mit produktiven Ressourcen werden vorab kontrolliert.
4. Schritt 4 – Funktion nachweisen: Integrität, API-Funktion, Zugriffsrechte, Netzwerk, Storage und Beispielworkload werden nach der Wiederherstellung getestet.

Praxisbezug: Durchführung eines dokumentierten Restore-Tests für Konfiguration und ein Testvolume.

Disaster-Recovery-Tests

Notfallverfahren gelten erst nach einem realistischen, wiederholbaren und ausgewerteten Test als belastbar.

1. Schritt 1 – Szenario wählen: Ausfall von Management, Storage, mehreren Knoten, Rack oder Standort wird mit klaren Annahmen beschrieben.
2. Schritt 2 – Erfolgskriterien definieren: RTO, RPO, Datenintegrität, Mindestservice und Kommunikationsziele werden messbar festgelegt.
3. Schritt 3 – Übung steuern: Startzustand, Freigabe, Beobachter, Sicherheitsgrenzen und Abbruchkriterien werden vor Beginn festgehalten.
4. Schritt 4 – Erkenntnisse umsetzen: Zeitabweichungen, fehlende Zugänge, unklare Rollen und technische Lücken werden in konkrete Maßnahmen überführt.

Praxisbezug: Planung einer Tabletop- und einer technischen Wiederanlaufübung mit messbaren Kriterien.

Praxislabor

• Erstellung einer Datenklassenmatrix mit passendem Storage-Dienst, Schutz und Wiederherstellungsziel.
• Durchführung eines kontrollierten Image-Updates mit paralleler Altversion und dokumentierter Rücknahme.
• Entwurf einer Objektablage für Artefakte und Backups mit Aufbewahrungs- und Berechtigungskonzept.
• Planung eines Sicherungslaufs für Steuerungsdaten und ein mandantenseitiges Anwendungsvolume.
• Analyse eines langsamen Volumes mit Trennung von Backend-, Netzwerk- und Gastursachen.
• Planung einer Tabletop- und einer technischen Wiederanlaufübung mit messbaren Kriterien.

Methoden und Arbeitsweise

Fachliche Einordnung, strukturierte Demonstrationen, geführte Systemübungen, technische Prüflisten und dokumentierte Störungsszenarien wechseln sich ab. Jeder Arbeitsschritt wird mit Ausgangszustand, erwarteter Wirkung, Prüfkriterium und Rückfallmöglichkeit beschrieben. Die Übungen verwenden realistische Rollen- und Fehlerbilder; produktive Zugangsdaten oder externe Verbindungen sind nicht erforderlich.