POWER芯片震荡中国服务器产业

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享

10月28日,中国POWER技术产业生态联盟在苏州成立,不仅由工信部副部长杨学山、江苏省副省长史和平亲自揭牌,而且几乎所有的国内服务器产业链企业全都齐聚苏州。问题来了,美国IBM的服务器芯片POWER缘何在中国受到如此重视,以至于震荡波席卷了整个中国服务器产业?

笔者在苏州现场发现签约不断,内容颇多,不过核心问题则在于以下四点。

一,IBM开放了服务器POWER8芯片的知识产权IP。这意味着中国企业可以在POWER8架构基础上进行自主创新,未来将在服务器芯片领域拥有难得的自主知识产权,类似于ARM的授权方式更有利于自主创新的国内大环境。

二,IBM同意开放软硬件系统并取消自身安全模块,允许中国加载国产安全模块。这意味着安全不等于可控,面对广受诟病的跨国企业IT产品的安全问题,IBM给出了颇有诚意的解决方案,更有利于自主可控的国内大环境。

三,IBM授权并转让给中国的不是落后技术,而是今年才发布的POWER8乃至未来几年后的POWER9芯片技术。这意味着不论对中国来说是市场换技术,还是对IBM来讲是技术换市场,正因为全球已经认识到服务器产业东迁中国的整体大环境,才使得市场和技术之间有了更匹配的交换价值。

四,刚刚成立的中国POWER联盟是与IBM全球OpenPOWER联盟平行的开放组织。相较于其他国家,中国IT产业和美国一样拥有完整的国产服务器生态链,IBM这种做法更容易吸引中国本土企业加盟,换句话说这样的组织架构更“接地气”。

这下该理解中国为何如此重视美国企业芯片的原因了吧。消息一出即引发业界震荡,但IT业界关心的话题又进入了新一轮扩展,具体看来多集中在如下四个方面:中美谈判都谈成了什么,IBM这样做的真实原因是什么,国产龙芯未来是否会受到影响,中国POWER芯片上市后是否仍会落后于主流市场?

 

爆料中美谈判内容

那么,这样意义深远的合作谈判是否会几经周折,耗时耗力?谈判过程是这样的。

全球背景是去年8月,IBM在开放POWER芯片后,宣布与谷歌、英伟达、泰安、Mellanox共同成立OpenPOWER联盟,现有成员已超过60家,包括中企业11家。

而中国政府指导的合作开始于今年3月。当时,还成立了工信部IBM联合工作小组,工信部和IBM签署了关于POWER技术产业合作MOU,包括微处理器,计算机系统,系统软件及应用生态系统,知识产权与培训等方面的合作内容。此后,四个月进入了多轮谈判过程。最终,在“核高基”重大专项专家组的直接领导下,就从IBM引进世界一流的64位指令系统及CPU技术在合作目标、引进和交付内容,分阶段合作规划、参与对象、时间进度安排等诸方面达成了一致意见。其中,POWER架构指令和POWER8 CPU芯片设计的两项技术授权协议早在7月26日就签署了协议文本。

据OpenPOWER联盟白金成员、POWER芯片中国被授权方——苏州中晟宏芯公司董事长郑茳透露,最后与IBM谈判的主要成果包括:

“技术的先进性:IBM转让全球最先进的POWER8 CPU技术,并承诺继续转让POWER9 CPU技术,保持技术的持续先进性;

授权的长期性:IBM对技术的授权将不设定期限,可供中国长期使用;创新的自主性:IBM同意中国拥有在POWER8架构基础上进行自主创新权利,承诺我们的自主知识产权;

安全的可靠性:IBM同意开放软硬件系统,取消安全模块,并接受中国的安全审查。我们将加载国产的安全模块系统,满足国家的安全需要;

合作的全面性:IBM围绕POWER8 CPU技术的转化和产业化,开放和转让操作系统、中间件和数据库软件,开展人才培训、研发支撑、软件生态建设等全方位支持,帮助打造中国自主Power服务器产业生态链。

市场的全球性:我们在中国市场销售国产服务器CPU,基于我们自主CPU的国产服务器产品可以拓展全球市场。”

 

IBM难道是“活雷锋”?

在仔细阅读了谈判重点成果后,业界同仁们关心的问题又来了:商业谈判重点在于互利互惠,IBM难道是“活雷锋”,它这样做的原因是什么呢?

众所周知,在目前服务器主流市场中,x86服务器全球出货量高达95%,营收也超过70%,而剩下的部分基本就是POWER服务器的市场(UNIX服务器中POWER市占率70%),且前者优势大有继续扩大之势。为此,IBM的POWER服务器从原来只搭载UNIX操作系统开始支持Linux,在虚拟化方面从独有的POWERVM开始支持KVM,未来还将包括DOKER技术,进一步走向开放,并试图全面覆盖x86服务器市场。

虽然,POWER芯片与Intel最新芯片相比性能更胜一筹,但是根据创新经济学观点,成为主流技术或产品的根本原因不在于技术性能的优劣,而在于技术的扩散范围和扩散速度,从这点来看,不可否认,POWER目前形式急迫。正如一盘围棋棋到中盘,而中国则成为POWER芯片与Intel对抗中的胜负手。这是因为,在全球服务器产业东迁中国的大背景下,中国的服务器企业和以互联网为主的超大规模数据中心,甚至行业企业需求都成长迅速,这样的市场可以说直接决定了POWER的扩散范围。

另一方面,效法ARM开放芯片知识产权也成为POWER芯片在商业模式上的胜负手,开放的商业模式决定了POWER的扩散速度。除了更为吸引系统企业加盟,在服务器市场上尤其值得一提的是,以云计算、互联网为代表的超大规模数据中心已占服务器出货量的20%,他们掀起了从芯片开始深度定制化的潮流,这也就不难理解为何谷歌会成为OpenPOWER联盟的创始成员。

但是对于POWER不同的是,ARM靠授权收费,也许注定只能成为利润颇丰的中型企业;而IBM POWER效仿ARM模式,并不意味着蓝色巨人指望靠授权盈利,更重要的在于盘活整个POWER服务器市场,在相关软件、服务器、生态圈中获取商机。

 

龙芯该怎么办?

就在10月,曙光也刚刚发布了龙芯3B芯片和服务器,自然有业界同仁反应中国企业开发已久的龙芯是否会在因此受到影响?这确实是个难以回答的问题。笔者认为最好答案一定是,芯片产业百花齐放百家争鸣的局面才是市场化的局面。

不过,仔细分析下服务器市场上的几颗“芯”,你也许可以自己做出判断。目前服务器市场上,除了英特尔已有的强大生态圈,POWER芯片正在建立的开放生态圈之外,其他芯片的情况是:Oracle和富士通采用SPARC架构芯片搭载Unix操作系统,在高端服务器市场占据一席之地,但未形成开放的生态环境,市场份额上也大大低于POWER芯片;龙芯采用MIPS架构,自主知识产权,应用于国内敏感领域,还未能进入主流商业市场;被普遍看好的ARM架构以及相关服务器,普遍认为从移动端转移到服务器端要等到2016年才可能规模应用。

应该说,除了过硬的芯片性能外,开放的生态圈,着眼于更大的市场才是决定芯片未来前景的衡量标准。而在中国市场,芯片未来还要满足自主可控、自主知识产权的条件。从这些指标来衡量,任何一种芯片如果可以着力于上述方向,都将具备良好的潜质。

 

等中国芯片上市又落后了?

不可否认,从授权签约到真正生产出中国POWER芯片,这种技术上的引进、吸收再创新一定需要数年的时间。而服务器芯片基本三年换一代,等中晟宏芯的中国POWER芯片问世,那时POWER8还是新技术吗?这是不少服务器产业链专业人士的进一步问题。

这一点上,IBM给出了从POWER8到POWER9技术都将授权给中国的承诺。另一方面,目前中国唯一生产POWER芯片的中晟宏芯董事长郑茳也在28日苏州的会议上给出了产品路线图。第一代芯片CP1H将于2015年12月推出,12核心,去除了IBM安全模块,它对标的是英特尔E5-2690,首先满足安全透明的要求。2016年搭载国产OS和基础软件、针对中高端市场的CP1H系统将问世。2017年12月第二款芯片CP2问世,它集成自主的FPT,多路直连,IO增强,对标英特尔E5-2620/2650,这时的POWER芯片才是一款真正自主可控的芯片。而搭载这款芯片的CP2系统将针对中低端市场,预计于2018年6月问世。

据悉,中国POWER芯片瞄准的不只是政府系统的自主可控服务器,以及关键行业高性能自主可控服务器,还包括面向数据中心和云服务的中低端商用服务器,可谓针对主流商业市场。那么未来这场震荡波将持续多久,后续是否可以掀起层层涟漪效应,让我们拭目以待。

(3个打分, 平均:3.33 / 5)

虚拟化网络的探讨

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

OpenStack的未来取决于是否拥抱Amazon!

OpenStack的未来取决于是否拥抱Amazon!

—— 一封致OpenStack社区的公开信

本文由:·@ben_杜玉杰 翻译,转载请注明本文链接!http://duyujie.org/post/56367280481/openstack-amazon-openstack

原文链接:http://www.cloudscaling.com/blog/cloud-computing/openstack-aws/

亲爱的Stackers,

在过去的三年里,OpenStack社区弥漫着武断和不公平的定位,尤其是对于AWS和VMware。这种观点最现实的表达就是OpenStack应该建立和维护一套他自己的差异化的API。

我毫不掩饰自己的信念,那就是这一选择将伤害OpenStack,或许已经存在伤害。现在,这个问题变得更加严峻,我希望能够说服你支持我的主张,那就是OpenStack应该立即拥抱既定的公有云的API和特性。这对于该项目的成功至关重要。更重要的是这样做才是真正符合OpenStack的使命。

为了说服你,我首先会解释一下为什么会有一个差异化的API集合的这段历史,然后,我们再看看为什么AWS和GCE支配公有云是不可避免的。我会揭穿围绕着有关抄袭这个公有云API的所有谎言,最后,我们将直击云计算中“创新曲线”的胡言乱语。

我们为何沦落到如此地步

当OpenStack在2010年夏天发布的时候在它最初的两个模块中并没有“native”API。Nova最初只提供EC2 API。该部分是由NASA贡献的,侧重于重新打造一个兼容EC2的私有云系统。Rackspace API是在EC2 API之后添加进来的,也就是在2010年那个夏天,OpenStack项目发布不久之前[1]。

引用自NOVA项目[README]:

You have come across a cloud computing fabric controller. It has identified itself as “Nova.” It is apparent that it maintains compatibility with the popular Amazon EC2 and S3 APIs.

请注意,在NOVA项目中没有任何描述提及过“原生的API”以及对目前的NOVA[README]的比较。

该项目的另一半Swift,使用它自己原生的API,其中一部分,也就是最初的Swift代码是来自于RackSpace的Cloud Files服务。

简单来说,OpenStack最初的“原生的”API,其中一半是AWS兼容的(NOVA),另一半是RackSpace公有云兼容的(Swift)。

然后,RackSpace并购了ANSO Labs ,从而实际上“拥有了”OpenStack代码另一半的贡献着。更重要的是,大多数能够决定该项目技术方向的项目团队负责人(PTLs) 都成为了RackSpace的员工。

在并购ANSO Labs的这段时间里,RackSpace的API才被更改为“nova-api”,这就是现在所谓的Nova的“native API”[2]。 该API在很大程度上与RackSpace Cloud Servers公有云服务的API是一致的。至今这个API变动不大,并且深深的影响了这个项目的命名法则(例如,“floating IPs”与“elastic IPs”) ,并在某种程度上影响了Nova的方向。

根本没有什么所谓的“native”API。事实上,把RackSpace Cloud Servers API称为“native API”是在宣扬一个概念,有一个OpenStack Nova API是独立于Amazon API的。现在很明显,事实上最初的OpenStack native API就是它的AWS EC2 API。

我们来控制OpenStack

自2010年上述决定做出以来,OpenStack项目的管理已日趋成熟。OpenStack基金会,一个独立的组织,目前主导着OpenStack的战略和商务方向,而其开发团队的技术精英在主导该项目的发展方向。

简而言之,社区控制着该项目的方向,并且是时候主张按照符合我们的最佳利益的策略来兼容公有云了,而不仅仅是由一个单一的,虽然是主要的贡献者来主导了。如果不能改变这个策略,最终很有可能会导致这个项目变得无足轻重而死去。

亚马逊主宰公有云

很明显AWS(也有可能是GCE)将完全主导公有云的竞争。但更重要的是,who cares?AWS和GCE主导并不意味着OpenStack失败。事实上,OpenStack很明显正走向“赢得”私有云的竞赛的道路上,并且快速拥抱Amazon将使得OpenStack处于主导混合云的关键位置。

在2011年二月的Cloud Connect大会上,我做过一个主题演讲,勾勒了“两个云的故事蓝图”,用数字比较了AWS和RackSpace Cloud Servers的规模和增长。在那个时候,我相信是RackSpace的年增长率给他们打了一剂强心针,使得在公有云的市场上他们被放在了AWS的死对头的位置(当时AWS年增长率是100%而RackSpace是90%)。

但在这之后的两年半的时间里,变化太大了。AWS的增长率有增无减,GCE正式加入竞赛。与此同行,RackSpace面临着增幅下滑。如果RackSpace今年Q2-Q4的盈利等同Q1,他们公有云将从最高90%的年增长率下滑到30%,在过去几年中出现惊人的跌幅。请参阅下图,假设2013年季度财季增长保持不变。

虽然没有关于GCE的增长率的公开信息,但我相信它与AWS是持平的。客户对他们的公有云服务的兴趣是如此之高,以至于他们等待列表中的客户数量已经大于实际上大多数生产环境中的公有云客户名单数量。而他们还仍然处于内测阶段。

是什么导致RackSpace公有云的突然下滑? 从公布的信息来看, AWS,很可能是GCE正在领跑公有云服务,并且给OpenStack社区一个显而易见的选择。[3]

阅读全文»

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

淘宝前台系统性能分析与优化

(没有打分)

淘宝技术嘉年华: 分布式系统稳定性模式的探索

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

一个前即刻老兵的告白–我所了解的人民搜索的研发状况

一个前即刻老兵的告白

离开即刻已经几个月了,想起在jike将近三年的工作时光,感慨还是很多的,闲来无事,整理下在即刻的点点滴滴,以供同行或者后续想去即刻谋生的参考。

即刻的前身叫人民搜索,当时可以说一穷二白,当时的领导是宫,由于对搜索不了解,无从下手,就先和中科院进行合作,用开源的Lucene搭了个搜索,功能和性能不能适合大搜索的要求。后来就搁浅了。

然后来了世界冠军,世界冠军果然不同凡响,首先就和前中国谷歌总监刘的公司云壤合作,聘请刘作为首席科学家,云壤提供技术支持和开发,当时签的合同是给云壤一定的股权,同时还有一大笔钱,当然钱来自纳税人,也无所谓了,刘的公司经过不到一年的开发,在2011年6月20日上线,并且更名为即刻搜索,记得我们当时听到更名为jike,都乐了,怎么能叫“饥渴”呢。当时的云壤由于资金不多,所有的机器都是即刻的,但是由于即刻一直没有给清合同规定的钱,云壤将代码封装成黑盒子,以lib库的形式提供给即刻,我们工程师就天天哭呵呵的围绕着这些黑盒子工作。由于云壤利用了即刻的机器,即刻也有部分云壤的代码,二者就心照不宣,因为除了刘,真正的即刻领导们包括后来加盟即刻成为副总的另一个谷歌的王,其实也不懂搜索。就这样维持着。

即刻搜索核心技术是想从云壤获得,所以不停地给云壤钱,给一点,云壤就多给一点代码,我们内部开发人员天天苦哈哈的做些外围工作,因为真正的核心组件都是密文形式的lib库。有一阵子,由于即刻答应给云壤的股份一直不能落实,云壤一度要挟要上法庭关掉即刻的服务,所以即刻只好多给些钱,暂时缓和。后来即刻内部斗争爆发,事情真相浮现出来,这就是著名的20亿。虽然给了云壤很多钱,但是即刻搜索迄今尚未完全掌握核心技术,相关技术仍未向即刻搜索全面开放,因为即刻答应给云壤的股份始终没法落实。索引检索排序的核心代码还在云壤手里,即刻只能以黑盒子的形式使用。所以和云壤的合作以云壤的刘出局告一段落后,即刻拿到一堆估计永远没人去看和消化的用来充数的外围代码。从即刻的代码库中,根本看不到即刻搜索内部是怎么工作的,只是一个黑盒。
阅读全文»

(13个打分, 平均:4.69 / 5)

Juniper 。 《Enterprise Data Center Network Reference Architecture》

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

腾讯 。 《打造支撑海量用户高性能Server》(2)

(3个打分, 平均:2.67 / 5)

Juniper . SRX5800 . 数据中心

(没有打分)

阮涵 . 《数据中心网络技术浅析》

[原文可参阅:新浪阮涵的博客

数据中心网络技术浅析

随着云计算/大数据/移动互联等技术的推动下,作为在网络设备商做了多年研发的我近期一直在想这个问题:云计算下的数据中心网络到底是怎么样?怎么样的基础网络才能满足当前云计算下变化复杂的业务? 首先,我理解网络架构的设计仍然还是自顶向下的,运行的业务、用户的投资回报(opex/capex)等因素影响着数据中心网络架构以及网络设备软硬件特性的变化。 从目前的种种迹象表明云计算是对数据中心网络的最大驱动力,我们先从当前业务模式技术驱动力开始。

1. 当前业务模式的技术驱动力

最上层是从不同的用户入口接收数据,首先是一个不依赖硬件的云OS, 完成应用、连接和交互,接着是数据智能从海量的数据进行语义分析,再下来是软件基础架构的变化(分布式软件系统等),进而影响着数据中心以及网络、服务器等基础设施的变革。云计算(数据中心计算)的主要技术领域涵盖了存储、计算、超大规模系统、数据中心等,比如存储,不仅要考虑文件、对象以及表等数据组织结构,也要定义访问模式,读少写多、读多写少以及是否实时存储等不同模式会在很大程度上影响存储系统的设计。再如计算,也分为数据密集型、通讯密集型和计算密集型。

2. 数据中心计算对网络的需求

上面简单了解一下目前业务驱动的一个总体架构,数据中心计算对基础网络有哪些需求呢?从用户直观体验上看,用户对于云端数据中心直接关心是提供运算能力和存储服务,因此狭义的数据中心主要包含计算和存储,但是如果没有数据中心网络的话又把我们带回仅仅scale-up的大型机时代,网络把数据中心的计算和存储连接在一起,在Scale-up和Scale-out两种模式的螺旋状上升中满足云计算的大规模提供能力的需求,因此网络在数据中心的地位同样也是非常重要的。对于数据中心的网络接入需求主要有下面几类:

(1).                 HPC/离线计算的通讯密集型:该类型主要是计算和通讯都有一定的要求,对网络的总体要求:流量是东西向多,由于大量分布式计算会有多打一的情况,因此网络尽可能的无收敛比,TOR接入大部分要求单网卡即可(除了HPC的Master节点要求双网卡接入),要求时延低,丢包率低, 不涉及虚拟机迁移(由于计算能力要求高,hypervisor还是耗资源的,暂时没有跑在虚拟机上面),由于一般情况下是TOR直接是三层网关,因此对于ARP/MAC等表项没有很大的要求。

(2).                弹性计算:弹性计算会涉及虚拟机以及虚拟机的迁移,那么网络至少要有一定的二层能力(不一定要超级大的二层),对于MAC/ARP的表项有一定的要求,对于时延和丢包相对不太敏感,流量南北向相对多,对于收敛比没有要求。

(3).                 分布式存储:对于HDFS的存储采用多份(本地一份,本机架交换机另外一个端口一份,跨机架一份),流量在TOR交换机间,不同的机架之间都很大,网络尽可能的无收敛,对于时延和丢包要求敏感,不涉及虚拟机的迁移。

阅读全文»

(7个打分, 平均:4.71 / 5)