Calcolo ad Alte Prestazioni su 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 più 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 calcolo ad alte prestazioni. Grazie alla sua adattabilità quasi infinita, Gentoo Linux viene definita una metadistribuzione.

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

Ottenere una copia di Gentoo dal sito web http://www.gentoo.org e fare riferimento alla documentazione per l'installazione.

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. Si raccomanda di disattivare tutte le variabili predefinite (vedere /etc/make.profile/make.defaults) mettendo un segno meno in /etc/make.conf. Malgrado questo potrebbe essere necessario attivare variabili USE come 3dnow, gpm, mmx, nptl, nptlonly, sse, ncurses, pam e tcpd. Per maggiori informazioni fare riferimento alla documentazione sulle flag USE.

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

o più semplicemente

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à si raccomanda l'installazione di vanilla-sources, la versione ufficiale del kernel (quella di http://www.kernel.org/), anche se si necessita di caratteristiche speciali, come xfs.

# emerge -a syslog-ng vanilla-sources

Quando in seguito verranno installati altri pacchetti si consiglia di effettuare l'emerge anche dei seguenti:

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

Strato per la comunicazione (Rete TCP/IP)

Un cluster necessita di un "communication layer" (ndT: 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 slave.

Il nodo master è il server del cluster e il suo compito è di coordinare i nodi slave dicendo loro 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 slave 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 propria LAN dedicata al cluster modificare il file /etc/conf.d/net nel nodo master.

# 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 configurare il demone DHCP del proprio 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 file nella rete.

Ci sono anche altri sistemi che hanno funzionalità simili a NFS e che possono essere usati in un cluster. L'Andrew File System dell'IBM, recentemente rilasciato open-source, ha un meccanismo di condivisione dei file 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 client disconnessi. Molte delle caratteristiche 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 -a nfs-utils portmap

Configurare e installare 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 nodo master modificare il file /etc/hosts.allow per accettare le connessioni dai nodi slave. Se la LAN del proprio 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

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

/home/  *(rw)

Aggiungere nfs al runlevel di default sul nodo master:

# rc-update add nfs default

Per montare filesystem nfs dal master bisogna modificare il file /etc/fstab dei nodi slave, aggiungendo una linea simile a questa:

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

Bisogna anche fare in modo che i nodi slave montino il filesystem nfs:

# rc-update add nfsmount default

RSH/SSH

SSH è un protocollo per effettuare login remoti e altri operazioni in una rete insicura, ma in 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 slave

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 si dispone già di un file "authorized_keys" usare 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 host bisogna 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 propria applicazione richiede comunicazioni via RSH è necessario emergere net-misc/netkit-rsh e sys-apps/xinetd.

# emerge -a xinetd
# emerge -a netkit-rsh

Adesso configurare il demone rsh modificando 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
}

Modificare 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 si può semplicemente dare fiducia alla propria LAN:

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

ALL:192.168.1.0/255.255.255.0

Per finire configurare l'autenticazione degli host modificando il file /etc/hosts.equiv.

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

master
node01
node02

E aggiungere xinetd al runlevel di 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à.

Scegliere un server NTP geograficamente abbastanza vicino da questa lista di server NTP pubblici e configurare i file /etc/conf.d/ntp e /etc/conf.d/ntp del proprio nodo master.

# /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=""

Modificare 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 impostare in tutti i nodi slave, come fonte per la sincronizzazione, il proprio nodo master.

# /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 aggiungere ntpd al runlevel di default in tutti i nodi:

# rc-update add ntpd default

IPTABLES

Per configurare un firewall sul proprio cluster bisogna installare iptables.

# emerge -a 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/iptables/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 aggiungere anche iptables al runlevel di default in 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 cluster, workstation, supercomputer e molti sistemi paralleli. Attualmente è la Altair Grid Technologies che continua lo sviluppo di PBS.

# emerge -a openpbs

Prima di iniziare a usare OpenPBS sono necessarie alcune configurazioni particolari. I file 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 la ridirezione dello standard error e dello 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 script. Se qualche volta c'è bisogno di eseguire delle operazioni manualmente si può richiedere una shell interattiva a OpenPBS, con il parametro "-I".

# qsub -I

Per vedere lo stato dei propri jobs (lavori) 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 macchine parallele, 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 flag USE flag: doc e crypt. doc installa anche la documentazione, mentre crypt configura MPICH in modo da usare ssh invece di rsh.

# emerge -a mpich

Potrebbe esserci la necessità di esportare una directory di lavoro per mpich in tutti i nodi slave in /etc/exports:

/home   *(rw)

La maggior parte dei sistemi ad elevato parallelismo ("Most massively parallel processors", o "MPP") 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 cluster di workstation necessitano che ogni processo in un lavoro parallelo sia fatto partire individualmente, malgrado esistano programmi che aiutano a fare partire questi processi. Ad ogni modo per usare i cluster di workstation bisogna avere ancora alcune informazioni, perchè non sono organizzati come un MPP. Mpich dovrebbe essere installato con una lista di workstation nel file machines.LINUX nella directory /usr/share/MPICH/. Questo file è usato da mpirun per scegliere il processore su cui fare partire il processo.

Modificare questo file per specificare le macchine del proprio cluster:

# Modificare questo file in modo che contenga le macchine su cui si vogliono
# eseguire i lavori di MPI. Il formato è un nome host per linea, utilizzando o
#    hostname
# o
#    hostname:n
# dove n è il numero di processori in un SMP. L'hostname dovrebbe
# essere uguale a quello ottenuto tramite il comando "hostname"
master
node01
node02
# node03
# node04
# ...

È possibile usare lo script tstmachines (in /usr/sbin) per assicurarsi di poter usare 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 correggerli 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 verifica che il programma nella directory corrente possa 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. In breve, ci sono tre test:

• Si possono fare partire dei processi nelle macchine remote? tstmachines prova ad eseguire il comando "true" su ogni macchina del file machines usando la shell remota.
• La directory di lavoro corrente è disponibile correttamente per tutte le macchine? Prova ad elencare il file che tstmachines crea lanciando ls tramite la shell remota.
• I programmi degli utenti funzionano correttamente nel sistema remoto? Controlla che le librerie condivise e altri componenti siano stati correttamente installati in tutte le macchine.

ed il test necessario per ogni strumento 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 consultare la documentazione sul sito http://www-unix.mcs.anl.gov/mpi/mpich/docs/mpichman-chp4/mpichman-chp4.htm

LAM

(Presto disponibile)

OMNI

(Presto disponibile)

4.  Bibliografia

Il documento originale (in inglese) è pubblicato sul sito Adelie 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 Foundation, 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.