Network Packet Processing in Reconfigurable Hardware

The Motivation for Building Networks with Reconfigurable Hardware

微处理器的性能提升无法满足互联网数据量增长的性能需求,因此需要新的方法来处理互联网数据流; 用可重构硬件构造的网络系统灵活、易修改,可以动态远程安装新的模块化功能组件; 硬件处理网络数据包相对于软件的顺序数据处理有更好的性能表现。 随着互联网的演进,产生了新的协议、特性和功能,比如IPv6、分类流队列、实时音视频,还有防火墙和入侵避免系统来增强网络安全。可重构硬件能用于适应这些演化,FPGA能在逻辑门电路层级可配置,使新服务能在高速骨干网络链接上部署。

NetworkPacketProcessinginReconfigurableHardware

发表在 其他, 科研论文 | 留下评论

基于内存的NoSQL分布式数据库技术研究项目总结

项目的主要产出

  • 完全自主设计了一套针对KV NoSQL数据库的自动化测评软件系统(约5000行C/ShellScript等代码),良好的分层软件架构保证了良好的扩展性,针对目前的测试模型可以全自动生成柱状对比图。
  • 对板内共享内存的局限、板内分布式和缓存技术做了大量测评分析,产出了一组有参考价值的数据。其中探索了缓存淘汰技术的适用性和局限性。
  • 完全自主设计了一套Data-Grid模式的分布式数据库系统(约4000行C代码),其中实现了一种基于一致性Hash的分布式节点管理策略,使其达到了O(1)节点查找性能;另外还实现了基于epoll和多线程方式的服务器并发处理策略。
  • 项目结论 本项目按计划探索了在各种条件下的数据库读性能的极限及其影响因素,顺利完成了研究任务。

NoSQL-总结

发表在 云计算技术, 其他 | 留下评论

理解科学——软件工程研究、实践和教学中的思考

近代科学改变了世界,这为科学主义的盛行和泛滥营造了土壤,至今嫣然已成为主流价值观了,但沿着近代西方科学的路继续往下走的话,是很难再像过去的三百年间那样改造世界创造辉煌,相反却会带来灾难,因此我们必须超越科学主义重新理解科学,这就是本文的由来,但限于笔者的背景是从事软件工程研究、实践和教学工作的,也就从软件工程学科的特点来思考科学理解科学。

一、多元视角下的科学研究传统

对于科学研究我们已经习惯了以数学模型化和实验室实验为主要特征的近代西方实证研究传统,并以此作为科学的唯一依据,形成了科学主义的主流价值观。除了实证研究传统就没有其他科学了吗?或者说实证研究盛行之前人类就没有科学研究?显然答案是否定的。一般我们认为除了实证研究传统,还有哲学传统和博物学传统。自然科学研究的哲学传统的典型例子就是古希腊哲学,古希腊哲学家们开始超越形而下,在形而上的世界思考和探索世界;而博物学传统的典型例子就是中医,中医对中草药和病症的逐一研究、试验探索让人叹为观止。

显然它们分别从不同的角度在探索着自然,形而上的哲学角度和数学模型化方法都在追求自然内在不变的规律,而博物学传统却通过认识多姿多彩多种多样的世界,从中感受自然的内在奥秘。

从方法学的角度看,近代实证科研传统更多地是将研究对象分隔、孤立和抽象的方法进行研究,以此来减小事物的复杂性,总结事物内在的数学模型化规律,然后人为地创造一个割裂孤立的环境来利用所发现的规律,从而服务人类。这种做法本无可厚非,但当人类创造的割裂孤立的环境足够大的时候,就会干扰和破坏大自然本身的生态系统,此时我们所认识的科学已经不再科学了,科学的目标是探索自然服务人类,而今天的科学已开始危害和遗害人类了,因此我们需要跳出近代西方科学的藩篱,从大科学的角度重新理解科学。

二、软件工程的研究对象和研究现状

所谓软件工程即是利用计算机科学来更好地解决问题的一门学问,它是软件工程师利用计算机的功能和理论来编写软件最终更好地解决问题,它的最终结果是计算机软件。由于软件本身的复杂性、易变性和不可见性,再加上软件极具个性,因为不同的软件工程师解决相同的问题开发的软件绝不会相同,哪怕同一个工程师在不同时间解决同一个问题所开发的软件也绝不会完全相同。因此静态地将计算机软件,或者说程序代码,作为研究对象无法揭示软件工程的奥秘,因为计算机软件与它的开发者、开发过程、所要解决问题及其问题所处的环境密切相关。

由此可见,分隔和孤立地研究软件工程中的某一个要素是难以揭示软件工程的内在奥秘的。可现状是软件工程的经典教材无不充斥着分隔和孤立地对软件工程中的某一个要素进行量化研究的内容,很多结论在实践中毫无意义。

科学家们总是固执而执着地迈向真理的深渊无法自拔,而上帝却在悄悄地提醒着人们,《人月神话》和《人件》这两部经典著作的经久不衰即是例证。尽管这两本书也有大量量化研究的内容和结论,但总的来看它围绕着要解决的问题及所处的环境来描述开发者和开发过程,颇有博物学传统的味道。

三、软件工程研究、实践和教学中的思考

由于软件工程实践中开发者是最重要的要素之一,开发者对问题的理解及其开发过程,都是旁观者无法体会甚至很难观察的,显然研究者无法像研究物理学那样以旁观者的身份来考察研究软件工程活动,软件工程研究依然必然需要超越近代西方实证研究的思维局限。

