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.