Seminar Grid Computing

Transkript

1 Seminar Grid Computing Datenmanagement im Grid Sabine Zill Sommersemester

2 Einleitung Im Grid stehen die Benutzer einer großen Datenmenge gegenüber. Dabei soll es jedem Benutzer ermöglicht werden schnell auf benötigte Daten zugreifen zu können. Um die Zugriffszeit auf die Dateien zu reduzieren, werden lokale Kopien von Dateien erstellt. Dabei muss das System in der Lage sein den Replikationsprozess zu steuern und dabei über jede Kopie einer Datei bescheid wissen. Ein Problem bei der Replikation im Grid ist, dass eine große Menge an Daten transferiert werden muss. Zu diesem Zweck muss es ein Protokoll geben, das in der Lage ist, diese Datenmengen sicher und effizient transferieren zu können. Mit GridFTP wird ein solches Protokoll zum Transferieren von Dateien im Grid beschrieben. Als Komponenten zum Managen von Replikationen werden der Replica Catalog sowie der Replica Location Service vorgestellt. Im Anschluss wird mit dem Storage Broker kurz beschrieben wie die Auswahl von Replikationen aussehen kann. Abschließend wird eine Replikationsarchitektur am Beispiel von GDMP vorgestellt. Dort werden die einzelnen Bestandteile, der Replikationsprozess und die verwendeten Replikationsmechanismen für die Replikation von Dateien und Objekten vorgestellt. 1. Komponenten für das Datenmanagement 1.1 Datentransfer - GridFTP Allgemein Im Grid wird eine große Zahl an unterschiedlichen Speichersystemen eingesetzt. Damit es möglich ist auf die dort gespeicherten Daten zugreifen zu können und diese zu transferieren, werden, je nach Speichersystem, unterschiedliche Protokolle verwendet. Um dennoch einen kompatiblen Zugriff und Transfer zu ermöglichen, wurde GridFTP entwickelt. Es ermöglicht einen sicheren und effizienten Datentransfer im Grid. GridFTP stellt eine Erweiterung des FTP Protokolls da. Dieses hat den Vorteil, dass es sich bei diesem Protokoll um um standardisiertes und somit weit verbreitetes Protokoll zur Datenübertragung handelt. Weiterhin stellt FTP eine wohldefinierte Architektur für Protokollerweiterungen bereit und lässt sich daher gut an die Bedürfnisse im Grid anpassen Eigenschaften von GridFTP Im Folgenden werden einige Eigenschaften und Erweiterungen des FTP Protokolls aufgeführt. Grid Security Infrastructure (GSI) Unterstützung Da der Zugriff auf Dateien und Speichersysteme kontrolliert werden muss, wurde GridFTP in die Grid Security Infrastructure integriert. Bei Bedarf kann durch diese Eigenschaft der Datenstrom verschlüsselt werden. Thrid-Party control Third-Party control kann eingesetzt werden um den Datentransfer in einem verteilten System zu kontrollieren. Dabei wird einem Benutzer oder einer Anwendung ermöglicht den Datentransfer von der Start- zur Zielseite zu starten, überwachen und zu kontrollieren. 2

3 Paralleler Datentransfer Durch mehrere parallele TCP Streams statt einer einzelnen Verbindung zwischen zwei Servern ist es möglich die Bandbreite zu verbessern. Verteilter Datentransfer Sind die zu kopierenden Daten auf mehreren Servern verteilt, werden sie mittels parallelem Datentransfer über mehrere TCP-Streams transferiert. Teiltransfer von Dateien Für manche Anwendungen kann es vorteilhaft sein, wenn jeweils nur Teile einer Datei übertragen werden, statt der gesamten Datei. Automatisches Aushandeln des TCP Buffers Je nach Größe und Anzahl der zu übertragenden Dateien kann durch automatisches oder manuelles Festlegen des TCP-Buffers die Leistung der Übertragung verbessert werden. Unterstützung von zuverlässigen und wiederstartbaren Datentransfer Um einen zuverlässigen Datentransfer zu ermöglichen, wurden Methoden hinzugefügt um Netzwerkfehler zu erkennen und zu korrigieren, sowie einen fehlgeschlagenen Datentransfer neu zu starten. 1.2 Management für Dateien - Globus Replica Catalog und Replica Location Service Die Replikation von Dateien führt zu dem Problem, dass identische Dateien an mehreren Stellen im Grid existieren und dennoch eindeutig identifiziert werden müssen. Dies geschieht, indem man dieser Menge von identischen Replikationen einen logischen Dateinamen zuweist. Jeder physikalischen Datei aus dieser Menge wird weiterhin ein physikalischer Dateiname zugewiesen. Dabei wird davon ausgegangen, dass der physikalische Dateiname einer Datei den kompletten Pfad auf dem Speicherelement enthält, der benötigt wird, um auf die zugehörige Datei verweisen zu können. Wie eine solche Abbildung und Verwaltung von Dateien aussehen kann, soll im weiteren Verlauf an Hand des Globus Replica Catalogs und dem Replica Location Service dargestellt werden. Voraussetzungen für einen Replica Location Service/ Replica Der Replica Location Service sowie der Replica arbeitet mit read-only Dateien und Versionierung. Es wird dabei davon ausgegangen, dass sich die Dateien nach ihrer Erzeugung nicht mehr verändern. Sollten sie doch verändert werden, so muss mit Versionierung gearbeitet werden. Die Informationen über die verschiedenen Versionen werden dabei in einem Metadaten-Katalog gespeichert. Wurde eine Datei verändert, gibt es zwei Möglichkeiten diese Änderungen an die anderen bisher bestehenden Replikationen weiter zu leiten. Zum einen besteht die Möglichkeit, dass alle bisherigen Versionen durch die neue Version ersetzt werden. Zum anderen ist es möglich, dass die neuste Version nur nach Anfrage ersetzt wird. Um die Versionierung möglichst effizient zu machen, ist es möglich Masterdateien zu definieren, von denen als einzige Dateien neue Versionen erstellt werden können. 3

