CN114866456A - 一种报文发送方法及装置 - Google Patents
一种报文发送方法及装置 Download PDFInfo
- Publication number
- CN114866456A CN114866456A CN202210431847.XA CN202210431847A CN114866456A CN 114866456 A CN114866456 A CN 114866456A CN 202210431847 A CN202210431847 A CN 202210431847A CN 114866456 A CN114866456 A CN 114866456A
- Authority
- CN
- China
- Prior art keywords
- port
- state
- message
- server
- egress
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 47
- 238000013507 mapping Methods 0.000 claims abstract description 40
- 238000001514 detection method Methods 0.000 claims description 119
- 230000004044 response Effects 0.000 claims description 51
- 230000005540 biological transmission Effects 0.000 claims description 24
- 238000012545 processing Methods 0.000 claims description 19
- 230000008569 process Effects 0.000 claims description 11
- 230000002159 abnormal effect Effects 0.000 abstract description 9
- 238000010586 diagram Methods 0.000 description 12
- 239000002699 waste material Substances 0.000 description 10
- 230000006870 function Effects 0.000 description 8
- 238000004590 computer program Methods 0.000 description 7
- 230000003287 optical effect Effects 0.000 description 3
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000001413 cellular effect Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Small-Scale Networks (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本申请提供一种报文发送方法及装置,该方法包括:在接收到目标报文后,利用目标报文的目的MAC地址查询多端口MAC表;其中,多端口MAC表包括服务器集群的集群MAC地址与多个出端口之间的映射关系,端口状态表包括多个出端口与多个服务器的内部状态之间的映射关系,且多端口MAC表中的出端口基于多个服务器的内部状态进行删除或者添加;若目的MAC地址与多端口MAC表中的集群MAC地址匹配,则从多端口MAC表中查询集群MAC地址对应的出端口;基于查询到的每个出端口,通过出端口发送目标报文。通过本申请的技术方案,能够根据每个服务器的内部状态自动调整多端口MAC表,从而避免报文复制给已异常的服务器,节省网络设备的内部链路带宽。
Description
技术领域
本申请涉及通信技术领域,尤其是涉及一种报文发送方法及装置。
背景技术
NLB(Network Load Balancing,网络负载均衡)可以应用于FTP(File TransferProtocol,文件传输协议)、WEB(万维网)、VPN(Virtual Private Network,虚拟专用网络)等应用场景,可以在网络负载均衡集群中部署多个服务器,这些服务器提供相同的功能,通过多个服务器的共同使用,能够提供网络可靠性,保证不间断工作,具有可伸缩性,当一台服务器出现问题,也不会影响其它服务器的正常运行,保证业务不间断,可以将大量连接平均分配给多个服务器。
为了实现负载均衡,需要将报文同时发送给多个服务器,由多个服务器对报文进行处理。为了将报文同时发送给多个服务器,通常是采用广播方式,即采用广播方式将报文同时发送给多个服务器。但是,在采用广播方式发送报文时,会将报文发送给除网络负载均衡集群中的服务器之外的其它设备,从而导致信息泄露,发送大量报文也会导致带宽浪费,占用大量的网络带宽资源。
发明内容
有鉴于此,本申请提供了一种报文发送方法及装置,用以解决现有技术中,发送大量报文会导致带宽浪费,占用大量网络带宽资源的问题。
本申请提供一种报文发送方法,应用于网络设备,所述网络设备包括与服务器集群包括的多个服务器对应的多个出端口;其中,所述网络设备包括多端口MAC表和端口状态表,所述方法包括:
在接收到目标报文后,利用所述目标报文的目的MAC地址查询所述多端口MAC表;其中,所述多端口MAC表包括所述服务器集群的集群MAC地址与多个出端口之间的映射关系,所述端口状态表包括多个出端口与所述多个服务器的内部状态之间的映射关系,且所述多端口MAC表中的出端口基于所述多个服务器的内部状态进行删除或者添加;
若所述目的MAC地址与所述多端口MAC表中的所述集群MAC地址匹配,则从所述多端口MAC表中查询所述集群MAC地址对应的出端口;
基于查询到的每个出端口,通过所述出端口发送所述目标报文。
可选地,在一种可能的实施方式中,基于所述多个服务器的内部状态,对所述多端口MAC表中的出端口进行删除或者添加的过程,包括:
针对所述端口状态表中的每个出端口,若该出端口对应的服务器的内部状态是正常状态,则基于第一发送周期,通过该出端口发送检测报文;
若在第一预设时长内未接收到针对所述检测报文的响应报文,则将所述端口状态表中的该出端口对应的服务器的内部状态从正常状态更新为故障状态;
在将所述端口状态表中的该出端口对应的服务器的内部状态从正常状态更新为故障状态之后,则从所述多端口MAC表中删除该出端口。
可选地,在一种可能的实施方式中,基于所述多个服务器的内部状态,对所述多端口MAC表中的出端口进行删除或者添加的过程,包括:
针对所述端口状态表中的每个出端口,若该出端口对应的服务器的内部状态是故障状态,则基于第二发送周期,通过该出端口发送检测报文;
若在第二预设时长内接收到针对所述检测报文的响应报文,则将所述端口状态表中的该出端口对应的服务器的内部状态从故障状态更新为正常状态;
在将所述端口状态表中的该出端口对应的服务器的内部状态从故障状态更新为正常状态之后,则在所述多端口MAC表中添加该出端口;
其中,所述第二发送周期大于或等于所述第一发送周期。
可选地,在一种可能的实施方式中,所述方法还包括:
针对所述集群MAC地址对应的出端口,若感知到该出端口对应的服务器的目标端口从正常状态切换为故障状态,则从所述端口状态表中删除该出端口与该服务器的内部状态的映射关系,并从所述多端口MAC表中删除该出端口;
针对所述集群MAC地址对应的出端口,若感知到该出端口对应的服务器的目标端口从故障状态切换为正常状态,则在所述端口状态表中添加该出端口与该服务器的内部状态的映射关系,并在所述多端口MAC表中添加该出端口;
其中,所述目标端口是该服务器上与该出端口连接的端口。
可选地,在一种可能的实施方式中,每个出端口对应的检测报文包括所述集群MAC地址、该出端口的端口标识和标记字段,且所述标记字段的取值为第一取值;所述通过该出端口发送检测报文之后,所述方法还包括:
在通过该出端口接收到报文后,若该报文包括所述集群MAC地址、端口标识和标记字段,且该端口标识与该出端口的端口标识相同,所述标记字段的取值为第二取值,则确定接收到所述检测报文的响应报文。
本申请提供一种报文发送装置,应用于网络设备,所述网络设备包括与服务器集群包括的多个服务器对应的多个出端口;其中,所述网络设备包括多端口MAC表和端口状态表,所述装置包括:
处理模块,用于在接收到目标报文后,利用所述目标报文的目的MAC地址查询所述多端口MAC表;其中,所述多端口MAC表包括所述服务器集群的集群MAC地址与多个出端口之间的映射关系,所述端口状态表包括多个出端口与所述多个服务器的内部状态之间的映射关系,且所述多端口MAC表中的出端口基于所述多个服务器的内部状态进行删除或者添加;
查询模块,用于若所述目的MAC地址与所述多端口MAC表中的集群MAC地址匹配,则从所述多端口MAC表中查询所述集群MAC地址对应的出端口;
发送模块,用于基于查询到的每个出端口,通过所述出端口发送目标报文。
可选地,在一种可能的实施方式中,所述处理模块基于所述多个服务器的内部状态,对所述多端口MAC表中的出端口进行删除或者添加时具体用于:
针对所述端口状态表中的每个出端口,若该出端口对应的服务器的内部状态是正常状态,则基于第一发送周期,通过该出端口发送检测报文;
若在第一预设时长内未接收到针对所述检测报文的响应报文,则将所述端口状态表中的该出端口对应的服务器的内部状态从正常状态更新为故障状态;
在将所述端口状态表中的该出端口对应的服务器的内部状态从正常状态更新为故障状态之后,则从所述多端口MAC表中删除该出端口。
可选地,在一种可能的实施方式中,所述处理模块基于所述多个服务器的内部状态,对所述多端口MAC表中的出端口进行删除或者添加时具体用于:
针对所述端口状态表中的每个出端口,若该出端口对应的服务器的内部状态是故障状态,则基于第二发送周期,通过该出端口发送检测报文;
若在第二预设时长内接收到针对所述检测报文的响应报文,则将所述端口状态表中的该出端口对应的服务器的内部状态从故障状态更新为正常状态;
在将所述端口状态表中的该出端口对应的服务器的内部状态从故障状态更新为正常状态之后,则在所述多端口MAC表中添加该出端口;
其中,所述第二发送周期大于或等于所述第一发送周期。
可选地,在一种可能的实施方式中,
所述处理模块,还用于针对所述集群MAC地址对应的出端口,若感知到该出端口对应的服务器的目标端口从正常状态切换为故障状态,则从所述端口状态表中删除该出端口与该服务器的内部状态的映射关系,并从所述多端口MAC表中删除该出端口;针对所述集群MAC地址对应的出端口,若感知到该出端口对应的服务器的目标端口从故障状态切换为正常状态,则在所述端口状态表中添加该出端口与该服务器的内部状态的映射关系,并在所述多端口MAC表中添加该出端口;其中,所述目标端口是该服务器上与该出端口连接的端口。
可选地,在一种可能的实施方式中,每个出端口对应的检测报文包括所述集群MAC地址、该出端口的端口标识和标记字段,且所述标记字段的取值为第一取值;所述处理模块通过该出端口发送检测报文之后还用于:
在通过该出端口接收到报文后,若该报文包括所述集群MAC地址、端口标识和标记字段,且该端口标识与该出端口的端口标识相同,所述标记字段的取值为第二取值,则确定接收到所述检测报文的响应报文。
由以上技术方案可见,本申请实施例中,网络负载均衡集群中部署多个服务器时,多个服务器可以对应同一集群MAC(Media Access Control,介质访问控制)地址,对于网络设备上与多个服务器对应的多个出端口,可以将多个出端口添加到多端口MAC表,即在网络设备维护多端口MAC表,多端口MAC表包括集群MAC地址与多个出端口的映射关系。这样,在接收到目标报文之后,若目标报文的目的MAC地址与多端口MAC表中的集群MAC地址匹配,就可以通过集群MAC地址对应的多个出端口发送目标报文,从而将目标报文发送给网络负载均衡集群中的多个服务器,避免采用广播方式发送目标报文,避免将目标报文发送给除网络负载均衡集群中的服务器之外的其它设备,从而避免信息泄露,避免带宽浪费,节约网络带宽资源。网络设备还可以维护端口状态表,该端口状态表包括多个出端口与多个服务器的内部状态的映射关系,在某个出端口对应的服务器的内部状态从正常更新为故障时,则从多端口MAC表中删除该出端口,从而避免将目标报文发送给这个服务器,避免造成带宽浪费。在某个出端口对应的服务器的内部状态从故障更新为正常时,则在多端口MAC表中添加出端口,从而能够将目标报文发送给这个服务器,恢复报文发送。能够动态调整多端口MAC表中的出端口,实时根据每个服务器的内部状态自动调整多端口MAC表,避免报文复制给已异常的服务器,节省网络设备的内部链路带宽。
附图说明
为了更加清楚地说明本申请实施例或者现有技术中的技术方案,下面将对本申请实施例或者现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请中记载的一些实施例,对于本领域普通技术人员来讲,还可以根据本申请实施例的这些附图获得其他的附图。
图1A和图1B是本申请一种实施方式中的应用场景示意图;
图2是本申请一种实施方式中的报文发送方法的流程示意图;
图3是本申请一种实施方式中的报文发送方法的流程示意图;
图4是本申请一种实施方式中的报文发送装置的结构示意图;
图5是本申请一种实施方式中的网络设备的硬件结构图。
具体实施方式
在本申请实施例使用的术语仅仅是出于描述特定实施例的目的,而非限制本申请。本申请和权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其它含义。还应当理解,本文中使用的术语“和/或”是指包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本申请实施例可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本申请范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,此外,所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
网络负载均衡可以应用于FTP、WEB、VPN等应用场景,可以在网络负载均衡集群(即NLB集群)中部署多个服务器,这些服务器提供相同功能,通过多个服务器的共同使用,能够提供网络可靠性,保证不间断工作,具有可伸缩性,当一台服务器出现问题,也不会影响其它服务器的正常运行,保证业务不间断运行,可以将大量连接平均分配给多个服务器,实现负载均衡。
为了实现负载均衡,需要将报文同时发送给多个服务器,由多个服务器对报文进行处理。为了将报文同时发送给多个服务器,本实施例中,可以配置集群MAC地址,网络负载均衡集群中的多个服务器对应该集群MAC地址,该集群MAC地址是单播MAC地址,即多个服务器对应同一个单播MAC地址。
示例性的,网络设备可以维护多端口MAC表,多端口MAC表也可以称为多端口单播MAC地址表,对于网络设备上与多个服务器对应的多个出端口,可以将多个出端口添加到多端口MAC表,即,在多端口MAC表中记录集群MAC地址与多个出端口的映射关系,也就是说,通过多端口MAC表将多个出端口与集群MAC地址进行绑定,从而能够将目的MAC地址是集群MAC地址的报文通过多个出端口复制转发出去,即通过多个出端口将报文发送给多个服务器。
参见图1A所示,在网络负载均衡集群的单播模式下,可以在网络负载均衡集群(也可以称为服务器集群)内部署至少两个服务器,图1A是以3个服务器(如服务器11、服务器12、服务器13)为例,在实际应用中,服务器的数量可以更多,对此不做限制,所有服务器使用同一个MAC地址,该MAC地址为集群MAC地址,显然,针对集群MAC地址的报文能够发送到每一服务器。
参见图1A所示,网络设备14(网络设备14可以是路由器或者交换机等,对此不做限制)上与服务器11对应的出端口是出端口141,即,网络设备14通过出端口141与服务器11连接,网络设备14上与服务器12对应的出端口是出端口142,网络设备14上与服务器13对应的出端口是出端口143。
参见表1所示,为多端口MAC表的一个示例,多端口MAC表用于记录集群MAC地址与多个出端口的映射关系,当然,除了记录集群MAC地址和多个出端口,多端口MAC表也可以记录其它内容,对此不做限制。在表1中,MAC地址aaa表示网络负载均衡集群内的所有服务器对应的集群MAC地址。
表1
网络设备14接收到报文后,通过报文的目的MAC地址查询表1所示的多端口MAC表,若报文的目的MAC地址是MAC地址aaa,则确定报文的目的MAC地址与多端口MAC表中的集群MAC地址匹配,从多端口MAC表中查询到与该MAC地址aaa对应的多个出端口,如出端口141、出端口142和出端口143。通过查询到的多个出端口发送报文,即通过出端口141将报文发送给网络负载均衡集群中的服务器11,通过出端口142将报文发送给网络负载均衡集群中的服务器12,通过出端口143将报文发送给网络负载均衡集群中的服务器13。
综上所述,通过多端口MAC表将多个出端口与集群MAC地址进行绑定,网络设备14就能够将目的MAC地址是集群MAC地址的报文通过多个出端口复制转发出去,从而通过多个出端口将报文同时发送给多个服务器。
参见图1A所示,为了通过多个出端口将报文发送给多个服务器,报文会在网络设备14内部被复制三份,需要占用网络设备14内部的带宽为3份,即一份报文通过出端口141被发送给服务器11,另一份报文被通过出端口142发送给服务器12,另一份报文被通过出端口143发送给服务器13。
在一种可能的实施方式中,当网络负载均衡集群中的某服务器(如服务器11)出现内部故障,但是,该服务器11的端口状态保持不变(即端口仍然处于UP状态,而不是处于DOWN状态,表示端口正常未故障),那么,网络设备14将无法感知到服务器11的内部故障。网络设备14在发送报文时,若报文的目的MAC地址是MAC地址aaa,则仍然需要通过出端口141、出端口142和出端口143发送报文。但是,由于服务器11存在内部故障,导致服务器11无法对报文进行正常处理,即内部故障导致无法对报文进行正常处理时,报文复制过程依然占用网络设备14的内部带宽,造成带宽资源浪费,参见图1B所示。
示例性的,服务器出现内部故障是指:服务器出现无法正常处理报文的故障,但这个故障不会导致端口异常(即端口仍然处于UP状态,而不是处于DOWN状态),如某个服务被挂起、协议栈故障等,对此内部故障的类型不做限制。
针对上述发现,本申请实施例中,网络设备14还可以维护端口状态表,该端口状态表可以包括多个出端口与多个服务器的内部状态之间的映射关系,服务器的内部状态可以是正常状态或者故障状态。其中,当服务器的内部状态是正常状态时,则说明服务器未出现内部故障,而当服务器的内部状态是故障状态时,则说明服务器出现内部故障(即服务器出现无法正常处理报文,服务器的端口未异常)。在初始状态下,每个服务器的内部状态均可以是正常状态。
参见表2所示,为端口状态表的一个示例,该端口状态表也可以称为服务器状态表,该端口状态表用于记录多个出端口与多个服务器的内部状态之间的映射关系,多个服务器是网络负载均衡集群中的服务器,多个出端口是网络设备14上与多个服务器对应的多个出端口。当然,除了记录多个出端口与多个服务器的内部状态,该端口状态表也可以记录其它内容,对此不做限制。
表2
出端口 | 服务器的内部状态 |
出端口141 | 正常状态 |
出端口142 | 正常状态 |
出端口143 | 正常状态 |
参见表2所示,与出端口141连接的服务器的内部状态是正常状态,与出端口142连接的服务器的内部状态是正常状态,与出端口143连接的服务器的内部状态是正常状态。
基于该端口状态表,在该端口状态表中的出端口对应的服务器的内部状态从正常状态更新为故障状态时,网络设备14可以从多端口MAC表中删除该出端口,从而避免将报文发送给这个出端口对应的服务器,避免造成带宽浪费,避免网络设备14的内部带宽浪费。在该端口状态表中的出端口对应的服务器的内部状态从故障状态更新为正常状态时,网络设备14可以在多端口MAC表中添加该出端口,从而能够将报文发送给这个出端口对应的服务器,恢复报文发送。上述方式能够动态调整多端口MAC表中的出端口,实时根据每个服务器的内部状态自动调整多端口MAC表,避免报文复制给已异常(即已内部故障)的服务器,节省网络设备的内部链路带宽。上述方式能够自动停止某个出端口的报文发送(即服务器存在内部故障时自动停止),也能够自动恢复某个出端口的报文发送(即服务器的内部故障恢复时自动发送)。
在一种可能的实施方式中,在出端口对应的服务器的内部状态从正常状态更新为故障状态时,网络设备14从多端口MAC表中删除该出端口,该过程可以包括:针对端口状态表中的每个出端口,若该出端口对应的服务器的内部状态是正常状态,则基于第一发送周期,通过该出端口发送检测报文;若在第一预设时长内未接收到针对该检测报文的响应报文,则将端口状态表中的该出端口对应的服务器的内部状态从正常状态更新为故障状态;在将端口状态表中的该出端口对应的服务器的内部状态从正常状态更新为故障状态之后,则可以从多端口MAC表中删除该出端口。
示例性的,网络设备14在连续发送K个检测报文之后,若针对每个检测报文,在第一预设时长内均未接收到针对该检测报文的响应报文,才将端口状态表中的服务器的内部状态从正常状态更新为故障状态。K为正整数,可以根据经验配置,对此不做限制,如K可以为1、2、3、4等,后续以3为例进行说明。
示例性的,第一发送周期可以根据经验配置,对此不做限制,比如说,可以在每个第一发送周期发送1个检测报文,在该情况下,第一发送周期可以为10秒钟、15秒钟、20秒钟等,对此不做限制。又例如。可以在每个第一发送周期发送K个检测报文,在该情况下,第一发送周期可以为3分钟、5分钟、8分钟等,后续以5分钟为例进行说明,即每隔5分钟发送K个检测报文。
示例性的,第一预设时长可以根据经验配置,对此不做限制,如第一预设时长可以为3秒钟、5秒钟、10秒钟等,后续以3秒钟为例进行说明。
针对端口状态表中的出端口141,出端口141对应的服务器的内部状态是正常状态,基于第一发送周期,网络设备14每隔5分钟通过出端口141发送3个检测报文(如针对每个5分钟,在第0秒发送1个检测报文,在第10秒发送1个检测报文,在第20秒发送1个检测报文,其它时间可以不发送检测报文)。若针对每个检测报文,网络设备14在第一预设时长内均接收到针对该检测报文的响应报文,则保持出端口141对应的服务器的内部状态是正常状态。
针对端口状态表中的出端口142,服务器的内部状态是正常状态,网络设备14每隔5分钟通过出端口142发送3个检测报文。若连续发送3个检测报文之后,针对至少一个检测报文,网络设备14在第一预设时长内接收到针对该检测报文的响应报文,则保持出端口142对应的服务器的内部状态是正常状态。
针对端口状态表中的出端口143,服务器的内部状态是正常状态,网络设备14每隔5分钟通过出端口143发送3个检测报文。若在连续发送3个检测报文之后,网络设备14在第一预设时长内均未接收到针对该检测报文的响应报文,则将出端口143对应的服务器的内部状态从正常状态更新为故障状态,参见表3所示。
表3
出端口 | 服务器的内部状态 |
出端口141 | 正常状态 |
出端口142 | 正常状态 |
出端口143 | 故障状态 |
示例性的,在将出端口143对应的服务器的内部状态从正常状态更新为故障状态之后,网络设备14还可以从多端口MAC表中删除出端口143,参见表4所示。从表4可以看出,MAC地址aaa对应的出端口中已去除出端口143。
表4
显然,基于表4所示的多端口MAC表,网络设备14接收到报文后,通过报文的目的MAC地址查询表4所示的多端口MAC表,若报文的目的MAC地址是MAC地址aaa,则从多端口MAC表中查询到出端口141和出端口142,并通过出端口141和出端口142发送报文,而不会通过出端口143发送报文。
综上所述,在某个出端口对应的服务器的内部状态从正常状态更新为故障状态时,网络设备14可以从多端口MAC表中删除该出端口,从而避免将报文发送给这个出端口对应的服务器,避免造成带宽浪费,避免网络设备14的内部带宽浪费。
在一种可能的实施方式中,在出端口对应的服务器的内部状态从故障状态更新为正常状态时,则网络设备14在多端口MAC表中添加该出端口,该过程可以包括:针对端口状态表中的每个出端口,若该出端口对应的服务器的内部状态是故障状态,则基于第二发送周期,通过该出端口发送检测报文;若在第二预设时长内接收到针对该检测报文的响应报文,则将端口状态表中的该出端口对应的服务器的内部状态从故障状态更新为正常状态;在将端口状态表中的该出端口对应的服务器的内部状态从故障状态更新为正常状态之后,则在多端口MAC表中添加该出端口;其中,该第二发送周期可以大于或等于该第一发送周期。
示例性的,网络设备14在发送检测报文之后,若在第二预设时长内未接收到针对该检测报文的响应报文,则继续保持端口状态表中的服务器的内部状态是故障状态。或者,若在第二预设时长内接收到针对该检测报文的响应报文,则可以将端口状态表中的服务器的内部状态从故障状态更新为正常状态。
示例性的,第二发送周期可以根据经验配置,对此不做限制,比如说,可以在每个第二发送周期发送1个检测报文,第二发送周期可以为10分钟、15分钟、20分钟等,后续以20分钟为例进行说明。在实际应用中,第二发送周期可以大于第一发送周期,其原因是:在服务器的内部状态为故障状态时,需要对服务器的故障进行修复,而故障修复过程通常需要比较长的时间,因此,可以将第二发送周期设置的长一些,即第二发送周期可以大于第一发送周期。
示例性的,第二预设时长可以根据经验配置,对此不做限制,如第二预设时长可以为3秒钟、5秒钟、10秒钟等,后续以3秒钟为例进行说明。
参见表3所示,针对端口状态表中的出端口141,由于服务器的内部状态是正常状态,因此,基于第一发送周期,网络设备14每隔5分钟通过出端口141发送3个检测报文。针对端口状态表中的出端口142,由于服务器的内部状态是正常状态,因此,网络设备14每隔5分钟通过出端口142发送3个检测报文。
针对端口状态表中的出端口143,服务器的内部状态是故障状态,因此,基于第二发送周期,网络设备14每隔20分钟通过出端口143发送1个检测报文。若在发送检测报文之后,网络设备14在第二预设时长内未接收到针对该检测报文的响应报文,则可以保持出端口143对应的服务器的内部状态是故障状态。若网络设备14在第二预设时长内接收到针对该检测报文的响应报文,则可以将出端口143对应的服务器的内部状态从故障状态更新为正常状态,参见表2所示。
示例性的,在将出端口143对应的服务器的内部状态从故障状态更新为正常状态之后,网络设备14还可以在多端口MAC表中添加出端口143,参见表1所示。从表1可以看出,MAC地址aaa对应的出端口中已添加出端口143。
显然,基于表1所示的多端口MAC表,在接收到报文后,通过报文的目的MAC地址查询表1所示的多端口MAC表,若报文的目的MAC地址是MAC地址aaa,则从多端口MAC表中查询到出端口141、出端口142和出端口143,并通过出端口141、出端口142和出端口143发送报文,即恢复通过出端口143发送报文。
综上所述,在出端口对应的服务器的内部状态从故障状态更新为正常状态时,可以在多端口MAC表中添加该出端口,从而将报文发送给服务器,恢复报文发送。
在一种可能的实施方式中,为了在网络设备与服务器之间交互检测报文和响应报文,可以定义检测报文和响应报文的消息格式,检测报文和响应报文用于确认服务器集群内各个服务器的内部状态,然后根据各个服务器的内部状态维护端口状态表,利用此端口状态表来指导网络设备14更新多端口MAC表。
示例性的,在检测报文和响应报文中,可以包括但不限于以下字段的至少一个:源MAC、目的MAC、组播MAC地址、标记字段、时间戳、端口标识。
其中,针对检测报文来说,源MAC是网络设备14的设备MAC地址。目的MAC是协议MAC地址,可以启用保留MAC。组播MAC地址是多个服务器共同使用的集群MAC地址,表示检测报文用于对该集群MAC地址对应的各服务器的内部状态进行检测。标记字段的取值为第一取值,第一取值用于表示报文是从网络设备到服务器。时间戳表示网络设备14发送检测报文时的发送时间戳,服务器可以基于该时间戳对检测报文的合法性进行校验。端口标识是出端口的标识,如通过出端口141发送检测报文时,端口标识是出端口141的标识。
其中,针对响应报文来说,源MAC是服务器的设备MAC地址。目的MAC是协议MAC地址,可以启用保留MAC。组播MAC地址是多个服务器共同使用的集群MAC地址。标记字段的取值为第二取值,第二取值用于表示报文是从服务器到网络设备。时间戳表示服务器发送响应报文时的发送时间戳,网络设备可以基于该时间戳对响应报文的合法性进行校验。端口标识是出端口的标识。
示例性的,网络设备14在通过某个出端口(以出端口141为例)周期性发送检测报文时,该检测报文可以包括集群MAC地址(如MAC地址aaa)、该出端口的端口标识(如出端口141的标识)和标记字段,且该标记字段的取值为第一取值。该检测报文还可以携带源MAC、目的MAC、时间戳等字段。
服务器11在接收到该检测报文之后,若确定该检测报文携带集群MAC地址(如MAC地址aaa)和标记字段,且该标记字段的取值为第二取值,则将当前报文确定为检测报文,并向网络设备14发送针对该检测报文的响应报文。否则,当前报文不是检测报文,也不需要返回针对该检测报文的响应报文。
其中,服务器11还可以比较检测报文中的时间戳(即发送时间戳)与服务器11接收到检测报文的接收时间戳,若发送时间戳与接收时间戳不匹配,如发送时间戳大于接收时间戳,则丢弃该检测报文,不再向网络设备14发送针对该检测报文的响应报文。若发送时间戳与接收时间戳匹配,如发送时间戳小于接收时间戳,则允许向网络设备14发送针对该检测报文的响应报文。
服务器11向网络设备14发送针对检测报文的响应报文时,响应报文可以包括集群MAC地址(如MAC地址aaa)、出端口的端口标识(如出端口141的标识,该端口标识是服务器11从检测报文中得到)和标记字段,且标记字段的取值为第二取值。检测报文还可以携带源MAC、目的MAC、时间戳等字段。
网络设备14在通过某个出端口(如出端口141)接收到报文后,若该报文包括集群MAC地址(如MAC地址aaa)、端口标识和标记字段,且该报文携带的端口标识与该出端口141的端口标识相同,且该标记字段的取值为第二取值,则网络设备14可以将该报文确定为针对检测报文的响应报文。否则,如该报文携带的端口标识与该出端口141的端口标识不同,或该标记字段的取值不为第二取值,网络设备14确定该报文不是针对检测报文的响应报文。
其中,网络设备14还可以比较响应报文中的时间戳(即发送时间戳)与网络设备14接收到响应报文的接收时间戳,若发送时间戳与接收时间戳不匹配,如发送时间戳大于接收时间戳,则丢弃该响应报文,即网络设备14确定未接收到针对检测报文的响应报文。若发送时间戳与接收时间戳匹配,如发送时间戳小于接收时间戳,则网络设备14确定接收到针对检测报文的响应报文。
在一种可能的实施方式中,针对集群MAC地址对应的出端口,若感知到该出端口对应的服务器的目标端口从正常状态切换为故障状态,则网络设备14可以从端口状态表中删除该出端口与该服务器的内部状态的映射关系,并从多端口MAC表中删除该出端口。此外,针对集群MAC地址对应的出端口,若感知到该出端口对应的服务器的目标端口从故障状态切换为正常状态,则在端口状态表中添加该出端口与该服务器的内部状态的映射关系,并在多端口MAC表中添加该出端口。示例性的,目标端口可以是该服务器上与该出端口连接的端口。
示例性的,当服务器出现外部故障时,这个故障会导致端口异常(即端口处于DOWN状态),当服务器的端口出现异常时,网络设备14上与该服务器连接的出端口也会出现异常,因此,网络设备14能够感知到该出端口对应的服务器的目标端口从正常状态切换为故障状态(即从UP状态切换为DOWN状态)。
当服务器的外部故障恢复时,这个故障恢复会导致端口处于正常状态(即端口处于UP状态),当服务器的端口处于正常状态时,网络设备14上与该服务器连接的出端口也会处于正常状态,因此,网络设备14能够感知到该出端口对应的服务器的目标端口从故障状态切换为正常状态(即从DOWN状态切换为UP状态)。
若出端口对应的服务器的目标端口从正常状态切换为故障状态,从端口状态表中删除该出端口与服务器的内部状态的映射关系,从多端口MAC表中删除该出端口。若出端口对应的服务器的目标端口从故障状态切换为正常状态,在端口状态表中添加出端口与该服务器的内部状态的映射关系,在多端口MAC表中添加该出端口。
比如说,若网络设备14感知到出端口141对应的服务器11的目标端口从正常状态切换为故障状态,则网络设备14从端口状态表中删除出端口141与服务器11的内部状态的映射关系,并从多端口MAC表中删除出端口141。
又例如,若网络设备14感知到出端口141对应的服务器11的目标端口从故障状态切换为正常状态,则网络设备14在端口状态表中添加出端口141与服务器11的内部状态的映射关系,并在多端口MAC表中添加出端口141。
参见上述应用场景,服务器集群包括多个服务器,多个服务器共用同一集群MAC地址,网络设备包括与多个服务器对应的多个出端口。网络设备包括多端口MAC表和端口状态表,多端口MAC表包括集群MAC地址与多个出端口的映射关系,端口状态表包括多个出端口与多个服务器的内部状态的映射关系。
在上述应用场景下,本申请实施例提出一种报文发送方法,该方法可以应用于网络设备,参见图2所示,为该方法的流程示意图,该方法可以包括:
步骤201、在接收到目标报文后,通过目标报文的目的MAC地址查询多端口MAC表。比如说,网络设备14在接收到客户端发送的目标报文后,可以从该目标报文中解析出目的MAC地址,通过目的MAC地址查询多端口MAC表。
步骤202、若目的MAC地址与多端口MAC表中的集群MAC地址匹配,则从多端口MAC表中查询该集群MAC地址对应的出端口。
比如说,若目标报文的目的MAC地址是MAC地址aaa,则可以确定目的MAC地址与多端口MAC表中的集群MAC地址匹配,因此,网络设备14可以从多端口MAC表中查询该集群MAC地址对应的出端口。参见表1所示,该集群MAC地址对应的出端口可以是出端口141、出端口142和出端口143。参见表4所示,该集群MAC地址对应的出端口可以是出端口141和出端口142。
步骤203、基于查询到的每个出端口,通过该出端口发送目标报文。
比如说,若该集群MAC地址对应的出端口是出端口141、出端口142和出端口143,则网络设备14可以通过出端口141发送目标报文,即将目标报文发送给服务器11,并通过出端口142发送目标报文,即将目标报文发送给服务器12,并通过出端口143发送目标报文,即将目标报文发送给服务器13。
又例如,若该集群MAC地址对应的出端口是出端口141和出端口142,则网络设备14可以通过出端口141发送目标报文,即将目标报文发送给服务器11,并通过出端口142发送目标报文,即将目标报文发送给服务器12。
由以上技术方案可见,本申请实施例中,网络负载均衡集群中部署多个服务器时,多个服务器可以对应同一集群MAC地址,对于网络设备上与多个服务器对应的多个出端口,可以将多个出端口添加到多端口MAC表,即在网络设备维护多端口MAC表,多端口MAC表包括集群MAC地址与多个出端口的映射关系。这样,在接收到目标报文之后,若目标报文的目的MAC地址与多端口MAC表中的集群MAC地址匹配,就可以通过集群MAC地址对应的多个出端口发送目标报文,从而将目标报文发送给网络负载均衡集群中的多个服务器,避免采用广播方式发送目标报文,避免将目标报文发送给除网络负载均衡集群中的服务器之外的其它设备,从而避免信息泄露,避免带宽浪费,节约网络带宽资源。网络设备还可以维护端口状态表,该端口状态表包括多个出端口与多个服务器的内部状态的映射关系,在某个出端口对应的服务器的内部状态从正常更新为故障时,则从多端口MAC表中删除该出端口,从而避免将目标报文发送给这个服务器,避免造成带宽浪费。在某个出端口对应的服务器的内部状态从故障更新为正常时,则在多端口MAC表中添加出端口,从而能够将目标报文发送给这个服务器,恢复报文发送。能够动态调整多端口MAC表中的出端口,实时根据每个服务器的内部状态自动调整多端口MAC表,避免报文复制给已异常的服务器(如存在内部故障的服务器),节省网络设备的内部链路带宽。
以下结合具体应用场景,对本申请实施例的上述技术方案进行说明。
本实施例中,网络设备14维护多端口MAC表,多端口MAC表也称为多端口单播MAC组(multi-port mac group),由于网络设备14的3个出端口分别连接三个服务器,因此,将这3个出端口(如出端口141、出端口142和出端口143)一起加入到多端口MAC表。可以设置一个定时器,如每隔5分钟发出3次检测报文,这些检测报文用于检测服务器集群中每台服务器的内部状态。
比如说,在检测服务器11的内部状态时,在一个探测周期(如5分钟)内,网络设备14发出3个检测报文,若均没有接收到响应报文,自动从多端口MAC表中去掉与服务器11连接的端口141,这样报文就不用再复制给出端口141。
继续检测服务器11的内部状态,在一个探测周期(如20分钟)内,网络设备14发出1个检测报文,若接收到响应报文,就自动在多端口MAC表中添加与服务器11连接的端口141,这样,报文可以继续复制给出端口141。
参见图3所示,为报文发送方法的流程示意图,该方法可以包括:
步骤301、探测周期为5分钟,网络设备14每隔5分钟就连续发送3个检测报文,即在每个出端口发送3个检测报文,如在5分钟的第0秒发送1个检测报文,在第10秒发送1个检测报文,在第20秒发送1个检测报文。
比如说,网络设备14维护多端口MAC表和端口状态表,多端口MAC表包括集群MAC地址与出端口141、出端口142和出端口143的映射关系,端口状态表包括多个出端口与多个服务器的内部状态的映射关系。针对端口状态表中的每个出端口,网络设备14每隔5分钟就连续发送3个检测报文。
步骤302、每个服务器(如服务器11、服务器12和服务器13)在接收到检测报文之后,向网络设备14返回针对该检测报文的响应报文。
步骤303、针对每个出端口,若网络设备14发送3个检测报文之后,未接收到针对该检测报文的响应报文,就从多端口MAC表中删除该出端口。
步骤304、针对已经从多端口MAC表中删除的出端口,探测周期可以为20分钟,网络设备14每隔20分钟就发送1个检测报文,即网络设备14在该出端口发送1个检测报文,如在20分钟的第0秒发送1个检测报文。
步骤305、网络设备14发送这1个检测报文之后,若接收到针对该检测报文的响应报文,就在多端口MAC表中添加该出端口。
基于上述多端口MAC表,网络设备14可以通过该多端口MAC表中的多个出端口发送目标报文,该目标报文是客户端发送的应用报文。
基于与上述方法同样的申请构思,本申请实施例中还提出一种报文发送装置,应用于网络设备,所述网络设备包括与服务器集群包括的多个服务器对应的多个出端口;其中,所述网络设备包括多端口MAC表和端口状态表,参见图4所示,为该报文发送装置的结构示意图,该装置可以包括:
处理模块41,用于在接收到目标报文后,利用所述目标报文的目的MAC地址查询所述多端口MAC表;其中,所述多端口MAC表包括所述服务器集群的集群MAC地址与多个出端口之间的映射关系,所述端口状态表包括多个出端口与所述多个服务器的内部状态之间的映射关系,且所述多端口MAC表中的出端口基于所述多个服务器的内部状态进行删除或者添加;查询模块42,用于若所述目的MAC地址与所述多端口MAC表中的集群MAC地址匹配,则从所述多端口MAC表中查询所述集群MAC地址对应的出端口;发送模块43,用于基于查询到的每个出端口,通过所述出端口发送目标报文。
示例性的,处理模块41基于所述多个服务器的内部状态,对所述多端口MAC表中的出端口进行删除或者添加时具体用于:
针对所述端口状态表中的每个出端口,若该出端口对应的服务器的内部状态是正常状态,则基于第一发送周期,通过该出端口发送检测报文;
若在第一预设时长内未接收到针对所述检测报文的响应报文,则将所述端口状态表中的该出端口对应的服务器的内部状态从正常状态更新为故障状态;
在将所述端口状态表中的该出端口对应的服务器的内部状态从正常状态更新为故障状态之后,则从所述多端口MAC表中删除该出端口。
示例性的,处理模块41基于所述多个服务器的内部状态,对所述多端口MAC表中的出端口进行删除或者添加时具体用于:
针对所述端口状态表中的每个出端口,若该出端口对应的服务器的内部状态是故障状态,则基于第二发送周期,通过该出端口发送检测报文;
若在第二预设时长内接收到针对所述检测报文的响应报文,则将所述端口状态表中的该出端口对应的服务器的内部状态从故障状态更新为正常状态;
在将所述端口状态表中的该出端口对应的服务器的内部状态从故障状态更新为正常状态之后,则在所述多端口MAC表中添加该出端口;
其中,所述第二发送周期大于或等于所述第一发送周期。
示例性的,所述处理模块41,还用于针对所述集群MAC地址对应的出端口,若感知到该出端口对应的服务器的目标端口从正常状态切换为故障状态,则从所述端口状态表中删除该出端口与该服务器的内部状态的映射关系,并从所述多端口MAC表中删除该出端口;针对所述集群MAC地址对应的出端口,若感知到该出端口对应的服务器的目标端口从故障状态切换为正常状态,则在所述端口状态表中添加该出端口与该服务器的内部状态的映射关系,并在所述多端口MAC表中添加该出端口;其中,所述目标端口是该服务器上与该出端口连接的端口。
示例性的,每个出端口对应的检测报文包括所述集群MAC地址、该出端口的端口标识和标记字段,且所述标记字段的取值为第一取值;所述处理模块41通过该出端口发送检测报文之后还用于:
在通过该出端口接收到报文后,若该报文包括所述集群MAC地址、端口标识和标记字段,且该端口标识与该出端口的端口标识相同,所述标记字段的取值为第二取值,则确定接收到所述检测报文的响应报文。
基于与上述方法同样的申请构思,本申请实施例中提出一种网络设备,参见图5所示,所述网络设备可以包括:处理器51和机器可读存储介质52,机器可读存储介质52存储有能够被处理器51执行的机器可执行指令;处理器51用于执行机器可执行指令,以实现本申请上述示例公开的报文发送方法。
基于与上述方法同样的申请构思,本申请实施例还提供一种机器可读存储介质,所述机器可读存储介质上存储有若干计算机指令,所述计算机指令被处理器执行时,能够实现本申请上述示例公开的报文发送方法。
其中,上述机器可读存储介质可以是任何电子、磁性、光学或其它物理存储装置,可以包含或存储信息,如可执行指令、数据,等等。例如,机器可读存储介质可以是:RAM(Radom Access Memory,随机存取存储器)、易失存储器、非易失性存储器、闪存、存储驱动器(如硬盘驱动器)、固态硬盘、任何类型的存储盘(如光盘、dvd等),或者类似的存储介质,或者它们的组合。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机,计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
为了描述的方便,描述以上装置时以功能分为各种单元分别描述。当然,在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可以由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其它可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其它可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
而且,这些计算机程序指令也可以存储在能引导计算机或其它可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或者多个流程和/或方框图一个方框或者多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其它可编程数据处理设备上,使得在计算机或者其它可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其它可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。
Claims (10)
1.一种报文发送方法,其特征在于,应用于网络设备,所述网络设备包括与服务器集群包括的多个服务器对应的多个出端口;其中,所述网络设备包括多端口MAC表和端口状态表,所述方法包括:
在接收到目标报文后,利用所述目标报文的目的MAC地址查询所述多端口MAC表;其中,所述多端口MAC表包括所述服务器集群的集群MAC地址与多个出端口之间的映射关系,所述端口状态表包括多个出端口与所述多个服务器的内部状态之间的映射关系,且所述多端口MAC表中的出端口基于所述多个服务器的内部状态进行删除或者添加;
若所述目的MAC地址与所述多端口MAC表中的所述集群MAC地址匹配,则从所述多端口MAC表中查询所述集群MAC地址对应的出端口;
基于查询到的每个出端口,通过所述出端口发送所述目标报文。
2.根据权利要求1所述的方法,其特征在于,基于所述多个服务器的内部状态,对所述多端口MAC表中的出端口进行删除或者添加的过程,包括:
针对所述端口状态表中的每个出端口,若该出端口对应的服务器的内部状态是正常状态,则基于第一发送周期,通过该出端口发送检测报文;
若在第一预设时长内未接收到针对所述检测报文的响应报文,则将所述端口状态表中的该出端口对应的服务器的内部状态从正常状态更新为故障状态;
在将所述端口状态表中的该出端口对应的服务器的内部状态从正常状态更新为故障状态之后,则从所述多端口MAC表中删除该出端口。
3.根据权利要求2所述的方法,其特征在于,基于所述多个服务器的内部状态,对所述多端口MAC表中的出端口进行删除或者添加的过程,包括:
针对所述端口状态表中的每个出端口,若该出端口对应的服务器的内部状态是故障状态,则基于第二发送周期,通过该出端口发送检测报文;
若在第二预设时长内接收到针对所述检测报文的响应报文,则将所述端口状态表中的该出端口对应的服务器的内部状态从故障状态更新为正常状态;
在将所述端口状态表中的该出端口对应的服务器的内部状态从故障状态更新为正常状态之后,则在所述多端口MAC表中添加该出端口;
其中,所述第二发送周期大于或等于所述第一发送周期。
4.根据权利要求1-3任一项所述的方法,其特征在于,所述方法还包括:
针对所述集群MAC地址对应的出端口,若感知到该出端口对应的服务器的目标端口从正常状态切换为故障状态,则从所述端口状态表中删除该出端口与该服务器的内部状态的映射关系,并从所述多端口MAC表中删除该出端口;
针对所述集群MAC地址对应的出端口,若感知到该出端口对应的服务器的目标端口从故障状态切换为正常状态,则在所述端口状态表中添加该出端口与该服务器的内部状态的映射关系,并在所述多端口MAC表中添加该出端口;
其中,所述目标端口是该服务器上与该出端口连接的端口。
5.根据权利要求2或3所述的方法,其特征在于,每个出端口对应的检测报文包括所述集群MAC地址、该出端口的端口标识和标记字段,且所述标记字段的取值为第一取值;所述通过该出端口发送检测报文之后,所述方法还包括:
在通过该出端口接收到报文后,若该报文包括所述集群MAC地址、端口标识和标记字段,且该端口标识与该出端口的端口标识相同,所述标记字段的取值为第二取值,则确定接收到所述检测报文的响应报文。
6.一种报文发送装置,其特征在于,应用于网络设备,所述网络设备包括与服务器集群包括的多个服务器对应的多个出端口;其中,所述网络设备包括多端口MAC表和端口状态表,所述装置包括:
处理模块,用于在接收到目标报文后,利用所述目标报文的目的MAC地址查询所述多端口MAC表;其中,所述多端口MAC表包括所述服务器集群的集群MAC地址与多个出端口之间的映射关系,所述端口状态表包括多个出端口与所述多个服务器的内部状态之间的映射关系,且所述多端口MAC表中的出端口基于所述多个服务器的内部状态进行删除或者添加;
查询模块,用于若所述目的MAC地址与所述多端口MAC表中的集群MAC地址匹配,则从所述多端口MAC表中查询所述集群MAC地址对应的出端口;
发送模块,用于基于查询到的每个出端口,通过所述出端口发送目标报文。
7.根据权利要求6所述的装置,其特征在于,
所述处理模块基于所述多个服务器的内部状态,对所述多端口MAC表中的出端口进行删除或者添加时具体用于:
针对所述端口状态表中的每个出端口,若该出端口对应的服务器的内部状态是正常状态,则基于第一发送周期,通过该出端口发送检测报文;
若在第一预设时长内未接收到针对所述检测报文的响应报文,则将所述端口状态表中的该出端口对应的服务器的内部状态从正常状态更新为故障状态;
在将所述端口状态表中的该出端口对应的服务器的内部状态从正常状态更新为故障状态之后,则从所述多端口MAC表中删除该出端口。
8.根据权利要求7所述的装置,其特征在于,
所述处理模块基于所述多个服务器的内部状态,对所述多端口MAC表中的出端口进行删除或者添加时具体用于:
针对所述端口状态表中的每个出端口,若该出端口对应的服务器的内部状态是故障状态,则基于第二发送周期,通过该出端口发送检测报文;
若在第二预设时长内接收到针对所述检测报文的响应报文,则将所述端口状态表中的该出端口对应的服务器的内部状态从故障状态更新为正常状态;
在将所述端口状态表中的该出端口对应的服务器的内部状态从故障状态更新为正常状态之后,则在所述多端口MAC表中添加该出端口;
其中,所述第二发送周期大于或等于所述第一发送周期。
9.根据权利要求6-8任一项所述的装置,其特征在于,
所述处理模块,还用于针对所述集群MAC地址对应的出端口,若感知到该出端口对应的服务器的目标端口从正常状态切换为故障状态,则从所述端口状态表中删除该出端口与该服务器的内部状态的映射关系,并从所述多端口MAC表中删除该出端口;针对所述集群MAC地址对应的出端口,若感知到该出端口对应的服务器的目标端口从故障状态切换为正常状态,则在所述端口状态表中添加该出端口与该服务器的内部状态的映射关系,并在所述多端口MAC表中添加该出端口;其中,所述目标端口是该服务器上与该出端口连接的端口。
10.根据权利要求7或8所述的装置,其特征在于,每个出端口对应的检测报文包括所述集群MAC地址、该出端口的端口标识和标记字段,且所述标记字段的取值为第一取值;所述处理模块通过该出端口发送检测报文之后还用于:
在通过该出端口接收到报文后,若该报文包括所述集群MAC地址、端口标识和标记字段,且该端口标识与该出端口的端口标识相同,所述标记字段的取值为第二取值,则确定接收到所述检测报文的响应报文。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210431847.XA CN114866456B (zh) | 2022-04-22 | 2022-04-22 | 一种报文发送方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210431847.XA CN114866456B (zh) | 2022-04-22 | 2022-04-22 | 一种报文发送方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN114866456A true CN114866456A (zh) | 2022-08-05 |
CN114866456B CN114866456B (zh) | 2024-07-23 |
Family
ID=82634065
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210431847.XA Active CN114866456B (zh) | 2022-04-22 | 2022-04-22 | 一种报文发送方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114866456B (zh) |
Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101340377A (zh) * | 2008-07-30 | 2009-01-07 | 华为技术有限公司 | 一种用于二层网络数据传输的方法、装置及其系统 |
CN101404619A (zh) * | 2008-11-17 | 2009-04-08 | 杭州华三通信技术有限公司 | 一种实现服务器负载均衡的方法和一种三层交换机 |
US7818408B1 (en) * | 2008-04-24 | 2010-10-19 | Network Appliance, Inc. | Automated virtual interface failover in a mass storage cluster |
CN101867495A (zh) * | 2010-06-25 | 2010-10-20 | 神州数码网络(北京)有限公司 | 以太网自动保护链路故障快速切换方法 |
CN101909010A (zh) * | 2010-08-06 | 2010-12-08 | 福建星网锐捷网络有限公司 | 端口配置方法、装置及交换机设备 |
WO2016177191A1 (zh) * | 2015-08-27 | 2016-11-10 | 中兴通讯股份有限公司 | 一种报文的处理方法及装置 |
US20180234336A1 (en) * | 2017-02-15 | 2018-08-16 | Intel Corporation | Compute node cluster based routing method and apparatus |
CN111988170A (zh) * | 2020-08-07 | 2020-11-24 | 锐捷网络股份有限公司 | 一种终端故障定位方法及装置 |
CN112737945A (zh) * | 2020-12-30 | 2021-04-30 | 杭州迪普信息技术有限公司 | 服务器连接控制方法及装置 |
CN113472698A (zh) * | 2021-06-18 | 2021-10-01 | 新华三信息安全技术有限公司 | 一种交换设备及其转发报文的方法 |
CN113852547A (zh) * | 2021-09-10 | 2021-12-28 | 锐捷网络股份有限公司 | 一种报文转发方法、装置、线卡及存储介质 |
-
2022
- 2022-04-22 CN CN202210431847.XA patent/CN114866456B/zh active Active
Patent Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7818408B1 (en) * | 2008-04-24 | 2010-10-19 | Network Appliance, Inc. | Automated virtual interface failover in a mass storage cluster |
CN101340377A (zh) * | 2008-07-30 | 2009-01-07 | 华为技术有限公司 | 一种用于二层网络数据传输的方法、装置及其系统 |
CN101404619A (zh) * | 2008-11-17 | 2009-04-08 | 杭州华三通信技术有限公司 | 一种实现服务器负载均衡的方法和一种三层交换机 |
CN101867495A (zh) * | 2010-06-25 | 2010-10-20 | 神州数码网络(北京)有限公司 | 以太网自动保护链路故障快速切换方法 |
CN101909010A (zh) * | 2010-08-06 | 2010-12-08 | 福建星网锐捷网络有限公司 | 端口配置方法、装置及交换机设备 |
WO2016177191A1 (zh) * | 2015-08-27 | 2016-11-10 | 中兴通讯股份有限公司 | 一种报文的处理方法及装置 |
US20180234336A1 (en) * | 2017-02-15 | 2018-08-16 | Intel Corporation | Compute node cluster based routing method and apparatus |
CN111988170A (zh) * | 2020-08-07 | 2020-11-24 | 锐捷网络股份有限公司 | 一种终端故障定位方法及装置 |
CN112737945A (zh) * | 2020-12-30 | 2021-04-30 | 杭州迪普信息技术有限公司 | 服务器连接控制方法及装置 |
CN113472698A (zh) * | 2021-06-18 | 2021-10-01 | 新华三信息安全技术有限公司 | 一种交换设备及其转发报文的方法 |
CN113852547A (zh) * | 2021-09-10 | 2021-12-28 | 锐捷网络股份有限公司 | 一种报文转发方法、装置、线卡及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN114866456B (zh) | 2024-07-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20230283559A1 (en) | Network flow management for isolated virtual networks | |
US10015082B2 (en) | Providing non-interrupt failover using a link aggregation mechanism | |
US8391289B1 (en) | Managing a forwarding table in a switch | |
US20190116220A1 (en) | Neighbor Discovery for IPV6 Switching Systems | |
US9019815B2 (en) | Source alive route injection | |
CN112367254B (zh) | 跨设备链路聚合方法、装置和电子设备 | |
US20030067917A1 (en) | IGMP proxy | |
CN101729425B (zh) | Vrrp组网中流量发送的方法及设备 | |
US10097454B1 (en) | Flexible packet rewriting framework | |
CN108600069B (zh) | 链路切换方法及装置 | |
CN111010329B (zh) | 一种报文传输方法及装置 | |
CN112887229B (zh) | 一种会话信息同步方法及装置 | |
CN109728972B (zh) | 网络连接检测方法和装置 | |
CN108259348B (zh) | 一种报文传输方法和装置 | |
CN110768917B (zh) | 一种报文传输方法及装置 | |
CN110391919B (zh) | 组播流量转发方法、装置、电子设备 | |
US20220094768A1 (en) | Processing protocol packet | |
CN113507431B (zh) | 一种报文管理方法、装置、设备及机器可读存储介质 | |
CN108234358B (zh) | 一种组播报文传输方法、装置及机器可读存储介质 | |
US20210326224A1 (en) | Method and system for processing device failure | |
CN114866456B (zh) | 一种报文发送方法及装置 | |
CN108632125B (zh) | 一种组播表项管理方法、装置、设备及机器可读存储介质 | |
CN111556179B (zh) | Arp表项更新方法和装置 | |
US20190089625A1 (en) | Setting link aggregation group | |
US20200341968A1 (en) | Differential Update of Local Cache from Central Database |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |