Ces dernières années, les flux d'actualités ont été inondés de messages sur un nouveau type de réseaux informatiques distribués qui résolvent (ou plutôt tentent de résoudre) les tâches les plus diverses - rendre la ville intelligente, sauver le monde des contrevenants au droit d'auteur, ou vice versa, transférer secrètement des informations ou des ressources, échapper à - sous le contrôle de l'État dans une zone particulière. Quelle que soit la sphère, ils ont 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é transmis aux masses lors du récent boom des crypto-monnaies et des technologies connexes. Probablement, chaque troisième article sur les ressources spécialisées à cette époque dans le titre avait le mot "blockchain" - la discussion des nouvelles solutions logicielles et des modèles économiques est devenue pendant un certain temps la tendance dominante, contre laquelle d'autres domaines d'application des systèmes informatiques distribués ont été relégués à l'arrière-plan.
Dans le même temps, les visionnaires et les professionnels ont vu l'essence principale du phénomène: l'informatique distribuée de masse associée à la construction de réseaux d'un grand nombre de participants disparates et hétérogènes a atteint un nouveau niveau de développement. Il suffit de jeter des sujets de battage médiatique hors de votre tête et de regarder le sujet de l'autre côté: tous ces réseaux, assemblés à partir d'énormes pools, qui se composent de milliers de participants hétérogènes isolés, ne sont pas apparus seuls. Les amateurs de mouvements cryptographiques ont pu résoudre d'une manière nouvelle les problèmes complexes de synchronisation des données et d'allocation des ressources et des tâches, ce qui nous 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 sûr, cela n'a pas passé par les équipes et les communautés impliquées dans le développement de l'informatique distribuée gratuite, et de nouveaux projets ne se sont pas fait attendre.
Cependant, malgré une sérieuse augmentation de la quantité d'informations disponibles sur les développements dans le domaine des réseaux et des équipements, les créateurs de systèmes prometteurs devront résoudre de graves 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, elle peut conduire à une impasse - vous ne pouvez pas y échapper, les livraisons centralisées de voyants à la communauté informatique sont encore en retard. Mais le choix doit être fait pour ne pas tomber dans le piège traditionnel que l'équipe prend un champ trop large et tente dès le départ de créer un autre projet non spécialisé d'informatique distribuée avec un large profil. Il semble que le front du travail ne soit pas si terrible, pour la plupart, il suffit d'appliquer les développements existants: unir les nœuds dans un réseau, adapter les algorithmes pour déterminer les topologies, échanger des données et contrôler leur cohérence, introduire des méthodes pour classer les nœuds et trouver un consensus, et, bien sûr, juste créez votre propre langage de requête et l'ensemble du langage et de l'environnement informatique. L'idée d'un mécanisme universel est très tentante et apparaît constamment dans une sphère ou une autre, mais la sortie se révèle toujours être l'une des trois: la solution créée se révèle être en fait un prototype limité avec un tas de «ToDo» suspendus dans le carnet de commandes, ou elle devient un monstre ingérable, prêt à glisser quiconque touche le fétide «bourbier de Turing», ou meurt simplement en toute sécurité du fait que le cygne, le crabe et le brochet, tirant dans une direction incompréhensible, sont déchirés.
Nous ne répéterons pas des erreurs stupides et choisirons une direction qui a une gamme de tâches compréhensible 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 semble extrêmement intéressant tant du point de vue de la R&D et du développement que du point de vue de l'économie. En utilisant un réseau distribué, vous pouvez:
- Former des réseaux de neurones
- Flux de signaux de processus
- Calculer la structure des protéines
- Rendre des scènes 3D
- Simuler l'hydrodynamique
- Tester les stratégies de trading pour les bourses
Afin de ne pas nous laisser emporter par la compilation d'une liste de choses intéressantes qui se marient bien, nous choisirons le rendu distribué comme autre sujet.
Le rendu distribué en soi n'est bien sûr jamais un phénomène nouveau. Les boîtes à outils de rendu existantes ont longtemps soutenu la répartition de la charge sur différentes machines, sans lesquelles il serait plutôt triste de vivre au XXIe siècle. Cependant, vous ne devriez pas penser que le sujet a été poussé de haut en bas, et il n'y a rien à faire là -bas - nous considérerons un problème urgent distinct: créer un outil pour créer un réseau de rendu.
Le réseau de rendu avec nous est l'union des nœuds qui doivent effectuer des tâches de rendu, avec des nœuds qui disposent de ressources informatiques gratuites pour gérer le rendu. Les propriétaires de ressources connecteront leurs stations au réseau de rendu afin de recevoir et d'exécuter des travaux de rendu à l'aide de l'un des moteurs de rendu pris en charge par le réseau. Dans le même temps, les fournisseurs de tâches travailleront avec le réseau comme un cloud qui distribue indépendamment les ressources, vérifie l'exactitude de l'exécution et gère les risques et autres problèmes.
Ainsi, nous envisagerons la création d'un cadre qui devrait prendre en charge l'intégration avec un ensemble de moteurs de rendu populaires et contenir des composants qui fournissent des outils pour organiser un réseau de nœuds hétérogènes et contrôler le flux des tâches.
Le modèle économique de l'existence d'un tel réseau n'a pas une importance fondamentale, par conséquent, pour le premier, nous prendrons un schéma similaire à celui utilisé dans les calculs dans les réseaux de crypto-monnaie - les consommateurs de ressources enverront des jetons aux fournisseurs qui effectuent le travail de rendu. Il est beaucoup plus intéressant de comprendre quelles propriétés un framework devrait avoir, pour lesquelles nous considérerons le scénario principal pour l'interaction des participants du réseau.
Il y a trois aspects de l'interaction dans un réseau: un fournisseur de ressources, un fournisseur de tâches et un opérateur de réseau (alias un centre de contrôle, un réseau, etc. tout au long du texte).
L'opérateur de réseau fournit au fournisseur de ressources une application client ou une image de système d'exploitation avec un ensemble complet de logiciels qu'il installera sur la machine dont il veut fournir 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 de contrôler à distance son serveur paysage: contrôler les paramètres du fer, effectuer la configuration à distance, redémarrer.
Lors de la connexion d'un nouveau nœud, le système de gestion de réseau analyse l'équipement et les paramètres d'accès spécifiés, le classe, attribue une certaine note et le place dans le registre des ressources. À l'avenir, afin de gérer les risques, les paramètres d'activité du nœud seront analysés et la note 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 mais souvent surchauffées?
Un utilisateur qui doit rendre une scène peut procéder de deux manières: télécharger la scène dans le référentiel réseau via l'interface Web ou utiliser le plug-in pour connecter son package de simulation ou le 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 pour l'achèvement est la génération du résultat du calcul de scène par le réseau. L'utilisateur peut suivre l'avancement de la tâche et gérer ses paramètres via l'interface web de son compte personnel.
La tâche arrive sur le 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 de nombreuses petites tâches. Les moteurs en profitent en répartissant ces tâches entre plusieurs fournisseurs de ressources. Le moyen le plus simple consiste à rendre de petites parties d'une scène appelées segments. Lorsque chaque segment est prêt, la tâche locale est considérée comme terminée, la ressource passe à la suivante non résolue.
Ainsi, pour le moteur de rendu, il n'y a pas de différence en tant que telle, que les calculs soient effectués sur une machine ou sur une grille à partir de nombreuses stations de calcul distinctes. Le rendu distribué ajoute simplement plus de cœurs au pool de ressources utilisé pour la tâche. Par le biais du 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éta-informations, qui permet aux nœuds d'exécution de choisir les tâches informatiques les plus adaptées pour eux.
Les tâches de segmentation et de distribution des calculs doivent être résolues 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 des économies d'énergie, car l'efficacité économique du réseau en dépend. En cas de décision infructueuse, il sera plus judicieux d'allumer ou d'éteindre le mineur afin qu'il ne fasse pas de bruit et ne gaspille pas d'électricité.
Mais revenons au processus. Lorsqu'une tâche est reçue entre le pool et le nœud, un contrat intelligent est également formé qui est exécuté lorsque le résultat de la tâche est correctement calculé. Sur la base des résultats du contrat, le nœud peut recevoir une récompense sous une forme ou une autre.
Le centre de contrôle surveille le processus de réalisation de la tâche, collecte les résultats des calculs, envoie les mauvais pour le retraitement et le classement de la file d'attente, le suivi de l'échéance normative de la tâche (afin qu'il ne se produise pas que le dernier segment n'est mis en service par aucun nœud).
Les résultats du calcul 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 du framework paysage, conçu pour construire des systèmes de rendu distribués, émerge:
- Tableaux de bord Web
- Un ensemble de logiciels pour l'installation sur les nœuds
- Par système de gestion:
- Sous-système de contrôle d'accès
- Le sous-système de décomposition des tâches de rendu
- Sous-système de distribution des tâches
- Sous-système de composition
- Paysage du serveur et sous-système de gestion de la topologie du 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 soulève le sujet et quelles réponses vous intéressent?