4 1.2.1 Globus Replica Catalog Die Abbildung eines logischen Dateinamens auf mehrere physikalische Instanzen der Datei erfolgt durch die verschiedenen Einträge im Replica Catalog. Dieser beinhaltet zu diesem Zweck drei Eintragstypen: logische Kollektionen, Speicherorte und logische Dateien. Diese verschiedenen Einträge werden im Folgenden näher erklärt. Logische Kollektionen Eine logische Kollektion stellt eine benutzerdefinierte Gruppe von Dateien dar, d.h. ein Benutzer kann mehrere Dateien, die für ihn zusammen gehören, zu einer solchen logischen Kollektion zusammenfassen und zusammen bearbeiten. Dementsprechend wird dadurch die Anzahl der Katalogeinträge reduziert, da nicht jede Datei einzeln im Katalog gespeichert werden muss, sondern nur ein Eintrag je Kollektion gespeichert wird. Innerhalb dieses Eintrags wird auf die einzelnen Dateien der Kollektion verwiesen. Ein weitere Vorteil der logischen Kollektionen ist es, dass weniger Operationen auf dem Katalog ausgeführt werden müssen. Möchte ein Benutzer eine Operation auf der Kollektion ausführen, so wird sie nur für die Kollektion ausgeführt. Es muss nur der Eintrag der Kollektion manipuliert werden, jedoch nicht jeder einzelne Eintrag einer zur Kollektion gehörenden Datei. Jeder Eintrag einer logischen Kollektion kann zusätzliche Attribute enthalten. Dazu gehört der Dateiname jeder Datei der Kollektion, Name des Erstellers sowie Zeitstempel der Erstellung und der Änderung der Kollektion. Ein Eintrag für eine Kollektion enthält somit keine Möglichkeit, einen logischen Dateinamen auf physikalische Instanzen abzubilden. Er ermöglicht lediglich Dateien zu einer Gruppe zusammenzufassen. Speicherorte Der Eintrag über die Speicherorte einer Datei ermöglicht die Abbildung eines logischen Dateinamens auf physikalische Instanzen der Datei. Es werden dabei alle Dateien einer Kollektion aufgelistet, die in dem bestimmten Speichersystem gespeichert sind. Dies kann eine vollständige aber auch teilweise Kopie der Kollektion sein. Ein Eintrag enthält alle Informationen um eine URL konstruieren zu können mit der man auf die einzelnen Dateien der Kollektion zugreifen zu können. Dieser URL Konstruktor stellt den Mechanismus zum Abbilden von logischen Dateinamen auf physikalische Namen zur Verfügung. Weiterhin können weitere optionale Attribute angegeben werden, wie der Dateiname einer bestimmten Datei der Kollektion, der Hostname des Speichersystems, das Protokoll, das benötigt wird, um auf das Speichersystem zugreifen zu können, den Port, Name des Erstellers, Zeitstempel der Erstellung und Änderung. 4

5 Logische Dateien Im Gegensatz zu den Kollektionen charakterisiert der Eintrag der logischen Dateien einzelne Dateien. Die Einträge haben einen global eindeutigen Namen und, möglicherweise, mehrere physikalische Instanzen. Der Name wird entweder automatisch vom System vergeben oder kann vom Benutzer angegeben werden. In dem letzten Fall wird vorher geprüft ob der Name zulässig und eindeutig ist. Der Katalog kann optional einen Eintrag für jede logische Datei einer Kollektion haben. Ein Eintrag einer logischen Datei kann ebenfalls optionale Attribute enthalten. Dazu zählen die Größe der Datei, Name des Erstellers und der Zeitstempel der Erstellung und der Änderung der Datei. Beispiel für einen Replica Catalog Abbildung 1 Beispiel für einen Replica Catalog Die obige Abbildung zeigt ein Beispiel für einem Replica Catalog mit den zuvor genannten Eintragstypen. Der Katalog enthält zwei logische Kollektionen (CO 2 Messungungen der Jahre 1998 und 1999), wobei die erste Kollektion (Messung 1998) weiter aufgeschlüsselt wird. Die Kollektion mit den Daten von 1998 enthält zwei physikalische Standorte. Bei dem linken Eintrag handelt es sich jedoch nur um einen Teil der Kollektion, da dort nur die Dateien zwischen März und Oktober gespeichert sind. Der rechte Eintrag enthält die gesamte Kollektion. Weiterhin sind die Einträge der logischen Dateien der Kollektion zu sehen. 5

