Impressum

You are here: SE » TeachingHome » SoftwareprojektClusterManagement2018 » SoftwareprojektClusterManagement2018Docu

SoftwareprojektClusterManagement2018Docu

09 Aug 2023 - 17:03 | Version 13 | UnknownUser

Bedienungsanleitung

Mit dem Cluster verbinden

Verbindung zu beiden Gateways geht nur über das FU-Netz. Somit muss der eigene Key entweder auf andorra hinterlegt werden oder ProxyJump (ssh -J) genutzt werden (ohne <>):

ssh -J <Nutzername>@andorra.imp.fu-berlin.de <Nutzername2>@<server>.imp.fu-berlin.de

Dabei steht "server" für das Zielgateway (s.u.), für den LDAP-Namen auf andorra und für den entsprechenden Account auf dem Server.

Lethe
- Zugriff für Admins (linnert, koenigl, lwalter, tareb98, abrahas55) mit ssh-key
Styx
- Zugriff für Admins (s.o.) und Nutzer (gruppe3) mit ssh-key

Nutzer in NIS anlegen

Um neue Nutzer anzulegen werden diese auf dem Solaris erstellt (s. https://docs.oracle.com/cd/E18752_01/html/816-4556/anis2-38485.html|Administering NIS Users). Hierzu wird erst ein Benutzer angelegt und sein Home-Directory auf dem NFS-Mount erstellt. Da aber das Home-Directory nicht auf /export liegen soll (sondern nur dort erstellt), sondern unter /home, dorthin jedoch vom automounter bzw. NFS gemappt wird, muss danach noch mit usermod das Verzeichnis verändert werden.

# useradd -md /export/home/<username> <username>
# usermod -d /home/<username> <username>

Anm.: Mit -G <additional,groups> kann der Nutzer gleich weiteren Gruppen hinzugefügt werden.

Die generierten Zeilen in /etc/passwd und /etc/shadow werden dann in die NIS Quell-Dateien überpflegt

# grep ^<username>: /etc/passwd >> /var/yp/passwd=
# grep ^<username>: /etc/shadow >> /var/yp/shadow=

Danach werden die Nutzer auf dem regulären System außerhalb des NIS wieder gelöscht. # userdel

Nun wird die NIS-Datenbank nun aus den modifizierten Quelldateien generiert:

# cd /var/yp
# /usr/ccs/bin/make passwd

Dokumentation

Aufbau

Cluster	Open CCS
virtuelle Nodes (LDoms)	Debian
Nodes	Solaris 10
Hardware	T5120,T5240 (←GW)

Aufbau

4-6 Ldoms pro Maschine, 4-6 Maschinen

T5120er und T5240 (←Gateway):

Oracle's Sun SPARC Enterprise T5140/T5240servers extend this scalability by adding dual sockets for UltraSPARC T2 Plus processors and considerably large memory support. Oracle's Sun SPARC Enterprise T5120 server supports a single UltraSPARC T2 processor whereas Oracle's Sun SPARC Enterprise T5140 supports two UltraSPARC T2 Plus processors.

Performancecounter (LK, BL)

Linux stellt das perf-Syscallinterface (perf_event_open(2)) bereit, sowie die Konsolenschnittstelle perf(1).
SPARC LDoms reichen diese nahtlos an den Guest-Kernel weiter
Jedoch ist dieses aus Sicherheitsgründen per-default nur eingeschränkt nutzbar. Zum Entfernen der Einschränkungen:

sysctl -w kernel.perf_event_paranoid=-1

Darauf aufbauend gibt es die API libpfm4, welche den z.T. numerischen IDs der Performance-Counter sprechende Namen zuweist, um perf_even_open(2) -API einfacher zugänglich zu machen.
perf und pfm4 unterstützen die SPARC T2 "Niagara" Architektur.
Wiederum darauf aufbauend gibt es die Platformunabhängige PAPI, welche versucht eine generelle Schnittstelle für Performance-Counter bereitzustellen und die systemspezifischen Teile wegzuabstrahieren. Auf aktuellen Linux-Kerneln wird als Backend perf/pfm4 genutzt.
- PAPI selber unterstüzt keine 64-bit SPARC-Architekturen, jedoch reicht es 3 Zeilen hinzuzufügen, um den Support zu implementieren, der Rest wird von perf erledigt (TODO: Patch dokumentieren).
- Zusätzlich ist das perf-Backend von PAPI unvollständig und findet zwar Performance-Counter, weigert die sich aber wegen fehlerhaften Codes (bzw. harcodeten-Checks die auf Kerneln >2.6.x immer fehlschlagen dürften) diese zu benutzen. Auch hier ist ein kleiner Patch/Workaround notwendig (TODO: Patch dokumentieren)
Wichtig: libpfm4 ist aus dem perfmon-Projekt entstanden, welches in Zeiten von Linux 2.6.x einen out-of-tree patch (perf_ctr) bereitgestellt hat um dem Kernel ein einheitliches Performance-Counter Subsystem hinzuzufügen. Dieses wurde jedoch verworfen, geblieben ist die Userspace-API, welche seit libpfm4 nicht mehr auf perfmon2/perf_ctr sondern auf perf aufbaut. perf hat hier auch die anderen APIs wie OProfile oder VTune weitestgehend abgelöst

Solaris auf Gateway direkt ans Fachbereichsnetz: BL

Installserver: Admins

Aktuell werden die Debian-Compute-Nodes manuell installiert, ein Squid-Server auf lethe wird benutzt um Systemaktualisierungen ins interne Netz zu holen.

Kernel lokal: Admins

Die Boot-Partition unter /boot enthält den Kernel vmlinuz und das initial ram filesystem initrd.img. Beides sind Symlinks auf den jeweiligen aktuellen Kernel. Es gibt keinen Bootloader wie GRUB, eine Auswahl des Bootsystems passiert über OpenBoot und dessen ok-promt über das ldom interface.

Ldoms+Solaris: LW

Nutzerverwaltung: auf Solaris Gateway YP/NIS "clusterdomain"

Der NIS Server sollte auf der gleichen Node laufen, wie das NFS, da NFS für die homes zuständig ist und NIS für die Nutzerverwaltung.

Auf lethe wurde der NIS Master Server eingerichtet (s. https://docs.oracle.com/cd/E18752_01/html/816-4556/cnis1-21774.html|Preparing the Master Server). Die über NIS administrierten Dateien liegen in DIR=/var/yp/sources und die Passwd Dateien in PWDDIR=/var/yp. Dazu wurden wie in der obigen Anleitung alle entsprechenden Dateien von /etc/ nach /var/yp/sources migriert bzw. dort angelegt, sowie /var/yp/Makefile modifiziert.

Nun muss mit die NIS Domäne gesetzt werden.

# domainname clusterdomain

Danach kann das entsprechende Verzeichnes aus den Quelldateien generiert werden:

# /usr/sbin/ypinit -m

Um tatsächlich auch den Nameserver zu benutzen wurde die NIS-Default NS-Switch Konfiguration benutzt und danach der Dienst aktiviert:

# cp /etc/nsswitch.nis /etc/nsswitch.conf
# svcadm enable network/nis/server:default

Auf dem Debian-Image wurde der Client eingerichtet, indem zuerst das Paket nis installiert und bei der Interaktiven Konfiguration die entsprechende Domäne angegeben wurde. Danach wurde in der YP-Konfiguration der NIS-Server eingetragen:

# echo "ypserver 10..." >> /etc/yp.conf

In der Datei /etc/nsswitch.conf können die Dienste konfiguriert werden, die über NIS bezogen werden sollen, indem bei den Einträgen passwd, group, shadow und hosts das Feld nis hinten ergänzt wird. Abschließend werden die betroffenen Dienste neugestartet.

# systemctl restart rpcbind nis

Schnittstelle an- und abschalten LDoms: Admins

Home-Verzeichnisse via NFS Automount

Die Home-Verzeichnisse liegen auf lethe unter /export/home und sollen auf den Debian-Systemen via NFS bereitgestellt werden. Dies geschieht via Automounter on-demand, d.h. erst dann, wenn der entsprechende Nutzer sich einloggt. Auf den Debian-Images sind hierzu die Pakete autofs und nfs-common notwendig.

Das Verzeichnis /home soll durch die Konfigurationsdatei /etc/auto.home gesteuert werden, dies spezifizieren wiederum in /etc/auto.master wiefolgt:

/home auto.home -nobrowse

Nun wird in /etc/auto.home konfiguriert wie diese im speziellen gemountet werden sollen. Wir spezifizieren NFSv4 und den NFS-Server:

* -v4,defaults 10.11.103.10:/export/home/&

Die Lesart ist die folgende: Der * matcht jede beliebige Anfrage (bspw. Nutzer koenigl) und das & enthält nun diesen match und spezifiziert also, dass das entsprechende Verzeichnis auf dem angegebenen Server unter /export/home/koenigl zu finden ist.

Noch ausstehend:

Uhrzeit bei allen virtuellen Maschienen gleich
Fortran Compiler
openCCS konfigurieren * /home wird vom node verwendet, muss dieser persistent sein? * in NFS?

Open CCS (TB)

Dependencies

PCP wurde auf 3.10.9 gedowngradet. Das ist die neuste Version, welche nicht auf libdbd-mysql-perl basiert, da diese auf sparc64 nicht die nötigen Dependencies besitzt.
Flex wurde auf 2.5.39-8 gedowngradet. Mit 2.6.0 gab es Änderungen an den yyin und yyout Variablen, wodurch der Open CCS Tokenizer flexer.l nicht mehr richtig funktioniert.

Configure

./configure wurde mit folgenden Optionen aufgerufen:

-enable-ccs-account=ccs:CCS
-enable-develop-mode
-enable-thread-support (ohne diese Option kompiliert eine für das gesamte Build notwendige Bibliothek nicht)

Build

Die Standard Open CCS Source (Stand Revision 1168) ist nicht einfach buildable, da vieles komplett broken ist. Welche Dateien genau geändert wurden, kann dem SVN Repository (/home/ccs/openccs) entnommen werden. Folgende Änderungen wurden vorgenommen:

LINUXSPARC64 wurde als Architektur hinzugefügt. Dies ist allerdings nur ein lazy Port: Überall wo im Source Code die Architektur LINUX64 referenziert wird, wurde dieser um LINUXSPARC64 erweitert.
Fehlende '' bei der configure.ac Variable CIS_INC führt dazu, dass cis/ falsch gelinkt wird. Dies wurde behoben.
In einigen Ordnern wurden die Automake Dependencies in Makefile.am geändert oder neu hinzugefügt, da sonst einige Bibliotheken nicht in der richtigen Reinfolge gebaut werden.
Im shared/rsd/parser.y Script wurde ein Syntaxfehler behoben.
Beim Bauen wird die Datei shared/evt/evt_com_xdr.c von rpcgen mit einem Syntaxfehler generiert, dieser muss manuell behoben werden.
Im util/ccs_postinstall Script wird eine Datei referenziert, die in keinster Weise im aktuellen Build existiert, daher musste das Script angepasst werden.