High Performance Computing on Gentoo Linux

1.Introduzione

Gentoo Linux è una speciale distribuzione di Linux che può essere facilmente ottimizzata e personalizzata per qualsiasi applicazione o necessità. L'estrema velocità, la grande configurabilità e l'ottima collaborazione fra gli sviluppatori e gli utenti sono i grandi punti di forza di Gentoo.

Grazie a portage, Gentoo Linux può diventare un server sicuro, una workstation per lo sviluppo, una postazione desktop professionale, una piattaforma di gioco, un sistema embedded o - come spiega questa guida - un sistema di computing ad alta performance. Le varie personalizzazioni di Gentoo Linux sono quasi infinite, perciò il sistema viene anche definito una metadistribuzione.

Questa guida spiega come installare un sistema basato su Gentoo in un sistema di computing ad alta performance. Passo dopo passo spiega quali pacchetti sono necessari e come configurarli correttamente.

Se non sei ancora in possesso di Gentoo Linux puoi procurartene una copia dal sito web http://www.gentoo.org e puoi aiutarti durante l'installazione con la documentazione.

2.Configurazione di Gentoo Linux per un Cluster

Ottimizzazîoni raccomandate 

Durante l'installazione di Gentoo bisogna attivare alcune variabili USE in /etc/make.conf. Noi raccomandiamo di disattivare tutte le variabili predefinite (confronta /etc/make.profile/make.defaults) mettendo un segno meno in /etc/make.conf. Malgrado questo potreste avere bisogno di attivare USE variabili come x86, 3dnow, gpm, mmx, sse, ncurses, pam e tcpd. Per maggiori informazioni vi consigliamo perciò la documentazione sulle USE flags.

# Copyright 2000-2003 Daniel Robbins, Gentoo Technologies, Inc.
# Contains local system settings for Portage system

# Please review 'man make.conf' for more information.

USE="-oss 3dnow -apm -arts -avi -berkdb -crypt -cups -encode -gdbm
-gif gpm -gtk -imlib -java -jpeg -kde -gnome -libg++ -libwww -mikmod
mmx -motif -mpeg ncurses -nls -oggvorbis -opengl pam -pdflib -png
-python -qt -qtmt -quicktime -readline -sdl -slang -spell -ssl
-svga tcpd -truetype -X -xml2 -xmms -xv -zlib"

o più semplicemente

# Copyright 2000-2003 Daniel Robbins, Gentoo Technologies, Inc.
# Contains local system settings for Portage system

# Please review 'man make.conf' for more information.

USE="-* 3dnow gpm mmx ncurses pam sse tcpd"

Nelle sezioni 7 e 9 (Configurazione del Kernel e Installazione degli strumenti di sistema) per ragioni di stabilità raccomandiamo l'installazione di vanilla-sources, la versione ufficiale del kernel (quella di http://www.kernel.org/), anche se necessitate di feautures speciali, come xfs.

# emerge -p syslog-ng vanilla-sources

Quando in seguito installerete altri pacchetti vi consigliamo di emergere pure questi:

# emerge -p nfs-utils portmap tcpdump ssmtp iptables xinetd

Communication Layer (TCP/IP Network) 

Un cluster necessita di un communication layer ("strato per le comunicazione") per connettere i nodi principali ai nodi secondari. Normalmente delle schede di rete come FastEthernet o GigaEthernet hanno un buon rapporto qualità/prezzo. Un'altra possibilità è l'uso di prodotti come Myrinet, QsNet o altri ancora.

Un cluster è composto da due tipi di nodi: master (primari) o slave (secondari). Normalmente da un solo nodo master e da molti nodi slaves.

Il nodo master è il server del cluster e il suo compito è di coordinare i nodi slaves dicendogli che cosa fare. Normalmente ha quindi dei demoni come dhcpd, nfs, pbs server, e pbs-sched. Il nodo master deve quindi garantire sessioni interattive e accettare esecuzioni di processi.

I nodi slaves invece attendono di ricevere istruzioni (ad esempio via ssh/rsh) dal nodo master. Il loro unico compito è di elaborare le istruzioni ricevute, quindi non dovrebbero avere installati servizi inutili.

Ogni nodo dovrebbe avere nel file host (/etc/hosts) gli indirizzi di tutti i nodi del cluster.

# Adelie Linux Research & Development Center
# /etc/hosts

127.0.0.1	localhost

192.168.1.100	master.adelie master

192.168.1.1	node01.adelie node01
192.168.1.2	node02.adelie node02

Per configurare la LAN dedicata del vostro cluster editate il file /etc/conf.d/net del server.

# Copyright 1999-2002 Gentoo Technologies, Inc.
# Distributed under the terms of the GNU General Public License, v2 or later

# Global config file for net.* rc-scripts

# This is basically the ifconfig argument without the ifconfig $iface
#

iface_eth0="192.168.1.100 broadcast 192.168.1.255 netmask 255.255.255.0"
# Network Connection to the outside world using dhcp -- configure as required for you network
iface_eth1="dhcp"

Infine configurate il demone DHCP del vostro server, in maniera da poter evitare di dover mantenere manualmente la configurazione della rete su ogni nodo slave.

# Adelie Linux Research & Development Center
# /etc/dhcp/dhcpd.conf

log-facility local7;
ddns-update-style none;
use-host-decl-names on;

subnet 192.168.1.0 netmask 255.255.255.0 {
        option domain-name "adelie";
        range 192.168.1.10 192.168.1.99;
        option routers 192.168.1.100;

        host node01.adelie {
		# MAC address of network card on node 01
                hardware ethernet 00:07:e9:0f:e2:d4;
                fixed-address 192.168.1.1;
        }
        host node02.adelie {
		# MAC address of network card on node 02
                hardware ethernet 00:07:e9:0f:e2:6b;
                fixed-address 192.168.1.2;
        }
}

NFS/NIS 

Il Network File System (NFS) è stato sviluppato per permettere a delle macchine di montare una partizione del disco su una macchina in rete, come se fosse realmente un suo disco. Ciò permette quindi di condividere velocemente e simultaneamente dei files nella rete.

Ci sono anche altri sistemi che hanno funzionalità simili a NFS e che possono essere usati in un cluster. Il File System Andrew dell' IBM, recentemente rilasciato open-source, ha un meccanismo di file-sharing con alcuni miglioramenti per la sicurezza e le prestazioni. Il File System Coda è ancora in fase di sviluppo, ma è stato progettato per lavorare ottimamente con clients disconnessi. Molte delle feautures del file system Coda saranno probabilmente introdotte nella prossima release di NFS (Version 4). Attualmente NFS ha i vantaggi di essere maturo, standardizzato, molto conosciuto e supportato molto bene da diverse piattaforme.

# emerge -p nfs-utils portmap
# emerge nfs-utils portmap

Configura e installa un kernel che supporti NFS v3 in tutti i nodi:

CONFIG_NFS_FS=y
CONFIG_NFSD=y
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
CONFIG_NFSD_V3=y
CONFIG_LOCKD_V4=y

Nel server modifica il file /etc/hosts.allow per accettare le connessioni dai nodi slaves. Se la LAN del tuo cluster è su 192.168.1.0/24 il file hosts.allow dovrebbe essere simile a questo:

portmap:192.168.1.0/255.255.255.0

Modifica il file /etc/exports del server per esportare una directory di lavoro (/home va molto bene in questo caso).

/home/	*(rw)

Aggiungi nfs al runlevel come default sul server:

# rc-update add nfs default

Per montare sui nodi slaves il filesystem nfs del nodo master dovete modificare il file /etc/fstab dei vostri nodi slaves. Dovete quindi aggiungere una linea simile a questa:

master:/home/	/home	nfs	rw,exec,noauto,nouser,async	0 0

Dovete anche fare in modo che i nodi slaves montino il filesystem ntfs:

# rc-update add nfsmount default

RSH/SSH 

SSH è un protocollo per effettuare login remoti e altre operazioni in una rete insicura, ma maniera sicura. Infatti OpenSSH usa la crittografia a chiave pubblica per garantire un'autenticazione e una comunicazione sicura. Prima di configurare ssh bisogna generare una chiave pubblica, che sarà poi condivisa con il sistema remoto, e una chiave privata che sarà conosciuta solo dal sistema locale.

Per un uso pulito di ssh devono essere usate le chiavi pubbliche/private. Ciò va fatto con due passaggi:

• Generare la chiave pubblica e quella privata
• Copiare la chiave pubblica su tutti i nodi slaves

Per un'autenticazione basata sugli utenti, bisogna eseguire qualcosa del genere:

# ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa): /root/.ssh/id_dsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_dsa.
Your public key has been saved in /root/.ssh/id_dsa.pub.
The key fingerprint is:
f1:45:15:40:fd:3c:2d:f7:9f:ea:55:df:76:2f:a4:1f root@master


ATTENZIONE! Se hai già un file "authorized_keys" usa quello, non dare il seguente
comando.


# scp /root/.ssh/id_dsa.pub node01:/root/.ssh/authorized_keys
root@master's password:
id_dsa.pub   100%  234     2.0MB/s   00:00