6 Operationen auf dem Replica Catalog Der Replica Catalog ermöglicht folgende Operationen Erstellen und Löschen von Kollektionen, Speicherstellen und logischen Einträgen Einfügen und Entfernen von logischen Dateinamen in Kollektionen und Speicherorten Inhalt von Kollektionen und Speicherorten auflisten Finden aller physikalischen Speicherorte einer Datei Auflisten aller Attribute die zu einer gespeicherten Kollektion, einem Speicherort oder einer logischen Datei gehören Globus Replikationsmanagement Architektur Neben dem Replica Catalog beinhaltet die Globus Replikationsmanagement Architektur eine Replikationsmanagement API, die für die Integration des Replica Catalogs mit GridFTP sorgt. Sie sorgt dafür, dass Replikationen auf dem Speichersystem erzeugt oder gelöscht werden und die Änderungen in den Replica Catalog geschrieben werden. Services des Replikationsmanagement Systems Wie zuvor angedeutet, stellt das Replikationsmanagement System einen Service zur Verfügung um Replikationen von Dateien oder Teilen einer Kollektion zu erzeugen. Im Anschluss an diesen Prozess, sorgt ein anderer Service dafür, dass diese neuen Replikationen im Replica Catalog gespeichert werden. Ein weiterer Service des Replikationsmanagement Systems ist es, die Datei für die Replikation auszuwählen, die am besten dafür geeignet ist. Diese Auswahl kann unter verschiedenen Gesichtspunkten erfolgen. Dies kann z.b. die Netzwerkleistung sein oder die Speicherung bzw. der Zugang zu der Datei. Im letzten Fall würde in die Entscheidung mit einbezogen werden, ob die Datei sofort verfügbar ist, oder ob sie erst aus einem Massenspeicher System geladen werden muss Replica Location Service Eine weitere Möglichkeit alle physikalischen Orte einer Datei zu verwalten, stellt der Replica Location Service dar. Der Replica Location Service wurde ebenfalls von Globus entwickelt und nimmt im aktuellen Globus Toolkit den Platz des zuvor beschriebenen Replica Catalog als Datenmanagement Komponente ein. Beziehung zur früheren Globus Replica Management Software Der Replica Location Service ersetzt die früheren Replikationswerkzeuge. Dazu zählen unter anderem die Replica Catalog API und sie Replication Management API. Durch den Replica Location Service soll eine bessere Zuverlässigkeit erreicht werden, in dem ein single-point-of-failure vermieden wird. Ebenfalls soll die Performance und Skalierbarkeit verbessert 6

7 werden. Er trennt die für die Replikation benötigten Informationen von anderen Typen von Metadaten über die Dateien (z.b. Datum der Erstellung oder Änderung). Weiterhin enthält er, im Gegensatz zum zuvor beschriebenen Replica Catalog, keine Einträge von logischen Kollektionen. Logische Kollektionen können dennoch bestehen, nur geht der Replica Location Service davon aus, dass solche Informationen in einem separaten Metadatenservice gespeichert sind. Replica Location Service Framework Ein Replica Location Service Framework besteht aus fünf Elementen 1. Verwaltung eines konsistenten lokalen Zustands in Local Replica Catalogs (LRCs) 2. Verwaltung gemeinsamer Zustände/Sammelzustand mit schwacher Konsistenz in Replica Location Indices (RLIs) 3. Soft state Verwaltung von RLI Zuständen 4. Komprimierung von Zustandsaktualisierungen um Netzwerktraffic zu reduzieren 5. Verwaltung der Informationen über Zugehörigkeit und Aufteilung Local Replica Catalog In einem Local Replica Catalog werden alle Informationen über Replikationen gespeichert, die auf der entsprechenden lokalen Seite zur Verfügung stehen. Er bildet logische Dateinamen auf die physikalischen Dateinamen, der auf seinem Speichersystem befindlichen Dateien ab. Weiterhin ist es möglich Anfragen auf einem Katalog derart auszuführen, dass es möglich ist alle physikalischen Dateinamen zu finden, die einem gegebenen logischen Dateinamen zugeordnet sind. Andersherum ist es möglich alle logischen Dateinamen zu finden, denen ein gegebener physikalischer Dateiname zugeordnet ist. Replica Location Index Ein Replica Location Index ermöglicht es, Abfragen über mehrere Replikationsseiten durchzuführen. Da ein Local Replica Catalog nur Informationen über Dateien auf der lokalen Seite speichert, müssen in einem Replica Location Index Informationen über den logischen Dateinamen und den Speicherort aller Dateien gespeichert werden. Zu diesem Zweck wird in jedem Eintrag des RLIs ein Paar aus logischem Dateinamen und einem Zeiger auf einem LRC gespeichert. Dabei gibt es mehrere RLIs, die eine Teilmenge der Informationen enthalten, d.h. dass nicht nur ein einziger RLI Informationen zu allen Dateien im Grid enthält, sondern dass diese Informationen auf mehrere LRIs verteilt sind. Dabei können die Informationen redundant in den verschiedenen RLIs gespeichert werden. 7

8 Abbildung 2: Redundante Indizierung Abbildung 3: Redundanzfreie Indizierung Die Anzahl und Variation der RLIs ist dabei beliebig. Um die Verfügbarkeit der Informationen zu verbessern, ist es daher auch möglich, mehrere RLIs hierarchisch anzuordnen. Abbildung 4: Hierarchische Indizierung über zwei Ebenen Soft State Verwaltung Um zu jeder Zeit aktuelle Informationen über die Dateien im Grid zu haben, wird der soft state Mechanismus eingesetzt. Dabei handelt es sich um Informationen, die nur für eine bestimmte Zeit gültig sind und daher in regelmäßigen Abständen aktualisiert werden müssen. Dieses Prinzip wird dazu eingesetzt um die Verfügbarkeit von Dateien zu überprüfen und zu gewährleisten. Der Ablauf ist dabei wie folgt: Ein LRC gibt in regelmäßigen Abständen Informationen über seinen Zustand an Replica Location Indices weiter. Erhält ein RLI eine Information, die er nicht gespeichert hat, erstellt dieser einen neuen Eintrag mit der entsprechenden Information. Ansonsten wird die bestehende Information aktualisiert oder ersetzt. Zum Aktualisieren der Einträge wird von einem RLI für jeden Eintrag ein Timeout vergeben. Erhält der RLI in der vorgegebenen Zeit keine Information von einem LRC über einen Eintrag, wird der entsprechende Eintrag gelöscht. Verwaltung der Informationen über Zugehörigkeit und Aufteilung Jeder LRC und RLI Server verwaltet selbst beschreibende Metadaten, die an andere Dienste weitergegeben werden können. Wird ein Server entwickelt, erhält er neben diesen Metadaten Informationen über einige Komponenten im System. Kommt der Server in das System, senden alle 8

