Seminar Cloud&Heat Titan / SecuStack – Architektur und Komponenten

Inhaltsübersicht

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

Seminarprofil

Das Seminar vermittelt ein durchgängiges Architekturverständnis der physischen, cloudtechnischen und betrieblichen Schichten. Die Zusammenhänge zwischen Titan-Hardware, Management- und Datenebenen, Kubernetes, Yaook und OpenStack werden mit Fehlerdomänen und Kapazitätsreserven verbunden.

Lernziele

• die Plattform in physische, orchestrierende und cloudtechnische Schichten zerlegen
• Steuerungs-, Management- und Datenpfade nachvollziehbar dokumentieren
• Fehlerdomänen und Redundanzbeziehungen bewerten
• OpenStack-Dienste und Yaook-Komponenten funktional einordnen
• Kapazität und Reserven aus technischen Anforderungen ableiten

Zielgruppe und Voraussetzungen

Zielgruppe: Cloud-Architektur, Plattformadministration, Rechenzentrumsbetrieb, IT-Sicherheit, technische Projektleitung und Presales-Architektur.

Voraussetzungen: Solide Grundlagen in Virtualisierung, IP-Netzwerken und Linux. Erste Berührungspunkte mit OpenStack oder Kubernetes erleichtern den Einstieg.

Seminarinhalte

Tag 1: Produktkontext, Referenzarchitektur und physische Basis

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

Einordnung von Titan und SecuStack

Die Einheit ordnet die Plattform als vorkonfigurierte, skalierbare On-Premises-Cloud für souveräne und besonders geschützte Betriebsmodelle ein.

1. Schritt 1 – Anwendungsfall abgrenzen: Schutzbedarf, Datenlokation, Verfügbarkeitsziel und erforderliche Offline-Fähigkeit werden als belastbare Rahmenbedingungen erfasst.
2. Schritt 2 – Leistungsumfang strukturieren: Hardware, Cloud-Plattform, Betriebswerkzeuge, Sicherheitsfunktionen und optionale Betriebsleistungen werden voneinander abgegrenzt.
3. Schritt 3 – Betriebsmodell zuordnen: Eigenbetrieb, unterstützter Betrieb und vollständig betreute Varianten werden anhand von Verantwortlichkeiten und Reaktionszeiten verglichen.
4. Schritt 4 – Zielbild dokumentieren: Die gewählte Ausbaustufe wird mit Annahmen, Abhängigkeiten, offenen Entscheidungen und Abnahmekriterien festgehalten.

Praxisbezug: Erstellung eines kompakten Zielbilds für einen beispielhaften KRITIS-nahen oder souveränen On-Premises-Einsatz.

Referenzarchitektur und Schichtenmodell

Die Plattform wird in physische Infrastruktur, Kubernetes- und Operator-Ebene, OpenStack-Dienste, Sicherheitsfunktionen und Betriebsprozesse zerlegt.

1. Schritt 1 – Schichten identifizieren: Rack, Compute, Storage, Netzwerk, Management, Kubernetes, Yaook-Operatoren und OpenStack-Dienste werden in einer Gesamtübersicht verortet.
2. Schritt 2 – Abhängigkeiten erfassen: Steuerungs-, Daten- und Verwaltungswege werden zwischen den Schichten nachvollzogen und kritische Kopplungen markiert.
3. Schritt 3 – Fehlerdomänen bilden: Ausfallbereiche für Strom, Kühlung, Netzwerk, Hosts, Cluster-Komponenten und Plattformdienste werden systematisch getrennt.
4. Schritt 4 – Architektur bewerten: Redundanz, Wartbarkeit, Skalierbarkeit und Sicherheitszonen werden gegen die zuvor definierten Anforderungen geprüft.

Praxisbezug: Aufbau eines Architekturdiagramms mit Schichten, Schnittstellen, Vertrauensgrenzen und Fehlerdomänen.

Physische Infrastruktur und Hardwaretopologie

Die physische Basis wird vom Rack über Server und Netzkomponenten bis zu Stromversorgung und Sensorik betrachtet.

1. Schritt 1 – Komponenten inventarisieren: Servertypen, Netzkomponenten, Massenspeicher, Managementschnittstellen, PDUs und Sensoren werden mit ihrer Funktion erfasst.
2. Schritt 2 – Verkabelung nachvollziehen: Management-, Storage- und Datennetze sowie Strompfade werden den jeweiligen Ports und Redundanzgruppen zugeordnet.
3. Schritt 3 – Ressourcenprofile bilden: CPU, Arbeitsspeicher, lokale Datenträger, Netzbandbreite und Reservekapazitäten werden pro Knotenklasse dokumentiert.
4. Schritt 4 – Fehlerauswirkungen prüfen: Der Ausfall einzelner Server, Switches, Strompfade oder Sensoren wird gegen das geplante Betriebsmodell bewertet.