# scp /root/.ssh/id_dsa.pub node02:/root/.ssh/authorized_keys
root@master's password:
id_dsa.pub   100%  234     2.0MB/s   00:00

Per l'autenticazione basata sugli hosts devi modificare il file /etc/ssh/shosts.equiv.

node01.adelie
node02.adelie
master.adelie

Sono necessarie anche alcune modifiche al file /etc/ssh/sshd_config.

# $OpenBSD: sshd_config,v 1.42 2001/09/20 20:57:51 mouring Exp $
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# This is the sshd server system-wide configuration file.  See sshd(8)
# for more information.

# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key

Se la tua applicazione richiede comunicazioni via RSH è necessario emergere net-misc/netkit-rsh e sys-apps/xinetd.

# emerge -p xinetd
# emerge xinetd
# emerge -p netkit-rsh
# emerge netkit-rsh

Adesso configura il demone rsh editando il file /etc/xinet.d/rsh.

# Adelie Linux Research & Development Center
# /etc/xinetd.d/rsh

service shell
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = root
        group           = tty
        server          = /usr/sbin/in.rshd
        log_type        = FILE /var/log/rsh
        log_on_success  = PID HOST USERID EXIT DURATION
        log_on_failure  = USERID ATTEMPT
        disable         = no
}

Modifica anche il file /etc/hosts.allow per autorizzare le connessioni rsh.

# Adelie Linux Research & Development Center
# /etc/hosts.allow

in.rshd:192.168.1.0/255.255.255.0

O potete semplicemente avere fiducia nella vostra LAN:

# Adelie Linux Research & Development Center
# /etc/hosts.allow     

ALL:192.168.1.0/255.255.255.0

Per finire configura l'autenticazione degli host editando il file /etc/hosts.equiv.

# Adelie Linux Research & Development Center
# /etc/hosts.equiv

master
node01
node02

E imposta il runlevel di xinetd su default:

# rc-update add xinetd default

NTP 

Il Network Time Protocol (NTP) è usato per sincronizzare l'ora di un computer (client o server) con quella di un altro server o di un altra macchina che ha un orologio, ad esempio una radio, un ricevitore satellitare o un modem. Generalmente la precisione in una rete LAN è di un millisecondo e in una rete WAN è di una decina di millisecondi utilizzando ad esempio UTC (Coordinated Universal Time) con un GPS (Global Positioning Service). Solitamente le configurazioni di NTP utilizzano molti servers ridondanti e diversi percorsi della rete per raggiungere un'ottima precisione e un'ottima attendibilità.

Scegli un server NTP geograficamente abbastanza vicino a te da questa lista di servers NTP pubblici e configura i tuoi files /etc/conf.d/ntp e /etc/ntp.conf del tuo nodo master.

# Copyright 1999-2002 Gentoo Technologies, Inc.
# Distributed under the terms of the GNU General Public License v2
# /etc/conf.d/ntpd

# NOTES:
#  - NTPDATE variables below are used if you wish to set your
#    clock when you start the ntp init.d script
#  - make sure that the NTPDATE_CMD will close by itself ...
#    the init.d script will not attempt to kill/stop it
#  - ntpd will be used to maintain synchronization with a time
#    server regardless of what NTPDATE is set to
#  - read each of the comments above each of the variable

# Comment this out if you dont want the init script to warn
# about not having ntpdate setup
NTPDATE_WARN="n"

# Command to run to set the clock initially
# Most people should just uncomment this line ...
# however, if you know what you're doing, and you
# want to use ntpd to set the clock, change this to 'ntpd'
NTPDATE_CMD="ntpdate"

# Options to pass to the above command
# Most people should just uncomment this variable and
# change 'someserver' to a valid hostname which you
# can aquire from the URL's below
NTPDATE_OPTS="-b ntp1.cmc.ec.gc.ca"

##
# A list of available servers is available here:
# http://www.eecis.udel.edu/~mills/ntp/servers.html
# Please follow the rules of engagement and use a
# Stratum 2 server (unless you qualify for Stratum 1)
##

# Options to pass to the ntpd process that will *always* be run
# Most people should not uncomment this line ...
# however, if you know what you're doing, feel free to tweak
#NTPD_OPTS=""

Modifica il file /etc/ntp.conf del nodo master in maniera da impostare una fonte esterna per la sincronizzazione:

# Adelie Linux Research & Development Center
# /etc/ntp.conf

# Synchronization source #1
server ntp1.cmc.ec.gc.ca
restrict ntp1.cmc.ec.gc.ca
# Synchronization source #2
server ntp2.cmc.ec.gc.ca
restrict ntp2.cmc.ec.gc.ca
stratum 10
driftfile /etc/ntp.drift.server
logfile  /var/log/ntp
broadcast 192.168.1.255
restrict default kod
restrict 127.0.0.1
restrict 192.168.1.0 mask 255.255.255.0

