异构混合多云管理的需求，如何在SDN平台落地丨TF成立大会演-创新互联

本文整理自华胜天成云计算研发与产品中心总经理李明军在“TF中文社区成立暨第一次全员大会”上的演讲。更多会议资料，请在公众号后台回复“成立大会”获取。

华胜天成云计算研发与产品中心总经理李明军

非常高兴有机会跟大家分享，华胜天成在云计算开源网络落地方面的经验。

我们接触Tungsten Fabric是在2019年上半年，到现在有半年多的时间，非常欣喜地看到这样一个出色的解决方案能够放到社区里来。

企业用户需求：开放、异构、场景化

在过去的十年里面，我们看到云计算从一个概念，到现在成为一个主流的架构。在这个过程里，我们的客户对云计算技术架构的需求，以及功能的期望，也在发生着变化。

对于中大型的企业市场来说，需求由最初的异构，演变成后来的异构混合，到今天变成了异构混合多云的管理需求——在基础设施层面，有桌面云，以虚拟化形态存在的各种类型的资源池，还有各种公有云的资源池，公有云的应用，都已经进入到中大型的企业的IT环境里面。企业需要在这样一个异构混合多云的环境里面，找到一个集成的、直接服务于业务的基础设施。

这就带来一个非常切实的需求，我们总结了三个词：开放、异构、场景化。

怎么来理解开放？与开放相对应的，就是在前期的时候很多私有的解决方案，或者由单一厂商主导的解决方案，带来的就是对功能扩展和商务合作上的限制。

异构的情况出现在很多层面，比如历史的IT架构与现有的应用系统和IT基础设施，或者今天多种类型的云计算基础技术服务，包括私有云、公有云。

另外，客户十年前建设的系统，可能有好多仍然在继续运行，并且承载一些非常重要的业务，这些系统服务怎么跟新兴的互联网，Cloud-native的架构和基础设施集成在一起，是迫切需要去考虑的一个问题。

对于中大型企业来说，如何把用户现在数据中心里所有的IT能力汇集起来，形成一个云服务，变成了企业很迫切的需求。我们碰到非常多这样的客户，不管是电力行业，运营商，还是在金融行业。

第三个就是场景化，不管技术有多高大上，对客户来讲，首先要问的一个问题，就是新的技术对业务场景的促进是什么？哪些业务场景能够直接提高业务效率？企业投资IT首先需要想到的，是怎么能够给业务带来帮助。

我们在落地一些云解决方案时，会着重强调，哪些是能够跟客户具体的业务场景相关联的。这里很关键的一个思想，就是我怎么把云里面的非常丰富和多样化的东西，能够跟业务关联起来，能够跟我的应用关联起来。

这是我们看到的三个方面的需求。

在这个大的背景下，我们看到，网络作为云计算的骨骼和神经至关重要，只有通过网络，才能够对异构的环境提供连接和支撑，并能够把这些异构的、混合的、多云的资源管理起来。

企业级云管平台的“三板斧”

我们主要从三个方面应对上述需求和挑战。
首先就是异构多云基础资源管理。在混合云的管理上，针对私有云我们看到几个主流的技术方案。比如OpenStack，在商用市场里有非常多资源池存在的VMware，作为小型机资源池的POWER，以及裸机管理资源的工具xCAT，在云原生应用里面主流的资源池K8s。公有云的话，主要是国内的阿里云、华为云、腾讯云，然后AWS也在国内拥有越来越多的客户。

对异构化的计算存储网络，包括技术资源的、技术软件的异构化管理，实际上就是针对异构混合多云的基础设施，我们要提供一个统一的入口，统一资源池的管理工具，能够把所有的资源形成服务目录。

然后在这之上，我们看看怎么能够面对客户的场景化，怎么面向他的业务能够直接提供帮助，在这里面我们有两大应用功能：一个是场景化的应用中心。

相比较传统的云服务产品，我们在云里面只提供了一些虚拟机和基础网络服务。在基础的存储服务里面，可以通过申请一个虚拟机，然后创建一个基于某种虚拟化的操作系统，在这个操作系统里可以申请服务IP，然后挂在某一个存储池的网络上，我们认为这是过去几年里比较主流的一个云管产品，我们把它定义成是一个在资源级别能够提供服务的云产品。

现在我们有条件把它上升到一个对企业业务提供支撑的级别。在这个场景化应用中心里，我们可以通过在云计算服务中定义一组业务，这组业务是互相关联的，不管是计算资源、存储资源、网络资源，还有在这些技术资源运行之上的业务系统，比如说是一个金融的互金平台，可能有几十个虚拟机分布在各个网络安全域里面，这些虚拟机里有多种操作系统的需求，包括Linux、UNIX或Windows，存储的需求也是基于前端应用和终端应用有所不同的。

怎么在一个业务场景里把所有需要的IT资源编排起来，并且能够自动化部署，是一个非常大的挑战。我们在这方面做了很多的落地实践。

