美国债务上限和欧洲债务危机

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享

上周的美国市场显得有些动荡,忽高忽低,一周下来,指数也跌落了一些。这些动荡主要是以欧洲债务危机和美国债务上限为故事开展的。
欧洲本来是希腊危机越演越烈,欧盟疲于应付,不断增加新的救助措施。现在连笨猪四国里比较大的意大利(PIGS Four,葡萄牙,意大利,希腊,西班牙)都面临危机,使得市场相当的恐慌。本来投资者以为意大利因为比较大,所以自身应该可以应付债务,不至于处于危险境地。这里边或者不排除有穆迪氏等评级机构借题发挥,获取利益的可能?
美国债务已经面临上限的限制,如果不立即提高上限,则美国很可能违约,无法偿还利息。中国作为美国最大的债权国,自然对此非常关切。一旦美国违约,其经济可能会再次跌入更深的衰退。穆迪氏和标普都已经发出强烈警告,表示即使提高了债务上限,而没有能够达成有效的债务消减方案也会导致美国的评级被降低。
虽然事态严重,不过美国国会两党却迟迟未能就提高债务上限达成一致。没有国会的批准,政府也没法擅自作主。而两党争论的焦点主要在于如何减少庞大的债务,民主党是希望政府大一些,多向富人收点税;而共和党则希望是不要加税,减少开支,精简政府。共和党为了获取最大的政治利益,以债务上限为筹码,对民主党和奥巴马施加压力,希望迫使民主党做出让步。此时最着急的当然是奥巴马,因为一旦金融市场再次动荡,影响美国经济复苏,他的竞选连任希望可以说会彻底破灭。
这个危机就像美国大片的通常套路,好人总是要与坏蛋搏斗到最后一刻,然后问题解决,全剧结束。上一次美国政府预算案也是两党搏斗到最后一刻,美国政府面临关门的风险,市场剧烈动荡,最后终于在时间快要用完的时候,达成妥协。由于美国政府暂时关闭不是第一次(克林顿时代就有过一次),所以市场对那次危机的反应要强一些。这次的美国债务上限危机,尽管评级机构发出严厉警告,伯南克和盖特纳也都站出来讲话表明事态的严重性,却并没有能够让市场恐慌。不过,两党也都了解,如果无法达成共识,导致经济再次陷入衰退的责任谁也承担不起。因此,市场对于最后债务上限的提高虽然有些忧虑,但是没有陷入恐慌境地。实际上,美国大量印刷纸币,让美元贬值,已经在暗地里减少了自身的债务偿还,完全没有必要再在表面上违约。作为美国的最大债权人,我国也希望美国能够以负责任的态度对待美国国债,而不是拿他人利益当做政治筹码。
上周美国的经济数据在就业市场方面显现了一点重回正轨的信号,首次申领失业救济的人数下降了,如果本周显示这一数据持续降低,很有可能预示着失业率会重新降低而非农就业人数的增加会重回轨道。本周也将发布一些房地产相关的指数,但是由于这些数据不是关键经济数据,市场很可能会继续沿着美国债务上限和财报的故事波动。

(1个打分, 平均:4.00 / 5)

弯曲出品--罗依 (Roy)。《云计算数据中心网络技术》(PDF)

(24个打分, 平均:4.63 / 5)

云计算数据中心网络技术

Sorry to delete

(16个打分, 平均:4.25 / 5)

弯曲财经:美股上周市场评论及对本周市场的展望

上周是两年来美国股市涨幅最大的一周,道指,标普和纳斯达克指数几乎每天都有相当不错的表现。这个主要是上周之前的一个阶段,失业率数据不理想,新增就业又大幅下滑,同时反映房价的CaseShiller指数显示了一种可能double dip的前景,让人们对于经济未来深感忧虑。媒体借机大幅炒作房价二次探底论,失业率下滑论,经济复苏减缓等等。希腊危机的再次引起关注也是媒体在这种背景下的一次借题发挥。在这样的氛围下,人们的悲观情绪蔓延,市场不断下跌。
但是在上周,当数据出来之后,这些悲观的推测有些已经被打破了。首先,在房地产市场方面,房价有了轻微的反弹,四月的Case Shiller指数相比三月上涨了百分之0.7%。另外,上周的二手房签约情况出现了转机,上涨了8.2%。签约后一般会在一到二个月之内完成交易,因此预示着未来二手房销量的增加,能够更快地减少房屋销售存量。 其次,在驱动经济复苏的主要动力制造业上也有好消息。ISM制造业指数55.3好于预期,稍早的Chicago PMI指数也强于预期。这些都使得人们有理由相信之前的经济减缓只是暂时的。同时希腊问题通过了投票,暂时获得了解决。从而,之前打压股市的理由消失了,市场快速反弹。
下周将会发布重要的经济数据,尤其是八号发布的新增非农就业人数以及失业率等。预期这将是市场要过的又一个关口,如果这些数据也有了大幅度提升,市场乐观情绪还会进一步推动市场的上涨。失业率的下降,个人收入的增加表示经济基本面开始好转。克林顿前两天预测失业率下降速度会比多数经济学家预期的速度更快,果真如此的话,市场上涨还会更多。

