Ces dernières années, les fils d'actualité ont été inondés de messages sur l'émergence, littéralement de nulle part, de nouveaux types de réseaux de calcul distribué, cherchant (ou plutôt essayant de résoudre) une variété de problèmes : rendre les villes intelligentes, sauver le monde des violations de droits d'auteur ou, au contraire, transmettre secrètement des informations ou des ressources, échapper au contrôle de l'État dans divers domaines. Quelles que soient les sphères, toutes partagent un certain nombre de caractéristiques communes, résultant du fait que les algorithmes et méthodes qui ont alimenté leur croissance se sont largement diffusés lors du récent boom des cryptomonnaies et des technologies qui y sont associées. Probablement un article sur trois sur les ressources spécialisées à l'époque contenait le mot « blockchain » dans le titre — la discussion des nouvelles solutions logicielles et des modèles économiques est devenue pendant un certain temps la tendance dominante, reléguant d'autres domaines d'application des systèmes de calcul distribué au second plan.
En même temps, les visionnaires et les professionnels ont vu l'essence même du phénomène : le calcul distribué de masse, lié à la construction de réseaux composés d'un grand nombre de participants disparates et hétérogènes, a atteint un nouveau niveau de développement. Il suffit de mettre de côté les thèmes à la mode et de considérer le sujet sous un autre angle : tous ces réseaux, constitués de vastes pools contenant des milliers de participants isolés et variés, n'ont pas émergé d'eux-mêmes. Les passionnés du mouvement crypto ont pu résoudre sous un nouvel angle les problèmes complexes de synchronisation de données et de distribution des ressources et des tâches, ce qui a permis de rassembler une telle masse d'équipements et de créer un nouvel écosystème destiné à résoudre une tâche spécifiquement ciblée.
Bien sûr, cela n'a pas échappé aux équipes et aux communautés engagées dans le développement des calculs distribués libres, et les nouveaux projets ne se sont pas fait attendre.
Cependant, malgré l'augmentation considérable du volume d'informations disponibles sur les avancées dans la construction de réseaux et le travail avec du matériel, les créateurs de systèmes prometteurs devront faire face à des problèmes sérieux.
Le premier d'entre eux, aussi étrange que cela puisse paraître, est le problème du choix de la direction.
L'orientation peut être juste ou mener à une impasse — il n'y a pas moyen d'y échapper, les livraisons centralisées de voyants à la communauté IT accusent un certain retard. Mais il faut faire un choix pour ne pas tomber dans le piège traditionnel, à savoir que l'équipe prend un domaine trop vaste et essaie dès le départ de créer un autre projet non spécialisé de calcul distribué à large spectre. Il semble que le champ d'action ne soit pas si menaçant, il suffit surtout d'appliquer les développements existants : relier les nœuds en réseau, adapter les algorithmes pour définir les topologies, échanger des données et contrôler leur cohérence, mettre en œuvre des méthodes de classement des nœuds et de recherche de consensus, et bien sûr, il suffit de créer son propre langage de requêtes et tout l'environnement linguistique et computationnel associé. L'idée d'un mécanisme universel est très séduisante et refait surface dans un domaine ou un autre, mais le résultat se résume toujours à l'une des trois options : la solution créée s'avère soit un prototype vraiment limité avec de nombreuses tâches en attente dans le backlog, soit un monstre inutilisable, prêt à engloutir quiconque s'y aventure dans un « marais de Turing » nauséabond, ou bien simplement meurt parce que ceux qui tiraient le projet dans une direction floue, tel un cygne, un crabe et un brochet, se sont tout bonnement épuisés.
Ne répétons pas les erreurs stupides et choisissons une orientation ayant un cercle de tâches clair et bien adaptée au modèle de calcul distribué. On peut comprendre ceux qui essaient de tout faire en même temps — il y a bien des choix. Et beaucoup de choses semblent extrêmement intéressantes tant du point de vue R&D et développement que du point de vue économique. Grâce à un réseau distribué, nous pouvons :
- Former des réseaux neuronaux
- Traiter des flux de signaux
- Calculer la structure des protéines
- Réaliser le rendu de scènes 3D
- Modéliser l'hydrodynamique
- Tester des stratégies commerciales pour les bourses
Pour ne pas se laisser emporter par la constitution d'une liste de choses intéressantes qui se parallélisent bien, choisissons comme notre thème ultérieur le rendu distribué.
Le rendu distribué n’est pas un phénomène nouveau en soi. Les kits d'outils de rendu existants prennent déjà en charge la répartition de la charge sur différentes machines, sans quoi il serait assez malheureux de vivre au XXIe siècle. Cependant, il ne faut pas penser que le sujet est épuisé et qu'il n'y a rien à explorer — nous allons aborder un problème spécifique et actuel : la création d'un outil pour la formation d'un réseau de rendu.
Notre réseau de rendu est une combinaison de nœuds qui doivent effectuer des tâches de rendu, avec des nœuds qui ont des ressources de calcul disponibles pour le traitement du rendu. Les propriétaires de ressources vont connecter leurs stations au réseau de rendu pour recevoir et exécuter des tâches de rendu à l'aide de l'un des moteurs de rendu supportés par le réseau. Les fournisseurs de tâches travailleront avec le réseau comme s'il s'agissait d'un cloud, se chargeant de la répartition des ressources, du contrôle de la conformité d'exécution, de la gestion des risques et d'autres problèmes.
Ainsi, nous allons examiner la création d'un cadre qui doit prendre en charge l'intégration avec un ensemble de moteurs de rendu populaires et contenir des composants fournissant des outils pour organiser un réseau composé de nœuds hétérogènes et gérer le flux des tâches.
Le modèle économique de l'existence d'un tel réseau n'est pas fondamentalement important, nous allons donc prendre pour base un schéma similaire à celui utilisé dans les calculs dans les réseaux de cryptomonnaie : les consommateurs de ressources enverront des jetons aux fournisseurs qui effectuent le travail de rendu. Il est plus intéressant de comprendre les propriétés que doit posséder le cadre, pour cela nous allons examiner le scénario principal d'interaction des participants au réseau.
Il existe trois parties en interaction dans le réseau : le fournisseur de ressources, le fournisseur de tâches et l'opérateur du réseau (aussi appelé centre de contrôle, réseau, etc. dans le texte).
L'opérateur de réseau fournit au fournisseur de ressources une application cliente ou une image du système d'exploitation avec un ensemble de logiciels préinstallés, que celui-ci installera sur la machine dont il souhaite fournir les ressources, accessible via un tableau de bord web qui lui permet de définir les paramètres d'accès aux ressources et de gérer à distance son paysage serveur : contrôler les paramètres matériels, effectuer des réglages à distance, redémarrer.
Le système de gestion de réseau, lors de la connexion d'un nouveau nœud, effectue une analyse de l'équipement et des paramètres d'accès définis, le classe en lui attribuant une certaine note et l'inscrit dans le registre des ressources. Par la suite, afin de gérer le risque, les paramètres d'activité du nœud seront analysés et la note du nœud sera ajustée pour garantir la stabilité du réseau. Personne ne serait ravi si sa scène était envoyée à rendre sur des cartes puissantes mais souvent bloquées à cause de surchauffe ?
L'utilisateur qui doit rendre une scène peut prendre deux chemins : soit télécharger la scène dans le dépôt du réseau via une interface web, soit connecter son paquet de modélisation ou son moteur de rendu installé au réseau à l'aide d'un plugin. Dans ce cas, un contrat intelligent est initié entre l'utilisateur et le réseau, avec pour condition de fin que le réseau génère le résultat du calcul de la scène. L'utilisateur peut suivre le processus d'exécution de la tâche et gérer ses paramètres via l'interface web de son espace personnel.
La tâche est envoyée à serveur, où le volume de la scène et le nombre de ressources demandées par l'initiateur de la tâche sont analysés, puis le volume total est décomposé en parties adaptées pour le calcul sur le nombre et le type de ressources dédiées par le réseau. L'idée générale est que la visualisation peut être divisée en de nombreuses petites tâches. Les moteurs tirent parti de cet avantage en répartissant ces tâches parmi de nombreux fournisseurs de ressources. La manière la plus simple consiste à effectuer le rendu de petites parties de la scène, appelées segments. Lorsque chaque segment est prêt, la tâche locale est considérée comme terminée, et la ressource passe à l'exécution de la suivante parmi les non-résolues.
Ainsi, pour le moteur de rendu, il n'y a pas de différence entre effectuer des calculs sur une seule machine ou sur un réseau composé de plusieurs stations de calcul distinctes. Le rendu distribué ajoute simplement plus de cœurs au pool de ressources utilisées pour la tâche. À travers le réseau, il reçoit toutes les données nécessaires pour rendre un segment, calcule celui-ci, renvoie le segment et passe à la tâche suivante. Avant d'entrer dans le pool commun du réseau, chaque segment reçoit un ensemble de métadonnées permettant aux nœuds exécutants de choisir les tâches de calcul qui leur conviennent le mieux.
Les tâches de segmentation et de distribution des calculs doivent être résolues non seulement en termes d'optimisation du temps d'exécution, mais aussi en termes d'utilisation optimale des ressources et d'économie d'énergie, car cela affecte l'efficacité économique du réseau. En cas de décision infructueuse, il serait plus judicieux de placer un mineur sur le nœud ou de l'éteindre pour qu'il ne fasse pas de bruit et ne consomme pas d'électricité.
Cependant, revenons au processus. Lors de la réception de la tâche, un contrat intelligent est également formé entre le pool et le nœud, qui s'exécute lorsque le résultat de la tâche est correctement calculé. À l'issue de l'exécution du contrat, le nœud peut recevoir une récompense sous une forme ou une autre.
Le centre de gestion contrôle le processus d'exécution des tâches, recueillant les résultats des calculs, renvoyant pour retraitement les informations incorrectes et classant la queue, tout en surveillant le délai normal d'exécution de la tâche (afin d'éviter que le dernier segment ne soit pris en charge par aucun nœud).
Les résultats des calculs passent par une étape de composition, après quoi l'utilisateur reçoit les résultats du rendu et le réseau peut obtenir une récompense.
Ainsi, se dessine la composition fonctionnelle du cadre paysager destiné à la construction de systèmes de rendu distribué :
- Tableaux de bord utilisateurs avec accès web
- Ensemble de logiciels pour installation sur les nœuds
- Concernant les systèmes de gestion :
- Sous-système de gestion des accès
- Sous-système de décomposition des tâches de rendu
- Sous-système de distribution des tâches
- Sous-système de composition
- Sous-système de gestion du paysage serveur et de la topologie du réseau
- Sous-système de journalisation et d'audit
- Sous-système expert auto-apprenant
- API REST ou autre interface pour les développeurs externes
Que pensez-vous ? Quelles questions soulève ce sujet et quelles réponses vous intéressent ?
Source : habr.com
