Je pose quelques hypothèses sur le domaine junkyard computing (au vu de la biblio):

• on sait faire du stockage de fichier / serveur web / mail / whatever qui n'est pas du calcul sur du matos hétérogène et non-fiable, avec les problèmes de répartition de charge associés (exemple en stockage de fichier chez les CHATONS, Garage: https://garagehq.deuxfleurs.fr/blog/2022-introducing-garage/),
• on sait faire du calcul distribué sur du matos hétérogène en faisant tourner des VM de partout, mais ça consomme pas mal de CPU et de RAM,
• on sait faire du cluster de calcul sur smartphones homogènes, et on peut le faire en Wi-Fi pour un petit nombre d'appareils.

Je pose quelques hypothèses sur le cluster LIFE:

• on va récupérer un gros volume de matos,
• ce matos, en terme de ressources de calcul, est composé de serveurs, tours, laptop et smartphones, sans tris a priori ⇒ on a au moins 3 archi matérielles dans le cluster (x86_64, ARMHF/ARMV7 (ARM 32 bits), AARCH64 (ARM 64 bits)) voire 4 (si on a du i686 qui traîne).

Donc, ce que LIFE apporte par rapport à l'existant:

• faire du calcul sur ce matériel hétérogène sans empiler des couches d'abstractions,
• proposer du stockage sur du matériel non fiable,
• permettre à ces tâches (ainsi que des services de communication) de tourner sur une infrastructure énergétique intermittente,
• faire un POC avec un grand nombre de matériels (et pas juste 10 smartphones qui se battent dans une armoire),
• tout ça sans avoir racheté de matos neuf.

Quelques problèmes:

1. On ne peut pas, comme dans les papiers de Switzer, faire de l'exécution répartie en passant simplement un payload binaire à exécuter quelle que soit la machine.
2. La diversité des smartphones récupérés n'est pas maîtrisée, et on veut éviter l'obsolescence logicielle ⇒ tout les OS qui patchent le userspace pour rentrer dans un noyau downstream type LineageOS / UbuntuTouch / LuneOS sont out.
3. On ne peut pas décemment espérer faire causer plus d'une poignée de machine en Wi-Fi dans un espace restreint.
   1. on peut cloisonner sur des bandes de fréquences différentes (avec toutes les limites de l'exercice) ou alors distribuer spatialement à l'UPEC les devices

Quelques pistes de solutions:

1. Pour sortir de l'impasse du payload binaire:
   1. Privilégier l'exécution de codes en langage interprétés (Java, Python, …).
   2. Si on a des personnes qui veulent lancer un code compilé, 3 possibilités:
      • demander à avoir des binaires pour chaque plateforme du cluster (lourd côté utilisateur·rice),
      • si non, montrer l'hétérogénéité et restreindre l'exécution du binaire qu'à certaines parties du cluster (comme ce qui est fait pour les codes demandant des GPU),
      • ou encore, permettre de lancer le binaire en natif sur les machines qui vont bien, et via une VM sur les autres.
2. Pour gérer des smartphones hétérogènes sur le long cours
   1. Utiliser postmarketos, qui utilise un noyau mainline plutôt qu'un linux downstream.
   2. Pour la diversité des modèles, Ubuntu Touch annonce 28 téléphones supportés avec la dernière version, PostmarketOS v24.06 annonce le boot de 250 matériels (majoritairement des smartphones, après certains ne font que booter sans support de l'OTG / de la batterie par exemple).
3. Pour passer à l'échelle en terme d'échanges réseau
   1. Utiliser de l'éthernet switché → ça demande du matériel actif. (OM : on a un/autant de switchs Gb que l'on souhaite !) (GS: alors on n'a plus qu'à sourcer les adaptateurs OTG usb-C/micro-usb → RJ45 et ça le fait)
   2. Passer par une pyramide USB → moins efficace en terme de bande passante.
   3. Utiliser une approche hybride sans fils / filaire.

• Quel dimensionnement de l'installation énergétique ? (OM : question centrale qu'on va devoir adresser en analysant lors de la construction du cluster la qté d'énergie requise - idle/peak/average)
• S'il y a des noeuds de contrôle/coordination/maître, est-ce qu'ils sont choisis en statique (plus maîtrisé, notamment quand il faut éteindre une partie du cluster) ou dynamiquement/par élection (moins de configuration à faire, potentiellement plus adaptable à la topologie) ? (OM : à voir selon les contraintes énergétiques mais aussi de pannes)
• Quels sont les services/machines que l'on va estimer prioritaire quand il n'y aura pas assez d'énergie disponible ? (OM : c'est là où on entre dans le dur et le politique du projet : qui détermine quels services sont prioritaires)
• Comment gérer une partie du cluster qui tombe avec des tâches de calcul au long cours (typiquement un entraînement de réseau de neurone) ? (OM : des snapshots réguliers ou des outils au niveau de la FS comme des FS journalisées qui le font automagiquement)

• Boot2Container (car on peut imaginer que sur des serveurs on installe un hyperviseur et qu'on ait un lot de VM qui rendent des services - cela permet les choses habituelles de la virtualisation (factorisation/scalabilité/sauvegardes/taux d'usage qui peut atteindre 90%/…)) - regarder le programme des JRES'24 (vu cet outil là bas)
  
  • GS: intéressant, la fusion de cet initramfs avec un noyau pmOS tel quel devrait bien se faire (pas de problème de configuration noyau vis-à-vis de systemd par exemple); à voir aussi avec un noyau downstream, mais moins durable dans le temps.
• reproductibilité des environnements avec GUIX
  
  • GS: ou avec Nix ?

Rien à voir mais jeter un oeil à Wild Tech GS: done

Je vois deux possibilités :

1. du général purpose (via des VMs par exemple, ou bien des micro-services embarqués)
2. des tâches dédiées sur des données (un calcul demandé par un physicien par exemple - type HPC)
3. ???

Des idées de services à offrir qui ne sont pas fournis par la DSI :

• impression
• dépôt de fichiers audios et transcription avec l'outil NoScribe quand du temps de Cpu est disponible