E imposta in tutti i nodi slaves, come fonte per la sincronizzazione, il tuo nodo master.

# Copyright 1999-2002 Gentoo Technologies, Inc.
# Distributed under the terms of the GNU General Public License v2
# /etc/conf.d/ntpd

NTPDATE_WARN="n"
NTPDATE_CMD="ntpdate"
NTPDATE_OPTS="-b master"

# Adelie Linux Research & Development Center
# /etc/ntp.conf

# Synchronization source #1
server master
restrict master
stratum 11
driftfile /etc/ntp.drift.server
logfile  /var/log/ntp
restrict default kod
restrict 127.0.0.1

Per finire aggiungi ntpd al runlevel di tutti i nodi:

# rc-update add ntpd default

IPTABLES 

Per configurare un firewall sul vostro cluster dovete installare iptables.

# emerge -p iptables
# emerge iptables

Configurazione del kernel richiesta:

CONFIG_NETFILTER=y
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_LOG=y

Le regole che questo tipo di firewall necessita sono:

# Adelie Linux Research & Development Center
# /var/lib/iptbles/rule-save

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -s 192.168.1.0/255.255.255.0 -i eth1 -j ACCEPT
-A INPUT -s 127.0.0.1 -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -j LOG
-A INPUT -j REJECT --reject-with icmp-port-unreachable
COMMIT
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A POSTROUTING -s 192.168.1.0/255.255.255.0 -j MASQUERADE
COMMIT

Infine aggiungi anche iptables al runlevel di tutti i nodi:

# rc-update add iptables default

3.HPC Tools

OpenPBS 

Il Portable Batch System (PBS) è un sistema flessibile per la gestione delle code di batch; originariamente è stato sviluppato dalla NASA. Funziona bene con networked e sistemi UNIX multi-piattaforma, come clusters, workstations, supercomputers e molti sistemi paralleli. Attualmente è la Altair Grid Technologies che continua lo sviluppo di PBS.

# emerge -p openpbs

Prima di iniziare a usare OpenPBS sono necessarie alcune configurazioni particolari. I files da personalizzare sono:

• /etc/pbs_environment
• /var/spool/PBS/server_name
• /var/spool/PBS/server_priv/nodes
• /var/spool/PBS/mom_priv/config
• /var/spool/PBS/sched_priv/sched_config

Questo è un esempio di sched_config:

#
# Create queues and set their attributes.
#
#
# Create and define queue upto4nodes
#
create queue upto4nodes
set queue upto4nodes queue_type = Execution
set queue upto4nodes Priority = 100
set queue upto4nodes resources_max.nodect = 4
set queue upto4nodes resources_min.nodect = 1
set queue upto4nodes enabled = True
set queue upto4nodes started = True
#
# Create and define queue default
#
create queue default
set queue default queue_type = Route
set queue default route_destinations = upto4nodes
set queue default enabled = True
set queue default started = True
#
# Set server attributes.
#
set server scheduling = True
set server acl_host_enable = True
set server default_queue = default
set server log_events = 511
set server mail_from = adm
set server query_other_jobs = True
set server resources_default.neednodes = 1
set server resources_default.nodect = 1
set server resources_default.nodes = 1
set server scheduler_iteration = 60

Per mandare un processo (job) a OpenPBS, il comando qsub è usato con alcuni parametri opzionali. Ad esempio "-l" permette di specificare le richieste necessarie, "-j" permette il redirect degli errori e degli standard out e "-m" manda un e-mail all'inizio (b), alla fine (e) e all'interruzione (a) del lavoro.

manda la richiesta a OpenpPBS di eseguire myscript in 2 nodi

# qsub -l nodes=2 -j oe -m abe myscript

Normalmente le istruzioni sono mandate a OpenPBS sotto forma di scripts. Se qualche volta aveste bisogno di eseguire delle operazioni manualmente potete richiedere una shell interattiva a OpenPBS, con il parametro "-I".

# qsub -I

Per vedere lo stato dei vostri jobs potete usare il comando:

# qstat
Job id  Name  User   Time Use S Queue
------  ----  ----   -------- - -----
2.geist STDIN adelie 0        R upto1nodes

MPICH 

Message passing (scambio di messaggi) è una libreria usata frequentemente in certi tipi di parallel machines, specialmente nelle architetture a memoria distribuita. MPICH è un'implementazione di MPI (lo standard per lo scambio di messaggi) distribuita liberamente.