Weibo 蓝海财经-美股 网址 ibluesea.com

(2个打分, 平均:5.00 / 5)

弯曲出品:《浅谈系统性能优化与技巧》

(5个打分, 平均:4.20 / 5)

对大宋下一代系统软件架构师的七个期望

有诗云:人之老,其言真;人之去;其行善。

系统软件设计是软件系统的皇冠中的宝石。绚烂美丽。令无数男女痴迷。

在系统软件,特别是通信系统软件的设计上,有没有一些可以提炼的方法论?

今身处幽州(北平),心在大宋。聊聊数语。谈谈我对大宋年轻一代的系统软件工程师的期望。

1。 The Thinner vs. The Thicker
年轻人都以为有些事情需要粗,有些事情需要厚。其实,合适就好。。。

系统软件一定要越细越好;越薄越好。

我在华为做speech的时候,也提到过:能把系统软件做薄,才是一代高手。

最可怕的就是为了做而做。

最高境界是:能不做就不做。

每一行代码,都会成为历史(Legacy);每一份恋情都会成为过去。

工程的事情,就是要简简单单。

内在算法的复杂不代表外在的臃肿。

一个女人,要的是清澈美丽;而非妖娆迷人。

智慧者应该做的是cut;而非单纯的add。

2。 Re-Create vs Re-Search

ReCreate是工程之大忌。任何一个问题,必须首先养成良好的科研习惯:
--是否陈首席已经解答过类似的问题。
--是否友商(敌商)解决过类似的问题。
--是否Open Source领域已经解决过类似的问题。
--是否Google和Baidu已经解答过类似的问题。

如果有,拿来主义基础上的改良主义就是最好的。重复发明已经发明了的算法,模型是兵家之大忌。
学术界的Research的意思是:伊人已经在阑珊处;要的是反复寻找,找到你的爱人。
工业界的Recreate是:瞎折腾。利己但害公司。

3。 Qualitative vs Quantitative
大宋文化博大精深,但似乎更多的是在形而上,在君臣父子,为相为官上做文章。

自然科学在中国的错失是我们大宋百年之痛之根本之一

定性和定量分析的有机结合,是成为一个优秀的系统软件架构师的基本素养。

只有定性分析的胶片,是研发之大忌。

一定要养成能case study,算法分析的良好工作习惯。

要的是数据说话;不要的是框架忽悠。
4。 Feature Parity vs Disruptive Innovation

大宋某公司特别喜欢玩一个词汇:技术断裂点。还有一些:领先世界产品的优势点。

这基本上是胡扯。或者从大样本的角度,是胡扯。是文革作风。是党八股。

作为一个工程设计人员,不要羞于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

拿来主义,没人反对。也需要提倡。但如何贡献和反馈给社区,这是每一个大宋系统软件工程师应该反思的。知识共享不仅仅是一个方法论,也应该是一种精神家园。

天天信息安全,什么都藏着,躲着,非一代天骄之所为。

成大事者,必有大胸怀。公司也好;个人也罢。

(25个打分, 平均:4.72 / 5)

拨云见日:虚拟化的最后一公里–虚拟化网卡

最近看到有国内厂家打出“虚拟化网卡”的概念,我认为这个提法是非常有价值的,可以让更多的人开始思考网络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的设置有非常敏感的反应,虚拟机往往要求特殊的端口队列模型,如果模型不对,性能可能大幅下降甚至不可用,而单一的物理网卡无法对上层多个操作系统提供不同的队列服务,进一步影响了性能。
        

