Communication réseau de Flower

Cette référence complète l’explication du Flower Architecture en détaillant les connexions réseau utilisées dans un système Flower d’IA collaborative déployé.

Note

Optionnellement, un troisième lien vers un service tiers peut être établi pour fournir une authentification utilisateur via OIDC. Cela signifie que seuls les utilisateurs authentifiés via flwr login peuvent interagir avec le contrôFlower.

Subprocess Mode Process Mode

Astuce

Cliquez sur les boutons ci-dessus pour basculer entre les diagrammes de réseau pour les modes d’isolement subprocess et process.

Connexions réseau obligatoires

Les systèmes Flower déployés ont au moins deux types de connexions réseau :

• CLI vers SuperLink (Control API) : la commande CLI flwr, généralement exécutée sur le poste de travail de l’utilisateur, sert à interagir avec une fédération Flower déployée composée de SuperLink et de SuperNodes. Du point de vue réseau, la CLI flwr agit comme un client gRPC et SuperLink agit comme un serveur gRPC. La CLI flwr est le seul moyen pour un utilisateur (chercheur en IA ou data scientist) d’interagir avec une fédération Flower déployée. Il ne peut pas, par exemple, interagir directement avec les SuperNodes connectés au SuperLink. La connexion de la CLI flwr à SuperLink doit toujours utiliser TLS, mais le mode insecure est pris en charge pour les tests locaux.

• SuperNode vers SuperLink (Fleet API) : dans la terminologie Flower, une fédération Flower est un ensemble de SuperNodes connectés au même SuperLink. Du point de vue réseau, chaque SuperNode agit comme un client gRPC et SuperLink agit comme un serveur gRPC. Cela signifie que, lors du déploiement d’un SuperNode, seules des connexions sortantes sont nécessaires pour se connecter au SuperLink. Seuls les SuperNodes peuvent initier ces requêtes et ils ne répondent pas aux requêtes entrantes. La connexion de SuperNode à SuperLink doit toujours utiliser TLS (consultez Activer les connexions TLS pour en savoir plus), mais le mode insecure est pris en charge pour les tests locaux.

Connexions réseau facultatives

En fonction de la configuration SuperLink et SuperNode, les systèmes Flower peuvent avoir/employer un certain nombre supplémentaire de connexions réseau.

API des composants Flower

Tous les composants Flower — SuperLink, SuperNode, SuperExec, ServerApp processus et ClientApp processus — exposent des APIs pour interagir avec d’autres composants Flower. Le composant SuperLink comprend trois telles APIs : l’API ServerAppIo, l’API Fleet et l’API Control. De même, le composant SuperNode comprend l’API ClientAppIo. Chaque de ces APIs sert un but distinct lors du lancement d’une application Flower en utilisant la Deployment Runtime, comme résumé dans le tableau ci-dessous.

Component	Port par défaut	API	Purpose
SuperLink	9091	API ServerAppIo	Utilisé par les processus SuperExec et les processus ServerApp
	9092	Fleet API	Utilisé par les SuperNodes
	9093	Contrôle API	L’utilisateur interagit avec le SuperLink via cette API en utilisant le FlowerCLI
SuperNode	9094	API ClientAppIo	Utilisé par les processus SuperExec et ClientApp,

Note

Les APIs AppIo imposent la compatibilité de version d’exécution entre le serveur API et ses appelants. Par défaut, les requêtes provenant des appelants utilisant une version majeure mineure incompatibles sont rejetées avant que la communication AppIo ne se poursuive. Les appelants plus anciens sans métadonnées d’exécution sont actuellement acceptés par cette vérification de compatibilité pour des raisons de compatibilité ascendante. Gardez les composants d’exécution SuperLink, SuperNode, SuperExec, ServerApp et ClientApp sur des versions Flower compatibles.

Mode d’isolement

Les deux processus SuperLink et SuperNode peuvent fonctionner dans différents modes d’isolement. Le SuperExec est responsable de la planification, du lancement et de la gestion des processus d’applications, tels que le processus ServerApp et le processus ClientApp.

La configuration de mode d’isolement subprocess configure le SuperLink/SuperNode pour lancer automatiquement le SuperExec en tant que processus subprocessuel à l’exécution. Le mode d’isolement process, par contraste, s’attend à ce que le SuperExec fonctionne dans un processus externe géré séparément, de sorte que le SuperLink/SuperNode ne lancera pas automatiquement un tel processus. Cela permet, par exemple, d’exécuter les SuperLink/SuperNode et SuperExec dans des conteneurs Docker distincts avec des ensembles de dépendances différents, ou d’y exécuter sur différents serveurs au sein du même réseau. Consultez le guide Exécuter Flower à l’aide de Docker pour une compréhension plus approfondie de la façon dont utiliser les deux modes.

Lorsque vous utilisez le mode d’isolement process, des connexions réseau supplémentaires sont nécessaires pour permettre au processus externe exécutant le SuperExec, ServerApp ou ClientApp de communiquer avec le SuperLink ou SuperNode:

• SuperExec/ServerApp process to SuperLink (ServerAppIO API) : Les deux processus SuperExec pour ServerApps et les processus ServerApp agissent comme clients gRPC et se connectent à l’API ServerAppIO du SuperLink. Cette connexion permet au SuperExec de découvrir des exécutions à lancer et aux processus ServerApp de récupérer les entrées nécessaires pour exécuter le ServerApp. Cela permet également aux processus ServerApp, une fois en cours d’exécution, de faire des choses typiques comme envoyer/recevoir des messages vers/à partir des SuperNodes disponibles (via le SuperLink).

