第1部分。开始
1.1简介和问题陈述
在MTS,我们集中控制数据传输网络(或更简单地说,是运输网络(不要与物流运输网络混淆))的质量,以下简称TS。并且,在我们活动的框架内,我们始终必须解决两个主要任务:
- 已检测到客户服务(相对于车辆)的性能下降-有必要确定其通过车辆的连接路径,并找出车辆的任何部分是否是服务质量下降的原因。此外,我们将其称为直接问题。
- 检测到传输信道或信道序列质量下降-必须确定哪个服务依赖于此信道来确定影响。此外,我们将其称为反问题。
TS服务被理解为客户端设备的任何连接。这些可以是基站(BS),B2B客户端(使用MTS TS来组织对Internet和/或重叠VPN网络的访问),固定访问客户端(所谓的宽带访问)等。等等
我们拥有两个中央信息系统:
绩效监控系统 | 网络参数和拓扑数据 |
---|---|
指标,KPI TS | 配置参数,L2 / L3通道 |
任何运输网络本质上都是有向图 ,其中每个边具有非负容量。因此,从一开始,就在图论的框架内寻找这些问题的解决方案。
首先,通过从字面上组合并以网络图的形式呈现拓扑和质量数据,解决了将TS和服务的质量指标与TS拓扑进行比较的问题。
根据拓扑和性能数据形成的图的视图是使用开源Gephi软件实现的。这使得解决拓扑的自动表示问题成为可能,而无需人工进行拓扑更新。看起来像这样:
实际上,这里的节点是TS(路由器,交换机)和基本节点的节点,边缘是TS的通道。颜色编码分别表示质量下降的存在和这些下降的处理状态。
似乎很清楚,您可以工作,但是:
- 仅在TS拓扑本身非常简单的情况下(树或仅是串行连接,没有任何环网和替代路由),才能非常准确地解决直接问题(从服务到服务路径)。
- 逆问题可以在类似的条件下解决,但同时,在聚合级别和网络核心级别,原则上不可能解决此问题,因为 这些网段由动态路由协议控制,并具有许多潜在的替代路由。
另外,请记住,通常,网络拓扑要复杂得多(上面的片段用红色圆圈圈出):
这不是最小的部分-拓扑越来越复杂:
因此,此选项适合于对个案进行冥想分析,但绝不简化工作,而且不适用于自动化正向和反向解决方案。
第2部分。自动化v1.0
让我提醒您我们完成了哪些任务:
- 确定通过车辆的服务路径-直接任务。
- 从TC通道确定相关服务-反问题。
2.1。基站的运输服务
通常,从中央节点(控制器/网关)到BS的传输组织如下所示:
在聚合段和TS的核心上,通过MPLS网络的传输服务建立连接:L2 / L3 VPN,VLL。在访问段上,通常通过专用VLAN执行连接。
让我提醒您,我们有一个数据库,该数据库存储了车辆的所有实际(在一定时期内)参数和拓扑。
2.2。拨号段解决方案(访问)
我们获取有关BS逻辑接口的VLAN的数据,并逐步“遍历”链接,链接的端口包含此Vlan ID,直到到达边界路由器(MBN)。
为了解决这样一个简单的问题陈述,我最终不得不:
- 编写算法,用于通过聚合网络的通道逐步跟踪从BS传播的VlanID的“传播”
- 考虑现有的数据缺口。对于站点节点之间的关节尤其如此。
- 实际上,编写SPF算法是为了在末端丢弃不通向MVN路由器的死角分支。
该算法来自一个主要过程和七个子过程。实施和调试它需要3-4周的纯工作时间。
此外,我们得到了特别的荣幸...
2.2.1。SQL联接
由于其结构,用于遍历图的关系模型需要一种显式的递归方法,该方法具有在每个级别的联接操作,同时反复遍历同一组记录。反过来,这会导致系统性能下降,尤其是在大数据集上。
出于明显的原因,我无法在此处引用数据库查询的内容,而是进行评估-查询文本中的每个“ ledge”都是下一个表的连接,在这种情况下,获得Port和VlanID之间的统一对应关系是必需的:
该请求用于以统一的形式获取交换机内部的VlanID交叉连接:
考虑到端口数是数万个,而VLAN是10倍以上,因此所有这些都不愿意折腾。并且必须针对每个节点和VlanID发出此类请求。而且“立即卸载所有内容并进行计算”是不可能的,因为 它是取决于上一步结果的分步操作对路径c的顺序计算。
2.3。确定路由网段中的服务路径
在这里,我们从一家MVN供应商开始,该供应商的管理系统在MPLS网段上提供有关当前和备用LSP的数据。知道与访问连接的访问接口(L2 Vlan),就可以找到LSP,然后通过对NBI系统的一系列请求,获得LSP路径,该路径由路由器和它们之间的链接组成。
- 类似于交换网段,卸载MPLS服务的LSP路径的描述导致了一种算法,该算法已经具有17个子例程。
- 该解决方案仅适用于该供应商服务的细分市场
- 有必要确定MPLS服务之间的连接的定义(例如,在网段的中心有一个通用的VPLS服务,而EPIPE或L3VPN都与之分离)
我们为其他MVN供应商解决了这个问题,这些供应商没有控制系统,或者原则上他们没有提供有关当前LSP通道的数据。我们找到了几种解决方案,但是-通过路由器的LSP的数量不再是在交换机上注册的VanID的数量。“按需”延迟如此大量的数据(毕竟,我们需要操作信息)-存在使硬件崩溃的风险。
此外,还有其他问题:
- – , , . .. – MPLS .
- , LSP, . . .
2.4. .
必须将接收到的有关服务连接路径的数据记录在某处,以便稍后在解决正向和反向问题时可以参考它们。
立即排除了将数据存储在关系数据库中的可能性:是否很难汇总来自许多来源的数据,以便以后将其最终分类到下一组表中?这不是我们的方法。此外,请记住多层连接及其性能。
数据应包含有关服务的结构及其组件的依存关系的信息:链接,节点,端口等。
作为测试解决方案,选择了XML格式和Native-XML DB-Exist。
结果,每个服务都以以下格式写入数据库(为简洁起见,省略了详细信息):
<services>
<service>
<id>,<description> (, )
<source>
<target> Z
<<segment>> L2/L3
<topology> (, /, )
<<joints>> (, /, )
</service>
</services>
使用XPath协议对正负问题进行数据查询:
所有。现在系统正在运行-对于具有BS名称的请求,将返回通过传输网络进行连接的拓扑;对于具有TS节点和端口名称的请求,将返回依赖于该列表的BS列表。因此,我们得出以下结论...
2.5。
而不是第2部分的发现
2.5.1。对于交换网段(L2以太网交换机上的网络)
- 拓扑和端口-VlanID对应的完整数据是必需的。如果某个链接上没有VlanID数据,则算法停止,找不到路径
- 针对关系数据库的多级非生产性查询。当新的供应商出现其自己的详细信息,参数时-在工作的各个阶段添加请求
2.5.2。对于路由的网段
- 受MVN SU的功能限制,无法提供有关LSP MPLS服务拓扑的数据。
- – , .. LSP .
- LSP – ( , “” ).
2.5.3.
- , , , , ( – , ), , – .
- . 3-4 .
- , .. , MPLS .
- – , .
2.6. -
- , , .. – .
- , -
- (, VlanID)
在评估了实现愿望的可能选择之后,我们决定了可以提供所有这些“即开即用”的系统的类别-这就是所谓的。图形数据库。
尽管最后一句话看起来像是线性而简单的,但鉴于以前我们(以及事实证明,我们的IT专家都没有)曾经遇到过这样的数据库类,但他们还是偶然地做出了决定:提到了类似的数据库(但不了解)。特别是提到产品Neo4j... 从描述的角度来看,它不仅满足了我们所有的要求,而且还具有完全免费的功能社区版本。那些。-不是30天的试用期,不是切断主要功能,而是可以慢慢学习的功能全面的产品。图算法的广泛支持并未在选择中扮演最后一个角色(如果不是主要角色)。
第3部分。Neo4j中直接问题的实现示例
为了不拖累Neo4j图形数据库中TS模型的实现方式的线性叙述,我们将立即通过示例展示最终结果。
3.1。跟踪3G BS Iub接口的路径
服务路由沿两段运行-路由的MVN和交换的无线电中继线路(无线电中继站充当以太网交换机)。通过RRL段的路径以与第2部分中所述相同的方式确定-通过将BS接口VlanID沿着RRL段传递到MVN边界路由器。MVN网段将边界路由器(与RRL网段)连接-与BS控制器(RNC)连接到的路由器。
最初,根据Iub参数,我们确切地知道哪个MVN是BS的网关(边界MVN),以及哪个控制器由BS服务。
根据这些初始条件,我们将为每个段建立2个查询到数据库。对数据库的所有查询均以Cypher语言构建... 为了不被现在的描述分散注意力,请将其简单地认为是“ SQL for graphs”。
3.1.1。RRL段。VlanID路径
根据可用的VlanID和L2拓扑数据来跟踪服务路径的Cypher请求:
Cypher查询的片段
(通过构造-将查询的一个阶段的结果传递到下一个(处理的流水线)) |
中间查询结果(Neo4j控制台中的可视表示形式-“ Neo4j浏览器”) |
---|---|
获取将在其间搜索Iub服务路径的BS和MVN节点
|
|
接收BS接口Iub的Vlan节点
|
|
我们选择与BS在同一站点上的车辆节点,并在其端口上注册了VlanID Iub BS
|
|
使用Dijkstra的算法,我们找到了从基站站点TS的VlanID到边界MVN的最短路径
|
|
从Vlan链中,我们获得了节点,端口以及端口之间的连接的列表,最终,这将是将Iub服务从BS连接到边界路由器的方式
结果: |
|
|
如您所见,即使部分缺少数据,也已经获得了路径。在这种情况下,没有有关BS端口与无线电中继站端口的连接的信息。
3.1.2。RRL段。L2拓扑路径
假设在第3.1.1节中进行了尝试。由于VlanID参数上的数据完全或部分缺少而失败。换句话说,没有建立到达MVN节点的类似连续链:
然后,您可以尝试根据L2拓扑将服务连接定义为MVN的最短路径:
结果: |
|
如您所见,获得了相同的结果。这里,通过与BS之间的站点的对象(节点)的通信的传递来弥补关于BS与RRS的连接的信息的缺乏。当然,此方法的准确性会更低,因为 通常,Vlan可能不会沿Dijkstra算法假定的最短路径注册。但是该请求仅包含两个操作。
3.1.3 MVN段。跟踪从边界MVN到控制器的路径
在这里,我们还使用Dijkstra的算法。
一条路,成本最低
|
|
成本最低的前2条路径(主要+替代)
|
|
成本最低的前3条路径(主要+两种选择)
|
同样,在这种情况下,也没有有关MVN与RNC直接连接的信息。但这并不能阻止我们建立服务路径,即使算法假设了该路径(稍后会详细介绍)。
3.2。人工成本
现在显示的直接问题的实现与“开发算法,程序,存储和检索结果的方法”方法截然不同-归结为“将查询写入数据库”。展望未来,我们注意到从开发一个简单的图形模型,从关系数据库将数据加载到Neo4j,编写查询直到获得结果的整个过程总共花费了一天的时间。
3-4个月和1天!这是最终离开图形数据库的最后一个原因。
第4部分。图形数据库Neo4j并将数据加载到其中
4.1。关系数据库和图形数据库的比较
4.2。资料模型
直到L3拓扑级别的TS表示的基本模型:
当然,该模型比提出的模型更广泛,并且还包含MPLS服务和虚拟接口,但是为简单起见,我们将考虑其中的一部分。
在这种模型中,同一区域的两个网络元素之间的关系可以表示为:
4.3。加载数据中
我们从车辆的参数和拓扑数据库中加载数据。为了从SQL数据库加载到Neo4j中,使用了APOC库-apoc.load.jdbc,该库将RDBMS的连接字符串和SQL查询的文本作为输入,并返回一组通过CYHPER表达式映射到节点,链接或参数的字符串。对于每种类型的模型对象,逐层执行此类操作。
例如,用于加载/更新代表网络元素(节点)的节点的过程:
|
调用过程apoc.load.jdbc,
获取数据集 |
|
对于
按区域和站点代码从数据集中的每一行,将搜索 代表相应站点的节点 |
|
对于每个站点对象,将更新
关联的网络元素(节点)。 使用MERGE + SET指令 , 如果该对象已存在于数据库中,则更新该对象的参数;如果不存在 ,则创建该对象。还记录 节点节点的参数及其与PL节点的连接。 |
依此类推-在TS模型的所有级别上。
已更新字段用于控制列中数据的相关性-删除未超过特定时间段的对象将被删除。
第5部分。解决Neo4j中的逆问题
刚开始时,“服务跟踪”一词首先带来以下关联:
即,在给定时间直接跟踪服务的当前路径。
这不完全是图形数据库中的内容。在GDB中,根据确定每个涉及的网络元素中其配置 的对象之间的关系来跟踪服务。即,配置以图形模型的形式表示,并且结果跟踪是表示该配置的模型的传递。
由于与交换段不同,mpls段中的实际服务路由是由动态协议确定的,因此我们不得不接受一些...
5.1。路由段的假设
因为根据mpls服务的配置数据,无法确定通过动态路由协议控制的网段的确切路径(特别是如果使用流量工程的情况)-解决方案使用了Dijkstra算法。
是的,有一些管理系统可以通过NBI接口提供服务LSP的实际路径,但是到目前为止,我们只有一个这样的供应商,而MVN段中有不止一个供应商。
是的,在AS中有一些分析路由协议的系统,通过侦听IGP协议的交换,可以确定感兴趣前缀的当前路由。但是有这样的系统-像被击落的波音公司一样,并且考虑到这样的系统需要部署在同一移动井底的所有AS上-解决方案的成本以及所有许可证将是在完全加油时被与Angara火箭相连的铸铁桥击落的波音公司的成本。尽管存在这样的事实,但这样的系统并未完全解决使用BGP通过多个AS进行路由计费的问题。
因此-到目前为止。当然,我们为标准Dijkstra算法的条件添加了一些支持:
- 解释接口/端口的状态。断开连接的链接会增加成本,并且会转到可能的路径选项的末尾。
- 考虑备份链接状态。根据性能监视系统,分别计算了mpls通道中仅存在keepalive流量,这种通道的成本也增加了。
5.2。如何解决Neo4j中的逆问题
提醒。相反的任务是获得依赖于传输网络(TS)的特定信道或节点的服务列表。
5.2.1。交换L2段
对于交换路径,其中服务路径和服务配置实际上是相同的,仍然可以通过CYPHER请求解决问题。例如,对于从第3.1.1节中解决直接问题的结果进行的无线电中继飞行,我们将从无线电中继链路调制解调器发出请求-我们将“扩展”通过它的所有Vlan链:
match (tn:node {name:'RRN_29_XXXX_1'})-->(tn_port:port {name:'Modem-1'})-->(tn_vlan:vlan)
with tn, tn_vlan, tn_port
call apoc.path.spanningTree(tn_vlan,{relationshipFilter:"ptp_vlan>|v_ptp_vlan>", maxLevel:20}) yield path as pp
with tn_vlan,pp,nodes(pp)[-1] as last_node, tn_port
match (last_node)-[:vlan]->(:port)-->(n:node)
return pp, n, tn_port
红色节点表示我们要部署其Vlan的调制解调器。圈出了3个BS,结果导致带Modem1的过境Vlan的部署得以完成。
这种方法有几个问题:
- 对于端口,必须知道已配置的VLAN,并将其加载到模型中。
- 由于可能会出现碎片,因此Vlan链不会始终输出到终端节点
- 无法确定Vlan链中的最后一个节点是否属于终端节点,或者服务实际上是否继续。
也就是说,始终比在任意“中间”和一个OSI层中跟踪终端节点/其段的点之间的服务更为方便。
5.2.2。路由段
对于路由网段(如第5.1节所述),无需选择-没有办法根据某个中间MPLS链路当前配置的数据来解决逆问题-该配置未明确定义服务跟踪。
5.3。决断
该决定如下。
- 车辆模型的满载,包括BS和控制器
- 对于所有BS,解决了直接问题-跟踪Iub,S1服务从BS到边界MVN,然后从边界MVN到相应的控制器或网关。
- 跟踪结果以以下格式写入常规SQL数据库:BS名称-服务路径元素数组
因此,当使用条件TS或Node TS +端口访问数据库时,将返回服务列表(BS),其路径数组包含所需的Node或Node +端口。
第6部分。结果与结论
6.1。结果
结果,系统工作如下:
目前,要解决直接问题,即 在分析单个服务降级的原因时,开发了一个Web应用程序,该应用程序显示了Neo4j的跟踪结果(路径),以及有关路径各个部分的质量和性能的叠加数据。
为了获得依赖于TS的节点或通道的服务列表(反问题的解决方案),已经开发了用于外部系统(特别是Remedy)的API。
6.2。结论
- 两种解决方案都将服务质量和传输网络分析的自动化提高到了质的新水平。
- 此外,在存在有关BS服务路线的现成数据的情况下,就可以迅速为业务部门提供有关在特定站点包括B2B客户的技术可能性的数据(就路线的容量和质量而言)。
- Neo4j证明自己是解决网络图问题的非常强大的工具。该解决方案有据可查,并在各种开发人员社区中得到广泛支持,并且一直在不断开发和改进。
6.3。计划
我们有计划:
- Neo4j数据库中建模的技术领域的扩展
- 宽带服务跟踪算法的开发与实现
- 提高服务器平台性能
感谢您的关注!