rhel-readonly

Il y a des avantages et des inconvénients à ce que tous les Raspberry pi du cluster bootent ensemble avec le même root-file-system situé sur un serveur nfs.

- L’énorme avantage est la maintenabilité : une mise  à jour sur le serveur nfs et tous les nœuds sont automatiquement à jour. Finit de dupliquer les sd-cartes, de faire des yum update sur chaque nœud, de répliquer les fichiers de configuration etc. (même si avec des outils comme Ansible on peut automatiser cela)

- L’inconvénient majeur est qu’il y a des fichiers modifiés simultanément par plusieurs  nœuds. Par exemple les fichiers de log, les caches etc. Pour éviter ces confits il va falloir faire 4 choses :

1. Monter le root file system en read-only.
2. Monter certains fichiers ou répertoire dans un file system temporaire en mémoire
3. Attribuer un espace de stockage persistent spécifique à chaque nœuds
4. Organiser/configurer les applications pour quelles écrivent dans cette zone dédiée.

1) Monter le root-file system en read-only

Dans le répertoire du serveur tftp (/var/lib/tftpboot/) nous avons le fichier cmdline.txt qui contenait jusqu’à maintenant cette unique ligne :
    root=/dev/nfs nfsroot=192.168.1.100:/var/nfs/rpi-fs  rw  ip=dhcp  rootwait
Il faut y remplacer le « rw »  par « ro ». Ce qui donne :
    root=/dev/nfs nfsroot=192.168.1.100:/var/nfs/rpi-fs  ro  ip=dhcp  rootwait

(ne booter par encore)

2) Monter certains fichiers et répertoires en mémoire

3) Attribuer un espace de stockage persistent à chaque Raspberry Pi du cluster

Avec CentOS 7.2+ ces deux points sont pris en charge par le pseudo service ‘rhel-readonly’.


Le service est:       /lib/systemd/rhel-readonly
Il décrit par:        /lib/systemd/system/rhel-readonly.service
Il est configuré par: /etc/sysconfig/readonly-root
Pour voir ses log:    journalctl -u rhel-readonly

Ce n’est pas un véritable service car il ne peut être ni activé ni désactivé avec systemctl car il est toujours exécuté au boot mais ne fait rien. Pour l’activer il faut éditer  /etc/sysconfig/readonly-root

ATTENTION: ne pas éditer les fichiers du serveur nfs, mais ceux qui sont dans la partie exportée par le serveur nfs : /var/nfs/rpi-fs/ . Le fichier  /path/to/file sur le client (le nœud du cluster) est sur le serveur nfs : /var/nfs/rpi-fs/path/to/file. 

Il y a plusieurs subtilités de configuration entre la ligne de commande du kernel et les deux variables READONLY et TEMPORARY_STATE. Pour faire simple et général on va configurer ce fichier ainsi:

READONLY=yes
TEMPORARY_STATE=yes

RW_MOUNT=/var/lib/stateless/writable
RW_LABEL=stateless-rw
RW_OPTIONS=

STATE_LABEL=stateless-state
STATE_MOUNT=/var/lib/stateless/state
STATE_OPTIONS=
CLIENTSTATE=192.168.1.100:/var/nfs

SLAVE_MOUNTS=yes


Adapter l'ip et le path de CLIENTSTATE à votre config.

En fait client va monter via nfs le path $CLIENTSTATE/$HOSTNAME sur $STATE_MOUNT.
Par example le noeud 'node04' va monter 192.168.1.100:/var/nfs/node04 sur /var/lib/stateless/state

Ce sera une zone persistante dédiée à l’activité de ce nœud. (Revoir le post sur la configuration du serveur nfs).


Pour le reste, ce qui va se passer dépend de ce qui est dans le fichier /etc/rwtab et /etc/statetab.

• /etc/rwtab et /etc/rwtab.d désignent quelles parties du file system seront montées dans un file system temporaire en mémoire. Ceci a deux implications : Ces zones ne peuvent pas servir à stoker de gros fichiers et ces fichiers seront perdus au reboot.
  
• /etc/statetab et /etc/statetab.d désignent quelles parties du file system seront montées dans le file system persistant désigné par $STATE_MOUNT (dans notre cas un export nfs). Ici pas de problème de taille de fichiers et tous les fichier sont préservés au reboot.
  