还有一个是面向业务的运维中心。前面几位专家也讲了，三分资源管理七分运维，实际上在整个多云架构里面，面向应用的业务场景落地以后面临很大问题，就是怎么能够在一个业务场景下，对这些资源更好地运维。

在传统的架构里面，一个业务上线，或者一个业务跟具体的资源相关联时，有两张很重要的图：一张是应用架构图，是从应用架构师的角度对要部署的业务系统进行描述；还有一张是物理部署图，是数据中心团队理解业务系统物理布局的。

在传统的IT管理方式中，应用架构图连接了应用的开发部门，对金融机构来讲就是开发测试中心，物理部署图是数据中心团队来做的，各种各样基础的计算、存储、网络，在应用的中间件落地的时候，做的物理部署规划图。

在缺乏一个面向业务的云管平台时，我们通常会经历很多次跨团队的沟通，从开发测试，到服务器管理员、存储管理员、数据中心管理员，以及整个运营团队，才能从应用架构图慢慢演进成一个物理部署图，能够在数据中心落地，把一个业务能上线运维起来。

在我们现在新一代的云管平台里，所有东西都变成了线上一个自动化的模式。

首先我们可以在云管平台里创建一个应用，然后添加应用架构师熟悉的逻辑单元，通过对这些逻辑单元添加服务，来关联一些组件之间的依赖关系，这些动作是通过在线的一个图形化的拖拽形成的，通过这一步完成了对业务系统的逻辑定义。

接下来我们会对逻辑定义，相当于数据中心架构师对逻辑架构图进行实例化的过程，我们通过对每一个逻辑单元跟后端的物理资源池的资源进行关联和配置，来进行每一级别的配置。

比如这一步，我们被配置某一个前端的部署单元，就跑到一个KVM虚拟机里面，这个虚拟机是运行在哪个网络安全域的哪个资源池里面，通过这一步最后形成虚拟节点的定义。虚拟节点里面的操作系统定义，就是它的用户组、它的磁盘卷组，还有它的网络安全策略的定义，都会在这个节点上来完成。

每一个节点都完成之后，最后就会形成对应于传统手工时代定义的这张物理部署图。整个过程支持私有云和公有云的混合架构，以及多个云计算资源池厂商的异构混合多云环境，在这样一个环境里，完成了一个业务系统的落地。

在这个过程中我们看到，不管是KVM资源池，还是通过OpenStack支持的OpenStack的资源池，还是商业化的VMware资源池，其实对应到单个资源池内部的时候，它的管理工具相对来说支撑体系比较健全。比如VMware它提供了非常完整的虚拟化管理的一套工具集，OpenStack慢慢也发展出了非常多的开源工具集。就单个的资源池内部来讲，这些东西都是相对来说比较容易解决的。

统一管理与SDN选择

一旦涉及到多种类型的资源池，就是刚才我们定义的异构化的多种技术栈，有私有云、公有云，包括了多种云的资源池技术的时候，最头疼的问题就来了，实际上就是网络怎么把这些多样化的服务串起来，能够互相关联，互相调用。

我们在接触Tungsten Fabric之前，实际上动了很多的脑筋，在云管平台这一侧做了非常多的开发，相当于我们会在云管平台侧来实现部分二层和三层的方案，解决多个资源池内部网络的互联互通问题。

这里我们有两层的工作，首先云管平台作为整个数据中心的入口，要解决的不只是在多个厂家的IT资源池之间的互联互通，还要解决在单个SDN解决方案的内部，它的小型机怎么连，它的物理服务器怎么连，它的虚拟交换机这一侧的互联互通解决方案是什么样的，都要根据每一个厂商的SDN解决方案来做适配，在云管平台实现对某一类型的某一个SDN解决方案下面所有异构资源的管理。

然后到第二步，就是有些大的客户会有多种SDN方案，我们见到最多的有三个厂家的SDN方案。当前市场上每家的解决方案都互相不兼容，都必须要自成体系，你要一个OpenStack接两个SDN控制器几乎不可能的。这样的话，我们需要再做一个总的云计算解决方案，在云管平台侧考虑实现对多家SDN解决方案的互联互通，进行二层和三层的功能开发设计。

今天我们看到，Tungsten Fabric这样一个框架，实际上已经在非常大的程度上，解决了我们在大型云计算落地里必须要关注的这两个问题。

对于单个SDN的异构资源池之间的互联互通问题，Tungsten Fabric这个框架实际上提供了业界几乎最完整的这样一个组合，包括比较主流的OpenStack + KVM体系的支持，还有K8s + docker，甚至包括商业化的VMware，都提供了通过单一SDN控制器实现对各自的资源池级别的虚拟交换机、虚拟网络的支持，已经内置得比较健全了。

另外一个我们比较看好的，就是它对多家公有云网络之间的互联互通方面，在市场上做的比较靠前，包括对AWS等主流国外公有云厂商的支持。像阿里、腾讯、华为这样国内公有云网络的互联互通，我相信通过社区的努力，也可以很快实现。

