Grid-Technologien im Rechenzentrum Das Condor-System

Präsentation zum Thema: "Grid-Technologien im Rechenzentrum Das Condor-System"—  Präsentation transkript:

1 Grid-Technologien im Rechenzentrum Das Condor-System
Horst Wenske Rechenzentrum Universität Karlsruhe (TH)

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 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 Das Condor Daemon Layout
Personal Condor / Central Manager Master negotiator startd schedd collector

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. IRIX SGI Unclaimed Idle :00:04 antipholus.cs LINUX INTEL Unclaimed Idle :28:42 coral.cs.wisc LINUX INTEL Claimed Busy :27:21 doc.cs.wisc.e LINUX INTEL Unclaimed Idle :20:04 dsonokwa.cs.w LINUX INTEL Claimed Busy :01:45 ferdinand.cs. LINUX INTEL Claimed Suspended :00:55 LINUX INTEL Unclaimed Idle :03:28 LINUX INTEL Unclaimed Idle :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 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

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_submit Befehl 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 = // current time KeyboardIdle = 1432; // seconds Disk = ; // kbytes Memory = 64; // megabytes State = "Unclaimed"; LoadAvg = ; 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 = ; // Submit time secs. past 1/1/1970 CompletionDate = 0; Owner = "raman"; Cmd = "run_sim"; WantRemoteSyscalls = 1; WantCheckpoint = 1; Iwd = "/usr/foo/foo1"; Args = "-Q "; Memory = 31; Rank = KFlops/1E3 + other.Memory/32; Constraint = other.Type == "Machine" && other.Arch == "INTEL„ && other.OpSys == "SOLARIS251„ && other.Disk >= && 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_q ausgeben 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 : < :1027> : ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD frieda /16 06: :00:00 I 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 s 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 ( ) 05/25 19:10:03 Job submitted from host: < :1816> ... 001 ( ) 05/25 19:12:17 Job executing on host: < :1026> 005 ( ) 05/25 19:13:06 Job terminated. (1) Normal termination (return value 0) Usr 0 00:00:37, Sys 0 00:00: Run Remote Usage Usr 0 00:00:00, Sys 0 00:00: Run Local Usage Usr 0 00:00:37, Sys 0 00:00: Total Remote Usage Usr 0 00:00:00, Sys 0 00:00: Total Local Usage Run Bytes Sent By Job Run Bytes Received By Job Total Bytes Sent By Job Total Bytes Received By Job

26 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

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