9 Komponenten ihre Metadaten an die ihnen bekannten Komponenten. Die RLS Komponenten können im Anschluss durch bestimmte Mechanismen Informationen über andere Komponenten erhalten. 2. Auswahl von Replikationen Bei der Auswahl einer Replikation sind mehrere Faktoren entscheidend. Zum einen ist es dafür wichtig zu wissen, wie schnell ein Speichersystem in der Lage ist die angeforderte Replikation auszuliefern, zum anderen muss man wissen unter welchen Bedingungen man auf das Speichersystem zugreifen darf, also ob der Benutzer oder die Anwendung die benötigten Rechte besitzt, um auf die Daten zugreifen zu können. Diese Informationen werden durch zwei Komponenten des Globus Toolkits gesammelt: GRIS Im Grid enthält jedes Speichersystem einen Grid Resource Information Server (GRIS), der Informationen über das Speichersystem speichert. Zu diesen Informationen zählen die Speicherkapazität des Speichersystems, Suchzeiten und Beschreibungen über Policies, die die Benutzung des Speichersystems regeln. Data Access Service Um Aussagen über die Geschwindigkeit des Speichersystems machen zu können, werden Informationen über frühere Datentransferraten gespeichert. Auf diese Weise werden Informationen über die Leistung des Speichersystems gesammelt, die bei der Auswahl einer Replikation wichtig sein könnten. Storage Broker Der Storage Broker stellt eine dezentralisierte Strategie dar, die eine entsprechende Auswahl von Replikationen trifft. Benötigt eine Anwendung Zugriff auf eine Datei, spezifiziert sie ihre Bedürfnisse als Classified Advertisement und gibt diese an den Broker weiter. Dabei sind Classified Advertisements Mechanismen, die die Bedürfnisse eines Jobs mit der Leistungsfähigkeit von Ressourcen vergleicht und beide zusammen führt. Der Broker durchläuft anschließend die folgenden Phasen: Such Phase: Der Replica Catalog wird durchsucht um eine zu den Bedürfnissen der Anwendung passenden Replikationen zu finden. Durchsuchen jedes Speicherortes einer Replikation. Dabei werden die zum Speichersystem gehörenden GRIS mit durchsucht. Jedes Speichersystem liefert seine Leistungsfähigkeit und die Policies zur Benutzung zurück. Der Broker sammelt alle diese Informationen. Match Phase: Die gesammelten Informationen über das Speichersystem werden in das ClassAd (Classified Advertisement) Format konvertiert 9

10 Der Broker vergleicht die im ClassAd gespeicherten Informationen der Applikation mit den ClassAds der Speichersystemen verglichen. Die passenden Speicherorte werden in einer Liste gespeichert. Mit der Rankingeigenschaft des ClassAd können den Treffern, basierend auf einigen spezifizierten Eigenschaften, Prioritäten zugeordnet werden. Zugriffsphase: Wurde eine passende Replikation gefunden, wird auf diese durch ein Transferprotokoll, z.b. GridFTP, zugegriffen. 3. GDMP Im diesem Kapitel wird an Hand von GDMP eine Replikationsarchitektur vorgestellt, die vom Forschungsinstitut Cern entwickelt wurde und dort auch eingesetzt wird. Es wird dabei im wesentlichen auf die Version 2.0 eingegangen, die seit Oktober 2001 zur Verfügung steht. Im Anschluss wird auf die aktuelle Version 4.0 eingegangen und kurz die Neuerungen gegenüber der Version 2.0 angesprochen. 3.1 GDMP 2.0 Allgemein GDMP ist ein Client-Server Replikationswerkzeug, das sicheres und effizientes Kopieren von Dateien im Grid ermöglichen soll. Es baut dabei auf den oben beschriebenen Datenmanagement Komponenten des Globus Toolkit auf. So wurde bisher die Verwaltung der Dateien durch den Replica Catalog geregelt. Die aktuelle Version 4.0 (Stand Februar 2003) verwendet statt dessen den Replica Location Service. Im Folgenden wird nur auf die Version 2.0, die auf dem Replica Catalog basiert, beschrieben. Anschließend wird kurz auf die Änderungen gegenüber der Version 4.0 eingegangen. GDMP würde vom Forschungsinstitut CERN entwickelt und sollte helfen die große Datenmenge zu verwalten und den Benutzern zugänglich zu machen. Die ersten Versionen von GDMP beschränkten sich nur auf Objektivity-Dateien, ab der Version 2.0 können inzwischen beliebige Dateiformate repliziert und verwaltet werden. Auf Grund der hohen Zahl an Objekten (Im Forschungsinstitut Cern entstehen bei den Messungen 10 7 bis Objekte bei einem Experiment) und der geringen Größe eines Objektes, kann nicht jedes Objekt in einer eigenen Datei gespeichert werden. Statt dessen werden diese in Dateien gespeichert. Dabei ist die Speicherung nur dann effizient, wenn eine hohe Anzahl an Objekten pro Datei gespeichert werden. Eine Einschränkung die GDMP macht ist, dass auf die Objekte nur lesend zugegriffen werden kann. Da die Objekte nur Messdaten speichern, stellt dies keine starke Einschränkung da. GDMP erlaubt, wie bereits beschrieben, Versionierung. Interne Kataloge Zur Überwachung des Replikationsprozesses und zur Buchführung verwendet GDMP neben dem Replica Catalog einige interne Kataloge. Zu diesen Katalogen gehört ein interner Datenkatalog. 10

