开源企业级云架构的方案选择

Virtualization is a technology, while cloud service is a business model.

--- By Timothy Chou

Timothy在硅谷业界有很高的知名度，我们老板调侃说，他是“给CEO讲课的人”。之前有幸听过Tim的一次讲座，上面这句话给我留下了很深的印象。那天，Tim带着我们以IT界商业模式为主线，从IT业初生，一路讲到云计算时代。

不论你是要满怀雄心壮志地创立一个云计算创业公司，还是自己所在的大公司要推行云计算战略，推出云计算产品和服务。都需要从商业模式和产品定位的角度进行一些思考。我们不妨先关注一下目前形形色色打着云计算Logo的产品，大致可以分为几类，思考一下自己产品的定位。（将补充对Iaas,Paas,Saas三种云服务类型的分析）

举一反三，Tim讲的是商业模式，我却突然意识到，在硝烟弥漫的IT业界，除了商业模式，Ecosystem（生态圈）在任何时代也是极其重要的，每一个IT巨人的崛起，每一种商业模式的成功，都离不开它，以至于很多大公司都有专门的Ecosystem部门。

想出这个名词的人真的太牛了！纵观IT史的成功案例，还真是一个个和谐美满的Ecosystem。从庞然大物到鱼虫蝼蚁，在某一商业模式和技术标准的支持下，各走各道，各取所需，占领并生活在生态圈的不同层次。

这让我深深相信，投身云计算时代，瞎摸乱撞是不行的，拍个脑袋，来个创意，然后不管天不顾地，单打独干更是不行的，要想有持续可观的发展，一定也要在Ecosystem里找准自身的定位，一刀一枪拼出自己的地盘，稳扎稳打繁衍自己的“族群”。

一激动扯的闲话有点多，让我们回到云，回到架构。接受了Ecosystem，那就不难理解为什么现在有那么多各式各样的云厂商，形形色色的云技术，大家都不容易，这么大的蛋糕，人人都想进来占个地盘，分块蛋糕。VMware说我们是市场占有率最大的，Redhat说选他们的KVM方案绝对没错， Citrix告诉你我们的XenServer已经在全球部署了多少多少个DataCenter，IBM、Oracle、Microsoft也围着您说，客官您看看，俺们的方案其实有更多优点！你是不是有点头疼了？别头疼，也别眼花，在我看来，这么多形形色色让人无从选择的方案，其实就根植于两点：各家厂商的“传统技术优势”和“商业战略考量”。

如果您想做企业级云解决方案，肯定不是仅仅做个云自己用吧？所以，不妨也从自己的“传统技术优势”和“商业战略考量”这两方面开始，进行自己关于架构方案的思考。我发现，写着写着就偏抽象化了，但是，思维方式比具体答案更宝贵。每个公司的情况都不同，笔者只能提供切入点，您如果按照这条思路去考虑，肯定有所斩获。

感谢开源！有了Xen和KVM，让我们国内厂商不必自己去慢慢啃Hypervisor这根硬骨头。感谢OpenStack，这个当下颇为成功的AWS-like Iaas云平台，为我们提供了更多可借鉴的思路。但其实，也并不是只有开源这一条路可走。基于闭源的VMware和Citrix产品并不是就不能赚钱。国内已经有这样的商业项目。据笔者的路边社消息，西南某省最大的某行业设备与方案提供商，已经在利用收费的虚拟化平台，开发适用于自己行业的云产品。

但是，这毕竟属于高度定制化的云产品。如果您想做的，是一个无行业差别的，能够推销给众多企业，帮他们构建私有云、公有云的解决方案。那么，有效利用开源产品，无疑是最优的选择。不仅能有效节省财力，物力，人力，在最短的时间，推出最完整的产品方案，而且能把重心放在客户需求上，根据实际需求开发出含金量更高的功能和服务。不仅实现了追赶，更有机会超越！

基于开源产品的，企业级云产品的架构设计中，应该考虑哪些问题？

其实这个问题很大，很难写好，且必然被拍砖。但俺决定，要抱着抛砖引玉，舍身成佛的精神，用有限的积累，去大胆探索出一条对大家有用的思路。如果这砖抛的好，大家都来思考这个问题，那我们国内云计算产业就更有希望啦！^_^

务虚之后，我们来务实！下面列出的，是开源企业级云架构必然会考虑到的一些方面。后续博文中，我们一起逐一分析！

·         Hypervisor方案选择

·         管理中间件的方案选择

·         管理平台方案

·         网络方案选择

·         存储方案选择

·         安全方案选择

最近工作很忙，只能晚上加完班之后抽空写，说实话，对于这个开篇，其实自己很不满意的，感觉平时积累的很多东西，到写的时候反而组织不到位。发现写原创文章真的是一件很不易的事情，呵呵。

虽然已经发出来了，我仍然会不断去修改的，有了什么想法，就来充实一下，或者补充更多的例子，以便大家更好地理解这篇比较务虚的开篇文章里的一些思路和想法。

本文出自 “CloudEra” 博客，转载请与作者联系！

 

 

云计算催生了更多“离奇”的客户需求，云计算技术的迅猛发展也孕育出针对这些客户需求的更多更好的解决方案。大二层网络，这个曾经看来异常理想化的构想，就是一个非常典型的例子。让我们从需求案例说起:

客户需求一：我有n个数据中心，在硅谷的数据中心有一台VM，在北京的数据中心有另一台VM，我想让这两台VM，都感觉对方和自己处于同一个二层网络。

客户需求二：我有n个数据中心，在硅谷的数据中心有编号为A、B、C的VM，在新加坡的数据中心有编号为D、E、F的VM，在上海的数据中心有编号为G、H、J的VM，我想虚拟出三个二层网络：{A，D，G}，{B，E，H}，{C，F，J}。每个虚拟二层网中的VM，觉得自己和其余两台机器就像连在同一台交换机上一样；而三个虚拟二层网彼此隔离，处于不同虚拟网络的VM在二层网络上不连通，必须通过router交互。

第一个充满野性的需求，实质是要求一张广阔无垠的二层网络，主题是二层网络在WAN范围内的按需延伸。第二个需求看起来更加常规一些，但实现起来也并不容易。出于安全和性能考虑，硕大的二层虚拟网太过于平坦，从性能上来讲，广播帧会像洪水一样吃尽资源；从安全上来讲，没有隔离机制的海量VM组成的网络，既没有必要，也难以让人信任。

产品化的解决方案：

1. Cisco的OTV

永远不要低估业界巨头对技术潮流的把握能力！

虽然是传统的物理网络供应商，但Cisco似乎在云网络的领域一直走在最前端。早在2010年2月，Cisco就推出了自己针对云架构的产品OTV（Overlay Transport Virtualization）。通过在硬件交换机上，采用扩展链路层网络的技术，它可以使二层网跨越数据中心。最吸引人的，是很多资料中宣称，OTV安装和使用的便捷性：据说安装OTV的流程只需要5条命令，耗时仅仅5分钟！从物理网络来讲，跨数据中心肯定数据包肯定要向上进入三层网络，通过路由，再到达目的端。这也就决定了二层广播帧不可达。为了实现这一目标，隧道技术的采用是不可避免的。OTV很自然地采用了MAC in IP的封装方式。

图1是使用Cisco OTV之后的网络效果图，图中处于VLAN 1的VM，事实上分布于物理网络上不同的数据中心，仅凭物理网络，无法直接二层通信。引入OTV之后，它们彼此认为自己处于同一个VLAN标注之下的一个二层网络中，广播帧可送达任何一台VM。

 

图1  OTV跨数据中心二层连通示意图 

 

那么Cisco是怎么做到这一点的呢？在图2中你肯定能找到想要的答案。

 

图2  OTV工作原理示意图

很显然，Cisco既然是硬件厂商，那么改改自己交换机中的转发策略还是很easy的一件事情。要实现这一功能，技术细节很多，但简要来讲，他们是通过在交换机的MAC地址转发表上动手脚实现的。对于处于同一数据中心，物理二层网络连通的机器，在转发表中，对应MAC地址转发到某交换机端口。而处于不同数据中心的机器，它的MAC地址对应的转发目的地不是端口，而是一个IP，这个IP就是对方数据中心OTV模块的三层网络地址。本地OTV模块，会将需要跨越数据中心传输的二层帧，完整地打包到一个三层数据包中。通过路由，交付到对端OTV模块进行处理。接下来的，不用我说，相信你也了然于胸了。

