電子簽核

使用SDN/NFV的物联网（IoT）服务交付

非常高兴有一个机会站在这个讲台上给大家分享一下飞思卡尔。其实最重要的是跟大家汇报一下，飞思卡尔我们作为传统的芯片厂商，我们是如何来应对未来的网络新的发展趋势，包括我们自己做的工作。我今天选择的题目是怎么样来利用这个NFV、SDN的网络来实现所谓的IoT物联网的交付。

首先从趋势上来讲，大家刚才已经看到了很多，我列了三个，首先IoT是一个非常典型的，对于未来网络需求推动的方式，它代表了网络规模的不断增加，网络带宽更大的需求，而SDN和5G是面对这种不断增加的需求、复杂度、网络的带宽，怎么来解决这个问题。其实刚才各位专家都已经讲了很多，我不再重复更多的内容。但是我们来简单的看一下IoT的例子，我们把IoT放在一个树状的架构里面，它其实从现在的角度来讲，很难把它结构化。但是我们能够从基本上，从不同的层次把这个IoT的网络做一下分类。首先树冠是非常繁茂的，代表了各种各样的服务，这其中涵盖了很多概念，各种各样的，然后所有的这些概念，如果我们往下看，就是在下边它是以技术为基础的，这些技术包括了，首先你数据的来源，也就是说数据从各种各样不同的传感器或者说数据收集的源头，把这些数据收集起来。另外一个就是你要处理这些数据，或者说在数据到达数据之前，其实有很多数据已经被预处理过。另外一个最重要的就是连接，我们怎么样来把这些数据搬移到你后台的云里面、数据中心里面。这个还隐含了另外一层意思，就是安全，怎么样把我这些数据非常安全的、有保证的、可靠的搬移到数据中心里面，来为数据中心进一步的处理，包括数据中心来提供这里面讲的各种各样的服务做一个可靠的、有效的保证。

基于这个架构，今天我将从两个角度，一个是飞思卡尔做的软件的努力。大家可以注意到作为一个传统的芯片厂商，为了应对越来越多的新的IoT网络发展趋势，我们也是在不断地增加我们在软件方面的投入。不管是从人力上，还是和各个组织之间的合作上，我们都有很多新的投入。另外一方面从芯片、从我们的架构本身，因为大家可能了解的飞思卡尔的都知道，我们传统上所谓的数字网络产品部，我们绝大多数的产品都是在网络应用的，不管从控制面也好，数据面也好，我们绝大多数产品都是非常集中在网络相关的处理。所以我们的硬件到底怎么样应对未来发展的趋势，也是我汇报的一个重要议题。

这里先给大家简单列举一下，就是ONF在过去的activities，所有这些方面我们都是非常积极参与的。然后将展示过去几年里面我们所做的一些事情，但是我想非常简要的提几个方面，一是从人员来讲。作为一个芯片厂商，如果大家有概念的话可以想像一下，在全球我们有超过1100个软件工程师，从整个公司来讲，有超过700个软件工程师就是服务于数字网络产品部的，从事内核开发、甚至包括应用层的软件，这里面还有一些基于交换的开发、CPE的开发，这些我后面会给大家简单讲一下。这里面首先给大家一个印象，就是飞思卡尔作为一个硬件厂商，我们是投入了越来越多的资源在软件方面。所以这些资源都用在什么地方呢这里面分成几个方向，一个是我们的工具，另外一个就是我们运营时的这些产品，所谓产品，这里面我提到一个叫Vortiqa，有一些客户有定制化的软件需求，我们也可以提供。另外一个，我们有一个组织，它可以为大家提供方案级的产品，就是从底层的操作系统到应用，方案级的各种软件的参考，大家可以直接拿来用。另外就是随着时间的发展，多核更复杂的数据面。另外就是应用，这些所有的就是给它本身开发的需求增加越来越多，不像以前简单的那样。越来越多的基础定制也出现在大家的视野里面，我们最近经常提到的有一个非常重要的概念，因为由于内核空间本身的限制，它极大的限制了你最终产品在网络性能上的发挥，所以我们是有很多的客户，其实包括在座的，他们都已经把自己的驱动迁移到了用户空间，这样能够最大效能的发挥不管是芯片还是网络架构本身它的效能。

几个方面来介绍一下，首先是虚拟化。虚拟化本身，其实作为传统的芯片厂商，在我们的架构里面提供非常强大的虚拟化的支持。我们自己开发的一个，可直接做在硬件和操作系统之间的。飞思卡尔也在开展新的产品线的开发，所以这些所有的工作我们也会相应的移植到这个上面。然后刚才我们也简单的介绍了一下VortiQa，它的一个软件架构，基本上大家可以看到是利用了现有的硬件加速的功能，或者硬件引擎加速它的不管是流表，还是本身这个数据转发流程的过程。通常的情况下我们的软件会提供两个版本，在我们的SDK里面，是随着我们的芯片发给客户的，所以你可以看到一个基础框架的版本。另外就是由VortiQa提供的软件产品，这个是在SDK基础上做过专门的优化，跟我们的硬件专门匹配，所以大家一方面可以用SDK作为参考，如果大家有性能需求或者特殊的软件定制需求也可以找到一个和厂家结合在一起的方案。

