Obliczenia wielkoskalowe na Gentoo

1.  Wstęp

Gentoo to wyjątkowo konfigurowalna i nadająca się do optymalizowania dystrybucja Linuksa, której dodatkowymi zaletami są świetna społeczność użytkowników i deweloperów.

Gentoo dzięki technologii może stać się bezpiecznym serwerem, stacją roboczą developera, profesjonalnym systemem biurkowym, maszyną do gier lub ... systemem obliczeń wielkoskalowych. Dzięki swojej niemal nieograniczonej przystosowalności można nazwać Gentoo metadystrybucją.

Ten dokument wyjaśnia jak zmienić Gentoo w system obliczeń wielkoskalowych. Krok po kroku omówimy w nim, które pakiety należy zainstalować, a następnie jak je skonfigurować.

Pierwszy krok to oczywiście instalacja Gentoo zgodnie ze wskazówkami spisanymi w odpowiedniej dokumentacji.

2.  Konfigurowanie Gentoo dla klasteryzacji (ang. clustering).

Zalecane optymalizacje.

Podczas instalacji należy ustawić flagi USE w /etc/make.conf. Zalecane jest wyłączenie wszystkich domyślnych zmiennych (patrz /etc/make.profile/make.defaults) poprzez zanegowanie ich w make.conf. Można pozostawić jedynie takie zmienne USE jak: x86, 3dnow, gpm, mmx, nptl, nptlonly, sse, ncurses, pam and tcpd. Więcej informacji można znaleźć w dokumentacji flag USE.

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 nptl nptlonly -oggvorbis -opengl pam -pdflib -png -python -qt3
-qt4 -qtmt -quicktime -readline -sdl -slang -spell -ssl -svga tcpd -truetype -X
-xml2 -xv -zlib"

Lub po prostu:

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

Dla wielkoskalowego systemu polecamy wybranie jądra vanilla-sources ze względu na jego dużą stabilność, o ile nie są potrzebne dodatkowe łatki, zawierające np. obsługę XFS. Źródła tego jądra można pobrać ze strony http://www.kernel.org/.

# emerge -p syslog-ng vanilla-sources

Polecamy zainstalowanie następujących pakietów:

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

Warstwa komunikacyjna (sieć TCP/IP).

Klaster wymaga warstwy komunikacyjnej do łączenia węzłów podrzędnych z węzłem głównym. Zwykle Fast Ethernet lub Giga Ethernet LAN mogą być użyte ponieważ mają dobry stosunek cena/jakość. Inne możliwości uwzględniają użycie produktów takich jak: Myrinet, QsNet lub innych.

Zwykle klaster składa się z węzła głównego oraz kilku węzłów podrzędnych.

Węzeł główny jest serwerem klastra. Jest on odpowiedzialny za wyznaczanie zadań dla węzłów podrzędnych. Serwer zwykle ma uruchomione takie demony jak: dhcpd, nfs, pbs-server i pbs-sched. Węzeł główny będzie pozwalał na interakcyjne sesje dla użytkowników oraz będzie zatwierdzał wykonywanie zadań.

Węzły podrzędne nasłuchują instrukcji (poprzez ssh/rsh) z węzła głównego. Powinny one być poświęcone na opracowywanie wyników, a zatem nie powinny mieć uruchomionych żadnych niepotrzebnych usług.

Skonfigurujemy teraz plik hosts dla naszego klastra. Każdy węzeł powinien posiadać plik hosts (/etc/hosts) z wpisami dla każdego węzła będącego w klastrze.

# 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

Aby ustawić sieć LAN oddaną naszemu klastrowi należy zedytować plik /etc/conf.d/net na węźle głównym.

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

W końcu ustawiamy demon DHCP na węźle głównym, dzięki czemu unikniemy konfigurowania sieci na każdym z węzłów podrzędnych.

# 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.

Network File System (NFS) został stworzony, aby umożliwić komputerom zamontowanie partycji z maszyny zdalnej, tak jakby była ona na lokalnym dysku, co pozwala na szybkie i jednolite współdzielenie plików w całej sieci.

Są inne systemy, które dają podobne możliwości jak NFS i które również mogłyby zostać użyte w środowisku klastra. Andrew File System od IBM, którego kod został ostatnio otwarty to dobry mechanizm do współdzielenia plików z pewnymi dodatkowymi funkcjami bezpieczeństwa oraz wydajności. Coda File System jest ciągle rozwijany. Jest to system zaprojektowany do dobrego współdziałania z odłączonymi klientami. Wiele cech systemów plików Andrew i Coda na pewno zostanie włączonych do następnej wersji NFS (wersja 4). Zaletą NFS jest fakt, że jest to system bardzo dopracowany i przez wielu uznawany już za standard, a ponadto powszechnie znany oraz obsługiwany na bardzo wielu różnych architekturach.

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

Należy skonfigurować i zainstalować jądro aby wspierało NFS v3 na wszystkich węzłach:

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

