2016 CCS企业云计算高峰论坛（ccs.d1net.com）于6月15日在北京国际会议中心盛大举行，这是国内面向政企客户的最重要的一个云计算会展。CCS企业云计算高峰论坛上，云与大型企业的兼容性将成为主要议题。
以下是现场速递。（声明：本稿件来源为现场速记，可能有笔误和别字，仅供参考）
主持人：感谢宁总的精彩分享。开源、开放、共享是IT产业发展的趋势，OpenStack正是以这样的核心理念让更多的企业，尤其是用户通过软件定义的方式参与到下一代数据中心的建设当中去。接下来有请华为云计算网络首席架构师申思讲讲“基于OpenStack公有云网络云平台的实践”，掌声有请。
华为 云计算网络首席架构师 申思
申思：各位领导，各位同事大家好。我今天讲三部分，第一需求和驱动力。第二，对OpenStack级联技术的介绍。第三，我们在公有云和企业云实践案例的分享。
首先，我们识别的云计算的一个精髓，就是融合共享，对资源池的融合共享，对物理资源，包括计算资源，存储资源，网络资源的一种抽象，然后给用户提供一个敏捷、开放的，迅速能够集中上线它的业务的这样一种平台能力。解决多个异构资源池的问题。
OpenStack实际上现在由于它自身的开放性、灵活性、兼容，以及多个厂商对他们的支持，已经成为云计算管理平台的一个标准，华为今年成为OpenStack的国内首家黄金董事席职位。我们提供OpenStack为企业用户或者运营商用户搭建公有云、私有云的时候其中有这么几个问题。
重点的几个问。第一，跨DC融合的问题，但是对于跨DC的实践，基于传统的OpenStack能力很难做到大规模扩展，因为单做OpenStack实际的管理规模，站点规模可能也就是500台左右，不会超过1000台。不同的DC管理的时候，传统的方式就是通过协同层，通过搭一个协同层，拉通资源整体的分配，拉通资源，特别是网络层面的互通。这种方式带来的一个问题，它破坏了OpenStack原生的，最核心的数据模型和开放生态的API的能力，变成相对来说厂商绑定的一个私有云方案。
另外一个思路，是不是可以通过集成之后仍然提供标准的OpenStack原生的能力，保持OpenStack开源的生态。这个是客户的一个关键的诉求。同时在一个站点内，也有多种不同类型的资源池，像vMware，特别是资源池规模不断增长，不断扩展的时候，传统的以主机方式很难满足这个问题，同时网络层面客户诉求也是非常多，客户有跨DC的诉求，支撑一些容灾备份这样的能力，也有三层的诉求，通过集中式的节点。这么多的诉求用传统的OpenStack解决存在这么几个比较大的问题。首先，单个OpenStack的管理规模是有限的，第二，OpenStack在服务器和控制节点之间跑的是私有的RPC协议，这个协议很难管理，很难单独运维，单独控制。其次，像升级故障定位，故障率很难隔离到一个具体的域，保证发生故障的时候其他业务不受影响。这个问题促进我们怎么解决这些诉求，因为华为在OpenStack上非常清晰的就是源于开源，基于OpenStack解决客户的诉求，跟厂商合作，跟社区合作，同时回馈社区。
所以，我们考虑OpenStack的级联技术，这个技术从最早的思考，到它实际落地以及商用也经历了一个过程。我们基于现在正在做的级联商用的案例，正在不断把补充的代码贡献到社区。
那么，我们最初的考虑是什么?既然OpenStack是用户所关注的一个重点，那么我是不是能够用OpenStack进行多站点，多OpenStack，多资源池的编排，这是最初的一个想法。这样解决的问题就是保证OpenStack的一个独立性和API，同时多站点的融合，成为开源OpenStack的编排能力，可以防止被厂商锁定。
那么，这个想法非常好，是不是可行，我们考虑是不是可以把OpenStack作为一个编排的节点。经过验证和分析，我们发现这个方案是完全可行的，因为OpenStack本身就是一个驱动插件，在座可能有对OpenStack比较熟悉的，以Nova为例，调度到计算机点之通过计算机的Driver实现对KVM的虚拟机的生命周期感觉。相对Vmware来说，也一样是通过Driver方式实现，Driver既然可以管理这个节点，是不是可以管理OpenStack，这是我们最初的想法，而且不会修改OpenStack原生主体，只是通过外围的插件进行对接。对于网络也是一样的，OpenStack二层要实现OVS上的扫描插拔。这些接口也是可以通过对接下层的OpenStack实现网络业务的下发。
经过验证我们有了OpenStack的级联方案，还有一部分加固能力我们逐渐往社区贡献。整个加固分成两层，第一层是上层编排层，是完整的OpenStack的服务，对底层所有的实践客户并不感知。在多个DC内通过实际的业务OpenStack实现对DC内的OpenStack的资源池的关联，用级联层的OpenStack，上层的OpenStack有一层插件层，这层插件层完全以插件的形式控制到社区，这个插件负责在两层之间打通业务，并且把计算存储网络都打通，这样用户在上层的OpenStack发放业务的时候只要选择在哪个OpenStack部署这个业务，整个计算存储业务的下发都是自动的完成，利用OpenStack原生的这个能力。
这里面举个例子，比较实际的一个例子，当用户发放一个虚拟机的时候，通过上层的API调度，然后决定分布到哪个OpenStack。然后，OpenStack接触到的也是同样的API的接口，在下层主机这侧进行调度，网络、计算、虚拟机挂在那儿，网络自动会同步。在两个DC之间通过OpenStack流程原生的机制，通过级联层做广播，实现跨地区的虚拟机和虚拟机业务的互动。
总结一下OpenStack级联的价值，首先是一个开源的编排层，没有厂商绑定的问题，是标准的OpenStack。可以解决故障率隔离的问题，比如一个站点、业务出现故障，一个站点宕掉，其他站点的业务不受影响。其次，站点间故障隔离。同时，可以水平扩展，并且每个OpenStack都是可以独立进行升级维护管理的，具备比较好的故障隔离性和独立性。这个是我们的项目，主要解决单OpenStack本身的扩展性和容量的问题，通过分布式控制技术，通过DB的订阅减少RPC量的本地缓存，这个也是比较受关注的项目，解决了原生的RPC的扩展性的问题。通过这个分布式控制技术，仍然是开源的项目，但是它可以解决单个OpenStack最大到一万台物理服务器的规模。
我们现在在华为企业云，以及跟国外的一些运营商，国内的运营商合作，大的公有云部分已经上线了，现在已经开始用基于OpenStack级联这个架构进行整个业务的实现。我们现在通过OpenStack级联这个技术，我们最多能够支持的被级联的站点是100个，目前是100个。每个站点可以有1000到10000台虚拟机，我们理论上的规格在10万台物理机，支持一百万的虚拟机。当然，我们现在正在朝这个方向做商用，规模大了之后，包括商用加固、运维管理的复杂性会变的非常高，这部分商用的加固其实难度比较高，所以我们也朝这个方向在努力，也希望大家可以和我们一起基于这个项目构筑一个大规模的企业云，或者私有云。
最后，是我们在公有云和企业云的一些实践，简单分享一下。我们现在在华为企业云，去年7月份上线，以及国外的像德国、西班牙，还有国内的一些运营商也已经有合作，开始大规模的上线公有云项目。我们用的架构是一套基于软件的Overlay架构，这个跟华为传统做设备，做盒子这种印象完全不同，完全是通过软件实现的，解决我们对接入交换机，汇聚交换机完全是一个异构的，不需要华为提供设备，也一样可以实现Overlay这种能力。同时对高级的服务，防火墙服务，VPN，也是通过软件现的，整个架构是用X86搭起来的，没有任何厂商锁定的问题，所以这个对客户来讲是非常有价值的点，不管是国内还是国外的企业运营商客户，他们非常认可纯软件实现的Overlay运算的这种能力。
我们在定义试图的时候，一部分是租户的视图，一个是物理的视图。物理视图就是有多个物理的DC，DC内部划分多个具体的逃路，物理的小隔离，这是整个资源视图。
我们从逻辑架构上来讲，有接口/业务层，提供商业的编排能力，业务编排下发能力，提供计费、单点认证，安全。然后有标准的自动化编排层，基于OpenStack级联层的编排能力，提供OpenStack标准的API。下面就是IaaS层，通过不同的OpenStack实现实际业务的管理和下发。虚拟化层，有开源的KVM站的支持，也可以针对Vmware进行。基础设施完全是X86服务器实现的，没有用任何私有的绑定的硬件。整个全局视图是这样的结构，跨地区实现业务的高可能性。跨DC实现整个网络业务的存储的拉动。整个资源可以是零扩展，扩展任何一个DC的时候，只需要在这个DC内进行部署，不需要对其他业务有任何影响。
我们在跨DC的VxLAN Overlay互通，具体的虚拟机可以调度到不同的DC内部，虚拟机通过底层的Overlay技术三层互通。四到七的服务能力包括面向虚拟的负载均衡服务，虚拟的路由服务，防火墙的服务这些都是通过软件实现的。通过这个集群跨DC实现业务的LB，我们Web服务器和企业里的服务器，可以在不同的地区内部署，保障高可能性。用户访问的时候调度策略也是可以配，这个提供了一个跨DC的负载均衡服务。这是两个比较典型的一个使用案例。我的分享就到这儿，谢谢大家!
本文转自d1net（转载）