• $STATE_MOUNT/files joue le même rôle que /etc/statetab, et permet a chaque nœud de designer les zones du file system a monter dans la zone NFS.

4) Organiser/configurer les applications

Certaine application sont tres configurable d'aute moins. Il faudra bien déterminer les zones disque en écriture dons elles ont besoins et si ce doit être persistent ou volumineux (dont via nfs) ou petit et temporaire (donc en ram). On pourra jouer sur la configuration de l'application et sur la configuration de rhel-readonly via /etc/rwtab.d et /etc/statetab.d.

Note: COMMENT METTRE A JOUR ?!!

Une fois ceci en place aucun nœud ne peut est utilisé pour mettre à jour les packages avec "yum update" puisque pour tous les nœuds le root file system est read-only !

De plus le serveur tftp et nfs est un x86 donc pas la même architecture, impossible de 'partager' ses mises à jour.

On verra plus loin comment faire à l’étape tftp pour que l’un des nœuds n’utilise pas la ligne de commande qui force le root file system en ro.

NFS

Il y a plusieurs  raisons pour installer un serveur NFS dans notre cluster de Rasberry Pi 2:
•    Pour suppléer aux faiblesses des cartes SD liées au rapport cout / fiabilité-capacité-vitesse.
•    Il peut être plus facile aux nœuds d’échanger des données  via un espace disque commun  plutôt que via des sessions TCP (même si  NFS repose sur du réseau).
•    Pour simplifier le management/configuration/backup du cluster il peut être pratique d’avoir un espace disque partagé par tous les nœuds.
•    Pour booter via NFS et non via la carte SD. Cette dernière  restera nécessaire mais son contenu sera minimaliste et plus facile à maintenir.

Tout ce qui suit s’effectue avec l’utilisateur root.

1 NFS coté serveur

Le serveur que nous utilisons ici est une machine utilisant centos 7, donc pas un Raspberry . Dédier un Raspberry à cette tâche est possible à condition d’utiliser un disque externe, sinon on perd sur tous les tableaux.

Installation serveur NFS (centos)

yum install nfs-utils nfs-utils-lib