11 Erstellt eine Seite eine oder mehrere Dateien, wird im Anschluss jede Datei in diesem Katalog registriert. Im Gegensatz zu dem Replica Catalog enthält dieser Datenkatalog nur die Dateien, die lokal verfügbar sind. Ein Eintrag enthält den physikalischen Dateinamen sowie logische Dateiattribute wie den logischen Dateinamen, Größe, Zeit der Erstellung und Datentyp. Alle Einträge im lokalen Datenkatalog werden ebenfalls im Replica Catalog veröffentlicht und alle angemeldeten Seiten Informiert. Der lokale Datenkatalog ist nur für den lokalen GDMP Server sichtbar, für alle anderen Benutzer bleibt er unsichtbar. Weiterhin existiert auf jeder Seite jeweils ein Export- und ein Importkatalog. Diese werden für die Veröffentlichung und Übertragung von Dateien benötigt. Der Vorgang ist dabei folgender: Alle neu erstellten Dateien, bzw. Änderungen im Datenbestand werden automatisch erkannt. Basierend auf diesen Änderungen wird ein lokaler Exportkatalog erstellt, der diese Dateien, sowie deren Informationen, enthält. Im Anschluss wird dieser Katalog an alle Seiten verschickt, die sich angemeldet haben. An der Zielseite wird der Exportkatalog in Importkatalog umbenannt, um zwischen dem importierten und lokal erstellten Exportkatalogen unterscheiden zu können. Will eine Verbraucherseite Dateien haben, erzeugt sie, basierend auf den erhaltenden Exportkatalogen, einen Importkatalog, in dem alle Dateien aufgelistet werden, die von den jeweiligen Erzeugern veröffentlicht, aber noch nicht übertragen wurden. Neben den Namen aller physikalischer und logischer Dateinamen enthält der lokale Importkatalog den jeweiligen Namen des FTP-Servers für die Datenübertragung. Abbildung 5: Kataloge bei GDMP GDMP Server GDMP stellt einen Server für jede Seite bereit, der mit anderen entfernten Seiten interagiert. Er initialisiert Anfragen zur Replikation von Dateien indem er Client Kommandos zur Verfügung stellt. Dazu gehört, dass er Informationen über verfügbare Dateien an entfernte Seiten weiter gibt und diese benachrichtigt, wenn neue Dateien auf der Seite verfügbar sind. 11

12 GDMP Client Der GDMP Client stellt verschiedene Services für das Datenmanagement zur Verfügung. Dazu gehört, das Anmelden an einer entfernten Seite. Auf diese Weise wird der Client informiert, wenn diese Seite neue Dateien erstellt oder repliziert. Nachdem sich der Client bei dieser Seite angemeldet hat, kann er sich über einen weiteren Service den Exportkatalog dieser Seite liefern lassen. Das Veröffentlichen von neu erstellten Dateien stellt ebenfalls einen Service des GDMP Clients dar. In diesem Fall werden die neuen Daten in den Exportkatalog geschrieben und an alle Seiten geschickt, die sich an dieser Seite angemeldet haben. Sollen Dateien repliziert werden, sorgt eine Funktion des Clients dafür, dass diese Dateien von einer entfernten Seite übertragen wird. Bevor der GDMP Client auf Anfragen an den Server stellen kann, muss dieser zuerst authentifiziert und autorisiert werden. Dies geschieht bei GDMP durch den Security Layer, der zu diesem Zweck GSI verwendet. Die Anfragen werden nicht direkt an den GDMP Server gestellt, sondern werden an den Request Manager gerichtet. Dieser stellt ein Modul zu Client-Server Kommunikation dar und implementiert die Serverfunktionen, die benötigt werden um die Anfragen der Clients bearbeiten zu können. 3.2 GDMP Architektur Abbildung 4 zeigt die wesentlichen Komponenten von GDMP. Neben dem Request Manager, der die Anfragen des Clients steuert, und dem Security Layer für die Autorisierung der Clients, basiert GDMP auf dem Replica Catalog Service, dem Data Mover Service und dem Storage Manager Service. Diese drei Services werden in den folgenden Abschnitten näher beschrieben. Abbildung 6: Architektur und grundlegende Services von GDMP Replica Catalog Service GDMP setzt in der Version 2.0 für den Replica Catalog Service den Replica Catalog ein. Mit seiner Hilfe wird ein globaler Namensraum im Grid erreicht. Dies geschieht, in dem er sicher stellt, dass 12