Na węźle głównym należy edytować plik /etc/hosts.allow i zezwolić na połączenia z węzłów podrzędnych. Jeśli sieć klastra jest na 192.168.1.0/24, to hosts.allow będzie tak wyglądał:

portmap:192.168.1.0/255.255.255.0

Następnie należy edytować plik /etc/exports węzła głównego, aby wyeksportować strukturę katalogu roboczego (odpowiedni do tego jest np. /home).

/home/  *(rw)

Skrypt nfs powinien znaleźć się na domyślnym poziomie uruchomieniowym:

# rc-update add nfs default

Aby móc montować wyeksportowany system plików nfs z głównego węzła należy odpowiednio skonfigurować także węzły podrzędne. W tym celu do /etc/fstab dodajemy taką linię:

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

Potrzebujemy jeszcze ustawić wszystkie węzły, aby mogły montować system plików nfs. Dokonuje się tego następującym poleceniem:

# rc-update add nfsmount default

RSH/SSH.

SSH to protokół umożliwiające bezpieczne zdalne logowanie oraz dostarczający wielu innych usług sieciowych. OpenSSH zapewnia bezpieczną autoryzację poprzez klucz publiczny i prywatny. Klucz publiczny jest współdzielony na wszystkich systemach, prywatny znajduje się tylko w lokalnym komputerze. Aby z nich korzystać należy najpierw skonfigurować klaster OpenSSH.

Proces wdrażania systemu kluczy w klastrze składa się z dwóch etapów:

• Generowania klucza publicznego i prywatnego,
• oraz kopiowania klucza publicznego na węzły podrzędne

Klucze generuje się w ten sposób:

# 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

UWAGA! Jeśli istnieje już plik o nazwie "authorized_keys" nie należy
korzystać z poniższego polecenia, tylko ręcznie dodać do niego odpowiedni wpis.

# 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

By umożliwić uwierzytelnianie hosta trzeba również edytować plik /etc/ssh/shosts.equiv.

node01.adelie
node02.adelie
master.adelie

Oraz wykonać kilka zmian w pliku /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

Jeśli program wymaga komunikacji RSH, należy zainstalować net-misc/netkit-rsh i sys-apps/xinetd.

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

Potem konfigurujemy demona rsh. W tym celu edytujemy plik /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
}

A następnie plik /etc/hosts.allow i zezwalamy na połączenia rsh.

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

in.rshd:192.168.1.0/255.255.255.0

Lub po prostu możemy zaufać sieci LAN klastra:

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

ALL:192.168.1.0/255.255.255.0

W końcu konfigurujemy uwierzytelnianie hosta w /etc/hosts.equiv.

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

master
node01
node02

Potem należy dodać xinetd do domyślnego poziomu uruchamiania:

# rc-update add xinetd default

NTP.

Network Time Protocol (NTP) jest używany do synchronizacji czasu komputera klienta lub serwera do innego serwera lub innego odnośnika źródła czasu, jak np. odbiornik radiowy, satelitarny lub modem. Dostarcza ono dokładność rzędu milisekund w sieci LAN i do kilkudziesięciu milisekund w sieci WAN w odniesieniu do czasu uniwersalnego (UTC), poprzez na przykład satelitarny program lokalizujący GPS. Typowe ustawienia NTP wykorzystują wielorakie rezerwowe serwery oraz różnorodne ścieżki sieciowe, co zapewnia wysoką dokładność i rzetelność wyniku.

Należy wybrać najbliższy geograficznie serwer NTP ze strony NTP Time Servers oraz skonfigurować pliki /etc/conf.d/ntp i /etc/ntp.conf na węźle głównym.

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

Następnie edytujemy plik /etc/ntp.conf na węźle głównym, aby ustawić zewnętrzne źródło synchronizacji:

# 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

Później na wszystkich węzłach podrzędnych ustawiamy źródło synchronizacji tak jak na węźle głównym.

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

Następnie na wszystkich węzłach należy dodać demon ntpd do domyślnego poziomu uruchamiania:

# rc-update add ntpd default

Iptables.

Do ustawienia zapory ogniowej w klastrze będziemy potrzebować iptables.

# emerge -p iptables
# emerge iptables

Wymagana konfiguracja jądra:

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

A to reguły wymagane dla naszej zapory ogniowej:

# 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

Następnie na wszystkich węzłach należy dodać iptables do domyślnego poziomu uruchamiania:

# rc-update add iptables default

3.  Narzędzia HPC.

OpenPBS.

Portable Batch System (PBS) jest elastycznym systemem nadzorującym kolejkowanie prac wsadowych oraz obciążenie pracą, który pierwotnie został opracowany dla NASA. Operuje ono na sieciowych wieloplatformowych środowiskach UNIX, włącznie z niejednorodnymi klastrami stacji roboczych, superkomputerów oraz w operacyjnych komputerach masywnie równoległych (massive parallel systems). PBS jest rozwijany przez Altair Grid Technologies.

# emerge -p openpbs

