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