quantum (quantum.nat.uni-magdeburg.de)

Frontansicht des Clusters

Aktuelles:

  • 10.12.14-22.12.14 - System wird neu installiert, SL7
  • ToDo: - AFS (?), Jobpriorisierung

Allgemeines

Quantum.nat ist ein Compute-Cluster der theoretischen Physik (AG Prof. Jan Wiersig) beschafft im September 2008. Er besteht aus 30 PowerEdge 1950 Servern die mit 1Gbit Ethernet vernetzt sind. Zugang besteht ueber ssh mit PublicKey fuer die Arbeitsgruppen der Theoretischen Physik (ITP) und deren Gaeste. Jobs der Arbeitsgruppe Wiersig werden priorisiert, d.h. andere Jobs werden ggf. abgebrochen und "resubmitted" (in Arbeit). Die Administration erfolgt ueber das URZ (Dr. Joerg Schulenburg URZ-S Tel. 58408 oder vertretungsweise von Dr. Gerald Kasner ITP Tel. 12469). Fragen zum Cluster und Aenderungswuensche, diese Webseite betreffend, richten Sie bitte an Joerg Schulenburg. 2014-12 wurde das System von CentOS5 und OpenPBS auf SL7 und Slurm umgebaut.

Quickstart


   ssh -X quantum.nat.uni-magdeburg.de   # login to master via ssh-key


   sinfo  # get cluster health info
   squeue # get job queue info
   
   module avail    # show available software modules
   module list     # show loaded software modules (default: mpi/openmpi-x86_64)
   
   module load mpi/openmpi-x86_64  # laeded by default (not needed)
   mpicc -O3 -o mpiprog mpiprog.c  # compile mpi program

   qsub jobscript                  # send job to the jobsystem

   jobscript:
     #!/bin/sh
     # 3*6 tasks on 3 nodes 800MB/node shared nodes
     #SBATCH --nodes=2
     #SBATCH --ntasks-per-node=6
     #SBATCH --mem=800
     #SBATCH --time 48:00:00
     # -share erlaubt anderen Jobs, Knoten zu teilen (vs. --exclusive)
     #SBATCH --share
     module load mpi/openmpi-x86_64   # see "module av" for available modules
     mpiexec --bind-to-core ./mpiprog
   
   sbatch jobscript         # send job to queue, output to slurm-$JobID.out
   sbatch -N2 -n4 jobscript # start 4 tasks on 2 nodes (2 per node)
   squeue -l                # Jobliste anzeigen
   scancel JOBNUMMER        # Job loeschen
                         
   # please adapt the CPU needs to your memory needs (CPUs=memory/4GB)
   # if you dont need much memory, let a minimum of one CPU per node free for
   #   those users, which need a lot of memory (for example ppn=7)
   #   for maximum overall efficiency of the cluster, thanks
   # contact Joerg Schulenburg Tel. 58408 for help

Hardware:

 - 240 cores, 2.9TFLOP, 960GB memory, 13TB scratch disk, 2*30Gbit/s network
 - overview:
   - 30 nodes: Dell PowerEdge 1950 (240..300W 3GHz, 235..270W 2GHz 1HE)
     CPUs= 2*Quad-Xeon E5450 3GHz L1=2*32kB(1ns,15GB/s) L2=2x6MB 1333FSB TDP=80W
     Memory= 32GB 667MHz FBD (8x4GB dual rank DIMMs, Intel 5000X Chipset)
             benchmarks: 30*8random=8GB/s,238ns(1GB) 30*8stream=185GB/s
     Storage=  2*250GB 7k2rpm 3.5inch SATA HD RAID striped (r=158MB/s)
     Network=  2*1GbE
   - master:
     CPU=Quad-Xeon E5405-2.00GHz Memory=8GB disk=6*1TB 7k2-SATA 220W
   - UPS for master node (1kW)
 - Storage:
   13TB scratch-disk (summed bandwith = 4.5GB/s)
     30 * 424GB at node0xx:/scratch (w=110MB/s r=158MB/s ext3r=154MB/s)
   5TB (5+1)RAID5 on master via PERC 6/i PCIx8 SAS RAID 256MB 300MB/s
     sda=1.8TB r=277MB/s sdb=1.8TB sdc=1.2TB
     1.7TB home space on master:/home (via GbE-NFS w=88..91MB/s r=51MB/s)
     2.8TB work space on master:/tmp1 (ext3 w=185MB/s r=263MB/s)
 - Network:
     eth0: 1GE 192.168.42.0/24 ssh,NFS  192.168.44.0/24 ipmi
     eth1: 1GE 192.168.43.0/24 mpich2   theor.peak=30*100MB/s=3GB/s
     MPI_Sendrecv: (30: 30*60MB/s(32KB), 45us, 30*8: 1400MB/s 118us)