所有的这些软件其实它只有一个目的，就是服务于飞思卡尔的硬件，来为我们做下一步网络开发首先做验证，另外与我们的硬件结合在一起，为大家提供一个更好的性能。这里面简单介绍一下，从我们的MCU，就是消费类的和工业级的，到汽车级的，在MCU这个领域里面我们都会把汽车列出来，因为它的可靠性和安全都是有别于消费级的。虽然现在飞思卡尔慢慢从消费类的电子里面退出，除了手机之外的一些方案，我们也是能够给大家提供一个非常好的方案。

最后，是作为网络来出现的飞思卡尔的数字网络产品部，是我们从整个飞思卡尔的角度来讲，我们能够在IoT的那里面谈到的，在这个领域里面能够为大家提供的解决方案，从非常小的，从数据采集的这一端一直到数据中心的这一端，我们都是有非常好的处理方案的。

飞思卡尔数字广告的路标，给大家一个概念，我们现在已经全面进入到28纳米，所有产品升级为64位的。我们的T系列，所有产品都已经完成了量产。今年我们所做的一件事情，非常重要的一件事情，我们更加强调的是我们的包加速的这种功能，而且我们用内部的一个词叫做AIOP，就是说在通用盒之外，我们更加强调我们所能够为包加速提供的可能性。在未来我们都会统一到这个架构里面，这是我们在未来2016、2017年的后续的工作。这是从我们自己长久以来在芯片领域，或者在半导体领域里面一些经验的总结，它们从不同的角度分析基建。蓝色的也就是说我们的网口，还有我们的8548，非常有代表性的这样一个产品，它是一个超过1G或者最高到1.5G的内核，加上4个千兆的网口。我们的P系列，这是我们的4核以上最多到8核的一个系列，我们的网络IO的处理能力逐渐增加。相应的绿色的也得到了相应的提高，另外一个就是我们的加速，再到我们的T系列，最终，它的IO处理能力和加速能力都得到了极大的提升。但是橙色的那部分，它一直是滞后于的接口需求、CPU核的处理能力的，这就是DDR。作为一个多核的处理器来讲，你所有的流量、带宽都要体现在你DDR上，你没有足够的带宽的话，就没有办法让你的CPU核处理你的数据。相对于IO的处理能力增长来讲，核本身它的发展也是相对滞后的，为什么会相对滞后呢？因为和核绑定在一起的非常重要的就是互联，现在我们处理器发展到8个核、32个核，这种总线的架构完全不能适应CPU处理能力的发展，所以这种网状的环的处理结构出现在了CPU的架构里面。

这时候网本身的规模已经在你的半导体设计里，占到了很大的一部分，芯片面积，在半导体的设计里面有很重要的几个参数，首先是说你的功耗。功耗的面积，就是你去掉芯片的封装，里面的硅片，带的面积代表了你功耗的主要来源。带的面积很大程度上决定了你这个器件的良率，然后带面积越大，你的成本会越高，所以半导体本身现在的工艺并不支持无线的这种核互联它的扩张，所以，比如说在不管是16纳米还是28纳米这样的工艺条件下面都有一个最优的，最大做到300平方毫米或者310平方毫米，如果再大就没办法实现量产。所以在这里面我们最终选择了一个核加上加速引擎这样一个架构，然后除了核本身提高它的处理能力，提高核的数量之外，我们更加侧重于在加速的这个方面，就是用更优化的，也许它还是核，但是它一定不是通用的大核，是一种优化过的小核的一个架构来充分使用这种加速引擎和大核的结构来匹配不断增长的网络需求。可能很多朋友联想到了NP，但是对于我们来讲，我们会避免提NP这个词，因为我们不会往那个方向发展，而我们更多的是利用我们的核，利用我们的加速引擎，来提供更多的处理能力，所以我们避免来提这种核，或者NP这个词。这就是我们今年正在推出的LS2的产品，它是和架构无关的、可编程加速架构，它的目标应用领域就是SDN交换，以及数据中心的应用。

从我们的角度来讲，网络永远都是不只只有数据中心，它包含了接入网最终到数据中心。这个网络的架构永远都是从接入开始的，从IoT的角度来讲，网络永远都是有最基础的网关的起点作为起始，然后通过传输，通过路由器回到中心里面，形成整体的网络，所以我们所关注的不仅仅只有数据中心这一侧，所以我们也很关注在接入的这一侧的各种不同的情况。所以大家可以看到，我们提供的产品和我们的模块，都是现在可以作为一个SDN演进的方式提供给大家。

其中一个方案，刚才在之前的会议里面也提到过一个趋势，作为数据中心里面的加速我们要采用什么样的形式，其中之一就是INIC，来加速网络的随时处理能力。当然还有一个就是安全、加密、学习更多密钥的交换，密钥从1024推到2048之后，我们提供的C29系列的加速网卡，它是专门面向公钥、私钥的加速。如果大家有兴趣可以到我们的网站获取更多的资料。

现在越来越多的定制化的，尤其是各个不同的数据中心的所有者，包括谷歌，阿里巴巴等，它们都会有对自己定制不同的需求，所以相应的也是我们未来的重点之一。

最后IoTSDNGateway，它可能是虚拟的，但是它提供的能力是一致的。时间的原因，不一一的把它念出来了。然后就是作为一个Gateway的蓝本，这是我们提供的一个开发系统，这里面包括我们了MCU的方案，在通用的平台底下可以通过不同的核心，来提供这里面所有的互联的需求和Gateway需求的平台。

最后，简单回顾一下今天讲到的内容。首先是我们介绍了我们飞思卡尔的产品，包括我们一些加速的产品，也包括简单提到了我们MCU上面能够为大家提供的方案。另外就是关于软件，包括我们软件的开发，如果大家有兴趣的话也可以跟我们展开更多的合作。另外一个就是我们重点还是放在SOC的开发上面，重点都是为下一代的SOC作为基础为大家来服务的。我们最终希望达到的目标，还是被大家从基本的接入层一直到数据中心这个领域里，来提供更好的芯片级的服务。谢谢大家。

演讲者简介：
刘立冬，飞思卡尔亚太区网络事业部技术市场经理

OpenStack合力Kubernetes打造IoT平台，提供智能城市解决方案

本文详细介绍了OpenStack奥斯丁峰会上主题演讲所提及的开源IoT平台。首先我们会介绍关于IoT的方法和愿景，随后会提供简要的技术概述并展示两个使用案例。

物联网（IoT）是云计算领域的“下一件大事”。领先的行业供应商都提供了自己的IoT解决方案，并将其视作自己的业务战略。因此IoT这个词已经被滥用成为描述不同供应商专有解决方案的一个新流行词汇。“IoT”这个词几乎可以代表一切，甚至比“云计算服务”更加空泛。物联网主要围绕日益增加的计算机间通信，可通过用于收集数据传感器的网络和连接到云计算服务的执行程序处理各类信息。这个技术可以让我们生活中的一切，从街边路灯到港口都变得更加“智能”。

我们对IoT的看法与其他供应商有所差异。我们会通过相同的方法向客户提供私有云解决方案，并使用现有的开源项目对云服务的实现方式进行扩展，借此打造通用IoT平台，以应对不同用例的需求。为此我们定义了下列需求：

开源软件 整个平台必须基于现有的开源解决方案，并且绝对不能只由某一家供应商开发。我们希望使用现有的平台：OpenStack、Kubernetes、Docker、OpenContrail等。

不依赖具体硬件和供应商 软硬件方面不能存在供应商锁定的情况。IoT网关CPU必须支持x86/64或ARM架构。我们不想因为昂贵的专有装置而被迫只能使用某一供应商的产品。

**互操作性**IoT平台必须是通用的，可以适合不同用例。举例来说，如果某一IoT网关可用于统计街灯数量，那么也必须能通过相同的方式将其用于智能工厂或工业4.0应用程序中。

因此我们设计出涉及OpenStack、Kubernetes、OpenContrail和Docker开源项目的下列高层体系结构。

开源软件

整个平台必须基于现有的开源解决方案，并且绝对不能只由某一家供应商开发。我们希望使用现有的平台：OpenStack、Kubernetes、Docker、OpenContrail等。

不依赖具体硬件和供应商

软硬件方面不能存在供应商锁定的情况。IoT网关CPU必须支持x86/64或ARM架构。我们不想因为昂贵的专有装置而被迫只能使用某一供应商的产品。

互操作性

IoT平台必须是通用的，可以适合不同用例。举例来说，如果某一IoT网关可用于统计街灯数量，那么也必须能通过相同的方式将其用于智能工厂或工业4.0应用程序中。

下文技术概述一节将详细介绍其中的技术细节。首先一起来看看我们构建解决方案原型的两个用例。

智能城市原型

第一个用例是为捷克共和国一个名为皮斯克（Pisek）的小城市构建的智能城市项目。智能城市的理念和架构需要部署超过3000个端点，以及大约300个IoT网关，这些网关以高可用模式运行在Kubernetes驱动的容器中。该解决方案还包含开放数据门户，并通过数据API为第三方公司提供了下列信息：