13 jeder Name einer Datei im Katalog eindeutig ist. Die Dateinamen können entweder automatisch erstellt oder vom Benutzer festgelegt werden. Da jede Datei nach ihrere Erzeugung im Replica Catalog eingetragen wird, ist sichergestellt, dass jeder Name eindeutig ist. Weiterhin ist der Replica Catalog Service dafür verantwortlich, dass replizierte und neu erstellte Dateien im Replica Catalog eingefügt und veröffentlicht werden. Dazu werden die oben genannten Informationen wie Dateiname, Größe, Datum der Erstellung, usw. (siehe Replica Catalog), in den Replica Catalog eingefügt. Die Veröffentlichung erfolgt dabei wie folgt. Nach dem die Dateien im Replica Catalog und den lokalen Datenkatalog eingefügt sind, werden alle Clients über die Änderungen informiert, die sich bei der Daten erzeugenden Seite angemeldet haben. Sie erhalten, wie oben beschrieben, einen aktuellen Exportkatalog der Seite. Ein weiterer Service, den der Replica Catalog Service zur Verfügung stellt, ist das Ermöglichen von Benutzeranfragen auf dem Katalog. Ein Benutzer oder eine Anwendung kann Filter definieren nach denen der Katalog durchsucht werden soll. Er erhält alle Informationen zu den Dateien zurück, die auf seine Anfrage passen. Diese Informationen enthalten die Metadaten der Dateien und alle physikalischen Instanzen der Dateien. Aufbauend auf diesen Informationen kann eine Datei zur Replikation ausgewählt werden. Data Mover Service Anfragen zur Replikation von Dateien gehen an den Data Mover Service. Er wird zur Bearbeitung von Transferanfragen verwendet. Da der Transfer zugleich schnell und sicher sein muss, wird GridFTP verwendet. Für den Datentransfers selbst gibt es auf jeder Seite einen lokalen Dateitransfer Server. Dies ist in den meisten Fällen ist dies ein FTP-Server der GridFTP implementiert. Da eine große Menge an Daten transferiert wird, muss der Data Mover Service in der Lage sein, Netzwerkfehler zu erkennen und zu behandeln. Zusätzlich besitzt der Service weitere Mechanismen um die Verfälschung von Daten zu erkennen und die Übertragung ggf. neuzustarten. Storage Management Service Die Replikation der Daten erfolgt im Allgemeinen nicht von disk to disk, da bei der großen Datenmenge im Grid nicht alle Daten immer direkt zugreifbar sind. Statt dessen werden die Daten in einem Massenspeicher System gespeichert. Bei Bedarf werden die Daten von Band auf Festplatte gespeichert. Jede Seite hat einen lokalen disk pool, der als Cache für den Datentransfer verwendet wird. Dort hin werden die Daten, die repliziert werden sollen, geladen. Es gibt zusätzlich ein Massenspeicher System auf dieser Seite. Die Möglichkeit, Daten zwischenspeichern zu können ist notwendig, wenn man nur begrenzten Speicherplatz zur Verfügung hat und viele Benutzer gleichzeitig Daten anfragen. GDMP stellt mit dem Storage Management Service ein Interface zu Massenspeicher Systemen dar, indem es externe Werkzeuge zum Zwischenspeichern der Daten benutzt. Diese Werkzeuge werden für jeden MSS-Typ benötigt um die Daten zwischenzuspeichern. 13

14 Da im Replica Catalog die physikalischen Speicherorte einer Datei gespeichert sind, wird dort zuerst nachgesehen, ob die Datei dort verfügbar ist. Fragt eine Seite eine Replikation an, die sich nicht im disk pool befindet, wird ein Prozess gestartet um die entsprechenden Daten von Band in den disk pool zu kopieren. Der GDMP Server benachrichtigt anschließend die anfragende Seite, dass die Datei nun verfügbar ist und startet automatisch den Transfer der Daten. 3.3 Replikation mit GDMP GDMP stellt zwei verschiedene Arten der Replikation zur Verfügung: Datei- und Objektreplikation. Bei der Datei-Replikation werden die Daten auf Basis von existierenden Dateien repliziert, d.h. es werden nur bereits bestehende Dateien für die Replikation verwendet und keine Dateien eigens für den Replikationsprozess erzeugt. Die Objektreplikation erfolgt hingegen auf Basis bestehender Objekte. Wie bereits beschrieben, werden Objekte in GDMP in Dateien gespeichert. Der Mechanismus der Objektreplikation kopiert jedoch nicht die Dateien, sondern die Objekte aus den jeweiligen Dateien. Dabei werden mögliche bestehende Beziehungen zwischen den Objekten vernachlässigt. Beide Replikationsmechanismen sollen im Folgenden vorgestellt werden. Probleme bei der Replikation und Lösung durch GDMP Sicherheitsprobleme stellen ein wichtiges Problem bei der Replikation von Daten dar. Bevor auf die Daten zugegriffen werden darf, muss der Benutzer authentifiziert und autorisiert werden um den Zugriff auf das Speichersystem kontrollieren zu können. GDMP löst dieses Problem durch den Security Layer, der die Clients authentifiziert bevor sie auf den Server zugreifen dürfen. Ebenfalls sorgt der Request Manager dafür, dass nicht direkt auf die Server zugegriffen wird. Ein weiterer Aspekt bei der Replikation von Dateien ist, dass man meist nicht an allen Teilen der Dateien interessiert ist. Im Falle von GDMP hieße das, dass man nur einige der Objekte in einer Datei repliziert haben will, nicht aber die gesamte Datei. Um dies zu ermöglichen, verwendet GDMP den Mechanismus der Objektreplikation. Existieren mehrere Replikationen einer Datei, können Probleme auftreten wenn Dateien geändert wurden. Diese Änderungen müssen im Allgemeinen an alle Replikationen weiter gegeben werden. GDMP geht diesem Problem aus dem Weg, indem der Zugriff auf Objekte nur lesend möglich ist und Änderungen an Objekten durch Versionierung geregelt werden. Die Verschiedenen Möglichkeiten diese Änderungen weiterzugeben, wurden bereits zuvor vorgestellt. Weitere Änderungen, die durch Replikation und das Erstellen von neuen Dateien entstehen, müssen dem Replica Catalog bekannt gemacht werden. Dies geschieht bei GDMP, wie bereits beschreiben, durch einen Service des Replica Catalog Service Dateireplikation Probleme bei der Datei-Replikation Neben den oben beschriebenen Problemen bei der Replikation von Daten, gibt es bei der Datei- Replikation einen weiteren zu beachtenden Aspekt. So ist der zur Replikation verwendete 14