Administration

 Logfiles:
  - /var/torque/server_logs/YYYYMMDD
  - /var/log/messages

History + ChangeLog:

 11.09.08 - Lieferung 72 Kartons
 22.09.08 - zweite Nachfrage wann Aufbau
 01.10.08 - Systemconfig abgefragt (Sonderwunsch CentOS wird erfuellt)
 06.10.08 - Server Aufbau HW
 17.10.08 - Installation (5 Wochen!)
 xx.10.08 - Instabilitaeten IPMI+COM1 umgangen. Cluster einsatzbereit.
            MPI-Bug getriggert, fix durch par-tec
 04.11.08 - crash aller nodes durch urandom-test
 14.11.08 - node003 hanging because of Out-Of-Memory
 16.12.08 - stabil mit BIOS.ext.ser.com=COM2 (workaround)  (nach 2Monaten!)
 16.12.08 - node006 SAS-Controller defekt (Austausch)
 25.01.09 - node006 disk controller ausgefallen (?)
 14.03.09 - node006 wieder defekt?
 28.07.09 - 11:00 13min Stromausfall
 31.08.09 - node017-node020 down, External Serial Connector war COM1
 11.03.10 - Bioseinstellungen verbessert (fix IPMI/serial_console/IRQ3 problem)
            node006 reconfiguriert
 15.07.10 - Teilabschaltung node01-28 wegen Klimaarbeiten
 06.08.10 - Absturz Node011, ExtSerCon war noch auf COM1 gestellt
 14.09.10 - node005 hanging because of Out-Of-Memory, bad OOM-kills
 10.05.11 - 22:00 Shutdown wegen Klimaausfall, ab 30.05. Sparbetrieb wegen Klimareparatur
 01.06.11 - shutdown wegen Klimaausfall
 03.06.11 - Knoten physisch abgeschaltet, da Netzteile immernoch heiss
 14.06.11 - Klima-Teilbetrieb, Knoten eingeschaltet
 04.07.11 - mpich2 aus EPEL installiert
 08.07.11 - Status: 5 blaue Anzeige LEDs defekt (17%), 2 Nodes mit ECC-Warnung
 18.10.11 - set parastation.psd.rl_core=0 (writing no mpi-core-files,
            parallel writing of big core-files caused excessive nfs load)
 08.12.11 - Abschaltung der Knoten wegen Klima-Reparatur
 14.12.11 - epel-mpich2 auf Knoten installiert (PATH-konflikte)
 16.12.11 - install/update openmpi, wrapperscripte ergaenzt
 20.04.12 - Bios-Update n001-030 2.3.1 zu 2.7.0 (fix sporadische DIMM-Error-Meldungen!?)
          - korrigierbare ECC-Fehler node026 (wandert mit DIMM slot7 zu slot8)
          - memtest86+-4.20 fehlerfrei
 04.05.12 - Austausch defektes Memorymodul node026
 05.05.12 - Ausfall 670W-Netzteil node024
 09.07.12 - Netzteil node024 getauscht (+defektes rueckgesendet)
 18.07.12 - Stromausfall (eine Phase, node1-8,25-30,master)
 25.07.12 - Stromausfall (2 Phasen, Last umverteilt, Messung Stromzange 4*8A=7kW)
            Teilabschaltung bis Upgrade Hauptsicherungen 63 zu 100A
 29.10.12 - Austausch Hauptsicherung 63A zu 100A, alle Knoten hochgefahren
 20.01.13 - probleme durch volles /var, nach "yum clean all" wieder ok
 26.04.13 - Ausfall node006.MegaRAID am 21.04. 22:11, reset (Jobs hingen in Queue)
 26.08.13 15:41-15:53 uniweiter Stromausfall + Netzwerkstoerung, Nodes off/on
 04.09.14 - reboot master, USV resettet (reset error)
 09.09.14 - node023 system+ipmi hanging, IERR CPU1, hard off/on
            node030 Ausfall 4GB-DIMM7 + reboot ((8-2)*4GB=24GB)
 18.12.14 - Neuinstallation Scientific Linux 7 + Jobmanager Slurm 14.11
 18.12.14 - neuer kernel 3.10.0 (leider ohne blcr support)
 01.06.15 - Ausfall Dell-GbSwitch 1 (48port 1Gb), Kabel auf Switch 2 gewechselt
 30.07.15 - Sicherung F39 ausgeloest (eine Phase), Master + Node22(?)-30 off
 13.08.15 - reboot master (Ursache unklar), slurmctld startet nicht
            autostart problem slurmctld am 21.08.15 behoben (see 07.04.16)
 21.08.15 - def. 4GB DIMMs node01 nach node30 getauscht
            node01: wieder OK (32GB)
            node30: sockel dimm7 defekt und dimm8 defekt = 32GB-2*4GB = 24GB
 24.08.15 - reboot master (Ursache unklar, Gewitter?), nfs-server startet nicht
 27.08.15 14:00 reboot master (Ursache unklar), nfs-server startet nicht
            soft-reboot ok, nfs-problem behoben?
 14.01.16 14:00 reboot master (Ursache unklar), nfs-server startet nicht
 11.02.16 13:58 reboot master (Ursache unklar), monitoring+alarm reboots
 25.02.16 14:00 reboot master (14d-USV-selftest?), Jobs laufen nach 2min weiter
 10.03.16 13:55 reboot master (14d-USV-selftest!), Jobs OK
 24.03.16 13:46 reboot master, Jobs OK, set cluster to DRAIN
 07.04.16 7y-bad-USV-APC +14d-selftest caused reboots, USV removed
 17.02.17 reconfigure slurm to avoid swap-use by bad cgroup-config

