Nos últimos anos, os feeds de notícias inundaram mensagens sobre um novo tipo de redes de computação distribuída que resolvem (ou melhor, tentam resolver) as mais diversas tarefas - tornar a cidade inteligente, salvar o mundo de violadores de direitos autorais ou vice-versa, transferir informações ou recursos secretamente, escapar de - sob o controle do estado em uma área específica. Independentemente da esfera, todos eles têm uma série de características comuns, devido ao fato de que o combustível para o seu crescimento foram algoritmos e técnicas que foram para as massas durante o recente boom de criptomoedas e tecnologias relacionadas. Provavelmente, todo terceiro artigo sobre recursos especializados naquela época no título tinha a palavra "blockchain" - a discussão de novas soluções de software e modelos econômicos por algum tempo se tornou a tendência dominante, contra a qual outras áreas de aplicação de sistemas de computação distribuídos foram relegadas para segundo plano.
Ao mesmo tempo, visionários e profissionais viram a essência principal do fenômeno: a computação distribuída em massa relacionada à construção de redes de um grande número de participantes díspares e heterogêneos alcançou um novo nível de desenvolvimento. É suficiente tirar da cabeça os tópicos exagerados e olhar para o assunto do outro lado: todas essas redes, montadas em enormes piscinas, que consistem em milhares de participantes heterogêneos isolados, não apareciam por conta própria. Os entusiastas do movimento de criptografia foram capazes de resolver de uma nova maneira os complexos problemas de sincronização de dados e a alocação de recursos e tarefas, o que tornou possível reunir uma massa semelhante de equipamentos e criar um novo ecossistema projetado para resolver um problema de alvo restrito.
Obviamente, isso não passou pelas equipes e comunidades envolvidas no desenvolvimento da computação distribuída gratuita, e novos projetos não demoraram a chegar.
No entanto, apesar de um aumento sério na quantidade de informações disponíveis sobre desenvolvimentos no campo de redes e equipamentos, os criadores de sistemas promissores terão que resolver problemas sérios.
O primeiro deles, por mais estranho que possa parecer, é o problema de escolher uma direção
A direção pode estar certa, pode levar a um beco sem saída - você não pode escapar dela, as entregas centralizadas de clarividentes para a comunidade de TI ainda estão atrasadas. Mas a escolha deve ser feita para não cair na armadilha tradicional de que a equipe ocupa um campo muito amplo e, desde o início, tenta criar outro projeto não especializado de computação distribuída com um perfil amplo. Parece que a frente do trabalho não é tão terrível; na maioria das vezes, você só precisa aplicar os desenvolvimentos existentes: unir os nós em uma rede, adaptar os algoritmos para determinar topologias, trocar dados e controlar sua consistência, introduzir métodos para classificar nós e encontrar consenso e, é claro, apenas crie sua própria linguagem de consulta e todo o ambiente de linguagem e computação. A idéia de um mecanismo universal é muito tentadora e aparece constantemente em uma esfera ou outra, mas um dos três resultados ainda é obtido: a solução criada acaba sendo na verdade um protótipo limitado com um monte de "ToDo" suspenso no backlog ou se torna um monstro incontrolável, pronto para arrastar qualquer um que toque no fétido "atoleiro de Turing", ou simplesmente morra com segurança pelo fato de que o cisne, o caranguejo e o lúcio, puxando em uma direção incompreensível, estão em pedaços.
Não repetiremos erros estúpidos e escolheremos uma direção que possua uma gama compreensível de tarefas e que seja adequada ao modelo de computação distribuído. Você pode entender as pessoas que estão tentando fazer tudo de uma vez - é claro, há muito por onde escolher. E muito parece extremamente interessante, tanto do ponto de vista de P&D e desenvolvimento, quanto do ponto de vista da economia. Usando uma rede distribuída, você pode:
- Treinar redes neurais
- Processar fluxos de sinal
- Calcular a estrutura da proteína
- Renderizar cenas em 3D
- Simular a hidrodinâmica
- Teste estratégias de negociação para bolsas de valores
Para não se deixar levar pela compilação de uma lista de coisas interessantes que se assemelham bem, escolheremos a renderização distribuída como nosso tópico adicional.
A renderização distribuída em si mesma, é claro, nunca é um fenômeno novo. os kits de ferramentas de renderização existentes há muito apoiam a distribuição de carga em diferentes máquinas, sem as quais seria bastante triste viver no século XXI. No entanto, você não deve pensar que o tópico foi direcionado para cima e para baixo e não há nada a fazer lá - consideraremos um problema urgente separado: criar uma ferramenta para criar uma rede de renderização.
A rede de renderização conosco é a união de nós que precisam executar tarefas de renderização, com nós que possuem recursos de computação gratuitos para lidar com a renderização. Os proprietários de recursos conectarão suas estações à rede de renderização para receber e executar tarefas de renderização usando um dos mecanismos de renderização suportados pela rede. Ao mesmo tempo, os provedores de tarefas trabalharão com a rede como uma nuvem que distribui recursos de forma independente, verifica a correção da execução e gerencia riscos e outros problemas.
Assim, consideraremos a criação de uma estrutura que deve suportar a integração com um conjunto de mecanismos de renderização populares e conter componentes que fornecem ferramentas para organizar uma rede de nós heterogêneos e controlar o fluxo de tarefas.
O modelo econômico da existência dessa rede não é de fundamental importância, portanto, para o inicial, adotaremos um esquema semelhante ao usado nos cálculos nas redes de criptomoedas - os consumidores de recursos enviarão tokens aos fornecedores que executam o trabalho de renderização. É muito mais interessante entender quais propriedades uma estrutura deve ter, para a qual consideraremos o cenário principal para a interação dos participantes da rede.
Existem três aspectos da interação em uma rede: um provedor de recursos, um provedor de tarefas e um operador de rede (também conhecido como centro de controle, rede, etc.) ao longo do texto.
O operador de rede fornece ao provedor de recursos um aplicativo cliente ou uma imagem do sistema operacional com um conjunto abrangente de software que ele instalará na máquina cujos recursos ele deseja fornecer e uma conta pessoal acessível via interface da web, permitindo que ele defina parâmetros de acesso ao recurso e controle remotamente seu servidor paisagem: controle os parâmetros do ferro, execute a configuração remota, reinicie.
Ao conectar um novo nó, o sistema de gerenciamento de rede analisa o equipamento e os parâmetros de acesso especificados, classifica-o, atribui uma determinada classificação e o coloca no registro de recursos. No futuro, para gerenciar riscos, os parâmetros de atividade do nó serão analisados e a classificação do nó será ajustada para garantir a estabilidade da rede. Ninguém ficará satisfeito se sua cena for enviada para renderização em cartões poderosos, mas muitas vezes superaquecidos?
Um usuário que precisa renderizar uma cena pode seguir duas maneiras: fazer upload da cena no repositório da rede via interface da web ou usar o plug-in para conectar seu pacote de simulação ou o renderizador instalado à rede. Nesse caso, um contrato inteligente é iniciado entre o usuário e a rede, cuja condição padrão para a conclusão é a geração do resultado do cálculo da cena pela rede. O usuário pode monitorar o progresso da tarefa e gerenciar seus parâmetros através da interface da web de sua conta pessoal.
A tarefa chega ao servidor, onde são analisados o volume da cena e o número de recursos solicitados pelo iniciador da tarefa, após o qual o volume total é decomposto em partes adaptadas para o cálculo do número e tipo de recursos alocados pela rede. A idéia geral é que a visualização possa ser dividida em muitas pequenas tarefas. Os mecanismos aproveitam isso distribuindo essas tarefas entre vários provedores de recursos. A maneira mais simples é renderizar pequenas partes de uma cena chamada segmentos. Quando cada segmento está pronto, a tarefa local é considerada concluída, o recurso prossegue para o próximo não resolvido.
Assim, para o renderizador, não há diferença, como tal, se os cálculos são executados em uma máquina ou em uma grade de muitas estações de computação separadas. A renderização distribuída simplesmente adiciona mais núcleos ao pool de recursos usados para a tarefa. Pela rede, ele recebe todos os dados necessários para renderizar um segmento, calcula-o, envia esse segmento de volta e prossegue para a próxima tarefa. Antes de entrar no pool geral da rede, cada segmento recebe um conjunto de meta-informações, o que permite que os nós em execução escolham as tarefas de computação mais adequadas para eles.
As tarefas de segmentação e distribuição de cálculos devem ser resolvidas não apenas do ponto de vista da otimização do tempo de execução, mas também do ponto de vista do uso otimizado de recursos e economia de energia, uma vez que a eficiência econômica da rede depende disso. No caso de uma decisão malsucedida, será mais conveniente ligá-lo ou desligá-lo para que não faça barulho nem desperdice eletricidade.
Mas voltando ao processo. Quando uma tarefa é recebida entre o pool e o nó, também é formado um contrato inteligente que é executado quando o resultado da tarefa é calculado corretamente. Com base nos resultados do contrato, o nó pode receber uma recompensa de uma forma ou de outra.
O centro de controle monitora o processo de conclusão da tarefa, coletando os resultados dos cálculos, enviando os incorretos para reprocessamento e classificando a fila, rastreando o prazo normativo da tarefa (para que não ocorra que o último segmento não seja colocado em operação por nenhum nó).
Os resultados do cálculo passam pelo estágio de composição, após o qual o usuário recebe os resultados da renderização e a rede pode receber uma recompensa.
Assim, a composição funcional da estrutura da paisagem, projetada para construir sistemas de renderização distribuídos, emerge:
- Painéis da Web
- Um conjunto de software para instalação em nós
- Por sistema de gerenciamento:
- Subsistema de controle de acesso
- O subsistema de decomposição das tarefas de renderização
- Subsistema de distribuição de tarefas
- Subsistema de composição
- Subsistema de gerenciamento de paisagem e topologia de servidor
- Subsistema de Registro e Auditoria
- Subsistema de Aprendizado Especialista
- API de descanso ou outra interface para desenvolvedores externos
O que você acha? Em que perguntas o tópico levanta e em quais respostas você está interessado?