区块链热的废墟上的应用技术或资源分配的实际好处

近年来,新闻提要中充斥着有关新型分布式计算网络的消息,这些新型网络可以解决(或更确切地说,解决)最多样化的任务-使城市变得聪明,使世界免受版权侵权者的侵害,反之亦然,秘密传输信息或资源,逃避-在特定区域内的国家控制之下。 不管涉及哪个领域,它们都具有许多共同的特征,这是由于它们的增长动力是在最近的加密货币和相关技术的繁荣期间传给大众的算法和技术。 当时标题上有关专业资源的每篇第三篇文章都有“区块链”一词-一段时间以来,对新软件解决方案和经济模型的讨论成为主流趋势,与此相对应,分布式计算系统的其他应用领域也沦为背景。

同时,有远见的人和专业人士看到了这一现象的主要本质:与大量不同异构参与者建立网络相关的大规模分布式计算达到了新的发展水平。 将炒作话题从头脑中抛弃,从另一侧看待这个主题就足够了:所有这些网络都是由庞大的集合所组成,而这些集合由成千上万个孤立的异类参与者组成,它们并不是自己出现的。 加密运动爱好者能够以新的方式解决数据同步以及资源和任务分配的复杂问题,这使我们能够组装类似数量的设备,并创建旨在解决一个针对性很窄的问题的新生态系统。

当然,参与免费分布式计算开发的团队和社区并没有这样做,新的项目不久也就来了。
但是,尽管有关网络和设备领域发展的可用信息的数量大大增加,但有希望的系统的创建者将不得不解决严重的问题。

首先,无论听起来多么奇怪,都是选择方向的问题


方向可能是正确的,可能会导致死胡同-您无法逃脱,通向IT社区的集中人才的交付还很晚。 但是,应该做出选择,以免落入团队所涉领域太广的传统陷阱,并从一开始就尝试创建另一个具有广泛知名度的非专业化分布式计算项目。 看起来工作的前途似乎并不那么糟糕,在大多数情况下,您只需要应用现有的开发成果:将节点合并到网络中,调整用于确定拓扑的算法,交换数据并控制其一致性,介绍用于对节点进行排名和达成共识的方法,当然,创建您自己的查询语言以及整个语言和计算环境。 通用机制的想法非常诱人,并且不断出现在一个或另一个领域中,但是仍然获得了三个结果之一:所创建的解决方案或者实际上是数量有限的原型,积压着一堆悬浮的“ ToDo”,或者变成了难以管理的怪物,准备拖拖拉拉。任何触碰到令人讨厌的“转弯泥潭”的人,或者仅仅是因为天鹅,螃蟹和长矛在无法理解的方向上被拉扯成碎片而安全死亡的人。

我们不会重复愚蠢的错误,而是选择一个方向,该方向具有可以理解的任务范围,并且非常适合于分布式计算模型。 您可以理解尝试同时做所有事情的人-当然,这里有很多选择。 从研发和发展,以及从经济的角度来看,很多事情都非常有趣。 使用分布式网络,您可以:

  • 训练神经网络
  • 过程信号流
  • 计算蛋白质结构
  • 渲染3D场景
  • 模拟流体动力学
  • 测试证券交易所的交易策略

为了不因编写一系列平行的有趣事物而感到困惑,我们将选择分布式渲染作为我们的进一步主题。

当然,分布式渲染本身绝不是新现象。 在二十一世纪的生活现有渲染工具长期支持负载到多台机器平衡,没有这将是非常可悲的。 但是,您不应该以为主题已被颠覆,也无所事事-我们将考虑另一个紧急问题:创建用于创建渲染网络的工具。

与我们一起的渲染网络是需要执行渲染任务的节点与具有免费计算资源来处理渲染的节点的结合。 资源所有者将其工作站连接到渲染网络,以便使用网络支持的渲染引擎之一来接收和执行渲染作业。 同时,任务提供者将像云一样与网络一起工作,该云独立地分配资源,验证执行的正确性并管理风险和其他问题。

