Nos últimos anos, as notícias foram inundadas com relatos de redes computacionais distribuídas de novo tipo, surgindo literalmente do nada, tentando resolver as mais diversas questões — tornar a cidade inteligente, salvar o mundo dos violadores de direitos autorais ou, ao contrário, transmitir informações ou recursos em segredo, escapando do controle estatal em diversas áreas. Independentemente do setor, todas elas compartilham uma série de características comuns, resultantes do fato de que os algoritmos e metodologias que alimentaram seu crescimento emergiram durante o recente boom das criptomoedas e das tecnologias relacionadas. Provavelmente, um em cada três artigos em recursos especializados na época tinha a palavra "blockchain" no título — a discussão sobre novas soluções de software e modelos econômicos tornou-se uma tendência dominante, em meio à qual outras áreas de aplicação de sistemas de computação distribuída foram colocadas em segundo plano.
Ao mesmo tempo, visionários e profissionais perceberam a essência do fenômeno: a computação distribuída em massa, relacionada à construção de redes compostas por um grande número de participantes diversos e desconectados, atingiu um novo nível de desenvolvimento. Basta afastar da mente as questões de hype e olhar para o assunto de outro ângulo: todas essas redes, formadas por enormes pools que consistem em milhares de participantes isolados e heterogêneos, não surgiram por conta própria. Entusiastas do movimento cripto conseguiram resolver, de uma nova maneira, problemas complexos de sincronização de dados e distribuição de recursos e tarefas, o que permitiu reunir tal massa de equipamentos e criar um novo ecossistema destinado a resolver uma tarefa específica.
É claro que isso não passou despercebido por equipes e comunidades dedicadas ao desenvolvimento da computação distribuída livre, e novos projetos não tardaram a aparecer.
No entanto, apesar do aumento significativo de informações disponíveis sobre o desenvolvimento de redes e o trabalho com equipamentos, os criadores de sistemas promissores enfrentarão problemas sérios.
O primeiro deles, por mais estranho que possa parecer, é a questão da escolha da direção.
A direção pode estar certa ou levar a um beco sem saída — não há como escapar disso, as entregas centralizadas de videntes para a comunidade de TI ainda estão atrasadas. No entanto, é necessário fazer uma escolha para não cair na armadilha tradicional, que consiste em a equipe assumir um escopo muito amplo e tentar desde o início criar mais um projeto não especializado de computação distribuída de amplo espectro. Aparentemente, a superfície do trabalho não é tão assustadora, é principalmente uma questão de aplicar as soluções existentes: conectar nós em uma rede, adaptar algoritmos para identificação de topologias, troca de dados e controle de consistência, implementar técnicas de classificação de nós e alcançar consenso, e, claro, apenas criar sua linguagem de consulta e todo o ambiente computacional e linguístico. A ideia de um mecanismo universal é muito tentadora e surge constantemente em uma ou outra área, mas no final das contas, o que se obtém é uma das três opções: a solução criada se torna de fato um protótipo limitado cheio de “ToDo” pendentes, ou se transforma em um monstro inutilizável, pronto para arrastar qualquer um que se aproxime para a fétida “lama de Turing”, ou simplesmente morre de sucesso por ter seu projeto puxado em direções confusas, como um cisne, um caranguejo e uma lúcia que se desgastam.
Não vamos repetir erros tolos e escolheremos uma direção que tenha um escopo de tarefa claro e que se encaixe bem no modelo de computação distribuída. É compreensível que as pessoas tentem fazer tudo de uma vez — de fato, há muitas opções. E muitas ideias são extremamente interessantes tanto do ponto de vista de P&D e desenvolvimento, quanto do ponto de vista econômico. Com uma rede distribuída, é possível:
- Treinar redes neurais
- Processar fluxos de sinais
- Calcular estruturas de proteínas
- Realizar renderização de cenas tridimensionais
- Modelar hidrodinâmica
- Testar estratégias comerciais para bolsas de valores
Para não nos perdermos na elaboração de uma lista de coisas interessantes que se paralelizam bem, escolhemos como nosso próximo tema a renderização distribuída.
A renderização distribuída por si só não é uma novidade. Conjuntos de ferramentas de renderização existentes já suportam a distribuição de cargas entre várias máquinas; sem isso, viver no século XXI seria bastante triste. No entanto, não devemos pensar que este assunto está esgotado e que não há mais nada a ser explorado — vamos abordar um problema relevante: a criação de uma ferramenta para formar uma rede de renderização.
A rede de renderização é uma junção de nós que precisam executar tarefas de renderização e nós que possuem recursos computacionais livres para processar essa renderização. Os proprietários dos recursos conectarão suas estações à rede de renderização para receber e executar tarefas de renderização usando um dos motores de renderização suportados pela rede. Os fornecedores de tarefas, por sua vez, trabalharão com a rede como se fosse uma nuvem, realizando autonomamente a distribuição de recursos, controle da correção da execução, gerenciamento de riscos e outros problemas.
Portanto, vamos considerar a criação de um framework que deve suportar a integração com um conjunto de motores de renderização populares e conter componentes que forneçam ferramentas para organizar uma rede de nós heterogêneos e gerenciar o fluxo de tarefas.
O modelo econômico da existência dessa rede não é fundamental, portanto, vamos assumir um esquema semelhante ao utilizado em cálculos em redes de criptomoedas — os consumidores de recursos enviarão tokens para os fornecedores que realizam a tarefa de renderização. É muito mais interessante entender quais propriedades o framework deve possuir, para isso, vamos examinar o cenário básico de interação entre os participantes da rede.
Na rede, existem três partes interagindo: o fornecedor de recursos, o fornecedor de tarefas e o operador da rede (também conhecido como centro de controle, rede, etc. no texto).
O operador de rede fornece ao fornecedor de recursos um aplicativo cliente ou uma imagem do sistema operacional com um conjunto completo de software pré-instalado, que será instalado na máquina cujos recursos deseja disponibilizar, e um painel de controle acessível através de uma interface web, permitindo que ele defina os parâmetros de acesso aos recursos e gerencie remotamente sua infraestrutura de servidores: controlando os parâmetros de hardware, realizando configurações remotas e reiniciando.
O sistema de gerenciamento de rede, ao conectar um novo nó, realiza uma análise do hardware e dos parâmetros de acesso definidos, classifica-o, atribuindo uma determinada classificação, e o insere no registro de recursos. No futuro, para fins de gerenciamento de risco, 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 gostaria que sua cena fosse enviada para renderização em placas poderosas, mas que frequentemente travam devido ao superaquecimento, não é?
O usuário que precisa renderizar alguma cena pode seguir dois caminhos: fazer o upload da cena para o repositório da rede através da interface web ou conectar seu pacote de modelagem ou renderizador instalado à rede usando um plugin. Nesse processo, é iniciado um smart contract entre o usuário e a rede, sendo que a condição padrão para a sua conclusão é a geração do resultado da computação da cena pela rede. O usuário pode acompanhar o progresso da tarefa e gerenciar seus parâmetros através da interface web do seu painel de controle.
A tarefa é enviada para servidor, onde o volume da cena e a quantidade de recursos solicitados pelo iniciador da tarefa são analisados, após o que o volume total é decomposto em partes adaptadas para computação na quantidade e tipo de recursos designados pela rede. A ideia geral é que a visualização pode ser dividida em várias pequenas tarefas. Os motores aproveitam essa vantagem, distribuindo essas tarefas entre vários fornecedores de recursos. A maneira mais simples é renderizar pequenas partes da cena, chamadas segmentos. Quando cada segmento está pronto, a tarefa local é considerada concluída, e o recurso passa a executar a próxima tarefa pendente.
Assim, para o renderizador, não há diferença entre realizar os cálculos em uma única máquina ou em uma grade de várias estações de computação separadas. A renderização distribuída apenas adiciona mais núcleos ao pool de recursos disponíveis para a tarefa. Através da rede, ele obtém todos os dados necessários para renderizar o segmento, calcula-o, envia esse segmento de volta e parte para a próxima tarefa. Antes de ser incluído no pool comum da rede, cada segmento recebe um conjunto de metainformações que permite que os nós executores escolham as tarefas computacionais mais adequadas.
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 em termos de uso eficiente de recursos e economia de energia, pois isso afeta a eficiência econômica da rede. Em caso de uma decisão malsucedida, pode ser mais viável colocar um minerador no nó ou desligá-lo para que não faça barulho e não consuma eletricidade.
No entanto, voltemos ao processo. Ao receber uma tarefa, um contrato inteligente também é criado entre o pool e o nó, que é executado quando o resultado da tarefa é calculado corretamente. Com os resultados da execução do contrato, o nó pode receber recompensas de diversas formas.
O centro de controle monitora o processo de execução da tarefa, coletando os resultados dos cálculos, enviando novamente para processamento aqueles que estão incorretos e classificando a fila, monitorando o prazo normativo para a execução da tarefa (para que não aconteça o caso de que o último segmento não seja aceito por nenhum nó).
Os resultados dos cálculos passam pela etapa de composição, após a qual o usuário recebe os resultados da renderização e a rede pode receber recompensas.
Assim, delineia-se a composição funcional da estrutura de framework voltada para a construção de sistemas de renderização distribuída:
- Painéis de usuários com acesso via web
- Pacote de software para instalação nos nós
- Os sistemas de gerenciamento:
- Subsistema de gerenciamento de acesso
- Subsistema de decomposição de tarefas de renderização
- Subsistema de distribuição de tarefas
- Subsistema de composição
- Subsistema de gerenciamento da paisagem do servidor e topologia da rede
- Subsistema de logging e auditoria
- Subsistema de especialistas em aprendizado
- API REST ou outra interface para desenvolvedores externos
E o que você acha? Quais questões a tema levanta e quais respostas você está interessado?
Fonte: habr.com
