ÜB-3-GnC

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"]

1. Share resources across dynamic and geographically dispersed organizations
2. Enable single sign-on
3. Delegate rights and authorize access
4. Ensure access control
5. Ensure application of local and global policies
6. Coordinate shared resources
7. Provide uniform information infrastructure
8. Support metadata management
9. 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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

1. Share resources across dynamic and geographically dispersed organizations
   Betroffene Schichten: Collective, Connectivity
   Begründung: Der Collective Layer koordiniert die Ressourcennutzung (z. B. Scheduling) zwischen Organisationen, während die Connectivity Layer eine sichere Kommunikation ermöglicht.
2. Enable single sign-on
   Betroffene Schichten: Connectivity
   Begründung: Single Sign-On basiert auf den Authentifizierungs- und Sicherheitsprotokollen der Connectivity-Schicht.
3. Delegate rights and authorize access
   Betroffene Schichten: Connectivity
   Begründung: Die Delegation von Rechten und Autorisierung erfolgen durch Sicherheitsmechanismen (z. B. X-Zertifikate) in der Connectivity-Schicht.
4. Ensure access control
   Betroffene Schichten: Fabric, Connectivity
   Begründung: Lokal (physisch) erfolgt die Zugriffskontrolle in der Fabric Layer, während die Connectivity-Schicht Sicherheitsdienste zur Authentifizierung bereitstellt.
5. Ensure application of local and global policies
   Betroffene Schichten: Resource
   Begründung: Die Durchsetzung von Richtlinien (z. B. Nutzungs- und Zugriffskontrollen) wird auf der Resource Layer umgesetzt und verwaltet.
6. Coordinate shared resources
   Betroffene Schichten: Collective
   Begründung: Der Collective Layer ist für die Orchestrierung und Koordination mehrerer Ressourcen in einem Grid zuständig.
7. Provide uniform information infrastructure
   Betroffene Schichten: Resource, Collective
   Begründung: Die Resource Layer verwaltet ressourcenspezifische Daten, während die Collective Layer diese Daten integriert und einheitlich bereitstellt.
8. Support metadata management
   Betroffene Schichten: Collective, Application
   Begründung: Die Collective Layer verwaltet systemweite Metadaten; die Application Layer nutzt diese Metadaten für konkrete Anwendungen.
9. Provide the management of data replicas
   Betroffene Schichten: Fabric, Resource, Collective
   Begründung: Die Fabric Layer stellt Speicherressourcen bereit, die Resource Layer verwaltet den Datenzugriff und der Collective Layer koordiniert Replikationsstrategien.

Aufgabe 3.3: Grundlegende Techniken

Beschreiben bzw. positionieren Sie die folgenden grundlegenden Techniken und Technologien im Kontext der Vorlesung.

1. High Performance Computing (HPC)-Systeme

   • Supercomputer oder leistungsstarke Cluster für parallele, rechenintensive Aufgaben, Kommunikationsnetz im Vordergrund

2. High Throughput Computing (HTC)-Systeme

   • Systeme für hohen Gesamtdurchsatz, bearbeiten viele Aufgaben über längere Zeit,Rechenwerk im Vordergrund. HTC fokussiert sich weniger auf die Leistung einzelner Recheneinheiten als auf den Gesamtdurchsatz vieler Aufgaben

3. Computer Cluster versus Computational Grid

   • Cluster: Lokal verbundene Computer, arbeiten als ein System
   • Grid: Verteilte Ressourcen über Standorte und Organisationen hinweg

4. Service-orientierte Architekturen (SOA)

   • Bereitstellung von Softwarefunktionen als Dienste über das Netwerk

5. Virtuelle Maschinen versus virtuelle Infrastrukturen

   • Virtuelle Maschinen: Simulierte Computer auf einem Host
   • Virtuelle Infrastrukturen: Gesamte virtuelle IT-Umgebung mit vielen Ressourcen

6. Virtuelle Organisationen versus Reale Organisationen

   • Virtuelle Organisationen: Temporäre Gruppen zur gemeinsamen Ressourcennutzung
   • Reale Organisationen: Physische Unternehmen oder Institutionen

7. 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

Formelsammlung

1. Verfügbarkeit (Availability)

Verfügbarkeit beschreibt die Wahrscheinlichkeit oder den Prozentsatz der Zeit, in der ein System betriebsbereit ist. Es gibt drei Hauptarten der Verfügbarkeit:

• Inherent Availability ($A_i$)
• Achieved Availability ($A_a$)
• Operational Availability ($A_o$)

Jede dieser Verfügbarkeitsarten berücksichtigt unterschiedliche Ausfallzeiten und Wartungsmaßnahmen.

---

1.1 Inherent Availability ($A_i$)

Die inhärente Verfügbarkeit beschreibt die maximale theoretische Verfügbarkeit, wenn nur reparierbare Fehler betrachtet werden.

Wichtige Begriffe:

• Meantime Before Failure (MTBF)
  Durchschnittliche Zeit zwischen zwei aufeinanderfolgenden Ausfällen eines Systems.
  Formel:

$$\text{MTBF}=\frac{\text{Summe der Betriebszeiten zwischen Ausfa¨llen}}{\text{Anzahl der Ausfa¨lle}}$$

• Meantime to Repair (MTTR)
  Durchschnittliche Zeit zur Behebung eines Fehlers.
  Formel:

$$\text{MTTR}=\frac{\text{Summe der Reparaturzeiten}}{\text{Anzahl der Reparaturen}}$$

Formel für die Inherent Availability:

