Aufgabe 3.1: Virtuelle Organisationen (3VL GridCloud-08-11-2024)
In der Vorlesung wurde der Begriff der virtuellen Organisation (VO) verwendet. Versuchen Sie, VOs zu definieren oder zumindest zu charakterisieren und geben Sie Beispiele und Gegenbeispiele an.
Eine Virtuelle Organisation ist ein Zusammenschluss von Individuen und/oder Institutionen, die Ressourcen und Informationen teilen, um ein gemeinsames Ziel zu erreichen. Das Hauptmerkmal hierbei ist, dass die Mitglieder aus verschiedenen geografischen Standorten arbeiten, moderne Technologien zur Zusammenarbeit nutzen und dennoch als Einheit auftreten.
Weitere Merkmale von Virtuellen Organisationen:
- Dynamik: Mitglieder können flexibel hinzukommen oder ausscheiden.
- Gemeinsame Ressourcen: Nutzung von Hardware, Software und Daten durch alle Mitglieder.
- Verteilte Kontrolle: Keine zentrale Autorität, Entscheidungen werden gemeinschaftlich getroffen.
Beispiele für Virtuelle Organisationen:
- Wissenschaftliche Zusammenarbeit: Gemeinsame Nutzung von Supercomputern oder z. B. durch BOINC, das ein Peer-to-Peer-System verwendet.
- Open-Source-Projekte: Dezentrale und flexible Zusammenarbeit von Entwicklern weltweit, die über digitale Plattformen wie GitHub gemeinsam Code entwickeln, teilen und weiterentwickeln.
- Geschäftsnetzwerke: Strategische Allianzen zwischen Unternehmen, die Ressourcen und Wissen für gemeinsame Projekte teilen.
Gegenbeispiele:
- Klassische Unternehmen: Geschlossene Organisationen, in denen Mitarbeitende vor Ort arbeiten und keine externe Kooperation stattfindet.
- Proprietäre Netzwerke: Zusammenarbeit nur innerhalb einer festen Gruppe ohne öffentliche Zugänglichkeit oder Ressourcenfreigabe.
- Hierarchische Strukturen: Organisationen mit starren, zentralisierten Strukturen und ohne dynamische oder flexible Zusammenarbeit.
- Exklusivprojekte: Projekte, bei denen nur ein begrenzter Kreis von Personen beteiligt ist und keine offene Teilnahme möglich ist.
Aufgabe 3.2: Grid-Basisarchitektur (Grid-Architektur Eine detaillierte Übersicht)
Hinweis: Grid-Basisarchitektur
In der Vorlesung wurde Ihnen das grundlegende Grid-Architekturmodell von Foster vorgestellt [1]. Der Einfachheit halber ist es in Abbildung 2 noch einmal angegeben.
Lesen Sie bitte Abschnitt 4 des Papers [1] (Online), und geben Sie für jede der folgenden Grid-Anforderungen an, welche Ebene(n) der Basisarchitektur in Abbildung 2 Ihrer Ansicht nach involviert ist/sind – selbst wenn Ihnen Details noch nicht bekannt sind.
flowchart TD
Application["Application"] --> Collective["Collective"]
Application --> Resource["Resource"]
Application --> Connectivity["Connectivity"]
Fabric["Fabric"]
- Share resources across dynamic and geographically dispersed organizations
- Enable single sign-on
- Delegate rights and authorize access
- Ensure access control
- Ensure application of local and global policies
- Coordinate shared resources
- Provide uniform information infrastructure
- Support metadata management
- Provide data replica management
Beispielsweise wäre die Antwort zu Punkt 9: Fabric, Resource, Collective.
Komponenten der Grid-Architektur erklärt (Leseempfehlung: Grid-Architektur Eine detaillierte Übersicht)
Application (Anwendung)
Die Anwendungsschicht ist die oberste Ebene der Grid-Architektur. Hier befinden sich die Benutzeranwendungen, die Grid-Dienste nutzen, um komplexe Aufgaben auszuführen. Anwendungen interagieren mit den darunterliegenden Schichten, um auf verteilte Ressourcen zuzugreifen und koordinierte Berechnungen durchzuführen.
Collective (Kollektiv)
Die Kollektivschicht koordiniert mehrere Ressourcen und stellt globale Dienste bereit, die nicht an eine einzelne Ressource gebunden sind. Sie umfasst Funktionen wie Ressourcenentdeckung, Replikationsmanagement, Monitoring und Workflow-Management. Diese Schicht ermöglicht die Zusammenarbeit zwischen verschiedenen Ressourcen und Organisationen innerhalb einer Virtual Organization (VO).
Resource (Ressource)
Die Ressourcenschicht verwaltet den Zugriff auf einzelne Ressourcen. Sie definiert Protokolle für die sichere Aushandlung, Initiierung, Überwachung und Kontrolle von Aktionen auf Ressourcen wie Rechenleistung, Speicher oder Datenbanken. Diese Schicht stellt sicher, dass Ressourcen gemäß den festgelegten Richtlinien genutzt werden.
Connectivity (Konnektivität)
Die Konnektivitätsschicht bietet die grundlegenden Kommunikations- und Authentifizierungsprotokolle, die für Grid-spezifische Netzwerktransaktionen erforderlich sind. Sie ermöglicht sichere Datenübertragung und die Verifizierung von Identitäten über verschiedene Ressourcen und Organisationen hinweg, was für vertrauenswürdige Interaktionen unerlässlich ist.
Fabric (Grundlage)
Die Fabric-Schicht bildet die Basis der Grid-Architektur und umfasst die physischen Ressourcen selbst, wie Computer, Speicher, Netzwerke und Sensoren. Sie stellt Schnittstellen für die lokale Steuerung und den direkten Zugriff auf diese Ressourcen bereit. Die höheren Schichten bauen auf dieser Ebene auf, um komplexere Dienste und Funktionen bereitzustellen.
Zusammenfassung Abschnitt 4 des Papers
In Abschnitt 4 des Artikels “The Anatomy of the Grid” beschreiben die Autoren die Grid-Architektur, die darauf abzielt, allgemeine Anforderungen für verschiedene Klassen von Komponenten zu identifizieren, ohne alle notwendigen Protokolle, Dienste, APIs und SDKs vollständig aufzuzählen. Die Architektur ist in Schichten organisiert, ähnlich dem “Sanduhrmodell”, wobei der schmale Hals eine kleine Menge an Kernabstraktionen und -protokollen definiert, auf die viele verschiedene hochrangige Funktionen abgebildet werden können.
Die Grid-Architektur besteht aus folgenden Schichten:
- Fabric-Schicht: Stellt die Ressourcen bereit, auf die mittels Grid-Protokollen zugegriffen wird, wie z. B. Rechenressourcen, Speichersysteme, Kataloge, Netzwerke und Sensoren. Sie bietet Schnittstellen für die lokale Kontrolle und ermöglicht die Implementierung von ressourcenspezifischen Operationen.
- Connectivity-Schicht: Definiert grundlegende Kommunikations- und Authentifizierungsprotokolle, die für Grid-spezifische Netzwerktransaktionen erforderlich sind. Sie ermöglicht die sichere und einfache Kommunikation zwischen Ressourcen und stellt sicher, dass Benutzer und Ressourcen authentifiziert werden können.
- Resource-Schicht: Baut auf der Connectivity-Schicht auf und definiert Protokolle für die sichere Aushandlung, Initiierung, Überwachung, Kontrolle, Abrechnung und Bezahlung von Sharing-Operationen auf einzelnen Ressourcen. Sie konzentriert sich auf den Zugriff und die Verwaltung individueller Ressourcen.
- Collective-Schicht: Enthält Protokolle und Dienste, die nicht an eine bestimmte Ressource gebunden sind, sondern globaler Natur sind und Interaktionen über Sammlungen von Ressourcen hinweg erfassen. Diese Schicht ermöglicht die Koordination und Verwaltung mehrerer Ressourcen und bietet Funktionen wie Verzeichnisdienste, Replikationsmanagement und Workflow-Management.
- Anwendungen: Die oberste Schicht besteht aus Benutzeranwendungen, die innerhalb einer Virtuellen Organisation (VO) operieren und Dienste aus allen darunterliegenden Schichten nutzen. Anwendungen können komplexe Aufgaben ausführen, indem sie auf die bereitgestellten Grid-Dienste zugreifen.
Die Autoren betonen, dass ihre architektonische Beschreibung auf hohem Niveau gehalten ist und nur wenige Einschränkungen hinsichtlich Design und Implementierung auferlegt. Sie erläutern auch, wie das Globus Toolkit, ein weit verbreitetes Toolkit für Grid-Computing, Protokolle und Dienste in den verschiedenen Schichten implementiert. Beispiele für Projekte, die diese Architektur nutzen, werden ebenfalls genannt.
Das Hauptziel dieser Architektur ist es, eine flexible und erweiterbare Struktur bereitzustellen, innerhalb der Lösungen für Schlüsselanforderungen von Virtuellen Organisationen platziert werden können. Durch die Schichtung können Komponenten innerhalb jeder Ebene gemeinsame Eigenschaften teilen und auf Fähigkeiten und Verhaltensweisen der niedrigeren Ebenen aufbauen.
-
Share resources across dynamic and geographically dispersed organizations
- Connectivity, Resource, Collective
- Erläuterung: Teilen von Ressourcen über sichere Kommunikation (Connectivity), Zugriff auf einzelne Ressourcen (Resource) und deren Koordination über Organisationen hinweg (Collective).
-
Enable single sign-on
- Connectivity
- Erläuterung: Single Sign-On wird durch Authentifizierungsprotokolle der Connectivity-Schicht ermöglicht.
-
Delegate rights and authorize access
- Connectivity, Resource, Collective
- Erläuterung: Rechte-Delegation und Autorisierung erfordern sichere Authentifizierung (Connectivity), Durchsetzung von Zugriffsrechten auf Ressourcenebene (Resource) und übergreifende Autorisierungsdienste (Collective).
-
Ensure access control
- Fabric, Resource, Connectivity
- Erläuterung: Zugriffskontrolle umfasst lokale Mechanismen (Fabric), Ressourcenverwaltung (Resource) und Authentifizierung (Connectivity).
-
Ensure application of local and global policies
- Fabric, Resource, Collective
- Erläuterung: Lokale Richtlinien werden in Fabric und Resource angewendet, globale Richtlinien durch die Collective-Schicht koordiniert.
-
Coordinate shared resources
- Collective
- Erläuterung: Die Koordination gemeinsamer Ressourcen über mehrere Standorte erfolgt in der Collective-Schicht.
-
Provide uniform information infrastructure
- Fabric, Resource, Connectivity, Collective
- Erläuterung: Alle Schichten sind beteiligt, um eine einheitliche Informationsinfrastruktur für Ressourceninformationen und deren Zugriff zu gewährleisten.
-
Support metadata management
- Fabric, Collective
- Erläuterung: Metadaten werden auf lokaler Ebene verwaltet (Fabric) und übergreifend koordiniert (Collective).
-
Provide data replica management
- Fabric, Resource, Collective
- Erläuterung: Datenreplikation nutzt lokale Speichermechanismen (Fabric), Zugriffsprotokolle auf einzelne Daten (Resource) und Koordination zwischen Ressourcen (Collective).
Aufgabe 3.3: Grundlegende Techniken
Beschreiben bzw. positionieren Sie die folgenden grundlegenden Techniken und Technologien im Kontext der Vorlesung.
-
High Performance Computing (HPC)-Systeme
- Supercomputer oder leistungsstarke Cluster für parallele, rechenintensive Aufgaben, Rechenwerk und Verbindungsnetz im Vordergrund
-
High Throughput Computing (HTC)-Systeme
- Systeme für hohen Gesamtdurchsatz, bearbeiten viele Aufgaben über längere Zeit, wieder Rechenwerk und Verbindungsnetz im Vordergrund. HTC fokussiert sich weniger auf die Leistung einzelner Recheneinheiten als auf den Gesamtdurchsatz vieler Aufgaben
-
Computer Cluster versus Computational Grid
- Cluster: Lokal verbundene Computrr, arbeiten als ein System
- Grid: Verteilte Ressourcen über Standorte und Organisationen hinweg
-
Service-orientierte Architekturen (SOA)
- Bereitstellung von Softwarefunktionen als Dienste über das Netwerk
-
Virtuelle Maschinen versus virtuelle Infrastrukturen
- Virtuelle Maschinen: Simulierte Computer auf einem Host
- Virtuelle Infrastrukturen: Gesamte virtuelle IT-Umgebung mit vielen Ressourcen
-
Virtuelle Organisationen versus Reale Organisationen
- Virtuelle Organisationen: Temporäre Gruppen zur gemeinsamen Ressourcennutzung
- Reale Organisationen: Physische Unternehmen oder Institutionen
-
Dienste versus Ressourcen
- Dienste: Software-Funktionen, die angeboten werden
- Ressourcen: Hardware oder Daten, die dafür genutzt werden
Aufgabe 3.4: Verfügbarkeit und Zuverlässigkeit
In dieser Aufgabe berechnen Sie die Verfügbarkeit (availability) und Zuverlässigkeit (reliability) einer Grid Site. Dazu verwenden Sie bitte die folgenden (realen) Daten einer Grid Site im Worldwide LHC Computing Grid (WLCG) (http://wlcg.web.cern.ch/ und http://atlas.cern/) für September 2017:
Datum | Regulärer Betrieb (Stunden) | Wartung (Stunden) | Datum | Regulärer Betrieb (Stunden) | Wartung (Stunden) | Datum | Regulärer Betrieb (Stunden) | Wartung (Stunden) |
---|---|---|---|---|---|---|---|---|
1.9.2017 | 24 | - | 11.9.2017 | 24 | - | 21.9.2017 | 22 | - |
2.9.2017 | 24 | - | 12.9.2017 | 24 | - | 22.9.2017 | 23 | - |
3.9.2017 | 12 | 12 | 13.9.2017 | 24 | - | 23.9.2017 | 24 | - |
4.9.2017 | 24 | - | 14.9.2017 | 24 | - | 24.9.2017 | 24 | - |
5.9.2017 | 24 | - | 15.9.2017 | 24 | - | 25.9.2017 | 24 | - |
6.9.2017 | 24 | - | 16.9.2017 | 12 | - | 26.9.2017 | 24 | - |
7.9.2017 | 24 | - | 17.9.2017 | 24 | - | 27.9.2017 | 24 | - |
8.9.2017 | 24 | - | 18.9.2017 | 24 | - | 28.9.2017 | 24 | - |
9.9.2017 | 24 | - | 19.9.2017 | 24 | - | 29.9.2017 | 24 | - |
10.9.2017 | 24 | - | 20.9.2017 | 8 | 10 | 30.9.2017 | 16 | 2 |
a) Wie hoch ist die Verfügbarkeit (availability) der Grid Site für den Monat September (in Prozent)?
Gemeint ist hier die operational availability (im Gegensatz zur inherent availability und achieved availability), die verstanden wird als das Verhältnis der verfügbaren Betriebszeit zur Gesamtzeit.
→ Die Verfügbarkeit beträgt
b) Wie groß ist die Zuverlässigkeit (reliability) der Grid Site für den Monat September (in Prozent)?
Der Einfachheit halber soll reliability hier verstanden werden als das Verhältnis der verfügbaren Betriebszeit zur Gesamtzeit ohne Wartungszeiten.
c) Das Bundesamt für Sicherheit in der Informationstechnik (BSI) (https://www.bsi.bund.de) hat die in Abbildung 3 gelisteten Verfügbarkeitsklassen definiert. In welche Klasse würde die hier betrachtete Grid Site fallen?
Verfügbarkeitsklasse (VK) | Bezeichnung Betrachtungseinheit, Prozess, System, Einheit, Komponente | Mindestverfügbarkeit | Ausfallzeit pro Monat* | Ausfallzeit pro Jahr* |
---|---|---|---|---|
VK 0 | Ohne zugesicherte Verfügbarkeit | - | - | - |
VK 1 | Normale Verfügbarkeit | 99,0 % | < 8 h | < 88 h |
VK 2 | Erhöhte Verfügbarkeit | 99,9 % | < 4 h | < 9 h |
VK 3 | Hochverfügbarkeit | 99,99 % | < 53 min | < 53 min |
VK 4 | Höchstverfügbarkeit | 99,999 % | < 26 s | < 6 min |
VK 5 | Verfügbarkeit unter extremen Bedingungen / auch bei höherer Gewalt (Disaster-Tolerant) | - | - | - |
*bei 7 x 24 Std. Betrieb
- VK0, da wir eine Reliability niedriger als 99% haben () und unsere Ausfallzeit größer ist als die von VK1 ()
d) Welche Maßnahmen müssten Ihrer Ansicht nach getroffen werden, um die Site in die nächsthöhere Klasse zu bringen?
- Es gibt Tage, an denen die verfügbare Zeit + Wartung nicht auf 24h kommt (z.B 20.09.2017, 30.9.2017 oder 21.9.2017). An diesen Tagen sollte angestrebt werden, die verfügbare Zeit zu verlängern
- Die Wartungszeiten sind allgemein sehr hoch mit 12h am 3.9.2017 und 10h am 20.9.2017. Man sollte bedenken, wie man diese Wartungszeit senkt, indem man eventuell Redundanzen, bessere Codebase etc bereitstellt
Literatur
[1] Ian Foster, Carl Kesselman, and Steven Tuecke. The anatomy of the grid: Enabling scalable virtual organizations. International Journal of High Performance Computing Applications, 15(3):200–222, 2001.