Abgleich mit der Anforderungsdefinition vom

Transkript

1 Abgleich mit der Anforderungsdefinition vom Neuere Anforderungen sollten abgewartet werden. Anforderungen Zugang/API Submittierung an den Supercomputer geht natürlich GUI haben wir nicht. Stattdessen: CLI. Man könnte ein GUI über das CLI bauen. Des Weiteren gibt es Konfigurationsdateien die man sicherlich auch graphisch darstellen könnte. Dabei wären Radio-Buttons oder Popup-Menus an Stellen denkbar an denen es nur ein bestimmte Wertebereich zulässig ist. Pre-/Postprocessing: Geschieht wenn erwünscht über DAGMan: Damit können wir beliebige "Directed Acyclic Graph"s darstellen und im simplesten Fall einen Pre- oder Postprozessor anschliessen. Zu testen bleibt die bereits verteilt gerenderten Bilder (povray ohne irgendwelche Zusätze) automatisch zu einer Animation zusammenzusetzen. Z.B mit Transcode. () Eine Benachrichtigung via wenn Job fertig ist haben wir schon in der Praxis bekommen. Ressourcen Die Eigenschaften von Ressourcen können Betrachtet und beim Scheduling verwendet werden. Dies ist beispielsweise mit dem Befehl condor_status möglich. Dazu gehören (in Klammern immer die Begriffe aus der Anforderungsdefinition) - OpSys "LINUX" (Betriebssystem) - Arch "INTEL" (CPU-Typ) - Mem "502" - warum nicht 512? (RAM) - LoadAvg "5.630" - ActvtyTime "0+02:15:01" - State "Unclaimed" - Activity "Idle" nicht...(zumindest nicht über condor_status) - Geschwindigkeit - bsp: condor_status -constraint 'Mips>1250' - 2 von 4 rechner bleiben übrig - alle Infos auf einmal mit condor_status -long - an dieser stelle könnte man auch ein Gui andocken MyType = "Machine" TargetType = "Job" Name = "vm2@daphne" Machine = "daphne" Rank = CpuBusy = ((LoadAvg - CondorLoadAvg) >= ) COLLECTOR_HOST_STRING = "pataplan.uni-paderborn.de" CondorVersion = "$CondorVersion: Nov $" CondorPlatform = "$CondorPlatform: INTEL-LINUX-GLIBC22 $" VirtualMachineID = 2 VirtualMemory = Disk = CondorLoadAvg =

2 LoadAvg = KeyboardIdle = 8469 ConsoleIdle = 8469 Memory = 251 Cpus = 1 StartdIpAddr = "< :34958>" Arch = "INTEL" OpSys = "LINUX" UidDomain = "uni-paderborn.de" FileSystemDomain = "uni-paderborn.de" Subnet = " " HasIOProxy = TRUE TotalVirtualMemory = TotalDisk = KFlops = Mips = 1074 LastBenchmark = TotalLoadAvg = TotalCondorLoadAvg = ClockMin = 914 ClockDay = 4 TotalVirtualMachines = 2 HasFileTransfer = TRUE HasMPI = TRUE HasJICLocalConfig = TRUE HasJICLocalStdin = TRUE JavaVendor = "Sun Microsystems Inc." JavaVersion = "1.4.2_02" JavaMFlops = HasJava = TRUE HasRemoteSyscalls = TRUE HasCheckpointing = TRUE StarterAbilityList = "HasFileTransfer,HasMPI,HasJICLocalConfig,HasJICLocalStdin,HasJava,HasRemoteSysc alls,hascheckpointing" CpuBusyTime = 312 CpuIsBusy = TRUE State = "Unclaimed" EnteredCurrentState = Activity = "Idle" EnteredCurrentActivity = Start = TRUE Requirements = START CurrentRank = DaemonStartTime = UpdateSequenceNumber = 1 MyAddress = "< :34958>" LastHeardFrom =