将研究者自己作为主要的研究对象之一,只有近代心理学(精神分析)和中医可以与之相比,弗洛伊德的《精神分析引论》是以案例研究为主,中医更是如此,同时中医又是经过数千年的积淀,而至今依然无法彻底破解生命和疾病的奥秘,或许破解奥秘压根就不是中医的目标,中医的目标是治病救人追求健康和谐。

软件工程不与此类似吗?尽管软件工程才只有短短几十年的历史,但我相信它会像中医一样成为千年积淀的一门学问,研究者只能像中医师一样投身实践,并不断观察、思考和摸索才能窥其一二,也只能以学无止境止于至善的态度投身于软件工程研究、实践和教学中。

鉴于以上理解,具体到软件工程教学中,最有效的教学方法显然是经典案例分析和教师指导下的实践,换句话说没有案例分析(不同课程可以是代码、模式、架构或策略层面的案例)和动手实践的课程不是一门好的软件工程课程。

参考文献:

[1]软件工程 – 理论与实践(第四版 影印版) Software Engineering: Theory and Practice (Fourth Edition),Shari Lawrence Pfleeger,Joanne M. Atlee ,高等教育出版社

[2]邢冬梅、蔡仲老师的《理解科学》课程教学内容

发表在 其他, 科研论文 | 留下评论

大数据研究的科学价值

李国杰
中国科学院计算技术研究所

大数据研究的科学价值.pdf

发表在 云计算技术, 科研论文 | 留下评论

转:虚拟化、云计算、开放源代码及其他

By , October 12, 2012 9:43 am

借国庆长假的机会写了这篇长文,全面地整理了个人从虚拟化到云计算各个层面的看法。主要的内容涉及虚拟化、虚拟化管理、数据中心虚拟化、云计算、公有云与私有云、以及开放源代码。本文的全部内容均属于作者的个人观点,而不代表任何公司的观点。欢迎讨论。

A、虚拟化

虚拟化是指在同一台物理机器上模拟多台虚拟机的能力。每台虚拟机在逻辑上拥有独立的处理器、内存、硬盘和网络接口。使用虚拟化技术能够提高硬件资源的利用率,使得多个应用能够运行在同一台物理机上各自拥有彼此隔离的运行环境。

虚拟化的也有不同的层次,例如硬件层面的虚拟化和软件层面的虚拟化。硬件虚拟化指的是通过模拟硬件的方式获得一个类似于真实计算机的环境,可以运行一个完整的操作系统。在硬件虚拟化这个层面,又有Full Virtualization(全虚拟化,几乎是完整地模拟一套真实的硬件设备。大部分操作系统无须进行任何修改即可直接运行在全虚拟化环境中。)、Partial Virtualization(部分虚拟化,仅仅提供了对关键性计算组件或者指令集的模拟。操作系统可能需要做某些修改才能够运行在部分虚拟化环境中。)和Paravirtualization(半虚拟化,不对硬件设备进行模拟,虚拟机拥有独立的运行环境,通过虚拟机管理程序共享底层的硬件资源。大部分操作系统需要进行修改才能够运行在半虚拟化环境中。)等不同的实现方式。软件层面的虚拟化,往往是指在同一个操作系统实例的基础上提供多个隔离的虚拟运行环境,也常常被称为容器技术。

在硬件虚拟化的层面,现代的虚拟化技术通常是全虚拟化和半虚拟化的混合体。常见的虚拟化技术例如VMWare、Xen和KVM都同时提供了对全虚拟化和半虚拟化的支持。以硬件虚拟化的方式所提供的虚拟机,通常都在运行一个完整的操作系统,在同一台宿主机上存在大量相同或者相似的进程和内存页,从而导致明显的性能损耗。目前,通过KSM等技术可以识别与合并含有相同内容的内存页,但是还没有对大量相同或者相似的进程进行优化处理的有效手段。因此,硬件虚拟化也往往被称为重量级虚拟化,在同一宿主机上能够同时运行的虚拟机数量是相当有限的。在软件虚拟化的层面,同一宿主机上的所有虚拟机共享同一个操作系统实例,不存在由于运行多个操作系统实例所造成的性能损耗。因此,软件虚拟化也往往被称为轻量级虚拟化,在同一宿主机上能够同时运行的虚拟运行环境数量是比较宽松的。以Solaris操作系统上的Container为例,一个Solaris操作系统的实例理论上可以支持多达8000个Container(实际能够运行的Container数量取决于系统资源和负载)。与此类似,Linux操作系统上的LXC可以轻松地在同一宿主机上同时支持数量可观的虚拟运行环境。

在虚拟化这个领域,国内的公司对硬件虚拟化的兴趣较大,在研发和生产环境中也大都采用硬件虚拟化技术。淘宝是国内较早地研究并应用软件虚拟化技术的,他们在淘宝主站的实践经验表明使用cgroup替代Xen能够提升资源利用率。至于在一个实际的应用场景中到底应该选择硬件虚拟化还是软件虚拟化,则应该重点考虑最终用户是否需要对操作系统的完全控制权(例如升级内核版本)。如果最终用户仅仅需要对运行环境的控制权(例如PaaS层面的各种App Engine服务),软件虚拟化可能性价比更高。对于为同一应用提供横向扩展能力的应用场景,软件虚拟化也是比较好的选择。