image

   

 既然软件交换机是问题,最直接的思路就是绕过软件交换机。因此,VMWare、Intel、AMD等提出了Hypervisor Bypass方案,也就是说虚拟机绕过软件交换机直接同网卡打交道,这样做的好处是一个虚拟机独享一个PCIe通道,想怎么玩就怎么玩,能够实现接近于访问物理PCIe设备的功能和性能。这个方案在主流平台上有不错的支持,VMWare VMDirectPath和Intel VT-d/AMD IOMMU等相关技术都有比较广泛的部署。

image

        

 上面这种形式的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限制。

image

这里有很多针对虚拟接入的非常棒的讨论,下面介绍虚拟通道技术。

 

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)。

  • PF是一个完整的PCIe设备,包含了全面的管理、配置功能,当Hypervisor识别出一块SR-IOV网卡后,会通过PF来管理和配置网卡的所有I/O资源;
  • VF是一个简化的PCIe设备,仅仅包含了I/O功能,无法通过VF对物理网卡进行管理,所有的VF都是通过PF衍生而来,一块SR-IOV网卡最多可以生成256个VF

每一个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数量的增加而增加物理网卡的数量。

image

在业界厂家的大力推广下,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等。

(9个打分, 平均:5.00 / 5)

GPL版陈首席

古之学者必有师。师者,所以传道、受业、解惑也。人非生而知之者,孰能无惑?惑而不从师,其为惑也,终不解矣。生乎吾前,其闻道也固先乎吾,吾从而师之;生乎吾后,其闻道也亦先乎吾,吾从而师之。吾师道也,夫庸知其年之先后生于吾乎?是故无贵无贱,无长无少,道之所存,师之所存也。

嗟乎!师道之不传也久矣!欲人之无惑也难矣!古之圣人,其出人也远矣,犹且从师而问焉;今之众人,其下圣人也亦远矣,而耻学于师。是故圣益圣,愚益愚;圣人之所以为圣,愚人之所以为愚,其皆出于此乎!爱其子,择师而教之,于其身也,则耻师焉,惑矣!彼童子之师,授之书而习其句读(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,
Huailin”

当你啥都不懂的时候,偶像的一句话是会改变人的一生的。首席的几句话改变了我的一生。

* 忘掉细节,牢牢把握基本概念。

*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 来作,这样
1)充分利用 memory bandwidth, 加速 zeroing.
2)bypass cache, 不污染 cache.
3) 可以并行初始化。

在没有量化分析的基础上,我们提出的方案明显是违背直觉的。某 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 吧。
(5个打分, 平均:3.00 / 5)

《云计算核心技术剖析》迷你书连载二 – 云计算的架构

现在当当上面已经开始发货了,希望大家能多买几本送朋友、送佳人和送老板^_^

 

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 SaaS

SaaS是最常见的,也是最先出现的云计算服务。通过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。

  1. Google Apps。中文名为“Google 企业应用套件”,它提供企业版Gmail、Google 日历、Google 文档和Google 协作平台等多个在线办公工具,而且价格低廉,使用方便,并且已经有超过两百万家企业购买了Google Apps服务。
  2. Salesforce CRM。它是一款在线客户管理工具,并在销售、市场营销、服务和合作伙伴这4个商业领域上提供完善的IT支持,还提供强大的定制和扩展机制,来让用户的业务更好地运行在Salesforce平台上。这款产品常被业界视为SaaS产品的“开山之作”。
  3. Office Web Apps。它是微软所开发的在线版Office,提供基于Office 2010技术的简易版Word、Excel、PowerPoint及OneNote等功能。它属于Windows Live的一部分,并与微软的SkyDrive云存储服务有深度的整合,而且兼容Firefox、Safari和Chrome等非IE系列浏览器。和其他在线Office相比,它的最大优势是,由于其本身属于Office 2010的一部分,所以在与Office文档的兼容性方面远胜其他在线Office服务。
  4. Zoho。Zoho是AdventNet公司开发的一款在线办公套件。在功能方面,它绝对是现在业界最全面的,有邮件、CRM、项目管理、Wiki、在线会议、论坛和人力资源管理等几十个在线工具供用户选择。同时包括美国通用电气在内的多家大中型企业已经开始在其内部引入Zoho的在线服务。Zoho在国内的代理商为百会。

3. 优势

