近年来，新闻源中充斥着关于新型分布式计算网络的消息，这种网络不知从何而来，解决（或者更确切地说，试图解决）各种各样的问题——使城市变得智能，使世界免受版权侵害。侵权者或反之亦然，秘密转移信息或资源，逃离某一地区或另一地区的国家控制。 无论哪个领域，它们都具有许多共同特征，因为它们增长的动力是在最近加密货币和相关技术繁荣期间向公众公开的算法和技术。 当时可能每三篇关于专业资源的文章标题中都会出现“区块链”一词——讨论新的软件解决方案和经济模型成为一段时间的主导趋势，在此背景下分布式计算系统的其他应用领域正在兴起。退居幕后。
与此同时，有远见的人和专业人士看到了这一现象的主要本质：与大量不同和异构参与者构建的网络相关的大规模分布式计算已经达到了新的发展水平。 只要把你头脑中的炒作话题扔掉，从另一个角度看这个话题就足够了：所有这些网络都是由巨大的池子组装而成的，这些池子由数千个孤立的异构参与者组成，它们并不是单独出现的。 加密货币运动的爱好者能够以一种新的方式解决数据同步以及资源和任务分配的复杂问题，这使得将类似数量的设备组合在一起并创建一个旨在解决一个狭隘问题的新生态系统成为可能。
当然，参与免费分布式计算开发的团队和社区并没有忽视这一点，新项目很快就会出现。
然而，尽管有关构建网络和使用设备领域的发展的可用信息量显着增加，但有前途的系统的创建者将不得不解决严重的问题。
第一个，无论听起来多么奇怪，都是选择方向的问题。
方向可能是正确的，也可能会走向死胡同——这是无法逃脱的；向IT社区集中供应千里眼还为时已晚。 但必须做出选择，以免陷入传统的陷阱，即团队范围太广，从一开始就试图创建另一个非专业的通用分布式计算项目。 看起来工作范围并不那么可怕，在大多数情况下，我们只需要应用现有的开发：将节点组合到网络中，调整用于确定拓扑的算法，交换数据并监控其一致性，引入对节点进行排序和查找的方法共识，当然，只需创建您自己的查询语言以及整个语言和计算环境。 通用机制的想法非常诱人，并且不断在某个领域出现，但最终结果仍然是以下三件事之一：创建的解决方案实际上是一个有限的原型，带有一堆暂停的“待办事项”在待办事项中，或者它变成一个无法使用的怪物，准备拖走任何接触恶臭“图灵沼泽”的人，或者只是因为天鹅、小龙虾和梭子鱼而安全地死去，它们正在将项目拉向一个难以理解的方向，简直是过度劳累了自己。
我们不要重复愚蠢的错误，选择一个任务范围明确、非常适合分布式计算模型的方向。 你可以理解那些试图同时做所有事情的人——当然，有很多选择。 无论是从研发和开发的角度，还是从经济学的角度来看，很多事情看起来都非常有趣。 使用分布式网络，您可以：
- 训练神经网络
- 处理信号流
- 计算蛋白质结构
- 渲染 XNUMXD 场景
- 模拟流体动力学
- 测试证券交易所的交易策略
为了不沉迷于编译一系列并行化良好的有趣事物，我们将选择分布式渲染作为我们的进一步主题。
当然，分布式渲染本身并不是什么新鲜事。 现有的渲染工具包长期以来一直支持跨不同机器的负载分配；如果没有这个，生活在二十一世纪将是相当悲伤的。 然而，您不应该认为这个主题已经被广泛覆盖，并且没有什么可做的 - 我们将考虑一个单独的紧迫问题：创建一个用于创建渲染网络的工具。
我们的渲染网络是需要执行渲染任务的节点与具有空闲计算资源来处理渲染的节点的组合。 资源所有者将其工作站连接到渲染网络，以使用网络支持的渲染引擎之一接收和执行渲染作业。 在这种情况下，任务提供者将与网络作为云一起工作，独立分配资源、监控执行的正确性、风险管理等问题。
因此，我们将考虑创建一个框架，该框架应支持与一组流行渲染引擎的集成，并包含提供用于组织异构节点网络和管理任务流的工具的组件。
这种网络存在的经济模型并不重要，因此我们将采用类似于加密货币网络计算中使用的方案作为初始方案 - 资源的消费者将向执行渲染工作的供应商发送代币。 理解框架应该具有哪些属性更有趣，为此我们将考虑网络参与者之间交互的主要场景。
网络中存在交互的三个方面：资源提供者、任务提供者和网络运营者（文中又名控制中心、网络等）。
网络运营商向资源提供商提供客户端应用程序或带有已部署软件集的操作系统映像，资源提供商将其安装在他想要提供资源的计算机上，以及可通过 Web 界面访问的个人帐户，使他能够设置资源的访问参数并远程管理其服务器环境：控制硬件参数、执行远程配置、重新启动。
当连接新节点时，网络管理系统分析设备和指定的访问参数，对其进行排名，分配一定的等级，并将其放入资源寄存器中。 未来，为了管理风险，将分析节点的活动参数，调整节点的评级，以保证网络的稳定性。 如果他们的场景被发送到经常因过热而冻结的强大卡上进行渲染，没有人会感到高兴？
需要渲染场景的用户可以采用两种方式：通过 Web 界面将场景上传到网络存储库，或者使用插件将其建模包或安装的渲染器连接到网络。 在这种情况下，用户和网络之间发起智能合约，完成智能合约的标准条件是网络生成场景计算结果。 用户可以通过个人帐户的网络界面监控任务的完成过程并管理其参数。
任务发送到服务器，服务器分析场景的体积和任务发起者请求的资源数量，然后将总体积分解为适合计算网络分配的资源数量和类型的部分。 总体思路是可视化可以分解为许多小任务。 引擎通过在多个资源提供者之间分配这些任务来利用这一点。 最简单的方法是渲染场景的小部分（称为片段）。 当每个段准备就绪时，本地任务被视为已完成，并且资源将移至下一个未完成的任务。
因此，对于渲染器来说，无论计算是在单个机器上还是在许多单独计算站的网格上执行，都没有区别。 分布式渲染只是将更多核心添加到用于任务的资源池中。 通过网络，它接收渲染片段所需的所有数据，对其进行计算，将该片段发回，然后继续执行下一个任务。 在进入通用网络池之前，每个段都会接收一组元信息，允许执行节点为它们选择最合适的计算任务。
计算的分割和分布问题不仅要从执行时间优化的角度来解决，还要从资源优化利用和节能的角度来解决，因为网络的经济效益取决于此。 如果解决方案不成功，最好在节点上安装一个矿机或者将其关闭，这样它就不会发出噪音，也不会浪费电力。
不过，让我们回到这个过程。 当接收到任务时，矿池和节点之间也会形成智能合约，当任务结果计算正确时执行。 根据履行合约的结果，节点可以以一种或另一种形式获得奖励。
控制中心控制任务执行的过程，收集计算结果，发送错误的重新处理并排序队列，监控完成任务的标准期限（以免出现最后一段没有被占用的情况）任何节点）。
计算结果经过合成阶段，之后用户收到渲染结果，网络可以获得奖励。
因此，为构建分布式渲染系统而设计的景观框架的功能组成就出现了：
- 具有网络访问权限的个人用户帐户
- 用于在节点上安装的软件包
- 按控制系统：
- 门禁子系统
- 渲染任务分解子系统
- 任务分配子系统
- 合成子系统
- 服务器布局和网络拓扑管理子系统
- 日志记录和审计子系统
- 学习专家子系统
- Rest API 或其他供外部开发人员使用的接口
你怎么认为？ 该主题提出了哪些问题以及您对哪些答案感兴趣？
来源： habr.com