对于需要深入了解虚拟化技术的技术人员来说,VMWare发表的白皮书《Understanding Full Virtualization, Paravirtualization, and Hardware Assist》是一份很好的参考资料。

通常来讲,能够直接使用虚拟化技术的用户数量是比较少的。以Linux操作系统为例,能够进行虚拟机生命周期管理的用户,一般就是具有访问libvirt权限的用户。在一个公司或者其他实体中,这些用户通常是系统管理员。

B、虚拟化管理

早期的虚拟化技术,解决的是在同一台物理机上提供多个相互独立的运行环境的问题。当需要管理的物理机数量较小时,系统管理员可以手动登录到不同的物理机上进行虚拟机生命周期管理(资源配置、启动、关闭等等)。当需要管理的物理机数量较大时,就需要写一些脚本/程序来提高虚拟机生命周期管理的自动化程度。以管理和调度大量物理/虚拟计算资源为目的软件,称为虚拟化管理工具。虚拟化管理工具使得系统管理员可以从同一个位置执行如下任务:(1)对不同物理机上的虚拟机进行生命周期管理;(2)对所有的物理机和虚拟机进行查询甚至监控;(3)建立虚拟机命名与虚拟机实例直接的映射关系,使得虚拟机的识别和管理更加容易。Linux操作系统上的VirtManager是一个简单的虚拟化管理工具。在VMWare产品家族中,VMWare vSphere是一个功能强大的虚拟化管理工具。

虚拟化管理工具是虚拟化技术的自然延伸。简单的虚拟化管理工具,解决的是由于物理机数量增多所导致的工作内容繁杂问题。在这个层面,虚拟化管理通常和集群的概念同时出现。一个虚拟化管理工具,往往需要获得各台物理机上的虚拟机生命周期管理权限(例如具有访问libvirt权限的用户名和密码)。在同一个集群当中,为了方便起见,可能需要设定一个在整个集群层面通用的管理用户。可以认为,虚拟化管理为系统管理员提供了便利,但是并没有将虚拟机生命周期管理的权限下放给其他用户。

C、数据中心虚拟化

在数据中心的层面,系统管理员需要面对大量不同类型的硬件和应用。与小型的集群相比较,数据中心的系统复杂度大大提高了。这时简单的虚拟化管理工具已经无法满足系统管理员的要求,因此在虚拟化管理工具的基础上又发展出各种数据中心虚拟化管理系统。在硬件层面,数据中心虚拟化管理系统通过划分资源池(一个资源池通常是一个集群)的方式对硬件资源进行重新组织,并以虚拟基础构架(Virtual Infrastructure)的方式将计算资源暴露给用户。在软件层面,数据中心虚拟化管理系统引入系统管理员和普通用户两种不同的角色,甚至是基于应用场景的需要设定颗粒度更细的基于角色的权限控制(Role Based Access Control,RBAC)。系统管理员对整个数据中心的物理机和虚拟机拥有管理权限,但是一般不对正常的虚拟机进行干涉。普通用户只能在自己具有权限的资源池内进行虚拟机生命周期管理操作,不具有控制物理机的权限。在极端的情况下,普通用户只能够看到分配给自己的资源池,而不了解组成该资源池物理机细节。

在数据中心虚拟化之前,创建虚拟机的动作是需要系统管理员来完成的。在数据中心虚拟化管理系统中,通过基于角色的权限控制,虚拟机生命周期管理的权限被下放给所谓的“普通用户”,在一定程度上可以减轻系统管理员的负担。但是,出于系统安全的考虑,并不是公司里所有的员工都能够拥有这样的“普通用户”账号。一般来说,这种“普通账号”只能够分配给某个团队的负责人。可以认为,一直到数据中心虚拟化这个层面,虚拟机的生命周期还是集中式管理的。

数据中心虚拟化管理系统是虚拟化管理工具的进一步延伸,它所解决的是由于硬件和应用规模上升所带来的系统复杂度问题。具体的物理设备被抽象成资源池之后,公司高管只需要了解各个资源池的规模、负载和健康状况,最终用户只需要了解分配给自己的资源池的规模、负载和健康状况。只有系统管理员还需要对每一台物理设备的配置、负载和故障了如指掌,但是资源池的概念也从逻辑上对所有的物理设备进行了重新整理和分类,使得系统管理员的工作变得更加容易了。

现代的数据中心虚拟化管理系统,往往提供了大量有助于运维自动化的功能。这些功能包括 (1)基于模板快速部署一系列相同或者是相似的运行环境;(2)监控、报表、预警、会计功能;和(3)高可用性、动态负载均衡、备份与恢复等等。一些相对开放的数据中心虚拟化管理系统,甚至以开放API的方式使得系统管理员能够根据自身的应用场景和流程开发额外的扩展功能。

在VMWare产品家族中,VMWare vCenter是一个数据中心虚拟化管理软件。其他值得推荐的数据中心虚拟化管理软件包括Convirt、XenServer、Oracle VM、OpenQRM等等。

D、云计算

云计算是对数据中心虚拟化的进一步封装。在云计算管理软件中,同样需要有云管理员和普通用户两种(甚至更多)不同的角色以及不同的权限。管理员对整个数据中心的物理机和虚拟机拥有管理权限,但是一般不对正常的虚拟机进行干涉。普通用户可以通过浏览器自助地进行虚拟机生命周期管理 ,也可以编写程序通过Web Service自动地进行虚拟机生命周期管理。

在云计算这个层面,虚拟机生命周期管理的权限被彻底下放真正的普通用户,但是也将资源池和物理机等等概念从普通用户的视野中屏蔽了。普通用户可以获得计算资源,但是无需对其背后的物理资源有任何了解。从表面看,云计算似乎就是以与Amazon EC2/S3相兼容的模式提供计算资源。在实质上,云计算是计算资源管理的模式发生了改变,最终用户不再需要系统管理员的帮助即可自助地获得获得和管理计算资源。

对于云管理员来说,将虚拟机生命周期管理权限下放到最终用户并没有降低其工作压力。相反,他有了更加令人头疼的事情需要去处理。在传统的IT架构中,往往 是一个应用配备一套计算资源,应用之间存在物理隔离,问题诊断也相对容易。升级到云计算模式之后,多个应用可能共享同一套计算资源,应用之间存在资源竞 争,问题诊断就相对困难。因此,云管理员往往希望选用的云计算管理软件能够有相对全面的数据中心虚拟化管理功能。对于云管理员来说,至关重要的功能包括 (1)监控、报表、预警、会计功能;(2)高可用性、动态负载均衡、备份与恢复等等;和(3)动态迁移,可以用于局部负载调整以及故障诊断。

显而易见,从虚拟化到云计算,对物理资源的封装程度不断提高,虚拟机生命周期的管理权限逐步下放。

在VMWare产品家族中,VMWare vCloud是一个云计算管理软件。其他值得推荐的云计算管理软件包括OpenStack、OpenNebula、Eucalyptus和CloudStack。虽然OpenStack、OpenNebula、Eucalyptus和CloudStack都是云计算管理软件,但是其功能有较大的差别,这些差异源于不同 的软件具有不同的设计理念。OpenNebula和CloudStack最初的设计目标是数据中心虚拟化管理软件,因此具有比较全面的数据中心虚拟化管理 功能。云计算的概念兴起之后,OpenNebula增加了OCCI和EC2接口,CloudStack则提供了称为CloudBridge的额外组件 (CloudStack从 4.0版本开始缺省地包含了CloudBridge组件),从而实现了与Amazon EC2的兼容。Eucalyptus和OpenStack则是以Amazon EC2为原型自上而下地设计成云计算管理软件的,从一开始就考虑与Amazon EC2的兼容性(OpenStack还增加了自己的扩展),但是在数据中心虚拟化管理方面的功能尚有所欠缺。在这两者当中,Eucalyptus项目由于起步较早,在数据中心虚拟化管理方面的功能明显强于OpenStack项目。

E、私有云与公有云

如D 所述的云计算,仅仅是一种狭义上的云计算,或者是与Amazon EC2相类似的云计算。 广义上的云计算,可以泛指是指各种通过网络访问物理/虚拟计算机并利用其计算资源的实践,包括如D 所述的云计算和如C 所述的数据中心虚拟化。这两者的共同点在于云计算服务提供商以虚拟机的方式向用户提供计算资源,用户无须了解虚拟机背后实际的物理资源状况。如果某个云平台仅对某个集团内部提供服务,那么这个云平台也可以被称为“私有云”;如果某个云平台对公众提供服务,那么这个云平台也可以被称为“公有云”。一般来说,私有云服务于集团内部的不同部门(或者应用),强调虚拟资源调度的灵活性(例如最终用户能够指定虚拟机的处理器、内存和硬盘配置);公有云服务于公众,强调虚拟资源的标准性(例如公有云服务提供商仅提供有限的几个虚拟机产品型号,每个虚拟机产品型号的处理器、内存和硬盘配置是固定的,最终用户只能够选择与自身需求最为接近的虚拟机产品型号)。

对于公有云服务提供商来说,其业务模式与Amazon EC2相类似。因此,公有云服务提供商通常应该选择如D 所述的云计算管理软件。对于私有云服务提供商来说,则应该根据集团内部计算资源的管理模式来决定选用的软件。如果对计算资源进行集中式管理,仅仅将虚拟机生命周期管理的权限下放到部门经理或者是团队负责人这个级别,那么就应该选择如C 所述的数据中心虚拟化管理系统。如果要将虚拟机生命周期管理的权限下放到真正需要计算资源的最终用户,则应该选择如D 所述的云计算管理软件。

传统上,人们认为私有云是建立在企业内部数据中心和自有硬件的基础上的。但是硬件厂商加入云计算服务提供商的行列之后,私有云与公有云之间的界限变得越来越模糊。Rackspace推出的私有云服务,客户可以选择使用自有的数据中心和硬件,也可以选择租用Rackspace的数据中心和硬件。Oracle最近更进一步提出了“由Oracle拥有并管理”( Owned by Oracle, Managed by Oracle)的私有云服务。在这种新的业务模式下,客户所独享的私有云是仅仅是云服务提供商的公有云当中与其他客户相对隔离的一个资源池(you got private cloud in my public cloud)。而对于云服务提供商来说,用于提供公有云服务的基础构架可能仅仅是其自有基础构架(私有云)中的一个资源池,甚至是硬件厂商自有基础构架(私有云)中的一个资源池(you got public cloud in my private cloud)。

对于客户来说,使用基于云服务提供商的数据中心和硬件的私有云服务在财务上是合理的。这样做意味着自建数据中心和采购硬件设备的固定资产投入(CapEX)变成了分期付款的运营费用(OPEX),宝贵的现金则可以作为用于拓展业务的周转资金。即使长期下来拥有此类私有云的总体费用比自建数据中心和采购硬件设备要高,但是利用多出来的现金进行业务拓展所带来的回报可能会超过两个方案之间的费用差额。在极端的情况下,即使企业最终没有获得成功,也无需心疼新近购置的一大堆硬件设备。除非是房地产市场在短时间内有较大的起色,一家濒临倒闭的公司通常是不会为没有自建一个数据中心而感到后悔的。(需要指出的是,对于一家能够长时间运作的公司来说,通过房地产来盈利是完全有可能的。在Sun 公司被Oracle公司收购之前,就曾经通过变卖祖业的方式使得财报扭亏为盈。)

那么,硬件厂商在这场游戏里面扮演的是什么角色呢?当用户的固定资产投入(CapEX)变成了分期付款的运营费用(OPEX)时,硬件厂商难道不是需要更长的时间才能够收回货款吗?

1865年,英国经济学家威廉杰文斯(Willian Jevons,1835-1882)写了一本名为《煤矿问题》(The Coal Question)的书。杰文斯描述了一个似乎自相矛盾的现象:蒸汽机效率方面的进步提高了煤的能源转换率,能源转换率的提高导致了能源价格降低,能源价格的降低又进一步导致了煤消费量的增加。这种现象称为杰文斯悖论,其核心思想是资源利用率的提高导致价格降低,最终会增加资源的使用量。在过去150年当中,杰文斯悖论在主要的工业原料、交通、能源、食品工业等多个领域都得到了实证。

公共云计算服务的核心价值,是将服务器、存储、网络等等硬件设备从自行采购的固定资产变成了按量计费的公共资源。虚拟化技术提高了计算资源的利用率,导致了计算资源价格的降低,最终会增加计算资源的使用量。明白了这个逻辑,就能够明白为什么HP会果断加入OpenStack的阵营并在OpenStack尚未成熟的情况下率先推出基于基于OpenStack的公有云服务。固然,做云计算不一定能够拯救HP于摇摇欲坠之中,但是如果不做云计算,HP恐怕就时日不多了。同样,明白了这个逻辑,就能够明白为什么Oracle会从对云计算嗤之以鼻摇身一变称为云计算的实践者。收购了Sun 公司之后,Oracle一夜之间变成了世界领先的硬件提供商。当时云计算的概念刚刚兴起,Oracle不以为然的态度说明它尚未充分适应自身地位的变化。如今云计算已经从概念炒作进入实战演习阶段,作为主要硬件厂商之一的Oracle如果不打算从云计算中分一杯羹的话,那就是真正的反射弧过长了。

根据杰文斯悖论,对于用户来说,价格降低是用量增加的前提。那么,应该如何给云计算资源定价呢?

目前,大部分公有云服务提供商的虚拟机产品都是按照配置定价的。以Amazon EC2为例,其中型(Medium)虚拟机(3.75 GB内存,2 ECU计算单元,410 GB存储,0.16美元每小时)的配置是小型(Small)虚拟机(1.7 GB内存,1 ECU计算单元,160 GB存储,0.08美元每小时)的两倍,其价格也是小型虚拟机的两倍。新近推出的HP Cloud Services,以及国内的盛大云和阿里云,基本上都照搬Amazon EC2的定价方法。问题在于,虚拟机的配置提高之后,虚拟机的性能并没有得到同比提高。一系列针对Amazon EC2、HP Cloud Services、盛大云和阿里云的性能测试结果表明,对于多种类型的应用来说,随着虚拟机配置的提高,其性价比实际上是不断降低的。这样的定价策略,显然不能达到鼓励用户使用更多计算资源的目的。

按照虚拟机的性能来定价可能是一个更加合适的做法。举个例子说,某个牌子的肥皂有大小两种包装,小包装有一块肥皂而大包装有两块肥皂。用户愿意花双倍的钱购买大包装,往往是因为大包装能够洗两倍的衣服而不是因为它看起来更大。同理,来自同一公有云服务提供商的不同虚拟机产品,应该尽可能使其性价比维持在同一水平线上。问题在于,不同类型的应用对处理器、内存和存储等计算资源的需求存在较大差异,其“性能–配置”变化曲线也各有不同。因此,在公有云服务领域需要一个对虚拟机性能进行综合评估的框架,通过该框架获得的评估结果可以表示一台虚拟机的综合处理能力,而不仅仅是处理器、内存和存储当中的任何一项。基于这样一个测试框架,不仅可以对同一公有云服务提供商的产品进行比较,还可以对不同公有云服务提供商的产品进行比较。

F、开放源代码

近些年来,我们在信息技术领域观察到一个规律。当一个闭源的解决方案在市场上取得成功时,很快就会出现一个甚至是多个提供类似功能(或者服务)的开源或者闭源的追随者。(首先出现开源软件,然后出现与之竞争的闭源软件的案例比较少见。)在操作系统领域,Linux逐渐达到甚至是超越了Unix的技术水平,进而取代Unix的市场地位。在虚拟化领域,Xen和KVM紧紧跟随VMWare的技术发展并有所突破,逐步蚕食VMware的市场份额。在云计算领域,Enomaly率先推出了以Amazon EC2为蓝本的闭源解决方案,紧跟着又出现了以Eucalyptus和OpenStack为代表的开源解决方案。与此同时,传统意义上的闭源厂商对开源项目和社区的态度也在发生转变。例如,多年来对开源项目持敌视态度的微软于今年四月组建了一家名为“微软开放技术”(Microsoft Open Technologies)的子公司,其目标是推进微软向开放领域的投资,包括互操作性、开放标准和开源软件。

我们今天所处的商业环境,与上个世纪80年代自由软件运动(Free Source Movement)刚刚兴起的时候已经有了较大的不同。自1998年NetScape第一次提出开放源代码(Open Source)这个术语起,开放源代码就已经成为一种新的软件研发、推广与销售模式,而不再是与商业软件相对立的替代品了。与传统的闭源软件商业模式相对比,基于开放源代码的商业模式具有如下特点:

(1)在项目萌芽阶段,通过开源软件或者自由软件等关键词吸引潜在客户以及合作伙伴。对于潜在客户来说,选择开源软件能够免费或者是低价获得闭源软件的(部分)功能。对于合作伙伴来说,其兴趣点可能在于销售基于开源软件的增强版本(例如企业版),提供基于开源软件的解决方案,或者是该开源软件的成功可能对其自身的产品的销售有促进作用。

(2)在项目成长阶段,主要的研发人员来自发起项目的企业以及该项目的企业合作伙伴。虽然也有一些单纯出于兴趣而向开源项目贡献代码的个人开发者,但是其数量相对较少。我们在开源软件的宣传资料当中经常会见到类似于“由某某社区开发”的描述。最近10年来,各种“社区”中的主要研发力量始终来自数量极为有限的企业合作伙伴。但是有些开源项目在宣传中通常会有意无意地淡化企业合作伙伴的重要性,甚至是误导受众以为社区的主要成分是个人开发者。

(3)在项目收割阶段,项目发起者以及主要合作伙伴可以通过销售增强版本或者是提供解决方案获取财务回报。虽然其他厂商也可以提供类似的产品或者服务,但是开源项目的主要参与者往往在市场上拥有更大的话语权和权威性。关于开源项目的盈利问题,Marten Mickos(Eucalyptus的CEO)在担任MySQL公司CEO期间曾指出:“如果要在开源软件上取得成功,那么你需要服务于:(A)愿意花费时间来省钱的人;和(B)愿意花钱来节约时间的人。”如果说一个公司在开源方面取得了成功,那么它从开源软件的销售和服务方面获得的回报至少应该大于在研发和推广方面的投入。显而易见,某些用户之所以能够免费使用开源软件,一方面固然是因为他们的参与降低了开源软件在研发和推广方面的投入,另一方面则是因为付费用户为开源软件付出了更多的钱。

那么,为什么基于开源软件的解决方案通常要比其闭源的竞争对手更便宜呢?通常来说,闭源软件作为一个领域的开创者,在市场研究、产品设计、研发测试、推广销售等等环节都面临很大的挑战。开源软件作为闭源软件的追随者,在市场研究方面有闭源软件作为成功案例,在产品设计方面有闭源软件作为参考模板,在推广销售方面也得益于闭源软件的市场拓展。在研发方面,开源软件出现的时间要稍晚于闭源软件,在这个时间段里发生的技术进步会明显降低开源软件进入相关领域的门槛。除此之外,开源软件可能在某些特性方面超越闭源软件,但在总体水平上其功能的完备性、易用性、稳定性、可靠性会稍逊于闭源软件。因此,基于开源软件的解决方案通常会采取“以闭源软件30%的价格提供闭源软件80%的功能”这样的营销思路。除此之外,基于开源软件的解决方案的可定制性对于某些客户来说也有特别的吸引力。

在中国的商业环境中,IT公司(或者说互联网公司)通常是愿意花费时间来省钱的,而非IT公司(或者说传统行业)通常是愿意花钱来节约时间的。需要指出的是,中国的非IT公司往往不在乎软件是否开源,但是非常注重开源软件的可定制性。

开放源代码作为一种新的商业模式,并不比传统的闭源模式具有更高的道德水准。同理,在道德层面上对不同的开放源代码实践进行评判也是不合适的。在OpenStack项目的萌芽阶段,Rackspace公司的宣传文案声称OpenStack是“世界上唯一真正开放源代码的IaaS系统”。CloudStack、Eucalyptus和OpenNebula等具有类似功能的开源项目由于保留了部分闭源的企业版(2012年4 月以前,CloudStack项目和Eucalyptus均同时发布完全开源的社区版和部分闭源的企业版。2012年4 月之后,Eucalyptus项目宣布全面开源,CloudStack项目被Citrix收购并捐赠给Apache基金会后也全面开源。)、或者是仅向付费客户提供的自动化安装包(OpenNebula Pro是一个包含了增强功能的自动化安装包,但是其全部组件都是开放源代码的。)而被Rackspace归类为“不是真正的开放源代码项目”。类似的宣传持续了接近两年时间,直到Rackspace公司推出了基于OpenStack项目的Rackspace Private Cloud软件 — 一个性质上与OpenNebula Pro类似的自动化包。OpenNebula Pro是一个仅向付费用户提供的软件包,但是任何用户都可以免费地下载与使用Rackspace Private Cloud软件。问题在于,当用户所管理的节点数量超过20台服务器时,就需要向Rackspace公司寻求帮助(购买必要的技术支持)。这里我们暂且不讨论将节点数量限制为20台服务器这部分代码是否开源的问题。开源项目的发起者和主要贡献者在其重新打包的发行版中添加了限制该软件应用范围的功能,从道德层面来看很难解释,但是在商业层面来看就很正常。在过去两年中,OpenStack项目在研发、推广、社区等领域所采取的种种措施,都堪称是基于开放源代码的商业模式的经典案例。