(depuis Centos 7.2 nfs-utils-lib n'existe plus car inclu dans nfs-utils)

systemctl enable rpcbind
systemctl enable nfs-server
systemctl start rpcbind
systemctl start nfs-server

Si les services nfs-lock et nfs-idmap sont requis voir la fin de ce post.

Vérifier l’installation
ps -e | grep rpc
    2152 ?        00:00:00 rpcbind
    2323 ?        00:00:00 rpciod
    2337 ?        00:00:00 rpc.statd
    2338 ?        00:00:00 rpc.mountd
    2339 ?        00:00:00 rpc.idmapd
ps -e | grep nfs
    1254 ?        00:00:00 nfsd4_callbacks
    1260 ?        00:00:00 nfsd
    1261 ?        00:00:00 nfsd
    ...
    2001 ?        00:00:00 nfsiod

cat /proc/filesystems | grep nfs
    nodev   nfsd
    nodev   nfs

    nodev   nfs4

rpcinfo -p | sort | grep nfs
   program vers proto   port  service
    100003    3   tcp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   tcp   2049  nfs
    100003    4   udp   2049  nfs
    100227    3   tcp   2049  nfs_acl
    100227    3   udp   2049  nfs_acl

Notez que pour chaque version de nfs (3 ou 4) les deux protocoles (udp et tcp) sont supportés sur le même numéro de port (2049).


Créer les répertoires à exporter
On va créer un répertoires par nœud et deux répertoires d'usage commun.
Le répertoire rpi-fs servira pour le network-boot (DHCP/BOOTP + TFTP)

mkdir -pv /var/nfs/node{01..15} /var/nfs/common /var/nfs/rpi-fs

chown  nfsnobody.nfsnobody        /var/nfs/*
chmod  a=rx,ug+w                  /var/nfs/*

ls –l /var/nfs
drwxrwxr-x 2 nfsnobody nfsnobody  common
drwxrwxr-x 2 nfsnobody nfsnobody  node01
...
drwxrwxr-x 2 nfsnobody nfsnobody  node15
drwxrwxr-x 2 nfsnobody nfsnobody  rpi-fs

Créer la liste des exports

vi /etc/exports

/var/nfs/common 192.168.0.0/24(rw,sync,root_squash,all_squash,no_subtree_check)

/var/nfs/node01 192.168.0.101(rw,sync,root_squash,all_squash,no_subtree_check)

...

/var/nfs/node15 192.168.0.115(rw,sync,root_squash,all_squash,no_subtree_check)

/var/nfs/rpi-fs 192.168.0.0/24(rw,sync,no_root_squash,no_all_squash,no_subtree_check)

Attention : Pas d’espace entre l’IP et la parenthèse ouvrante.
Adapter les noms des nœuds (ici nodexx) et les IP (ici 192.168.0.1xx) à la configuration de votre cluster.
192.168.0.0/24 désigne n’importe quelle machine du réseau 192.168.0.0
L'option no_root_squash pour le partage /var/nfs/rpi-fs utilisé plus tard pour le network boot est importante.


Exporter
exportfs –rav

Vérifier
exportfs -v


NFS v2 

Activer la version 2 de NFS est obligatoire si on veut booter via le réseau. Si ce n'est pas votre but vous pouvez ignorer cette partie.

Normalement la commande

    cat /proc/fs/nfsd/versions

indique avec un '+' les versions acceptées par le serveur nfsd. Par exemple:

   -2 +3 +4 +4.1 +4.2

signifie que la versions 2  n'est pas acceptées par nfsd.

On peut aussi vérifier avec la commande ci-dessous quelles versions sont acceptées :
    rpcinfo -p

Pour booter un Raspberry Pi2 via nfs (network boot) if faut que le serveur nfsd accepte la version 2 de nfs. Pour forcer l'usage de nfsv2 il faut éditer le fichier :
  /etc/sysconfig/nfs
et remplacer la ligne
    RPCNFSDARGS=""

par
    RPCNFSDARGS="-V 2"

et redémarrer nfs avec:
  systemctl restart nfs
  systemctl restart nfs-config

Mais avec nfs il y a tellement de services en jeux que rebooter est plus sûr...

Vous devriez alors obtenir:

cat /proc/fs/nfsd/versions
+2 +3 +4 +4.1 +4.2

et rpcinfo doit montrer
  portmapper en version 2, 3, 4
  mountd en version 1, 2, 3  (c'est bien 1, 2, 3)
  nfs en version 2, 3, 4

2 NFS coté client

Ici on est bien sur un Raspberry (sur celui qui servira à faire la carte SD master).

Installation client NFS  (rasperian)

apt-get install  nfs-common  rpcbind

update-rc.d rpcbind enable
service     rpcbind start

Installation client NFS  (CentOS 7.x)

yum install nfs-utils rcbind

systemctl enable rpcbind
systemctl start  rpcbind


Vérifier l’installation (toute versions)
cat /proc/filesystems | grep nfs
rpcinfo -p            | grep portmap

Tester
Depuis le noeud #10 (qui a l'ip 192.168.0.110) taper
mkdir -pv /mnt/nfs_home /mnt/nfs_common
mount  192.168.0.100:/var/nfs/node10 /mnt/nfs_home
mount  192.168.0.100:/var/nfs/common /mnt/nfs_common

192.168.0.100 est l’ip du serveur NFS (le serveur centos dans notre exemple)
Plus tard ce serveur fera aussi TFTP et éventuellement DHCP.

Si vous essayez de monter un export qui n'existe pas ou qui ne correspond pas votre ip vous obtiendrez ce message d'erreur:
mount.nfs: access denied by server while mounting 192.168.0.100:/var/nfs/node11

Notez que, pendant le temps du montage, le propriétaire des répertoires utilisé pour monter les exports est nobody.nogroup

ls -l /mnt
drwxrwxr-x 2 nobody nogroup     nfs_common
drwxrwxr-x 2 nobody nogroup     nfs_home

A moins que vos programmes s’exécutent en tant que root ou nobody, il faudra certainement faire un chmod o+w  pour écrire dans ces répertoires.

3 Debug NFS

Par défaut NFS n'est pas trés bavard dans les log. Pour avoir plus d'info il faut les demander avec rpcdebug.

  rpcdebug -m nfsd -s all       <-- debuger le serveur
  rpcdebug -m nfs  -s all       <-- debuger le client
  rpcdebug -m rpc  -c all       <-- debug utilisable des deux cotés

  nfsstat --all --list  <-- statistiques du serveur nfs

GNU Parallel

Avant de se lancer dans la programmation du cluster il faut mettre en place des outils de gestion du cluster permettant, par exemple, d’exécuter la même tache sur tous les nœuds du cluster, ou copier un  fichier d’un nœud vers tous les autres nœuds etc… Pour cela il y a « gnu parallel ». C’est un utilitaire d’un usage un peu spécial mais très puissant. A ne pas confondre avec ‘parallel’ inclus dans le package moreutils et qui ne permet de gérer le parallélise que sur la machine où il s’exécute.

Installation de gnu parallel

 La version classique consisterai à faire

apt-get install parallel
parallel --version

Mais il y a de fortes chances que la version ainsi obtenue ne soit pas récente. Heureusement vous pouvez installer manuellement la dernière version. Mais avant, pour éviter les conflits, il faut supprimer le package (sudo apt-get remove parallel) puis effectuer l’installation manuelle que voici :

wget http://ftpmirror.gnu.org/parallel/parallel-latest.tar.bz2
tar xjf parallel-latest.tar.bz2
cd parallel-[date]
./configure && make && sudo make install

Éditer ou créer si nécessaire le fichier /etc/parallel/config.
Supprimer ce qu’il contient (--tollef en particulier)
Ajouter la ligne :

--wc

Test

Tapez

parallel -j0 ping -nc 2 :::  google.com yahoo.com bing.com

Ceci exécutera en parallèle 3 commandes « ping –nc 2 »
A cause de l'option -j0 chaque commande s’exécutera sur un processeur diffèrent.

Remplacez -j0 par -j1 pour n’utiliser qu’un seul processeur

parallel –j1 ping -nc 2 :::  google.com yahoo.com bing.com

C’est au moins deux fois plus lent.

NB : Comme tout s’est passé sur la même machine on aurait pu utiliser le parallel de moreutils pour cela. Mais on ne va pas en rester là…

Introduction

Deux trois trucs à comprendre pour utiliser gnu parallel :

• La ligne de commande de gnu parallel est pléthorique. Certaines options existent sous deux, trois ou quatre noms. Certaines sont obsolètes. Beaucoup (trop) de choses sont configurables. Et pour aggraver les choses le man est très complet mais aussi très verbeux (plus de 3600 lignes). Par exemple, le man explique comment utiliser gnu parallel avec TOR !  Le tout donne une sensation de ‘gros machin’.
• Gnu parallel utilise un système de template basé sur la syntaxe {xxx}. C’est un peu comme le %xxx dans le printf() de C. Ce %xxx est remplacé par un paramètre de la fonction printf(). Avec parallel le paramètre qui va remplacer un {xxx} peut venir de stdin, de la ligne de commande ou d’un fichiers. Il y a donc plusieurs façons de faire la même chose. Le xxx définit comment le paramètre est utilisé dans la substitution.

Commençons pas exécuter la commande uptime sur les serveur node01,02,03,04 du cluster:

parallel --nonall –S node01,node02,node03,node04 uptime

 00:36:33 up 12:56,  0 users,  load average: 0.00, 0.01, 0.05
 00:36:33 up 12:56,  0 users,  load average: 0.00, 0.01, 0.06
 00:36:33 up 12:56,  0 users,  load average: 0.03, 0.01, 0.05
 00:36:33 up 12:56,  0 users,  load average: 0.00, 0.02, 0.05

Le résultat n’est pas lisible car on ne sait pas à qui appartient ce qui s’affiche. On va ajouter un echo et on va y inclure $(hostname). ATTENTION il faut que $(hostname) s’exécute sur le serveur distant pas local. Il faut donc utiliser des quotes simples pour que la commande arrive intacte sur le serveur  distant. Avec des quotes doubles on aurait à chaque fois le nom du serveur local.

parallel --nonall –S node01,node02,node03,node04 'echo ==== $(hostname) ====; uptime'

Ce n’est pas pratique de devoir lister les serveurs un a un. On peut utiliser ceci :

parallel --nonall -Snode0{1..4} 'echo ==== $(hostname) ====; free'

NB: Malgré la ressemblance la notation {1..4} ne relève pas de parallel mais de bash. C’est pour cela que dans ce cas il ne faut pas d’espace après le -S (je vous laisse chercher pourquoi …)

Voici une commande qui récupère la charge et la température des cpu des 9 serveurs:

parallel --nonall -Snode0{1..9} 'echo ==== $(hostname) ====; uptime; /opt/vc/bin/vcgencmd measure_temp'

==== node01 ====
 00:38:51 up 12:58,  0 users,  load average: 0.00, 0.01, 0.05
temp=37.4'C
==== node02 ====
 00:38:51 up 12:58,  0 users,  load average: 0.01, 0.01, 0.06
temp=39.0'C
==== node03 ====
 00:38:51 up 12:58,  0 users,  load average: 0.00, 0.01, 0.05
temp=36.9'C
==== node04 ====


... etc ...

==== node09 ====
 00:38:52 up 12:59,  0 users,  load average: 0.03, 0.02, 0.05
temp=36.9'C

Un dernier exemple: Stress des 9 nodes avec affichage de la température avant et après le stress. Bien sur il faut avoir installé le package 'stress' sur chaque node (voila un autre travail pour gnu parallel)

parallel --nonall -j0 -Snode0{1..9} 'echo ==== $(hostname) ====; /opt/vc/bin/vcgencmd measure_temp; stress -c 4 -i 4 --timeout 30; /opt/vc/bin/vcgencmd measure_temp'

...
==== node05 ====
temp=37.4'C
stress: info: [2352] dispatching hogs: 4 cpu, 4 io, 0 vm, 0 hdd
stress: info: [2352] successful run completed in 30s
temp=46.5'C
==== node07 ====
temp=40.6'C
stress: info: [2350] dispatching hogs: 4 cpu, 4 io, 0 vm, 0 hdd
stress: info: [2350] successful run completed in 30s
temp=49.2'C
...


Attention: les programmes ainsi exécuté via parallel sur des serveurs distants n'ont pas de tty associé. Cela peut poser divers problèmes. Le plus évident est l'impossibilité d'interagir avec ces programmes.
Exemple:
parallel --nonall -j0 -Snode0{1..9} 'echo ==== $(hostname) ====; apt-get autoremove'

==== node08 ====
Reading package lists...
Building dependency tree...
Reading state information...
The following packages will be REMOVED:
 ... ... ...
Do you want to continue [Y/n]? Abort.

 apt-get abandonne puisque, faute de tty, il ne peut pas lire la réponse [Y/n]

La bonne invocation est:
parallel --nonall -j0 -Snode0{1..9} 'echo ==== $(hostname) ====; apt-get -y autoremove'

 qui force apt-get a toujours prendre 'y' comme reponse aux questions.



à suivre...

Auto Configuration

Principe

Il n’est pas question de configurer à la main la carte micro-SD de chaque Raspberry Pi 2 du cluster. Nous allons plutôt construire une image unique, un master, que l’on dupliquera. A chaque boot le Rasperry Pi s’auto configurera pour fonctionner comme nœud du cluster. Ce système d’auto configuration devra donner une adresse IP unique, ainsi qu’un nom (hostname) unique, à chaque nœud.

L’affectation d’une adresse IP spécifique à chaque nœud se fera par DHCP. L’affectation du hostname pourrait aussi se faire via DHCP, mais tous les serveurs DHCP ne le permettent pas (en particulier ceux inclus dans les box des opérateurs internet). L’affectation du hostname unique se fera donc via un script exécuté sur le nœud à chaque fois qu’il recevra une adresse IP du serveur DHCP.

Concrètement

• Les IP seront allouées dans le réseau privé 192.168.0.0/24
• Sur la base de son adresse MAC, chaque nœud obtiendra du serveur DHCP une IP fixe spécifique, de la forme 192.168.0.XXX
• Au moment de l’allocation de cette adresse IP un script extraira du fichier /etc/hosts le hostname associé a cette IP et l'affectera au système.

Le lien entre adresse MAC et adresse IP sera configuré une fois pour toutes dans le serveur DHCP. Donc, au lieu de configurer chaque carte micro-SD individuellement avec sa propre ip et son hostname, on configurera de manière centralisé le serveur DHCP.

Exemple :
    Adresse MAC envoyée au serveur DHCP: b8 27 eb c6 3f 77
    Adresse IP retournée par le DHCP: 192.168.0.105
    Hostname assigné: node05

PAS à PAS

Si rien n'est dit c'est qu'il faut faire la même chose avec Raspberian et avec CentOS.

a) Désactiver ipv6
Ajouter disable_ipv6=1 à la fin de l'unique ligne de /boot/cmdline.txt
et/ou ajouter au fichier /etc/sysctl.conf la ligne
net.ipv6.conf.all.disable_ipv6=1

b) Mettre à jour /etc/hosts

(on en profite pour enlever tout ce qui concerne ipv6)

> cat /etc/hosts

127.0.0.1       localhost
 
192.168.0.101   node01
192.168.0.102   node02
192.168.0.103   node03
 ...
192.168.0.115   node15

c) Configuration du daemon client dhcpcd (Raspbian)
Son vrai nom est dhcpcd5 bien que ce soit la version 6 !

> cat /etc/dhcpcd.conf

# debug
ipv4only
noarp
option domain_name_servers, domains_name
nohook lookup-hostname, hostname

TOUT le reste doit être supprimé ou mis en commentaire avec #

Pour CentOS rien à faire (le fichier /etc/dhcpcd.conf n'existe pas) et le client s’appelle dhclient.


d) interfaces (Raspbian)


cat /etc/network/interfaces

auto  lo eth0
iface lo   inet loopback
iface eth0 inet manual

Même si c’est dhcpcd qui configurera l’interface eth0 il ne faut pas utiliser ‘dhcp’ mais ‘manual’.

Pour CentOS toujours rien à faire, eth0 est par défaut configurée par dhcp.

e) Attribution du hostname (Raspbian)

Dans le répertoire /lib/dhcpcd/dhcpcd-hooks créer le fichier 99-set-hostname

cat /lib/dhcpcd-hooks/99-set-hostname

get_hostname()
{
    [ -z "$new_ip_address" ] && return 1
    local h="$(/usr/bin/getent hosts $new_ip_address)"
    if [ $? = 0 ]; then
        echo "$h" | sed 's/[^ ]* *\([^ ]*\).*/\1/'
        return 0
    fi
    return 1
}