• SuperExec/ClientApp process to SuperNode (ClientAppIO API) : Les deux processus SuperExec pour ClientApps et les processus ClientApp agissent comme clients gRPC et se connectent à l’API ClientAppIO du SuperNode. Cette connexion permet au SuperExec de découvrir des exécutions à lancer et aux processus ClientApp de récupérer les détails nécessaires (par exemple, fichier FAB) pour exécuter le ClientApp, exécuter le ClientApp (par exemple, entraînement local du modèle), et renvoyer les résultats d’exécution (par exemple, mise à jour locale des paramètres de modèle) au SuperNode.

Note

Les liens AppIo ci-dessus peuvent fonctionner avec une communication en clair ou avec un TLS authentifié par le serveur. Sans les options --appio-ssl-*, ces liens restent non chiffrés et devraient rester à l’intérieur d’un réseau de confiance:

• Processus SuperLink + SuperExec + ServerApp

• Processus SuperNode + SuperExec + ClientApp

Pour sécuriser ces liens, configurez les serveurs ServerAppIo et ClientAppIo API avec --appio-ssl-certfile, --appio-ssl-keyfile, et --appio-ssl-ca-certfile. Les clients AppIo vérifient les certificats de serveur avec --root-certificates. Dans le mode d’isolement subprocess, le SuperLink et SuperNode passent la voie CA au processus SuperExec qu’ils lancent. Cela n’est pas mTLS. Consultez Activer les connexions TLS pour des commandes concretes.

Avertissement

Lorsqu’il est lancé sans TLS, chaque groupe doit rester dans un réseau de confiance unique. Ils ne devraient jamais communiquer entre eux sur des réseaux non fiables (par exemple, Internet public).

Authentification de compte

Lorsque l’authentification de compte est activée, Flower utilise un serveur compatible OIDC pour authentifier les requêtes :

• SuperLink vers le serveur OIDC : Un SuperLink peut être configuré pour ne permettre que des utilisateurs authentifiés d’y interagir. Dans ce cas, le SuperLink Flower agit comme client REST vers le serveur OIDC compatible.

Connexions spécifiques à l’application

Les utilisateurs qui créent des applications Flower (ServerApp et ClientApp) peuvent également effectuer des requêtes réseau supplémentaires. Cela ne fait pas partie intégrante de la plateforme d’intelligence artificielle fédérée, Flower, en tant que décision (a) du utilisateur sur les types de systèmes tiers auxquels leur application Flower doit se connecter et (b) de l’administrateur système sur les types de connexions qu’ils souhaitent autoriser.

Exemples typiques incluent :

• ClientApp vers la base de données : Les instances ClientApp ont généralement besoin d’accéder aux données pour effectuer l’action pour laquelle elles ont été conçues (par exemple, entraîner localement un modèle, exécuter une requête DB). La manière dont cette connexion est établie dépend de la technologie de stockage utilisée côté client. Notez que dans le diagramme ci-dessus, nous montrons deux représentations de connexions à des bases de données sur les clients A et B. Votre(s) connexion(s) vers la base de données peut(ont) probablement différer de l’illustration ci-dessus.

• ServerApp vers la base de données : Les instances ServerApp peuvent souhaiter accéder aux données pour effectuer l’action pour laquelle elles ont été conçues (par exemple, évaluer un modèle sur des données après agrégation). La manière dont cette connexion est établie dépend de la technologie de stockage utilisée côté client. Notez que dans le diagramme ci-dessus, nous avons omis de montrer une base de données connectée aux composants ServerApp.

• ServerApp vers le service de journalisation de métrique : Les services de journalisation de métrique tels que TensorBoard, MLFlow et Weights & Biases sont souvent utilisés pour suivre les progrès des exécutions d’entraînement. Dans ce cas, le ServerApp agit généralement comme client vers le service de journalisation de métrique.

Modèle de communication

Lors du déploiement réel, le modèle de communication push/pull adopté par chaque composant peut influencer les décisions relatives à la provisionnement des ressources, l’échelle, le suivi et la fiabilité. Pour soutenir ces décisions, la liste ci-dessous détaille le modèle de communication utilisé entre les composants Flower :

• SuperLink ⇌ SuperNode (Fleet API) : Le SuperNode récupère/pousse des Messages vers/à partir du SuperLink via l’API Fleet. Le SuperNode récupère également le FAB si une nouvelle exécution est en cours.

• SuperLink ⇌ ServerApp (ServerAppIo API) : Les processus ServerApp récupèrent/poussent des Messages vers/à partir du SuperLink via l’API ServerAppIO. Les processus ServerApp récupèrent également le FAB lors de la première interaction avec le SuperLink, et à la fin de l’exécution ils poussent le Context vers le SuperLink.

• SuperNode ⇌ ClientApp (ClientAppIo API) : Les processus ClientApp récupèrent/poussent des Messages vers/à partir du SuperNode via l’API ClientAppIO. Les processus ClientApp récupèrent également le FAB lors de la première interaction avec le SuperNode, et à la fin de l’exécution ils poussent le Context vers le SuperNode.