Disaggregation ? Distribution?
突然发现最近很多系统都用Disaggregated
在替代Distribution
,一些细微的变化值得去探索,似乎Dis-Aggregated把分布式的过程变得更加巨像化了。但是却又发现一些有趣的事情,有些公司又开始把一些技术糅合在一起,推出各种One
的方案(嘿嘿,我什么都没说…),例如樱桃的OneAPI
樱桃对于计算任务Scalar
Vector
Spatial
Matrix
的划分和相应的XPU处理看上去整个框架考虑的非常不错。
但是我一直对OneAPI有些疑惑,上层的编程语言和生态系统的统一哪有那么容易。然后打开OneAPI的Spec, 那些熟悉的私货又被夹带进来了TBB
MKL
对于未来包含大量异构芯片的系统应该如何实现分布式计算和协同,是Offload的模式,还是MPI的方式?突然想起樱桃以前的一个产品Xeon Phi了,当年Xeon Phi可是踌躇满志,利用X86的核去跟nvidia GPU比灵活性,然后再加上一大堆pragma xxx
神操作搞的整个代码面目全非,最近读了一下这本书,似乎对于当年的失败又有了更多的理解:
而如今的OneAPI,似乎又是在复杂的C艹他爹都搞不清有多少特性的基础上,再给C艹增加一大堆语法糖..是否真的有必要Aggregate
到一个API平台上,变相的保证Central PU(CPU)
的价值
如今DAO(Decentralized Autonomous Organization)正在兴起,本质上它是人类协作史上的一次革命性的进化,而计算机系统是否也需要同样的Decentralized PU
呢?这或许是DPU更好的一个定义,为了实现Decentralized
处理而构建的一颗特殊的处理单元。
在这个过程中逆水行舟的基本上都死了,例如SDN采用集中式控制平面,通常在规模达到一定程度后,控制器就会面临一大堆问题,性能上、数据隐私上、架构和配置复杂程度上。虽然可以通过一些分布式架构来解决问题,但是这样的控制器集群本身就会是一个很大的风险。所以跟着它抄出来的SDWAN等一系列产品都会面临同样的问题:
我在设计思科的分布式AIOps引擎时,自然而然的拿了一只呆萌的章鱼作为logo,本质上就是要区分这两种架构,拥有智能的不应该是大脑,而是最接地气的触须.
当然关于这只章鱼的架构后面会连续发一系列文章来手把手教大家实现下图中的整个workflow,并帮助大家自己定制一个AIOps平台,其中的一些关键组件也将开源出来.
另一个Disaggregation的处理方式便是如下图所示:
Offload的思路很对樱桃的胃口,毕竟还是承认CPU的集权地位,由它控制并下放计算任务,正如OneAPI正在潜意思的培养大家这样的思维。而工业界似乎更希望由一个完全解耦合的方式来构建多芯片流水线,因此相对于樱桃的OneAPI在编程语言之上由CPU调度,NetDAM把这一层统一到了更底层的内存访问上,保证每颗芯片都能实现Decentralized Autonomous Organization:
并且也能保证整个系统上所有的组件能够在统一的内存抽象层上协同:
而对于连接它们的SDWAN系统,也是采用完全DAO的方式实现,没有中心就连算路选路都是边缘节点自主完成的:
未来十年的变革,无论是商业模式,还是社会构成,都将带来一个完全去中心化的方式。而很多企业还想算计着靠制定标准或者聚焦资源,本质上就是逆潮流而动罢了..
最后插播一个小广告…
zEcho:一个无聊的回包器
项目地址: github.com/zartbot/zecho
主要是用于一些防火墙NAT测试时,IXIA这类流量发生器通常只能从内网打到外网,由于很多动态NAT测试时,地址和端口被NAT更改后,很难从外网注入流量,而且往返延迟也无法测量。于是无聊写了一个回包器,即把接收到的报文MAC地址、IP地址和UDP、TCP端口通通交换,当然为了快也懒得算CRC了直接把三四层CRC改为了0,然后启用了RSS,16个核可以干到80Mpps基本满足测试需求了,然后单个流hash到单核也有5Mpps。大概就这样了..
《Disaggregation ? Distribution?》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:http://www.bookhoes.com/291.html