Grid-Technologien im Rechenzentrum Das Condor-System

1. Grid-Technologien im Rechenzentrum Das Condor-System Horst Wenske RechenzentrumUniversität Karlsruhe (TH) Horst.Wenske@rz.uni-karlsruhe.de

2. Übersicht • Was ist das Condor Projekt/System? • Eigenschaften von Condor • Das Condor Daemon Layout • Ein kleines Benutzerbeispiel • Condor-G • Der Einsatz von Condor im RZ Karlsruhe.

3. Das Condor Projekt • Das Condor Projekt ist 1985 gegründet worden • Momentan arbeiten ca. 40 Vollzeitentwickler an Condor • Es existieren inzwischen viele Unterprojekte die mit Condor zusammenarbeiten • Condor wird in akademischen, wissenschaftlichen und wirtschaftlichen Sektor eingesetzt • Seit den letzten Jahren arbeitet die Grid Community eng mit dem Condor Projekt zusammen.

4. Was ist das Condor System? • Condor ist ein spezialisiertes Workload Management System für rechenintensive Jobs • Condor verfügt über viele Eigenschaften eines klassichen Batch Systems: • Job Queueing • Scheduling Policies • Prioritäten Modelle • Ressourcen Monitoring • Ressourcen Management • Condor unterstützt dedizierte und „on-demand“ Rechencluster • Condor kann z.B. brachliegende Rechenleistung von nicht genutzten Workstations und Poolraum PCs nutzbar machen.

5. Eingenschaften von Condor • Der Source Code von einem Condor Job muss nicht modifiziert werden • Condor bietet PVM und MPI (MPICH) Unterstützung • Im „Standard Universe“ sind Job Migration und Checkpointing möglich • Condor bieter ein sehr flexibles Ressourcen Matching durch ClassAds • Eine spezielle Condor Version (Condor-G) arbeitet mit Globus zusammen • Das Verbinden von verschiedenen Condor Pools ist möglich (Condor Flocking) • …

6. Die Condor Software • Man kann Condor auf den Condor Webseiten herunterladen http://www.cs.wisc.edu/condor • Operating System Unterstützung: • Erhältlich für viele Unix Systeme (z.B. Linux, Solaris, HPUX, Irix) • Erhältlich für Windows NT / XP • Condor Public Licence.

7. Personal Condor / Central Manager negotiator startd schedd collector Das Condor Daemon Layout Master

8. Der condor_master Daemon • Der Master Daemon startet und überwacht alle anderen Condor Daemonen. • Er läuft auf jedem Condor Knoten • Er überwacht, ob neue Daemon Binärdateien existieren, und restarted „schonend“ einen entsprechenden Daemon • Er dient weiterhin als Server für entfernte Administrationsbefehle. • condor_reconfig, condor_restart, condor_on, condor_off, …

9. Der condor_collector Daemon • Der condor_collector läuft nur auf den so genannten Central Manager des Condor Pools • Der “definiert” einen Condor Pool • Es gibt einen Collector pro Pool • Es sammelt die Informationen von allen anderen Condor Daemonen im Pool • “Directory Service” / Datenbank für einen Condor Pool • Jeder Daemon schickt periodische Updates (“ClassAds”) zum Collector • Bedient Dienstanfragen: • Anfrangen von Condor Daemonen. • Anfragen von Condor Anwendern (condor_status).

10. condor_status % condor_status Name OpSys Arch State Activity LoadAv Mem ActvtyTime haha.cs.wisc. IRIX65 SGI Unclaimed Idle 0.198 192 0+00:00:04 antipholus.cs LINUX INTEL Unclaimed Idle 0.020 511 0+02:28:42 coral.cs.wisc LINUX INTEL Claimed Busy 0.990 511 0+01:27:21 doc.cs.wisc.e LINUX INTEL Unclaimed Idle 0.260 511 0+00:20:04 dsonokwa.cs.w LINUX INTEL Claimed Busy 0.810 511 0+00:01:45 ferdinand.cs. LINUX INTEL Claimed Suspended 1.130 511 0+00:00:55 vm1@pinguino. LINUX INTEL Unclaimed Idle 0.000 255 0+01:03:28 vm2@pinguino. LINUX INTEL Unclaimed Idle 0.190 255 0+01:03:29