Praxisbezug: Erstellung einer vereinfachten Rack- und Verkabelungsdokumentation für eine Titan-Ausbaustufe.

Tag 2: Vertrauenszonen, Cloud-Dienste und Sizing

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

Steuerungs-, Management- und Datenebenen

Getrennte Ebenen reduzieren Fehlerfolgen und schaffen kontrollierbare Zugriffswege für Administration, Plattformdienste und Nutzlasten.

1. Schritt 1 – Datenflüsse klassifizieren: BMC-Zugriffe, Kubernetes-Steuerung, OpenStack-APIs, Storage-Verkehr, Tenant-Verkehr und Monitoring werden getrennt erfasst.
2. Schritt 2 – Vertrauenszonen festlegen: Administrations-, Infrastruktur-, Service- und Mandantenzonen werden mit erlaubten Kommunikationsbeziehungen definiert.
3. Schritt 3 – Zugriffswege begrenzen: Jump Hosts, Management-VPN, Mehrfaktorverfahren und rollenbasierte Freigaben werden den administrativen Tätigkeiten zugeordnet.
4. Schritt 4 – Kontrollpunkte bestimmen: Protokollierung, Filterung, Zertifikatsprüfung und Anomalieerkennung werden an geeigneten Übergängen vorgesehen.

Praxisbezug: Entwurf einer Kommunikationsmatrix mit Quelle, Ziel, Protokoll, Zweck und Genehmigungsstatus.

OpenStack-Service- und Ressourcenmodell

Die zentralen OpenStack-Dienste werden als zusammenhängende Steuerungsebene für Identität, Compute, Netzwerk, Images und Storage eingeordnet.

1. Schritt 1 – Dienste zuordnen: Keystone, Nova, Neutron, Glance, Cinder, Horizon und ergänzende Dienste werden nach Aufgabe und Schnittstelle klassifiziert.
2. Schritt 2 – Ressourcenbeziehungen lesen: Projekt, Benutzer, Rolle, Netzwerk, Subnetz, Port, Image, Flavor, Volume und Instanz werden in ihrer Abhängigkeit dargestellt.
3. Schritt 3 – API-Wege nachvollziehen: Authentifizierung, Servicekatalog, Token-Nutzung und nachfolgende API-Aufrufe werden als vollständige Transaktion betrachtet.
4. Schritt 4 – Betriebsgrenzen erkennen: Mandantenaufgaben, Plattformaufgaben und Infrastrukturaufgaben werden voneinander abgegrenzt.

Praxisbezug: Aufbau eines Ressourcenmodells für die Bereitstellung einer virtuellen Maschine mit Netzwerk und persistentem Volume.

Sizing, Kapazität und Reserven

Ressourcenbedarf wird aus Workloads, Schutzbedarf, Wachstum, Wartungsfenstern und Hochverfügbarkeitsanforderungen abgeleitet.

1. Schritt 1 – Lastprofile erfassen: CPU-, RAM-, Storage-, IOPS- und Netzanforderungen werden getrennt nach Grundlast, Spitzenlast und Wachstum dokumentiert.
2. Schritt 2 – Overcommit festlegen: Zulässige Überbuchung wird für Compute-Ressourcen anhand von Workload-Klassen und Performance-Risiken bewertet.
3. Schritt 3 – Ausfallreserve berechnen: Kapazität für Knotenwartung, Hostausfall, Rebuilds und geplante Erweiterungen wird als feste Reserve eingeplant.
4. Schritt 4 – Grenzwerte definieren: Warn-, Planungs- und Eskalationsschwellen werden für zentrale Ressourcen und Fehlerdomänen festgelegt.

Praxisbezug: Berechnung eines groben Kapazitätsmodells mit N+1-Reserve und Wachstumspuffer.

Praxislabor

• Erstellung eines kompakten Zielbilds für einen beispielhaften KRITIS-nahen oder souveränen On-Premises-Einsatz.
• Aufbau eines Architekturdiagramms mit Schichten, Schnittstellen, Vertrauensgrenzen und Fehlerdomänen.
• Erstellung einer vereinfachten Rack- und Verkabelungsdokumentation für eine Titan-Ausbaustufe.
• Entwurf einer Kommunikationsmatrix mit Quelle, Ziel, Protokoll, Zweck und Genehmigungsstatus.
• Aufbau eines Ressourcenmodells für die Bereitstellung einer virtuellen Maschine mit Netzwerk und persistentem Volume.
• Berechnung eines groben Kapazitätsmodells mit N+1-Reserve und Wachstumspuffer.

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.