因此,我们将考虑创建一个框架,该框架应支持与一组流行的渲染引擎集成,并包含提供用于组织异构节点网络和控制任务流的工具的组件。

存在这种网络的经济模型并不是根本性的,因此,对于最初的网络,我们将采用与加密货币网络计算中所使用的方案类似的方案-资源使用者将向执行渲染工作的供应商发送令牌。 理解框架应具有的属性会更加有趣,为此我们将考虑网络参与者交互的主要场景。

网络中存在三个交互方面:资源提供者,任务提供者和网络运营商(在本文中全称为控制中心,网络等)。

网络运营商为资源提供者提供了一个客户端应用程序或操作系统映像,其中包含要安装在要提供其资源的机器上的一整套软件,以及可以通过Web界面访问的个人帐户,从而允许他为资源设置访问参数并远程控制服务器景观:控制熨斗的参数,执行远程配置,重新启动。

连接新节点时,网络管理系统会分析设备和指定的访问参数,对其进行排名,分配一定的等级并将其放入资源寄存器中。 将来,为了管理风险,将分析节点的活动参数,并调整节点的等级以确保网络的稳定性。 如果将他们的场景发送到功能强大但经常过热的卡上进行渲染,没有人会感到高兴吗?

需要渲染场景的用户可以采用两种方式:通过Web界面将场景上传到网络存储库,或使用插件将其仿真包或已安装的渲染器连接到网络。 在这种情况下,在用户和网络之间启动智能合约,完成该合约的标准条件是由网络生成场景计算结果。 用户可以通过其个人帐户的Web界面监视任务的进度并管理其参数。

任务到达服务器,在服务器上分析场景数量和任务发起者请求的资源数量,然后将总数量分解为适合计算网络分配的资源数量和类型的部分。 一般的想法是可视化可以分解为许多小任务。 引擎通过在多个资源提供者之间分配这些任务来利用此优势。 最简单的方法是渲染场景中称为片段的小部分。 当每个段准备就绪时,本地任务被视为已完成,资源将继续处理下一个未解决的任务。

因此,对于渲染器而言,计算是在一台机器上还是在来自许多单独的计算站的网格上进行的,就没有区别。 分布式渲染只是将更多核心添加到用于任务的资源池中。 通过网络,他接收渲染段所需的所有数据,对其进行计算,将该段发送回去,然后继续执行下一个任务。 在进入网络的通用池之前,每个网段都会接收一组元信息,这使执行节点可以为其选择最适合的计算任务。

由于网络的经济效率依赖于此,因此不仅应从优化执行时间的角度来解决计算的分割和分配任务,而且还应从资源的最佳利用和节能的角度来解决计算的问题。 如果决策失败,则更方便的做法是打开或关闭矿机,以免产生噪音且不会浪费电力。

但是回到过程。 当在池和节点之间接收到任务时,也会形成一个智能合约,当正确计算任务结果时会执行该合约。 根据合同的结果,节点可以以一种或另一种形式获得奖励。

控制中心监视完成任务的过程,收集计算结果,发送不正确的结果以进行重新处理和对队列进行排名,跟踪任务的规范术语(这样就不会发生最后一个段没有被任何节点运行的情况)。

计算结果经过合成阶段,此后用户收到渲染结果,网络可以收到奖励。

因此,旨在构建分布式渲染系统的景观框架的功能组成出现了:

  1. 网络仪表板
  2. 一组用于在节点上安装的软件
  3. 通过管理系统:
    • 访问控制子系统
    • 渲染任务的分解子系统
    • 任务分配子系统
    • 合成子系统
    • 服务器环境和网络拓扑管理子系统
    • 日志和审核子系统
    • 学习专家子系统
    • 面向外部开发人员的Rest API或其他接口

你觉得呢 主题引发什么问题,您对什么答案感兴趣?

Source: https://habr.com/ru/post/zh-CN466139/


All Articles