3 Netwerk-Anbindung nicht dabei? Festplattenplatz (siehe oben) Software: - Binaries werden im Normalfall mitgeschickt (verteiltes Dateisystem geht wohl auch aber noch nicht getestet Daten Daten werden mitgeschickt oder remote geöffnet oder stehen im verteilten Dateisystem zur Verfügung. getestet: verteiltes Dateisystem. Paramteter wurden beim Start automatisch angepasst so dass wir einen Job definiert haben und gesagt haben mach das 160 mal. Monitoring: - idle: wird darsgestellt - man kann präzise angeben unter welchen Bedingungen ein Job starten darf und unter welchen Bedingungen er angehalten wird. nicht getestet: Auslastung der CPU gegen Schwellwert. Ist wohl möglich. getestet: Keyboard on idle. Scheduling - getestet: Unterbrechung von Job durch Benutzung des Keyboards hat funktioniert. - nicht getestet: Checkpointing und Migration - nicht getestet: Absturz von Software (ist schwer festzustellen bei Endlosschleife. Kann man feststellen bei unerlaubtem zugriff auf fremde Speicherbereiche) - nicht getestet: Hardware-ausfall eines Knotens :-) Rechte: - nicht getestet weil wir Condor auf den Poolrechnern unter condorad installiert haben aber laut Doku möglich: verschiedenen Benutzern verschiedene Rechte geben, Verwaltung über Gruppen Jobs/tag? Beschränkung der Laufzeit? Konto mit CPU-Zeit? Prioritäten? Local/Remote-zugriff: Local soll beispielsweise bevorzugt werden können die Jobausführung hat eingeschränkte rechte auf dem Knoten (wird bei Condor angeblich als nobody ausgeführt. somit kann man aber immer noch das /tmp vollmüllen) keine root-rechte: Condor braucht root-rechte um die Software unter dem User laufen zu lassen der sie startet. Gibt es nur einen Condor user ist das ganze System nicht sicher vor dem Benutzer, weil potenziell jeder admin ist. oder es läuft alles wenn nicht als condorad als nobody, aber da weis ich noch zu wenig drüber - werden remote system calls benutzt verhält der job sich so als ob er lokal laufen würde. (ist condor als root installiert laufen die jobs andernfalls als nobody) - beenden und neu starten von Condor darf nur der Eigentümer (im Optimalfall root) siehe dazu "redundanz" Redundanz Condor hat eine zentrale Komponente: den central manager. Der besteht aus dem negotiator und dem collector. Beide Komponenten können auf verschiedenen Rechnern laufen und über das Netz miteinander kommunizieren (ist normalerweise nicht der Fall) Fällt der central manager aus so werden keine Jobs mehr verteilt. Weiter passiert nichts. Alle laufenden Jobs laufen weiter. Da auf Dauer der Pool nicht läuft ohne central manager sollte es eine stabile maschine sein und im Notfall neu gestartet werden können von einem Administrator.

4 einzelne Komponenten: Auf jedem Rechner läuft der master deamon dessen Hauptaufgabe es ist alle anderen benötigten Komponenten am Leben zu halten. Falls eine Komponente abstürzt oder sich nicht korrekt verhält wird sie von ihm neu gestartet. Der master an sich könnte noch vom System überwacht werden. ich weis aber nicht ob das normalerweise gemacht wird Administration Das Sperren der Knoten durch admin ist möglich. Dazu kann man entweder dem master auf einem Knoten sagen, er soll gewisse Komponenten neu starten und so eine neue Konfiguration laden, die die Komponenten logisch sperrt oder man kann dem master sagen, er solle alle Komponenten sauber herunterfahren. Laufende Prozesse werden migriert, falls möglich oder neu gescheduled. - man kann jeder Zeit Komponenten (Knoten) entfernen und hinzufügen zum System Benutzerverwaltung: "ich könnte mir vorstellen, dass das geht, wissen tu ich es aber nicht" (Einstellungen von Benutzerrechten, sperren von Benutzern) Konfiguration: CPU Auslastung kann berücksichtigt werden fürs scheduling, keyborad/mouse on idle auch (man gibt an wie lange das der fall sein muss) - sehr präzise angaben durch conors class ads und die mächtigen Ausdrücke Weitere Anmerkungen Condor ganz nett: man kann zwar sagen, dass ein Job 1k Arbeitsspeicher benötigt und so sich eine Ressource schnappen, aber die Ressource kann überprüfen wie viel tatsächlich genutzt wird und entsprechend den Job zwangsräumen Hier die Lösung: PREEMPT = (...) (TARGET.ImageSize > Memory * 1024) gut: certificates für die Kommunikation zwischen den daemons (Stichwort gsi) 3:34 einzeln 214 1:20 bei 4 rechnern 80 Nachteile letzte Woche: Testumgebung festlegen: hw + sw + os eigener user Condor oder root-zugriff auf einigen maschinen Installation mögliche Probleme während der Installation Diese Woche:

5 Mindestanforderungen, vor- und nachteile - Mindestanforderungen - Unterstützte Plattformen (Architektur + OS) - Digital UNIX (Alpha) - HP-UX? - Manual: ja - Website: keine Binaries - Irix 6.5 (SGI) - Linux 2.4 (x86, Itanium, Alpha) - Offiziell wird nur Red Hat unterstützt - Mac OS X (PPC) - NT 4.0, 2000, XP (x86) - Solaris (Sparc) - True64UNIX (PA RISC) - Aufgabenabhaengig central manager Da die Aufgaben für den Pool relativ wichtig sind sollte der Central Manager eine zuverlässige Maschine sein. Falls sie abstürzt werden keine weiteren Jobs mehr verteilt (die alten Jobs laufen aber weiter). Außerdem sollte der Rechner nach Möglichkeit schnell neu gestartet werden können. Da der Central Manager kontinuierlich Updates von allen anderen Pool-Rechnern erhält sollte er eine schnelle Netz-Anbindung haben. Execute-Host Um ein Execute-Host zu sein braucht ein Rechner keine großen Ressourcen. Die einzige Ressource, die er vielleicht brauch ist Festplatten-Platz für den Fall dass ein Job einen Checkpoint anlegt. Dieser wird zunächst lokal gespeichert bevor er zum Submit-Rechner übertragen wird. Im Allgemeinen sind mehr Ressourcen nur von Vorteil. Submit-Host - präzisere Formulierungen gibt es nicht; hauptsächlich ist wohl die Anforderung des auszuführenden Programms entscheidend Nachteile: - dual-cpu - 2 mal single mit 50% ram ist wohl default konfiguration - kein Sourcecode - kein GUI - gewisser Lernaufwand für die Benutzung - dort ggf. ansetzten indem man Condor im Hintergrund administriert und ein vereinfachtes Interface davor baut - noch keine Version für den 2.6er Kernel - wenn redhat 9 kommt Problem - kein Checkpointing/remote system calls von kommerzieller Software - dies verhindert Migration von Prozessen - keine remote system calls bei Windows - file transfer Mechanismus kann nur Dateien bis zu einer Grösse von 2 GB transferieren - es gibt keine Möglichkeit sich den gesamten Status anzusehen von einem Cluster. ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD 18.1 mike 12/8 09: :00:01 R shake 18.2 mike 12/8 09: :00:00 R shake 18.3 mike 12/8 09: :00:00 R shake

6 becomes: ID OWNER SUBMITTED TOTAL_RUN_TIME ST CMPLTE CMD 18.* mike 12/8 08: :41:01 R 52/100 shake 19.* mike 12/8 09: :00:00 I 0/50 maya 20.* mike 12/8 09: :00:00 I 0/600 prman zu beachten: die Software schickt regelmässig Status Infos übers netz an die Entwickler. Das kann man aber disablen: Installieren und berichten: Abgleich mit den anforderungen: