你好,游客 登录 注册 发布搜索
背景:
阅读新闻

从CPU/OS到虚拟机和云计算 一切皆有可能

[日期:2014-05-09] 来源:移动Labs新闻  作者: [字体: ]

  关于软硬件谁为主导这个话题,套用一句谚语就是三十年河东三十年河西,风水轮流转。软件和硬件一定是相互促进、相互拆台又相互搭台的。一些之前被诟病的上层架构,或许若干年之后会被发现成了最合适的选择,而再过若干年,又会变得不合适。软件定义亦或是硬件定义,同样也是这样,硬件定义的结果是性能够强但是不灵活,此时软件定义便会开始酝酿翻盘,但是任何事情都有惯性,软件“过度”定义之后,会发现很多事情搞不定,还得靠硬件来加速一下,此时开始进入硬件定义周期,然后循环往复。我们可以用几个例子来窥探一下这种规律。

云,云计算

  CPU和OS

  一对不离不弃的夫妻,阴抱阳,阳抱阴。一开始没有所谓中断,更没有所谓OS,只有顺序执行指令计算机和被写死的程序,很不灵活。后来才有了OS,CPU 先执行OS这个大循环程序,然后载入所需要执行的用户程序执行,执行完退出,可以继续载入其他程序执行。哪怕最简单的OS要想玩转,CPU起码也得至少提供IO和时钟中断机制。OS呱呱坠地,就得不断长大,不断地进化,单任务不灵活,就得多任务分时执行,所有任务共享内存空间,导致了安全性问题,这就不得不引入虚拟内存技术,所以软件越来越复杂,性能逐渐就不行了。此时CPU出来说话了,我来搞定虚拟内存,提供页表极致,提供专用的控制寄存器,并提供专用的查表加速硬件部件。多任务分时OS的生产力被初步释放,但是性能还是较差,还得依靠CPU搞定。CPU继续发力,引入超线程技术,让多个线程的代码可以并发执行,这得益于流水线的设计;为了能够更好的实现线程并发执行,后来继续出现多核心多CPU的SMP技术, OS不得不做出改动。但是多CPU/核心并不是任何时候都很高效地并发多线程的,随着软件复杂度提升,线程同步、缓存一致性等问题导致需要大量状态和数据同步,传统的共享式的前端总线效率太低,所以不得不改为交换式Fabric比如IntelQPI,访问内存经过太多跳器件效率上不去,所以也改为直连 CPU分布式共享架构,这也是当今的形态。再往后会怎么发展,应该可以顺着惯性往前推导一下,交换式Fabric的出现,意味着CPU和CPU之间可以离得越来越远,只要有足够高速的链路连接,这一形态其实就是大型NUMA计算机的形态了。这一形态的轮回意味着软件架构的变化,传统领域需要高性能的场景不得不使用大型机、小型机,但它们是极其昂贵的——就是因为不开放,而且又不可能像互联网领域一样投入开发资源在分布式系统上定制化自己的应用。而开放式大型NUMA系统出现之后,可能之前的被“过度”定义了的分布式系统生态又会沉寂下来,这个循环进入新的周期纪元,在这个纪元里,曾经光鲜的分布式系统可能会被新生代工程师/架构师认为是一种很不可思议的“野路子”:“你看,以前这种架构,好坑爹啊!”。这就像我们现在回头看之前的有些设计一样,也会感觉到不可思议,那时候的人都这么“脑残”么?恩,如果换了你回到那个时代,或许更脑残:)。不管谁脑残,一个事实是始终不变的,那就是硬件性能的绝对值是一直直线上升的,不管分布式还是集中式。

  CPU和VMM

  VMM能发展到今天这个地步是无人始料的,一开始就是玩玩,没想到玩了个大的出来。有不少人持有上述观点,其实这个观点只是表象。虚拟机技术起源于大型机,中小型机上早已也使用了多年,所以VMM可并不是玩玩。大机小机都是封闭市场,技术也确实牛。开放市场领域很多技术其实都是源自大型机小型机。虚拟机显然是单机性能过剩,而多机整体资源又无法得到全局细粒度池化分配时代的产物。VMM虚拟CPU,虚拟IO设备,虚拟内存,一开始全用软件实现,每一条指令解释执行,后来优化了设计,但最终还是要监控和截获+虚拟那些敏感和特权指令,每个进程还要虚拟出额外页表从而虚拟内存,IO需要经历重重内存拷贝才能发出去一个包,要想商用的话,软件各方面开销实在是搞不定了,此时还得硬件出马,在CPU层面提供硬件辅助,IO设备也开始有了SRIOV/MRIOV的方案,我总感觉这次硬件反而有点“过度”定义了,被软件骗了一回。为什么呢?就因为硬件资源不能做到池化和细粒度切分,才会产生VMM这个尴尬的东西,而此时硬件仿佛走火入魔了,弄出一系列复杂的技术来支撑VMM。其实硬件还有另一条路可以走,同样可以实现VMM类似的效果,那就是让硬件变得可以切分,而不是用软件去切分。这条路在小机系统上曾经有人尝试过,采用总线级别的隔离开关来切分不同的CPU和内存以及IO槽位。要实现细粒度切分的前提是必须把硬件最小切分粒度降下来,单CPU使劲增加性能其实已经不是一条比较明智的路线了。近几年众核CPU不断冒出头来,单CPU128个核心已经不是什么惊讶之事了,但是由于生态尚未成熟,它们目前仍被局限在并行度高耦合度低的处理场景比如网络包处理等。另一个迹象就是ARM生态的崛起,种种迹象表明这很有可能是一条光明大道。但是如何将传统生态导向这个道路上就不那么简单了。我们看到Intel正在搞SiPh硅光方案,其致力于硬件资源的灵活拼搭,如果粒度足够细,VMM其实就可以退出舞台了,这将又是一场硬件拆台软件的血腥战斗。

  虚拟机和云计算

  虚拟机的发展催生硬件加速方案,也正是因为硬加速,又使得虚拟机可以大范围应用,也正是如此,才将云计算的概念带了出来,也就是硬件又反过来加速了软件的变革。而随着量的上升,会影响质变,人们会发现其实VM这种东西是非常低效的虚拟化,VMM个人理解其实是一股具有邪性的阳气,他看似光鲜实则非常损耗阴实的,体现为过多不必要的操作系统实例。操作系统本来就是利用线程/进程来虚拟化多任务多用户的运行,每一次系统调用的开销是非常高的,让一个CPU同时运行多个操作系统实例,无疑是极大的浪费,上文提到过这种模式是单机性能过剩而整体资源又无法得到池化时代的产物。而云计算架构的出现,会打破这个矛盾。云计算可能初生的时候就是一个全局虚拟机资源调度管理软件框架,但是一个事物毕竟是不断在成长进化的,云计算会最终找到它的使命,那就是大范围全局资源的池化、分配调度管理监控,也就是数据中心级的OS,做的事情与单机OS如出一辙。既然如此,那么AAAS(ApplicationAs a Service)应该是云计算最终要实现的状态,这就相当于打开屏幕,就出现一堆应用图标,点进去完成你要的功能,退出,结束。既然用户不需要IAAS,不需要直接面对操作系统,那么搞那么多VM实例其实就是没有必要的,空耗资源。云计算需要实现一个全局的应用进程级别的调度中枢,而不是调度VM。再来思考一下大机为什么需要VM?因为大机那个时代并没有现在这种云计算的概念,xAAS这个思维,你可以说那时候人脑残,那时候软件技术是很封闭而且不发达的,所以进行资源细粒度切分,用VM也算是快刀斩乱麻的方案。我们也看到进程级虚拟机(比如LinuxContainer)业逐渐在受到关注。这些都是云计算这个软件框架、这个宏观的OS的定义,那么这种定义会对硬件有什么影响?我想那一定会催生两个硬件形态的变革,一个就是上面所说的单点的性能要足够低,力度要足够细,单点性能“足够低”,这可能让人大跌眼镜,不过将来可真说不定啊,众核CPU就是个很好的胚子;另一个是局部多层高速Fabric核间通信,由于CPU/核心可以任意切分和组合,他们之间一定需要一个高速总线相互连接,目前存在多种Fabric方案和产品,这块虽然比较低调冷门但是也还算成熟,加上硅光等技术会将Fabric隐身至机架外,这就为大范围池化提供了支撑。而这次硬件的变革很可能又会影响软件的架构,使得大规模并行计算不再需要MPI等远程消息传递机制,消息传递直接使用Fabric硬件加速的队列FIFO,会大大简化编程,有利于HPC的模式最终可以全面得到普及。

  云计算,宏观操作系统,数据中心级的NUMA机,一切皆有可能。

原文链接:http://labs.chinamobile.com/news/104494_p2

收藏 推荐 打印 | 录入:Cstor | 阅读:
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数
点评:
       
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款