11. Der condor_startd Daemon • Er representiert eine Machine im Condor System • Er is verantwortlich Jobs zu starten, suspenden und zu stoppen • Er setzt die Wünsche des Besitzers des Rechners/Rechenknotens durch (der Besitzer kann Policies definieren, wann und wie sein Rechner benutzt werden darf) • Er existiert nur auf “execute” Knoten.

12. Der condor_schedd Daemon • Er existiert nur auf “submit” Knoten (Rechner von denen man eine Job abschicken kann) • Er verwaltet eine persistente Queue von Jobs • Er is verantwortlich fürs Kontaktieren von verfügbaren Rechnern und dem schicken von Jobs • Er bedient Anwenderanfragen welche sich auf Jobs beziehen: • condor_submit,condor_rm, condor_q, condor_hold, condor_release, condor_prio, …

13. Der condor_negotiator Daemon • Er befindet sich nur auf dem Central Manager • Es gibt nur einen condor_negotiator Daemon pro Pool • Er führt das sogenannte “Matchmaking” in Condor durch • Er bekommt Informationen vom Collector, welche Ressourcen verfügbar sind und welche Jobs abgearbeitet werden müssen • Er versucht ein “Match” von Job und Ressource zu finden • Dieser Match wird als “Vorschlag” an Job und Ressource geschickt • Sowohl Job als auch Ressource Maschine müssen die gegenseitigen Bedingugen erfüllen, damit der Job ausgeführt wird.

14. Cluster Node = Process Spawned Central Manager Master Master Master startd negotiator schedd schedd Cluster Node Master Master startd Desktop Desktop Master Master Layout von einem Condor Pool = ClassAd Communication Pathway Master negotiator Collector Master Master startd startd schedd schedd

15. Die ersten Schritte mit Condor • Der Benutzer muss ein “Universe” für seinen Job wählen • Z.B. Vanilla Universe • Der Benutzer muss seinen Job “batch-ready” machen (z.B. keine interaktiven Eingaben, keine weiteren Prozesse forken etc.) • Der Benutzer muss eine sogenannte Submit Description Datei erstellen • Mit dem Ausführen vom condor_submitBefehl mit der Submit Description Datei als Argument, wird der Job in die lokale Queue aufgenommen.

16. Erstellung einer Submit Description Datei • Eine normale ASCII Textdatei • Die Dateiendung spielt für Condor keine Rolle • Versorgt Condor mit den notwendigsten Job Informationen • Welche auführbare Datei, Universe, Input, Output und Error Dateien benutzt werden sollen. • Command-line Argumente, Umgebungsvariabeln, besondere Jobanforderungen, … • Es köennen viele Jobs auf einmal spezifiziert werden (ein Job Cluster), die jeweils unterschiedliche Input/Output Dateien und Argumente haben können.

17. Einfache Submit Description Datei # Simple condor_submit input file # (Lines beginning with # are comments) # NOTE: the words on the left side are not # case sensitive, but filenames are! Universe = vanilla Executable = my_job Queue

18. Der Befehl condor_submit • Als erstes gibt man den Befehl condor_submit mit dem Pfad zur gespeicherten Job Description ein: • condor_submit my_job.submit • condor_submit parst die Submit Datei, prüft auf Fehler und erstellt eine “ClassAd”, die den Job beschreibt.

19. ClassAds • ClassAds stellen Condors interne Datenrepresentation dar • Sie sind ähnlich zu klassifierten Werbeanzeigen/Suchanfragen • Sie representieren ein Objekt und seine Attribute • Es kann auch beschreiben, mit was ein Objekt kompatibel ist.

