odl基础翻译

最新推荐文章于 2023-11-20 13:22:56 发布

w1272145777

最新推荐文章于 2023-11-20 13:22:56 发布

阅读量1.3k

点赞数 2

分类专栏： odl 文章标签： odl

odl 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

内容
1.介绍… … … 5
1.1。大纲 … … … 6
2.软件定义网络… … … 8
2.1。SDN理论… … … 9
2.2。SDN定义… … … 11
2.3。OpenFlow … … … 11
2.4。分布式控制器… … … 12
3. OpenDayLight（ODL）… … … 14
3.1。建筑… … … 15
3.2。ODL的服务… … … 16
4.分布式系统… … … 18
4.1。集群计算系统… … 21
4.2。负载均衡 … … … 22
4.3。高可用性 … … … 22
5.筏，共识算法… … … 23
5.1。领导选举… … … 27
5.2。日志复制… … … 30
5.3。安全 … … … 32
5.3.1。选举限制… … 33
5.3.2。承诺以前的条款… … 34
5.4。摘要（筏）… … … 34
5.4.1。期刊复制… … … 35
5.4.2。快照复制… … 36
5.4.3。耐久性/恢复… … … 36
6.阿卡… … … 38
6.1。会员资格… … … 38
3
6.2。故障检测器… … … 39
6.3。种子节点… … … 39
6.4。会员生命周期… … … 40
6.5。加入种子节点… … … 41
6.6。离开… … … 42
6.7。节点角色… … … 43
6.8。持久性模块… … … 43
6.9。快照… … … 44
7.八卦协议… … … 45
8.在OpenDayLight中聚类… … … 48
8.1。这是如何构建的？… … … 49
8.2。数据同步… … … 51
8.3。沟通… … … 52
8.4。数据分布… … …
8.5。高可用性（HA）… … … 53
8.6。数据存储流程… … … 54
8.7。启动 … … … 54
9.群集的设置和测试… … … 56
9.1。测试… … … 61
10.对数分析… … … 63
11.控制器之间的消息… … 69
11.1。捕获… … … 69
11.1.1。Akka工具零件… … … 70
11.1.2。筏算法部分… … … 73
12.带宽使用分析… … … 78
12.1。实验方法… … 78
12.2。Mininet … … … 78
12.3。数据采集和处理… … 81
12.4。建模… … … 85
4
13.结论… … … 90
13.1。未来的工作 … … … 91
五
1.简介
在过去的十年中，世界目睹了互联网流量以非常快的速度增长，这是由于更多的因素，如更多的互联网用户，扩散
设备和连接，视频服务，移动动力和许多其他[1]。
这导致大型数据中心的增加，目的是处理所有这些信息。由于这些因素，计算复杂性和存储量大大增加，因此使网络复杂性更高。
为了应对这个难以处理的网络问题，运营商，研究人员和设备供应商等一系列组织聚集在一起，看到了创新的需要，这就是为什么在2011年成立的开放网络基金会（ONF）的目标是推广新网络提议，软件定义网络（SDN）。
SDN背后的基本思想是一种网络架构，其中控制平面与数据平面分离[2]，这种架构开辟了之前的可能性。这是因为通过SDN，可以使用可编程网络，网络管理员可以在其中定制网络以满足其需求。在SDN范例中，有一个称为控制器的中央软件程序，它处理整个网络的行为。成为网络的大脑，使网络设备变得简单转发设备。
这种管理网络的新方式导致需要与SDN控制器通信简单的转发设备，并且为此创建了称为OpenFlow的通信协议。
在SDN架构中，网络设备仅依赖于单个控制器，这给系统带来了单点故障的弱点。这个问题可以
通过部署SDN控制器集群来解决这个问题，这将使系统在可扩展性，高可用性和信息持久性方面得到改进。本论文的主要目标是部署和分析不同方面
内部执行，控制器之间交换的消息，以及OpenDayLight控制器集群的带宽使用情况。为此创建了一个具有三个控制器实例的集群，随后它连接了一个Mininet网络，其中拓扑大小发生了变化。其中一个目标还是提供具有高可用性（HA）的集群，为此目的，集群中的两个节点在发生故障时充当冗余。在OpenDayLight中，它们充当关注者，而另一个节点充当群集的领导者。领导者是负责与所有网络设备通信的人，如果失败，系统将选择新的领导者。网络设备将被传递出来进行控制。为了维护集群中的信息持久性和HA，必须持续交换控制器间流量，以保持其他节点的更新。然后利用这些信息建立一个模型来预测带宽使用（Mbps）与拓扑变化的关系。
1.1。大纲
此报告按以下方式组织：第2章包含有关软件定义网络的一些背景知识。第3章简要介绍了OpenDayLight控制器。第4章介绍了分布式系统的工作原理。第5章解释了Raft（共识算法）是如何工作的，以及为什么对于集群的部署如此重要。第6章描述了Akka，这是发现部分中使用的工具。第7章解释了八卦协议。第8章介绍了ODL中的集群体系结构。第9章介绍了群集的配置，以及如何检查群集是否正常运行。第10章介绍了系统的日志。第11章显示了用于ODL的不同消息。第12章包含带宽使用的模型。第13章总结了论文，并讨论了未来的工作。
2.软件定义网络
SDN网络背后的想法是从网络硬件中提取智能，这在其他技术领域已经完成。现在正在使用与1999年相同的路由器，交换机，路由协议，它们更快，具有更大的背板，更高的吞吐量，Qos以及更多的东西。但情报基本相同。这些年来，网络设备保持不变。在SDN中，网络设备变得笨拙。允许创建管理系统，以通过控制网络架构使整个系统更加智能化。以前只是管道大小的问题，换句话说就是速度（例如，将物品从一个点A运输到B点需要多长时间）。随着实时通信等新应用的到来（YouTube，skype，VoIP）真正重要的是延迟或抖动。现在存在实时通信的问题，其中使用Qos来对包进行某种优先级排序。例如，使数据包VoIP比FTP更重要，因此首先通过网络发送它。在过去，人们常说FTP流量的优先级低于SIP流量。现在有更多的设备连接到网络，在某些情况下，FTP流量可能比SIP流量更重要。今天可用于管理Qos的系统的问题在于它无法动态配置此信息，这必须是静态编程的。SDN是否可以发挥非常重要的作用，可以根据需要动态建模和塑造流量，
为什么要塑造实时流量？
无论何时配置网络，都将受其自身限制的约束。大多数情况下，应用程序使用分配的整个带宽，有时仅使用部分带宽。但是在某些情况下，另一个应用程序需要使用未用于其他应用程序的带宽，不幸的是它无法使用。这是一个明显的例子，说明如果有一个基础设施可以实时确定流量的优先级，那将是多么有趣。例如，在一个1 Mb的管道中，默认情况下为所有服务划分管道，最好根据即时需求动态修改它。
2.1。SDN理论
根据[3]，传统的IP网络很复杂，很难管理。根据预定义的策略配置网络很困难，并重新配置它以响应故障，负载和变化。更重要的是，当前的网络也是垂直整合的：控制和数据平面捆绑在一起。软件定义网络（SDN）是一种新兴的范例，它承诺通过打破垂直整合，将网络的控制逻辑（控制平面）与底层路由器和交换机（数据平面）分离来改变这种状况，如图2-1所示。促进网络控制的逻辑集中化，并引入网络编程能力。随着控制平面和数据平面的这种分离，所有的网络设备都变得笨重，它们开始只是转发设备。控制平面现在在集中控制器中实现。

数据平面：是允许包从A点到达点b的所有交换机和路由器（转发设备）所在的位置。
控制平面：驻留一组管理服务器，与所有转发设备通信，并说明数据应如何在平面数据中移动。这可以随时间动态更改，允许从单个点控制整个网络。
这是通过分离网络基础设施的不同组件来完成的，因此能够单独处理它们。

图2-1 - SDN架构[3]
既然控制平面和数据平面是分开的，那么它们需要一种新的通信形式。在SDN中有一种称为OpenFlow的东西，它是用于控制所有网络设备的协议。
SDN网络的主要特征是：
1）控制平面和数据平面解耦。
2）转发决策是基于流的[3]，流是指从一个点到另一个点的数据包序列。
3）现在控制平面和数据平面分离，然后逻辑控制移动到外部实体，在SDN中，这个外部实体称为SDN控制器。
4）SDN网络通过应用程序高度可编程，这些应用程序运行在控制平面之上。
所有上述内容都使SDN架构变得灵活，集中管理，直接可编程和可扩展[4]。

2.2。SDN定义
为了使读者能够进行语境化，将解释SDN术语。
1）转发设备（FD）：负责实现为控制器提供的所有流规则的交换机和路由器。它们通过南向接口连接到控制器，这是通过使用OpenFlow协议完成的。
2）数据平面（DP）：所有转发设备所在的位置。
3）控制平面（CP）：是网络的大脑，它与南向接口的数据平面连接，与北向接口的应用程序连接。
4）南向接口（SI）：控制器与转发设备通信的方式，使用的协议是OpenFlow。
5）北向接口（NI）：SDN架构提供了一种对控制器进行编程和修改控制器内部事物的方法，这是通过使用该接口完成的。

2.3。OpenFlow
这是一个为开放网络基金会（ONF）管理的通信标准接口，用于控制平面和SDN网络中的数据平面[2]，基本上允许配置转发设备，如交换机和路由器。
该协议消除了静态网络架构的问题[5]。使用OpenFlow可以创建可以在整个网络中传播的单个网络控制策略，允许中央控制器远程管理数据平面的所有转发设备中的转发信息。这是一种惊人的方法，因为这使网络更加自动化，消除了逐个手动配置所有设备和接口的问题。
另一个优点是它不会因供应商而异，从而使这一过程更加容易。