• 交通流量、路线、停车位
• 监控和管理能源的使用以实现节能
• 电子商务、营销、旅游信息
• 环境分析
• 生活方式、社交服务、社交网络

该解决方案使用基于RaspberryPi 2的IoT网关。来自网关的数据存储在Graphite中，通过自行开发的数据挖掘应用程序进行处理，将结果显示在基于Leonardo CMS构建的市民门户网站中。Leonardo CMS是一种Web服务，可以将复杂的可视化结果混合显示在一起呈现任何内容。这个开放数据门户可以通过可视化仪表盘或API提供数据访问。

下图展示了特定时间内，Kollarova和Zizkova两条街道十字路口的机动车和行人通行情况。

若要详细了解该项目，建议阅读奥斯丁SuperUser杂志《更进一步，让城市变得更智能》一文，或观看KubeCon 2016演讲。

OpenStack奥斯丁峰会上的智能会议系统

为了证明我们的IoT平台真正不依赖某种应用程序环境，在OpenStack峰会过程中，我们将智能城市项目中使用的IoT网关（RaspberryPi 2）带到了奥斯丁会议中心，通过基于IQRF的网状网络将其与传感器连接在一起，借此测量湿度、温度，以及二氧化碳浓度。这个演示证明了IoT网关可以对IQRF、蓝牙、GPIO，以及任何其他基于Linux平台的通信标准进行管理并收集数据。

我们在会议中心三层楼内部署了20个传感器和20个路由器，通过一个IoT网关接收来自整个IQRF网状网络的数据，并将其中继至一个专门的时序数据库，本例中使用的数据库是Graphite。数据收集器使用了Docker容器内运行，通过Kubernetes管理的MQQT-Java网桥。其中最有趣的地方是距离，运行Docker容器的Raspberry位于美国奥斯丁的会议中心内，而虚拟机运行在欧洲的数据中心。动态网络覆盖渠道由OpenContrail SDN提供。下文技术概述一节还将对该平台进行进一步介绍。

下图展示了传感器和路由器发现过程中找到的一个无线IQRF网状网络。区域0 - 1覆盖会议中心一楼，区域2 - 4覆盖四楼。

IQRF是一种工作在亚GHz ISM波段的无线网状网络技术，可提供简单易行的集成能力，良好的互操作性，最多支持240个跃点的健壮网状网络连接，工作距离可达数百米，能耗非常低。

下图展示了会议中心二楼不同房间的二氧化碳实时浓度。历史图表显示了自周一以来的数值。从中可以直观了解到主题演讲的开始时间和午饭时间。

奥斯丁这套平台的数据收集方面，我们使用了下列服务架构。

技术概述

本节进一步介绍了这个IoT平台的一些技术构思。这个IoT平台以“通用”为愿景，旨在以安全的方式收集、管理和处理来自数千个端点的数据，并以动态的方式集中管理所有数据。

因此整个体系结构可以分为下列两大主要部分：

数据中心

数据中心是整个IoT平台的中心管理点。其中包含OpenStack IaaS云，以及伴随云同时运行的虚拟机和SDN控制面板。这些计算机负责了时序存储、数据处理群集、数据API网关访问，以及可视化Web服务等任务。

网关

IoT网关可位于任何目标位置，例如街灯、工厂机械、家用电器中。SDN提供的传输层将远程IoT网关与云服务连接在一起。网关可支持多平台，甚至可能混合使用了x86/64和ARM设备。该技术可以通过一个网关为多个客户承载多种传感器平台，这一特性是通过微服务分隔（Docker容器）和Kubernetes对多租户的支持实现的。整个平台可以提供可伸缩的多租户环境，无论多远距离的应用程序和传感器都可位于同一个网络中。

下列架构图展示了数据中心层和网关端的相关组件。下文架构详情一节提供了进一步介绍。

架构详情

架构图展示了整个IoT平台在体系结构方面的逻辑视图。左侧是数据中心，右侧是上文提到的网关。

从下图可以看到，这里使用OpenStack作为承载所有控制服务的云，同时所有大数据处理和前端可视化任务也是在这里进行的。网关使用Kubernetes对服务进行微分隔，为了实现多租户功能并确保不同传感器的安全，这一步是必须的。同时该平台还使用OpenContrail将两端连接在一起，并为Kubernetes POD和OpenStack Project虚拟机提供网络分隔。

上文曾提到过，分隔是通过SDN覆盖实现的。这里的重点在于数据中心边缘路由器和IoT网关之间只存在IP连接。网关操作系统和数据中心边缘路由器之间的VPN连接可以看作该平台的最底层，该层之上是SDN，在这里可以通过OpenContrail实现虚拟机（OpenStack云）和容器（网关）之间的直接通信。这种方法使得用户可以自由选择不同类型的传感器和执行程序，为其设置权限，并用安全的方式将其与云中负责任务处理的应用程序连接在一起。

数据中心包含下列服务：

管理服务

硬件群集中运行的虚拟机承载了所有控制服务：OpenStack控制器、OpenContrail控制器（SDN）、Kubernetes主机、Salt主机。

OpenStack云

OpenStack项目为数据库（Graphite、Influxdb、openTSDB）、大数据处理（Hadoop），以及数据可视化（Grafana、LeonardoCMS）所涉及的不同虚拟机服务提供了分隔和划分。这个云运行在KVM hypervisor之上，通过OpenContrail的Neutron插件实现网络连接。

边缘路由器

OpenContrail会与数据中心边缘路由器创建iBGP对端，这样便可以将OpenStack虚拟机和Kubernetes POD的动态网络路由传播至IoT网关。该设备可以MPLSoverGRE或MPLSoverUDP方式创建标准的L3VPN。

远程网关包含下列组件：

Kubernetes Minion

Kubernetes minion负责与数据中心内的Kubernetes主机通信，并负责管理Kubeletand POD。Kubelet使用了Opencontrail插件，借此将Docker容器与vRouter代理连接在一起。

Kubernetes POD

Kubernetes POD是连接到vRouter的一个或多个Docker容器。POD可按照标签进行分隔，这样即可启动不同应用程序，从不同消息总线以IQRF、蓝牙，或GPIO方式读取数据。

Docker容器

Kubernetes POD中的Docker容器为整个平台提供了极大的收益，可在无需特别安装的情况下支持任何类型的操作系统。例如，IQRF使用了某一版本的简单Java应用程序，可通过容器在几分钟内交付，并且不会与网关本身的操作系统产生不匹配的情况。

应用程序视图

下列架构图详细介绍了应用程序视图。从图中可知，借助OpenContrail覆盖的帮助，OpenStack云内部的虚拟机可以通过L2或L3私有网络联系位于任何地理位置的Docker容器。因此应用程序开发者可以使用标准云平台中用过的同一套工具。他们可以通过HEAT部署虚拟机应用程序控制器，随后通过简单的Yaml文件在远程网关上的容器中部署Kubernetes服务。

以通过环境传感器收集数据的做法为例：传感器直接连接至容器，数据在Docker容器中处理后发送至Graphite时序数据库。因为我们希望以图形化方式实时呈现数据，因此使用了另一个虚拟机，通过Leonardo CMS借助Graphite API读取数据，并将其显示在网站上。据此我们可以通过同一个云平台，按照相同的原则创建不同项目，并使用多种输入和输出位置。

结论

我们希望对这个IoT平台的愿景和已经部署的原型进行一个简要的介绍。目前我们正在完成整个智慧城市解决方案的细节设计工作。

今年在奥斯丁举行的OpenStack峰会和伦敦举行的KubeCon上对该方案进行介绍后，我们收到了来自社区成员的大量反馈。在IoT平台的安全性、弹性，以及性能方面，我们的构想得到了大家的认可，很多技术合作伙伴希望通过合作对我们的IoT平台进行扩展，借此构建他们自己的解决方案。我们现在正在着手有关工业4.0的构想，打算通过开源项目创建第一个智能工厂。

作者：Jakub Pavlik
阅读英文原文：OpenStack and Kubernetes join forces for an Internet of Things platform

sites links

http://www.sdn-iot2016.umkc.edu/#

courses links

http://www.cc.ntut.edu.tw/~phtseng/SDN/SDNintro.pdf

基於OpenFlow的數據中心網絡負載均衡算法

董宏成1，2，鄭飛毅1

（1.重慶郵電大學通信新技術應用研究中心，重慶400065；2.重慶信科設計有限公司，重慶400065)

摘 要：現代數據中心網絡（Date Center Network，DCN）經常會使用多路徑（MultiPath，MP）拓撲結構，這樣可以避免兩節點間某條鏈路失效而導致的網絡擁塞問題，而且增加了網絡的帶寬和容錯率。傳統的OSPF（Open Shortest Path First）路由算法會選擇單條最短路徑作為最終路徑，這樣可能會導致大部分數據流集中在單一路徑上而出現網絡擁塞，而其他可用路徑處於閒置狀態，不能充分地利用DCN中的鏈路資源，基於SDN（Software Defined Network）的集中化的調度方式能夠提高網絡利用效率。設計了一套基於OpenFlow協議的鏈路負載均衡模型，詳細闡述了它的總體框架和算法實現過程，並通過實驗仿真驗證了算法的可行性和有效性。

中圖分類號：TP393

文獻標識碼：A

DOI：10.16157/j.issn.0258-7998.2016.05.033

中文引用格式：董宏成，鄭飛毅. 基於OpenFlow的數據中心網絡負載均衡算法[J].電子技術應用，2016，42(5)：120-123，127.

英文引用格式：Dong Hongcheng，Zheng Feiyi. A load balancing algorithm for date center network based on OpenFlow[J].Application of Electronic Technique，2016，42(5)：120-123，127.

0 引言

近年來，數據中心呈現爆炸式的急速發展，大量公司開始建立自己的大型網際網路數據中心(Internet Data Center，IDC)。雲計算技術的出現對數據中心網絡提出了新的挑戰，比如網絡安全、虛擬機遷移、多租戶管理、負載均衡等。傳統的數據中心採用專用的負載均衡設備實現網絡資源的有效利用，具有設備成本高昂和可擴展性差等問題，而基於軟體定義網絡的集中化的調度方式能夠提高資源利用率，簡化網絡管理，降低運維成本。

ADVERTISEMENT

SDN^[1]是一種將控制層和轉發層分離的新型網絡架構，交換機只負責數據流的轉發，降低了網絡交換機的負載，控制層的功能全部由運行於伺服器上的控制器實現。控制器需要下發流表到交換機才能支持轉發層設備的有效運行，而控制層與轉發層之間的通信需要遵守一定的規則，目前較普遍的是採用OpenFlow^[2]協議來實現信息交互。本文目的是在SDN網絡架構下解決網絡流量高峰期鏈路的負載分布不均勻問題，設計了負載均衡機制的總體框架、實現流程圖以及具體實現。

1 數據中心網絡流量特徵

國內外學者對真實數據中心網絡流量特徵進行了深入的觀察研究。Mckeown研究表明數據中心網絡流量與傳統的區域網和廣域網流量有著極大的不同，內部節點間的數據流量在數據中心網絡所有流量中占主導地位^[3]。Greenberg指出數據中心80%的數據流量為數據中心內部的流量，而且85%的數據流小於100 KB^[4]。目前採用最多的是Fattree^[5]網絡拓撲，它可以為兩兩節點之間的流量提供多條路徑，這樣從理論上能降低單一路徑的負載率過高的問題，而在實際應用中還是會出現某條路徑上流量擁塞嚴重而其他可用路徑卻處於閒置狀態的問題。

ADVERTISEMENT

數據中心網絡流量模型由大流和小流組成，每個數據流由許多數據包組成，這些數據包具有5個相同特徵（源IP位址、源埠號、目的IP位址、目的埠號、協議類型）。而大流是造成部分鏈路擁塞的主要原因，所以負載均衡機制主要針對大流，在調度過程中儘量忽視小流來降低調度開銷。數據流的大小由其所含字節數決定，同時數據流越大，持續的時間越長，小流持續時間很短。本文將字節數大於100 KB的流界定為大流。

2 負載均衡實現的總體框架

控制器的負載均衡功能模塊如圖1所示，主要包括拓撲發現模塊、大流監測模塊、流量收集模塊、路徑計算模塊、流表導入模塊。拓撲發現模塊幫助控制器掌握通過全局的拓撲信息，包括主機的位置信息、交換機之間的連接等。大流監測模塊在鏈路利用率最大路徑上找出並標記大流。流量收集模塊周期性地收集OpenFlow交換機網絡的流量信息，為兩個節點之間的多條路徑選擇提供參考流量監測模塊統計交換機接口的流量信息，用於分析計算各鏈路的鏈路利用率。路徑計算模塊為大流的重路由提供支持，是實現負載均衡功能的重要部件。流表導入模塊是通過控制器向OpenFlow交換機發送Packet_out消息實現的，動態地將大流的最終得出的重路由路徑添加到交換機流表，從而實現OpenFlow網絡的負載均衡功能。負載均衡算法的實現流程如圖2所示。

ADVERTISEMENT

3 各功能模塊的數學建模與實現

首先為負載均衡制定一個啟動閾值，這裡採用負載均衡參數：

其中load_i，j(t)代表在t時刻鏈路<i，j>上的已經被占用的帶寬^[6]，N是網絡中所有鏈路的數目。下面簡單描述各模塊的實現方式。

3.1 拓撲發現模塊

拓撲發現模塊的功能是收集網絡的拓撲信息，將其保存在拓撲圖表中，並對網絡的拓撲結構進行管理。控制器與交換機之間是在OpenFlow標準協議的基礎下進行通信的，但是控制器並不能通過Open。Flow協議獲得網絡的拓撲結構，是通過LLDP組件^[7]發送LLDP(Link Layer Discovery Protocol)數據包到OpenFlow交換機，再收集並解析交換機反饋的LLDP數據包，從而實現網絡拓撲感知。

3.2 大流監測模塊

由於本文所提出的負載均衡機制是針對大流的，所以必須有一種方法將大流和小流區分開來。文獻[8]對3種主流的大流監測機制進行了分析比較，包括採樣監測、應用監測和統計監測。文獻[9]中提出探測大流最有效的方式是在終端主機進行，一方面占用的資源比例相對交換機要少，從而避免大流監測占用過多的交換機端資源；另一方面流的狀態也取決於終端應用程式生成數據包的快慢，而不是網絡的鏈路狀態，終端對應用程式發包速率的可知性更強。監測原理是通過觀測終端主機socket緩存區，當緩存區內具有相同特徵的數據包大小超過100 KB，它就會被標記為大流，本文便採用對主機端的統計監測方式來進行大流監測，主機端需要精確統計和維護數據流的速率和字節等信息，再將統計信息通過交換機發送到控制器，從而實現控制器的大流監測功能。

3.3 流量收集模塊

這個組件的目的是詢問每個OpenFlow交換機的流量信息，再將所有收到的反饋信息進行聯合併最終存儲到控制器的存儲單元。這些收集到的數據被路徑計算模塊用來計算不同鏈路上的負載，因為基於權重的多路徑路由的核心思想是將大流的數據包分配到負載較輕的鏈路上，因此需要確切知道路徑上所有可能的鏈路負載。這個單元模塊周期性地通過輪詢的方式收集每個OpenFlow交換機的流數量、流表以及埠數據，並作為一個快照對象進行存儲。每個快照對象都會通過一串數字標識，每個周期生成新的快照對象後數字標識會自動加1，存儲區只會保存最新的2個快照對象，其他的功能模塊都有獲得快照對象數據的權限。

3.4 路徑計算模塊

初始狀態採用Floyd^[10]算法計算基於跳數的Top-K最短路徑，然後需要對每條路徑的狀態進行評估。本文主要對路徑的兩個方面指標進行評估，一個是路徑所包含鏈路的長度，這個體現在跳數（Hop Count）；另外一個指標是路徑上的負載，這個體現在這條路徑所包含的交換機和鏈路上的流量。由於每條路徑上包含多個交換機以及多條鏈路，不能簡單地以總流量的平均數來表示這條路徑的負載，而應該根據特定的交換機和鏈路來代表該路徑的負載情況。交換機的負載通過它所統計的PC(Packet Count)和BC(Byte Count)來體現，鏈路的負載通過埠的轉發率（Forwarding Rate）來表示。這些數據可以通過控制器周期性地向OpenFlow交換機發送狀態請求消息得到。每條路徑的負載狀況可以表示為S=(H，P，B，F)，其中H表示跳數；P=Max(P₁，P₂，…，P_H)，P_i表示該路徑的第i台交換機所轉發的封包數量，共包含H台交換機；B=Max(B₁，B₂，…，B_H)，B_i表示該路徑的第i台交換機所轉發的字節數量。F=Max(F₁，F₂，…，F_H)，F_i表示該鏈路經過的第i台交換機出埠的轉發率。由於參數之間的差異比較大，需要先進行如下變換^[11]：

每一條路徑可以用矩陣R=(r_hr_pr_br_f)表示,權重向量W=(0.35，0.20，0.20，0.25)，各個參數值根據經驗自己定義，這裡路徑的長度取0.35顯示了其重要性。每個節點對之間的所有路徑可以通過一個矩陣表示為：

Q_i表示路徑i最後的權值，根據權值可以確定數據流經i節點傳輸到j節點的最佳路徑。路徑計算模塊偽代碼如下：

Algorithm : Route Construction

(1)Connect the topology with the RYU controller

(2)Detect the topology and do the following activities:

(3)Calculate top K shortest paths between each pair of nodes using Top-K Shortest Path algorithm(TKSP is the extension of Open Shortest Path First).

(4)Evaluate the Top-K path with the proposed method.

(5)Sort the paths between each pair of nodes according to the evaluation and store the results to the controller.

(6)Reconstruct the path using step1-5 in case of a node/link failure.

3.5 流表導入模塊

中心控制器通過路徑計算模塊產生的結果生成轉發規則，然後封裝到Packet_out消息中導入到支持OpenFlow的交換機，交換機流表添加該轉發規則並根據更新的流表項來指導流量轉發。由於網絡流量和拓撲結構都是不可預測的，交換機流表會伴隨負載均衡機制實時、動態地更新，而且過期的流表項會根據交換機配置而刪除。

4 實驗結果分析

本文採用Mininet2.2.0^[12]作為一個開發環境模擬數據中心網絡場景，搭建如圖3所示的網絡拓撲結構，在Ubuntu Kylin 14.04.3上運行RYU控制器，結合iperf工具來產生TCP(Transmission Control Protocol)數據流和UDP(User Datagram Protocol)數據流，並且能夠測量端到端的吞吐量，從而得出整個網絡的吞吐量。host1～4同時向host5～8發送數據流量，在RYU^[12]控制器中結合拓撲發現模塊、流量監測模塊、路徑計算模塊和流表導入模塊來對負載均衡算法進行驗證。仿真實驗通過h1～h16傳輸時延、總吞吐量和總體鏈路利用率這3個指標來驗證本文所提出的負載均衡算法的有效性。總體鏈路利用率通過下式得到：

其中，MAX_LOAD代表每條物理鏈路最大帶寬，仿真實驗的信息見表1。

選擇h1和h16為網絡時延測量的觀測對象,實驗結果如圖4所示，在實驗進行的前47 s數據包從h1～h16延時很低，而且本文所提出的LB(Load balance)算法和基於最短路徑算法的時延曲線表現出了極高的相似度。這是因為剛開始時鏈路負載較輕，兩種算法都是採用h1-S1-S9-h16來傳輸流量，而LB算法由於需要監測數據流量並且周期性地向控制器發送網絡狀態信息，這樣會產生部分開銷而導致延時略高於基於最短路徑算法；但是47 s之後LB算法下的時延明顯低於採用OSPF算法的時延，這是因為太多的流量集中在最短路徑h1-S1-S9-h16，而其他可用路徑處於空閒狀態，負載不均衡度大於判決門限，就會觸發負載均衡機制，原路徑上的流量會轉移到其他可用路徑，鏈路利用率也得到了明顯提升，如圖5所示。網絡整體吞吐量的性能比較如圖6所示，當負載低於550 Mb/s時，兩者的性能曲線非常相似，由於LB算法需要傳輸額外的鏈路狀態信息導致吞吐量會略高於550 Mb/s；當負載超過550 Mb/s，基於最短路徑算法網絡出現擁塞，其他可用鏈路得不到有效利用，吞吐量的增長明顯放緩。而LB算法下的網絡吞吐量在550～700 Mb/s區間能一直保持快速增長。因此本文提出的LB算法相比傳統的OSPF算法能夠在負載不均衡情況下改善網絡性能。

5 結束語

本文設計了負載均衡功能實現的總體框架，主要包括拓撲發現模塊、流量監測模塊、路徑計算模塊、流表導入模塊。設計了負載均衡功能的實現流程圖，對相關的數學模型進行了詳細的分析設計，確定了以大流為目標流的調度策略，並通過實驗驗證了該負載均衡算法相比傳統的OSPF算法能夠實現更低的網絡延時和更高的總體鏈路利用率和吞吐量。

該算法的不足之處是沒有考慮到大流出現重複調度的情況，如果某個大流被多次選為目標流調度，可能會使情況更糟糕，而且流的轉移開銷也會影響負載均衡的實現效率。降低大流在調度過程中的開銷具有重要的意義，上述兩點將是下一步需要重點關注的內容。

參考文獻

[1] 左青雲，陳鳴，趙廣松.基於Open Flow的SDN技術研究[J].軟體學報，2013，24（5）：1078-1097.

[2] Open Networking Foundation.OpenFlow[EB/OL].(2016)[2016].https：//www.opennetworking.org/en/sdn-resources/openflow.

[3] MCKEOWN N，ANDERSON T，BALAKRISHNAN H，et al.OpenFlow：Enabling innovation in campus networks[J].SIGCOMM Computer Communication Review，2008，38(2)：69-74.

[4] GREENBERG A，HAMILTON J R，JAIN N，et al.VL2：A scalable and flexible data center network[C].Proceedings of the AC_MSIGCOMM 2009 Conference on Data Communication.Barcelona，Spain，2009：51-62.

[5] GREENBERG A，HAMILTON J，MALTZ D A，et al.The cost of a cloud：research problems in data center networks[C].In ACM SIGCOMM，2008：68-73.

[6] Long Hui.Research on the OpenFlow -based load-balancing routing in distributed networks[D].Shanghai：Shanghai Jiao Tong University，2013.

[7] 張遠.基於OpenFlow的負載均衡研究[D].北京：北京工業大學，2014.

[8] 李龍，付斌章.Nimble：一種適用於OpenFlow網絡的快速流調度策略[J].計算機學報，2015，38（5）：1056-1068.

[9] CURTIS A R，KIM W.Mahout：low-overhead datacenter traffic management using end-host-based elephant detection[J].IEEE INFOCOM，2011，2(3)：1629-1637.

[10] BACKHOUSE R C，EIJINDE J P H W，GASTEREN A.J.M.V.Calculating path algorithms[J].Science of Computer Programming，1994，22(1-2)：3-19.

[11] Li Jun，Chang Xiangqing，Ren Yongmao，et al.An effective path load balancing mechanism based on SDN[C].IEEE 13th International Conference on Trust，Security and Privacy in Computing and Communications，2014.

[12] Mininet Team.Mininet：An instant virtual network on your laptop[EB/OL].(2016)[2016].http://www.mininet.org/.