虽然和传统桌面软件相比,现有的SaaS服务在功能方面还稍逊一筹,但是在其他方面还是具有一定的优势的,下面是其中的4个方面。

  1. 使用简单。在任何时候或者任何地点,只要接上网络,用户就能访问这个SaaS服务,而且无需安装、升级和维护。
  2. 支持公开协议。现有的SaaS服务在公开协议(比如HTML 4/HTML5)的支持方面都做得很好,用户只需一个浏览器就能使用和访问SaaS应用。这对用户而言非常方便。
  3. 安全保障。SaaS供应商需要提供一定的安全机制,不仅要使存储在云端的用户数据处于绝对安全的境地,而且也要通过一定的安全机制(比如HTTPS等)来确保与用户之间通信的安全。
  4. 初始成本低。使用SaaS服务时,不仅无需在使用前购买昂贵的许可证,而且几乎所有的SaaS供应商都允许免费试用。

4.技术

由于SaaS层离普通用户非常接近,所以大家对SaaS层用到的大多数技术都耳熟能详。下面列出了其中最主要的5种技术。

  1. HTML。它是标准的Web页面技术,现在主要以HTML 4为主。但是即将推出的HTML5会在很多方面推动Web页面的发展,比如视频和本地存储等。
  2. JavaScript。一种用于Web页面的动态语言,通过JavaScript,能够极大地丰富Web页面的功能。最流行的JavaScript框架有jQuery和Prototype。
  3. CSS。主要用于控制Web页面的外观,而且能使页面的内容与其表现形式之间进行优雅地分离。
  4. Flash。业界最常用的RIA(Rich Internet Applications,富因特网应用)技术,能够在现阶段提供HTML等技术所无法提供的基于Web的富应用,而且在用户体验方面也非常不错。
  5. Silverlight。来自微软的RIA技术。虽然它现在的市场占有率稍逊于Flash,但由于它可以使用C#来进行编程,所以对开发者非常友好。

由于通用性和较低的学习成本,大多数云计算产品都会倾向于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。

  1. Force.com。就像上面所说的那样Force.com是业界第一个PaaS平台,它主要通过提供完善的开发环境和强健的基础设施等来帮助企业和第三方供应商交付健壮的、可靠的和可伸缩的在线应用。还有,Force.com本身是基于Salesforce著名的多租户架构的。
  2. Google App Engine。Google App Engine提供Google的基础设施来让大家部署应用,还提供一整套开发工具和SDK来加速应用的开发,并提供大量免费额度来节省用户的开支。
  3. Windows Azure Platform。它是微软推出的PaaS产品,运行在微软数据中心的服务器和网络基础设施上,通过公共互联网来对外提供服务。它由具有高扩展性的云操作系统、数据存储网络和相关服务组成,而且服务都是通过物理或虚拟的Windows Server 2008实例提供的。还有,它附带的Windows Azure SDK(软件开发包)提供了一整套开发、部署和管理Windows Azure云服务所需要的工具和API。
  4. Heroku。它是一个用于部署Ruby On Rails应用的PaaS平台,并且其底层基于Amazon EC2的IaaS服务,而且在Ruby程序员中有非常好的口碑。

3. 优势

和现有的基于本地的开发和部署环境相比,PaaS平台主要有下面这6方面的优势。

  1. 友好的开发环境。通过提供SDK和IDE(Integrated Development Environment,集成开发环境)等工具来让用户不仅能在本地方便地进行应用的开发和测试,而且能进行远程部署。
  2. 丰富的服务。PaaS平台会以API的形式将各种各样的服务提供给上层的应用。
  3. 精细的管理和监控。PaaS能够提供应用层的管理和监控,比如能够观察应用运行的情况和具体数值[比如吞吐量(Throughput)和响应时间(Response Time)等]来更好地衡量应用的运行状态,还能通过精确计量应用所消耗的资源来更好地计费。
  4. 缩性强。PaaS平台会自动调整资源来帮助运行于其上的应用更好地应对突发流量。
  5. 多住户(Multi-Tenant)机制。许多PaaS平台都自带多住户机制,不仅能更经济地支撑庞大的用户规模,而且能提供一定的可定制性以满足用户的特殊需求。
  6. 整合率局。PaaS平台的整合率非常高,比如Google App Engine能在一台服务器上承载成千上万个应用。

4. 技术

与SaaS层所采用的技术不同的是,PaaS层的技术比较多样,下面是常见的5种。

  1. REST。通过REST(Representational State Transfer,表述性状态转移)技术,能够非常方便和优雅地将中间件层所支撑的部分服务提供给调用者。
  2. 多租户。它能让一个单独的应用实例可以为多个组织服务,而且能保持良好的隔离性和安全性。通过这种技术,能有效地降低应用的购置和维护成本。
  3. 并行处理。为了处理海量数据,需要利用庞大的x86集群进行规模巨大的并行处理,Google的MapReduce是这方面的代表之作。
  4. 应用服务器。在原有应用服务器的基础上为云计算作了一定程度的优化,比如用于Google App Engine的Jetty应用服务器。
  5. 分布式缓存。通过这种技术,不仅能有效降低对后台服务器的压力,而且还能加快相应的反应速度。最著名的分布式缓存的例子莫过于Memcached。