15 Mechanismus nicht in der Lage jede Datei als eigenständig und abgeschlossen zu behandeln. Enthält eine Datei ein Objekt, das auf ein Objekt in einer anderen Datei verweist, so besteht zwischen diesen beiden Dateien eine Beziehung. Würde der Mechanismus diese Beziehungen vernachlässigen und die angeforderten Dateien replizieren, gingen diese Beziehungen und die damit verbundenen Informationen auf der Zielseite verloren. Um dieses Problem zu umgehen und die Beziehungen zu erhalten, werden bei der Anfrage zur Replikation einer Datei alle Dateien gesucht, die in Beziehung zu der angeforderten Datei stehen. Diese Dateien werden als zusammengehörige Dateien betrachtet und dementsprechend zusammen repliziert. GDMP Replikationsprozess Der von GDMP verwendete Replikationsprozess basiert auf dem Erzeuger-Verbraucher Prinzip. Stehen auf einer Seite neue Dateien, z.b. durch Replikation oder Erstellen einer Datei, so können diese anderen Seiten im Grid bekannt gemacht werden. Damit die Verbraucherseiten diese Informationen erhalten können, müssen sie sich zuvor bei der Erzeugerseite angemeldet haben. Nachdem die Informationen ausgetauscht sind und eine Anfrage zur Replikation gestellt wurde, gewährleistet GDMP, dass die benötigten Transferoperationen erfolgreich ablaufen. Replikationsschritte Wie bereits erwähnt wurde GDMP zunächst entwickelt um Objectivity-Dateien zu replizieren. Dies findet sich in den verschiedenen Replikationsschritten wieder. Dort gibt es verschiedene Schritte, die hauptsächlich für solche Dateien benötigt werden, aber für die meisten anderen Dateiformate entfallen kann. Die Schritte sind im einzelnen: Vorbereitung: Die Zielseite muss für Replikation vorbereitet werden. Dieser Schritt ist abhängig vom Dateiformat und kann in einigen Fällen entfallen. Dieser Schritt ist beispielsweise für Objectivity-Dateien notwendig. Zu den notwendige Schritten gehören Maßnahmen um die Dateien problemlos in den bestehenden Verbund einfügen zu können. Datentransfer: Transfer der zu replizierenden Datei. Dieser muss sicher und effizient geschehen. Nachbereitung: Dieser Schritt ist ebenfalls abhängig vom Dateiformat und kann in einigen Fällen entfallen. Zu den Operationen zählt das Einbinden einer Datenbankdatei in einen lokalen Verbund. Eintrag in den Replikationskatalog: Um den Replica Catalog auf dem aktuellen Stand zu halten und den logischen Namen auf die neuen physikalischen Dateien abzubilden, werden die Dateien in den Katalog eingetragen Objektreplikation Wie bei den Problemen der Replikation bereits angesprochen, ist man bei Replikationsanfragen meist nicht an der gesamten Datei interessiert, sondern nur an bestimmten Objekten in der Datei. Will ein Benutzer eine hohe Zahl von Objekten haben, kann der zuvor vorgestellte Mechanismus 15

