高陆云
江苏省通信管理局
随着云计算技术的不断发展,无论是Openstack、Cloudstack等原生态开源云计算平台,还是VMWare Cloud等非开源云平台,亦或是基于开源云平台开发的适应各种特定场景需要的云平台,不断被应用到当前数据中心的建设方案中。传统数据中心以设备为中心,存在将IT技术与业务分离看待、无弹性、不灵活等缺点,已经无法满足日益复杂的业务需要。而云计算将整个IT体系架构从底层的基础设施、应用开发和平台,到业务软件均作为一种服务,弹性按需交付。云计算的多租户(Muti tenancy)概念要求不同租户间网络隔离,形成虚拟数据中心(VDC),极大地满足了数据中心运营商的现实需要,VDC已成为当前数据中心的主要建设形式。
此外,与传统数据中心不同,通信服务正向着宽带化、融合化、智能化和云化的方向发展。传统数据中心在架构上控制与转发不分离,控制功能与转发功能集中在同一网络设备中,整个网络是固定、不便于调整、无法集中控制的。而软件定义网络(SDN)将控制与转发分离,控制功能集中到控制器上,网络设备瘦身为转发设备,这种架构正在驱动网络和信息服务基础设施新一轮的变革。数据中心集中网络管理的现实需要,更使得SDN技术在VDC建设中得以广泛使用。
因此,基于SDN技术的云平台虚拟数据中心方案逐渐成为一种较为常见的数据中心建设方案。新技术的不断涌入和发展,特别是云架构的普遍使用,加上虚拟化对传统IT和CT的影响,给运维故障定位带来了新的挑战。
2008年,美国斯坦福大学提出了OpenFlow技术,并以此技术为基础,实现了SDN控制转发分离架构(见图1)。OpenFlow技术以流表达方式抽象了数据平面转发行为,并作为SDN体系中数据平面与控制平面之间通信接口的标准。OpenFlow协议使得设备内OpenFlow通道与外部控制器之间互通。
图1 OpenFlow基本架构
2012年,ONF(开放网络基金会)在软件定义网络的白皮书中首次提出了软件定义网络的体系框架(见图2):基础设施层、控制层、应用层。其中控制层是核心,由SDN控制软件组成,基础设施层由简化了的去除控制等功能后的网络设备组成,应用层由业务应用组成。控制层与基础设施层通过控制数据平面接口(如OpenFlow)交互,控制层与应用层之间通过API接口交互网络状态信息。
图2 SDN体系框架图
在虚拟数据中心(VDC)应用SDN后的网络体系架构如图3所示,包含应用层、编排层、控制层和转发层。
应用层:包括云化管理平台、SDN应用程序、SDN管理程序、网管等。
编排层:包括SDN编排器等。负责分配资源、冗余管理、错误管理和弹性调整,实现云业务中网络资源的自动开通与部署。
控制层:主要包括SDN控制器。负责流量控制来确保智能网络,满足云业务对网络资源的需求。
转发层:包括SDN转发设备等。可为软件设备或传统网络转发设备。
图4是一个典型的基于SDN技术的数据中心组网架构,采用SDN+VXLAN(虚拟扩展局域网)组网,SDN网络控制器处于核心地位,通过OpenFlow协议控制网络中的设备,包括虚拟的vSwitch(虚拟交换机),物理的TOR交换机等。其中vSwitch作为VTEP(VXLAN隧道终端)。
图4 基于SDN技术的数据中心组网架构图
基于SDN技术的虚拟数据中心运维实践中,网络故障定位面临新的挑战。从技术实现角度看,IT和网络的虚拟化带来了动态性、易变性、开放性、多元性,因此,给故障定位带来的挑战是多方面的。
1.3.1 传统网管的挑战
传统网管是对网络中的物理设备进行监控和管理的重要手段。常见的功能有告警监控、性能任务监控、拓扑展示、设备配置等。然而在SDN场景下,控制和转发功能分离,控
制功能被集中到SDN控制器上,转发功能可由传统物理设备实现或软件实现(如Open vSwitch等)。传统网管无法实现对SDN场景下控制和转发功能的完整监控管理。此外,在OpenStack等云化管理场景下,IT虚拟化技术的广泛使用使得原先针对物理服务器的监控管理方案更显得力不从心。
1.3.2 巡检工具的挑战
巡检工具对于网络运维是必不可少的,可以将预先设定的检查项进行定期周期性核实,然而亦存在许多弊端。首先,巡检工具的执行需人工触发,执行频率较低,半年甚至一年才执行一次,即使1个月或者几个星期执行一次,对于故障定位来说,实时性仍不够;其次,巡检是预置的、固定的,是不灵活的,无法研判未知故障,只能对已有故障进行巡检核实;再次,巡检工具按照固定的模式核查网络中是否存在异常,发生故障时无法有针对性地快速查找原因。
1.3.3 运维人员学习的挑战
虚拟化、特别是云化技术的发展,以及新概念、新技术的涌入和迭代,使得领域间不断整合、融合,以往按照网络所承担的功能分工运维的模式不再适用。运维人员需打破现有知识结构,学习并融会贯通各领域知识技能,才能适应当前的运维工作需要。
SDN组网架构下,数据中心核心协议就是OpenFlow协议。此外,VXLAN组网亦是最常用的技术。相较VLAN组网,VXLAN组网突破了4000+子网的限制,且由于VXLAN协议架设在UDP协议之上,具备较高的扩展性。因此,在基于SDN技术的VDC故障定位中,基于OpenFlow与VXLAN的协议分析是首选方案。基于协议分析的故障定位技术将故障排查重点放在OpenFlow交换机和VXLAN VTEP两个协议载体上。
OpenFlow交换机,即支持OpenFlow协议的交换机,其内包含流表、组表以及连接SDN控制器的OpenFlow通道。在现有商用产品中,OpenFlow交换机可以是Open vSwitch,也可以是传统交换机改造后的混合物理OpenFlow交换机。故障排查定位以OpenFlow交换机流表分析为主线,核查数据包走向和丢失问题。
VXLAN VTEP就是封装和解封装VXLAN包围的网络设备。在数据中心组网中,一般有三种角色:VXLAN VTEP、VXLAN GW、VXLAN IP GW。VTEP是直接与虚机(VM)连接的设备,负责原始以太网包围的VXLAN封装与解封装。VXLAN GW将VXLAN报文转换成对应的传统二层网络送到传统以太网,适用于VXLAN网络内服务器与远端服务器的二层互联。VXLAN IP GW将VXLAN报文转换成传统三层报文送至IP网络,适用于VXLAN网络内服务器与远端终端之间的三层互访,同时也用作不同VXLAN网络互通。VTEP故障排查以VXLAN报文流向为主线,核查数据包走向及丢失问题。
OpenFlow交换机支持OpenFlow协议,按照流表规则对流量进行处理(转发、丢失、缓存)。流表分三个部分:头域、统计域、动作域。其中统计域保存了该条流表项所匹配报文的基本统计信息,包含流表、流、接口、队列统计信息,统计项的值在OpenFlow交换机运行时自动更新。故障定位可以从负载、时延、丢包率、流量分布等维度分析。
在当前基于SDN技术的VDC网络组网中,存在物理网络设备,例如物理OpenFlow交换机、用于接入或者汇聚的交换机、VXLAN网关等。站在物理设备的角度,排查接口数据包的实际状况,以及包转发路由状态,也是故障定位的一个方向,一般可以确定物理设备硬件或者软件故障。
在传统网络管理架构下,网元设备通过SNMP等协议上报告警信息,这些告警信息实时告知维护人员设备上的异常。然而这些告警都是以设备为单位组织上报的,设备间的告警是割裂开来的,缺乏统一分析。此外,设备上的告警信息往往无法涵盖发生问题的具体原因。现实维护场景下常出现这样的状况:上报告警与本次故障无关,花费人力解决了一些非紧急的故障,而急需解决的故障却被耽搁;或者告警量过大,无法精确快速筛选哪条或者哪些告警与本次故障相关。因此,告警的只能融合分析是很有必要的,特别是在虚拟化场景下。
系统可集成在传统网管中,作为传统网管的深层次功能对外整体展现,开发架构上采用BS架构,客户端只需要安装浏览器即可使用。
系统可以部署在物理服务器上或者虚机上,网络上需打通与SDN网络的网络通道,或者直接部署在SDN网络中,外部网络远程访问系统需要通过防火墙隔离(见图5)。系统还可以通过支持的协议向第三方管理系统上报信息。在部署形态上,支持单机或者冗余备份部署。
图5 故障定位系统网络部署架构图
系统实现架构如图6所示。管理网络接入适配接口负责接入适配SDN网络中的所有管理设备(包括Open vSwitch),接口包括SNMP、Netconf、FTP等。在管理网络接入适配接口之上是故障定位核心模块,包括协议分析模块、流量分析模块、设备分析模块、告警智能综合分析模块,从4个维度(第2章节介绍的4类故障定位技术)综合定位分析网络故障。而安全鉴权模块、日志记录模块、系统监控模块是系统基本模块,上报第三方适配接口主要用于对接第三方系统,支持SNMP、FTP等协议。
图6 故障定位系统实现架构图
基于SDN技术的虚拟数据中心网络故障定位系统通过协议、流量、设备、告警智能综合分析开展多维度的网络故障定位分析,在当前SDN网络数据中心实际场景下具备较高的应用价值。系统以端到端的概念代替网络设备端点的割裂分析,加快了网络故障定位的速率,可以较好地缓解运维故障定位压力。在某虚拟数据中心为期一年的运维实践中,系统故障定位有效性达85%以上,效率提升近50%。
本文以分析当前流行的基于SDN技术的虚拟数据中心网络架构为切入点,介绍了虚拟化和云化后的数据中心采用SDN技术后的整体架构及应用,研究了虚拟数据中心运维故障定位技术,并基于技术方案提出了虚拟数据中心网络故障定位系统设计和实现架构。实践效果表明,该系统对于辅助运维人员快速定位、分析和研判虚拟数据中心网络故障,提升工作效率具备较高的应用价值。然而,在具体实践过程中,网络故障的定位仍有诸多难点,部分网络故障定位采用预置知识尚无法自动研判,还需人力辅助,有待进一步研究。