从这一点来讲，不管是对私有云里面的多种技术栈，还有多个公有云的技术栈，现在TF框架已经做到了最完整的支持，满足了我们在使用单一SDN条件下，所有异构混合多云环境下的网络的互联互通，我觉得TF现在是做得最好的。

为什么我们需要对多个SDN的框架，花很多的精力动脑筋做集成，就因为过去单一的SDN解决方案他们是不开放的，某一个IT厂家的方案只支持自己的交换机、虚拟交换机的管理，通过TF开源的框架，这些问题部分得到解决，通过社区的发展，可能将来不需要再有多家SDN控制器的“团战”了。

实际上不管对裸机的管理，对虚拟资源池的管理，完全可以通过一个大家都认可的开放平台来管理，所以我们现在新一代的云管平台里的网络框架，会基于TF来做各个设备层的互联互通，我们认为这是一个更优的解决方案。

这是根据我们的经验，对现在市场上常见的几个SDN方案的对比。

首先，在中国市场上我们看到，有几个主要的SDN解决方案提供商，包括华为、华三、思科和瞻博网络，这里面商业产品没有列出来。

然后我们从三个维度来做了比较。

首先就是中大型企业比较关注的，对异构资源池的支持，TF在这方面有非常领先的一个优势，他现在可以非常好的支持OpenStack，我们第一个合作，实际上是把我们自己的OpenStack产品跟TF做了集成测试，各方面的功能，我们也是联合做了一些客户项目的演示，最终效果还是不错的。

然后对VMware，裸机，K8s都已经有比较成熟的方案，对公共云这块也是市场走得比较早的，对AWS的支持很早就已经实现了。

另外TF是一个开源的版本，拥有社区的优势，可以不单借助厂商的力量，不管是高校，还是我们从业厂商的力量，大家可以把很TF没有做出来功能，基于项目的场景，基于我们的用户的场景能够很快做出来。

再比如说大家比较迫切的，对underlay这样一些功能的扩展和管理，以及南向协议的支持。对underlay这一块，我们看到现在大家的主要问题就是对物理网络的支持相对来说比较弱，大部分都是基于自身的硬件体系。这样的话其实也是导致了客户需要有多个SDN存在，因为有些时候网络设备是分批买的，或者说因为各种各样的商业博弈的原因，一个客户数据中心里面存在多家的SDN的方案，这就变成了一个事实。

所以说如果我们有一个比较开放的框架，可以很容易地去支持不同厂家的Underlay管理的话，我们相信在Tungsten Fabric会是一个比较好的替代方案，客户其实没有必要拥有多家的SDN方案，如果有一个方案能够在云管平台这一侧,能够非常容易地实现对underlay的这样一些功能的管理，其实必要性就是大大降低了。

运营商与政务云的案例

接下来给大家讲两个案例。

这个是我们在中国移动某省公司来落地的，做了整个生产环境的云化资源池管理。在这样一个架构里面，客户对IT的使用入口，就是我们的异构混合云管理平台。目前我们在这个环境里面分了三个区域。

一个是SDN区域，用来管理OpenStack、VMware、裸机等的资源池。非SDN的区域，由于网络配置问题的一些原因，我们保留了一个非SDN区域，这里面主要是对x86裸机的支持，还有对POWER服务器的支持。对VMware来讲的话，我们有一个VMware的直连区域来管理VMware的资源池。

客户越来越希望把他的工作负载，能够转到SDN区域里面，实现对网络的灵活管理。这里SDN给客户带来的价值，就是把IT的资源跟网络来解耦。

之前比较痛苦的一个问题，是说VMware的资源，或KVM的资源池，在跨网络迁移时，总是受限于一些网络的配置，包括手工的一些VXLAN的 配置，没法很好地去做自动化。有了SDN的功能，尤其跟云管平台来做集成以后，它可以实现跨网络域的虚拟机迁移，变得非常自动化。

第二个项目案例是某直辖市的政务云，是一个规模较大的完全基于开源技术的资源池，在这个项目里，有540台x86的物理服务器，加上20台的POWER服务器，可以提供29000万 TPMC处理能力，全部都在SDN的管理之下。不管是计算，还是存储，都是一个异构化的环境。

这个项目里SDN的价值，除了体现在跨资源池的虚拟机迁移，还包括物理设备和网络解耦，另外客户还基于SDN实现了虚拟路由器、虚拟防火墙、负载均衡器等功能，这些都是在SDN控制器的编排控制之下，然后通过云管平台来形成统一的服务目录。

实际上我们看到，从2018年开始，在企业的一些大型项目里，SDN的落地基本上变成了一个必选项。过去由于受单一厂家SDN方案的限制，在设备联调和功能集成方面会让人比较头疼。今天我们非常高兴有这样一个基于TungstenFabric的解决方案，对于企业级大型解决方案的集成，以及云计算方案的整体功能设计等，都带来了非常大的便利性。

谢谢大家！

关注微信：TF中文社区

另外有需要云服务器可以了解下创新互联建站www.cdcxhl.com，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。