对于很多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。

  1. Amazon EC2。EC2主要以提供不同规格的计算资源(也就是虚拟机)为主。它基于著名的开源虚拟化技术Xen。通过Amazon的各种优化和创新, EC2不论在性能上还是在稳定性上都已经满足企业级的需求。而且它还提供完善的API和Web管理界面来方便用户使用。
  2. IBM Blue Cloud。“蓝云”解决方案是由IBM云计算中心开发的业界第一个,同时也是在技术上比较领先的企业级云计算解决方案。该解决方案可以对企业现有的基础架构进行整合,通过虚拟化技术和自动化管理技术来构建企业自己的云计算中心,并实现对企业硬件资源和软件资源的统一管理、统一分配、统一部署、统一监控和统一备份,也打破了应用对资源的独占,从而帮助企业能享受到云计算所带来的诸多优越性。
  3. Cisco UCS。它是下一代数据中心平台,在一个紧密结合的系统中整合了计算、网络、存储与虚拟化功能。该系统包含一个低延时、无丢包和支持万兆以太网的统一网络阵列以及多台企业级x86架构刀片服务器等设备,并在一个统一的管理域中管理所有资源。用户可以通过在UCS上安装VMWare vSphere来支撑多达几千台虚拟机的运行。通过Cisco UCS,能够让企业快速在本地数据中心搭建基于虚拟化技术的云环境。
  4. Joyent。它提供基于Open Solaris技术的IaaS服务。其IaaS服务中最核心的是Joyent Accelerator,它能够为Web应用开发人员提供基于标准的、非专有的、按需供应的虚拟化计算和存储解决方案。基于Joyent Accelerator,用户可以使用具备多核CPU、海量内存和存储的服务器设备来搭建自己的网络服务,并提供超快的访问、处理速度和超高的可靠性。

3. 优势

与传统的企业数据中心相比,IaaS服务在很多方面都存在一定的优势,下面是最明显的5个。

  1. 免维护。主要的维护工作都由IaaS云供应商负责,所以用户不必操心。
  2. 非常经济。首先免去了用户前期的硬件购置成本,而且由于IaaS云大都采用虚拟化技术,所以应用和服务器的整合率普遍在10(也就是一台服务器运行十个应用)以上,这样能有效降低使用成本。
  3. 开放标准。虽然很多IaaS平台都存在一定的私有功能,但是由于OVF等应用发布协议的诞生,IaaS在跨平台方面稳步前进,这样应用能在多个IaaS云上灵活地迁移,而不会被固定在某个企业数据中心内。
  4. 支持的应用。因为IaaS主要是提供虚拟机,而且普通的虚拟机能支持多种操作系统,所以IaaS所支持应用的范围非常广泛。
  5. 伸缩性强。IaaS云只需几分钟就能给用户提供一个新的计算资源,而传统的企业数据中心则往往需要几周时间,并且计算资源可以根据用户需求来调整其资源的大小。

4. 技术

IaaS所采用的技术都是一些比较底层的,其中有4种技术是比较常用的。

  1. 虚拟化。也可以将它理解为基础设施层的“多租户”。因为通过虚拟化技术,能够在一个物理服务器上生成多个虚拟机,并且能在这些虚拟机之间实现全面的隔离,这样不仅能降低服务器的购置成本,而且还能降低服务器的运维成本。成熟的x86虚拟化技术有VMware的ESX和开源的Xen。
  2. 分布式存储。为了承载海量的数据,同时也要保证这些数据的可管理性,所以需要一整套分布式存储系统。在这方面,Google的GFS是典范之作。
  3. 关系型数据库。基本上是在原有的关系型数据库的基础上作了扩展和管理等方面的优化,使其在云中更适应。
  4. NoSQL。为了满足一些关系数据库所无法满足的目标,比如支撑海量数据等,一些公司特地设计一批不是基于关系模型的数据库,比如Google的BigTable和Facebook的Cassandra等。