16 der Datei-Replikation schnell ineffizient werden. Sucht man nur bestimmte Objekte, so müssen zunächst alle Dateien gefunden werden, die mindestens eines der gesuchten Objekte enthalten um aus diesen Dateien die zu bestimmen, die für die Replikation ausgewählt werden sollen. Die Suche liefert im Allgemeinen eine große Menge an Dateien, bei denen hinzukommt, dass sie nur wenige der gesuchten Objekte enthält. Würde man in diesem Fall den Mechanismus der Datei-Replikation verwenden, müsste eine sehr große Menge an Dateien repliziert, transferiert und in den Katalogen eingetragen werden. Um dennoch in diesem Fall effektiv Dateien, bzw. Objekte, replizieren zu können, wurde der Mechanismus der Objektreplikation entwickelt. Auch hier ist es notwendig, Dateien zu finden, die die angeforderten Objekte enthalten. Allerdings reicht es hierbei aus, ein Objekt ein Mal zu finden. Wurden alle Objekte gefunden, werden sie mit Hilfe eines Objektkopier-Werkzeug aus den jeweiligen Dateien kopiert. Anschließend wird eine neue Datei erzeugt, in die die angeforderten Objekte geschrieben werden. Ist dies geschehen, kann die Datei an die Zielseite transferiert werden und an der Quellseite gelöscht werden. 3.4 Einige GDMP-Werkzeuge Im Folgenden werden kurz einige der Funktionen vorgestellt die GDMP für das Datenmanagement zur Verfügung stellt. gdmp_filter_ Möchte man nicht alle im Importkatalog zur Verfügung stehenden Dateien replizieren, ermöglicht diese Funktion es den Katalog zuvor zu filtern. Es können dabei mehrere Filter verwendet werden um Kataloge zu im- und/oder exportieren. Die Funktion stellt dabei zwei Arten von Filtern zur Verfügung: positive und negative Filter. Positive Filter wählen alle Dateien aus, welche die angegebenen Bedingungen erfüllen und löschen alle anderen Dateien aus dem Katalog. Negative Filter löschen alle Dateien, die mindestens eins der angegebenen Kriterien erfüllen. Die Filter löschen nur die Einträge aus dem jeweiligen Katalog, jedoch nicht die Dateien selbst. gdmp_get_ Bekommt eine Seite wegen Server- oder Netzwerkfehlern Änderungen nicht mit, ist sie dafür verantwortlich sich die neusten Informationen bei den anderen Seiten zu beschaffen. Das Programm ermöglicht es sich den Exportkatalog einer Seite geben zu lassen und einen entsprechenden lokalen Importkatalog zu erzeugen. gdmp_host_subscribe Die Funktion ermöglicht es einem Host sich bei einem anderen Host im Grid anzumelden um über neue erstellte Dateien informiert zu werden. gdmp_ping Diese Funktion bietet die Möglichkeit zu überprüfen, ob auf einer angegebenen Seite ein GDMP Server läuft. Hierbei kann ein Timeout angegebenen werden. Im allgemeinen sollte vor jedem Datentransfer die Erreichbarkeit der entsprechenden entfernten Seite überprüft werden. gdmp_publish_ 16

17 Auf Basis des lokalen Datenkatalogs wird ein Exportkatalog mit den zu veröffentlichenden Dateien erstellt. Eine Kopie dieses Katalogs wird anschließend an alle angemeldeten Hosts gesendet und die gesamten Replikationsinformationen in dem Replica registriert. gdmp_register_local_file Wurde eine neue Datei erzeugt, sorgt diese Funktion dafür, dass der logische und physikalische Dateiname, die Größe, das Datum der Änderung und der Dateityp in den lokalen Datenkatalog eingetragen werden. gdmp_replicate_get Fordert eine Seite eine Datei an, sorgt diese Funktion dafür, dass diese Dateien von einem entfernten Host transferiert. Dabei kann die Funktion von mehreren Clients auf einem Katalog ausgeführt werden. Das System ermöglicht dabei die Nebenläufigkeit. gdmp_remove_local_file Soll eine Datei von der Festplatte gelöscht werden, müssen zusätzlich alle Einträge in allen verfügbaren Katalogen überprüft werden. Befindet sich ein Eintrag zu der zu löschenden Datei in einem der Kataloge (lokaler Datenkatalog, Exportkatalog, Importkatalog, Replica ), wird dieser Eintrag ebenfalls gelöscht. 3.5 GDMP 4.0 Neben der Möglichkeit den Replica zur Verwaltung der Replikationen, besteht in der aktuellen Version 4.0 (Stand Februar 2003) die Möglichkeit den Replica Location Service einzusetzen. Die Aktualisierung der einzelnen LRCs erfolgt durch den GDMP Server. Jeder Server ist so konfiguriert, dass er einen einzelnen LRC aktualisieren. Dies kann jeder beliebiger LRC sein, wobei empfohlen wird einen LRC zu wählen, der sich ebenfalls auf der Serverseite befindet oder sich am besten auf dem gleichen Speicherelement befindet. Der LRC wird mit den Informationen über den logischen und physikalischen Dateinamen aktualisiert. Im Anschluss an diese Aktualisierung, werden diese an den RLI weiter gegeben. 4. Referenzen GridFTP und Replica Catalog: File and Object Replication in Data Grids, H. Stockinger, A. Samar, B. Allcock, I. Foster, K. Holtman, and B. Tierney; Proc. of the Tenth International Symposium on High Performance Distributed Computing (HPDC-10), IEEE Press, August Secure, Efficient Data Transport and Replica Management for High-Performance Data-Intensive Computing, B. Allcock, J. Bester, J. Bresnahan, A. Chervenak, I. Foster, C. Kesselman, S. Meder, V. Nefedova, D. Quesnel, and S. Tuecke; submitted to IEEE Mass Storage Conference, April Getting Started with the Globus Replica Catalog ( Replica Location Service: 17

18 Giggle: A Framework for Constructing Scalable Replica Location Services, A. Chervenak, E. Deelman, I. Foster, L. Guy, W. Hoschek, A. Iamnitchi, C. Kesselman, P. Kunst, M. Ripeanu, B, Schwartzkopf, H, Stockinger, K. Stockinger, B. Tierney. Proceedings of Supercomputing 2002 (SC2002), November Auswahl von Replikationen: Replica Selection in the Globus Data Grid, S. Vazhkudai, S. Tuecke, and I. Foster; Proc. of the First IEEE/ACM International Conference on Cluster Computing and the Grid (CCGRID 2001), pp , IEEE Computer Society Press, May GDMP: Secure, Efficient Data Transport and Replica Management for High-Performance Data-Intensive Computing, B. Allcock, J. Bester, J. Bresnahan, A. Chervenak, I. Foster, C. Kesselman, S. Meder, V. Nefedova, D. Quesnel, and S. Tuecke; submitted to IEEE Mass Storage Conference, April GDMP User guide 4.0 GDMP User guide 2.0 Getting Started with the Globus Replica Catalog ( 18