Ursula Winkler

Günther BertholdUsermeeting 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   CPU Memory   /tmp Jahr

Narya, Vilya HP ES45 4x Alpha 1250 MHz 32,16 350 12/2004

Sauron (8 Nodes)

HP ES 45 4x Alpha 1250 MHz4x8 4x16

140 12/2002

Celeborn (43 Nodes)

Intel Xeon 2x Intel Xeon 3 40 7/2003

Boltzmann (80 Nodes)

Sun Fire V20z 2x AMD Opteron 248 2,2GHz 4 100 7/2005

Kepler (17 Nodes)

Sun Fire V20z 2x AMD Opteron 248 2,2GHz 4 100 7/2005

Pregl (48 Nodes)

Sun Fire V20z 2x AMD Opteron 248 2,2GHz 4 100 7/2005

Erwin (16 Nodes)

Sun  X2200 M 2 2x AMD Opteron DC 2.6 GHz 8 190 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 (17.1.2008):

Kepler Pregl Erwin Boltzmann

Priority-Queue Nein Nein Nein Ja (mpi)

# Nodes

pro QueueAlle Alle Alle

default: 31 mpi…: 48

Einführung Testqueue

Nein Nein Nein Ja

Laufzeitlimits (pro Queue)

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

< Userbeitrag >

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