Ces dernières années, les fils d'actualité ont été inondés de messages sur un nouveau type de réseaux informatiques distribués surgissant littéralement de nulle part, résolvant (ou plutôt essayant de résoudre) une grande variété de problèmes - rendre une ville intelligente, sauver le monde du droit d'auteur. contrevenants ou vice versa, transférant secrètement des informations ou des ressources, échappant au contrôle de l'État dans une zone ou une autre. Quel que soit le domaine, ils présentent tous un certain nombre de caractéristiques communes, du fait que le moteur de leur croissance a été les algorithmes et les techniques qui ont été rendus publics lors du récent boom des crypto-monnaies et des technologies associées. À cette époque, un article sur trois sur les ressources spécialisées contenait probablement le mot « blockchain » dans le titre - la discussion sur de nouvelles solutions logicielles et de nouveaux modèles économiques est devenue la tendance dominante pendant un certain temps, dans le contexte de laquelle d'autres domaines d'application des systèmes informatiques distribués ont été relégué au second plan.
Dans le même temps, visionnaires et professionnels ont vu l'essence principale du phénomène : l'informatique distribuée massive, associée à la construction de réseaux à partir d'un grand nombre d'acteurs disparates et hétérogènes, a atteint un nouveau niveau de développement. Il suffit de chasser les sujets à la mode et de regarder le sujet de l'autre côté : tous ces réseaux, constitués d'immenses pools, constitués de milliers de participants hétérogènes isolés, ne sont pas apparus d'eux-mêmes. Les passionnés du mouvement cryptographique ont pu résoudre d'une nouvelle manière des problèmes complexes de synchronisation des données et de répartition des ressources et des tâches, ce qui a permis de rassembler une masse similaire d'équipements et de créer un nouvel écosystème conçu pour résoudre un problème étroitement ciblé.
Bien entendu, cela n'a pas échappé aux équipes et aux communautés impliquées dans le développement de l'informatique distribuée libre, et de nouveaux projets ne se sont pas fait attendre.
Cependant, malgré l'augmentation significative du volume d'informations disponibles sur les développements dans le domaine de la construction de réseaux et du travail avec des équipements, les créateurs de systèmes prometteurs devront résoudre de sérieux problèmes.
Le premier d’entre eux, aussi étrange que cela puisse paraître, est le problème du choix d’une direction.
La direction peut être correcte, ou elle peut conduire à une impasse - il n'y a pas d'issue possible : l'approvisionnement centralisé en voyants de la communauté informatique est encore en retard. Mais le choix doit être fait de manière à ne pas tomber dans le piège traditionnel de l'équipe qui s'approprie un domaine trop large et tente de créer dès le départ un autre projet généraliste de calcul distribué, non spécialisé. Il semble que l'étendue du travail ne soit pas si effrayante, pour l'essentiel il suffit d'appliquer les développements existants : combiner des nœuds dans un réseau, adapter des algorithmes pour déterminer les topologies, échanger des données et surveiller leur cohérence, introduire des méthodes pour classer les nœuds et trouver consensus et, bien sûr, créez simplement votre propre langage de requête ainsi que l'ensemble du langage et de l'environnement informatique. L'idée d'un mécanisme universel est très tentante et surgit constamment dans un domaine ou un autre, mais le résultat final est toujours l'une des trois choses suivantes : la solution créée s'avère soit être un prototype limité avec un tas de « ToDos » suspendues " dans l'arriéré, ou il devient un monstre inutilisable prêt à entraîner quiconque touche le fétide " marais de Turing ", ou meurt simplement en toute sécurité du fait que le cygne, l'écrevisse et le brochet, qui tiraient le projet dans une direction incompréhensible, ils se sont simplement surmenés.
Ne répétons pas d'erreurs stupides et choisissons une direction qui comporte un éventail de tâches clair et qui est bien adaptée au modèle informatique distribué. Vous pouvez comprendre les gens qui essaient de tout faire en même temps - bien sûr, il y a beaucoup de choix. Et beaucoup de choses semblent extrêmement intéressantes, tant du point de vue de la R&D et du développement que du point de vue économique. En utilisant un réseau distribué, vous pouvez :
- Former les réseaux de neurones
- Traiter les flux de signaux
- Calculer la structure des protéines
- Rendre des scènes XNUMXD
- Simuler l'hydrodynamique
- Tester des stratégies de trading pour les bourses
Afin de ne pas nous laisser emporter par la compilation d'une liste de choses intéressantes et bien parallélisées, nous choisirons le rendu distribué comme sujet supplémentaire.
Le rendu distribué en lui-même n’a bien sûr rien de nouveau. Les boîtes à outils de rendu existantes prennent depuis longtemps en charge la répartition de la charge sur différentes machines ; sans cela, vivre au XXIe siècle serait plutôt triste. Cependant, il ne faut pas penser que le sujet a été largement couvert et qu'il n'y a rien à faire là-bas - nous examinerons un problème urgent distinct : créer un outil pour créer 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 disposant de ressources informatiques gratuites pour traiter le rendu. Les propriétaires de ressources connecteront 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 pris en charge par le réseau. Dans ce cas, les fournisseurs de tâches travailleront avec le réseau comme s'il s'agissait d'un cloud, distribuant indépendamment les ressources, surveillant l'exactitude de l'exécution, gérant les risques et autres problèmes.
Ainsi, nous envisagerons de créer un cadre qui devrait 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 de nœuds hétérogènes et gérer le flux de tâches.
Le modèle économique de l'existence d'un tel réseau n'a pas d'importance fondamentale, nous prendrons donc comme schéma initial un schéma similaire à celui utilisé dans les calculs dans les réseaux de crypto-monnaie - les consommateurs de la ressource enverront des jetons aux fournisseurs effectuant le travail de rendu. Il est beaucoup plus intéressant de comprendre quelles propriétés un framework doit avoir, pour lesquelles nous considérerons le scénario principal d'interaction entre les participants au réseau.
Il existe trois aspects de l'interaction dans le réseau : le fournisseur de ressources, le fournisseur de tâches et l'opérateur de réseau (c'est-à-dire centre de contrôle, réseau, etc. dans le texte).
L'opérateur de réseau met à disposition du fournisseur de ressources une application client ou une image du système d'exploitation avec un ensemble de logiciels déployés, qu'il installera sur la machine dont il souhaite mettre à disposition les ressources, et un compte personnel accessible via l'interface web, lui permettant de définir les paramètres d'accès à la ressource et gérer à distance son paysage serveur : contrôler les paramètres matériels, effectuer la configuration à distance, redémarrer.
Lorsqu'un nouveau nœud est connecté, le système de gestion de réseau analyse l'équipement et les paramètres d'accès spécifiés, le classe, lui attribue une certaine note et le place dans le registre des ressources. À l'avenir, afin de gérer le risque, les paramètres d'activité du nœud seront analysés et la notation du nœud sera ajustée pour assurer la stabilité du réseau. Personne ne sera content si sa scène est envoyée pour être rendue sur des cartes puissantes qui gèlent souvent en raison d'une surchauffe ?
Un utilisateur qui a besoin de restituer une scène peut procéder de deux manières : télécharger la scène sur un référentiel réseau via l'interface Web, ou utiliser un plugin pour connecter son package de modélisation ou son moteur de rendu installé au réseau. Dans ce cas, un contrat intelligent est initié entre l'utilisateur et le réseau, dont la condition standard de réalisation est la génération du résultat du calcul de scène par le réseau. L'utilisateur peut suivre le processus de réalisation d'une tâche et gérer ses paramètres via l'interface web de son compte personnel.
La tâche est envoyée au 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, après quoi le volume total est décomposé en parties adaptées pour le calcul du nombre et du type de ressources allouées par le réseau. . L’idée générale est que la visualisation peut être décomposée en plusieurs petites tâches. Les moteurs en profitent en répartissant ces tâches entre plusieurs fournisseurs de ressources. Le moyen le plus simple consiste à restituer 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 à la tâche en attente suivante.
Ainsi, peu importe pour le moteur de rendu que les calculs soient effectués sur une seule machine ou sur une grille de plusieurs stations de calcul individuelles. Le rendu distribué ajoute simplement plus de cœurs au pool de ressources utilisées pour une tâche. Grâce au réseau, il reçoit toutes les données nécessaires au rendu d'un segment, le calcule, renvoie ce segment et passe à la tâche suivante. Avant d'entrer dans le pool général du réseau, chaque segment reçoit un ensemble de métainformations qui permettent aux nœuds d'exécution de sélectionner les tâches informatiques les plus appropriées pour eux.
Les problèmes de segmentation et de répartition des calculs doivent être résolus non seulement du point de vue de l'optimisation du temps d'exécution, mais aussi du point de vue de l'utilisation optimale des ressources et de l'économie d'énergie, puisque l'efficacité économique du réseau en dépend. . Si la solution échoue, il serait plus judicieux d'installer un mineur sur le nœud ou de l'éteindre afin qu'il ne fasse pas de bruit et ne gaspille pas d'électricité.
Cependant, revenons au processus. Lorsqu'une tâche est reçue, un contrat intelligent est également formé entre le pool et le nœud, qui est exécuté lorsque le résultat de la tâche est correctement calculé. Sur la base des résultats de l'exécution du contrat, le nœud peut recevoir une récompense sous une forme ou une autre.
Le centre de contrôle contrôle le processus d'exécution de la tâche, collecte les résultats de calcul, envoie les résultats incorrects pour retraitement et classement dans la file d'attente, surveille le délai standard pour terminer la tâche (afin qu'il n'arrive pas que le dernier segment ne soit pas occupé par n’importe quel nœud).
Les résultats des calculs passent par l'étape de composition, après quoi l'utilisateur reçoit les résultats du rendu et le réseau peut recevoir une récompense.
Ainsi, la composition fonctionnelle d'un cadre paysager conçu pour construire des systèmes de rendu distribué émerge :
- Comptes d'utilisateurs personnels avec accès au Web
- Kit logiciel pour installation sur nœuds
- Par système de contrôle :
- Sous-système de contrôle d'accès
- Sous-système de décomposition des tâches de rendu
- Sous-système de répartition des tâches
- Sous-système de composition
- Sous-système de gestion du paysage serveur et de la topologie réseau
- Sous-système de journalisation et d'audit
- Sous-système expert en apprentissage
- API Rest ou autre interface pour les développeurs externes
Qu'en penses-tu? Quelles questions le sujet soulève-t-il et quelles réponses vous intéressent ?
Source: habr.com