1. Ideen Goobi Storage API
GOOBI – Steuerungsgremium, 23.9.2011, Berlin
Christian Mahnke, SUB Göttingen
2. Bestehende Probleme bzw. Vorgaben
• Probleme mir der Anzahl der Unterordner (FS
Problem - Dresden)
• Storage Anforderungen skalieren schlecht (SAN
Kosten - Göttingen)
• Archivsystem (LZA - Alle)
3. High Level Anforderungen
• Trennung zwischen Speicherbereichen (z.B. Produktions- und
Archivbereich)
– Regelbasierte Zuordnung (z.B Zeit, Präfixe für Master etc.)
• Tiefere Hierarchien (z.B. um FS Limitierungen zu umgehen)
• Import- / Exportfunktionalität
– Bereitstellung im Präsentationssystem
– Bereitstellung auf FTP Server eines Kunden
• Kein zusätzlicher (oder geringer) Aufwand für Systemadministratoren
gewünscht
• Integritätsprüfungen und Ausfallsicherheit, sowie Nachvollziehbarkeit
notwendig
• Projektspezifische Konfigurationen (z.B. für zeitkritische Aufträge)
• Implementierungen von Anforderungen sollten kombinierbar sein
• Externe Zugriffsverfahren (z.B. via Samba) sollten berücksichtigt werden
– Externe Applikationen (über CLI, z.B. Jhove(2)) sollen genutzt werden
können.
5. Anforderungen Anwendungsebene
• Transparenter Umgang mit Objekten
• Nutzung von URIs für interne Referenzierung
• Nutzung von Datenströmen (wo möglich)
• Bereitstellung als temporäre Datei für Legacy
Code und externe Anwendungen (z.B. Samba)
– Berücksichtigung von Berechtigungen
• Synchrone vs. asynchrone Bereitstellung für
Nutzer
6. Anforderungen Storage Verwaltung
• Unterschiedliche Strategien (kombinierbar und
projektspezifisch)
– CDL Pair Tree
– Caches bei Ausfall des unterliegenden Storages
(schreiben)
– Generierung von Prozessmetadaten
• Versionierung für Metadaten
• Checksummen, ggf. inklusive Integritätsprüfung,
Transaktionssicherheit
• Unterschiedliche Aktivierungen
– Manuelle Zuordnung (z.B. Export)
– Schrittgesteuert (z.B. Archivierung)
– Erkennung von ungenutzten Daten basierend auf
Regeln (wie HSM)
7. Anforderungen Storage
• Unterschiedliche Abstraktionsebenen (Beispiele)
– Dateisystem
• Dateien und Verzeichnisse
– „Objektspeicher“ – z.B. TextGrid
• Objekte und Kollektionen (Beinhalten jeweils auch
komplexe Metadaten)
• Unterschiedliche Semantiken (Beispiele)
– Z.B. Update einer Datei vs. Update eines
Objekts (s.o)
– Implizite Versionierung (z.B. kein Löschen
möglich)
– Sichtbarkeit vs. Publizierung
9. Vielen Dank!
Fragen?
mahnke@sub.uni-goettingen.de
9
Editor's Notes
Diese Folien spiegeln Überlegungen aus dem Zeitraum 10/2009 bis 3/2010 wieder, sie werden inzwischen nicht mehr aktiv verfolgt. Es sind allerdings nachnutzbare Anforderungsdefinitionen vorhanden.
Berechtigungen und Eigentümerschaft sind in diesem Modell nur spezielle Metadaten eines Dateisystems Asynchrone Dateioperation werden benötigt, um die Applikation beim Umgang mit großen Datenemengen nicht zu blockieren