“多租户和可编程网络中的故障管理”

博士学位论文答辩前报告员：Hind Castel，巴黎南部电信教授Stefano Secci，巴黎CNAM教授评审团组成：Hind Castel，巴黎南部电信公司教授。报告员Eric Fabre，INRIA雷恩研究总监。Yacine Ghamri-Doudane博士生导师，拉罗谢尔大学教授检查员Gregor Gössler，INRIA格勒诺布尔研究员。审查员Sofiane Imadali，Orange实验室研究工程师。特邀成员Stefano Secci，巴黎CNAM教授。报告员Sandrine Vaton，布列斯特IMT教授审查员Dir.论文作者：Eric Fabre，INRIA研究总监。共同导演。论文作者：Gregor Gössler，INRIA研究员。L’UNIVERSITE DE RENNESCOMUEU NIVERSITEB RETAGNE L'Oire第601号博士学校数学与信息与通信科学与技术通过"Sihem Cherrared"多租户和可编程网络中的故障管理2020年6月26日提交并答辩论文研究单位：ORANGE Labs Netwoks INRIA一个知识分子首先，我要如果没有大量人的有意识的干预，这一论点我想在这里感谢他们。我的导师们的信任、耐心和建议是一个巨大的贡献，没有他们，这项工作就而且，我要感谢我的论文导师埃里克·法布尔，感谢他我感谢我的主管Sofiane Imadali对我感谢我的导师格雷戈尔·戈斯勒，感谢他为丰富和完成我的论文工作所提供的我还要衷心感谢评审团成员对我的工作表现出的兴趣，他们同意审查我的工作，并提出他们的建议。我感谢报告员花时间审阅我的手稿和他们的相关评论。我不会忘记我亲爱的父母，我的兄弟姐妹，他们总是在那里支持我，以他们自己的方式面对这篇论文的困难。 还有我的侄子和侄女，他们给我的生活带来了当然，我要感谢我在Orange和Sumo团队的同事们，感谢他们在我的博士论文中共同度过的美好时光。最后，IIID.教育致我亲爱的母亲，致我的父亲，给我的兄弟姐妹。IVR总结在F Rancais背景和问题新一代移动5G此外，数十亿个具有不同需求水平的对象将需要连接。这种新环境提供了更加动态和灵活的服务，同时降低了实施和维护成本。此外，为了从虚拟化中获得更大的好处，运营商与客户共享其未占用的资源。这些客户来自具有不同优先级服务的不同行业（例如，部署在运营商基础设施上的医院网络）。这是通过"多租户"概念实现的，该概念允许多个客户端在同一基础架构中共存。在这种类型的环境中，服务的可靠性成为一个关键问题。一次简单的故障就可能造成重大的人员和金钱损失。特别是因为受影响的部门是敏感的，例如联网的自动驾驶汽车， 工业过程或外科机器人。因此，有必要快速检测和定位故障，同时朝着自我修复的方向前进对于像Orange这样的网络和云运营商来说，提供具有强大弹性和故障恢复保证的服务，同时优化资源使用，将是其未来客户的一个关键卖点。 事实上，服务故障另一方面，这些故障可能会影响其客户所感知的服务质量形象。这种损失的一个例子是因此，管理故障至关重要，尤其是服务虚拟化是电信世界中的一个新兴方面。虽然故障管理是运营商熟悉的一门学科，也是过去多次解决的一个问题，但在这些挑战中，我们可以特别提到动态拓扑。实际上，网络实体拓扑的不断变化使得根的定位复杂化。V并可能导致错误的结果。本论文的目的是通过开发故障因果关系监控机制来保证虚拟化电信网络服务的可用性。这些机制允许发现有故障的组件，从而我的论文工作描述在这份手稿是结构如下：• 在第二章中，我们通过解释虚拟化电信体系结构的组成和特征来介绍本文的一般背景。我们描述了"虚拟IP多媒体子系统（vIMS）" [ 19 ]的用例 多媒体通信标准的虚拟化版本：IMS。• 第3章介绍了我们的第一篇文章，这是关于传统随后，我们描述了为虚拟网络提出的较新的故障管理技术，并将我们的论文工作与最新技术水平进行了比较第2章已• 在第4章中，我们提出了一个全面的故障管理平台，它代表了故障管理的各个阶段：故障检测、定位和修复，以及每个阶段使用的• 第5章描述了我们提出的虚拟网络自建模方案。所提出的模型是具有表示布尔变量的节点的逻辑依赖图。该建议已应用于第2章中介绍的vIMS用例。我们使用故障管理技术来验证、调整和扩展模型。提出了一种自建模算法，用于对当前网络拓扑进行建模。最后，我们提出了应用于自建模算法的性能测试• 第6章提出了一个主动故障诊断过程，验证了我们的自建模方法。该过程考虑由自建模算法生成的依赖图和初始观察（故障症状）以找到故障的主要原因。故障诊断程序引入了测试的概念，允许您在诊断过程中添加观察结果。为了验证诊断程序，我们将此程序应用于实际故障场景在下文中，我们将对论文的结果进行总结VI面对网络故障诊断是检测、定位和解决网络故障的过程。图1显示了不同的故障管理步骤和方法。故障诊断的第一阶段是检测系统是否处于故障状态。故障检测步骤确定系统是否在正常条件下运行或是否发生故障（或故障）。故障是可能导致系统进入错误状态的主要原因。当错误导致网络设备或软件出现故障，从而导致症状时，就会发生故障症状是故障的外部表现对于故障检测，收集两种类型的数据：度量和警报。指标是一种定量的方法，用于检查所需的能力和衡量退化。它们测量网络所有层的活动和操作状态。网络指标包括：抖动、吞吐量、网络利用率、延迟和数据包丢失。警报是故障的外部表现。这些通知可以来自故障定位（也称为故障隔离）是确定故障确切根本原因的过程。在故障定位的背景下，已经开发了许多这些方法提供了故障管理过程的自动化，并应用于故障预测、故障组件的定位或故障传播分析。它的大部分方法都是机器学习（ML）方法，能够从数据或模型中推断结果。这些方法可分为两大类：白盒和黑盒白盒，如贝叶斯网络，是一种基于模型的诊断方法。模型表示一组节点和依赖关系。节点表示网络组件、事件或故障。节点之间的依赖关系表示因果关系、逻辑关系或概率关系。白盒方法通过基于模型提供了对故障过程的更好解释而黑盒，如神经网络，是一种在数据集上学习模式的技术，而实际上并没有对所学习的内容进行解释。学习方法应用的一个例子VII二进制类输出。图1网络世界中的传统问题正面临着虚拟化带来的新挑战，尤其是在可靠性和可用性方面• 动态网络拓扑：5G将支持根据客户需求定制的实时服务部署。这种不断的重新配置使得网络拓扑的演变和网络上的实体的依赖性不可预测。管理系统必须实时考虑拓扑的变化，以识别故障组件并避免误报。• 缺乏网络可见性：将虚拟功能分布在多个站点上，可以更好地抵御服务中断。然而，这带来了一个新的管理问题，即：日志的分布或集中化。事实上，同一服务的日志可能分布在多个站点，这意味着缺乏可见性，并使故障诊断复杂化。因此，为了管理服务，需要网络的全局视图• 故障隔离：在多个客户端之间共享• 警报的增长、模糊性和不一致性：虚拟网络中服务数量的增加意味着需要管理更多的实体，警报数量也在增加这些警报由不同的代理（如Syslog）和VIII网络的不同层。此外，故障可能会跨层和站点传播，从而增加警报的数量 这些警报的来源不同站点和实体之间的差异会导致警报的模糊性和不一致性。在这种情况下，报警管理在我的论文工作中，我们选择了基于模型的方法。这种类型的方法提供了对诊断的更好的解释，但是遭受了一个主要的限制，即难以定义用于诊断的模型。前面提到的虚拟化挑战使该模型的推导变得复杂。实际上，定义的模型必须表示虚拟网络的不同层（物理、虚拟、应用和服务）。模型还必须表示最精细的粒度（例如，应用程序进程）。该模型还必须LUMEN：虚拟网络的故障管理平台为了应对与虚拟化相关的挑战，我们提供了LUMEN：一个全球性的故障管理平台[17]。LUMEN是一个四阶段架构，包括：源、汇、提取和决策。每一步都概述了必须部署的方法，以应对不同的虚拟化挑战，包括：图2显示了LUMEN的相位。源阶段和接收阶段表示数据（如日志或拓扑描述）的收集、过滤和存储部分。在此阶段，不同客户端的日志被集中起来，以解决缺乏网络可见性的问题。还为每个客户端标识这些日志，以便将其隔离。提取阶段允许根据决策方法的需要提取必要的数据。例如，仅检索指示网络故障的日志以用于诊断。LUMENLUMEN的主要贡献是准备和提取诊断方法所需的数据。例如，在警报收集部分IX图2自建模和主动诊断方法在通过LUMEN平台定义了故障管理步骤后，我们选择了一种白盒方法，该方法集成了故障原因跟踪机制，因为这些方法提供了更详细的故障解释，从而使我们尽管定义模型很困难，但我们做出这一选择的动机是，所获得的知识可以从网络描述文件、协议甚至专家那里检索。在我们的一篇论文[18]中，我们介绍了从虚拟网络中获取的不同类型的数据。D’un autre côté, les connaissances apprisesX中断，如连接链路断开和相关事件的收集。这一机制是由Netflix在ChaosMonkey项目中引入的，以测试其平台的弹性。在我们的例子中，这种机制被用来学习模型的依赖性。为了对虚拟网络进行建模，我们定义了一组"模板"。tem-pad定义了虚拟网络每一层中的网络组件tem-plate是一个有向无环图G=（V，E），其中V是表示布尔变量的节点集，E是逻辑链的集合 我们已经定义了一个节点和它的前一个节点之间的四种类型的逻辑链接：dv={AND，OR，A=⇒B，A=⇒B}，其中A和B是图的两个节点。所提出的建模方法基于面向对象编程的原理。在面向对象的范例中，模板可以被认为是"对象类"。然后，所使用的建模规则重新组合类的二元图。建模规则的目的是构建描述网络所有组件的布尔变量和逻辑依赖关系图。使用生成的图形表示模板的组合实例。具有相同性质的元件具有相同的模型，但具有该模型的不同实例。L’instanciation de cesL’algorithme d’auto-modélisation prend en considération les 模板的定义方式为这是一个有点通用的解决方案，它满足了虚拟电信网络的所有用例。这些定义包括这些用例之间的几个共同方面，例如虚拟网络功能的弹性原理和自我修复机制。然后，我们在Docker版本的Clearwater开源项目中将这种自建模方法应用Docker是一种比虚拟机更高效、更轻量级的虚拟化技术（系统开销更少我们使用错误注入程序原理并将实际部署中的故障传播与模型中的传播进行比较。图3显示了错误在真实部署中的传播与其在体系结构对应的依赖模型中的传播的示例。L’architecture这些组件是：Bono、Sprout、Homestead、Cassandre和ETCD。Bono是客户的第一联系人Sprout允许您路由它们1YAML是可用于网络描述和配置的数据表示格式。XI会话发起协议（SIP）2的消息。Homestead负责检索和存储客户信息，如客户密码，这些信息存储在Cassandra数据库中。最后，ETCD允许在Clearwater的功能之间共享配置信息。在此示例中，Docker Sprout复制了两次。为了在我们的示例中，Docker Bono1已停止，这意味着SIP请求中出现错误，代码为"408"，表示请求超时已除此错误外，Sprout11和Sprout12还报告了另一种类型该体系结构在YAML文件中进行了描述，通过将相同的错误注入到该依赖关系图中（C’est à然后将该模型用作过程的输入图3基于Microsoft Z3逻辑求解器的诊断程序[83]3。一旦通过第一次观察（或警报）检测到故障，主动诊断的步骤如下：1. 将当前拓扑建模为全局依赖图G。会话发起协议（SIP）是用于多媒体通信的3是Microsoft开发的SAT（布尔可满足性问题）求解器XII2. 从全局依赖图G中提取子图SG，该子图SG由观测的已知节点和具有F状态的节点的直接前置节点（父节点）组成。3. 然后将SG图转换为一组描述节点及其依赖关系的逻辑约束4. 然后将这些约束与观测值一起提供给求解器以获得解。所得到的解在解释故障的节点处包含最小数量的5. 如果节点处的这些F是可测试的，则它们随后通过测试。根据获得的值，将其分为三类：• 无辜：如果节点是可测试的并且正在工作（val（node）=V true）。• 可疑：如果节点不可测试，或可测试且其值未知。• 缺陷：如果节点是可测试的，并且其值为假。• 罪魁祸首：如果除了故障之外6. 在无辜和可疑的情况下，这些节点的值被添加到观察中。7. 在有缺陷的情况下，为了使这个节点成为主要原因，它必须8. 如果仍然找不到故障的主要原因L’administrateur peut changer实验结果为了测试为此，我们回到诊断过程从提取这些节点及其前置节点的SG由图4中所示的诊断算法提出的解决方案故障场景：停止Bono1、DcBono1S码头工人：XIII1. 解决方案：Appbono12. 以下解决方案和测试• Bono1应用程序测试• 测试Docker ETCD1的连接（val（DCE1C）=V rai）。• Docker Bono1的连接测试（val（DCbono1C）=F aux）。3. 结果：Docker Bono1（DCbono1C）连接可能是原因。继续？：是的。4. 以下解决方案和测试• Docker本地连接机制测试："网桥"（val（NB1）=V为真）。• 测试• 结果：继续？：不图4 - .诊断结果通过多次测试，XIV结论和展望电信网络的虚拟化提供了更动态和灵活的服务，同时降低了实施和维护成本。 此外，为了从虚拟化中获得更多好处，运营商与客户共享其未占用的然而，这种虚拟化模式带来了许多挑战，特别是在可靠性和可用性方面，例如：动态网络拓扑、网络组件的异构性、缺乏可见性、共享相同基础架构的不同客户端的故障隔离问题这些挑战影响了传统的故障管理方法和途径为了应对这些挑战，我们选择了一种基于模型的故障管理方法，该方法允许对故障进行解释，以便进行有针对性的自我修复。为此，我们日志的集中和过滤解决了客户端日志缺乏可见性和隔离的问题。然后，我们定义了应用于vIMS用例的虚拟网络自建模方法。然后，通过故障传播场景验证定义的模型，并在主动诊断过程中进行测试。诊断过程基于测试，以依赖关系图的形式提供结果，其中包含无辜、可疑和故障节点。建议的结果允许论文的结果开辟了几个可能的前景视角：自建模和诊断过程中的大多数步骤都是自动化的。但是，其他步骤也值得自动化或扩展，例如：• L’auto-apprentissage de "templates": l’extension des一个可能的前景是开发一种自学习算法，该算法能够推断学习到的依赖关系并校正或扩展这些"模板"。这些算法将故障注入场景应用于 在实际部署中和在定义的模型中。L’algorithme d’auto-apprentissagecomparera• 自动创建YAML文件：在我们的工作中，我们手动编写YAML文件，我们没有开发从不同 部 署 生 成 此 文 件 的 过 程 。 通 过 查 询 已 部 署 的 网 络 编 排 器 （ 如 OpenStack 或Docker），可以轻松完成此过程。XV• 测试自动化：为了提高所提出的诊断过程的效率，一个可能的前景是主动诊断过程执行必要的测试，而不询问网络管理员。为此，必须向主动诊断算法提供执行这些测试所需的测试命令行和有关网络组件的信息。例如，对于连接测试，除了这些观点之外，所提出的逻辑依赖图可以被扩展为概率图，以处理诊断过程的另一个可能的改进是在诊断开始后捕获拓扑变化。为此，自建模算法必须每次根据拓扑的变化来更新依赖图。 我们对自建模算法进行的一项研究除了在诊断过程中考虑拓扑变化之外，诊断过程还可以添加自我修复操作以推进其结果。最后，我们在Clearwter vIMS用例上证明了XVITABLE来自C组法文摘要IV图23列表表二十四列表模板列表XXV1论文引言11.1上下文11.2论文目标41.3论文方法和科学贡献41.4论文结果61.4.1出版物61.4.2概念验证72可编程虚拟网络82.1导言82.2网络虚拟化生态系统102.2.1软件定义的网络（SDN）2.2.1.1SDN和网络功能虚拟化（NFV）共存 .152.2.2多租户和切片162.2.3虚拟主机环境172.2.4NFV管理和编排（MANO）182.2.4.1虚拟基础架构管理器（VIM）202.2.4.2NFV网络212.2.4.3NFV故障和性能管理222.3虚拟网络功能（VNF）链：克利尔沃特vIMS242.3.1IP多媒体子系统（IMS）252.3.2克利尔沃特虚拟IP多媒体子系统（vIMS）2.4虚拟网络的功能和挑战2.4.1虚拟网络依赖性302.4.2物理和虚拟共存31XVII2.4.3网络拓扑的动态性312.5结论313关于全面故障管理调查的建议333.1导言333.2故障管理的传统方法概述343.2.1故障检测和观察收集（日志记录）343.2.1.1用于检测的数据挖掘353.2.2故障定位和识别373.3黑盒接近403.3.1基于规则和案例的推理403.3.2决策树433.3.3神经网络（NN）463.4白盒接近503.4.1因果关系/依赖关系图503.4.2约束图553.4.3贝叶斯网络613.4.4佩特里网663.5传统故障管理方法性713.6新的故障管理技术743.6.1自我建模743.6.2自我疗愈763.6.3故障注入803.6.4讨论813.7论文工作的定位824LUMEN：全球故障管理框架844.1导言844.2LUMEN全球故障管理框架4.2.1Lumen飞机864.3虚拟网络数据894.4LUMEN在vIMS用例90中的应用4.4.1DockerClearwatervIMS部署904.4.2交通一代904.4.3错误注入程序904.4.4日志收集和筛选924.5结论92内容表XVIII5自我塑造935.1导言935.2自我建模方法概述935.3建模规则推导945.4真实世界应用：克利尔沃特vIMS自建模1045.4.1ClearwatervIMS模板描述1055.5自建模算法1115.5.1上市登记服务1155.5.2拓扑的动态性1175.6vIMS型号118的验证5.6.1模板验证1205.6.2通过错误传播用例模型1225.7自建模算法的实验评估1245.7.1依赖图可伸缩性评估1245.7.2自建模算法性能1265.8总结和结论1286活动故障定位1296.1导言1296.2定义和符号1296.2.1全局依赖关系图和子图1296.2.2诊断引擎1316.3子图诊断1346.4主动诊断过程1366.5讨论1406.6实验结果1426.6.1具有相同症状的故障的诊断1436.6.2第147章6.6.3多个故障的诊断1486.6.4摘要1516.7与相关作品的1536.7.1与传统电信监控例程的定性比较1536.7.2与黑匣子方法的1536.7.3与基于模型的方法的定性比较1546.8结论1547结论和今后的工作156XIX7.1论文获得的结果1567.2前景1587.2.1自动化组成自建模和诊断过程的其他步骤1587.2.2概率依赖图1597.2.3动态诊断1607.2.4将自建模方法应用于其他用例160附录A161附录B164附录C170首字母缩略词列表171参考书目177XXISTF.伊古尔斯1故障管理的步骤和方法VII2LUMENIX平台3故障传播示例XI4. 诊断结果。..........................................................................................................十三2.1网络虚拟化生态系统[151][51]2.2网络功能虚拟化愿景[151][51]112.3网络功能虚拟化132.4SDN分层体系结构142.5NFV和SDN共存的示例。已启用VNF流量路由由SDN提供。 SDN虚拟交换机和控制器托管在虚拟主机中。152.6NFV软件即服务（SaaS）的多租户案例。 在情况1中，租户A和租户B具有不同的VNF，而在情况2中，它们共享相 同 的 VNF具有两个不同的切片162.7虚拟机、容器和uniker-nels上的VNF部署的简化视图。 容器对于托管VNF来说比单内核和虚拟机（VM）。.......................................................................................................182.8欧洲电信标准协会（ETSI）NFV架构框架-工作[34]。........................................... 192.9三个容器共享同一主机并通过网络通信工作桥"Docker0"，（b）：通过覆盖网络通信的两台主机。222.10 由ETSI组规范（GS）表示的NFV体系结构中的故障相关方案。该体系结构说明了四个局部故障相关器和三个外部故障相关器.....................................................。2.11 核心IMS架构252.12 清水vIMS体系结构[19] ........................................................................................................272.13 虚拟网络组件303.1故障管理流程333.2故障定位方法393.3黑盒与基于模型的机器学习（ML）方法3.4（a）基于规则[23]和（b）基于案例的推理[1]。................................................. 413.5玻璃开关报警使用案例42