L'ebuild di mpich scritto da Adelie Linux ha due USE flags: doc e crypt. doc installa anche la documentazione, mentre crypt configura MPICH in modo da usare ssh invece di rsh.

# emerge -p mpich
# emerge mpich

Potreste avere la necessità di esportare una directory di lavoro per mpich in tutti i vostri nodi slaves in /etc/exports:

/home	*(rw)

Most massively parallel processors (MPPs) mette a disposizione un modo per fare partire un programma su un determinato numero di processori; quando è possibile mpirun usa questo comando. Al contrario, i clusters di workstations necessitano che ogni processo in un parallel job sia fatto partire individualmente, malgrado esistano programmi che aiutano a fare partire questi processi. Ad ogni modo per usare i cluster di workstations bisogna avere ancora alcune informazioni, perchè non sono organizzati come un MPP. Mpich dovrebbe essere installato con una lista di workstations nel file machines.LINUX nella directory /usr/share/MPICH/. Questo file è usato da mpirun per scegliere il processore su qui fare partire il processo.

Modifica questo file per specificare le macchine del tuo cluster:

# Change this file to contain the machines that you want to use
# to run MPI jobs on.  The format is one host name per line, with either
#    hostname
# or
#    hostname:n
# where n is the number of processors in an SMP.  The hostname should
# be the same as the result from the command "hostname"
master
node01
node02
# node03
# node04
# ...

Puoi usare lo script tstmachines (in /usr/sbin) per assicurarti che puoi fare uso correttamente di tutte le macchine specificate precedentemente. Lo script chiama rsh e fa una breve lista della directory; se il test funziona vuole dire che l'accesso al nodo funziona correttamente e che la directory corrente è visibile nel nodo remoto. Se ci sono dei problemi il test darà degli errori, e sarà necessario rimediarvi prima di procedere con le prossime istruzioni.

L'unico argomento di tstmachines è il nome dell'architettura, che è lo stesso nome dell'estensione del file machines. L'esempio seguente testa che il programma nella directory corrente può essere eseguito da tutte le macchine della lista LINUX.

# /usr/local/mpich/sbin/tstmachines LINUX

# /usr/local/mpich/sbin/tstmachines -v LINUX

L'output di questo comando sarà qualcosa del genere:

Trying true on host1.uoffoo.edu ...
Trying true on host2.uoffoo.edu ...
Trying ls on host1.uoffoo.edu ...
Trying ls on host2.uoffoo.edu ...
Trying user program on host1.uoffoo.edu ...
Trying user program on host2.uoffoo.edu ...

Se tstmachines trova un problema suggerisce delle possibili ragioni e soluzioni. Si possono vedere ad esempio questi test seguenti:

• Si possono fare partire dei processi nelle macchine remote?tstmachines lancia il comando "true" su ogni macchina del file machines usando la shell remota.
• La directory di lavoro corrente è disponibile correttamente per tutte le macchine? Consiste nel listare il file che tstmachines crea lanciando ls tramite la shell remota.
• I programmi degli utenti funzionano correttamente nel sistema remoto? Controlla che le shared libraries e tutti i componenti necessari siano stati correttamente installati in tutte le macchine.

Anche questo test è necessario per tutti i tools di sviluppo:

# cd ~
# cp /usr/share/mpich/examples1/hello++.c ~
# make hello++
# mpirun -machinefile /usr/share/mpich/machines.LINUX -np 1 hello++

Per ulteriori informazioni su MPICH consulta la documentazione sul sito http://www-unix.mcs.anl.gov/mpi/mpich/docs/mpichman-chp4/mpichman-chp4.htm

LAM 

(in arrivo)

OMNI 

(in arrivo)

4.Bibliografia

Il documento originale (in inglese) è pubblicato sul sitoAdelie Linux R&D Centre, ed è stato pubblicato qui grazie al permesso degli autori e del Cyberlogic's Adelie Linux R&D Centre.

• http://www.gentoo.org, Gentoo Technologies, Inc.
• http://www.adelielinux.com, Adelie Linux Research and Development Centre
• http://nfs.sourceforge.net, Linux NFS Project
• http://www-unix.mcs.anl.gov/mpi/mpich/, Mathematics and Computer Science Division, Argonne National Laboratory
• http://ntp.org
• http://www.eecis.udel.edu/~mills/, David L. Mills, University of Delaware
• http://www.ietf.org/html.charters/secsh-charter.html, Secure Shell Working Group, IETF, Internet Society
• http://www.linuxsecurity.com/, Guardian Digital
• http://www.openpbs.org/ Altair Grid Technologies, LLC.