虚拟化网络的探讨

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享

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

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

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