Datenaustausch im Rechnerverbund NRW. Thomas Eifert Rechen- und Kommunikationszentrum der RWTH Aachen

Transkript

1 Datenaustausch im Rechnerverbund NRW Rechen- und Kommunikationszentrum der RWTH Aachen

2 RV-NRW: Status Der Verbund auf Basis von DCE/DFS läuft technisch stabil Rechenzentren stellen dem RV-NRW Ressourcen zur Verfügung zwischen den RZ Software, Backup,... für Benutzer: Crossfire Beilstein-Stoff- und Reaktionsdatenbank Login auf entfernte Rechner, z. B. Sun-Hochleistungsrechner RV-Nutzer aus anderen NRW-Hochschulen nutzen derzeit schon die Dienste in Aachen

3 Nutzung der Aachener Rechner RV-NRW Benutzer Sun-Hochleistungsrechner: Login mittels ssh in RV-NRW-Account Datenbereiche HOME und WORK. Zusätzliches Verzeichnis: RVHOME im verteilten Dateisystem (die Aufteilung HOME / RVHOME ist RV-weit gemeinsam) gegenwärtige Restriktion: RVHOME steht im Batch nicht zur Verfügung lokale Benutzer Login mittels ssh in RZ-Account Datenbereiche HOME und WORK

4 Rechnerverbund NRW verteiltes Filesystem (DFS) Arbeitsdaten (schnelles lokales Filesystem) landesweite DCE-Zelle Nutzer- verwaltung im DFS Münster eingetragener Nutzer Zugriff auf alle Ressourcen im RV Uni C Rechner in RV-Zelle Uni B Uni C HPC RV-NRW Rechner in RV-Zelle Uni A Uni C Beilstein RV-NRW

5 Eingesetzte Technik und Status DCE / DFS als technische Basis für den Rechnerverbund und ein Verbund-weites Dateisystem AIX: keine Probleme IRIX: ex. nur Clients Solaris: DCE/DFS von IBM-Transarc Keine Probleme mit: Solaris7 / Solaris8-32bit / DCE-only ca. 5 Monate, bis DFS auf Solaris8-64bit lief (bis dahin: Kernel-Panic beim Starten von DFS) DCE-Integration des Batch-Systems in Arbeit Vorfreude beim Wechsel auf Solaris9... Linux: Software angekündigt

6 Globale Aktivitäten Alle reden vom Grid Alle arbeiten mit Globus (fast alle..) Überall hohe Investitionen unter dem Grid -Etikett Auf der SuperComputing DAS Thema - wo steht der RV-NRW?

7 Ziele des Grid Universeller Zugang zu verteilten Ressourcen:

8 Anspruch kollaborativer, koordinierter Zugang:

9 Grid und RV-NRW Anspruch geht in ähnliche Richtung, aber völlig unterschiedliche Philosophien Wesentliche Unterschiede: Grid: auch Daten sind eine Ressource, die ggf. mit einer anderen Ressource (Computer) verküpft wird (werden muß!); expliziter Transport Kein interaktiver Login Programmentwicklung!? RV-NRW datenzentrischer Ansatz: die Daten sind schon da (dadurch auch: Software! ) Interaktiver Zugang

10 Gemeinsame Erkenntnis Zugriff auf verteilt vorhandene Daten von unterschiedlichen Orten aus ist essentiell

11 Middleware Grid: Globus-Toolkit modern viele Entwickler z. Zt. Mainstream im HPC-Land RV-NRW: DCE/DFS alt (IBM: mature product Nischen-Dasein abgehangen ) haben wir etwas falsch gemacht? Nein!

12 Middleware In Globus gibt es keine Filesystem-Semantik Der User MUSS seine Daten explizit transportieren (z.b. GriPhyN) - mit DFS (AFS?) kein Problem DCE/DFS skaliert über große Anzahlen und große Entfernungen DCE/DFS existiert: RV-NRW ist keine Technologie-Demo, sondern funktionierende Infrastruktur

13 Erfahrungsaustausch zu DCE/DFS DCE-Workshop (2001 in Aachen): 47 Teilnehmer von 18 Unis IBM, Sun, Entegrity, Honda, SerCon, T-Systems und Deutsche Bank Beiträge der Firmen sowie von Uni Karlsruhe, Uni Wien, Uni Augsburg, Uni Hohenheim, Uni Bonn, Uni Münster (RV-NRW), RWTH Aachen, Uni Göteborg SC2001 (Denver) Zumindest in den ASCI-Labs ist DCE/DFS fester Bestandteil der Infrastruktur (ohne Alternativen!) alles ok?

14 Entwicklungen These: mittel-/langfristig führt kein Weg an Grid vorbei - kein Widerspruch Möglichkeiten: Einsatz von Grid-Tools innerhalb des RV-NRW GridEngine (aber: Defizite im HPC-Umfeld; Koop. RWTH mit Sun) Portal-Zugriff (für manche User / Software geeignet) In jedem Fall: Vorteile durch gemeinsamen Datenraum! Etablieren von RV-NRW als Grid-Ressource (wenn der RV-NRW selbst eine Ressource darstellen kann)

15 Weiterentwicklung des Datenraums DFS über G-WiN funktioniert, ist aber nicht notwendigerweise die finale Lösung: Software: weitere (künftige) / alternative Protokolle und Produkte (komfortabel: DFS läuft) Hardware: direkt gekoppelte Speicher-Systeme, die schnellen Datentransfer realisieren (DFS als Zugriffs-Layer?) Archiv-Systeme (verteilt!?), die (auch mit explizitem Transfer) Daten langfristig speichern und verteilt erreichbar machen

16 Überblick: Daten zum Tauschen Datenaustausch im RV-NRW (und anderswo): unmittelbare User-Daten (Dateien der User) Verteilter Zugriff durch User (-Gruppe) selbst Verteilte Speicherung transparent für User: Archiv-Replikation mittelbare Daten Software: den User interessiert nur, daß die Software verfügbar ist Metadaten, z.b. Anfragen in Trouble-Ticket-Systemen Informationen über die nicht-eigenen Systeme

17 Trouble-Ticket-System Daten in einem TTS User-Informationen (Name, Anschrift...) Call-Informationen (Datum, Thema, Bearbeiter...) Anfrage-Text Mitschrift der Lösungsschritte, ggf. mit User-Rückfragen Wissensdatenbank als Extrakt

18 Austausch-Szenarien User wendet sich an passendes TTS Bearbeiter wendet sich an TTS des Users, - z.b. via Web-Interface TTS tauschen Daten aus User arbeitet mit seinem TTS Bearbeiter arbeitet mit seinem TTS Projekt mit der Firma ConSol zur Kopplung verteilter Instanzen des CallManagers

19 Zusammenfassung Mit dem Verlassen der Insel muß eine Vielzahl unterschiedlicher Daten mit spezifischen Anforderungen ausgetauscht werden Durch den gemeinsamen Datenraum ist für die Nutzerdaten kein expliziter Transfer notwendig Die Integration von Grid -Komponenten scheint unverzichtbar Kein Widerspruch zu DCE/DFS Koexistenz kann vorteilhaft sein