Probleme

Bei der Installation im Oktober 2008 traten folgende Probleme auf: Die mpich-Bibliothek hatte einen Bug (Deadlock wurde von ParTec behoben) und das System ist vermutlich in Folge eines Firmwarebugs im BMC zur Fernsteuerung ueber IPMI im Zusammenspiel mit einem Bug im seriellen Treiber des Linuxkernels instabil, d.h. es stuerzte bei starker Belastung nach gewisser Zeit mit mit Kernel Oops ab (Kernel Panic mit uart_put_char+0x42/0x64 oder _stext+0x7ffff000/0x1000, oder serial8250: too much work for irq3). Letzteres Problem liess sich durch Umkonfigurierung des "Externel Serial Connectors" von COM1 auf COM2 im BIOS oder deaktivieren von agetty fuer ttyS1 umgehen. 

 typische Fehlerlogs:
  init Id "co" respawning too fast: disabled for 5 minutes
  login: FAILED LOGIN 3 FROM (null) FOR , User not known to the underlying  ...
  pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=ttyS1 ruser= rhost=
  
 Funktionierende Einstellung (Work Around):
  Serial Communication ....... On with Console Redirection via COM2             
  External Serial Connector .. COM2
  Failsafe Baud Rate ......... 57600                                            
  Remote Terminal Type ....... VT100/VT220                                      
  Redirection After Boot ..... Enabled
2014-12 bei der Neukonfigurierung faellt auf, dass immernoch gelegentlich Zeichen via IPMI verloren gehen. Selbst bei niedrigster Uebertragungsrate von 9600bd verschluckt sich die IPMI-Console schon im BIOS und muss neu gestartet werden. 

 Out-of-Memory-Probleme (OOM), kernel-2.6.18 haengt u.U.:
  Workarround (tested +buffer+cache+/dev/shm) for rc.local Jul2011:
    echo 100 > /proc/sys/vm/overcommit_ratio   # full memory can be used
    echo 2   > /proc/sys/vm/overcommit_memory  # no overcommit memory!

 - blaue LEDs nach 3 Jahren dauerleuchten nur noch 0-20% Helligkeit, 
   7 von 60 Totalausfaelle (60 gruene LEDs ohne merkbare Probleme)

Weitere HPC-Systeme:

SC072-PDS asgard, GbE Cluster mit 30 Dual-QuadXeon quantum, SC5832 kautz, ISUT-Cluster comp2_mb