Weltuntergang am 10. September?
Ich kann es kaum erwarten bis der Large Hadron Collider läuft, die Welt nicht untergegangen ist und endlich mehr über dieses mysteriöse Higgs-Boson bekannt wird. Und mich würde interessieren ob diese elende komplexe gLite-Middleware mit der mich eine gewisse Hassliebe aufgrund meiner intensiveren fachlichen Beschäftigung mit ihren Internas verbindet, bei dem ganzen Experiment mitspielt.
Weil der LHC nämlich mehr Daten als ein Rechner speichern kann schneller erzeugt als er sie verarbeiten könnte, müssen diese auf einem geographisch verteilten Rechnerverbund (alias Grid) gespeichert werden. Und ob dieses Datagrid die Petabytes von im LHC anfallenden Informationen mit seinen lose gekoppelten, getrennt entwickelten (und das ist das schlimmste: teilweise auf Webservices basierenden) Komponenten dann auch ordentlich verarbeitet, ist wohl genauso fraglich, wie ob es das Higgs-Boson denn nun gibt oder nicht.
Will man eine größere Datei abspeichern, braucht man Castor als Low-Level API, SRM zur Speicherplatzreservierung, LFC zur Registrierung einer damit verbundenen UID und/oder eines logischen Bezeichners und GridFTP zur tatsächlichen Übertragung. Ach ja, und einen gültigen VOMS-Proxy, damit man sich gegenüber dem Storage-Server authentifizieren kann. Damit hätte man allerdings erst die Datei im Datagrid indiziert abgespeichert, aber sie noch nicht im Rahmen eines Jobs verwendet.
Natürlich stammt die Komponenten keineswegs aus einer Hand. Castor wurde am CERN selbst entwickelt, SRM stammt von einer Reihe von Institutionen (u.a. CERN, Fermilab, LBNL und das italienische Nuklearforschungsinstitut), LFC kommt wiederum vom CERN selbst und GridFTP entstand im Rahmen von Globus und ist damit mehr oder weniger direkt auf das Argonne National Laboratory in Chicago zurückzuführen.
Die dazugehörigen Kommandozeilenwerkzeuge laufen ausschließlich unter Scientific Linux, was für Nutzer anderer Betriebssysteme bedeutet: APIs verwenden oder hoffen, dass jemand anders das Higgs-Boson findet. Wäre schön und gut, wären die APIs denn auch schön einheitlich. SRM ist ein Webservice und bietet somit eine SOAP-Schnittstelle, GridFTP ist über eine Java-API und eine Python-API ansprechbar, während LFC nur eine C-Bibliothek als offizielle Interaktionsmöglichkeit vorzuweisen hat. Intern verwendet der LFC ein proprietäres, binäres RPC-Protokoll (!). Immerhin ist die C-Bibliothek auch im Quellcode vorhanden.
So kann man, wenn man viel Zeit oder wie ich keine andere Möglichkeit hat, die Kommunikationsschritte des Protokolls auch in einer anderen Programmierspracheabschreiben nachprogrammieren. Angesichts dessen verwundert es eher, dass das Datagrid überhaupt funktioniert, als dass der Start des LHC öfters verschoben werden musste. "So gerade" schafft man es aber schon damit umzugehen, wenn man ein bisschen Ärger nicht scheut.
Trotzdem bin ich immer noch skeptisch, ob ich mir den kolportierten Weltuntergang tatsächlich schon für den 10. September vormerken sollte.
Aber zum Glück kann man sich die Wartezeit bis dahin noch mit dem kongenialen LHC-Rap vertreiben:
(Youtube-Video als Link)
Weil der LHC nämlich mehr Daten als ein Rechner speichern kann schneller erzeugt als er sie verarbeiten könnte, müssen diese auf einem geographisch verteilten Rechnerverbund (alias Grid) gespeichert werden. Und ob dieses Datagrid die Petabytes von im LHC anfallenden Informationen mit seinen lose gekoppelten, getrennt entwickelten (und das ist das schlimmste: teilweise auf Webservices basierenden) Komponenten dann auch ordentlich verarbeitet, ist wohl genauso fraglich, wie ob es das Higgs-Boson denn nun gibt oder nicht.
Will man eine größere Datei abspeichern, braucht man Castor als Low-Level API, SRM zur Speicherplatzreservierung, LFC zur Registrierung einer damit verbundenen UID und/oder eines logischen Bezeichners und GridFTP zur tatsächlichen Übertragung. Ach ja, und einen gültigen VOMS-Proxy, damit man sich gegenüber dem Storage-Server authentifizieren kann. Damit hätte man allerdings erst die Datei im Datagrid indiziert abgespeichert, aber sie noch nicht im Rahmen eines Jobs verwendet.
Natürlich stammt die Komponenten keineswegs aus einer Hand. Castor wurde am CERN selbst entwickelt, SRM stammt von einer Reihe von Institutionen (u.a. CERN, Fermilab, LBNL und das italienische Nuklearforschungsinstitut), LFC kommt wiederum vom CERN selbst und GridFTP entstand im Rahmen von Globus und ist damit mehr oder weniger direkt auf das Argonne National Laboratory in Chicago zurückzuführen.
Die dazugehörigen Kommandozeilenwerkzeuge laufen ausschließlich unter Scientific Linux, was für Nutzer anderer Betriebssysteme bedeutet: APIs verwenden oder hoffen, dass jemand anders das Higgs-Boson findet. Wäre schön und gut, wären die APIs denn auch schön einheitlich. SRM ist ein Webservice und bietet somit eine SOAP-Schnittstelle, GridFTP ist über eine Java-API und eine Python-API ansprechbar, während LFC nur eine C-Bibliothek als offizielle Interaktionsmöglichkeit vorzuweisen hat. Intern verwendet der LFC ein proprietäres, binäres RPC-Protokoll (!). Immerhin ist die C-Bibliothek auch im Quellcode vorhanden.
So kann man, wenn man viel Zeit oder wie ich keine andere Möglichkeit hat, die Kommunikationsschritte des Protokolls auch in einer anderen Programmiersprache
Trotzdem bin ich immer noch skeptisch, ob ich mir den kolportierten Weltuntergang tatsächlich schon für den 10. September vormerken sollte.
Aber zum Glück kann man sich die Wartezeit bis dahin noch mit dem kongenialen LHC-Rap vertreiben:
(Youtube-Video als Link)
bellerophon - 2. Sep, 23:29
2 Kommentare - Kommentar verfassen - 0 Trackbacks
Trackback URL:
https://keinspass.twoday.net/stories/5165252/modTrackback