2.4。分布式控制器
在SDN网络中也可以使用分布式控制器架构，将控制分配给一组控制器的事实使系统能够具有多个故障点[6]。不像以前那样系统有单点故障。
实现如图2-2所示。
图2-2 - 分布式控制器[6]
让多个控制器同时运行并协同工作还可以使网络提高其可扩展性，持久性，共享工作负载以及在高可用性模式下工作。
控制器必须交换一些控制信息才能以分布式方式工作，这种流量通常称为东西向流量。在此流量中包括有关拓扑网络，库存和一些其他控制平面参数的信息。
3. OpenDayLight（ODL）
OpenDayLight是一个为Linux Foundation托管的协作开源项目，它成立于2013年4月，但第一个版本是在2014年2月。
它的创建旨在减少已知的“供应商锁定”，因此支持更多协议而不仅仅是OpenFlow。OpenDayLight的目标是提供一个允许拥有可编程网络的集中管理系统。
这可以通过使用API框架来实现。OpenDayLight是一个模块化的开放式SDN平台，适用于任何规模和规模的网络，可在多供应商环境中的各种硬件上实现网络服务。
微服务架构允许用户控制应用程序，协议和插件，以及提供外部消费者和提供者之间的连接[7]。
在今天，所有网络都必须手动修改，以适应当前的需求和工作量。为此，在SDN网络中，OpenDayLight控制器可用作配置网络不同方面和解决不同网络挑战的平台。
ODL使用开源集成标准和API，使网络更具可编程性，智能性和适应性。控制器非常适合需求，这使得能够结合多种服务和协议来解决不同的问题。
ODL是开源的这一事实是其快速发展的关键，使得世界各地的许多程序员可以为该管理系统开发软件做出贡献[8]。

3.1。架构
OpenDayLight控制器有3个不同的层，分为：顶层，中层和底层，如图3-1所示。
图3-1 - OpenDayLight架构[8]
在ODL架构中包括一些组件作为完全可插拔的控制器[9]，接口，协议插件和应用程序。对于正在用于本论文的版本的氦释放，将解释三层ODL。
顶层 - 北向接口：在此层中，北向接口提供控制器服务和公共REST API。这有助于管理网络基础结构配置。
中间层 - 控制器平台：在此层中，控制器借助南向插件与底层网络基础架构通信。它负责提供基本的网络服务，包括拓扑管理器和交换机管理器。
底层 - 南向界面：在该层中，所有用于管理和控制底层网络基础结构的协议都驻留在该层中。
它有不同的插件，也可以实现与硬件直接通信的各种网络协议。这是OpenFlow协议所在的位置。
3.2。ODL中的服务：
拓扑管理器:负责存储和处理有关网络设备的所有信息。它包含拓扑详细信息作为交换机和链接。
统计管理器：负责收集所有统计信息，这可以通过向节点发送统计请求并存储响应来完成。统计管理器还与北向API通信，以提供有关节点，流，表和组统计信息的信息。
Switch Manager：提供有关交换机和端口的信息。它还可以与北向API通信以提供信息。
库存管理器：保证库存数据库始终可以更新。它查询和更新有关OpenDayLight管理的交换机和端口的信息。
4.分布式系统
是什么？
在传统计算中，一切只在一台机器上执行，如图4-1所示，无论是计算机，移动电话还是其他任何计算设备都无关紧要。
该过程很简单：向计算设备提供输入以便处理它，并最终获得所需的输出。事实是，在今天这实际上已经足够了，但是在非常大规模的项目中，例如，在进行3D图形，视频渲染或实际上甚至更大规模的项目时，例如，如果研究人员试图纠正一个复杂的科学问题。
在这种情况下，单个计算机的处理能力可能不够。
图4-1 - 单个系统
单个计算机可能太慢而无法解决大问题，这就是分布式计算的问题，这个想法非常简单。
这是一项庞大的复杂任务，它被切成小块，将工作量分配到大量计算机上，这样每台计算机只需要在一个小工作中工作。所有计算机都应该统一工作，因此可以在比上次计算更少的时间内获得解决方案。
把这个想法带到论文的主要工作中，其中有非常大规模的服务，而这些服务正在收到试图访问它们的人的大量请求。什么时候出现一个大问题。
如果只想用一台机器同时为这么多人提供服务，那基本上是不可能的。它不能构建一个可以同时为任何人服务的计算机。
我们的想法是在互连的计算机上分配负载（请求数），这些计算机相互通信并一起运行应用程序，如图4-2所示。
因此，网络上的计算机相互连接，它们正在处理负载的不同部分。这种方式可以在系统获得更多请求时进行扩展，只需将更多计算机添加到分布式系统即可。这种方法的另一个巨大优势是，例如，当其中一个节点出现故障时，另一个节点将承担该节点的工作负载。
它允许扩大规模，是可靠的，这是一种有意义且可行的方法。
图4-2 - 分布式系统
分布式系统最适合的任务是可并行化的任务，它可能需要大量复杂的操作，但许多这些操作可以相互独立地进行。
这意味着每个任务都是分布式的，并且由于一个任务不依赖于另一个不同任务的结果，因此所有任务可以同时完成，而不必考虑其他任务。
这样做的方式很简单，基本上有一台主机和一组计算机可以帮助分布式系统。主机是设置任务的位置，运行主程序的位置，该计算机的任务是定义所有小作业，并将它们分发给其余的计算机。
然后每台计算机处理这些小任务，并发回处理结果。主计算机从各个任务中获取所有结果，然后将它们全部放在一起以生成最终结果。在该项目中，主要关注的是集群计算系统架构。
4.1。集群计算系统
在这种体系结构中，有一组计算机（也称为节点）通过网络链接在一起[10]，这使计算机能够协调其活动并共享系统资源。
用户通常将此体系结构视为单个系统。由于其可扩展性和容错特性，该系统非常有效。他们可以轻松分配更多用户或更快地响应请求，只需添加更多节点即可处理额外负载。
它们还避免了单点故障的问题，这是通过添加良好的恢复和冗余系统来实现的。
集群计算的另一个特征是透明度[11]，用户不知道何时出现故障，或者是否存在复制过程或者实际运行的是哪个进程。群集机制允许将两个或多个进程作为唯一实体一起工作。
在OpenDayLight中，可以将控制器的多个实例作为一个实体一起工作。
优点：
扩展：如果网络中运行的控制器不止一个，它将能够工作更多并处理更多数据。也可以将数据分布在集群中，这称为分片，可以在群集的每个控制器上具有不同的分片。
高可用性：如果其中一个控制器发生故障，则可以继续运行网络并使其可用。
数据持久性：当控制器崩溃时，它不会丢失数据。
有许多用途和配置，具体取决于所需的群集类型。他们可以从Web服务转向科学计算。
4.2。负载均衡
在此配置中，所有节点共享集群的工作负载，这意味着如果存在给定服务并且它正在接收来自许多用户的请求，那么它可以完全共享所有节点的所有负载量。
此配置将提供更好的网络性能。如果节点出现故障，集群将所有负载从该节点重定向到其他节点。这样，整个响应时间将得到优化。
4.3。高可用性
它们也称为HA集群，主要思想是创建冗余网络以提高集群方法的可用性。执行此操作是为了在系统组件发生故障时保证服务，从而为网络提供多个故障点。在这项工作中，这是将要使用的工作。
5. Raft，一致性算法
Raft是一种用于管理复制日志的一致性算法[12]。在开始解释算法之前，有必要定义什么是共识？
共识是一种算法，它允许一组节点或服务器一起工作，作为一个能够处理其某些节点故障的独特连贯系统。这可以通过复制领导者的状态机来完成。每个节点都有自己的状态机副本，但整个系统的错觉是只有一个相干状态机，如图5-1所示，即使某些节点已关闭。
状态机的分布可用于解决单一领导者的大规模系统中的不同问题。典型的共识集群可以自动从服务器故障中恢复，有2个故障情况，它们是以下情况。

