美国债务上限和欧洲债务危机
作者 ibluesea | 2011-07-17 20:04 | 类型 弯曲推荐, 行业动感 | 65条用户评论 »
上周的美国市场显得有些动荡,忽高忽低,一周下来,指数也跌落了一些。这些动荡主要是以欧洲债务危机和美国债务上限为故事开展的。 | |
弯曲出品--罗依 (Roy)。《云计算数据中心网络技术》(PDF)
作者 陈怀临 | 2011-07-06 02:38 | 类型 专题分析, 云计算, 弯曲推荐 | 55条用户评论 »
云计算数据中心网络技术
作者 Roy | 2011-07-05 00:51 | 类型 弯曲推荐, 新兴技术, 行业动感 | 132条用户评论 »
工具箱
本文链接 |
|
打印此页 | 132条用户评论 »
弯曲财经:美股上周市场评论及对本周市场的展望
作者 ibluesea | 2011-07-03 06:31 | 类型 弯曲推荐, 行业动感 | 14条用户评论 »
上周是两年来美国股市涨幅最大的一周,道指,标普和纳斯达克指数几乎每天都有相当不错的表现。这个主要是上周之前的一个阶段,失业率数据不理想,新增就业又大幅下滑,同时反映房价的CaseShiller指数显示了一种可能double dip的前景,让人们对于经济未来深感忧虑。媒体借机大幅炒作房价二次探底论,失业率下滑论,经济复苏减缓等等。希腊危机的再次引起关注也是媒体在这种背景下的一次借题发挥。在这样的氛围下,人们的悲观情绪蔓延,市场不断下跌。 Weibo 蓝海财经-美股 网址 ibluesea.com | |
弯曲出品:《浅谈系统性能优化与技巧》
作者 陈怀临 | 2011-06-30 17:19 | 类型 弯曲推荐, 研发动态 | Comments Off
对大宋下一代系统软件架构师的七个期望
作者 陈怀临 | 2011-06-18 17:35 | 类型 弯曲推荐, 研发动态 | 52条用户评论 »
有诗云:人之老,其言真;人之去;其行善。 系统软件设计是软件系统的皇冠中的宝石。绚烂美丽。令无数男女痴迷。 在系统软件,特别是通信系统软件的设计上,有没有一些可以提炼的方法论? 今身处幽州(北平),心在大宋。聊聊数语。谈谈我对大宋年轻一代的系统软件工程师的期望。 1。 The Thinner vs. The Thicker 系统软件一定要越细越好;越薄越好。 我在华为做speech的时候,也提到过:能把系统软件做薄,才是一代高手。 最可怕的就是为了做而做。 最高境界是:能不做就不做。 每一行代码,都会成为历史(Legacy);每一份恋情都会成为过去。 工程的事情,就是要简简单单。 内在算法的复杂不代表外在的臃肿。 一个女人,要的是清澈美丽;而非妖娆迷人。 智慧者应该做的是cut;而非单纯的add。 2。 Re-Create vs Re-Search ReCreate是工程之大忌。任何一个问题,必须首先养成良好的科研习惯: 如果有,拿来主义基础上的改良主义就是最好的。重复发明已经发明了的算法,模型是兵家之大忌。 3。 Qualitative vs Quantitative 自然科学在中国的错失是我们大宋百年之痛之根本之一 定性和定量分析的有机结合,是成为一个优秀的系统软件架构师的基本素养。 只有定性分析的胶片,是研发之大忌。 一定要养成能case study,算法分析的良好工作习惯。 要的是数据说话;不要的是框架忽悠。 大宋某公司特别喜欢玩一个词汇:技术断裂点。还有一些:领先世界产品的优势点。 这基本上是胡扯。或者从大样本的角度,是胡扯。是文革作风。是党八股。 作为一个工程设计人员,不要羞于Feature Parity。学习和模仿美军,伪军的东西,是提高自己的最佳方法。不要上来就是什么断裂点。 邓公稼先都说:我们这几代人要做的是使得国家不要差距加大。 我们这2,3代人能做的是:Follow。领先基本上不存在现实。 这其中,最大的问题不是工程,而是教育的落后。教育的落后使得我们不存在成为一个高科技大国的基础yet。 所以,不要有强迫症,没事玩断裂点。跟上并略微有改良就好。 这就好比,明明不是AV明星,非要玩AV明星的动作。。。受罪。 请把创新留给90后和00后吧。。。 5。 Semi-Optimal Optimization vs Full-Optimal Optimization 工程上,没有最好的算法;只有最好的折衷。 不要过分追求最佳算法。要能把握算法带来的时间和空间上代价的折衷。更为重要的是,在工程上,如果出了问题,调试,调优和定位带来的代价。否则,能解决问题的算法,就是好算法。 6。 Application vs System 系统是为应用服务的。 男人的钱是为你爱的女人而挣的。 做系统不能玩意淫。不能为做系统而做系统。 一切要为人民服务,为应用服务。 只有人民的需要,才是系统软件的需要。 “爱系统软件就是爱人民。是等价的”。这是愚弄人民。 不能本末倒置。 应用和系统是相通的。你能写汇编,也能写object-C。都是逻辑的表达而已。 7。 Proprietary vs Open Source 拿来主义,没人反对。也需要提倡。但如何贡献和反馈给社区,这是每一个大宋系统软件工程师应该反思的。知识共享不仅仅是一个方法论,也应该是一种精神家园。 天天信息安全,什么都藏着,躲着,非一代天骄之所为。 成大事者,必有大胸怀。公司也好;个人也罢。 | |
拨云见日:虚拟化的最后一公里–虚拟化网卡
作者 libing | 2011-06-07 08:00 | 类型 弯曲推荐, 行业动感 | 58条用户评论 »
最近看到有国内厂家打出“虚拟化网卡”的概念,我认为这个提法是非常有价值的,可以让更多的人开始思考网络I/O在虚拟化发展中的重要性,但什么才是“虚拟化网卡”?“虚拟化网卡”有何作用?也许这个概念本身并不清晰,在更多的场合仅被作为一个忽悠的工具在使用。另一方面,今天的服务器网卡确确实实在发生一些重要的变化,这些变化将对整个数据中心产业今后的发展产生至关重要的影响。 我希望通过自己的理解,引来更多高手的讨论,最终对这个概念提出一个明确、清晰的认识。毕竟,技术名词是要落地的,我们需要的是“云计算”而不是“晕计算”。 关键词:虚拟化网卡 厂商:Cisco、Intel 。。。 领域:数据中心网络 模糊程度:四星 缘起:虚拟化的最后一公里 在推动虚拟化轰轰烈烈发展的众多因素中,资源的再利用是很重要的一点,当一台服务器只运行一个业务时,其CPU资源往往没有被充分利用,花大价钱购买的CPU就这样沉睡在机架上,干耗电不干活。大多数客户都希望在部署虚拟化之后,将原来服务器可怜的CPU利用率尽可能提高一些。虚拟化软件(如VMWare vsphere、XEN、KVM等)很好地解决了这个问题,在虚拟化软件中,一颗CPU能够被分配给多个虚机同时使用,部署了虚拟化软件的服务器,其CPU利用率往往能够从不到10%增长到70%左右。 这当然非常棒,可任何新技术的发展都是一个以点带面的过程,好像抗生素的发明虽然挽救了成千上万的生命,但人类至今仍在为对抗其带来的副作用而努力。虚拟化技术也不是真空中的产物,它需要同数据中心内部的主机、存储、硬件等方方面面发生关系,当操作系统的运行方式发生变化时,原先的基础架构并不一定能适应这种变化,新的挑战开始浮出水面, 首先告急的就是内存,当CPU主频在Intel和AMD的竞争中,如脱缰野马一般往前发展时,其他部件并没有以相同的速率前进。内存大小就一度制约了单台服务器上虚拟机–也就是VM(Virtual Machine)–数量的增加,由于大量OS实例同时运行在内存中,服务器的内存容量很快捉襟见肘。为了解决这个问题,各个服务器厂家开始疯狂增加DIMM槽容量,现在单台X86服务器最大内存已经可以达到令人匪夷所思的1TB! 内存警报暂时解除后,网络逐渐成为新的瓶颈。当越来越多不同性质的虚拟机跑在一台物理服务器上时,他们的进出数据都会拥挤在一个I/O通道上,这显然是不合理的。以Cisco为首的网络厂家提出了VN-Tag/VEPA等解决方案,来规范虚拟机流量的转发机制,通过在全网部署VN-Tag,不同虚拟机的流量能够被识别,并且在上联交换机上得到很好的QoS保证和安全隔离,但这只解决了一部分问题,虽然VN-TAG能够区分出来自不同虚拟机的流量,但普通服务器网卡只提供一个PCIe通道,在出口网卡上,这些流量仍然混杂在一块。 单一通道造成问题的典型例子是高性能计算环境。 虚拟软件平台也就是Hypervisor往往集成了一个软件交换机,这个软件交换机通过CPU模拟出简单的二层转发功能。传统的解决方案中,多台虚拟机通过一个Hypervisor软件交换机连接到一张物理网卡上,流量进入软件交换机不但消耗CPU资源还产生了时延,这还不要紧,在高性能计算环境中,上层业务对网络I/O的设置有非常敏感的反应,虚拟机往往要求特殊的端口队列模型,如果模型不对,性能可能大幅下降甚至不可用,而单一的物理网卡无法对上层多个操作系统提供不同的队列服务,进一步影响了性能。
既然软件交换机是问题,最直接的思路就是绕过软件交换机。因此,VMWare、Intel、AMD等提出了Hypervisor Bypass方案,也就是说虚拟机绕过软件交换机直接同网卡打交道,这样做的好处是一个虚拟机独享一个PCIe通道,想怎么玩就怎么玩,能够实现接近于访问物理PCIe设备的功能和性能。这个方案在主流平台上有不错的支持,VMWare VMDirectPath和Intel VT-d/AMD IOMMU等相关技术都有比较广泛的部署。
上面这种形式的Hypervisor Bypass满足了虚拟机对I/O性能的要求,但它远非一个一劳永逸的办法,基本是个半拉子工程,其思路是利用物理网卡为VM直接服务,从而暂时回避了传统I/O跟不上虚拟化发展的问题。最大的缺陷就是每个虚拟机都独占一个PCIe插槽,而插槽意味着什么呢?意味着money!在不断扩张的服务器机房内,每一个PCIe插槽都牵动着能耗、散热和空间的支出,更不用说单台服务器上PCIe插槽的数量上限了。这种以大量占用物理网卡数量为代价的方式很快就会遇到PCIe插槽数量的极限,不是一个可持续发展的方案。 也许有人会问,能不能通过优化Hypervisor的网络功能来解决这个难题呢?首先,网络不是虚拟化软件目前的开发重点;其次,软件的开销太大,普通万兆网卡在多VM的传输环境下已经占用了不少系统资源,如果还要精确、高效地模拟不同虚拟机的传输队列,将会消耗大量CPU资源;最后,软件实现的效率也不高。 随着邮件、OA等简单应用在虚拟化平台上的成功运行,越来越多的重要业务将开始向虚拟化迁移,这些业务中很大一部分都对网络I/O有着严格要求。我们搞定了CPU,搞定了存储,搞定了内存,搞定了交换机,却没来及搞定服务器上一块小小的网卡,当其他所有都不再是限制的时候,I/O这块短板开始慢慢显现,成为阻碍虚拟化发展的最后一个瓶颈,也就是接通虚拟化世界的最后一公里。 所以我们看到”虚拟化网卡”应运而生了,这个概念出现在这个时间点是一件自然而然的事,是技术进化到一个阶段的必然产物,只有跨过这个坎,虚拟化才可能开始向更高的段位发展。 那么,下一个问题就是:什么是虚拟化网卡? 什么是虚拟化网卡? 除了基本的数据转发,上层业务对网络的需求可以归纳为以下两点: 1)安全隔离; 2)服务质量保证QoS 实现这两点的前提都是对数据流量进行清晰的区分,只有区分出不同的流量,才能根据业务类型配以不同的保障等级。如果以服务器出口为界,我们可以将数据流过的路径划分为外部和内部两部分。 对于服务器外部网络:VN-TAG/VEPA可以区分出不同虚拟机的流量,并在整个数据中心内部署有针对性的隔离和QoS策略,我们称为“虚拟接入”; 对于服务器内部:虚拟化网卡要在不破坏现有业务机制的前提下,为每个虚拟机提供一个模拟真实的网络通道,这个模拟出来的虚拟通道不仅仅要对VM透明,而且要尽可能重现在非虚拟化环境中的一切网络机制,我们称为“虚拟通道”。只有在这样的环境中,上层业务在向虚拟化迁移的过程中,才不必因为网络环境的变更而做出改动,从而尽量减小迁移成本,加快迁移流程。虚拟机产生的数据通过独立通道进入网卡 ,紧接着被打上标签送往外部网络,反向亦然,对于上层业务来说,感受不到I/O的变化,所有的数据行为同运行在一台独立物理服务器上无异。 因此,我们可以定义虚拟化网卡的核心是“虚拟接入”和“虚拟通道”,只有补上这两块短板,才真正打通了服务器网卡的虚拟化瓶颈,彻底解决了服务器端的网络I/O限制。 在这里有很多针对虚拟接入的非常棒的讨论,下面介绍虚拟通道技术。
SR-IOV 虚拟通道的实现方式有很多,由于其在未来虚拟化环境中的重要性,大佬们纷纷提前卡位,其中PCI-SIG制定的SR-IOV影响力最大,其背后推手是Intel、Broadcom等巨头。 大多人认识虚拟通道都是从SR-IOV开始,SR即Single Root,IOV为I/O Virtualization,合起来就是将单个PCIe设备(Single Root)–如一个以太网卡–对上层软件虚拟化为多个独立的PCIe设备。 SR-IOV虚拟出的通道分为两个类型,PF(Physical Function)和VF(Virtual Funciton)。
每一个VF都好象物理网卡硬件资源的一个切片,对于虚拟化软件平台Hypervisor来说,这个VF同一块普通的PCIe网卡一模一样,安装相应驱动后就能够直接使用。假设一台服务器上安装了一个单端口SR-IOV网卡,这个端口生成了4个VF,则Hypervisor就得到了四个以太网连接。 SR-IOV的实现依赖硬件和软件两部分,首先,SR-IOV需要专门的网卡芯片和BIOS版本,其次上层Hypervisor还需要安装相应的驱动。这是因为,只有通过PF才能够直接管理网卡的I/O资源和生成VF,而Hypervisor要具备区PF和VF的能力,从而正确地对网卡进行配置。 在SR-IOV的基础上,通过进一步利用Intel VT-d或AMD IOMMU(Input/output memory management unit),直接在VM和VF之间做一对一的映射,在这个过程中,Hypervisor的软件交换机被完全Bypass掉了,同传统的VM DirectPath相比,这种方式即实现了VM对VF硬件资源的直接访问,又无需随着VM数量的增加而增加物理网卡的数量。 在业界厂家的大力推广下,SR-IOV已经成为虚拟化数据中心一个非常重要的演进方案,支持SR-IOV的网卡开始大量出现,其中不得不谈谈的就是Cisco名声大噪的Palo卡。 Cisco Palo Cisco这块红得发紫的网卡大名M81KR,昵称Palo。 Palo是一块SR-IOV网卡,但它又不是一块标准的SR-IOV网卡(×_×!),这句话翻译成人类的语言就是,Palo能够兼容SR-IOV的所有行为,但无需Hypervisor对SR-IOV的支持。 之所以Cisco要玩得这么特立独行,是因为PCI-SIG自推出SR-IOV后,其市场推广并不是太给力,前面说过,要实现多个虚拟通道需要在Hypervisor上安装对应的驱动,但目前为止只有XEN和KVM等开源系统比较积极地提供了对SR-IOV的支持,VMWare vsphere和Microsoft Hyper-v这类主流平台迟迟不见动静。 数据中心市场经过一轮大浪淘沙,已经逐渐明确了未来的发展方向,谁越早拿出一个切实可行的解决方案,客户就会跟谁走。Cisco在数据中心市场提前数年布局,投入不可谓不重,目前看来,思科是是唯一在各个方面有充足储备的厂家,其他人的下一代数据中心网络产品线还很模糊。尽管Nexus平台优势明显,但后面的追兵一刻也没松懈,大家都在争分夺秒地划分地盘,HP已经在给802.1qbg拼命造势,如果这个节骨眼上,客户因为SR-IOV的不成熟限制了虚拟化的部署,拖累了整个市场向虚拟化的转型,相当给了其他厂家喘息的机会,这是Cisco最不希望看到的局面。 因此,思科在Palo上又一次采取了以往屡试不爽的策略,一方面提供对公开标准的支持,一方面抢先推出自己的实现版本,以促进市场尽快成熟。同SR-IOV类似,Palo最大能够实现128个以太或存储通道,但Hypervisor无需支持SR-IOV,思科会单独推出Palo在各个平台上的驱动。能做到这点,一方面是因为思科自身迫切的需求,另一方面,其网络大佬的影响力,也推动了软件厂家的合作。 Palo作为市面上第一块真正意义上的虚拟化网卡,同时实现了基于VN-Tag/802.1qbh的虚拟接入和类似SR-IOV的虚拟通道功能,第一次将网络接入延伸到VM层面。在部署了Palo卡的刀片服务器上,VMWare vsphere上VM的流量被直接发送到一个独立的PCIe通道,这些数据在此随即被打上VN-Tag标记,然后送往上联交换机。在这个环境中,上联交换机、服务器网卡、甚至刀片机框IO模块不再是分裂的对象,而是合并为一个逻辑上统一的接入交换机,这个接入交换机能够直接看到VM的端口,对单个VM的数据流量进行安全隔离,对以太和FCoE流量实施QoS策略,而Hypervisor无需再维护一个软件交换机,原来被软件交换机占用的CPU资源能够用来运行更多的虚拟交换机。 虚拟接入和虚拟通道相辅相成,在Cisco Palo上第一次实现了同物理机类似的虚拟机接入。 后面的故事 近年来,数据中心的发展如火如荼,VN-Tag、FCoE等新技术层出不穷,新一代数据中心架构逐渐成形,虚拟化网卡是这个拼图的最后一块。Cisco Palo作为这个领域的第一个尝试,拉开了服务器网卡的升级序幕,网卡厂家将开始新一轮的技术竞争,MR-IOV、Hypervisor Bypass情况下的虚拟机动态漂移等领域将成为下一代技术热点。而随着虚拟化网卡的不断完善,数据中心的转型将开上一条真正的快车道。 五分钟Q&A 1)什么是虚拟化网卡? 虚拟化网卡要能够对不同的虚拟机提供独立接入,区分不同虚拟机的流量,以提供相应的安全和QoS策略。在实现方式上,虚拟网卡要支持”虚拟接入”和“虚拟通道”技术。 2)什么是“虚拟接入”? “虚拟接入”技术利用标签,在全网范围内区分出不同的虚拟机流量。 3)什么是“虚拟通道”? “虚拟通道”在物理网卡上对上层软件系统虚拟出多个物理通道,每个通道具备独立的I/O功能。 4)什么是SR-IOV? SR-IOV是PCI-SIG推出的一项标准,是“虚拟通道”的一个技术实现,用于将一个PCIe设备虚拟成多个PCIe设备,每个虚拟PCIe设备如同物理物理PCIe设备一样向上层软件提供服务。 5)SR-IOV在网络虚拟化方面有和用处? SR-IOV网卡能对上层操作系统虚拟出多个PCIe网卡,每个网卡可以实现独立的I/O功能。独立的通道能够实现更强的安全隔离、更完善的QoS和更高的传输效率。SR-IOV目前支持在一块PCIe网卡上虚拟出256个通道,是实现虚拟化网卡的基础之一。 6)部署SR-IOV需要什么条件? 部署SR-IOV需要支持SR-IOV的硬件网卡,和支持SR-IOV的软件操作系统。 7)SR-IOV同Hypervisor Bypass是一个玩意吗? 不是。 尽管SR-IOV常常同Intel VT-d等Hypervisor bypass技术配合使用,但两者各自独立,SR-IOV的功能是虚拟出多个PCIe设备,Hypervisor Bypass实现的是虚拟机对底层硬件的直接访问。 8)什么是Cisco Palo? Palo是Cisco推出的兼容SR-IOV的虚拟化网卡,能对上层虚拟出128个以太或存储通道,并且支持VN-TAG/802.1qbh虚拟接入技术。 10)SR-IOV是实现虚拟网卡的唯一方式吗? No 市场还有很多公司提供类似的I/O虚拟化解决方案,如Xsigo等。 | |
GPL版陈首席
作者 coder | 2011-06-06 21:00 | 类型 弯曲推荐, 行业动感 | 14条用户评论 »
古之学者必有师。师者,所以传道、受业、解惑也。人非生而知之者,孰能无惑?惑而不从师,其为惑也,终不解矣。生乎吾前,其闻道也固先乎吾,吾从而师之;生乎吾后,其闻道也亦先乎吾,吾从而师之。吾师道也,夫庸知其年之先后生于吾乎?是故无贵无贱,无长无少,道之所存,师之所存也。 嗟乎!师道之不传也久矣!欲人之无惑也难矣!古之圣人,其出人也远矣,犹且从师而问焉;今之众人,其下圣人也亦远矣,而耻学于师。是故圣益圣,愚益愚;圣人之所以为圣,愚人之所以为愚,其皆出于此乎!爱其子,择师而教之,于其身也,则耻师焉,惑矣!彼童子之师,授之书而习其句读(dòu)者,非吾所谓传其道解其惑者也。句读之不知,惑之不解,或师焉,或不(fǒu)焉,小学而大遗,吾未见其明也。巫医、乐师、百工之人,不耻相师;士大夫之族,曰师曰弟子云者,则群聚而笑之。问之,则曰:“彼与彼年相若也,道相似也。位卑则足羞,官盛则近谀。”呜呼!师道之不复可知矣!巫医、乐师、百工之人,君子不齿。今其智乃反不能及,其可怪也欤! 圣人无常师。孔子师郯(tán)子、苌(cháng)弘、师襄、老聃。郯子之徒,其贤不及孔子。孔子曰:“三人行,则必有我师。”是故弟子不必不如师,师不必贤于弟子。闻道有先后,术业有专攻,如是而已。 李氏子蟠(pán),年十七,好古文,六艺经传(zhuàn),皆通习之,不拘于时,学于余。余嘉其能行古道,作《师说》以贻(yí)之。 今天,我的 Mphil (master by research) thesis 终于评审完了。上来 tektalk 写一篇感谢我的老师,陈首席的文章。感慨万千,不知如何下笔。 copy 一份 《师说》顶置。 05 年,我还是一个大一 freshman,一个月黑风高之夜,在学校网吧 (学校不让大一学生上网,傻逼学校),误入 CLF (www.linuxforum.net)。当时就傻眼了,什么 V 总啊,茶总啊,轮总啊,斯基啊。开始把 CLF 翻个地(注意儿化音)掉。 BNN 的帖子总是直指人心。鼓起勇气给偶像发个信求教一下,没想到,居然收到了回信。 “Sorry for the late reply. I think having a good understanding of computer arch, networking, os, compiler and data structure would be a good start. Since you are even a fresh man yet, please focus on your course study including those math, physics and computer basics. Step by step, have patience; Then you will reach your goal eventually. Best regards, 当你啥都不懂的时候,偶像的一句话是会改变人的一生的。首席的几句话改变了我的一生。 * 忘掉细节,牢牢把握基本概念。 *Computer system 远大于一个 kernel, computer architecture 是 computer system 的核心。 *量化一个系统。 虽然不懂这些话是什么意思,但是牢牢的记住了。 受首席当年在CLF介绍 Xen 和 L4的影响,我有机会在大四的时候去 ERTOS/UNSW ( http://ertos.nicta.com.au/) 作和 L4 有关的 毕业设计。 直到08年本科毕业后去清华陈渝老师那里打杂。首席这个时候已经创办了 tektalk, 我记得是在我评论了一个关于QNX的文章后,首席在 google talk 上加了我。当时激动的几乎晕倒。 想象一下,如果你喜欢打控卫,相当于 斯托克顿 过来跟你打个招呼。 后来我来到了堪培拉村,开始在 ANU 读 Mphil (Master by research). 首席时不时的会指点我两下。字字珠玑。我的 master thesis 的工作离不开首席的鼓励。 09 年的 9 月 1 号,我和首席的一段聊天记录 me: BCORE 我准备动态的 用 write_to_memory 替换 一般的 write
因为一般的write需要 write_allocated
BNN: 你要bypass cache?
me: 恩
BNN: 原因为何?
13:46
I mean, what criteria then for your algorithm?
me: write to cache 需要 1)snooping 得到回复(need waite)
1)需要 allocated cache line
13:47
2)modify it
3)如果连续写的空间很大,又要把以前的modified line 写回去
2 double transactions on links
如果 directly write,
13:48
需要 invilidate cache ilne
和 write back to memory
13:49
BNN: 你的case可以在如下数据访问pattern下解释的过去:
Write without Read.
:写完之后,不会立刻做读操作。
me: 恩
BNN: 否则,代价很大。
me: cache locality 非常不好的情况下
和 不以来这些写顺序的情况下
13:50
BNN: yeah
me: X86的memory consistency对这个write combing 可以 reorder
BNN: 所以,你的算法要与编译结合起来了。
me: 恩
detect
BNN: 这样才能做出漂亮的优化!
最早想去作 compiler 的优化,但是一些商用的 compiler 已经实现了这个功能。后来由于发现 managed language applications 初始化 objects 的开销很大,把这个优化做到了 JVM 里,写了一篇 paper 投到 OOPSLA,然后根据这个 paper 写了我的 thesis.
我的 thesis 讨论了一个非常非常简单的东西:初始化内存。 Managed languages 一般要求创建的 objects 必须是初始化好的 (清 0)。 我们发现这个 清0 开销是很大.
目前的优化一般是想要提高 temporal-locality: 把 清0 留到 创建 objects 的时候来作 (hot-path zeroing)。我们反其道而行之,提出了用 non-temporal instruction 来作,这样 在没有量化分析的基础上,我们提出的方案明显是违背直觉的。某 JVM developer 亲口跟我说 我的方法 make no sense. 我觉得这个 thesis 突出了几个点: 1)优化永远是在量化的基础上来作。
2)Multicore 时代,怎么提高 utilization of shared memory subsystems 是关键。
在thesis, 我写到
“I also would like to thank my shifu, Huailin, who has been teaching me the
architecture of computer systems, and sharing his system-design experiences in the
last few years.”
首席不止影响了我一个人,希望这些影响是GPL的:受到影响的同学继续帮助身边其他的人,这也许就是 education 吧。
| |
《云计算核心技术剖析》迷你书连载二 – 云计算的架构
作者 吴朱华 | 2011-06-02 20:54 | 类型 云计算, 弯曲推荐, 行业动感 | 73条用户评论 »
现在当当上面已经开始发货了,希望大家能多买几本送朋友、送佳人和送老板^_^
IT,身为一个新兴行业,在其发展历程中向其他行业借鉴了一些先进的思想和理念,比如除了前面提到的从电力行业借鉴了公用事业这种商业模式和从丰田汽车流水线生产中总结出精益这套编程模式之外,还在软件设计方面引入了架构这个在建筑行业非常核心的概念。 架构,对软件系统而言是极为重要的。因为它不仅定义了系统内部各个模块之间是如何整合和协调的,同时也对其整体表现起着非常关键的作用。而云,作为一个非常复杂的大型软件系统,其中包含着许许多多的模块和组件,所以如果能够理出其架构的话,将会非常有益。 为了让大家对云计算有更深入的理解,本章将会对云的架构进行深入剖析。除了云的架构之外,本章还将会对云计算最主要和最常见的4种模式进行深入介绍。 2.1 云的架构在对云计算进行了三年多的研究之后,觉得云计算虽然涉及了很多产品与技术,表面上看起来的确有点纷繁复杂,但是云计算本身还是有迹可循和有理可依的,所以在个人理解的基础上,我总结出了一套云计算的架构,具体请看图2-1。 这个云架构共分为服务和管理这两大部分。 在服务方面,主要以提供用户基于云的各种服务为主,共包含3个层次。其一是Software as a Service(软件即服务),简称SaaS,这层的作用是将应用主要以基于Web的方式提供给客户。其二是Platform as a Service(平台即服务),简称PaaS,这层的作用是将一个应用的开发和部署平台作为服务提供给用户。其三是Infrastructure as a Service(基础设施即服务),简称IaaS,这层的作用是将各种底层的计算(比如虚拟机)和存储等资源作为服务提供给用户。从用户角度而言,这3层服务是独立的,因为它们提供的服务是完全不同的,而且面对的用户也不尽相同。但从技术角度而言,云服务这三层是有一定依赖关系的。比如一个SaaS层的产品和服务不仅需要用到SaaS层本身的技术,而且还依赖PaaS层所提供的开发和部署平台或者直接部署于IaaS层所提供的计算资源上,而PaaS层的产品和服务也很有可能构建于IaaS层服务之上。 图2-1 云计算的架构 在管理方面,主要以云的管理层为主,它的功能是确保整个云计算中心能够安全、稳定地运行,并且能够被有效管理。 接下来,将给大家详细介绍每个层次,其中将不仅涉及它们的历史和相关产品,而且还将讨论它们的优势和采用的技术。 2.1.1 SaaSSaaS是最常见的,也是最先出现的云计算服务。通过SaaS这种模式,用户只要接上网络,通过浏览器就能直接使用在云上运行的应用。SaaS云供应商负责维护和管理云中的软硬件设施,同时以免费或者按需使用的方式向用户收费,所以用户不需要顾虑类似安装、升级和防病毒等琐事,并且免去初期高昂的硬件投入和软件许可证费用的支出。 1. 历史 SaaS的前身是ASP(Application Service Provider),其概念和思想与ASP相差不大。最早的ASP厂商有Salesforce.com和Netsuite,其后还有一批企业跟随进来。这些厂商在创业时都主要专注于在线CRM(客户关系管理)应用,但由于那时正值互联网泡沫破裂的时候,而且当时ASP本身的技术也并不成熟,而且还缺少定制和集成等重要功能,再加上当时欠佳的网络环境,所以ASP没有受到市场的热烈欢迎,从而导致大批相关厂商破产。但在2003年后,在Salesforce的带领下,惨存的ASP企业喊出了SaaS这个口号,并随着技术和商业这两方面不断成熟,Salesforce、WebEx和Zoho等国外SaaS企业得到了成功,而国内的企业(诸如用友、金算盘、金碟、阿里巴巴和八百客等)也加入到SaaS的浪潮中。 2. 相关产品 由于SaaS产品起步较早,而且开发成本低,所以在现在的市场上,SaaS产品不论是在数量还是在类别上都非常丰富。同时,也出现了多款经典产品,其中最具代表性的莫过于Google Apps、Salesforce CRM、Office Web Apps 和Zoho。
3. 优势 虽然和传统桌面软件相比,现有的SaaS服务在功能方面还稍逊一筹,但是在其他方面还是具有一定的优势的,下面是其中的4个方面。
4.技术 由于SaaS层离普通用户非常接近,所以大家对SaaS层用到的大多数技术都耳熟能详。下面列出了其中最主要的5种技术。
由于通用性和较低的学习成本,大多数云计算产品都会倾向于HTML、JavaScript和CSS这对黄金组合,但是在HTML5被大家广泛接受之前,RIA技术在用户体验方面还是具有一定优势的,所以Flash和Silverlight也将会有一定的用武之地,比如VMware vCloud就采用了基于Flash的Flex技术,而微软的云计算产品肯定会在今后大量使用Silverlight技术。 2.1.2 PaaS通过PaaS这种模式,用户可以在一个提供SDK(Software Development Kit,即软件开发工具包)、文档、测试环境和部署环境等在内的开发平台上非常方便地编写和部署应用,而且不论是在部署还是在运行的时候,用户都无需为服务器、操作系统、网络和存储等资源的运维操心。 PaaS在整合率上非常惊人,比如一台运行Google App Engine的服务器能够支撑成千上万个应用,也就是说,PaaS是非常经济的。PaaS主要面对的用户是开发人员。 1. 历史 PaaS是云服务这三层之中出现最晚的。业界第一个PaaS平台诞生在2007年,是Salesforce的Force.com,通过这个平台,不仅能使用Salesforce提供的完善的开发工具和框架来轻松地开发应用,而且能把应用直接部署到Salesforce的基础设施上,从而能利用其强大的多租户系统。接着,在2008年4月,Google推出了Google App Engine,从而将PaaS所支持的范围从在线商业应用扩展到普通的Web应用,也使得越来越多的人开始熟悉和使用功能强大的PaaS服务。 2. 相关产品 和SaaS产品百花齐放相比,PaaS产品主要以少而精为主,其中比较著名的产品有:Force.com、Google App Engine、Windows Azure Platform和Heroku。
3. 优势 和现有的基于本地的开发和部署环境相比,PaaS平台主要有下面这6方面的优势。
4. 技术 与SaaS层所采用的技术不同的是,PaaS层的技术比较多样,下面是常见的5种。
对于很多PaaS平台,比如用于部署Ruby应用的Heroku云平台,应用服务器和分布式缓存都是必备的, REST技术常用于对外的接口,多租户技术则主要用于SaaS应用的后台(比如用于支撑Salesforce的CRM等应用的Force.com多租户内核),而并行处理技术常被作为单独的服务推出(比如Amazon的Elastic MapReduce)。 2.1.3 IaaS通过IaaS这种模式,用户可以从供应商那里获得他所需要的计算或者存储等资源来装载相关应用,并只需为其所租用的那部分资源付费,而这些烦琐的管理工作则交给IaaS供应商来负责。 1. 历史 和SaaS一样,类似IaaS的想法其实已经出现很久了,比如过去的IDC(Internet Data Center,互联网数据中心)和VPS(Virtual Private Server,虚拟专用服务器)等,但由于技术、性能、价格和使用等方面的缺失,这些服务并没有被大中型企业广泛采用。但在2006年年底,Amazon 发布了EC2(Elastic Compute Cloud,灵活计算云)这个IaaS云服务。由于EC2在技术和性能等多方面的优势,这类技术终于被业界广泛认可和接受,其中就包括部分大型企业,比如著名的纽约时报。 2. 相关产品 最具代表性的IaaS产品有:Amazon EC2、IBM Blue Cloud、Cisco UCS和Joyent。
3. 优势 与传统的企业数据中心相比,IaaS服务在很多方面都存在一定的优势,下面是最明显的5个。
4. 技术 IaaS所采用的技术都是一些比较底层的,其中有4种技术是比较常用的。
现在大多数的IaaS服务都是基于Xen的,比如Amazon的EC2等,但VMware也推出了基于ESX技术的vCloud,同时业界也有几个基于关系型数据库的云服务,比如Amazon的RDS(Relational Database Service,关系型数据库服务)和Windows Azure SDS(SQL Data Services,SQL数据服务)等。关于分布式存储和NoSQL,它们已经被广泛用于云平台的后端,比如Google App Engine的Datastore就是基于BigTable和GFS这两个技术,而Amazon推出的Simple DB则基于NoSQL技术。 2.1.4 云管理层虽然和前面云服务的三层相比,熟悉云管理层的人非常少,但是它确实是云最核心的部分,就好像一个公司离不开其董事会的管理一样。与过去的数据中心相比,云最大的优势在于云管理的优越性。云管理层也是前面三层云服务的基础,并为这三层提供多种管理和维护等方面的功能和技术。如图2-2所示,云管理层共有9个模块,而且这9个模块可分为3层,它们分别是用户层、机制层和检测层,具体请看图2-2。 图2-2 云管理层的架构 1. 用户层 顾名思义,这层主要面向使用云的用户,并通过多种功能来更好地为用户服务,共包括4个模块:用户管理、客户支持、服务管理和计费管理。 用户管理 对于任何系统而言,对于用户的管理都是必需的,云也是如此。云方面的用户管理主要有3种功能。其一是账号管理:包括对用户身份及其访问权限进行有效地管理,还包括对用户组的管理。其二是单点登录:英文为“Single Sign On”,其意义是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。这个机制可以极大地方便用户在云服务之间进行切换。其三是配置管理:对用户相关的配置信息进行记录、管理和跟踪。配置信息包括虚拟机的部署、配置和应用的设置信息等。 客户支持 好的用户体验对于云而言也是非常关键的,所以帮助用户解决疑难问题的客户支持是必需的,并且需要建设一整套完善的客户支持系统,以确保问题能按照其严重程度或者优先级来依次进行解决,而不是一视同仁。这样,能提升客户支持的效率和效果。 计费管理 利用底层监控系统所采集的数据来对每个用户所使用的资源(比如所消耗CPU的时间和网络带宽等)和服务(比如调用某个付费API的次数)进行统计,来准确地向用户索取费用,并提供完善和详细的报表。 服务管理 大多数云都在一定程度上遵守SOA(Service-Oriented Architecture,面向服务的架构)的设计规范。SOA的意思是将应用不同的功能拆分为多个服务,并通过定义良好的接口和契约来将这些服务连接起来,这样做的好处是能使整个系统松耦合,从而使整个系统能够通过不断演化来更好地为客户服务。而一个普通的云也同样由许许多多的服务组成,比如部署虚拟机的服务、启动或者关闭虚拟机的服务等,而管理好这些服务对于云而言是非常关键的。服务管理主要有下面这5个功能。
2. 机制层 这层主要提供各种用于管理云的机制。通过这些机制,能让云计算中心内部的管理更自动化、更安全和更环保。和用户层一样,该层也包括4个模块:运维管理、资源管理、安全管理和容灾支持。 运维管理 云的运行是否出色,往往取决于其运维系统的强健和自动化程度。而和运维管理相关的功能主要包括3个方面。首先是自动维护:运维操作应尽可能地专业和自动化,从而降低云计算中心的运维成本。其次是能源管理:它包括自动关闭闲置的资源,根据负载来调节CPU的频率以降低功耗并提供关于数据中心整体功耗的统计图与机房温度的分布图等来提升能源的管理,并相应地降低浪费。还有就是事件监控:它是通过对在数据中心发生的各项事件进行监控,以确保在云中发生的任何异常事件都会被管理系统捕捉到。 资源管理 这个模块和物理节点的管理相关,比如服务器、存储设备和网络设备等,它涉及下面这3个功能。其一是资源池:通过使用资源池这种资源抽象方法,能将具有庞大数量的物理资源集中到一个虚拟池中,以便于管理。其二是自动部署:也就是将资源从创建到使用的整个流程自动化。其三是资源调度:它将不仅能更好地利用系统资源,而且能自动调整云中资源来帮助运行于其上的应用更好地应对突发流量,从而起到负载均衡的作用。 安全管理 安全管理是对数据、应用和账号等IT资源采取全面保护,使其免受犯罪分子和恶意程序的侵害,并保证云基础设施及其提供的资源能被合法地访问和使用。主要包括下面这7种机制。
容灾支持 在容灾方面,主要涉及两个层面。其一是数据中心级别。如果数据中心的外部环境出现了类似断电、火灾、地震或者网络中断等严重的事故,将很有可能导致整个数据中心不可用,这就需要在异地建立一个备份数据中心来保证整个云服务持续运行。这个备份数据中心会实时或者异步地与主数据中心进行同步,当主数据中心发生问题的时候,备份数据中心会自动接管在主数据中心中运行的服务。其二是物理节点级别。系统需要检测每个物理节点的运行情况,如果一个物理节点出现问题,系统会试图恢复它或者将其屏蔽,以确保相关云服务正常运行。 3. 检测层 这层比较简单,主要监控这个云计算中心的方方面面,并采集相关数据,以供用户层和机制层使用。 监控系统 全面监控云计算的运行主要涉及3个层面。其一是物理资源层面,主要监控物理资源的运行状况,比如CPU使用率、内存利用率和网络带宽利用率等。其二是虚拟资源层面,主要监控虚拟机的CPU使用率和内存利用率等。其三是应用层面,主要记录应用每次请求的响应时间(Response Time)和吞吐量(Throughput),以判断它们是否满足预先设定的SLA(Service Level Agreement,服务级别协议)。 2.1.5 架构示例在现实的IT环境中,有许多云计算产都符合本章所讲述的架构,其中比较知名的有Salesforce CRM和Google App Engine。为了帮助大家进一步理解云的架构,本节将以这两个著名的云计算产品为例来进行介绍。 1. Salesforce CRM 首先,从用户角度而言,Salesforce CRM属于SaaS层服务,主要通过在云中部署可定制化的CRM应用,来让企业用户在初始投入很低的情况下使用上CRM,并且可根据自身的流程来灵活地定制,而且用户只需接入互联网就能使用。从技术角度而言,Salesforce CRM就像很多SaaS产品一样,不仅用到SaaS层的技术,而且还用到PaaS层、IaaS层和云管理层的技术。图2-3为Salesforce CRM在技术层面上大致的架构。
图2-3 Salesforce CRM 采用的主要技术包括以下几种。
2. Google App Engine 像前文介绍的那样,Google App Engine是一款PaaS服务,它主要提供一个平台来让用户在Google强大的基础设施上部署和运行应用程序,同时App Engine会根据应用所承受的负载来对应用所需的资源进行调整,并免去用户对应用和服务器等的维护工作,而且支持Java和Python这两种语言。在技术上,由于App Engine属于PaaS平台,所以关于显示层的技术选择由应用的自身需求而定,而与App Engine无关。App Engine本身的设计主要集中在PaaS层、IaaS层和云管理层。关于App Engine在技术层面上大致的架构,具体请看图2-4。 图2-4 Google App Engine 采用的主要技术有以下几种。
| |
《云计算核心技术剖析》迷你书连载一 – 首席的推荐和前言
作者 吴朱华 | 2011-05-29 10:21 | 类型 云计算, 弯曲推荐 | 38条用户评论 »
从今天开始,为了让网友们更方便地阅读迷你书的内容,从今天开始将在弯曲上进行连载,由于有一些内容的初稿都已经在弯曲放过了,所以如果看过的话,可以略去。还有,书已经可以在当当网和china-pub上预订,而且下周应该可以发货。 首席的推荐云计算是近年来非常热门的一个词,其含义已经跨越了学术和科技界,融入到了许多社会行业。但到底什么是云计算?是一个运营模式,还是一种技术产品,还是兼而有之? 许多人对此感到很迷惑,吴朱华的这本书恰好很好地回答了上述问题。此外,这本书兼具学术研讨、工程应用和科技普及的价值。 读过本书后,我觉得它对相关专业的大学高年级学生和研究生、研发公司相应产品线的技术人员和从事相关行业战略规划的人甚为有用,实为一本不可多得的好书。 我是通过“弯曲评论”认识吴朱华的,非常佩服他在云计算和当代数据库趋势等各方面的知识积累和创新能力。 他这种花费大量时间和精力把自己所学回馈给社会的精神值得我们肯定、学习并发扬光大。 在未来10 年,云计算一定会在社会各个层面开花结果,甚至会影响到人们生活的细微之处。 希望本书能帮助读者开阔视野、增长知识、提升技能。 陈怀临
前 言
“想要One Piece吗?那就去找吧,我的一切都在那里,在那伟大航道的尽头!”。 ——海贼王,哥尔 •D. 罗杰 如果你不知道什么是“One Piece”,千万不要伤心,因为这只能说明你很成熟。“One Piece”来自于一部非常经典的漫画《海贼王》,指“神秘的宝藏”,也就是海贼王哥尔 •D. 罗杰留下来的财富。这本书描述了男主角“草帽”蒙其•D. 路飞为了得到“One Piece”并当上“海贼王”,而与其伙伴共同踏上“伟大航道”(Grand Line)一起去冒险的经历。读到这里,读者肯定在心中充满了疑问:到底云计算和“One Piece”有什么关系?且听我慢慢道来。 我其实去年年中才开始接触已经被视为新“四大名著”之一的《海贼王》。刚开始的时候,我主要是为了欣赏传说中“女帝”的风采。但是随着剧情的发展,我慢慢地喜欢上了《海贼王》,也开始像很多朋友那样每天都期盼周日能早点到来,因为每周日会有最新一集的动画版《海贼王》。在《海贼王》中我们能看到很多令人感动的东西,比如小冯与路飞的真挚友情、艾斯那永不后退的性格和草帽海贼团生死与共的团队精神等。其中最让我感动的,莫过于有无数的海贼为了得到传说中的“One Piece”,在严酷和危险的伟大航道上面不知疲倦地冒险和拼杀。每当看到此情此景,我都会联想到自己专注的云计算领域。为什么国外国内那么多IT工作者,都像我一样对云计算充满着热切的期望,并为之而不懈奋斗?什么是云计算的“One Piece”?什么东西让我们如此着迷于云计算,如此坚信云计算必将改变这个世界,并推动整个世界的发展? 要回答这些问题,不得不提到一本书,就是这本书使我对云计算的看法从过去的不屑转变为现在的坚信,这本书就是尼古拉斯 •卡尔所著的《大转变:重新认识世界——从爱迪生到Google》。这本书描述了整个IT产业正在经历一个类似电力从发电机发电到电厂供电的巨大转变。这本书不仅改变了我的人生,更是开创了IT领域的“大海贼时代(云计算时代)”。我个人认为这本书在历史上的地位完全可以同托马斯 •弗里德曼的名著《世界是平的》相媲美,堪称“云计算的圣经”。这本书最关键和核心的部分,就是开头关于电力发展史的介绍。由于电力的出现,使大型工业水车这些低效率的动力设备成为了历史,并使发电机成为各个工厂核心设备,同时世界历史上最伟大的发明家爱迪生,在这段时间也因为其通用电气公司而赚足了钱。就在那个发电机为王的时代,爱迪生的徒弟兼私人秘书塞缪尔 •英萨尔却发现了集中供电在成本和使用这两方面巨大的优越性,这使其产生了成立电厂的想法。当然这些想法在爱迪生看来肯定是很愚蠢的,因为在他眼中发电机已经足够强大了。但是随着能长距离传输的交流电技术不断成熟,英萨尔的电厂想法在技术上有了非常坚实的基础,只是在安全性方面交流电和传统的直流电技术相比略有欠缺。之后英萨尔就带领自己的团队开始在美国的芝加哥实践他关于电厂的想法。在实践过程中,不仅技术上遇到了很多挑战,而且商业上也面临着用户的不解,同时更受到早已被人们奉若神明的爱迪生的嘲讽。但是最后由于电厂的规模效益不断增大,电力的价格也随之降低,而且用户使用起来更方便,无需维护和购买任何发电设备。最终,导致电厂几乎成为了唯一的供电方式,而发电机则成为只有少数企业才使用的“奢侈品”。 仔细想来,电力技术的发展和IT技术的发展是何等相似。大型工业水车不由使人们联想起当年IBM的穿孔卡片设备。现在的企业数据中心则是过去每个工厂必备的发电机的翻版,能让电力长距离传输的交流电技术就好比现在让信息四通八达的互联网,而将来的云计算中心则和现在的电厂像是一个模子刻出来的。虽然历史不会简单地重复,但是通过这些对比,应该能让我们对云计算的未来充满信心,并一起去追求云计算的“One Piece”,那就是使用信息和应用就像用电一样便捷,而且成本低廉。比如,能随时随地通过小型和廉价的终端(比如手机和平板电脑)来接入网络,并能通过网络使用各种功能强大的应用和访问海量的信息,而且按需使用,也没有昂贵的前期投入。还有,企业也可以通过将其整个IT基础设施外包来降低其运营成本,专注其主营业务。 本书将引导大家进入云计算这个绚烂的新世界。全书分为四部分:第一部分为理论篇,主要介绍云计算理论方面的知识;第二部分为产品与技术篇,将深入剖析多个顶尖云计算产品的实现,来帮助大家理解云计算是如何设计和实现的,并介绍云计算中非常重要的系统虚拟化技术和安全机制;第三部分为实践篇,将选择云的核心模块之一——分布式数据库作为实践的方向,并以YunTable这个云时代的BigTable为例,来给大家演示如何手工编写和设计一个分布式数据库;最后一部分为展望篇,让我们来猜想和预测一下云计算和整个IT产业未来的发展。 | |