$$A_i=\frac{\text{MTBF}}{\text{MTBF}+\text{MTTR}}$$

→ Hohes MTBF und niedriges MTTR ergeben eine hohe inhärente Verfügbarkeit.

---

1.2 Achieved Availability ($A_a$)

Die erreichte Verfügbarkeit berücksichtigt zusätzlich geplante Wartungsmaßnahmen.

Wichtige Begriffe:

• Meantime Before Maintenance (MTBM)
  Durchschnittliche Zeit, bevor eine geplante Wartung erforderlich ist.
• Downtime
  Zeit, in der das System nicht verfügbar ist (inkl. geplanter und ungeplanter Stillstände).

Formel für die Achieved Availability:

$$A_a=\frac{\text{MTBM}}{\text{MTBM}+\text{MTTR}}$$

→ Hohes MTBM bedeutet längere Betriebsphasen ohne Wartung.

---

1.3 Operational Availability ($A_o$)

Die operative Verfügbarkeit berücksichtigt alle Einflussfaktoren – Reparaturen, Wartung und externe Verzögerungen.

Wichtige Begriffe:

• Uptime
  Gesamtzeit, in der das System betriebsbereit ist.
  Formel:

$$\text{Uptime}=\text{Gesamtzeit}-\text{Downtime}$$

• Operational Cycle
  Gesamte Betriebszeit inklusive Ausfälle und Wartung.
  Formel:

$$\text{Operational Cycle}=\text{Uptime}+\text{Downtime}$$

Formel für die Operational Availability:

$$A_o=\frac{\text{Uptime}}{\text{Operational Cycle}}$$

→ Operational Availability ist die realistischste Verfügbarkeitsmetrik.

---

2. Zuverlässigkeit (Reliability)

Zuverlässigkeit beschreibt, wie lange ein System fehlerfrei arbeitet, bevor es ausfällt.

Formel für die Reliability:

$$R=\frac{\text{Uptime}}{\text{Operational Cycle}-\text{Maintenance Time}}$$

• Uptime: Zeit, in der das System fehlerfrei arbeitet.
• Operational Cycle: Gesamte Betriebszeit inkl. Ausfälle und Wartung.
• Maintenance Time: Zeit für präventive oder reaktive Wartung.

Ein System mit hoher Zuverlässigkeit hat:

1. Lange Betriebszeiten (hohes MTBF)
2. Seltene Wartungen (niedriges MTTR & niedrige Downtime)

---

Zusammenfassung der Unterschiede

Aspekt	Inherent Availability	Achieved Availability	Operational Availability	Reliability
Definition	Max. theoretische Verfügbarkeit ohne geplante Wartung oder Logistik	Verfügbarkeit inkl. Wartung, aber ohne logistische Verzögerungen	Realistische Verfügbarkeit unter Einbeziehung aller Ausfälle & Wartungen	Wie lange ein System fehlerfrei läuft
Berücksichtigt	Reparaturen (MTBF & MTTR)	Reparaturen + geplante Wartung (MTBM)	Reparaturen + Wartung + externe Faktoren	Betriebszeit vor dem ersten Ausfall
Formel	$A_i=\frac{\text{MTBF}}{\text{MTBF}+\text{MTTR}}$	$A_a=\frac{\text{MTBM}}{\text{MTBM}+\text{MTTR}}$	$A_o=\frac{\text{Uptime}}{\text{Operational Cycle}}$	$R=\frac{\text{Uptime}}{\text{Operational Cycle}-\text{Maintenance Time}}$
Wichtige Faktoren	MTBF, MTTR	MTBM, MTTR, Downtime	Uptime, Operational Cycle, externe Faktoren	MTBF, Wartung, Verfügbarkeit

---

Fazit

• Inherent Availability: Maximale theoretische Verfügbarkeit, nur Reparaturen zählen.
• Achieved Availability: Erweiterung um geplante Wartung.
• Operational Availability: Realistischste Verfügbarkeit mit allen Verzögerungen.
• Reliability: Wie lange ein System ohne Fehler läuft.

Praktische Bedeutung:

• In Hochverfügbarkeitssystemen (z. B. Cloud-Server) ist Operational Availability entscheidend.
• In kritischen Systemen (z. B. Luftfahrt, Medizin) ist Reliability essenziell.

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.

• $\text{Regula¨rer Betrieb: }669\text{h}$
• $\text{Gesamtzeit (September): }720\text{h}$

$$\begin{array}{rl}\text{Availability}& =\frac{\text{Regula¨rer Betrieb}}{\text{Gesamtzeit}}\\ & \\ & =\frac{669h}{720h}\\ & \\ & \approx 0,9292\\ & \end{array}$$

→ Die Verfügbarkeit beträgt $92.92\%$

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.

$$\begin{array}{rl}\text{Reliability}& =\frac{\text{Verfu¨gbare Betriebszeit}}{\text{Verfu¨gbare Betriebszeit}+\text{Ausfallzeit}}\\ & \\ & =\frac{683\text{h}}{683\text{h}+24\text{h}}\\ & \\ & =\frac{683\text{ h}}{707\text{ h}}\\ & \\ & \approx 0,9661\\ & \\ & \approx 96,61\%\end{array}$$

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 ($96,61\%<99,0\%$) und unsere Ausfallzeit größer ist als die von VK1 ($22\text{ h}>8\text{ h}$)

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.

---

×

MyUniNotes is a free, non-profit project to make education accessible for everyone. If it has helped you, consider giving back! Even a small donation makes a difference.

These are my personal notes. While I strive for accuracy, I’m still a student myself. Thanks for being part of this journey!