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

Ü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.

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.

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.

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) …

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.

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

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, …

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).

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

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.

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, …

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.

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

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_submit Befehl mit der Submit Description Datei als Argument, wird der Job in die lokale Queue aufgenommen.

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.

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

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.

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.

ClassAd einer Maschine [ Type = "Machine"; Activity = "Idle"; DayTime = 36107 // current time KeyboardIdle = 1432; // seconds Disk = 323496; // kbytes Memory = 64; // megabytes State = "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'; ]

ClassAd eines Jobs [ Type = "Job"; QDate = 886799469; // Submit time secs. past 1/1/1970 CompletionDate = 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; ]

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_q ausgeben lassen.

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

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

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

Condor-G: Globus + Condor Eine Middleware die bei vielen Grid Projekten eingestzt wird Es ermöglich Zugang zu entfernten Rechenressourcen Es ermöglich zuverlässlichen und robusten Datentransfer 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 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).

Condor Globus Universe

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.

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.

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