Cisco的官方文档，强调了几点使用OTV的好处，作为自己产品的卖点。比如，对现存网络设施无影响；操作简单，并且可以与其它Cisco设备集成管理；没有在协议上动什么大手脚，复杂性低。其实最后一条也是Cisco解决方案的一大特点，毕竟么，人家可以轻轻松松改自己硬件产品的转发逻辑。相比之下，其它软件厂商给出的方案，就只能另辟蹊径了，通过在协议上做文章，达到同样目的，这个在后面会讨论到。

 

2. VMware的VXLAN

看完了硬件厂商的方案，我们再来看看虚拟化领头羊的前沿产品。VMware从一开始提VXLAN，其格局就比Cisco的OTV要大很多。VXLAN不仅着眼于二层网络按需延伸，更是在安全隔离上走的更远，从某种程度上说，它也可以被认为是对SDN概念的一次尝试。云时代的数据中心，从VM接入数量来说，本来就愈加庞大，再加上大二层网络技术的推广，一个平坦的二层虚拟网络上连接百万台以上的VM也许不再是什么痴人说梦了。要对百万级别VM的接入，在二层做到很好隔离。传统的VLAN技术表示它要疯了…

为此，在2011的VMworld大会上，Cisco与VMware共同提出了VXLAN技术，在业界引发巨大反响。（怎么云网络里哪儿都有Cisco的事儿？呵呵，这也印证了上一篇博文里说的Ecosystem观点，大家都在生态圈里占地盘，Cisco为了云战略就和VMware走的很近，长期partner）

目前VXLAN已经提交了IETF草案，在努力朝着标准化的方向前进。站在这一阵营的包括VMware、Cisco、Arista、Broadcom、Citrix和Redhat，怎么样，这个团队看着还不错吧。

软件厂商没法修改硬件的转发策略，那么VXLAN就充分利用了IP多播技术。通过IP多播技术，在UDP包中，完整封装VM的二层数据包，达到跨数据中心，跨路由的目标。由此而形成的虚拟二层网络，其上的VM认为自己处在一个真实的二层网络中，但实际上，有些广播帧却是在VXLAN的协助下，通过三层网络送达远端数据中心里的VM。因此，在业界也有一个好玩的说法，称VXLAN“坐在2.5层”。

VXLAN定义了相应的协议，图3是其数据包格式图：

图3 VXLAN数据包格式

VXLAN的具体实现十分复杂，对于虚拟交换机来说，需要data plane的支持，在VMware的产品中，为了支持VXLAN，对位于ESX之上的vSwitch，vDS等kernel module模块都做了大量改动。这个问题如果展开，不是一时半会儿能讨论完的，我们这里就不做详细分析了。选择几个比较有意思的切入点分析一下：

隔离能力的扩展：传统VLAN tag只有12位，在云里，4096这个极限怎么看怎么不够用。VXLAN在网络隔离时，采用的VXLAN ID（图3中第7个字段）有24bit，可以划分出高达1600万个相互严格隔离的虚二层网络，目前看来这样的扩展性是远远足够的。

 图4  VXLAN网络示意图

对跨数据中心，跨物理VLAN的热迁移提供支持：使用VXLAN之后，原来局限于同数据中心，同物理二层网，同样VLAN的vMotion，现在可以不受这些限制，按需扩展到虚拟二层网络上的任何地方。这是一个非常令人激动的进步！

不足：由于VXLAN基于IP多播原理实现，而现实中很多路由也许不支持PIM，或者虽支持多播，但出于某种原因，路由默认情况下未配置。就会有问题。不过这个可以通过其他技术手段改善，如加入proxy机制加以解决。

  

3. 微软在做什么？

在这场轰轰烈烈的大二层网战役中，哪个大厂商也不甘落后，话语权就是商业利益啊！VXLAN出来没多久，Microsoft就联合Intel, HP& Dell 提出了NVGRE标准（NetworkVirtualization using Generic Routing Encapsulation）。说白了也是一种Mac In IP的解决方案，但是与VXLAN不同，它使用GRE (Generic Routing Encapsulation) key的低24位作为二层虚拟网络标示符，进行隔离。同样是24位，同样是1600万个子网容量！我怎么看怎么觉得像VXLAN，比较好奇性能上会有大不同么？如果没有大创新，为什么搞这么些标准出来...