if $if_up ; then
    if [ -z "$new_host_name" -a -z "$new_fqdn_name" ]; then
        export new_host_name="$(get_hostname)"
        hostname $new_host_name
    fi
fi

Ce script utilise l'adresse ip assignée par le serveur DHCP pour trouver le hostname dans le fichier /etc/hosts et l'assigner au système. (c'est du reverse DNS sans DNS)

Note: dans ce même répertoire les deux scripts 29-loopup-hostname et 30-hostname ont été désactivés dans /etc/dhcpcd.conf par la commande :

nohook lookup-hostname, hostname

e) Attribution du hostname (CentOS 7.x)

A chaque changement dans la config réseau le NetworkManager exécute les scripts qui sont dans /etc/NetworkManager/dispatcher.d Dans ce répertoire il y a déjà le script 11-dhclient qui source  les scripts xxxx.sh qui sont dans  le répertoire /etc/dhcp/dhclient.d et invoque la fonction xxxx_config quand interface devient  ‘up’, ou xxxx_restore quand une interface passe ‘down’. Les variables d’environnement donnant les info sur l’interface concernée (ip, netmask, gateway ..)
On va donc mettre notre script sethostname.sh dans /etc/dhcp/dhclient.d

cat /etc/dhcp/dhclient.d/sethostname.sh