现在大多数的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个功能。

  1. 管理接口。提供完善的关于服务的Web管理界面和API接口。
  2. 自定义服务。能让用户对服务进行自定义和扩展。
  3. 服务调度。配备强健的机制来负责服务的调度,以使服务能在合理的时间内被系统调用和处理。
  4. 监控服务。利用底层的监控系统来观测服务实际的运行情况。
  5. 流程管理。提供一个工具来让用户将多个服务整合为一个流程,并对它进行管理以提升运行效率。

2. 机制层

这层主要提供各种用于管理云的机制。通过这些机制,能让云计算中心内部的管理更自动化、更安全和更环保。和用户层一样,该层也包括4个模块:运维管理、资源管理、安全管理和容灾支持。

运维管理

云的运行是否出色,往往取决于其运维系统的强健和自动化程度。而和运维管理相关的功能主要包括3个方面。首先是自动维护:运维操作应尽可能地专业和自动化,从而降低云计算中心的运维成本。其次是能源管理:它包括自动关闭闲置的资源,根据负载来调节CPU的频率以降低功耗并提供关于数据中心整体功耗的统计图与机房温度的分布图等来提升能源的管理,并相应地降低浪费。还有就是事件监控:它是通过对在数据中心发生的各项事件进行监控,以确保在云中发生的任何异常事件都会被管理系统捕捉到。

资源管理

这个模块和物理节点的管理相关,比如服务器、存储设备和网络设备等,它涉及下面这3个功能。其一是资源池:通过使用资源池这种资源抽象方法,能将具有庞大数量的物理资源集中到一个虚拟池中,以便于管理。其二是自动部署:也就是将资源从创建到使用的整个流程自动化。其三是资源调度:它将不仅能更好地利用系统资源,而且能自动调整云中资源来帮助运行于其上的应用更好地应对突发流量,从而起到负载均衡的作用。

安全管理

安全管理是对数据、应用和账号等IT资源采取全面保护,使其免受犯罪分子和恶意程序的侵害,并保证云基础设施及其提供的资源能被合法地访问和使用。主要包括下面这7种机制。

  1. 访问授权。为多个服务提供集中的访问控制,以确保应用和数据只能被有授权的用户访问。
  2. 安全策略。实现基于角色或者规则的一整套安全策略,而且还允许系统能模拟策略发生变更的情况以提升安全策略的健壮性。
  3. 安全审计。对安全相关的事件进行全面审计,以检测是不是存在任何隐患。
  4. 物理安全。根据职责限定每个云管理人员不同的权限,比如门禁等。
  5. 网络隔离。使用VPN(Virtual Private Network,虚拟专用网络)、SSL(Secure Sockets Layer,安全套接层)和VLAN(Virtual Local Area Network,虚拟局域网)等技术来确保网络的隔离和安全。
  6. 数据加密。这个机制能确保即使数据被窃取,也不会被非法分子利用。相关的机制有:对称加密和公钥加密等。
  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

采用的主要技术包括以下几种。

  1. SaaS层。基于HTML、JavaScript和CSS这对黄金组合。
  2. PaaS层。在此层,Salesforce引入了多租户内核和为支撑此内核运行而定制的应用服务器。
  3. IaaS层。虽然在后端还是使用在企业环境中很常见的Oracle数据库,但是它为了支撑上层的多租户内核作了很多优化。
  4. 云管理层。Salesforce不仅在用户管理、计费管理、监控系统和资源管理这4个方面有不错的支持,而且在安全管理方面,Salesforce更是提供了多层保护,并支持SSL加密技术等。

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

采用的主要技术有以下几种。

  1. PaaS层:既有经过定制化的应用服务器,比如上面已经提到过的Jetty,也有基于Memcached的分布式缓存服务。
  2. IaaS层。在分布式存储GFS的基础上提供了NoSQL数据库BigTable来持久化应用的数据。
  3. 云管理层。由于App Engine基于Google强大的分布式基础设施,所以它在运维管理技术方面非常出色,同时其计费管理能做到非常细粒度的API级计费,而且App Engine在监控系统和资源管理这两方面都有非常好地支持。
(4个打分, 平均:5.00 / 5)

《云计算核心技术剖析》迷你书连载一 – 首席的推荐和前言

从今天开始,为了让网友们更方便地阅读迷你书的内容,从今天开始将在弯曲上进行连载,由于有一些内容的初稿都已经在弯曲放过了,所以如果看过的话,可以略去。还有,书已经可以在当当网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产业未来的发展。

(4个打分, 平均:5.00 / 5)