发明内容
有鉴于此,本发明提供一种交换机,应用于IP监控网络中,其中所述网络包括位于同一个二层网络中管理服务器以及多个业务服务器,所述多个业务服务器使用相同IP以及相同虚拟MAC地址对外提供相同类型的业务服务,每个业务服务器均配置有实际MAC地址,其中所述多个业务服务器以及管理服务器均连接到所述交换机,该交换机包括:
配置接收单元,用于接收并保存管理服务器下发的业务归属标记以及与该业务归属标记唯一对应的业务服务器的实际MAC地址;
表项处理单元,用于使用所述业务服务器的实际MAC地址匹配交换机在本地学习到MAC地址转发表以生成业务归属转发表;其中所述业务归属转发表包括业务归属标记以及对应的出端口;
报文转发单元,用于在收到目的MAC地址为所述虚拟MAC地址的报文时,从该报文中获取业务归属标记,使用该业务归属标记查找所述业务归属转发表获得对应的出端口,并将报文通过该出端口转发给对应的业务服务器;
本发明还提供一种管理服务器,应用于IP监控网络中用于对监控业务进行管理,其中所述网络包括交换机以及多个与该交换机相连且使用相同IP以及相同虚拟MAC地址对外提供相同类型业务服务的业务服务器,每个业务服务器均配置有实际MAC地址且与所述管理服务器位于同一个二层网络;该管理服务器包括:
注册处理单元,用于接收业务服务器的注册请求,并将所述注册请求携带的该业务服务器的实际MAC地址保存在本地;
业务调度单元,用于在调度当前业务时,从多个同类型的业务服务器中调度出一个业务服务器处理当前业务,并将当前业务的业务归属标记以及的调度到的业务服务器的实际MAC地址下发给所述交换机,其中所述业务归属标记唯一对应于处理当前业务的业务服务器。
本发明通过适当的配置之后,可以允许用户根据业务的实际需要弹性地对MS等各种业务服务器进行扩容,并且扩容过程不需要占用新的IP地址资源,对网络中大部分节点来说都是透明的,避免了复杂的配置工作。
具体实施方式
本发明提出一种多方互相配合的解决方案来支撑用户监控网络中业务服务器的弹性扩容。在描述本发明较佳实现方式之前,为了方便本领域普通技术人员理解本发明的本质,在此先提出一些定义。本发明所说的业务节点包括所有参与监控业务过程的设备,比如说参与实况业务的编码设备、解码设备、媒体转发服务器(MS)、告警服务器(AM)、管理服务器(VM)。各个业务节点与IP网络中的交换机、路由器以及网络存储设备等基础设施一起构成整个IP监控网络。其中MS以及AM(未图示)在本发明中统称为业务服务器,它们在VM的管理和调度下对外提供对应的各种类型的监控业务服务。
所述MS主要提供媒体转发服务,比如图1中各种编码设备(编码器EC以及网络摄像机IPC)需要向解码设备发送实况视频流时,其可以在VM的调度下先将实况视频流发送给MS,MS再将实况视频流转发给解码设备。MS的存在可以允许编码设备在多个解码设备都需要点播其上同一个实况视频流时,仅仅只需要发送一份实况视频流,有效地减轻了编码设备的负担和节省了网络带宽。告警服务器主要提供收集编码设备等业务节点的告警消息以及转发告警消息的服务。由于本发明实现并不依赖于业务服务器的业务处理过程,因此以下仅仅以最为典型的MS扩容为例进行说明,其他类型的业务服务器的处理是相同的。
请参考图1,在本发明一种实施方式中,假设原来监控网络中只有MS1,MS2是用户在本次扩容过程中新增的业务服务器。本发明业务服务器扩容过程中涉及到VM、交换机(图1中的Switch,以下简称SW)的处理,MS、VM以及SW的硬件架构可以参考图2,其中业务硬件并不是必须的,比如VM通常就并不包括业务硬件。请参考图3以及图4,本实施方式中,SW在逻辑上包括配置接收单元、表项处理单元以及报文转发单元;VM在逻辑上包括注册处理单元以及业务调度单元。以下描述新业务服务器(MS2)上线到实际开始处理媒体转发业务的处理流程。
步骤101,MS2上线后在MS2上配置与MS1相同的IP地址以及虚拟MAC地址;
在现有技术中,MS2上线过程中会借助管理员手工配置或DHCP等方式获得IP地址,这个IP地址通常与MS1是不同的。在本发明中,MS2上配置的IP地址与MS1的相同(可以是手工配置也可以是通过各种协议来配置)。同时本发明还给MS1以及MS2分配一个虚拟MAC地址,这个虚拟MAC地址可以是管理员任意额外配置的一个MAC地址。MS1与MS2使用相同的IP地址,这意味着从IP层来看,MS1与MS2发送的报文会被其他业务节点当成同一个MS发送的报文,其他业务节点并无法感知到MS2的加入。从这一点上来说,本发明的扩容过程对网络中大部分的节点来说都是透明的,需要新增的配置工作非常少。
步骤102,MS1与MS2侦听到对方发送的免费ARP报文或ARP响应报文时,检查这些报文中携带的源MAC地址与源IP地址是否与自身配置的IP地址及虚拟MAC地址相同,如果相同则禁止自身发送免费ARP及ARP响应报文。MS1和MS2发送的ARP报文的源MAC地址和发送端MAC地址是配置的虚拟MAC地址。
由于MS1与MS2配置了相同的IP地址,如果不做处理意味着MS1与MS2之间会构成IP地址冲突,此时可以通过ARP抑制机制来避免IP地址冲突。任何一方侦听到对方的免费ARP或ARP响应,则自身不再发送免费ARP或ARP响应。这属于一种比较流行的规避IP地址冲突手段,具体过程不再一一详述。
步骤103,MS2向VM发起注册请求,并在注册请求报文中携带自身的实际MAC地址;VM的注册处理单元处理MS2的注册请求,如果MS2注册成功,注册处理单元将报文中携带的所述实际MAC地址保存在本地。
在监控网络中,各个业务节点上线后都需要向VM发起注册,注册成功后才能在VM的调度下展开各种监控业务。需要说明的是,在本实施方式中,MS1、MS2以及VM均在同一个二层网络中(比如同一个VLAN中),MS1、MS2以及VM互相交互时,MS1与MS2均可以使用自身的实际MAC地址。由于三者在同一个二层网络,因此通过MAC地址就可以准确地找到通信的对端,MS1与MS2的IP地址相同并不会影响到通信的过程。因此MS1或MS2上只要配置好业务通信的规则即可,比如MS1,MS2上可以先下发一个虚拟路由表,并将实际MAC地址以及虚拟MAC地址对应的二层接口作为该虚拟路由表的两个出接口,对于发送到特定目的IP地址(比如VM)的报文从实际MAC对应的二层接口发送,对于其他目的IP地址的报文从虚拟MAC地址对应的二层接口发送。
MS2注册成功后,对于VM来说其调度媒体转发资源的时候多了一个新的选择,因此VM此时可以针对媒体转发业务创建一个业务服务器列表,请参考表1示例。列表中MS的实际MAC地址会在进行业务调度中使用到。在现有技术中,由于监控网络是IP网络,调度都是在IP层面以上,而MAC地址属于IP层面以下的链路层,因此现有技术中并不需要用到MS的实际MAC地址,或者最多将MS的实际MAC地址作为MS的标识来使用,而本发明后续流程中会将MS的实际MAC地址通知到交换机用来指导交换机的转发决策。
MS标识 |
MS实际MAC地址 |
MS1 |
0A:0B:0C:10:11:12 |
MS2 |
0A:0B:0C:10:11:13 |
表1
步骤104,业务调度单元在对当前业务调度时,从MS1与MS2中调度出一个MS来对应处理当前业务,并将当前业务的业务归属标记以及调度到MS的实际MAC地址下发给所述SW。
以最为常见的实况业务为例,解码设备(比如VC)希望点播编码设备(比如EC)上的实况时,其会向VM发送实况点播请求,VM在接受其点播请求后,会调度MS处理资源。假设此时VM根据预定的负载分担的算法调度到MS2,VM向EC(IP地址为IP1)发出信令要求其将自身编码产生的实况视频流向MS2的IP地址(后续以IP2来表示,实际上也是MS1的IP地址)上发送。VM还会相应地向MS2发送信令要求其将EC发送的实况视频流转发给VC。VM在发送给EC的信令中还会将MS上开放的目的端口(Port1)告知EC。在本发明中并不改变上述信令交互流程,更为细节的信令过程不再介绍。不同于现有技术的是,在本发明中,VM在进行上述业务调度的时候,还会将当前业务中作为业务归属标记的EC的地址IP1和/或所述Port1以及MS2的实际MAC地址发送给SW。
步骤105,SW的配置接收单元接收并保存管理服务器下发的业务归属标记以及与该业务归属标记唯一对应的业务服务器的实际MAC地址;SW的表项处理单元使用MS2实际MAC地址去匹配SW在本地学习到的MAC地址转发表以生成业务归属转发表;其中所述业务归属转发表包括业务归属标记以及对应的出端口;
步骤106,SW的报文转发单元在接收到目的MAC地址为所述虚拟MAC地址的报文时,从该报文中获取业务归属标记,使用获取到的业务归属标记查找所述业务归属转发表,并通过查找到的对应的出端口将报文转发给与所述业务归属标记对应的MS(比如MS1或MS2)。
步骤104到步骤106是本发明VM与SW配合的过程。本发明的业务归属标记是用来表明当前业务(对于SW而言就是其要转发的报文)到底归属哪一台MS处理,是能够指导交换机进行正确的转发决策的标记。业务归属标记必须是业务报文中携带的信息,在优选的方式中选择报文头部的信息来充当业务归属标记。现在列举三个比较容易实现的方式来说明。
方式一:VM将以EC为单位进行实况业务调度,比如说EC1-10的发送实况视频流由MS1负责处理,EC11-20的发送实况视频流由MS2负责处理,由于每个EC的IP地址都不同,当EC1-10任意一个EC向MS发送实况视频流时,该EC发送的承载实况视频流的报文会经过SW,SW可以依据报文的源IP地址(也就是EC的IP地址)就可以确定当前报文到底归属哪个MS来处理。
方式二:VM通过指定MS上开放的目的端口进行实况业务调度,比如说VM规划了端口6000-6999是MS1接收视频流的端口(也就是开放给对端业务节点的目的端口),VM在调度MS的媒体转发资源时,可以将MS1的媒体转发资源分配给EC11-20,VM可以相应地将6000-6999这些端口分配给EC11-20,供其发送实况视频流使用。经由这样的安排之后,EC11-20发送的实况视频流将由MS1负责处理。由于VM每次进行业务调度时分配给EC的MS的端口号都不同,因此SW根据作为报文目的端口就可以确定当前报文到底归属哪个MS来处理。
方式三:在方式一和方式二中业务归属标记都是单个报文特征,这样对于VM的规划来说可能会不够灵活。比如说如果VM不能允许各个MS接收实况视频流的端口号发生重复,当MS扩容到数量较大时会引发端口号规划的困难。再比如说VM可能不允许EC的IP地址相同,但是EC可能位于NAT设备内部,那么不同EC自身IP地址虽然不同,但经过NAT转换后的源IP地址(会被外部认为是EC的IP地址)就可能会变成相同的IP地址了。因此方式三中,选用业务来源标记和业务目的标记组合作为业务归属标记,比如说,可以用报文的源IP地址(也就是EC的IP地址)以及目的端口(也就是MS接受实况视频流的端口)的组合作为业务归属标记。只要这个组合可以唯一指向一个MS,那么SW就有明确的转发依据。
如前所述,SW的配置接收单元收到VM下发的业务归属标记以及对应的MS的实际MAC地址之后,表项处理单元可以结合自身的MAC地址转发表生成业务归属转发表。表项处理单元可以使用MS实际MAC地址去匹配MAC地址转发表中的表项,从而找到与业务归属标记对应的出端口。请参考表2示例:
表2
有了业务归属转发表之后SW就可以正确地将归属于每个MS处理的报文正确转发给该MS。如前所述MS在二层网络内部通信时使用的是自身实际MAC地址,此时VM发送给MS的报文的目的MAC一定是该实际MAC地址。但是通过网关对外通信时使用的是虚拟MAC地址。因此交换机从网关侧收到的报文的目的MAC地址一定是所述虚拟MAC。图5将这两种通信过程进行分层展示。较粗的线条表示与外部业务节点发送报文到达MS的过程,较细的线条表示二层网络内部的其他节点发送报文到达MS的过程。
由于交换机的工作原理是使用学习生成MAC地址转发表,然后根据报文的目的MAC地址查找MAC地址转发表做转发。当网关侧发送的报文到达SW时,如果该报文的目的MAC地址是所述虚拟MAC地址,此时交换机如果还是按照现有的转发方式则可能会出错,因为MS1与MS2都是使用同样的虚拟MAC地址。当前报文可能是归属MS1处理的,但交换机MAC地址转发表中最新的学习结果是该虚拟MAC地址的出端口指向MS2,因此可能转发出错。
为了规避上述可能出错情况,本发明中,SW的表项处理单元可以向底层硬件下发ACL(访问控制列表),要求底层芯片将所有目的MAC地址为所述虚拟MAC地址的报文上送到软件层面的报文转发单元处理(也就是通常所说的上送CPU处理),当然前述ACL也可以由管理员事先来下发。此时交换机的报文转发单元从底层芯片上送的报文中获取报文的业务归属标记,利用业务归属标记从业务归属转发表中找到对应的出端口,然后将报文从查找到的出端口发送给对应的MS。在当前比较流行的实现方式中,表2中形成的业务归属转发表可以放在软件层面。当然也可以下发到硬件层面处理(可能需要定制相应的芯片)。
需要注意的是,由于交换机服务的主机很多,当ACL没有匹配到,报文会自然走到底层的硬件转发流程中去,此时可以按照现有的查找MAC地址转发表去处理。另外,当报文转发单元在业务归属转发表没有找到对应的出端口,此时可以将报文再送回硬件层面走正常的硬件转发流程。
通过以上的描述可以看出,本发明通过适当的配置之后,可以允许用户根据业务的实际需要弹性地对MS等各种业务服务器进行扩容,并且扩容过程不需要占用新的IP地址资源,对网络中大部分节点来说都是透明的,避免了复杂的配置工作。
以上所述,仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围,凡在本发明的精神和原则之内所做的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。