博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
从CPU/OS到虚拟机和云计算
阅读量:5311 次
发布时间:2019-06-14

本文共 3335 字,大约阅读时间需要 11 分钟。

 

从CPU/OS到虚拟机和云计算

 作者:张冬

           关于软硬件谁为主导这个话题,套用一句谚语就是三十年河东三十年河西。风水轮流转。软件和硬件一定是相互促进、相互拆台又相互搭台的。

一些之前被诟病的上层架构。也许若干年之后会被发现成了最合适的选择,而再过若干年,又会变得不合适。

软件定义亦或是硬件定义。相同也是这样。硬件定义的结果是性能够强可是不灵活,此时软件定义便会開始酝酿翻盘。可是不论什么事情都有惯性。软件“过度”定义之后,会发现非常多事情搞不定。还得靠硬件来加速一下,此时開始进入硬件定义周期。然后循环往复。

我们能够用几个样例来窥探一下这样的规律。

CPUOS

       一对不离不弃的夫妻。阴抱阳,阳抱阴。一開始没有所谓中断,更没有所谓OS。仅仅有顺序运行指令计算机和被写死的程序,非常不灵活。后来才有了OSCPU先运行OS这个大循环程序,然后加载所须要运行的用户程序运行,运行完退出,能够继续加载其它程序运行。哪怕最简单的OS要想玩转,CPU起码也得至少提供IO和时钟中断机制。OS呱呱坠地,就得不断长大。不断地进化,单任务不灵活,就得多任务分时运行。全部任务共享内存空间。导致了安全性问题,这就不得不引入虚拟内存技术,所以软件越来越复杂。性能逐渐就不行了。此时CPU出来说话了。我来搞定虚拟内存。提供页表极致,提供专用的控制寄存器,并提供专用的查表加速硬件部件。多任务分时OS的生产力被初步释放。可是性能还是较差,还得依靠CPU搞定。CPU继续发力,引入超线程技术,让多个线程的代码能够并发运行。这得益于流水线的设计。为了能够更好的实现线程并发运行。后来继续出现多核心多CPUSMP技术, OS不得不做出修改。

可是多CPU/核心并非不论什么时候都非常高效地并发多线程的,随着软件复杂度提升,线程同步、缓存一致性等问题导致须要大量状态和数据同步,传统的共享式的前端总线效率太低,所以不得不改为交换式Fabric比方IntelQPI,訪问内存经过太多跳器件效率上不去,所以也改为直连CPU分布式共享架构。这也是当今的形态。再往后会怎么发展。应该能够顺着惯性往前推导一下。交换式Fabric的出现。意味着CPUCPU之间能够离得越来越远,仅仅要有足够快速的链路连接。这一形态事实上就是大型NUMA计算机的形态了。这一形态的轮回意味着软件架构的变化,传统领域须要高性能的场景不得不使用大型机、小型机,但它们是极其昂贵的——就是由于不开放,并且又不可能像互联网领域一样投入开发资源在分布式系统上定制化自己的应用。而开放式大型NUMA系统出现之后。可能之前的被“过度”定义了的分布式系统生态又会沉寂下来,这个循环进入新的周期纪元,在这个纪元里,以前光鲜的分布式系统可能会被新生代project师/架构师觉得是一种非常不可思议的“野路子”:“你看。以前这样的架构。好坑爹啊!”。

这就像我们如今回头看之前的有些设计一样。也会感觉到不可思议,那时候的人都这么“脑残”么?恩,假设换了你回到那个时代。也许更脑残:)。无论谁脑残,一个事实是始终不变的。那就是硬件性能的绝对值是一直直线上升的。无论分布式还是集中式。

CPUVMM

         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如出一辙。

既然如此,那么AAASApplicationAs a Service)应该是云计算终于要实现的状态。这就相当于打开屏幕。就出现一堆应用图标,点进去完毕你要的功能,退出,结束。既然用户不须要IAAS,不须要直接面对操作系统,那么搞那么多VM实例事实上就是没有必要的,空耗资源。

云计算须要实现一个全局的应用进程级别的调度中枢,而不是调度VM

再来思考一下大机为什么须要VM?由于大机那个时代并没有如今这样的云计算的概念。xAAS这个思维,你能够说那时候人脑残。那时候软件技术是非常封闭并且不发达的,所以进行资源细粒度切分,用VM也算是快刀斩乱麻的方案。我们也看到进程级虚拟机(比方LinuxContainer)业逐渐在受到关注。

这些都是云计算这个软件框架、这个宏观的OS的定义,那么这样的定义会对硬件有什么影响?我想那一定会催生两个硬件形态的变革,一个就是上面所说的单点的性能要足够低,力度要足够细。单点性能“足够低”。这可能让人大跌眼镜,只是将来可真说不定啊,众核CPU就是个非常好的胚子;还有一个是局部多层快速Fabric核间通信,由于CPU/核心能够随意切分和组合。他们之间一定须要一个快速总线相互连接。眼下存在多种Fabric方案和产品,这块尽管比較低调冷门可是也还算成熟,加上硅光等技术会将Fabric隐身至机架外,这就为大范围池化提供了支撑。

而这次硬件的变革非常可能又会影响软件的架构。使得大规模并行计算不再须要MPI等远程消息传递机制。消息传递直接使用Fabric硬件加速的队列FIFO,会大大简化编程。有利于HPC的模式终于能够全面得到普及。

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

转载于:https://www.cnblogs.com/ldxsuanfa/p/9964522.html

你可能感兴趣的文章
DP---最长公共子序列
查看>>
#100天计划# 2013年9月27日
查看>>
HDU-2086 A1 = ?
查看>>
主站点~~~~
查看>>
CC150-Array and string 1.1
查看>>
HDU 5880 Family View (AC自动机)
查看>>
简单说一下UWP中的JumpList
查看>>
jQuery控制TR的显示隐藏
查看>>
左偏树
查看>>
Web设计、黄金分割和神之比例
查看>>
Java入门系列 Java 中的四种引用
查看>>
【转】“正由另一进程使用,因此该进程无法访问该文件”的问题&解决方法
查看>>
python 序列化模块
查看>>
《switch platform‘s GPU sync object architecture》
查看>>
Jprofiler分析WebSphere(配置WebSphereagent代理)
查看>>
POJ 1287 Networking
查看>>
python 的正则表达式
查看>>
系统进程的Watchdog [转]
查看>>
activity切换出现应用程序终止的解决方法
查看>>
QOMO Linux 4.0 正式版发布
查看>>