只有少数服务器出现故障。在这种情况下，群集可以继续以相同的方式运行而不会出现任何问题
大多数服务器都会出现故障。在这种情况下，在新的大多数服务器再次运行之前，群集将不再可用，但即使没有可用性，群集也会保持信息的一致性。
通过使用复制日志执行复制，每个节点都有自己的日志，但它们必须与其他节点的日志相同，即使是相同的顺序。
图5-1 - 复制状态机体系结构。[12]
来自客户端的所有命令都在其他节点中复制，一旦为节点复制和处理这些命令，则领导者可以向客户端发送答案。
因此，节点似乎是单个状态机。所有共识算法都具有以下特征：
安全性是共识的一个重要特征，这是因为系统永远不会给客户端提供错误的答案，即使在延迟或丢包的情况下也是如此。
当大多数节点处于活动状态时，始终保证可用性。这意味着如果存在7个节点的集群，则系统可以处理3个节点的故障而不会丢失可用性。
不依赖于时间，确保在时钟失败的情况下日志的一致性首先通过选举系统的领导者来实现共识，在选举之后领导者获得管理复制日志的所有责任。
过程如下，领导者从客户端接收日志条目，然后将它们复制到其他节点。当大多数接收并确认来自领导者的日志条目时，它通知所有节点将这些日志条目应用于其状态机或“提交事务”。
如果领导人因任何原因失败，就必须有新的选举。使用共识模块来确保正确的日志复制。如前所述，只要大多数服务器停机，系统就不会取得任何进展。
筏算法分为三个部分：领导选举，日志复制和安全。
将以相同的顺序描述算法的每个部分。在领导者选举中，我们的想法是选择其中一个服务器作为集群领导者，如果该服务器出现故障，则必须选择新的选举。
在日志复制中，leader任务是从客户端获取命令，将这些命令附加到其日志中，然后将其日志复制到其他节点，以使其日志与其他服务器中的日志匹配。这样做是为了覆盖不一致。
在安全方面，我们的想法是为领导人选举过程增加限制，所以只有具有更新日志的服务器才能成为领导者。在集群架构中，典型的节点数为5，这使系统可以处理多达2个故障。
Raft为集群的节点实现3种不同的状态，它们是leader，candidate和follower，如图5-2所示。
当一个节点启动时，它总是从被动状态开始，这是一个被动状态，这意味着它不会发出任何请求，它只响应来自领导者和候选者的请求。领导者处理来自客户的所有请求，如果客户与跟随者联系，则必须将其重定向到领导者。
候选国是选举新领导人的州。
图5-2 - 服务器状态。[12]
Raft的另一个特点是它将时间划分为任意持续时间的术语，这些术语以连续的方式枚举，如图5-3所示。
图5-3 - 时间划分[12]
一个术语总是从选举过程开始，其中候选状态中的一个或多个节点试图成为领导者。当其中一名候选人赢得选举并成为领导者时，该任期将保留，直到领导人失败为止。
还有一些情况，在一个学期内没有任何领导人选举，这可能是由于分裂投票的情况造成的。当这种情况发生时，这个词将在没有任何领导者的情况下结束，然后一个新的术语开始以便进行新的选举。
这确保了只有一个节点才能成为给定术语中的领导者。术语值在Raft中起着重要作用，它用于节点以便检测过时的信息。该术语在节点之间的任何通信中交换，我们的想法是，当给定节点收到更大的术语时，它会将其术语值更新为为另一个节点发送的术语值。
当发生这种情况时，节点立即回到跟随者状态。该术语的另一个重要部分是当有选举过程时，因为当节点从具有较小术语的节点接收投票请求时，它将拒绝它。Raft中有两个不同的消息，一个是“请求投票”，另一个是“附加条目”，它们都是RPC消息。“请求投票”用于候选节点以便从其他节点获得投票，并且“追加条目”用于领导者以便复制日志条目。当“附加条目”消息为空时，它被称为“心跳”消息。
5.1。领导者选举当节点启动时，它们以跟随者状态开始。只要他们没有收到领导者或候选人的任何信息，他们就会留在该州。如果他们在一段称为“选举超时”的时间内没有收到任何消息，如图5-4所示，那么他们会将状态改为候选人，假设当前没有领导者。
图5-4 - 选举超时[13]如前所述，如果处于跟随状态的节点想要开始新选举，则在超时之后，它必须增加该术语并将其状态更改为候选。当选举过程开始时，候选节点总是为自己投票并发送“请求投票”消息以尝试从其他成员获得投票，如图5-5所示。
图5-5 - 投票请求[13]
候选节点保持该状态，直到：
1获得大多数选票并成为集群的领导者。当一个候选人赢得选举是因为它获得了大多数选票，这是按照先到先得的基本原则完成的，如[12]中所述。这确保了只有一个节点可以成为给定术语中的领导者。当它成为领导者时，它开始向其他节点发送“心跳”，以告知有领导者并阻止新的选举。
2另一个节点通过发送“心跳”消息成为领导者。如果候选节点在等待投票时收到“心跳”或“附加条目”消息，则它将返回到跟随者状态，因为群集中仍然存在领导者。
3没有人获得领导权，必须开始新的任期。在多个节点同时将其状态改变为候选者的情况下，它可能最终处于分裂投票的情况下。如果发生这种情况，候选人将在下一学期开始新的选举。图5-6显示了节点如何为候选人投票。
图5-6 - 授予的票数[13]
在上面提到的第三种情况下，可能是无限期分裂投票的情况，这就是为什么Raft使用额外的措施来防止这种情况。它使用随机选举超时来解决这个问题。
它们通常在150-300毫秒之间，这样在给定的期限内只有一台服务器会超时。它还将发送“Heartbeats”并在另一个节点超时之前收到确认。
5.2。日志复制选举领导者后，它可以开始为客户提供服务。那些客户端发出包含要附加到领导者日志的命令的请求，并行地，它还向其他节点发送“附加条目”以执行复制。当该条目被安全复制到大多数时，领导者最终可以将其应用于其状态机。这个过程也称为“承诺过程”，这意味着给定的命令已被复制并应用于状态机，现在是安全的。该条目是持久的，永远不会被覆盖.Raft组织日志的方式如下，每个日志条目有一个命令以及一个术语编号，表示领导者何时收到该条目。术语编号非常重要，因为系统检测到日志中的不一致。每个日志条目也有一个整数索引，以便识别它日志中的位置如图5-7所示。
图5-7 - 日志条目[12]
Raft的另一个属性是：日志条目永远不会更改它们在日志中的位置，以便具有一致性，并且还执行一致性检查。这是通过使用“附加条目”消息完成的。
在消息中包括新条目之前的条目的术语和日志索引。该信息用于跟随节点。如果关注者没有找到具有该术语和日志索引的任何条目，则它将删除新条目。但是，如果关注者找到具有该术语和日志索引的条目，则意味着领导者日志和跟随者日志完全相同。它将向领导者返回成功的“附加条目”消息。当系统正常运行时，一致性检查总是返回成功操作，这意味着领导者和追随者的日志保持一致。如果系统运行不一致，它可能处于领导者或追随者崩溃的情况下，这会导致日志不一致。日志不一致意味着关注者的日志可能与领导者的日志不同，它可能以不同的方式。有额外的条目或缺少条目，这些不一致性通过用来自领导者的条目覆盖冲突的条目来解决，这是一种安全的方法，但必须通过一些限制来完成，这些限制将在安全部分中解释。过程如下：领导者必须弄清楚哪个是其日志和跟随者日志之间匹配的最后一个条目，以便在跟随者节点中删除该点之后的其他条目，然后发送所有条目从领导者日志那一点。在正常条件下运行，在一轮消息中将新条目复制到大多数节点。5.3。安全性在描述了Raft如何执行领导者选举以及如何复制日志之后，还需要讨论一些机制来确保所有状态机在所有节点中都是相同的。例如，当一个领导者提交日志条目而其中一个节点不可用时，并且在某个时间之后，该节点被选为领导者。它开始用新条目覆盖为前一个领导者提交的条目。在上述情况下，它可能导致一致性松散，并且必须应用一些限制以确保任何给定术语的领导者包含先前术语中提交的所有条目。
5.3.1。Raft中的选举限制以前术语中的所有已提交条目必须在其选举时出现在新领导者中，这意味着不需要将任何条目转移到领导者，这遵循日志条目仅来自追随者的领导者，反之亦然。领导者永远不会覆盖已存在于其日志中的日志条目。在投票过程中，Raft阻止候选人没有先前提交的条目成为领导者的方式。当候选节点与系统中的其他节点联系以进行请求投票时，该消息包括关于候选日志的信息。这用于节点以确定哪个日志条目更新，哪个是领导者或其自己的日志条目。如果关注者有一个关于领导者日志的更新日志，它将拒绝投票，如果日志更新，那么它将确认投票。使用此过程可以确保所选的领导者具有先前条款中提交的所有日志条目。
5.3.2。从先前条款中提交条目一旦将条目复制到大多数，则表示提交条目。当一个节点正在执行其复制任务时，它会在它可以提交给定条目之前崩溃。该条目不会被未来领导人覆盖。未来的领导者将尝试完成复制条目，但不幸的是，新领导者无法知道是否已提交之前条款的条目。为了解决这个问题，Raft从不提交以前术语的日志条目。只能提交从当前领导者复制的条目，这是一种确保先前条目也被提交的方法。
5.4。摘要（Raft）在碎片启动时的选举中，它以跟随者的身份开始，因为它不知道系统中的任何其他内容。在那之后它等待一段时间的心跳，如果它在那个时间段内没有从领导者那里得到任何心跳，那么它就成为候选人并开始发送投票请求。在那之后，它等待投票，当然它投票支持自己，如果得到大多数选票，它将成为领导者。一旦它成为领导者，它就有权将数据复制到其他节点，它通过发送“附加条目”消息来实现。当这些消息没有任何有效负载作为复制数据的方式时，这些消息也可以充当“心跳”，这就是复制的工作方式。如果有一个领导者和两个粉丝，则以下列方式达成共识。有必要能够复制到至少一个关注者，并看到它的确认说数据已被存储。然后领导者最终可以提交它并将其放入数据树中，如果领导者没有得到任何响应，它就无法将其放入数据树中并且该信息保留在日志中。
5.4.1。日志复制当集群上有事务进程并且它被复制时，领导节点需要知道大多数节点是否获得了事务，然后领导者才能确认它并将其放入数据树中，如图所示图5-8。当大多数节点关闭时，群集无法容忍提交事务，在这种情况下，它将包含所有事务，它们将存储在日志中，但它们永远不会应用于数据树。图5-8 - 期刊复制[14]
5.4.2。快照复制通常，当群集启动节点时，将该条目逐个发送到该节点以完成复制并不是非常有效，因为这将花费太多时间。因此，当节点重新启动而不是发送“附加条目”时，它只是发送快照，如图5-9所示。因此，整个数据树被发送，除此之外，它还以较小的块分解数据树以执行复制，因为通常这个数据树可能非常大。这些块的大小通常固定为2 Mb。图5-9 - 快照复制[14]
5.4.3。持久性/恢复耐久性在恢复过程中很有用，在图5-10中有两个组件：第一个是存储在内存中的数据树，但也有持久的日志，其原因是重启，节点必须从持久性中恢复。例如，如果存在配置数据并且在配置中添加了一堆流，那么当控制器重新启动时，希望看到那里的所有流，因为否则它将无法重新配置所有交换机以同样的方式。因此，期刊基本上是所有修改，并且一个接一个地存储在期刊中，使用快照是因为恢复速度非常快。例如，当期刊中有数千个流，等待很长时间从磁盘读取每个流然后将其添加到数据树中并不是那么好。最好将所有数据树放入一个磁盘文件的快照中，它将立即读取所有数据树并从中构建数据树。
图5-10 - 持久性/恢复[14]

Akka
根据其规范，Akka Cluster提供容错的分散式基于对等的集群成员资格服务，没有单点故障或单点瓶颈。它使用八卦协议和自动故障检测器[15]。
在深入了解Akka之前解释一些定义很重要[16]。

节点：集群的逻辑成员。
集群：通过服务连接在一起的一组成员节点。
领导者：群集中的单个节点充当主节点。当节点是领导者时，它具有对交换机的完全访问权限。
6.1。成员资格集群由一组逻辑节点组成，每个节点都标识其主机名，端口和系统给出的标识号UID，目的是区分所有成员并提供更好的连接和死亡控制处理。通过向系统中的一个种子节点发送“加入消息”来启动成员资格过程，成员之间的这种通信是通过使用八卦协议来执行的。群集的当前状态以随机方式闲置到群集中的成员，优先考虑没有看到更新版本的状态的成员。
6.2。故障检测器故障检测器负责检测集群内不可到达的节点。它的行为方式如下：这个想法是保持故障统计的历史。这是根据从其他节点接收的心跳计算出来的，考虑到这一点，创建了一个阈值来计算将节点声明为无法访问所需的故障数量，该变量称为phi accrual故障检测器，并且可以由用户配置。这对系统来说是一件很重要的事情，因为它具有很高的阈值，可能会导致错误很少的情况，但需要更多的时间来检测真正的崩溃，相反，如果阈值较低，可能会产生更多的错误，但它会提供最快的检测速度。此变量的默认值为8次失败，适用于大多数情况。在集群体系结构中，节点通常由少数其他节点监视，它取决于群集大小，但通常最大数量是监视单个节点的5个节点。因此，当给定节点检测到另一个节点无法访问时，它将使用八卦协议将该信息发送到其余节点，这就是为什么只有一个节点需要将节点标记为无法访问以使其余节点标记为节点也无法访问。故障检测器的另一个功能是检测何时无法访问的节点再次可达，这再次通过八卦轮来完成。
6.3。种子节点种子节点负责作为加入群集的所有新节点的联系点，其地址和主机名必须存储在愿意加入群集的所有节点中。当新节点尝试加入集群时，首先要做的是联系种子节点，之后，它必须向首先应答的种子节点发送连接命令。可以在集群中配置许多种子节点，但只有一个种子节点，集群可以很好地工作。种子节点对群集性能没有任何影响，它们仅充当新节点的联系点。
6.4。成员生命周期在图6-1中显示了成员生命周期。节点启动时，它始终以加入状态启动。这种情况发生在所有节点都知道有新节点之前，这是通过八卦收敛完成的。一旦达到收敛，领导者就会将新节点的状态更改为up。在节点以正确的方式离开集群的情况下，领导者将该节点的状态改变为离开状态，然后当系统实现收敛时，它会将节点移动到现有状态，然后将其标记为已删除。在无法访问的节点的情况下，系统将无法实现收敛，因此将无法向前移动。在这种情况下，领导者等待该节点再次可达或者明确地将其标记为关闭。图6-1 - 成员生命周期[16]成员国如下：加入，关闭，离开，退出，关闭和删除。领导者和用户也有一些行动。 - 用户操作：加入，离开和关闭。 - 领导者行动：加入和退出。
6.5。加入种子节点在集群体系结构中，必须配置初始接触点，这样做的目的是为将尝试加入集群的所有节点自动加入。这些接触点也称为种子节点。这个想法是当节点启动时。它必须去配置文件中读取种子节点列表，这样做是为了获取种子节点的所有地址并尝试联系它们。当“连接节点”从任何种子节点获得答案时，它必须向首先回复的连接命令发送连接命令，以这种方式启动加入过程。如果没有人应答，节点必须继续联系种子节点，直到它得到答案或直到它关闭。种子节点可以按任何顺序启动，但唯一的条件是种子节点列表中的第一个节点必须是第一个在集群中启动的节点。否则，它将无法初始化其他种子节点。这样做的原因是为了避免在集群中创建分离的岛屿。对必须启动的种子节点数没有任何限制，但至少需要2个种子节点来启动集群。一旦有超过2个种子节点运行，就可以关闭种子节点列表中的第一个节点。当形成集群时，新节点可以尝试将集群加入任何成员节点。即使该节点不是种子节点。种子节点列表中的第一个节点将在其不能与任何其他种子节点
6.6联系的情况下加入自身。离开Akka只有两种方法可以从系统中删除成员。第一个是停止节点，然后等待其他节点检测到节点无法访问，之后领导者将其标记为已删除。第二个是通知系统给定节点必须离开。
6.7。节点角色在分布式系统中，所有节点都有不同的角色，这意味着工作负载可以以任何方式分发给系统的每个成员。例如，一个节点可以负责数据存储，另一个节点和另一个库存。但是也有可能通过冗余为所有成员赋予相同的角色，这可以通过复制成员之间的所有职责来完成，以获得系统中的可用性。角色在配置文件中定义。6.8。持久性模块Akka的持久性模块允许节点保持其内部状态，这样做是为了在崩溃后启动或重新启动节点时允许恢复。实际上，只保存对内部状态的更改，因此更改将保持不变，但永远不会保持当前状态（除非还实现了快照）。这些更改保存在内存中，但它们永远不会发生变异，这样可以实现最高的事务率和更高效的复制。所有持久的更改都会保存到日志中，以便稍后重播，以便从所有消息中恢复内部状态。当节点需要恢复时，它必须重放所有存储的更改才能重建内部状态。它可以从零开始重建内部状态，也可以从快照开始，这将使进程最快，从而缩短恢复时间。默认情况下，节点会在启动或重新启动时自动恢复，这样做会回复日志中的所有消息。如果在恢复阶段期间将新消息发送到节点，则它们不会干扰重放过程。它们存储在缓存中，当恢复阶段结束时，它们将被处理。6.9。快照通过使用快照，系统可以显着缩短恢复时间。系统保存了内部状态的快照，以便以后在恢复期间使用它。当节点即将启动或重新启动时，将提供此快照，以初始化内部状态。如果系统中有多个快照，则它将采用最新版本。

Gossip协议Akka使用一种版本的八卦呼叫推拉[16]，
这是为了减少集群中发送的信息。这意味着它只发送当前版本而不发送实际信息。在对八卦消息的回答中，节点发送另一个值，该值表示该节点是否具有更新版本或更新版本。这是在版本控制的矢量时钟的帮助下完成的，只能根据需要提取信息。每个节点都有所有其他节点的存储桶或版本信息，如图7-1所示。例如，在具有3个成员的集群中，成员1具有成员2和3的信息。通过这种方式，当成员与另一个节点进行八卦时，可以说它是否具有相对于其他节点的旧版本或更新版本。八卦机制以下列方式工作，每秒所有成员彼此发送状态消息，说明他们知道哪个版本的桶。然后，基于该信息，节点可以决定在其版本较低或者发送更新时发回其状态。每次更改存储桶中的内容时，也会更改存储桶的版本。
图7-1 - Gossip协议[14]消息通常每1秒交换一次，并且下一步发送消息的决定是随机的，但是那些没有看过最后一个版本的节点仍有一些优先权。另一个需要解释的概念是八卦融合的概念。当集群成员可以确定地证明已经观察到集群的所有其他成员观察到的集群状态时，可以讨论收敛。这个信息可以从一个节点传递到另一个节点，每次节点收到一个八卦消息，它会读取哪些成员已经看到了集群状态，并且在发送新的八卦消息之前它也会标记它。为了获得八卦融合，有必要让所有节点都可用，当节点不可达时，不可能实现收敛。当群集处于收敛状态时，系统仅发送仅包含八卦版本的小八卦消息。但是当群集发生变化并且没有收敛时，系统会返回。Gossip协议还利用数据结构的算法，这称为向量时钟，它对事件进行部分排序并检测分布式系统中的违规。Gossip使用向量时钟，以便在存在闲聊交换时记录群集状态的差异。向量时钟是一对（节点，计数器）对，因此每次集群状态改变时，矢量时钟也必须更新。向量时钟用于确定以下内容：

如果发件人有更新的版本，在这种情况下，它会发回一条消息以请求新版本。
如果发件人的版本过时，则收件人会发回其八卦状态。 - 如果存在冲突的八卦版本，则在这种情况下将这些版本合并并发回。

OpenDayLight中的集群
从体系结构开始本质上在集群实现中实现了2个子系统：

数据存储Data Store实现背后的理念是它允许高可用性和可伸缩性，所有成员都在与每个子系统进行通信其他分布数据如图8-1所示。
图8-1 - 数据存储[14]
Rpc如果存在路由器RPC且它正在尝试在节点中注册，则从RestConf或集群中的任何节点调用RPC，无论从何处调用。
图8-2 - RPC [14]
8.1。这是如何构建的？在高级架构中，分布式数据存储和RPC连接器都具有或多或少相同的基础，所有内容都是基于Akka actor构建的，如图8-3所示。
这是一种确保这些组件可以驻留在集群中的任何节点上的方法，可以在任何地方运行actor，并且可以从集群中的任何节点调用这些actor或向这些actor发送消息，而无需构建智能确切地说是演员驻留。
图8-3 - Akka Actors [14]
Akka持久性模块，提供了存储数据的能力，在重新启动的情况下，节点获取数据并重建树的状态，它有两个不同的东西：
Journal，本质上是一个文件，包含您在数据树中所做的所有修改。
快照，是存储树的整个状态的地方。Akka远程处理模块是一个模块，其中一个节点中的actor系统与另一个节点中的另一个actor系统通信，这是主要思想。Akka群集模块用于发现节点。
例如，如果有2个节点，并且想要知道另一个节点在哪里，或者哪个是ip地址或托管在哪里。Akka集群将提供该信息。它还提供有关成员状态的信息，例如，“成员是否活着，死亡，可达或无法访问”。
8.2。数据同步在数据存储中有树，目标是使所有树同步，如图8-4所示。存在不同的数据树，如库存，拓扑，Toaster。这些树被分配在一棵大树中，该树被同步以获得高可用性。为此，使用称为“RAFT the consensus algorithm”的算法，以确保所有这些树在每个节点上看起来相同。图8-4 - 同步数据树[14]对于RPC，每个注册节点都有一个RPC Registry同步，例如，一个想要在节点1上添加RPC流的开放流交换机，这很重要确切地知道如何在该交换机上调用添加的流。该信息进入注册表，它也被复制，如图8-5所示。
图8-5 - 同步RPC注册表[14]
8.3。通信“分布式数据存储”与数据树通信的方式是将演员放在数据树周围。因此，当需要与数据树进行通信时，只需要向actor发送消息并等待处理该消息，从而导致修改数据树。
8.4。数据分发一旦可以远程访问数据，接下来要做的就是不要将所有数据放在同一个地方。在大数据树的情况下，它被分解为较小的树并分布在整个群集中，如图8-6所示。
图8-6 - 分片[14] 8.5。高可用性（HA）使用分布式数据存储体系结构，可以分发所有数据，例如，库存可以在一个节点上，而拓扑在另一个节点中。但是如果库存在一个节点并且该节点发生故障，会发生什么？然后系统将无法访问库存数据。此问题的解决方案是以复制的方式在集群中分布数据，如图8-7所示。例如，成员1是给定分片的领导者，成员2和3充当跟随者，这些跟随者具有完全相同的数据。因此，如果成员1发生故障，其他两个节点中的一个将担任领导角色，以保证高可用性。它的工作方式再次由RAFT算法控制。
图8-7 - 分发数据存储[14]
8.6。数据存储流程数据存储中有2个模块，一个是de Config数据存储，另一个是操作数据存储。
8.7。启动一旦集群启动，就会创建一个分发数据存储的即时方法，然后它必须等待它准备好。这里的问题是，当存在分布式数据存储时，很难知道何时可以使用？
例如，使用“In Memory”数据非常清楚，它创建了“In Memory”数据存储，它可以立即用于工作，它可以开始创建事务等等。
相反，在“分发”数据存储中，这是不可能的，因为如果控制器的一个实例已启动且其他实例尚未启动，则不会达成共识。例如，谁是领导者。因此，在系统创建分发数据存储之后，有一个等待时间，直到它准备好，通常是90秒，试图找到领导者。这是足够的时间来启动另一个节点并创建其分片，这是为了选择领导者。
如果这发生在90秒内，那么它将向前移动，否则它将阻挡90秒。一旦创建了分发数据存储，它就会创建两个类：一个是允许与actor通信的ACTOR CONTEXT，这是必要的，因为分发数据存储不是一个actor，另一个是SHARD MANAGER，它是父的所有碎片。基于名为module-shards.conf的配置文件创建碎片，因此对于所有这些碎片，必须在90秒内找到领导者，如上所述。
因此，如果在找到领导者之前创建了一个事务，那么该事务将失败。创建分片时，他们首先要做的是从磁盘读取和恢复信息。
它可以从日志或快照发生，然后重新构建数据树，然后将其行为设置为跟随者，之后它说“我准备好进行通信” 继续选举过程以选择领导者。一旦找到领导者，倒计时和等待直到准备就绪。它可以继续前进，这个过程需要同时发生在ConfigDataStore和OperationalDataStore上。
9.集群的设置和测试本章将展示使用OpenDayLight控制器部署集群架构所需的配置。我们的想法是让控制器的多个实例一起工作，就像它们是单个实体一样，以便在系统中实现更好的扩展，持久性和高可用性。在这种情况下，它将是一个3节点集群，如图9-1所示，其中基本分布是Helium-SR4
图9-1 - 3节点集群
在深入了解集群部署之前，有必要考虑一下。
当想要构建集群系统时，记住需要奇数个控制器是非常重要的。这是因为OpenDayLight正在使用Raft算法，并且它总是需要大多数成员可用，以便以高可用性方式维护系统。
这意味着维护HA功能的最小簇大小为3个节点。如果它构建的节点少于2个节点，则可以进行一些功能测试，但它永远不会处于高可用性状态。需要考虑的另一件事是每个节点将扮演什么角色，这很重要，因为它必须先在运行时进行配置。
在这种情况下，主要目标是创建一个HA集群，所有成员都将扮演相同的角色。最后一个考虑因素是知道哪个是系统所需的数据，这个数据是在不同的分片之间分配的。默认情况下，OpenDayLight会带来一些已经创建的分片，它们是：Inventory，Topology，Toaster和其他类型信息的默认分片。在这个thesis将仅用于这些分片，因为论文的目的不是创建一个新分片。首先要做的是创建一个虚拟机（VM）来托管控制器，在这种情况下，它使用的是Ubuntu 14.04 [17]和VirtualBox 5.0.6 [18]的版本。现在有一台机器可以托管控制器，下一步是为这个部分获取OpenDayLight控制器有两个选项：第一步是下载一个已经修改过的版本，具有所需的所有功能，这个版本可以是在一些OpenDayLight存储库中找到。第二个选项是下载原始版本并手动添加群集部署所需的所有功能，此版本可以从OpenDayLight网页[8]中找到。对于这种情况，使用了直接从OpenDayLight网页下载的原始版本。
这里不会解释如何安装和配置VM [19]。需要的功能是odl-restconf，odl-l2switch-switch，odl-mdsal-clustering，odl-openflowplugin-flow-services。在集群架构中，至少需要3个VM，每个控制器一个。
然后可以在每个节点中运行控制器，这可以通过输入分发文件夹来完成，并查找/ bin目录。
为了运行控制器，必须像这样执行文件Karaf ./Karaf。这将运行控制器，并将出现一个命令窗口，如图9-2所示。
图9-2 - 命令窗口
在此窗口中可以执行某些操作，例如安装功能，查看已安装的功能以及查看控制器的某些内部过程。
例如，当交换机请求连接到控制器时。现在控制器正在运行，可以安装这些功能，其完成方式如下：在命令窗口中键入功能：install和所需功能的名称。在这种情况下，最重要的特征是odl-mdsal-clustering，这将在控制器中安装Akka工具包和更多特性，它将使集群功能成为可能。此功能还将创建一些初始配置，以及一些可以使手动配置成为可能的文件。
这些文件存储在“configuration / initial”文件夹中，它们被命名为akka.conf和module-shards.conf。安装odl-openflowplugin-flow-services也是必要的，这个功能负责与Open Flow设备的通信以及控制器之间的通信。一旦安装了上述功能，就可以从节点的手动配置开始。
首先，需要转到akka.conf文件并进行一些修改，需要做的更改是设置节点将侦听的IP地址和端口，配置所有种子节点并定义该节点的角色。初始配置中的IP地址和端口如下。然后有必要只修改节点的当前IP地址的主机名地址，端口是相同的。
此配置告诉系统它将在IP地址192.168.56.101和端口2500中进行侦听，这很重要，因为在此地址和端口将收到来自加入节点的所有请求。对于种子节点列表，最初有以下内容。在这一部分中，还必须修改种子节点的地址，因为最初它被配置为将自己与本地主机地址联系。可以在系统中配置多个种子节点，对集群中必须有多少种子节点没有限制。
对于每个节点的角色，最初它是由缺陷引起的，如下所示。在此部分中，仅当配置的节点不是第一个节点时才必须进行修改，但如果是第二个节点，则必须将其更改为member-1或member-2。
这些是akka.conf文件中所需的所有更改。然后还需要修改第二个文件module-shards.conf。在此文件中，需要指定是否将在其他节点中复制任何分片。在这将显示库存碎片的情况，初始文件如下所示。可以在不更改任何此文件的情况下运行群集，但是如果要查看实现高可用性的情况，需要在所有将成为集群一部分的节点中制作所有分片的副本，如下所示。一旦在所有节点中完成先前的配置，则可以再次重新启动所有控制器并从集群服务开始。
9.1。测试在集群配置完成后，需要实现一些允许验证设置是否正确的机制。验证意味着证明集群正在正常运行，例如验证每个分片都有一个领导者，并且系统正在进行正确的操作，如分片复制和提交操作。为此目的，将使用“Postman”作为发出HTTP请求的应用程序，使用此应用程序可以向控制器询问有关特定分片的信息。执行此操作的命令如下。获取http://192.168.56.101:8181/jolokia/read/org.opendaylight.controller:Category=Shar ds，name = member-1-shard-inventory-config，type = DistributedConfigDatastore此请求返回有关状态的信息集群如图9-3所示。
图9-3 - 测试响应
在此答案中，可以获取有价值的信息，如最后一个日志索引，当前术语，失败事务，已提交事务和当前领导者。
10.日志分析
在这部分中，将分析哪些是在每个节点中为控制器执行的操作。当控制器开始运行时，它会创建一个文本文件，指定所有步骤，该文件位于文件夹“data”中，名称为Log.txt。这意味着该文件包含有关操作的所有信息，在控制器中进行的通知和修改。日志可以帮助理解系统中真正发生的事情。为了集中在作为聚类部分的主要目标，将仅分析与该特征相关的信息。节点1让我们从种子节点列表（节点1）中的第一个节点开始。控制器启动并执行所有默认功能后，必须将自身初始化为群集节点。
这是一个自动过程，如下所示。
2016-01-19 18：04：11,359 | 信息| ult-dispatcher-2 | Remoting | 266 - com.typesafe.akka.slf4j - 2.3.10 | 远程开始; 听地址：[akka.tcp：//opendaylight-cluster-data@192.168.56.101：2550]
2016-01-19 18：04：11,480 | 信息| ult-dispatcher-2 | kka：// opendaylight-cluster-data）| 266 - com.typesafe.akka.slf4j - 2.3.10 | 群集节点[akka.tcp：//opendaylight-cluster-data@192.168.56.101:2550] - 开始…
2016-01-19 18：04：11,625 | 信息| ult-dispatcher-3 | kka：// opendaylight-cluster-data）| 266 - com.typesafe.akka.slf4j - 2.3.10 | 群集节点[akka.tcp：//opendaylight-cluster-data@192.168.56.101：2550] - 已注册的群集JMX MBean [akka：type = Cluster]
2016-01-19 18：04：11,626 | 信息| ult-dispatcher-3 | kka：// opendaylight-cluster-data）| 266 - com.typesafe.akka.slf4j - 2.3.10 | 群集节点[akka.tcp：//opendaylight-cluster-data@192.168.56.101：2550] - 已成功启动

节点1成功初始化后，Akka群集模块开始工作。它将加入消息发送到配置文件中配置的所有种子节点。此时，由于它是唯一初始化的节点，因此无法获得任何回复，这可以在日志中得到证明，哪里可以看到节点1联系其他节点但没有回答。连接被拒绝，如下所示。

2016-01-19 18：04：12,321 | 警告| ult-dispatcher-4 | ReliableDeliverySupervisor | 266 - com.typesafe.akka.slf4j - 2.3.10 | 与远程系统的关联[akka.tcp：//opendaylight-cluster-data@192.168.56.102：2550]失败，地址现在为[5000] ms门控。原因：[协会失败[akka.tcp：//opendaylight-cluster-data@192.168.56.102：2550]]引起：[连接被拒：/192.168.56.102:2550]
2016-01-19 18：04：12,343 | 信息| ult-dispatcher-4 | rovider $ RemoteDeadLetterActorRef | 266 - com.typesafe.akka.slf4j - 2.3.10 | 消息[akka.cluster.InternalClusterAction $ InitJoin $]从Actor [akka：// opendaylight-cluster-data / system / cluster / core / daemon / firstSeedNodeProcess-1＃645930444]到Actor [akka：// opendaylight-cluster- data / deadLetters]未送达。[1]遇到死信。可以使用配置设置’akka.log-dead-letters’和’akka.log-dead-letters-during-shutdown’关闭或调整此日志记录。

考虑到这一点，下一步是通过向其方向发送“加入消息”并指定其配置角色“member-1”来加入自身。之后，节点设置为up并且操作可以开始，只有当它是第一个节点列表中的第一个节点时才可以实现。

2016-01-19 18：04：12,263 | 信息| config-pusher | DistributedDataStore | 280 - org.opendaylight.controller.sal- distributed-datastore - 1.1.4.Helium-SR4 | 创建ShardManager：shardmanager-config当模块完全运行时，这意味着系统已从磁盘读取它或从零创建它，然后系统在日志中发出如下通知。2016-01-19 18：04：13,544 | 信息| lt-dispatcher-19 | ShardManager | 280 - org.opendaylight.controller。sal-distributed-datastore - 1.1.4.Helium-SR4 | 恢复完成：shard-manager-config
2016-01-19 18：04：13,550 | 信息| ult-dispatcher-4 | ShardManager | 280 - org.opendaylight.controller.sal- distributed-datastore - 1.1.4.Helium-SR4 | 恢复完成：shard-manager-operational现在所有模块都在系统中运行，下一步是转到初始配置文件，以便读取哪些是需要创建的分片。在这种情况下只有碎片：库存，拓扑，烤面包机和默认。在这个日志中，只提到了shard-inventory-operational，但是所有分片的过程都相同。一旦系统创建了分片，它就会进入“InMemoryDataTree”。2016-01-19 18：04：14,208 | 信息| lt-dispatcher-20 | 碎片| 273 - org.opendaylight.controller.sal-akka-raft - 1.1.4。氦-SR4 | 碎片创建：member-1-shard-inventory-operational persistent：true
2016-01-19 18：04：14,209 | 信息| lt-dispatcher-20 | InMemoryDataTree | 151 - org.opendaylight.yangtools.yang- data-impl - 0.6.6.Helium-SR4 | 尝试安装模式上下文现在，分片位于“InMemoryDataTree”中，可以从日志中恢复信息，之后，它会发出一条通知，告知该分片已准备就绪。
2016-01-19 18：04：14,279 | 信息| lt-dispatcher-20 | 碎片| 273 - org.opendaylight.controller.sal-akka-raft - 1.1.4.Helium-SR4 | member-1-shard-inventory-operational：使用期刊批量大小1开始恢复2016-01-19 18：04：14,281 | 信息| lt-dispatcher-20 | RoleChangeNotifier | 272 - org.opendaylight.controller.sal- clustering-commons - 1.1.4.Helium-SR4 | RoleChangeNotifier：akka.tcp：// opendaylight-cluster-data@192.168.56.101：2550 / user / shardmanager-operational / member-1-shard-inventory-operational / member-1-shard- inventory-operational-notifier＃-1968314382已创建并准备好进行分片： member-1-shard-inventory-operational当碎片准备好运行时，它总是以Raft算法中定义的Follower状态开始。在日志中可以看到节点如何将分片的状态切换为跟随者。在此步骤之后，系统开始执行领导者选举过程。2016-01-19 18：04：14,350 | 信息| lt-dispatcher-19 | 碎片| 273 - org.opendaylight.controller.sal-akka-raft - 1.1.4.Helium-SR4 | 恢复已完成 - 将actor切换为Follower - Persistence Id = member-1-shard-inventory- operational最后一个索引在log = -1，snapshotIndex = -1，snapshotTerm = -1，journal-size = 0节点2在此节点中也观察到与节点1相同的过程。它启动并立即尝试与种子节点通信，在这种情况下节点1已经在运行并且它是第一个种子节点列表，必须有一个答案。因此，两个节点之间的通信如下。首先，节点2向节点1发送“加入消息”，并以“欢迎消息”回复。这会自动创建连接，并允许继续进行群集部署。2016-01-19 18：04：59,926 | 信息| lt-dispatcher-19 | kka：// opendaylight-cluster-data）| 266 - com.typesafe.akka.slf4j - 2.3.10 | 群集节点[akka.tcp：//opendaylight-cluster-data@192.168.56.101：2550] - 节点[akka.tcp：// opendaylight-cluster-data@192.168.56.102：2550]正在加入，角色[member-2 ]
2016-01-19 18:05:01，869 | 信息| lt-dispatcher-15 | kka：// opendaylight-cluster-data）| 266 - com.typesafe.akka.slf4j - 2.3.10 | 群集节点[akka.tcp：//opendaylight-cluster-data@192.168.56.102：2550] - 欢迎来自[akka.tcp：// opendaylight-cluster-data@192.168.56.101：2550]
2016-01-19 18： 05：00,753 | 信息| ult-dispatcher-2 | kka：// opendaylight-cluster-data）| 266 - com.typesafe.akka.slf4j - 2.3.10 | 群集节点[akka.tcp：//opendaylight-cluster-data@192.168.56.101：2550] - 负责人正在将节点[akka.tcp：//opendaylight-cluster-data@192.168.56.102：2550]移动到[Up]群集中的所有节点都已启动，并且在每个节点中创建了分片，然后是时候从每个分片的领导者选举开始，这是通过实施Raft算法完成的。
如前所述，所有碎片都是作为追随者开始并等待“心跳” 在确定的时间内，他们没有收到任何可以将其状态改为候选人并试图从其他节点获得投票的东西。因此，他们发送请求投票消息，如果多数投票给一个节点，该节点可以将其状态更改为领导者。在等待确定的时间“超时”之后，在日志中可以观察分片何时将其状态从跟随者改变为候选者。在这种情况下，节点1的分片将状态更改为候选。

2016-01-19 18：04：24,425 | 信息| lt-dispatcher-20 | 碎片| 273 - org.opendaylight.controller.sal-akka-raft - 1.1.4.Helium-SR4 | member-1-shard-inventory-operational（追随者）： - 从行为追随者切换到候选人
2016-01-19 18：04：24,425 | 信息| lt-dispatcher-20 | RoleChangeNotifier | 272 - org.opendaylight.controller.sal- clustering-commons - 1.1.4。氦-SR4 | RoleChangeNotifier用于member-1-shard-inventory-operational，从关注者到候选者的角色更改一旦收到投票，就可以将确定分片的领导者设置为如下。
2016-01-19 18：05：05,241 | 信息| ult-dispatcher-3 | 碎片| 273 - org.opendaylight.controller.sal-akka-raft - 1.1.4.Helium-SR4 | member-1-shard-inventory-operational（候选人）： - 从行为候选人转为领导者
2016-01-19 18：05：05,244 | 信息| ult-dispatcher-5 | RoleChangeNotifier | 272 - org.opendaylight.controller.sal-clustering-commons - 1.1.4.Helium-SR4 | RoleChangeNotifier用于member-1- shard-inventory-operational，接收角色从候选人变为领导者上述部分非常重要，因为进行此分析是实际了解系统内部实际情况的唯一方法。
这将使我们也了解如何解决问题。11.控制器之间的消息已经解释了系统如何在内部工作，但仍然必须解释节点如何相互交互。交互意味着控制器之间的实际数据交换。考虑到这一点，执行分组数据捕获，以确定OpenDayLight数据包的结构以及实现的不同消息的方式。这将是项目最重要的部分之一，因为它将为将来与不同控制器的交互设置一些参数，拥有在OpenDayLight控制器和另一种控制器之间构建代理的工具。这将允许未来的群集体系结构，其中群集可以组成不同类型的控制器一起工作。为此，数据包捕获使用的是Wireshark [20]，它是一个数据包分析工具，这些工具可以过滤所需的所有数据包，也可以仅分离有效负载中包含的所需信息。11.1。捕获一旦控制器启动，它们就会尝试与种子节点进行通信，如前所述，首先是建立TCP通道。如果正在联系的节点处于活动状态，则它将允许连接。否则连接将被拒绝。此TCP通道使用三种握手机制构建。在聚类的第一部分期间，Akka工具负责所有通信，然后发生Raft算法。11.1.1。Akka工具部分握手并建立通道后，节点尝试通过发送消息来加入种子节点，消息基本上包含其方向，如下所示。… DB …> 3.opendaylight-cluster-data…192.168.56.102 …“。tcp …第一次接触后，加入节点必须等到任何种子节点回答第一次联系。这个答案非常简单，它包含了它的地址… DB …> 3.opendaylight-cluster-data…192.168.56.101 …“。tcp。] … …当第一次接触完成时，加入节点可以从加入过程开始。这是通过启动内部动作调用“加入操作”来完成的。此过程还具有包含在消息中的标识号。消息如下所示。…％…; 9akka.tcp：// opendaylight-cluster- data@192.168.56.101：2550 / .gc … system … cluster … …core … daemon“，akka.cluster.InternalClusterAction $ InitJoin $（…”w uakka.tcp：//opendaylight-cluster-data@192.168.56.102：2550 / system / cluster / core / daemon / joinSeedNodeProcess-1＃ - 2021912680一旦种子节点收到了上一个初始化消息，它就会发回该加入过程的确认，以便继续加入。整个通信是在标识号的帮助下进行的， number可以识别不同的进程.uakka.tcp：//opendaylight-cluster-data@192.168.56.102：2550 / system / cluster / core / daemon / joinSeedNodeProcess-1＃ - 2021912680.l8.opendaylight-cluster-data。.192.168.56.101 …“。akka.tcp … akka.cluster.InternalClusterAction $ InitJoinAck”^ akka.tcp：//opendaylight-cluster-data@192.168.56.101：2550 / system / cluster / core /守护进程＃1239809082确认后，加入节点必须发送有关其配置（集群中的成员或角色）的信息。这样做是因为有些配置中每个成员具有不同的角色。在这种情况下，初始配置中定义的角色是“member-2”。... V .....; 9akka.tcp：//opendaylight-cluster-data@192.168.56.101：2550 / .....ķ8.opendaylight-集群data..192.168.56.102 ... “.akka.tcp .... v..member-2 ....... system ...... cluster ...... core ..... daemon”'akka.cluster.InternalClusterAction $ Join（...“^ akka.tcp：//opendaylight-cluster-data@192.168.56.102：2550 / system / cluster / core / daemon＃2118301878现在种子节点知道加入节点的角色，它可以通过将加入节点的状态更改为up来完成启动过程。它还必须通知加入节点它已启动，这是通过欢迎消息完成的。^ akka.tcp：//opendaylight-cluster-data@192.168.56.102：2550 /系统/群/核心/守护＃2118301878 … [R … / H.KI …… L。（。M。） - 。I-.MI，I…3.4.34…35.340 …＆… W. \ p … | B …（6 … PM … L.＃757 … 2.R00M206JJMKL.L25.HJ.01I2.4M5LLL3KU …``。TBdP …... .... J..ZL..F ... B，@ ......＆...... * akka.cluster.InternalClusterAction $欢迎“^ akka.tcp：// opendaylight- cluster - data@192.168.56.101：2550 / system / cluster / core / daemon＃1239809082从此时起，加入节点开始成为集群的一部分。对于要加入群集的所有节点，此过程相同。在加入过程之后，集群中的所有成员都可以开始交换信息，这是在Akka集群模块的帮助下实现的。还有2条消息是该模块的一部分，一个是心跳，另一个是八卦消息。Heartbeat是一个非常重要的消息，它用于维护集群中成员的up状态，这就是为什么在集群的整个操作期间重复它。如果未响应心跳消息，则表示某个节点无法访问，系统会将其标记为该节点。只要未达到Phi应计失败检测器阈值，该节点将作为群集的一部分保留，否则必须将其从系统中删除。心跳消息还集成了心跳发送方号码，这对于识别不同的参与者很有用。它看起来如下。9akka.tcp：//opendaylight-cluster-data@192.168.56.102：2550 / … 8.opendaylight-cluster-data…192.168.56.101 …“。kka.tcp … system … cluster … heartbeatReceiver“-akka.cluster.ClusterHeartbeatSender $ Heartbeat（…”qoakka.tcp：// opendaylight - cluster-data@192.168.56.101：2550 / system / cluster / core / daemon / heartbeatSender＃-1807478239每个心跳消息都必须得到应答或确认，否则节点将达到phi accrual fail detector的值。心跳回答消息如下所示… Y … qoakka.tcp：//opendaylight-cluster-data@192.168.56.101：2550 / system / cluster / core / daemon / heartbeatSender＃-180747 8239.u？8.opendaylight-cluster-data…192.168.56.102 …“ 。2550 / system / cluster / core / daemon＃2118301878到此处为Akka集群工具，从现在开始，主要角色将在raft算法的监督下运行。11.1.2。Raft算法部分当集群服务启动时，是时候从系统中实现的所有分片的领导者选举开始。正如之前在Raft算法描述中所解释的那样，超时的第一个节点将成为候选者并将发送请求投票。这是为了获得大多数节点的认可并将状态更改为给定分片的领导者。与之前一样，它仅以Shard-Inventory-Operational消息的情况为例，但所有其他消息完全相同。该消息提供有关当前术语和候选ID的信息。请求投票消息如下所示。9akka.tcp：//opendaylight-cluster-data@192.168.56.102：2550 / … SR = org.opendaylight.controller.cluster.raft.messages。RequestVotem [}。a。）＆… J…lastLogIndexJ…lastLogTermL…candidateIdt…Ljava / lang / String; xr.Aorg.opendaylight.controller.cluste r.raft.messages.AbstractRaftRPC … .l … J…termxp … t。$ member-1-shard-inventory-operational … …用户… sha rdmanager-operational。（… $ member-2-shard-inventory-operational（…“… akka.tcp：//opendaylight-clusterdata@192.168。 56.101：2550 / user / shardmanager-operational / member-1-shard-inventory-operational＃-1784895488此消息的答案非常相似，此外它还提供有关是否授予投票的信息。消息看起来像以下。… akka.tcp：//opendaylight-cluster-data@192.168.56.101：2550 / user / shardmanager-operational / member-1-shard- inventory-operational＃-1784895488 … sr.Borg.opendaylight.controller.cluster.raft.messages.RequestVoteReply …_ … … Z…voteGrantedxr.Aorg.opendaylight.controller.cluster.raft.messages.AbstractRaftRPC … l … J…termxp …“。 .akka.tcp：//opendaylight-cluster-data@192.168.56.102：2550 / user / shardmanager-operational / member-2-shard-inventory- operational＃-870461665一旦候选节点获得大多数选票，在给定的术语中它将成为给定分片的领导者。在那之后它开始将数据复制到其他节点。在Akka的这种情况下，这种消息被称为“附加条目”消息，它也可以是用作心跳信息的一种方式。这是为了确定一个特定的领导者是上升还是下降，如果领导人失败，就必须进行另一轮选举。典型的附加条目消息如下所示。9akka.tcp：//opendaylight-cluster-data@192.168.56.102：2550 / … T … $ member-1-shard-inventory-operational … … … 0 … 8 …用户… shardmanager-操作。（ … $ member-2-shard-inventory-operational“org.opendaylight .controller.protobuff.messages.cluster.raft.AppendEntriesMessages $ AppendEntries（…”… akka.tcp：// opendaylight-cluster- data@192.168.56.101:2550/user / shardmanager-operational / member-1-shard-inventory-operational＃-1784895488此消息的答案如下：…`… akka。 tcp：//opendaylight-cluster-data@192.168.56.101：2550 / user / shardmanager-operational / member-1-shard- inventory-operational＃-1784895488 … sr.Dorg.opendaylight.controller .cluster.raft。结果，系统创建了一个事务，并开始将所有数据从分片领导者复制到关注者。该消息的示例如下。9akka.tcp：//opendaylight-cluster-data@192.168.56.102：2550 / rt… member-1-shard-topology-operational … * … .iorg。opendaylight.controller.cluster.raft.protobuff.client.messages.CompositeModificationByteStringPayload … Rclass org.open daylight.controller.cluster.datastore.modification.MergeModification … .0…Y … …0。.b + urn：TBD：params：xml：ns：yang：network-topologyb2013-10-21b.network-topology…Rclass org.opendaylight.controller.cluster.datastore.modification.Merge Modification … .0 … .0…c … .0。.B +瓮：TBD：PARAMS：XML：NS：阳：网络topologyb2013-10-21b.topologyb。network-topology…Rclass org.opendaylight.controller.cluster.datastore。modification.WriteModification.8 … .0 … 0 …“… …流程：1…0 … …“… …流程：1…0。.2 … .0。。：。flow：1H.b + urn：TBD：params：xml：ns：yang：network-topologyb2013-10- 21b.topologyb.topology-idb.network-topology … 50.8 … …用户… shardmanager-operational。’…＃member-2 -shard-topology-operational“_org.opendaylight.controller.protobuff.messages.cluster .raft.AppendEntries消息$ AppendEntries（…“… akka.tcp：//opendaylight-cluster-data@192.168.56.101:2550/user/shardmanager-operational / member-1-shard-topology- operational＃ -1971300728为响应上述消息，关注者回复“创建交易”消息并将其发送给领导者。消息如下… c …; 9akka.tcp：// opendaylight-cluster- data@192.168.56.101：2550 / … member-2-txn-0 … … 2550 / user / shardmanager-operational / member-1-shard-topology-operational＃-1971300728上面提到的是由于给定分片的修改，因此必须为给定的actor生成事务创建。在创建事务之后，一旦关注者收到了所有信息，他们就会回复给领导者一条消息，这意味着收到的信息将与分片中的旧信息合并。消息如下所示。…; 9akka.tcp：//opendaylight-cluster-data@192.168.56.101：2550 / … i … 0…Y … … .0。.b + urn：TBD：params：xml：ns：yang：network-topologyb2013-10-21b.network-topology … user … shardmanager-operational .’…＃ member-1-shard-topology- operational。＃… shard-member-2-txn-0＃1175605301“] org.opendaylight.controller.protobuff.messages。“… …流量：1…0 …”。…流量：1…0。.2 … .0。。：流量：1H.b +瓮：TBD：PARAMS：XML：NS：阳：网络topologyb2013-10-21b.topologyb。topology- idb.network-topology … user … shardmanager-operational .’…＃member-1-shard-topology-operational。＃… shard-member- 2- txn-0＃1175605301“] org.opendaylight.controller.protobuff.messages.transaction.ShardTransactionMessages $ WriteData（…”B @ akka.tcp：//opendaylight-cluster-data@192.168.56.102：2550 / temp / $ d它也必须得到领导者的承认，消息如下：@ akka.tcp：//opendaylight-cluster-data@192.168.56.102：2550 / temp / $ dh … borg.opendaylight。 controller.protobuff .messages.transaction.ShardTransactionMessages $ WriteDataReply“… akka.tcp：// opendaylight-cluster-data @ 192.168.56 .101：2550 / user / shardmanager-operational / member-1-shard-topology-operational / shard-member-2-txn-0＃1175605301一旦所有粉丝拥有内存中的信息，他们就会通知领导者信息可以提交到其中数据树。消息如下所示。…第…; 9akka.tcp：//opendaylight-cluster-data@192.168.56.101：2550 / …构件-2- TXN-0 … user … shardmanager- operational.3 … / member-1-shard-topology-operational＃-971300728“lorg.opendaylight.controller.protobuff.messages.c ohort3pc.ThreePhaseCommitCohortMessages $ CanCommitTransaction（…” B@akka.tcp：// opendaylight-cluster- data@192.168.56.102：2550 / temp / $ f领导发回一个确认，如下所示。@ akka.tcp：//opendaylight-cluster-data@192.168。 56.102：2550 / temp / $ fy … qorg.opendaylight.controller.protobuff.messages .cohort3pc。该虚拟网络的大小不同，目的是分析不同情况下网络的带宽使用情况。这里还将描述实验方法和分析期间的所有步骤。12.1。实验方法这项工作的方法如下。对于这部分进行了数据包捕获，使用了网络协议分析仪，在本例中为“Wireshark”[20]。然后用获得的数据进行数据处理，以获得有用的信息和带宽图，这个过程用Matlab [22]。
12.2。Mininet如[21]中所述，Mininet是一个网络模拟器，它创建一个虚拟主机，交换机，控制器和链接的网络。Mininet主机运行标准的Linux网络软件，它的交换机支持OpenFlow，可实现高度灵活的自定义路由和软件定义网络。它可以在一台机器（VM，云或本机）上创建一个真实的虚拟网络，在一台机器上运行真正的内核，交换机和应用程序代码，只需一个命令。它支持研究，开发，学习，原型设计，测试，调试以及可以从笔记本电脑或其他PC上拥有完整实验网络中受益的任何其他任务。Mininet默认带有自己的控制器，但也有可能使用远程控制器。
这正是实验所需的网络仿真器，Mininet网络将通过TCP / IP连接连接到SDN控制器“OpenDayLight”。Mininet中最简单的网络由一个交换机和2个主机组成，它可以使用以下命令执行。还有一些其他配置预先建立了一行命令，如：线性，单一和树形拓扑，但也有可能借助python脚本创建自定义拓扑。在这种情况下，它将使用可以按以下方式运行的线性拓扑。上面的命令始终以“mn”和一些参数开头，以定义要使用的拓扑和控制器的类型。这里只使用遥控器，以测试OpenDayLight控制器。在线性拓扑中，所有开关都以线性方式连接，每个开关都有自己的主机，如图12-1所示。
图12-1 - 线性拓扑
运行网络创建命令后，将显示如何创建并在系统打开Mininet终端后立即如图12-2所示，其中可以执行与网络相关的某些命令。
图12-2 - Mininet终端
在此终端中，可以执行连接测试，ping并获取有关网络的信息，如：节点，链接和地址。12.3。数据捕获和处理在本节中将描述如何捕获和处理OpenDayLight控制器之间交换的所有信息，这些信息也将用于工作的最后部分，目的是估计一个带宽使用的实验模型。集群架构。在整个工作期间，群集体系结构由OpenDayLight控制器的三个节点或实例组成。为简单起见，本部分将分析其中仅两个之间的流量，将其命名为node1作为控制器A，将node2命名为控制器B.这两个节点将通过使用Wireshark工具执行数据捕获。此流量将从A→B和B→A两个方向捕获.Wiresshark捕获包含大量信息，但由于显而易见的原因，本部分将重点关注控制器A和B之间传输的kbps量。有了这些信息，就可以进行进一步的估算和分析，不幸的是，Wireshark没有可以直接用于Matlab的输出格式。这就是为什么一些Linux命令将用于导出Wireshark文件所需的数据，基本上它过滤了所有原始信息，然后选择了重要的信息。使用以下命令执行上述操作。tshark -q -nr source_file.pcapng -z“io，stat，0.1，ip.src == 10.0.1.101 && ip.dst == 10.0.1.102”| 尾巴-n +13 | 头-n -1 | awk’{print $ 2，$ 12}’> result.txt上面的命令过滤源文件，然后它使用一个采样频率以获得一个矩阵，其中包含一些可以区分时间的数据，从这个矩阵开始使用Linux命令如tail，head和awk，如图12-3所示。
图12-3 - 数据矩阵捕获
在这种情况下，只选择时间和字节列。该命令的最后一部分用于保存包含分析所需信息的文件，在这种情况下，结果文件是两列文件，包含随后可以在Matlab中加载的时间和字节。对于实验，Mininet网络在60s时连接到集群，随后在120s时被移除。在此部分之后，获得的数据将在Matlab中处理。为了以更合适的方式绘制带宽使用情况，需要进行一些处理，因为本文采用的是滑动窗口方法[23]。这种方法基本上是在控制器之间交换所有字节并对它们求和，然后使用之前实现的采样时间执行标准化。如[23]中所述，滑动窗口方法以下列方式执行。选择宽度大于采样间隔的窗口大小（W）。窗口以信号的起始样本为中心，计算窗口中信号值的平均值并将其分配给中心值。在下一次迭代中，窗口向右移动一个样本，并在当前窗口中以与上一步骤相同的方式计算平均值，并持续到信号结束。在每次迭代中窗口之间发生重叠。在处理结束时，信号将比原始信号更平滑，但数据仍可用于构建模型。在图12-4中显示了具有3个节点大小的Mininet网络的带宽使用情况，具有不同的Ts和W值。图12-4 - 带宽使用图A→B
12.4。建模一旦完成捕获，就可以使用该数据为OpenDayLight控制器之间的流量交换构建实验模型，该模型可用于评估SDN网络中的可扩展性。通过OpenDayLight控制器，可以使用该模型轻松预测SDN网络中的不同场景，该模型利用所有实验捕获，以便为所有可能的情况创建估计。程序如下，首先需要获得所需的数据。为此，Mininet网络连接到控制器，这个Mininet网络具有线性架构，并且其大小会有所不同。它将部署一个线性拓扑，其大小为：1,3,5,7,9,12,15,20,25,30,40,50交换机。不幸的是，在50个节点之后，我们的计算资源无法以正确的方式运行，这就是为什么拓扑只能变化多达50个节点。然而，拟合曲线将扩展到100个节点。建模的设置如图12-5所示。在实验期间，对于每个拓扑尺寸重复该过程5次，这是为了具有更准确的测量。该过程如下。
1.启动将成为网络一部分的所有控制器。
2.设置所需的拓扑并建立与控制器的连接。
3.在180秒内启动数据包捕获，同时将虚拟网络连接到控制器。
4.在建立的时间后停止虚拟网络。
5.停止虚拟网络后60秒停止数据包捕获。
6.关闭群集中的所有控制器。
7。从数据包捕获中提取所有有用的数据，这是通过使用Tshark工具执行的。信息在.txt文件中提取。它包含2个变量，一个是时间，另一个是使用的位数。
8.在Matlab中打开.txt文件进行处理。
9.生成模型和图形。
图12-5 - 建模的测试
设置通过使用从A→B和B→A传输的“带宽”字节数生成模型。还需要拓扑大小。这些信息传递给称为多项式曲线拟合[24]的Matlab函数，它使用最小二乘法找到最佳拟合曲线。结果，Matlab给出了平均值的拟合曲线。图12-6显示了A→B模型和B→A模型的结果。
图12-6 - 带宽使用建模
在上图中，可以证明带宽相对于网络中节点数量的变化。在第一种情况下，从A→B，可以观察到带宽相对于节点数以线性方式增加。对于来自B→A的第二种情况，也可以观察到相同的线性增加，但是在这种情况下消耗的方式比前一种情况少。对上图中显示的行为的解释是因为在使用OpenDayLight进行聚类时，信息仅从领导者流向关注者，这就是为什么从A到B的带宽使用比从B到A的更多。领导者必须发送所有的有关拓扑，库存以及与控制器之间的成员资格相关的信息的信息。相反，其他节点只需要交换有关成员资格的信息，这就是它消耗较少带宽的原因。
13.结论
大多数最大的供应商和公司都支持将传统网络迁移到软件定义网络的想法，因此需要在SDN控制器领域进行进一步的研究，以确定哪个是最有效的。
网络。SDN网络已经证明，利用其解耦架构，可以更灵活，更可靠地整合网络流量。本文讨论了具有分布式SDN网络的重要性，以避免出现单点故障的问题，同时也因为分布式系统可以实现信息的高可用性，可扩展性和持久性。还分析了集群架构模式下OpenDayLight控制器的行为，目的是更好地理解如何操作控制器。
这项工作的最大部分之一是对控制器之间通信中用于网络的协议的研究，在这部分中还解释了控制器之间交换的不同消息。这是在Wireshark的帮助下完成的，在所涉及的接口上进行流量捕获并分析数据包以了解通信。在论文的最后部分，通过在控制器之间进行流量捕获来执行带宽使用分析。再次实现了Wireshark的数据捕获，然后实现了Matlab进行数据处理。本章实现了不同场景下带宽使用的实验模型。该过程包括改变网络的拓扑尺寸，这是通过Mininet中的线性拓扑实现的，然后它连接到主控制器。通过该模型可以观察带宽使用相对于拓扑大小的行为，然后最终结果是带宽随着拓扑大小以线性方式增长。
13.1。未来的工作寻求迁移到SDN网络对于证明和测试市场上目前可用的所有不同控制器非常重要，因为到目前为止还没有为SDN网络定义任何标准。为此，在ODL控制器之间交换的消息中进行了分析，为了系统的可理解性设置一些参数。这可以在以后与不同控制器的集成中使用，在ODL控制器和不同控制器之间构建代理。这也解释了集群架构中使用的所有协议。未来的另一项工作可能是在实际设备中实施集群，这是因为部署是在虚拟化环境中执行的，并且可能导致实际实施中的一些变化。这将有可能验证所获得的结果并比较实际网络中的带宽使用模型。参考文献[1] C.技术报告，“预测和方法，2014 - 2019年白皮书。”，思科视觉网络索引，2015年。
[2] ON基金会，“软件定义网络：网络的新规范”，ONF，白皮书，2012年。
[3] FMVRPEVCERSASU Diego Kreutz，“软件定义网络：综合调查”，IEEE，2015年。
[4] L. Faughnan，“软件定义网络”，TechEntral，2013年。
[5]是＆。一世。小组，“软件定义网络入门+深入了解大型交换机网络”，技术研究，2012年。
[6] LDJQHZ Ying Li，“软件定义中的多控制器管理”，IEEE，计算机应用与通信研讨会，2014年。
[7] ] L.基金会，“Opendaylight平台概述”，2016年。[在线]。可用：https：//www.opendaylight.org/platform-overview-beryllium。
[8] L.基金会，“OpenDayLight定义”，2016年。[在线]。可用：https：//www.opendaylight.org/。
[9] DA Liubov Efremova，“OpenDaylight中有什么”，2015. [在线]。可用：https：//www.mirantis.com/blog/whats-opendaylight/。
[10] J. Ogando，“分布式控制：多站加载系统的另一种选择”，塑料技术，1995年。
[11] U. o。P. Insup Lee，“引入分布式系统，讲义”，2014年。[在线]。可用：http：//www.cis.upenn.edu/~lee/00cse380/lectures/ln13-ds.ppt。
[12] JO Diego Ongaro，“寻求可理解的共识算法”，斯坦福大学，2014年。
[13] JO Diego Ongaro，“筏可视化”，2014年。[在线]。可用：https://raft.github.io/。
[14] M. Raja，“MD-SAL聚类内部，Linux基金会”，2015年。[Enlínea]。可用：http：//events.linuxfoundation.org/sites/events/files/slides/MD- SAL％20Clustering％20Internals.pdf。
[15] Akka，“Akka定义”，2011年。[在线]。可用：http://akka.io/。
[16] Akka，“Cluster Specification Akka，”2011。[在线]。可用：http：//doc.akka.io/docs/akka/snapshot/common/cluster.html#cluster。
[17] Ubuntu，“Ubuntu文档”，[在线]。可用：http：//www.ubuntu.com/。
[18] Oracle，“virtualbox文档”，[在线]。可用：https：//www.virtualbox.org/。
[19] L.基金会，“OpenDayLight用户指南 - 氦发布”，2015年。[在线]。可用：https：//www.opendaylight.org/software/release-archives。
[20] W.基金会，“wireshark Documentarion”。
[21] M. Org，“Mininet演练”，[在线]。可用：http：//mininet.org/。
[22] Mathworks，“Matlab文档”，[在线]。可用：http：//www.mathworks.com/。
[23] AS Muqaddas，“分布式ONOS控制器的评估”，硕士论文 - Politecnico di Torino，2015。[24] Mathwork，“Polynomial Curve Fitting，”[在线]。可用：http：//www.mathworks.com/help/matlab/math/polynomial-curve-fitting.html。
<---------------------------------------------------------------------o

w1272145777

关注

2
点赞
踩
5

收藏

觉得还不错? 一键收藏
1
评论
odl基础翻译

内容1.介绍… … … 51.1。大纲 … … … 62.软件定义网络… … … 82.1。SDN理论… … … 92.2。SDN定义… … … 112.3。OpenFlow … … … 112.4。分布式控制器… … … 123. OpenDayLight（ODL）… … … 143.1。建筑… … … 153.2。ODL的服务… … … 164.分布式系统… … … 18...
复制链接

扫一扫