Nos últimos anos, os feeds de notícias foram inundados com mensagens sobre um novo tipo de redes de computação distribuídas que surgiram literalmente do nada, resolvendo (ou melhor, tentando resolver) uma ampla variedade de problemas - tornar uma cidade inteligente, salvar o mundo dos direitos autorais infratores ou vice-versa, transferindo secretamente informações ou recursos, escapando do controle estatal em uma área ou outra. Independentemente da área, todos eles têm uma série de características comuns devido ao fato de que o combustível para o seu crescimento foram os algoritmos e técnicas que vieram ao público durante o recente boom das criptomoedas e tecnologias relacionadas. Provavelmente, um em cada três artigos sobre recursos especializados da época tinha a palavra “blockchain” no título - a discussão de novas soluções de software e modelos econômicos tornou-se a tendência dominante por algum tempo, tendo como pano de fundo outras áreas de aplicação de sistemas de computação distribuídos. relegado para segundo plano.
Ao mesmo tempo, visionários e profissionais perceberam a essência do fenômeno: a computação distribuída massiva, associada à construção de redes a partir de um grande número de participantes díspares e heterogêneos, atingiu um novo patamar de desenvolvimento. Basta tirar da cabeça os hype topics e olhar o assunto do outro lado: todas essas redes, montadas a partir de enormes pools, que consistem em milhares de participantes isolados e heterogêneos, não surgiram por conta própria. Os entusiastas do movimento criptográfico conseguiram resolver problemas complexos de sincronização de dados e distribuição de recursos e tarefas de uma nova forma, o que possibilitou reunir uma massa semelhante de equipamentos e criar um novo ecossistema projetado para resolver um problema de foco restrito.
É claro que isso não passou despercebido às equipes e comunidades envolvidas no desenvolvimento da computação distribuída gratuitamente, e novos projetos não tardaram a surgir.
No entanto, apesar do aumento significativo do volume de informação disponível sobre os desenvolvimentos no domínio da construção de redes e do trabalho com equipamentos, os criadores de sistemas promissores terão de resolver sérios problemas.
O primeiro deles, por mais estranho que pareça, é o problema de escolher um rumo.
A direção pode estar correta ou pode levar a um beco sem saída - não há como escapar disso: o fornecimento centralizado de clarividentes para a comunidade de TI ainda está atrasado. Mas a escolha deve ser feita para não cair na armadilha tradicional de a equipe ocupar uma área muito ampla e tentar criar desde o início outro projeto de computação distribuída geral não especializado. Parece que o escopo do trabalho não é tão assustador, na maioria das vezes só precisamos aplicar os desenvolvimentos existentes: combinar nós em uma rede, adaptar algoritmos para determinar topologias, trocar dados e monitorar sua consistência, introduzir métodos para classificar nós e encontrar consenso e, claro, apenas crie sua própria linguagem de consulta e toda a linguagem e ambiente de computação. A ideia de um mecanismo universal é muito tentadora e surge constantemente em uma área ou outra, mas o resultado final ainda é uma de três coisas: a solução criada acaba sendo um protótipo limitado com um monte de “ToDos” suspensos ” no backlog, ou se torna um monstro inutilizável pronto para arrastar qualquer um que toque no fétido “pântano de Turing”, ou simplesmente morre com segurança pelo fato de que o cisne, o lagostim e o lúcio, que estavam puxando o projeto em uma direção incompreensível, simplesmente se sobrecarregaram.
Não vamos repetir erros estúpidos e escolher uma direção que tenha uma gama clara de tarefas e seja adequada ao modelo de computação distribuída. Você pode entender as pessoas que tentam fazer tudo de uma vez - é claro, há muito por onde escolher. E muitas coisas parecem extremamente interessantes tanto do ponto de vista da I&D e do desenvolvimento, como do ponto de vista da economia. Usando uma rede distribuída você pode:
- Treine redes neurais
- Fluxos de sinal de processo
- Calcular a estrutura da proteína
- Renderizar cenas XNUMXD
- Simular hidrodinâmica
- Teste estratégias de negociação para bolsas de valores
Para não nos deixarmos levar por compilar uma lista de coisas interessantes e bem paralelizadas, escolheremos a renderização distribuída como nosso próximo tópico.
A renderização distribuída em si não é, obviamente, nada de novo. Os kits de ferramentas de renderização existentes há muito suportam a distribuição de carga entre diferentes máquinas; sem isso, viver no século XXI seria muito triste. No entanto, você não deve pensar que o tópico foi amplamente abordado e que não há nada a fazer lá - consideraremos um problema urgente separado: criar uma ferramenta para criar uma rede de renderização.
Nossa rede de renderização é uma combinação de nós que precisam realizar tarefas de renderização com nós que possuem recursos computacionais livres para processar a renderização. Os proprietários de recursos conectarão suas estações à rede de renderização para receber e executar trabalhos de renderização usando um dos mecanismos de renderização suportados pela rede. Nesse caso, os provedores de tarefas trabalharão com a rede como se fosse uma nuvem, distribuindo recursos de forma independente, monitorando a correção da execução, gerenciando riscos e outros problemas.
Assim, consideraremos a criação de uma estrutura que suporte a integração com um conjunto de mecanismos de renderização populares e contenha 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 de tal rede não é de fundamental importância, portanto tomaremos como esquema inicial um esquema semelhante ao utilizado nos cálculos em redes de criptomoedas - os consumidores do recurso enviarão tokens aos fornecedores que realizam o trabalho de renderização. É muito mais interessante entender quais propriedades um framework deve ter, para o qual consideraremos o principal cenário de interação entre os participantes da rede.
Existem três lados de interação na rede: provedor de recursos, provedor de tarefas e operador de rede (também conhecido como centro de controle, rede, etc. no texto).
O operador de rede fornece ao fornecedor de recursos uma aplicação cliente ou uma imagem de sistema operativo com um conjunto de software implementado, que irá instalar na máquina cujos recursos pretende fornecer, e uma conta pessoal acessível através da interface web, permitindo-lhe definir parâmetros de acesso ao recurso e gerenciar remotamente seu cenário de servidor: controlar parâmetros de hardware, realizar configuração remota, reinicializar.
Quando um novo nó é conectado, o sistema de gerenciamento de rede analisa o equipamento e os parâmetros de acesso especificados, classifica-o, atribuindo uma determinada classificação, e coloca-o no cadastro de recursos. Futuramente, para gerir o risco, serão analisados os parâmetros de atividade do nó 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 placas poderosas que muitas vezes congelam devido ao superaquecimento?
Um usuário que precisa renderizar uma cena pode seguir dois caminhos: carregar a cena em um repositório de rede por meio da interface da web ou usar um plug-in para conectar seu pacote de modelagem ou renderizador instalado à rede. Nesse caso, é iniciado um contrato inteligente entre o usuário e a rede, cuja condição padrão para conclusão é a geração do resultado do cálculo da cena pela rede. O usuário pode monitorar o processo de conclusão de uma tarefa e gerenciar seus parâmetros através da interface web de sua conta pessoal.
A tarefa é enviada ao servidor, onde são analisados o volume da cena e a quantidade de recursos solicitados pelo iniciador da tarefa, após o que o volume total é decomposto em partes adaptadas para cálculo da quantidade e tipo de recursos alocados pela rede . A ideia geral é que a visualização pode 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 da cena chamadas segmentos. Quando cada segmento estiver pronto, a tarefa local será considerada concluída e o recurso passará para a próxima tarefa pendente.
Assim, não faz diferença para o renderizador se os cálculos são realizados em uma única máquina ou em uma grade de muitas estações de computação individuais. A renderização distribuída simplesmente adiciona mais núcleos ao conjunto de recursos usados para uma tarefa. Através da rede, ele recebe todos os dados necessários para renderizar um segmento, calcula-o, envia esse segmento de volta e passa para a próxima tarefa. Antes de entrar no pool geral da rede, cada segmento recebe um conjunto de metainformações que permite aos nós em execução selecionar as tarefas computacionais mais adequadas para eles.
Os problemas de segmentação e distribuição dos cálculos devem ser resolvidos não só do ponto de vista da otimização do tempo de execução, mas também do ponto de vista da utilização óptima dos recursos e da poupança de energia, uma vez que disso depende a eficiência económica da rede. . Caso a solução não dê certo, seria mais aconselhável instalar um minerador no nó ou desligá-lo para que não faça barulho e não desperdice energia elétrica.
No entanto, voltemos ao processo. Quando uma tarefa é recebida, um contrato inteligente também é formado entre o pool e o nó, que é executado quando o resultado da tarefa é calculado corretamente. Com base nos resultados do cumprimento do contrato, o nó pode receber uma recompensa de uma forma ou de outra.
A central de controle controla o processo de execução da tarefa, coletando os resultados dos cálculos, enviando os incorretos para reprocessamento e classificando a fila, monitorando o prazo padrão para conclusão da tarefa (para que não aconteça que o último segmento não seja ocupado por qualquer nó).
Os resultados dos cálculos passam pela etapa de composição, após a qual o usuário recebe o resultado da renderização, e a rede pode receber uma recompensa.
Assim surge a composição funcional de um framework paisagístico projetado para a construção de sistemas de renderização distribuída:
- Contas de usuário pessoais com acesso à web
- Kit de software para instalação em nós
- Por sistema de controle:
- Subsistema de controle de acesso
- Subsistema de decomposição de tarefas de renderização
- Subsistema de distribuição de tarefas
- Subsistema de composição
- Subsistema de gerenciamento de topologia de rede e cenário de servidor
- Subsistema de registro e auditoria
- Subsistema especialista em aprendizagem
- API Rest ou outra interface para desenvolvedores externos
O que você acha? Que perguntas o tópico levanta e em quais respostas você está interessado?
Fonte: habr.com