开源SDN控制器并发缺陷的量化分析研究

郑 冰,李 华

(内蒙古大学 计算机学院,呼和浩特 010021)

1 引 言

SDN架构的网络中,控制器是负责管理底层网络的核心和关键组成部分[1,2],也是承载功能丰富的管理软件的网络操作系统,其质量对自己所承载的应用有很大影响.现有研究结果[2]表明,包括原型级控制器在内,65%以上的控制器均采用了多线程的并发编程技术,蕴含着并发缺陷,带来了网络运行的不确定.由于SDN的逻辑分层,天然具有异步性,使得并发缺陷更加需要关注.发现与修复并发缺陷是重要但耗时的工作.因此,极有必要对SDN控制器的并发缺陷及修复过程进行深入细化的研究.如果能够进行量化分析,对于它的缺陷修复具有更强的指导意义.

为了便于研究,研究对象限于代码和缺陷仓库开放访问的开源SDN控制器.现有开源SDN控制器主要分为两种[3]:作为某公司开发的产品的一部分在生产环境中应用和在学术研究中作为基础平台使用.虽然SDN控制器的实现技术各有不同,但均是基于SDN思想,实现大致相同的核心功能,提供类似的服务功能集合,因此各SDN控制器可能会出现相似的缺陷[3].通过针对现有研究和工业界应用情况的调研,开源SDN控制器按照应用场景分为3类:商业级通用、原型级通用和特定场景应用.基于调研结果总结了每类别中具有代表性的控制器及其代码级特征,如表1所示.

表1 按应用场景分类的开源SDN控制器(1)http://www.openhub.net,2021-04(部分)Table 1 Open source SDN controllers by application scenario1(part)

在SDN控制器并发控制实现过程中,采用了相应的并发编程技术,表1中列出的控制器均是如此.相比单线程控制器,多线程控制器适用于更复杂的环境,例如5G、SD-WAN和物联网等商业用途[4].发现与修复并发缺陷需要研究分析并发缺陷表征和修复过程相关的特征[5],通过对该特征的分析,有利于并发缺陷的再现和修复策略的制定.在软件缺陷管理工具的历史缺陷仓库和软件代码仓库的提交记录中保存了多个维度的缺陷表征和修复过程信息,因此可以基于该类数据进行特征量化分析.

下面以缺陷管理工具Jira获取的1个SDN控制器OpenDaylight(以下简称ODL)项目的真实历史缺陷作为实例简述研究动机.编号OPNFLWPLUG-1090(2)https://jira.opendaylight.org/browse/OPNFLWPLUG-1090,2021-04的缺陷报告所描述的缺陷发生在ODL南向接口插件SDN原生协议子项目OpenFlowPlugin中,具体表征及修复过程:1)报告者提交报告:单节点ODL控制器16台交换机部署下,在初始连接阶段出现了部分交换机连接请求被拒绝的情况;2)报告者和开发者通过评论区的讨论认为原因是由于多台交换机同一时间的握手请求引发了数据竞争,并且这一问题极有可能在大规模部署的生产环境中发生;3)开发者在代码仓库提交修复补丁代码;4)开发者在Jira中给出2个ODL版本的修复代码链接,并修改该缺陷报告的状态为“已解决”.

通过以上实例可以看到,真实的历史缺陷报告可以提供并发缺陷表征和修复过程的有用信息.本文以缺陷仓库真实历史并发缺陷数据为研究对象,采用量化分析的方式给出SDN控制器平台并发缺陷在典型并发缺陷类型的分布特征和修复过程的特征.不同SDN控制器项目并发缺陷的特征存在可能的共性,这些特征能够作为模式和规律传递的桥梁,有助于在SDN控制器平台上的应用程序的开发和调试,对SDN相关产品的理解、发展和管理也有帮助.本文所指的缺陷量化分析是将SDN控制器软件缺陷仓库保存的历史缺陷在产生和修复过程中产生的相关信息提取为多个维度的度量数据,统计量化计算分析度量数据的活动.并发缺陷特征是指在典型并发缺陷类型的数量分布特征和修复过程特征.

本文工作贡献如下:

1)给出一种半自动化量化分析SDN控制器并发性缺陷的框架方法;从软件缺陷管理周期出发,提出与SDN控制器软件并发缺陷数量修复过程相关的时间因素、缺陷影响、重要性和复杂度以及修复影响4个维度及10个具体度量,并给出度量指标的提取和计算方法;

2)在两个广泛使用的SDN控制器ODL和ONOS上进行了一系列实证研究.基于所给出的修复过程度量,对所获取的SDN控制器并发缺陷进行量化分析,给出了在典型并发缺陷类型的数量分布和修复过程特征的对比量化分析结果;给出了经过处理后的数据集,包含本文从ODL和ONOS所提取的修复过程特征的并发缺陷数据.

本文的其余部分组织如下:第2部分是相关工作,介绍与SDN控制器并发缺陷分析的相关工作并提出本文的研究问题;第3部分提出一种量化分析框架,给出修复过程度量,详细阐述了所采用的研究方法;第4部分给出SDN 控制器软件并发缺陷的量化分析结果,并进行了有效性分析;第5部分总结全文并给出未来工作展望.

2 相关工作

目前针对SDN控制器缺陷的研究工作主要从以下几个方面展开:通过文献综述的方法进行缺陷特征的分析,Yu等人[6]给出了SDN中可能出现缺陷的表征及根因;通过来自学术研究和生产运维中的观察及经验总结缺陷特征,Canini等人[7]关注了SDN控制器应用程序中存在的逻辑缺陷;通过实证研究的方法,利用真实缺陷报告获得SDN控制器缺陷特征,Vizarreta等人[5]通过统计分析方法给出了所报告缺陷数量的学习曲线模式和错误检测率的变化规律,又通过对ODL和ONOS控制器缺陷的研究[3],专门关注由分布式SDN控制器集群造成的缺陷,给出了缺陷的分类和根因分析.这些研究引入了预测SDN控制器缺陷数量、位置的模型和工具,但是并没有考虑特定的并发缺陷类型及其修复过程特征.关于SDN控制器的并发缺陷,Miserez等人[8]研究了SDN控制器和交换机交互引入的并发缺陷,并基于事件执行的有向无环图给出了相应的并发缺陷检测工具SDNRacer;MAY等人[9]进一步给出了SDN并发缺陷的检测工具BigBug.这些研究更多关注的是SDN架构中南向交互引入的并发缺陷及其检测,并没有过多关注由于控制器软件本身的多线程和分布式部署引发的并发缺陷及其修复过程特征.

由于不确定性,并发缺陷在开发和维护过程中的检测与修复一直是困扰开发者和使用者的难题.对于其他软件系统并发缺陷的研究有:Leesatapornwongsa 等人[10]对于数据中心分布式系统并发缺陷的表征、触发原因等进行了研究;Lu等人[11]对现实世界的真实并发缺陷进行了广泛研究;Gunawi等人[12]在对3000多个真实云系统故障事件的研究中,关注了由并发缺陷带来的云系统不确定性;石剑君等人[13]对操作系统并发缺陷的研究现状进行了分析.但是不同领域软件系统的并发缺陷都会有所不同[10],对于SDN控制器这类网络操作系统亦是如此[8],需要进行有针对性研究.

从真实缺陷报告中提取数据进行缺陷特征的分析,在许多与缺陷相关的研究中扮演着重要的基础性角色,相关研究包括:Zaman等人[14]对Firefox和Chrome的性能和非性能缺陷报告进行了量化分析,发现性能故障比非性能故障更难处理;Catolino等人[15]通过量化分析的方法研究了软件缺陷的根因分类和特征;Zheng等人[16]专门针对云平台OpenStack缺陷报告中的历史缺陷进行挖掘,给出了触发云平台缺陷的事件因素和动作特征.对缺陷报告的挖掘分析可以通过对所关注的特定度量指标的量化统计分析实现[17].

缺陷是软件产品期望属性的偏离,现有研究并没有对于真实SDN控制器并发缺陷的数量分布及其具体修复过程特征的研究.因此本文提出以下研究问题:

RQ1:SDN 控制器在各类型并发缺陷上的数据分布特征如何?各类型并发缺陷在SDN控制器各功能模块上的数据分布特征如何?

RQ2:以缺陷修复过程的多维度量作为表征,SDN控制器并发缺陷的修复过程特征是什么? SDN控制器的并发与非并发缺陷在修复过程特征上的区别是什么?

3 研究方法

3.1 方法的整体框架

SDN控制器并发缺陷的量化分析需要领域知识和对代码库的熟悉才能获得有意义的变化规律和分布特征[18].为了解决前面提出的问题,给出量化分析方法的框架如图1所示,具体步骤如下:

图1 SDN控制器并发缺陷量化分析方法框架Fig.1 Framework of quantitative analysis method for concurrent bugs of SDN controller

步骤1.数据收集及预处理.自动化进行缺陷报告数据的采集构成原始数据集BD;对文本数据进行预处理,生成文本语料数据集.

步骤2.修复过程特征提取.依据软件缺陷生命周期,提出修复过程的分析维度,给出修复过程度量和计算方法,利用Python工具计算提取修复过程特征,构成具有修复过程特征的数据集BD*.

步骤3.生成并发缺陷研究数据集.给出并发缺陷类型作为分类依据,利用自己设计的Python工具实现基于关键字检索缺陷报告文本语料集,获得候选缺陷报告.通过对代码提交记录和候选缺陷报告的人工筛选进行交叉验证,结合BD*获得具有修复过程特征的并发缺陷报告数据集CD.通过对BD*中的非并发缺陷报告进行分层随机采样获得比较分析需要的非并发缺陷数据集样本NCD.

步骤4.并发缺陷量化分析.给出量化统计分析方法,基于数据集CD和NCD,给出具体的量化分析结果,回答研究问题.

3.2 数据收集及预处理

开源社区缺陷管理工具(例如,Jira、Bugzilla)的缺陷仓库保存的历史缺陷报告数据可以公开访问直接获取.现有研究主要通过缺陷管理工具提供的开放API(Application Programming Interface)下载和爬虫爬取两种方式自动获取缺陷报告数据[16].为了确保数据集中只包含真正的历史缺陷,选择“Issue type”为“Bug”的缺陷报告,并保留缺陷管理工具中提供的所有预定义标签的数据作为量化分析的数据来源.虽然缺陷管理工具可能不同,项目定义的标签也会有所区别,但是按照通用的缺陷管理流程,一般由以下预定义标签组成:编号(Issue ID)类型(Issue type)、状态(Status)、创建者(Created)、优先级(Priority)、建立日期(Created)、摘要(Summary)、描述(Description)和评论(Comments)等.这些信息构成了以缺陷报告编号为索引的包含m条缺陷报告原始数据集合BD={b1,b2,…,bj,…,bm},其中,预定义标签是缺陷报告bj的默认属性,具有量化分析所需要的元数据信息,可以直接映射或派生为并发缺陷修复过程的具体度量.

对于缺陷报告bj中的文本数据,是由缺陷报告者和开发者提供的自然语言描述文本[5].具体包括:

1)摘要:是对缺陷问题核心的简练概括描述;

2)详细描述:不仅有自然语言描述,也时常附有触发缺陷的执行路径、代码片段、输出日志等,还可能包括报告者对于修复措施的建议;

3)评论:包含了开发者和报告者之间关于如何诊断和解决缺陷问题以及对于具体修复措施的讨论,也包含在代码仓库的修复链接.

缺陷文本中的信息可以作为识别并发缺陷以及修复过程度量提取(例如并发缺陷所影响的节点数目)的数据来源.将3个字段的文本内容以缺陷报告编号为索引进行拼接,构成分析所需要的文本语料集.然后,在原始数据集BD的基础上,计算提取修复过程度量,基于文本语料数据集和相应代码仓库的提交记录筛选并发缺陷.

3.3 修复过程特征提取

在缺陷管理工具中,缺陷生命周期是缺陷在最终解决之前所要经历的多个阶段,其核心任务是修复软件缺陷,因此本文所研究的特征关注了缺陷修复过程特征.在缺陷生命周期管理过程中,基于缺陷管理工具的典型缺陷修复过程如下[5,19]:1)报告者提交一个缺陷报告;2)缺陷被分配给开发者;3)开发者诊断缺陷并确定修复策略,这期间可以通过评论区与报告者进行交互;4)开发者修复缺陷,并标记缺陷报告状态为“已解决”或“修复”.

结合典型缺陷修复过程,基于BD数据集中包含的元数据信息,以下给出缺陷修复过程中所关注的4个维度和10个修复过程度量的定义和相应的形式化描述.

定义 1.(缺陷修复过程(FTP)).假设所有缺陷报告都被分配了正确的状态和优先级,缺陷修复过程表示为四元组FTP={T,S,I,F},其中:

·T表示缺陷修过程中的时间因素,可以表示为三元组T= {t_tr,t_dr,t_acomm},缺陷修复过程中涉及的主要时间点包括,从缺陷的报告开始,期间的评论互动,再到最后的缺陷解决或修复,可以反映缺陷修复的效率;

·S表示缺陷影响的范围,可以表示为二元组S={n_affv,n_node},由报告者或开发者认定缺陷发生所影响的版本数和节点数,可以反映缺陷发生的具体部署配置,对修复过程也会产生影响;

·I表示重要性和复杂度,由三元组I={priority,n_comm,n_sdc}表示,是开发者或报告者认为缺陷对于软件质量影响的重要程度以及表征修复缺陷本身的复杂程度;

·F表示修复结果,可以表示为二元组F={n_patches,n_fixv},是开发者对缺陷修复的最终结果.

针对4个维度中的指标,依据可获取原则,本文选取了10个具体度量,其详细描述如表2所示.

表2 并发缺陷修复过程量化分析维度及具体度量Table 2 Quantitative analysis of the measurement and metrics of concurrent bugs fix process

利用Python工具自动化实现具体度量数据的计算提取,所采用的方式包括从数据集中直接获取、通过计算派生和通过文本提取3类:

1)在直接获取的数据中,补丁数n_patches是通过代码仓库的提交记录和代码审计仓库获得.

2)通过计算派生的数据主要指时间因素(T)中的度量,其中,平均评论时间间隔t_acomm可以表征每条缺陷报告的报告者和开发者之间互动的频率,所设计的计算方法如公式(1)所示:

(1)

其中k表示缺陷报告的评论数(n_comm=k),t_commi表示该缺陷报告第i条评论的提交时间.

3)通过文本提取的数据主要指节点数n_node,可以表征发生缺陷时的具体部署配置,这里的节点数主要指发生缺陷时的SDN控制器的节点数目.具体赋值方法:节点数对缺陷无影响或缺陷报告中描述模糊的情况,均赋值为0;单控制器节点部署赋值为1;控制器集群部署情形下按照具体节点数赋值.

为了保证所分析的并发缺陷的准确性,只关注已解决和已修复的历史缺陷报告.从原始数据集BD的m条缺陷报告中筛选出n条符合要求的报告,按照上述方法,计算提取出FTP 4个维度的度量,形成数据集BD*.

3.4 生成并发缺陷研究数据集

为了有效的收集SDN控制器的历史并发缺陷,采用基于关键字的检索方式筛选并发缺陷[17,18,20].在文本语料具备相关信息的基础上,需要进行并发缺陷相关的关键字的选择.本文关注的并发缺陷是指:两个或两个以上的线程因交互作用于一个或多个共享资源而引起的程序崩溃或挂起,或产生与串行执行不同的结果,且这样的结果是不确定的.表3给出了具体并发缺陷类型的描述及对应的检索关键字.

生成并发缺陷研究数据集的过程如下:

1)对文本语料集进行筛选,保留已完成和已修复缺陷报告的n条语料数据,包含了各种类型的缺陷,基于表3中的关键字,利用Python工具采用检索技术筛出包含一个或多个关键字及其单词变形的缺陷报告,获得候选集.

表3 并发缺陷类型描述与关键字Table 3 Description and keywords of concurrent bugs

2)通过对候选集与代码仓库中的提交记录进行交叉核对的人工筛选方法获得SDN控制器的真实并发缺陷,并在数据集中标记具体并发缺陷类型,生成并发缺陷报告数据集CD.其中代码提交记录可以从缺陷报告中的修复链接获取,也可以从代码仓库(例如Git)的提交日志获取.

3)为了进行对比分析,采用分层抽样的方式筛选同等数量非并发缺陷样本.将所有非并发缺陷数据按照缺陷报告创建日期和所属的功能模块划分为多个类别,以保证所选取的样本尽量与并发缺陷报告具有相同的分布,减少后续量化分析中的误差,然后从每个类别中随机抽样选择缺陷报告组成非并发缺陷对比分析数据集NCD.

3.5 量化分析方法

采用的具体统计分析方法包括:

1)对于分类数据,通过统计不同分类下的数量,给出频数和频率(频数与数据总数的比值)分布.

2)对于数据分布特征的描述性统计,通过统计学中常用的集中趋势分析给出,采用的测度值包括,平均值、中位数、四分位数(75%)、极大值和众数.

3)两个独立样本比较检验,对于需要进行两组数据的对比分析时,统计学中经常假设数据满足某种分布,由于待检验数据集中的数据特征不一定遵循特定的分布,因此,并不假设数据服从某种分布,为了检验两个独立样本数据组间(并发缺陷和非并发缺陷)的特征值(修复过程特征)是否存在显著差异,使用Mann-Whitney U检验方法[16](简称MW U检验)进行统计检验,这是一种非参数检验,并且不需要做出数据具有正态分布的假设.显著性水平α=0.05取,如果p<0.05时认为所检验的两组数据间存在统计学上的显著差异.其中,p 值(P-value)是当原假设为真时,所得到的样本观察结果或更极端结果出现的概率,p值也称为观察到的显著性水平.

通过上述方法量化分析比较不同控制器之间以及控制器的并发缺陷和非并发缺陷在不同度量上的分布特征.

4 实例分析

4.1 实例研究对象选取

在采用实例进行研究时,选择有代表性的SDN控制器作为实例研究对象非常重要.为了确保代表性所采用的选择标准是:缺陷仓库可以公开访问且有至少1000条的缺陷报告;代码仓库可以公开访问,社区达到一定规模,此条标准通过代码行数和贡献者人数衡量;项目年限超过5年,保证并发缺陷具有足够长的演进历史可供量化分析;项目活动水平,通过一年内代码仓库的提交次数衡量.

按照以上标准,通过对表1中控制器相关数据的对比,选择ODL和ONOS作为实例研究对象.选择二者的其他优势包括:ODL和ONOS是目前较为典型的生产级开源SDN控制器[2],二者面对的主要目标用户不同,实现功能组件亦有所区别,一定程度上可以覆盖相对较多应用场景的SDN控制器并发缺陷特征.尤其是,ODL生态中包含了控制器和在控制器平台上实现的不同功能的网络应用程序,可以认为其缺陷仓库包含了以控制器为核心的控制平面、数据平面和应用平面在内的历史缺陷报告集合.由此保证了实例研究对象的代表性.

下面按照3.1节给出量化分析方法的框架,对实例研究对象进行处理及分析.

按照图1的步骤1进行数据收集及预处理,通过Jira API自动获取ODL和ONOS可以公开访问的历史缺陷报告,进行初步筛选统计的数据集信息如表4所示.其中,项目总体的缺陷修复率是指有明确解决方案的缺陷报告数/总缺陷报告数,ODL比ONOS的缺陷修复率低,主要因为缺陷整体修复率与项目规模呈负相关关系[16].需要说明的是,虽然二者缺陷报告在绝对数量上有差距,但是量化分析更关心的是相对数量,并不会影响分析结果.

经过了图1的步骤2和步骤3,对有明确解决方案的缺陷报告进行修复过程特征提取、关键字匹配、人工筛选以及分层随机抽样后的数据集样本数量如表5所示.

表5 各筛选阶段的缺陷报告数据集样本数量Table 5 Number of bug report data set samples at each stage

在表5中,对用于分析的数据进行了相应的预处理,例如,将优先级由文本映射为数字,根据不同粒度计算时间因素的度量,对于修复时间以“天”为粒度计算、对于回复延迟以“小时”为粒度计算等.

4.2 并发缺陷的量化分析

4.2.1 并发缺陷分类数据特征分析

本部分的量化分析结果可以回答RQ1,给出SDN 控制器在各类型并发缺陷和在各功能模块之间的数据分布特征.对于所获得的历史缺陷报告数据集,统计不同分类下的频数与频率分布.ODL和ONOS所发生并发缺陷类型分布特征如表6 所示.

表6 历史缺陷报告在并发缺陷类型的分布特征Table 6 Distribution of concurrent bugs for historical bug reports

基于表6给出的数据,对5种类型的并发缺陷的实例分析如下:

1)原子性违背:一般是由于线程交错操作缺乏约束破坏了假定具有原子性的操作.例如,在 ODL中的OPNFLWPLUG-1075,由于破坏模型驱动项目MD-SAL中事务写操作的原子性导致了端口事件线程关闭.ODL使用Java的CAS(Compare and Swap)指令实现原子性,CAS 指令被看作是硬件锁.ODL和ONOS中原子性违背的历史缺陷数量较少且大多发生在项目初期.

2)顺序违背:多个线程在同时执行时,未能按预期设计的顺序进行交互,出现了不正确交错执行.在SDN控制器所涉及的相关协议实现中,为了加强事件之间的因果关系,事件排序是必要的.其中,典型的问题是在控制器和交换机的交互中写(FLOW_MOD)和读(PACKET_IN)发生了顺序违背,交换机的转发状态可能会有很大的不同.例如,ODL的NETCONF协议项目中的NETCONF-93,多个配置通过一个会话异步发送,导致操作互相干扰,多个写的提交操作出现了乱序的问题.而ONOS项目中出现的流表规则的提交顺序冲突也属于此类问题.

3)数据竞争:是由共享资源引发,也包括共享数据库,是2个实例项目中出现最多的并发缺陷类型,这也与现有研究的结论相符合[13].在SDN网络中,特有的重要共享数据资源是流表,ODL提供两种数据存储,配置存储(config datastores)用于存储用户所需的状态,操作存储(operational datastores)用于存储实际的网络状态.ONOS的共享数据库是流规则存储(FlowRulesStores).由于共享造成的数据竞争,可能发生在节点内部,也可能发生在节点之间.例如,ODL项目中的BGPCEP-645,关闭对端并更新路由时发生对共享资源的竞争访问.对于非死锁类的并发缺陷,大多可以归因于数据竞争,也是任何并发软件系统中的基本问题.

4)死锁:死锁在2个实例项目中都有发生,ODL项目中发生的更多.例如,ODL项目中的CONTROLLER-1893,应用程序线程出现了死锁.在NETVIRT-424中出现了典型的ABBA死锁,由于互斥锁的粒度不恰当(粒度较粗),与 MAC 相关流的互斥锁在 ELAN + MAC 上的锁定无法操作,解决方法是通过锁定更细粒度的互斥锁锁定ELAN+MAC+DPID.SDN集群中会发生分布式死锁,即每个节点都在等待以便其他节点进行下一步操作,引发整个集群挂起.例如,ONOS-1965在Leader选举过程中,候选节点重启后没有出现在候选列表中,引发了死锁.

5)并发类型状态缺陷:会使系统进入不正确的状态.典型的是发生在SDN集群部署中,尤其是集群中的全局网络状态保存在多个同步的控制器中,并分散保存在数据平面的交换机中,如果出现并发类型状态缺陷,会造成不同控制节点有不同的全局视图的后果.在表6中,值得关注的是ONOS比ODL有更多的历史并发类型状态缺陷,这是因为ONOS在设计之初即考虑了分布式的集群部署方式实现,采用逻辑上集中控制实现分布式核心层.在ONOS缺陷管理工具中,报告者对于出现故障的表征更倾向于采用出现“状态不一致”等文字描述,为了区别于4类典型并发缺陷,本文将这些缺陷归类为并发类型状态缺陷.例如,ONOS-4515中的数据平面转发设备角色在3个集群节点间不同步,其中1个节点看到角色为“none”的5台转发设备,另外2个节点看到角色为“standby”的5台转发设备.为了让SDN控制器网络正常运行,这些集群节点的状态必须是一致的.

对于并发缺陷在功能模块上的数量分布,由于ODL生态中包含了以控制器为核心的3个平面的缺陷报告集合,以ODL为例进行分析.ODL控制器采用模块化的设计,不同子项目一般代表不同的功能模块.参考ODL官方网站的信息(3)https://www.opendaylight.org,2021-04和现有研究[5],对ODL进行功能模块划分,给出SDN控制器并发缺陷在功能模块上的数量分布,如图2所示.

图2 ODL历史并发缺陷在功能模块上的分布特征Fig.2 Distribution of ODL historical concurrency bugs on functional modules

由图2可以发现,南向接口插件和控制器核心功能的并发缺陷数量较多.在SDN控制平面和数据平面南向交互过程中涉及了多个协议,如OVSDB、NETCONF和POF等,而使用协议通信实现平面间的交互,增加、修改、删除和查看转发设备的配置和状态信息,对应了多线程实现中的读和写操作,容易引入并发缺陷.在与传统网络互联的南向插件中,发生死锁的情况使最多的,并且主要发生在3层网络路由的相关功能中.另外,控制器通过南向协议下发配置策略中出现的并发缺陷同样较为典型.例如,在通过NETCONF配置网络的过程中,NETCONF-58只通过REST操作,当删除和初始化连续发生时,出现了事务链上的数据竞争,导致事务链失败,解决方法是修改操作的逻辑顺序,首先应该删除配置而不是立即替换它,即,修改 POST>PUT 为POST>DELETE>POST.北向应用出现并发缺陷的数据较少,主要是基于意图通过流编程实现网络配置更新过程中出现的顺序违背(GBP-288).另外,在集群部署情况下,对于以多控制器为中心的东西向分布式协议的交互中,ODL具有多任务并发的特性,因此出现并发缺陷相关的问题主要是在核心控制器功能模块的集群(clustering)组件中.

通过以上分析发现:数据竞争仍是SDN控制器中最常出现的并发缺陷类型;由于分布式的部署方式,ONOS控制器中并发类型状态缺陷出现较多;ODL控制器中南向接口插件和控制器核心功能的并发缺陷数量较多,集群组件是发现并发缺陷过程中值得关注的组件.

4.2.2 并发缺陷修复特征量化分析

本部分给出的数据和分析可以回答RQ2,给出SDN控制器并发缺陷的修复过程特征的分析,以及并发与非并发缺陷在修复过程特征上的区别分析.表7给出了在修复过程度量上的量化分析结果,包括:并发缺陷数据(CD)和非并发缺陷数据(NCD)集中趋势分析的测度值,每个修复过程度量的分布在并发缺陷和非并发缺陷两个分类上的Mann-Whitney U检验的渐进显著性结果p值.为了可读性和避免异常值,在计算统计值时,去掉0值的影响,并且仅统计度量值是离散型数据(例如n_node)的众数.

表7 SDN控制器并发缺陷修复特征量化统计信息Table 7 Descriptive statistics of concurrency bugs for SDN controllers

通过定量方法来调查SDN控制器软件中并发和非并发缺陷在修复过程的异同.对于表7具体分析如下:

1)时间因素的分析.与预先的设想并不相同,SDN控制器中修复并发缺陷和非并发缺陷所投入时长的区别并不明显.相比其他软件,如Apache、ZooKeeper、 Spark 等开源软件中并发错误平均修复时间(82天)[13],SDN控制器的并发缺陷的平均修复时间是66天左右,需要的修复时间更短.对于反映互动频率的度量t_acomm,虽然p=0.054,区别并不显著,但是通过集中趋势分析的测度值可以发现,相对非并发缺陷而言,并发缺陷的平均讨论时间间隔更短,报告者和开发者互动的频率相对更高,对于SDN控制器,修复并发缺陷并不容易,需要通频繁互动补充必要的信息,例如触发缺陷的配置及操作,可能的根因的讨论等.

2)缺陷影响的分析.对于并发缺陷和非并发缺陷,影响节点数的度量n_node的区别显著(p≪0.05),因此,主要分析并发缺陷所影响的节点数目.SDN网络中,在测试或生产部署的过程中,包括单控制器节点部署和控制器集群部署两种方式.单控制器节点在开发测试阶段比较常见,生产环境中多以集群方式进行部署.并发缺陷影响的节点数目可以分为不同的情形:①只发生在单个SDN控制器节点,尤其是在连接多台交换机的单控制器扩展性测试中出现并发缺陷的情形出现较多;②只发生在集群中,例如,BGPCEP-442是发生在集群(3节点)中的数据竞争;③在单节点和集群中均发生,这类缺陷出现的情形最为普遍.但是受限于数据集来自于开发阶段的SDN控制器,节点触发范围的规模较小:多为1个节点(表7中众数为1);涉及到控制器集群,多为3个节点,例如,在ODL关于集群的并发缺陷报告中,以3节点集群测试例所报告的缺陷为主;最大为7个节点的情形.对于ONOS,在集群部署的情况下,即使一个缺陷只出现在一个节点上,它也会将其影响传播到其他节点或组件,从而导致集群的一部分或整个集群失败.对于非并发缺陷,节点数的影响并不明显,集中趋势分析中的多个测度值为0.

3)重要性和复杂度的分析.并发缺陷和非并发缺陷在优先级上的区别并不显著,但是在文本长度和评论数上均区别显著(p≪0.05),并发缺陷仍然是SDN控制器项目投入更多关注的缺陷类型.

4)修复影响的分析.从表7中可以看到,在所给出的2个度量上,两组数据均区别显著.与修复非并发性缺陷相比,修复并发缺陷明显涉及更多的补丁,有更多的修复影响版本,明显需要开发者投入更多工作量进行修复.

在SDN控制器中由于各平面的分离和分布式的部署方式,并发缺陷仍然需要关注.通过对比分析发现:并发缺陷在修复过程中,需要通过配置特定节点数目的SDN控制器才能够复现;虽然并发缺陷并没有赋予更高的优先级,但是需要开发人员投入更多工作量进行复现并修复.这些发现可以为并发缺陷检测和修复提供有用的指南.

4.3 有效性分析

对于实证研究需要讨论数据身来源是否真实可靠的有效性以及所得结论是否具有推广价值的有效性[21].由于所研究的缺陷是经过真实项目的开发团队成员的确认,设置状态为“已关闭”或“已解决”的缺陷,并通过与提交代码记录的交叉对比,因此认为是可以真实地反映实际缺陷情况的;其次,研究只关注ODL和ONOS两个SDN控制器项目的缺陷数据量的相对关系,从这个意义上说,在一定程度上可以屏蔽在代码规模和功能复杂程度的差异;第三,对于并发缺陷,基于关键字的搜索可能会遗漏一些真正的并发缺陷,但不包含任何所选关键字的并发缺陷报告极有可能没有包含完整信息,对分析而言没有用;第四,如4.1节所述,所选择实例分析SDN控制器项目具有代表性,但是,由于ODL和ONOS是开源项目,研究结果可能不适用于闭源的SDN控制器项目,未来,需要更多的数据来支撑更可靠的结论.

5 结 语

本文提出了SDN控制器软件并发缺陷量化分析方法框架,对SDN控制器软件的并发缺陷进行了实证量化分析.所提出的量化分析框架并不依赖于具体的SDN控制器软件,因此方法具有一定的通用性,可以用于或适应其他软件系统.基于软件缺陷生命周期给出了4个维度10个具体度量作为并发缺陷修复过程的评估指标.采用统计学中的量化分析方法研究了SDN控制器并发性缺陷在不同类型并发缺陷和功能模块的分布特征以及在所给出的修复过程度量所表现特征,可以为SDN控制器平台使用者和基于平台进行应用开发的开发者提供一个新的视角理解SDN控制器中出现的并发缺陷.也可以为SDN控制器的部署和后期维护提供便利支持更好地管理控制器应用软件产品,改善SDN控制器平台的并发缺陷修复过程.