前面我们提到,在同一领域往往存在多个相互竞争的开源项目。以广义上的云计算为例,除了我们熟悉的CloudStack、Eucalyptus、OpenNebula、OpenStack之外,还有Convirt、XenServer、Oracle VM、OpenQRM等等诸多选择。针对一个特定的应用场景,如何在众多的开源方案中进行选型呢?根据我个人的经验,可以将整个方案选型过程分为需求分析、技术分析、商务分析三个阶段。

(1)在需求分析阶段,针对特定的应用场景深入挖掘该项目采用云计算技术的真正目的。在中国,很多项目决策者对云计算的认识往往停留在“提高资源利用率、降低运维成本、提供更多便利”的阶段,并没有意识到这个列表已经是大部分开源软件均可提供的基本功能。除此之外,很多项目决策者缺省地将VMWare vCenter提供的全部功能作为对开源软件的要求,而没有考虑特定项目是否需要这些功能。因此,非常有必要针对特定的应用场景进行调研,明确将其按照数据中心虚拟化和狭义上的云计算归类,并进一步挖掘项目在功能上的具体要求。在很多情况下,数据中心虚拟化和狭义上的云计算均能够满足客户的总体需求,那么销售的任务就是将客户的具体需求往有利于自身的方向上引导。这个技巧,我们称之为客户期望值管理(Expectation Management)。通过需求分析,明确特定应用场景的分类,可以过滤掉一部分选项。

(2)在技术分析阶段,首先比较各个开源软件的参考架构,重点考虑在特定应用场景下按照参考构架进行实施所面临的困难。其次在功能的层面对各个开源软件进行对比,并将必须具备的功能(Must Have)和能够加分的功能(Good to Have)区别对待。除此之外,还可以对安装配置的难易程度、具体功能的易用性、参考文档的完备性、二次开发的可能性等等进行评估。通过技术分析,可以给各个开源软件打分排名,在此基础上可以淘汰掉得分最低的选项。

(3)在商务分析阶段,必须明确决策者是否愿意为开源的解决方案付费。如果决策者不愿意为付费,那么该项目就属于“愿意花费时间来省钱”的场景,反之则属于“愿意花钱来节约时间”的场景。对于愿意花费时间来省钱的应用场景,主要依赖于开源社区获得技术支持,可以将开源项目的社区活跃度作为重要的参考数据。对于愿意花钱来节省时间的应用场景,主要依赖于服务提供商获得技术支持,应该重点考察服务提供商在业界的影响力以及在本地的服务能力,开源项目的社区活跃度则显得无关紧要了。

在中国(狭义上)的云计算市场, 对于愿意付费的客户来说,CloudStack和Eucalyptus是值得优先考虑的选项。这两个项目的启动时间比较早,具有更好的稳定性和可靠性,在业界有较大的影响力,并且在国内有团队可以提供支持和服务。与此同时,国内一些创业团队开始提供基于OpenStack的解决方案,但是在短时间内很难积累必要的实战经验,而具备丰富经验的新浪SAE团队尚未开拓对外提供技术支持的业务。国内虽然也有一些单位在使用OpenNebula,但是在近期内很难形成对第三方提供技术服务的能力。对于愿意花时间的客户来说,CloudStack和OpenStack的优势较为明显,因为两者的社区活跃度相对较高。在这两者当中,CloudStack的功能更加丰富,也有更多的企业级客户以及成功案例,可能是短期内的更佳选择。从长远来看,基于OpenStack的解决方案会越来越流行,但是其他解决方案在技术和市场上也都在不断取得进步,因此在未来三年内很难形成一统天下的局面。单纯从商业上考虑,CloudStack和Eucalyptus获得成功的几率可能会更大一些。

G、其他

有些朋友希望我补充一些云计算在中国的现状。坦率地说,目前我尚不掌握充足的数据,在这里暂不展开论述。刘黎明(新浪微博@刘黎明3000)最近发布了一篇题为《点评阿里云盛大云代表的云计算IaaS产业》的文章,值得参考。

关于不同开源项目的社区活跃度比较,可以参考我最近的一篇博客文章《CY12-Q3 OpenStack, OpenNebula,Eucalyptus,CloudStack社区活跃度比较》。另外,我在《HP Cloud Services性能测试》一文中,也初步提出了一个对公有云进行性能评测的方法。

本文中的所有插图,全部来自Google搜索。除此之外,部分概念性内容参考了维基百科的相关条目进行了改写。

发表在 云计算技术 | 留下评论

CAP理论十二年回顾:”规则”变了

作者 Eric Brewer 译者 郭晓刚 李湃 发布于 2012年6月11日

本文首发于  Computer 杂志,由InfoQ和IEEE呈现给您。

CAP理论断言任何基于网络的数据共享系统,最多只能满足数据一致性、可用性、分区容忍性三要素中的两个要素。但是通过显式处理分区情形,系统设计师可以做到优化数据一致性和可用性,进而取得三者之间的平衡。

自打引入CAP理论的十几年里,设计师和研究者已经以它为理论基础探索了各式各样新颖的分布式系统,甚至到了滥用的程度。NoSQL运动也将CAP理论当作对抗传统关系型数据库的依据。

CAP理论主张任何基于网络的数据共享系统,都最多只能拥有以下三条中的两条:

  • 数据一致性(C),等同于所有节点访问同一份最新的数据副本;
  • 对数据更新具备高可用性(A);
  • 能容忍网络分区(P)。