20. ClassAd einer Maschine [ Type = "Machine";Activity = "Idle";DayTime = 36107 // current timeKeyboardIdle = 1432; // secondsDisk = 323496; // kbytesMemory = 64; // megabytesState = "Unclaimed";LoadAvg = 0.042969;Mips = 104;Arch = "INTEL";OpSys = "SOLARIS251";Kflops = 21893; Name = "foo.cs.wisc.edu";ResearchGroup = { "raman", "miron", "solomon"};Rank = member(other.owner, ResearchGroup) ? 10 : 0;Constraint = KeybrdIdle>'0:15': Daytime()<'8:00' || Daytime()>'18:00'; ]

21. ClassAd eines Jobs [ Type = "Job";QDate = 886799469; // Submit time secs. past 1/1/1970CompletionDate = 0;Owner = "raman";Cmd = "run_sim";WantRemoteSyscalls = 1;WantCheckpoint = 1;Iwd = "/usr/foo/foo1";Args = "-Q 17 3200 10";Memory = 31; Rank = KFlops/1E3 + other.Memory/32;Constraint = other.Type == "Machine" && other.Arch == "INTEL„ && other.OpSys == "SOLARIS251„ && other.Disk >= 10000 && other.Memory >= self.Memory; ]

22. Die Job Queue • Der condor_submit Befehl sendet die Jobs ClassAd zu den Schedd Daemon. • Dieser verwaltet die lokale Job Queue • Er speichert den Job in der lokalen Job Queue • Das ist eine atomare Operation, Zwei-phasen commit • Man kann sich den Status der lokalen Queue mit dem Befehl condor_qausgeben lassen.

23. Die Ausgaben von condor_submit und condor_q % condor_submit my_job.submit Submitting job(s). 1 job(s) submitted to cluster 1. % condor_q -- Submitter: perdita.cs.wisc.edu : <128.105.165.34:1027> : ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD 1.0 frieda 6/16 06:52 0+00:00:00 I 0 0.0 my_job 1 jobs; 1 idle, 0 running, 0 held

24. Weitere Information über einen Job • Diese Einstellungen kann man in der Submit Datei genauer spezifizieren • Condor verschickt normalerweise Emails bei Events • Generell Deaktivieren: Notification = Never • Nur bei Fehlern informieren: Notification = Error • Condor erstellt Log Dateien (user log) • “Beinhaltet die Lebensgeschichte eines Jobs“ • Zeigt alle Events in dem Leben des Jobs an • Man sollte immer ein Logfile haben. • Ein Logfile wird aktiviert durch: Log = filename

25. Beispiel einer Condor User Log Datei 000 (0001.000.000) 05/25 19:10:03 Job submitted from host: <128.105.146.14:1816> ... 001 (0001.000.000) 05/25 19:12:17 Job executing on host: <128.105.146.14:1026> ... 005 (0001.000.000) 05/25 19:13:06 Job terminated. (1) Normal termination (return value 0) Usr 0 00:00:37, Sys 0 00:00:00 - Run Remote Usage Usr 0 00:00:00, Sys 0 00:00:05 - Run Local Usage Usr 0 00:00:37, Sys 0 00:00:00 - Total Remote Usage Usr 0 00:00:00, Sys 0 00:00:05 - Total Local Usage 9624 - Run Bytes Sent By Job 7146159 - Run Bytes Received By Job 9624 - Total Bytes Sent By Job 7146159 - Total Bytes Received By Job

26. Condor Condor ermöglicht Job Scheduling über viele verschiedene Ressourcen hinweg Es verfügt über starke Fehlertoleranz durch Checkpointing und Migration Kann eine Schicht über Globus als eigenes Batch System für “das Grid” verwendet werden Condor-G: Globus + Condor Globus • Eine Middleware die bei vielen Grid Projekten eingestzt wird • Es ermöglich Zugang zu entfernten Rechenressourcen • Es ermöglich zuverlässlichen und robusten Datentransfer

27. Condor-G Installation Möglichkeiten Condor-G zu installieren: • Condor-G ist bereits Bestandteil von Condor. Condor-G “entspricht” dem Globus Universe • Condor/Condor-G ist Bestandteil von NMI (NSF Middleware Initiative) • Condor/Condor-G ist Bestandteil von VDT (Virtual Data Toolkit).

28. Condor Globus Universe

29. Der Einsatz von Condor im RZ Karlsruhe • Das RZ Karlsruhe verfügt über ca. 400 Poolrechner • Diese Poolrechner sind in der Regel über 90% der Zeit idle • Wir wollen diese brachliegende Rechenpower für Projekte nutzbar machen • Dabei sollen der Poolbetrieb und Vorlesungen in keiner Weise beeinträchtig werden • Momenten testen wir gerade Condor in unserem Pool Betrieb.

30. Seiteneffekte durch Condor • Ist die Klimaanlage ausreichend für den Condorbetrieb dimensionert? • Lärmentwicklung der PCs unter Volllast während einer Vorlesung • Organisatorische Strukturen des restriktiven Poolbetriebs, die mit Condor in Einklang gebracht werden müssen.

31. Referenzen • Condor Webseiten: http://www.cs.wisc.edu/condor/ • Diplomarbeit: „Condor Clusters with Multilateral Resource Matchmaking in Heterogeneous Networks, von Horst Wenske, Sept. 2003 • Studienarbeit: „Deploying Condor in Restricted Computer Pools“, von Heiko Reese, Sept. 2005