function sethostname_config {
  local ip_addr=127.0.0.1
  if [ -n "$IP4_ADDRESS_0" ]; then
    ip_addr="$(echo "$IP4_ADDRESS_0" | /usr/bin/cut -d'/' -f1)"
  else
    ip_addr=$DHCP4_IP_ADDRESS
  fi
  local h="$(/usr/bin/getent hosts $ip_addr)"
  if [ $? = 0 ]; then
    export new_hostname=$(echo "$h" | /usr/bin/awk '{print $2}')
    /usr/bin/hostnamectl --static set-hostname $new_hostname
    echo "Set my hostname to '$new_hostname' "
  else
    echo "ERROR: Cannot find $ip_addr in /etc/hosts"
  fi
}

function sethostname_restore {
  : # nothing todo

}

Note: Suivant la version du client dhcp ce sont les variables $IP4_* ou $DHCP4_* qui sont utilisées. D'où le test en début de script pour initialiser $ip_addr. Si le nom de host est 'localhost' c'est que aucune des deux variables n'existe, ou que le fichier /etc/hosts n'est pas à jour.

Ne pas oublier:

chmod +x /etc/dhcp/dhclient.d/sethostname.sh


f) Configurer le serveur DHCP
Se loguer sur chaque Raspberry Pi 2 pour noter l’adresse MAC de son interface Ethernet. Le plus simple est de faire cela via la console (HDMI/clavier usb), sans câble réseau. Ne pas être connecter au réseau évitera des problèmes de cache DHCP.

Une fois connecté à la console du Raspberry taper la commande :

cat /sys/class/net/eth0/address


Note : L’adresse MAC (Media Access Control Address) est constituée de 6 octets. Les 3 octets de poids fort dépendent du fabriquant. Pour Raspberry ces 3 octets sont toujours : b8 27 eb. Les 3 octets de poids faible identifient l’interface. Dans le cas des RPi ce sont les 3 octets de poids faible du numéro de série que l’on peut voir avec la commande : cat /proc/cpuinfo. 

Pour chaque adresse MAC ajouter une entrée dans la configuration du serveur DHCP. (voir la doc de cotre serveur DHCP. Exemple ci-contre)

La routine à répéter 15 fois est donc :
- se loger a un Raspberry en console et sans câble réseau
- noter l'adresse mac afficher par cat /sys/class/net/eth0/address
- mettre à jour le serveur DHCP (adresse mac, adresse ip)
- brancher le réseau
- rebooter le RPi (alt-ctrl-del)
- Au boot on doit avoir l'IP et le hostname voulus.
- shutdown
- deplacer la carte micro-sd au raspberry suivant
répéter...


Patience, ne dupliquez pas encore cette carte.
A SUIVRE...

Customisation

Le but est de créer une carte micro-SD master qui sera dupliquée en 15 exemplaires et sera installée sur chaque Raspberry du cluster. Le point de départ est l’une des images « Raspbian Jessie » ou CentOS 7 pour armv7hl. On crée une micro-SD master en se basant sur les instructions données par les liens précédant, puis on customise pour nos besoins de programmation parallèle en cluster.
Dans le cas de CentOS l'installation de depart est minimale, on ajoutera des packages. Dans le cas de Raspbian l'installation de départ est très complète, on enlèvera beaucoup de packages puis on en ajoutera.

1. L’adresse MAC de la carte Ethernet du Raspberry jouant un rôle important dans l’auto configuration on va modifier le fichier .bash_profile de 'root' (pour CentOS) ou de 'pi' pour Raspbian afin d'afficher cette adresse MAC au login.
   
   echo My MAC address is $(cat /sys/class/net/eth0/address)
    
2. On effectua plusieurs modifications pour qu’au boot chaque Raspberry PI 2 se configure automatiquement avec sa propre adresse IP et son propre nom sans que cette ip et ce nom ne soient hardcodé sur la carte. ⇒ Auto Configuration
    
3. Pour Raspbian supprimer tous les packages inutiles pour nous, principalement ceux liés au multimédia, à XWindow/X11 et libérer ainsi plus de 1Go de place sur la carte micro-SD.
    
4. Installer, enfin, les packages spécifiques à la programmation parallèle en cluster.
   
5. Installation de nos propres outils de gestion du cluster.

Le résultat est la carte micro-SD master qui sera dupliquée et installée dans chaque nœud du cluster.

Montage en images

Voici en quelques images les principales étapes du montage dans son boitier du cluster de Raspberry Pi 2.


1: De chaque coté du boitier percer les 4 trous pour la ligne de RPi du haut, les 4 trous pour la ligne  de RPi du bas, les 4 trous pour la fixation du switch. Pour pouvoir passer les tiges filetées dans les trous des circuits imprimés des Raspberry il faut les agrandir légèrement avec une mèche bois de 3mm.

2: Découper à la bonne longueur et passer les tiges filetées (3mm)
Fixer le switch. (Le switch n'est pas traversé de part en part  ;-)

3: Enfiler les Raspberry.

Pour maintenir un écartement constant, et éviter les contacts entre RPi, enfiler entre chaque RPi un tronçon de paille à boire.

4: Mettre en place l'alimentation 5 Volts.

 

6: Câbles USB-A / micro USB-B : Couper le coté USB-A.

7: Mettre en place les câbles (proprement)

8: Relier les câbles USB à l'alim, sans se tromper de sens: noir= -V (masse), rouge= +V (5 Volts) .
Ne pas relier les fils de data (blanc et vert).

Brancher.

Après c'est du logiciel.