Outils open source existants pour le Scheduler / ordonnanceur

Nous avons identifié au travers de l’analyse système qu’un certain nombre de fonctions vont être portées par un « Scheduler » (ordonnanceur) au sein de Phoenix.

Elles incluent notamment, d’un point de vue informatique, l’identification des ressources disponibles (stockage et capacité de calcul), la mise en oeuvre du composant logiciel (conteneur) sur ces ressources, et la réception amont puis la transmission aval des données.

Petit compte-rendu de recherche sur des outils existants open source :

  • mise en oeuvre du conteneur et équilibrage de charge : Kubernetes, le standard de fait pour la gestion des conteneurs dans l’IT « terrestre », constitue clairement le point d’entrée sur le sujet. Il permet notamment de gérer la « topologie » des noeuds, pour prendre en compte leur localisation et contraintes réseau, et on peut très bien imaginer qu’il puisse aussi être « conscient » des contraintes des opérations inter-satellites / noeuds du système.
  • je comprends qu’on pourrait même aller un niveau au-dessus avec un outil comme Fission, qui permet de gérer des fonctions au-dessus d’un cluster Kubernetes, et simplifierai encore l’utilisation du cloud Phoenix.
  • concernant la réception des données, on peut s’inspirer de la façon dont fonctionne SatNOGS. Dans la liste des projets open source recensés par l’initiative OpenSatCom, on trouve aussi un bon nombre de solutions de Software Defined Radio (SDR), dont certaines dédiées aux communications satellites, qui disposent probablement de leur système d’ordonnancement et de priorisation des trames.

Bon voilà un petit point de départ avant d’aller plus en profondeur, c’est aussi fait pour être challengé et analysé en détails !

1 « J'aime »

Perso j’aurais seulement un peit commentaire sur Kubernetes, à niveau securité je pense que l’approche OpenShift est plus raissonable en ce moment. Ça limite ce que tu peux faire avec les conteneurs Docker et je pense que c’est une bonne chose (https://en.wikipedia.org/wiki/Principle_of_least_privilege)

Sachant que OpenShift dit se baser sur Kubernetes, peux-tu @tid préciser ta pensée ?

Par ailleurs, nous n’allons probablement pas utilisé Kubernetes lui-même. Ici, nous indiquons seulement étudier ces outils pour comprendre et affiner les fonctionnalités attendues par Phoenix.

Simplemente l’approche de OpenShift de limiter ce que tu peux faire avec un containeur (pas de root ou de uid/guid specifique) is the way to go par rapport « à la liberté » de K8s.

Après probablement mes réflexions n’ont pas grand chose à voir avec l’esprit de ce thread, du coup je m’excuse pour avoir épandu le sujet sans nécessité.

Au contraire @tid, c’est maintenant qu’il faut brainstormer donc pas de problème pour partir tout azimut !

Au final, vu les contraintes énergétiques des satellites, je doute fort que l’on puisse prendre telle quelle une techno du cloud terrestre et simplement le déployer. Mais l’idée est bien de recenser l’ensemble des contraintes, description, mode de fonctionnement, etc pour ne pas réinventer la roue.

Pour le pas de côté : Software Container Technology