Ursula Winkler Günther Berthold Usermeeting 17. Jänner 2008

Agenda  Uni-Infrastruktur IV  Betriebskonzept  User Support  Sauron Systeme  Accounting  SGE Konfiguration  User Präsentationen  Binäre Datenkompression (Truhetz)  Allfälliges

UniInfrastruktur IV  Der neu anzuschaffende Rechner soll den Bedarf an Hochleistungsrechenkapazitäten an der Naturwissen- schaftlichen Fakultät der Universität Graz decken. Insbesondere steht er für die Arbeitsgruppen zur Verfügung die den Cluster im Rahmen des Programmes Forschungs- infrastruktur IV beantragt haben. Daneben soll es auch möglich sein, etwaigen an der Universität Graz neu gegründeten Gruppen Rechenzeit zur Verfügung zu stellen.  Der neue Rechner wird den zur Zeit laufenden Computer- cluster als Hochleistungsrechner für die Forschung schrittweise abhängig von den infrastrukturellen Gegebenheiten ablösen (Strom, Kühlung, Stellfläche).  Die erst im Sommersemester 2007 in Betrieb genommene Partition “Erwin” sowie die Partition “Kepler” sollen mindestens bis Ende 2010 laufen.

Betriebskonzept (ITIL)

Betriebskonzept (Uni Graz) I  Im Betriebskonzept werden die Details der Inbetriebnahme, des Betriebes und der Evaluation für den Hochleistungs- Rechencluster festgelegt, der im Rahmen des Programms Forschungsinfrastruktur IV angeschafft werden soll (7. Nov. 2007).  Die Verantwortung für den Betrieb des Rechners liegt beim ZID. Zur Koordinierung wird ein Beirat eingerichtet, in dem die Teilprojekte aus dem Infrastrukturantrag repräsentativ vertreten sind.  Es ist geplant in regelmäßigen Abständen (z.B. zwei Mal im Semester) Benutzertreffen abzuhalten.  Die Erteilung von Rechenaccounts für die User der Arbeits- gruppen die am Rechenbetrieb teilnehmen geschieht auf Antrag der Teilprojektleiter. Die Verwaltung der liegt beim ZID.

Betriebskonzept (Uni Graz) II  Der neue Rechencluster soll in zwei Partitionen eingeteilt werden, die die unterschiedliche Ausstattung mit Hardware (lokaler Speicher, Netzwerk) abbilden.  Es ist geplant den Auslastungsgrad des neuen Rechenclusters automatisiert mitzuprotokollieren und geeignet zu dokumentieren.  Die unter Verwendung von Rechenzeit des neuen Clusters erzielten Ergebnisse sollen nach außen hin geeignet dokumentiert werden. Es ist geplant Jahresberichte zu erstellen die kurz den Status der einzelnen Projekte darstellen und die Publikationen des letzten Jahres auflisten.

Agenda  Uni-Infrastruktur IV  Betriebskonzept  User Support  Sauron Systeme  Accounting  SGE Konfiguration  User Präsentationen  Binäre Datenkompression (Truhetz)  Multiple zombieartige Prozesse (Schwinzerl)  Allfälliges

User Support - Systeme Clustersysteme Type CPUMemory /tmpJahr Narya, VilyaHP ES454x Alpha 1250 MHz32, /2004 Sauron (8 Nodes) HP ES 454x Alpha 1250 MHz 4x8 4x /2002 Celeborn (43 Nodes) Intel Xeon2x Intel Xeon340 7/2003 Boltzmann (80 Nodes) Sun Fire V20z2x AMD Opteron 248 2,2GHz4100 7/2005 Kepler (17 Nodes) Sun Fire V20z2x AMD Opteron 248 2,2GHz4100 7/2005 Pregl (48 Nodes) Sun Fire V20z2x AMD Opteron 248 2,2GHz4100 7/2005 Erwin (16 Nodes) Sun X2200 M 22x AMD Opteron DC 2.6 GHz8190 2/2007

Installationen  Sauron  Auflösung des HP-Clusters  Einzelsysteme  Installation Tru64 V5.1B  Entfernung SAN Devices  Cluster-tmp: Neues Storage IP-Namen: sauron1 – sauron8 Zugang: via ssh (uni-intern) Änderungen: - /tmp: 136 GB (bisher 140) - /clu_tmp: 300 GB (bisher 200)

Accounting  Zugangsvoraussetzungen: - gültiger UGO-Account - HPC Projektteilnehmer (Institutsangestellte, Dissertanten, Diplomanden Probleme: uni-fremde Projektteilnehmer Account-Mehrfachnutzung  Geplant: Password-Setzung über UGO

Rechenzeiten  SGE Scheduling: - Hosts/CPU-Zuteilung - Zeit (Rechendauer)  Momentane Konfiguration: - 2 Queues (MPI, Default) mit jeweils allen Hosts + CPUs - keine Zeitlimits - keine Limits der Jobanzahl - keine Prioritäten  Schwierigkeit: - MPI Jobs sind, wenn Wartezeiten auftreten, im Queuing umso mehr benachteiligt, je mehr Ressourcen (# CPUs) sie benötigen

Rechenzeiten - Testruns mit vielen CPUs können damit unmöglich werden  Mögliche Abhilfe: - MPI-Queue mit höherer Priorität ausstatten - Prioritätensetzung in Abhängigkeit von der Laufzeit - generelle Laufzeitlimits für Jobs (z.B. 2 d) - Queue f. Single-Prozessor Jobs (Default-Queue) auf eine bestimmte Anzahl von Knoten beschränken, z.B. b01 – b40 - Beschränkung der Jobanzahl/User - „Advance Reservation“ v. MPI-Jobs i. d. Warteschlange

 Im Meeting folgende Übereinkunft getroffen ( ): KeplerPreglErwinBoltzmann Priority-QueueNein Ja (mpi) # Nodes pro Queue Alle default: 31 mpi…: 48 Einführung Testqueue Nein Ja Laufzeitlimits (pro Queue) Nein default: 7 Tage mpi: 3 Tage Fastmpi: 30 Min

Agenda  Uni-Infrastruktur IV  Betriebskonzept  User Support  Sauron Systeme  Accounting  Rechenzeiten  User Präsentationen  Binäre Datenkompression (Truhetz)Allfälliges

Userpräsentationen  Binäre Datenkompression (Truhetz)

Allfälliges  Erwin: SGE Upgrade auf 6.1  Ausgeschiedene Altsysteme: - SGI Origin 200 (Peregrin): Memory-Defekt - HP rx4640 Itanium Systeme (Beren, Dior, Elros, Elwe, Grimli): Mietvertrag ausgelaufen

Agenda  Uni-Infrastruktur IV  Betriebskonzept  User Support  Sauron Systeme  Accounting  SGE-Konfiguration  User Präsentationen  Binäre Datenkompression (Truhetz)  Allfälliges