重点推荐:思科FabricPath大二层技术详解

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享

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

基于FabricPath的数据中心设计

(没有打分)

谷歌水冷服务器技术介绍

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

谷歌数据中心供电系统介绍

 

(没有打分)

思科FabricPath技术和设计

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

The Unified Logging Infrastructure for Data Analytics at Twitter

(没有打分)

思科下一代数据中心体系结构-DFA

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

数据中心灾备-信息系统灾难恢复规范(国标)

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

数据中心灾备指南-10 things your data center backup solution should do

(没有打分)

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)