CAP理论的表述很好地服务了它的目的,即开阔设计师的思路,在多样化的取舍方案下设计出多样化的系统。在过去的十几年里确实涌现了不计其数的新系统,也随之在数据一致性和可用性的相对关系上产生了相当多的争论。“三选二”的公式一直存在着误导性,它会过分简单化各性质之间的相互关系。现在我们有必要辨析其中的细节。实际上只有“在分区存在的前提下呈现完美的数据一致性和可用性”这种很少见的情况是CAP理论不允许出现的。

虽然设计师仍然需要在分区的前提下对数据一致性和可用性做取舍,但具体如何处理分区和恢复一致性,这里面有不计其数的变通方案和灵活度。当代CAP实践应将目标定为针对具体的应用,在合理范围内最大化数据一致性和可用性的“合力”。这样的思路延伸为如何规划分区期间的操作和分区之后的恢复,从而启发设计师加深对CAP的认识,突破过去由于CAP理论的表述而产生的思维局限。 继续阅读

发表在 云计算技术 | 评论关闭

分布式系统原理介绍.pdf

分布式系统原理介绍.pdf

目录
前言
1 概念
1.1 模型
1.1.1 节点
1.1.2 通信
1.1.3 存储
1.1.4 异常
1.2 副本
1.2.1 副本的概念
1.2.2 副本一致性
1.3 衡量分布式系统的指标
1.3.1 性能
1.3.2 可用性
1.3.3 可扩展性
1.3.4 一致性
2 分布式系统原理
2.1 数据分布方式
2.1.1 哈希方式
2.1.2 按数据范围分布
2.1.3 按数据量分布
2.1.4 一致性哈希
2.1.5 副本与数据分布
2.1.6 本地化计算
2.1.7 数据分布方式的选择
2.1.8 工程投影
2.2 基本副本协议
2.2.1 中心化副本控制协议
2.2.2 primary-secondary 协议
2.2.3 去中心化副本控制协议
2.2.4 工程投影
2.3 Lease 机制
2.3.1 基于 lease 的分布式 cache 系统
2.3.2 lease 机制的分析
2.3.3 基于 lease 机制确定节点状态
2.3.4 lease 的有效期时间选择
2.3.5 工程投影
2.4 Quorum 机制
2.4.1 约定
2.4.2 Write-all-read-one
2.4.3 Quorum 定义
2.4.4 读取最新成功提交的数据
2.4.5 基于 Quorum 机制选择 primary

2.4.6 工程投影
2.5 日志技术
2.5.1 数据库系统日志技术简述
2.5.2 Redo Log 与 Check point
2.5.3 No Undo/No Redo log
2.5.4 工程投影
2.6 两阶段提交协议
2.6.1 问题背景
2.6.2 流程描述
2.6.3 异常处理
2.6.4 协议分析
2.7 基于 MVCC 的分布式事务
2.7.1 MVCC 简介
2.7.2 分布式 MVCC
2.7.3 工程投影
2.8 Paxos 协议
2.8.1 简介
2.8.2 协议描述
2.8.3 实例
2.8.4 竞争及活锁
2.8.5 协议推导
2.8.6 工程投影
2.9 CAP 理论
2.9.1 定义
2.9.2 CAP 理论的意义
2.9.3 协议分析
3 参考资料

发表在 云计算技术 | 评论关闭

架构原理-架构师的修炼-v1.2-艾飞.pdf

架构原理-架构师的修炼-v1.2-艾飞.pdf

发表在 其他 | 评论关闭

软件学院2012级工程实验选题参考

  • 面向中小型企事业单位的虚拟桌面云计算解决方案的研究与实现,主要考虑利用现有硬件资源,借助OpenStack\CloudStack等开源软件进行研究开发;
  • 开发一个朗读校正的App,可以借助讯飞的语音云来做。屏幕显示一句,用户朗读,像siri一样听到的语句与原显示语句对比,如有错误语音提示并范读,如对了就按学习计划显示下一句;iOS或Android均可。
  • 一个Mashup起来的B/S应用程序产品化调试及在Android应用市场上发布,HTML5(javascript、css、html)开发,Java/Jetty应用开发,Android应用部署维护等
  • 基于淘宝TOP API的购物盒子的设计与实现,服务器端开发.net或java或PHP,以及前端javascript、css、html开发
  • 基于微博API的评论盒子的设计与实现,主要涉及javascript、css、html及PHP开发
  •  HTML5 2D/3D技术研究,Javascript开发
  •  基于WebSocket的点对点透明通信管道的研究与实现,Javascript开发、Java服务端开发
  • 基于OpenSocial的研究与应用

如对以上项目感兴趣有基础请邮件联系mengning[AT]ustc.edu.cn

发表在 其他 | 评论关闭

Linux网络部分源代码阅读总结

Linux网络部分涉及了Linux操作系统主要关键技术,可以说如果对Linux操作系统的中断处理、软中断机制、系统调用和进程调度时机等关键技术理解不够的话,想搞明白Linux网络部分源代码几乎不可能,当然除此之外与网络紧密相关的sk_buff的分配和管理、网络协议之间大量的callback机制用法等也是必备的。

我们下面就是以网卡接收数据到recvfrom系统调用读到UDP数据返回到用户态为例进行分析。

继续阅读

发表在 Linux, 其他 | 标签为 | 留下评论