Aufgabe A – Multiple Choice
(a) Welche der folgenden Aussagen sind korrekt?
- Administrativ skalierbare Systeme sind auch geographisch skalierbar.
– FALSCH.
Begründung: Eine Skalierung hinsichtlich administrativer Aspekte (z. B. zentrale Verwaltung großer Systeme) bedeutet nicht automatisch, dass das System auch über weite geographische Entfernungen hinweg optimal funktioniert. - Fehlertoleranz ist eine grundlegende Eigenschaft verteilter Systeme.
– RICHTIG.
Begründung: Verteilte Systeme müssen oft Teilausfälle (z. B. einzelner Knoten) verkraften können – daher ist Fehlertoleranz essenziell. - Proxy-Zertifikate werden von VOs ausgestellt.
– FALSCH.
Begründung: Proxy-Zertifikate werden in der Regel vom Endnutzer (bzw. dessen Client mittels Delegation) erzeugt und nicht direkt von einer Virtuellen Organisation (VO) ausgestellt. - GridMap-Files bilden DNs auf VOs ab.
– FALSCH.
Begründung: Grid‑Mapfiles ordnen in der Regel die Distinguished Names (DNs) von Grid-Nutzern lokalen Benutzerkonten zu – sie bilden DNs nicht direkt auf Virtuelle Organisationen ab.
Aufgabe B – Job-Management
(a) Ausführung eines Grid-Jobs mit Zustandsdiagramm
Aufgabe:
Ordnen Sie die einzelnen Schritte eines Job-Lebenszyklus den entsprechenden Zuständen im GRAM-Zustandsdiagramm zu. Ein typischer GRAM-Job durchläuft folgende Zustände:
- PENDING:
– Schritt: Job Submission – Der Job wurde eingereicht und wartet auf weitere Verarbeitung. - ACTIVE:
– Schritt: Job Dispatching & Execution – Der Job wird aus dem Warteschlangen-Puffer in die Ausführungsphase überführt und läuft auf der Ressource. - DONE:
– Schritt: Job Completion – Der Job hat seine Ausführung beendet und liefert ein Ergebnis. - FAILED (oder CANCELED):
– Schritt: Fehlerbehandlung / Abbruch – Falls während der Ausführung ein Fehler auftritt oder der Job abgebrochen wird, wechselt der Status in FAILED bzw. CANCELED.
Hinweis: Die Trigger-Events (wie „job submitted“, „job started“, „job completed“, „job canceled“) lösen die Übergänge zwischen diesen Zuständen aus. Die genaue Zuordnung kann je nach Implementierung leicht variieren, doch typischerweise entspricht die Reihenfolge:
Submission → Pending → Active → (Done oder Failed/Canceled)
(b) Advance Reservation / Coallocation
Gegeben:
- Job A: Benötigt 100 von 200 CPUs für 6 Stunden, einsetzbar im Zeitfenster zwischen 11 und 21 Uhr.
- Job D: Benötigt 30 von 100 CPUs für 8 Stunden, einsetzbar im Zeitfenster zwischen 7 und 18 Uhr.
- Zusätzlich liegen Tabellen vor, die bereits laufende Jobs und damit belegte Ressourcen in den betreffenden Zeiträumen zeigen.
Fragestellungen und mögliche Lösungsschritte:
- Ist eine Allocation möglich?
– Lösung: Zunächst wird geprüft, ob in den gewünschten Zeitfenstern ausreichend freie Ressourcen vorhanden sind.
– Für Job A:
– Er benötigt 100 CPUs. Da insgesamt 200 CPUs zur Verfügung stehen, muss sichergestellt sein, dass im gewünschten Zeitraum (zwischen 11 und 21 Uhr) mindestens 100 CPUs frei sind.
– Da der Job 6 Stunden läuft, ist der späteste Startzeitpunkt 15 Uhr (15 + 6 = 21).
– Für Job D:
– Er benötigt 30 CPUs aus einem Pool von 100. Das Zeitfenster liegt zwischen 7 und 18 Uhr, d. h. der späteste Startzeitpunkt ist 10 Uhr (10 + 8 = 18).
– Beurteilung: Falls die Tabellen keine Überschneidungen oder Ressourcenkonflikte in diesen Zeiträumen anzeigen, ist eine Allocation möglich. - Falls nein, Zeitpunkt des ersten Konflikts angeben:
– Beispielantwort: Wäre beispielsweise im Zeitraum zwischen 11 und 15 Uhr schon ein anderer Job eingeplant, der 50 CPUs blockiert, sodass für Job A nur noch 150 – 50 = 100 CPUs (genau im Grenzfall) oder weniger zur Verfügung stünden, so könnte ein Konflikt ab dem frühesten Zeitpunkt der Überlappung auftreten.
– Da hier aber angenommen wird, dass in den Tabellen genügend freie CPUs vorhanden sind, tritt kein Konflikt auf. - Falls ja, Anfangszeitpunkte und maximale Reservierungszeit bestimmen:
– Job A:
– Anfangszeit: Möglichst früh, also idealerweise um 11 Uhr.
– Maximale Reservierungszeit: 6 Stunden (bis spätestens 17 Uhr, wenn man den gesamten Reservierungszeitraum ab 11 Uhr betrachtet, muss aber auch das Endfenster bis 21 Uhr berücksichtigt werden).
– Job D:
– Anfangszeit: Möglichst früh, also um 7 Uhr.
– Maximale Reservierungszeit: 8 Stunden (bis 15 Uhr).
Zusammenfassung Beispielantwort:
Allocation möglich:
- Job A kann um 11 Uhr starten und wird für exakt 6 Stunden (bis 17 Uhr) reserviert – innerhalb des zulässigen Fensters (bis 21 Uhr).
- Job D kann um 7 Uhr starten und wird für 8 Stunden (bis 15 Uhr) reserviert.
Der erste potenzielle Konflikt könnte auftreten, falls in einem der beiden Zeitfenster bereits andere Jobs Ressourcen beanspruchen – anhand der Tabellen ist hier jedoch anzunehmen, dass ausreichend Kapazitäten frei sind.
Aufgabe C – Storage Resource Management
Gegeben ist eine Workflow-Abbildung, in der Hostnamen, Dateien und Programme im Grid dargestellt sind (ähnlich wie in Blatt 8, Aufgabe 1).
(a) Stage-In / Stage-Out ohne SRM
URLs oder Parameter:
- Stage-In:
– Für das Übertragen von Eingabedateien von einem entfernten Speicher zum Rechenknoten verwendet man üblicherweise einen URL-Syntax mit einem Protokoll, z. B.:- Beispiel:
gsiftp://storage.example.com/path/to/input.dat
– Alternativ können Parameter wie Hostname, Port und Pfad separat angegeben werden.
- Beispiel:
- Stage-Out:
– Analog wird die Ausgabe in das gewünschte Verzeichnis des entfernten Speichers kopiert, z. B.:- Beispiel:
gsiftp://storage.example.com/path/to/output.dat
- Beispiel:
(b) Stage-In / Stage-Out mit SRM
URLs mit SRM:
- Bei Verwendung eines Storage Resource Managers wird oft das Schema
srm://genutzt.
– Beispiel Stage-In:
srm://storage.example.com:8443/srm/managerv2?SFN=/path/to/input.dat
– Beispiel Stage-Out:
srm://storage.example.com:8443/srm/managerv2?SFN=/path/to/output.dat
(c) Kopiervorgänge der Dateien
Typische Kopierprozesse im Grid-Workflow:
- Stage-In:
– Quelle: Externe Storage Resource (z. B. über SRM oder gsiftp)
– Ziel: Lokaler Arbeitsbereich (Scratch Space) auf dem Rechenknoten, wo der Job ausgeführt wird.
– Beispiel: Die Eingabedateiinput.datwird vom Storage-Element auf den lokalen temporären Speicher kopiert, damit der Job darauf zugreifen kann. - Stage-Out:
– Quelle: Lokaler Arbeitsbereich auf dem Rechenknoten (Ergebnisdateien, Logfiles etc.)
– Ziel: Zieldirectory auf dem Storage-Element (erneut via SRM oder gsiftp), sodass die Ergebnisse persistent abgelegt und später weiterverarbeitet oder abgerufen werden können.
Aufgabe D – Cloud Computing I
(a) IaaS vs. PaaS – Verantwortung des Users/Clients
IaaS (Infrastructure as a Service):
- User/Client verantwortlich für:
– Auswahl, Installation und Verwaltung des Betriebssystems, Middleware, Laufzeitumgebungen sowie Anwendungen. - Provider verantwortlich für:
– Hardware, Virtualisierung und grundlegende Infrastruktur.
PaaS (Platform as a Service):
- User/Client verantwortlich für:
– Nur die Entwicklung, den Deployment und das Management der eigenen Anwendungen sowie deren Daten. - Provider verantwortlich für:
– Betriebssystem, Laufzeitumgebung, Middleware und Infrastruktur.
In einer Checkliste könnte man beispielsweise markieren:
- Bei IaaS: Der Client muss OS, Patches, Sicherheitsupdates etc. verwalten.
- Bei PaaS: Der Client konzentriert sich auf den Anwendungscode, während der Provider die Plattform vollständig managed.
(b) Availability berechnen für einen Cloud Service Provider (CSP)
(i) Zuordnung der Ausfallzeiten
Beispielhafte Einordnung (die exakten Kategorien können je nach Modell variieren):
- PL (Physical Layer):
– Stromausfall, Speicherausfall - RACL (z. B. Middleware- oder Virtualisierungs-Schicht):
– Middleware-Ausfälle, Probleme bei der Virtualisierung - SL (Service Layer):
– Ausfälle auf VM-Ebene, Applikationsausfälle
(ii) Operationale Verfügbarkeiten und Gesamtverfügbarkeit
Beispielannahme:
- PL: 99,9 %
- RACL: 99,5 %
- SL: 99,0 %
Die Gesamtverfügbarkeit ergibt sich (vereinfacht) als Produkt der Einzelverfügbarkeiten:
0,999×0,995×0,99≈0,984(also ca. 98,4 %)0,999 \times 0,995 \times 0,99 \approx 0,984 \quad \text{(also ca. 98,4 %)}
(iii) Kategorie mit geringstem Ausfall
- Antwort:
– Die Physical Layer (PL) weist mit 99,9 % die höchste Verfügbarkeit auf – sie hat somit den geringsten Anteil an Ausfallzeiten.
(c) Gesamtsystem in Verfügbarkeitsklassen gemäß BSI/VK-Schema
Beispielhafte Einordnung:
- Liegt die Gesamtverfügbarkeit (z. B. 98,4 %) unter einer bestimmten Schwelle (z. B. 99,5 % für die höchste Klasse), wird das System in eine niedrigere Verfügbarkeitsklasse eingeordnet.
- Beispielantwort:
– Das Gesamtsystem könnte gemäß BSI/VK-Schema in Verfügbarkeitsklasse 2 (mittlere Verfügbarkeit) eingestuft werden.
(d) Einstufung als Cloud Provider in die nächsthöhere Stufe
Antwort:
- Ja, möglich – sofern der Cloud Provider zusätzliche Maßnahmen implementiert, um die Ausfallzeiten weiter zu reduzieren.
- Begründung:
– Durch den Einsatz redundanter Hardware, verbesserter Failover-Mechanismen, automatisierten Monitoring- und Recovery-Prozessen sowie strikter SLAs kann der Provider eine höhere operationale Verfügbarkeit erreichen und somit in eine nächsthöhere Verfügbarkeitsklasse eingestuft werden.
Aufgabe E – Cloud Computing II
(a) Unterschiede zwischen Grid und Cloud (Multiple Choice)
Kreuzen Sie die Aussagen an, die typische Unterschiede darstellen:
- Bezahlung für Zugriff
– Begründung: Cloud Services werden meist nach dem Pay-per-Use-Prinzip abgerechnet, während Grid Computing oft ressourcenbasierten, nicht-kommerziellen Zugang bietet. - Verschiedene administrative Domänen
– Begründung: Grid-Infrastrukturen erstrecken sich häufig über mehrere Organisationen und Domänen, während Clouds häufig von einem einzelnen Provider betrieben werden. - ”On-demand self-service”
– Begründung: On-demand Self-Service ist ein zentrales Charakteristikum von Cloud Computing, das Nutzern die sofortige Ressourcenzuteilung ermöglicht – ein Konzept, das in klassischen Grid-Umgebungen weniger ausgeprägt ist. - Heterogene Sicherheitsrichtlinien
– Begründung: In Grid-Umgebungen müssen oft unterschiedliche (und teils heterogene) Sicherheitsrichtlinien der beteiligten Organisationen berücksichtigt werden, während Clouds meist einheitliche Sicherheitsstandards durchsetzen.
(b) Unterschied zwischen Docker und VM (4 Punkte)
Antwort:
- Docker (Containerisierung):
– Container teilen den Kernel des Host-Betriebssystems, starten sehr schnell und haben einen geringen Overhead.
– Sie bieten eine isolierte Umgebung, jedoch mit weniger vollständiger Abstraktion von der Hardware. - Virtuelle Maschinen (VMs):
– VMs virtualisieren die komplette Hardware und besitzen jeweils ein eigenes, vollständiges Betriebssystem.
– Dies führt zu stärkerer Isolation, aber auch zu höherem Ressourcenbedarf und längeren Startzeiten.
(c) Unterschied zwischen Service Aggregation und Arbitrage (3 Punkte)
Antwort:
- Service Aggregation:
– Ein Aggregator bündelt mehrere Cloud-Dienste oder -Ressourcen zu einem integrierten, oft maßgeschneiderten Serviceangebot für den Endkunden. - Service Arbitrage:
– Ein Arbitrageur nutzt Preis- und Leistungsunterschiede zwischen verschiedenen Cloud-Anbietern aus, um Services günstig einzukaufen und mit Gewinn weiterzuverkaufen oder um den Kunden den jeweils besten Service anzubieten.
Diese Lösungen fassen die wesentlichen Aspekte der Aufgaben zusammen. Je nach konkreter Aufgabenstellung oder verwendeter Modellvarianten (z. B. in GRAM oder im BSI/VK-Schema) können Detailantworten variieren, doch die oben dargestellten Erklärungen decken die Kernkonzepte ab.