Przed rozpoczęciem użytkowania OpenPBS wymagane są zatem pewne zmiany w konfiguracji. Pliki, których ustawienia będziemy musieli dostosować to:

• /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

Przykładowy 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

Aby przedłożyć zadanie OpenPBS należy użyć polecenia qsub z opcjonalnymi parametrami. W przykładzie poniżej, "-l" pozwala określić wymagane zasoby, "-j" zapewnia przekierowanie wyjścia standardowego oraz standardowego raportowania błędów, a "-m" wysyła e-mail do użytkownika przy rozpoczęciu (b), zakończeniu (e) i anulowaniu (a) zadania.

(przedłożenie i żądanie aby OpenPBS uruchomił myscript na 2 węzłach)
# qsub -l nodes=2 -j oe -m abe myscript

Zwykle zadania dla OpenPBS są przedkładane w formie skryptów. Istnieje również funkcja ręcznego wykonywania poleceń dla celów testowych. Aby zażądać interaktywnej powłoki od OpenPBS należy podać parametr "-I".

# qsub -I

Aby sprawdzić stan zadań należy wykonać polecenie qstat:

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

MPICH.

Przesyłanie komunikatów jest paradygmatem używanym szeroko w pewnych klasach maszyn pracujących równolegle, szczególnie na tych z pamięcią rozproszoną. MPICH jest darmową, przenośną implementacją MPI, czyli standardu do bibliotek przesyłania komunikatów.

Stworzony przez Adelie Linux ebuild mpich pozwala na użycie 2 flag USE: doc i crypt. doc spowoduje zainstalowanie dokumentacji, a crypt skonfiguruje MPICH, aby używał ssh zamiast rsh.

# emerge -p mpich
# emerge mpich

Może być również konieczne wyeksportowanie katalogu roboczego mpich na wszystkie węzły podrzędne w /etc/exports:

/home  *(rw)

Większość operacyjnych komputerów masywnie równoległych (ang. massively parallel processors) daje możliwość uruchomienia programu na żądanej przez nas liczbie procesorów. mpirun robi użytek z odpowiedniego polecenia kiedykolwiek jest to możliwe. Z drugiej strony klastry złożone ze stacji roboczych wymagają aby każdy proces w równoległym zadaniu został uruchomiony oddzielnie, pomimo że istnieją programy, które pomagają start tym procesom. Ponieważ klastry stacji roboczych nie są jeszcze tak zorganizowane jak MPP, więc dodatkowa informacja jest wymagana aby zrobić z nich użytek. Mpich powinno być zainstalowane z listą uczestniczących stacji roboczych w pliku machines.LINUX, który się znajduje w katalogu /usr/share/mpich/. Ten plik jest używany przez mpirun do wybierania procesorów na których będzie dane zadanie wykonywane.

Należy edytować ten plik, tak by odpowiadał on konfiguracji sieci klastra:

# 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
# ...

Później należy użyć skryptu tstmachines w /usr/sbin/ aby się upewnić, że możemy używać wszystkich maszyn, które wcześniej zostały wpisane do pliku machines.LINUX. Ten skrypt wykonuje rsh i wyświetla krótką zawartość katalogu; te testy sprawdzają czy obie maszyny mają dostęp do węzła i czy program w katalogu bieżącym jest widoczny na węźle zdalnym. Jeśli są jakiekolwiek problemy, to zostaną one wyświetlone. Te problemy muszą być naprawione zanim przystąpimy do nastepnego kroku.

Jedynym parametrem dla tstmachines jest nazwa architektury, która jest taka sama jak rozszerzenie w pliku machines. Dla przykładu, następujące polecenie sprawdza czy program z katalogu bieżącego może być uruchomiony przez wszystkie maszyny, które są na liście maszyn LINUX.

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

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

Wynik tego polecenia może wyglądać tak jak poniżej:

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 ...

Jeśli tstmachines znajdzie problem, zasugeruje on możliwe przyczyny i rozwiązania tego problemu. W skrócie wykonuje on 3 testy:

• Czy procesy mogą być wykonywane na zdalnych komputerach? tstmachines próbuje uruchomić polecenie powłoki true na każdej maszynie, która jest na liście.
• Czy bieżący katalog jest dostępny dla wszystkich komputerów? Spróbuje poleceniem ls wyświetlić plik, który wcześniej utworzy.
• Czy programy użytkownika mogą być uruchamiane na zdalnych systemach? sprawdza czy biblioteki współdzielone i inne komponenty są poprawnie zaintalowane na wszystkich komputerach.

Wymagany test dla każdego narzędzia programistycznego:

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

Aby uzyskać więcej informacji o MPICH należy zajrzeć do dokumentacji na http://www-unix.mcs.anl.gov/mpi/mpich/docs/mpichman-chp4/mpichman-chp4.htm.

LAM.

(Wkrótce)

OMNI.

(Wkrótce)

4.  Bibliografia

Oryginalny dokument został opublikowany na stronie Adelie Linux R&D Centre, oraz jest powielony tu za zgodą autorów i 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.