CN116614348A - 用于远程复制服务的系统及其操作方法 - Google Patents

用于远程复制服务的系统及其操作方法 Download PDF

Info

Publication number
CN116614348A
CN116614348A CN202310882604.2A CN202310882604A CN116614348A CN 116614348 A CN116614348 A CN 116614348A CN 202310882604 A CN202310882604 A CN 202310882604A CN 116614348 A CN116614348 A CN 116614348A
Authority
CN
China
Prior art keywords
rep
node
cluster
state
backup
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.)
Pending
Application number
CN202310882604.2A
Other languages
English (en)
Inventor
刘乃朋
赵磊
魏婷婷
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Lenovo Netapp Technology Ltd
Original Assignee
Lenovo Netapp Technology Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Lenovo Netapp Technology Ltd filed Critical Lenovo Netapp Technology Ltd
Priority to CN202310882604.2A priority Critical patent/CN116614348A/zh
Publication of CN116614348A publication Critical patent/CN116614348A/zh
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0654Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0663Performing the actions predefined by failover planning, e.g. switching to standby network elements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/10Active monitoring, e.g. heartbeat, ping or trace-route
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1095Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本公开提供了一种用于远程复制Rep服务的系统及其操作方法。系统包括多个Rep集群,该多个Rep集群中的每个Rep集群包括监控模块和多个节点,其中,监控模块被配置为将多个节点中一个节点确定为当前主节点,将多个节点中的剩余节点确定为当前备份节点,并且监控当前主节点和当前备份。

Description

用于远程复制服务的系统及其操作方法
技术领域
本公开涉及分布式存储系统,并且具体地,涉及分布式存储系统中的用于远程复制Rep服务的系统和Rep集群之间的网络传输管理的方法。
背景技术
在分布式存储系统中,出于数据保护或灾难恢复的目的,需要将产品数据复制到处于远程位置的设备上,因此远程复制Rep服务逐渐成为一种常用的功能。由于分布式存储系统通常会处于一种不安全的环境之中,诸如网络故障、节点故障、磁盘故障等问题不可避免,甚至会经常发生,因此Rep服务的高可用性就是一种不可或缺的服务可持续性的保证。
Rep服务需要将一个Rep集群的数据传输到另一个Rep集群,对此,Rep集群之间的网络传输管理是必须要解决的问题,一方面要提供高性能的网络传输,另一方面还要解决存在于外部环境的网络不稳定问题,同时还要考虑业务模块使用的便利性。
本公开针对Rep服务的高可用性和Rep集群之间的网络传输管理提供了相关的解决方法。
发明内容
根据本公开的实施例提供了一种用于远程复制Rep服务的系统,包括:多个Rep集群,所述多个Rep集群中的每个Rep集群包括监控模块和多个节点,其中,所述监控模块被配置为:将所述多个节点中一个节点确定为当前主节点;将所述多个节点中的剩余节点确定为当前备份节点;监控当前主节点和当前备份节点的状态。
在一些示例中,所述状态包括故障状态、激活状态、备份状态和恢复状态。
在一些示例中,监控当前主节点和当前备份节点的状态包括:分别从当前主节点和当前备份节点接收心跳消息;以及基于没有接收到心跳消息来确定当前主节点和/或当前备份节点处于故障状态。
在一些示例中,监控模块还被配置为:当确定当前主节点处于故障状态时,从处于备份状态的当前备份节点中选择一个节点作为新的主节点。
在一些示例中,所述多个Rep集群中的每个Rep集群还包括网络管理模块,其中,所述多个Rep集群包括第一Rep集群和第二Rep集群,当第一Rep集群向第二Rep集群发送任务消息时,第一Rep集群中用于发送任务消息的节点为发送节点,第二Rep集群中用于接收任务消息的节点为接收节点;其中,所述网络管理模块被配置为:从上层业务接收第二Rep集群中所述接收节点的地址;以及随机或基于负载均衡在第一Rep集群中的所述发送节点与第二Rep集群中的所述接收节点之间的子会话的一个或多个通道中,确定用于发送所述任务消息的通道。
在一些示例中,所述网络管理模块还被配置为:当所确定的通道发生故障时,随机或基于负载均衡在第一Rep集群中的所述发送节点与第二Rep集群中的所述接收节点之间的子会话的剩余通道中,确定用于发送所述任务消息的通道;当所述子会话中的所述一个或多个通道均发生故障时,随机或基于负载均衡在第一Rep集群中的所述发送节点与第二Rep集群中的剩余节点之间的子会话的一个或多个通道中,确定用于发送所述任务消息的通道。
在一些示例中,所述地址由包括Rep集群ID、服务类型和Rep节点名称的三元组表示。
在一些示例中,第一Rep集群被配置为:定期向第二Rep集群发送第一Rep集群的视图;以及定期从第二Rep集群接收第二Rep集群的视图。
在一些示例中,所述视图包括Rep集群中的每个节点的节点类型、节点地址和节点状态。
在一些示例中,第一Rep集群的视图和第二Rep集群的视图被包括在心跳消息中。
根据本公开的实施例,提供了一种用于远程复制Rep服务的方法,包括,对于多个Rep集群中的每个Rep集群:由监控模块将Rep集群包括的多个节点中的一个节点确定为当前主节点;由监控模块将Rep集群包括的多个节点中的剩余节点确定为当前备份节点;以及由监控模块监控当前主节点和当前备份节点的状态。
在一些示例中,所述状态包括故障状态、激活状态、备份状态和恢复状态。
在一些示例中,由监控模块监控当前主节点和当前备份节点的状态包括:由监控模块分别从当前主节点和当前备份节点接收心跳消息;以及由监控模块基于没有接收到心跳消息来确定当前主节点和/或当前备份节点处于故障状态。
在一些示例中,所述方法还包括:当确定当前主节点处于故障状态时,由监控模块从处于备份状态的当前备份节点中选择一个节点作为新的主节点。
在一些示例中,所述方法还包括,当多个Rep集群中的第一Rep集群向第二Rep集群发送任务消息时,第一Rep集群中用于发送任务消息的节点为发送节点,第二Rep集群中用于接收任务消息的节点为接收节点,其中:由网络管理模块从上层业务接收第二Rep集群中所述接收节点的地址;以及由网络管理模块随机或基于负载均衡在第一Rep集群中的所述发送节点与第二Rep集群中的所述接收节点之间的子会话的一个或多个通道中,确定用于发送所述任务消息的通道。
在一些示例中,所述方法还包括:当所确定的通道发生故障时,由网络管理模块随机或基于负载均衡在第一Rep集群中的所述发送节点与第二Rep集群中的所述接收节点之间的子会话的剩余通道中,确定用于发送所述任务消息的通道;当所述子会话中的所述一个或多个通道均发生故障时,由网络管理模块随机或基于负载均衡在第一Rep集群中的所述发送节点与第二Rep集群中的剩余节点之间的子会话的一个或多个通道中,确定用于发送所述任务消息的通道。
在一些示例中,所述地址由包括Rep集群ID、服务类型和Rep节点名称的三元组表示。
在一些示例中,所述方法还包括:由第一Rep集群定期向第二Rep集群发送第一Rep集群的视图;以及由第一Rep集群定期从第二Rep集群接收第二Rep集群的视图。
在一些示例中,所述视图包括Rep集群中每个节点的节点类型、节点地址和节点状态。
在一些示例中,第一Rep集群的视图和第二Rep集群的视图被包括在心跳消息中。
本公开提出的方法可以基于主备方式来提供Rep服务。当主节点出现故障时,剩余的备份节点可以及时接管Rep服务,从而保证了在复杂的、不安全环境下的Rep服务的高可用性。此外,本公开提出的方法可以基于多层通道组合的方式在Rep集群之间进行网络传输,因此网络数据传输可以与业务功能解耦,并且业务功能模块无需关注网络内部的通道切换和变化,从而同时避免分布式存储系统中因为网络状态和节点状态视图不一致而引起的分布式系统的诸如状态卡、感知故障慢等的问题。
附图说明
为了更清楚地说明本公开实施例的技术方案,下面将对实施例的附图作简单地介绍,显而易见地,下面描述中的附图仅仅涉及本公开的一些实施例,而非对本公开的限制,其中:
图1示出了根据本公开的实施例的用于Rep服务的系统的示意图;
图2示出了根据本公开的实施例的Rep集群中的监控模块与节点通信的示意图;
图3示出了根据本公开的实施例的监控模块的示意图;
图4示出了根据本公开的实施例的Rep集群中的Rep节点的结构的示意图;
图5示出了根据本公开的实施例的Rep集群之间的网络传输管理的示意图;
图6A示出了根据本公开的实施例的当一个子会话中的部分通道发生故障的示意图;
图6B示出了根据本公开的实施例的当一个子会话中的全部通道发生故障的示意图;
图7示出了根据本公开的实施例的网络管理模块的示意图;以及
图8示出了根据本公开的实施例的用于Rep服务的系统的操作方法的流程图。
具体实施方式
提供下列参考附图的描述以有助于对通过权利要求及其等效物定义的本公开的各种实施例的全面理解。本描述包括各种具体细节以有助于理解但是仅应当被认为是示例性的。因此,本领域普通技术人员将认识到,能够对这里描述的各种实施例进行各种改变和修改而不脱离本公开的范围与精神。此外,为了清楚和简明起见,可以略去对公知功能与结构的描述。
在下面说明书和权利要求书中使用的术语和措词不局限于它们的词典意义,而是仅仅由发明人用于使得能够对于本公开清楚和一致的理解。因此,对本领域技术人员来说应当明显的是,提供以下对本公开的各种实施例的描述仅用于图示的目的而非限制如所附权利要求及其等效物所定义的本公开的目的。
应当理解,单数形式的“一”、“一个”和“该”包括复数指代,除非上下文清楚地指示不是如此。因此,例如,对“部件表面”的指代包括指代一个或多个这样的表面。
术语“包括”或“可以包括”指的是可以在本公开的各种实施例中使用的相应公开的功能、操作或组件的存在,而不是限制一个或多个附加功能、操作或特征的存在。此外,术语“包括”或“具有”可以被解释为表示某些特性、数字、步骤、操作、构成元件、组件或其组合,但是不应被解释为排除一个或多个其它特性、数字、步骤、操作、构成元件、组件或其组合的存在可能性。
在本公开的各种实施例中使用的术语“或”包括任意所列术语及其所有组合。例如,“A或B”可以包括A、可以包括B、或者可以包括A和B二者。除非不同地定义,本公开使用的所有术语(包括技术术语或科学术语)具有本公开所述的本领域技术人员理解的相同含义。如在词典中定义的通常术语被解释为具有与在相关技术领域中的上下文一致的含义,而且不应理想化地或过分形式化地对其进行解释,除非本公开中明确地如此定义。
以下讨论的图1至图8以及用于描述本专利文档中的本公开的原理的各种实施例仅作为说明,并且不应以任何方式解释为限制本公开的范围。本领域技术人员将理解,本公开的原理可以在任何适当布置的系统或设备中实施。
图1示出了根据本公开的实施例的用于Rep服务的系统的示意图。如图所示,系统可以包括多个Rep集群。Rep集群之间可以采用多层通道组合的方式进行网络传输。虽然在图1中,系统被示出为仅包括三个Rep集群,但是本公开不限于此,系统可以包括任意数量的Rep集群。
图2示出了根据本公开的实施例的Rep集群中的监控模块与节点通信的示意图。如图所示,一个Rep集群可以包括一个监控模块和一个或多个节点。
监控模块可以监控Rep集群中的一个或多个节点的状态,并且确定Rep集群的主节点和备份节点。通常,一个Rep集群中只有一个主节点。当Rep集群仅包括一个节点时,该一个节点即为主节点。当Rep集群包括多个节点时,监控模块可以从多个节点中选择一个节点作为主节点,并将剩余节点确定为备份节点。
在Rep集群包括多个节点的情况下,当Rep集群中的多个节点首次启动时,多个节点均处于创建状态。监控模块可以为多个节点中的每一个分配节点号。多个节点中的每一个可以周期性地向监控模块发送心跳消息(beacon)。监控模块将最先接收到其心跳消息的节点确定为Rep集群的主节点,并将剩余节点确定为Rep集群的备份节点。被确定为主节点的节点从创建状态切换到激活状态以提供Rep服务,被确定为备份节点的节点从创建状态切换到备份状态用于在当前主节点发生故障的情况下代替主节点提供Rep服务。
当Rep集群的主节点和备份节点被确定之后,监控模块可以通过接收来自节点的心跳消息来监控主节点和备份节点的状态。当监控模块没有接收到来自主节点的心跳消息时,则认为主节点发生故障,即主节点从状态激活状态切换为故障状态。或者,当监控模块在特定时间间隔内没有接收到来自主节点的心跳消息时,则认为主节点发生故障,即主节点从激活状态切换为故障状态。类似地,当监控模块没有接收到来自备份节点的心跳消息时,则认为备份节点发生故障,即备份节点从状态备份状态切换为故障状态。或者,当监控模块在特定时间间隔内没有接收到来自备份节点的心跳消息时,则认为备份节点发生故障,即备份节点从状态备份状态切换为故障状态。在一些实施例中,特定时间间隔可以是预定的,诸如10s。
当Rep集群中的主节点处于故障状态时,监控模块可以从处于备份状态的备份节点中选择一个备份节点作为Rep集群的新的主节点。新的主节点可以从备份节点中随机选择。或者,新的主节点可以是备份节点中节点号最小的备份节点。被选择为新的主节点的备份节点从备份状态切换到激活状态来代替原来的主节点继续提供Rep服务,以避免由于当前主节点故障造成的对Rep服务的可用性的影响。
处于故障状态的主节点和/或备份节点可以自行尝试恢复并切换到恢复状态。当发生故障的主节点和/或备份节点的故障解除时,主节点和/或备份节点从恢复状态切换到备份状态,并作为Rep集群中的备份节点运行。
继续参考图2,图中示出的Rep集群包括监控模块和三个节点,其中Rep 1为Rep集群的主节点,Rep 2和Rep 3为Rep集群的备份节点。虽然图2的Rep集群被示出为包括3个节点Rep 1、Rep 2和Rep 3,但是本公开不限于此,Rep集群可以包括更多或更少的节点。
在示例中,主节点Rep 1和备份节点Rep 2、Rep 3可以分别周期性地向监控模块发送心跳消息。主节点Rep 1处于激活状态,备份节点Rep 2、Rep 3处于备份状态。监控模块可以基于是否接收到来自各个节点的心跳消息来确定相应节点是否发生故障。或者,监控模块可以基于是否在特定时间间隔内接收到来自各个节点的心跳消息来确定相应节点是否发生故障。一旦监控模块没有接收到来自某个节点的心跳消息,或者在特定时间间隔内没有接收到来自某个节点的心跳消息,则认为该节点发生故障,例如,处于故障状态。
当监控模块没有接收到来自主节点Rep 1的心跳消息或者在特定时间间隔内没有接收到来自主节点Rep 1的心跳消息时,则认为主节点Rep 1发生故障,即主节点Rep 1从激活状态切换到故障状态。由于Rep 1是Rep集群的主节点,负责提供Rep服务,当主节点处于故障状态时,将会影响Rep服务的可用性,因此需要从处于备份状态的备份节点中选择一个备份节点来替代当前主节点Rep 1成为新的主节点。如果监控模块可以正常接收到来自备份节点Rep 2和Rep 3的心跳消息,则认为备份节点Rep 2和Rep 3处于备份状态(即,没有发生故障),从而监控模块可以从备份节点Rep 2和Rep 3中选择一个节点作为Rep集群的新的主节点,以继续提供Rep服务。
在示例中,监控模块可以从备份节点Rep 2和Rep 3中随机选择一个节点作为Rep集群的新的主节点。或者,监控模块可以从备份节点Rep 2和Rep 3中选择节点号最小的节点作为Rep集群的新的主节点,在此示例中,备份节点Rep 2的节点号最小,因此监控模块可以选择备份节点Rep 2作为Rep集群的新的主节点。当备份节点Rep 2被监控模块确定为Rep集群的新的主节点时,Rep 2从备份状态切换到激活状态。
在示例中,处于故障状态的Rep集群的原主节点Rep 1可以自行尝试从故障状态恢复并切换到恢复状态。当Rep 1的故障解除时,其可以从恢复状态切换到备份状态并作为Rep集群的备份节点运行。
在一些示例中,当监控模块没有接收到来自备份节点Rep 3的心跳消息或者在特定时间间隔内没有接收到来自备份节点Rep 3的心跳消息时,则认为备份节点Rep3发生故障,即从备份状态切换到故障状态。然而,由于Rep 3是Rep集群的备份节点,并不需要其对外提供Rep服务,因此不需要进行额外的操作,即不需要任何节点间的重新选择或切换。
在示例中,处于故障状态的Rep集群的备份节点Rep 3可以自行尝试从故障状态恢复并切换到恢复状态。当Rep3的故障解除时,其可以从恢复状态切换到备份状态并继续作为Rep集群的备份节点运行。
图3示出了根据本公开的实施例的监控模块的示意图。如图所示,监控模块可以包括收发单元和主节点确定单元。但是应当注意,本公开不限于此,监控模块还可以更多的单元。
收发单元可以用于从Rep集群中的节点接收心跳消息。在示例中,监控模块基于是否接收到心跳消息或是否在特定时间间隔内接收到心跳消息来确定节点的状态。收发单元还可以用于向Rep集群中的节点分配节点号。在示例中,当Rep集群中的节点首次启动时,收发单元可以向Rep集群中的节点分配节点号。收发单元还可以向Rep集群中的节点发送心跳消息以确定Rep集群的主节点。
主节点确定单元可以用于确定Rep集群的主节点。当Rep集群中的节点首次启动时,主节点确定单元可以将最先接收到其心跳消息的节点确定为Rep集群的主节点。当Rep集群的当前主节点处于故障状态时,主节点确定单元可以从Rep集群的备份节点中选择一个备份节点作为新的主节点。在示例中,主节点确定单元可以从Rep集群的备份节点中随机选择一个备份节点作为新的主节点。或者,主节点确定单元可以从Rep集群的备份节点中选择节点号最小的一个备份节点作为新的主节点。
图4示出了根据本公开的实施例的Rep集群中的节点的结构的示意图。主节点和备份节点可以具有类似的结构。具体地,节点可以包括心跳消息管理模块、网络会话管理模块以及其他功能管理模块。
心跳消息管理模块可以用于生成心跳消息,其中,节点定期地向监控模块发送心跳消息,并且监控模块基于是否接收到心跳消息或是否在特定时间间隔内接收到心跳消息来确定节点是否发生故障。
网络会话管理模块可以用于管理系统中的多个Rep集群之间的网络会话,例如,Rep集群之间的任务消息的传输,其中,任务消息可以包括业务消息。此外,一个Rep集群内的多个节点之间也可以互相传输任务消息,其中,任务消息可以包括管理消息。结合参考图2,Rep集群的主节点Rep 1可以分别与备份节点Rep 2和Rep 3进行任务消息的传输。其他功能管理模块可以用于管理节点的其他功能。
图5示出了根据本公开的实施例的Rep集群之间的网络传输管理的示意图,其中,该网络传输管理的方法可以由网络管理模块来执行。图5示出了两个Rep集群,Rep集群1和Rep集群2。在Rep集群1向Rep集群2发送任务消息的示例中,Rep集群1可以被称为发送集群,并且Rep集群2可以被称为接收集群,并且因此,发送集群中用于发送任务消息的节点可以被称为发送节点,并且接收集群中用于接收任务消息的节点可以被称为接收节点。但是应当注意,本公开不限于此,在一些示例中,Rep集群2也可以向Rep集群1发送任务消息。
如图所示,Rep集群1包括一个主节点Rep 1-1和两个备份节点Rep 1-2和Rep 1-3,并且Rep集群2包括一个主节点Rep 2-1和两个备份节点Rep 2-2和Rep 2-3。Rep集群1和Rep集群2还分别包括网络管理模块用于管理网络传输。但是应当注意,本公开不限于此,Rep集群可以包括任意数量的节点。
如图5所示,Rep集群1的主节点Rep 1-1与Rep集群2中的每个节点Rep 2-1、Rep 2-2和Rep 2-3分别建立了子会话1、子会话2和子会话3。其中,每个子会话可以包括一个或多个通道。在图5中,虽然每个子会话被示出为分别包括3个通道,但是本公开不限于此,每个子会话可以包括任意数量的通道。通道指的是点对点之间的连接,是如图5所示的示意图中最基本的连接。子会话指的是不同Rep集群中的节点之间的连接。例如,Rep集群1中的主节点Rep 1-1可以分别与Rep集群2中的主节点Rep 2-1以及备份节点Rep 2-2、Rep 2-3建立网络连接,该网络连接可以被称为子会话。多个子会话可以组成会话,即一个Rep集群中的一个节点与另一Rep集群中的所有节点之间的子会话的总和可以被称为会话。例如,Rep集群1中的主节点Rep 1-1分别与Rep集群2中的主节点Rep 2-1以及备份节点Rep 2-2、Rep 2-3建立了子会话1、子会话2和子会话3,而子会话1、子会话2和子会话3共同组成了Rep集群1中的主节点Rep 1-2和Rep集群2中的所有节点之间的会话。
虽然图5仅示出了从Rep集群1中的主节点Rep 1-2到Rep集群2中的所有节点的会话,但是Rep集群1中的每个节点都可以与Rep集群2中的所有节点建立会话,并且Rep集群2中的每个节点也可以与Rep集群1中的所有节点建立会话,从而在Rep集群之间形成双向的全连接模式。
当Rep集群1中的节点想要向Rep集群2发送任务消息时,上层业务可以向Rep集群1中的网络管理模块(网络管理模块1)通知Rep集群2的地址,然后该网络管理模块可以自动执行通道的选择。根据本公开的实施例,Rep集群地址可以由包括Rep集群ID、服务类型和Rep节点名称的三元组来表示。
根据本公开的实施例,网络管理模块可以自动选择某个通道以用于发送任务消息。例如,网络管理模块可以从一个子会话中选择一个通道。通道的选择可以是随机的或者基于负载均衡的。例如,如果一个子会话包括三个通道,则网络管理模块可以从三个通道中随机选择一个通道来发送任务消息。可替代地,网络管理模块可以基于负载均衡来从三个通道中选择一个通道来发送任务消息。具体地,如果三个通道中的两个通道上正在进行任务消息的传输,则网络管理模块将选择另一个其上没有任务消息正在传输的信道来发送任务消息,以实现负载均衡,从而避免多个通道中的部分通道过于忙碌而另一部分通道过于空闲。
在示例中,如果所选的通道发生故障,则网络管理模块可以从该一个子会话的剩余通道中选择一个通道来进行传输。从剩余通道中选择通道仍然可以是随机的或基于负载均衡的。
在示例中,如果该一个子会话中的所有通道均发生故障,则网络管理模块可以从包括在同一个会话中的剩余子会话中选择一个通道来发送任务消息。
通过这种方式,网络管理模块可以自适应地应对不同级别的网络故障,并且这种方式对上层业务很友好,因为上层业务无需关注底层网络的内部逻辑,从而可以实现业务层无感知的网络切换并且降低模块间耦合。
图6A示出了根据本公开的实施例的当一个子会话中的部分通道发生故障的示意图。
如图6A所示,Rep集群1的主节点Rep 1-1分别与Rep集群2中的主节点Rep 2-1、备份节点Rep 2-2、Rep 2-3之间建立了子会话1、子会话2和子会话3。每个子会话分别包括三个通道,通道1、通道2和通道3。
当Rep集群1的主节点Rep 1-1想要向Rep集群2发送消息时,可以从多个通道中选择一个来进行发送。例如,当Rep集群1的主节点Rep 1-1想要向Rep集群2的备份节点Rep 2-2发送消息时,网络管理模块可以从子会话2的三个通道中选择一个通道(例如,通道1)来进行任务消息的传输。网络管理模块可以随机选择,也可以基于负载均衡来进行选择。
当子会话2中的通道1发生故障时,网络管理模块可以从子会话2的剩余两个通道中选择一个通道来进行任务消息的传输。网络管理模块可以随机选择,也可以基于负载均衡来进行选择。例如,网络管理模块可以随机从子会话2的通道2和通道3中选择一个通道。或者,网络管理模块可以基于负载均衡从子会话2的通道2和通道3中选择一个通道。具体地,当通道2上正在进行任务消息的传输并且通道3上没有任务消息的传输时,基于负载均衡,网络管理模块将选择通道3来进行传输。
图6B示出了根据本公开的实施例的当一个子会话中的全部通道发生故障的示意图。
如图6B所示,当子会话2中的通道1、通道2和通道3均发生故障时,网络管理模块则无法继续从子会话2中选择通道来进行任务消息的传输。网络管理模块可以从子会话1和子会话3所包括的通道中随机选择通道来进行任务消息的传输。例如,网络管理模块可以从子会话1中选择通道1来进行任务消息的传输。来自Rep集群1的主节点Rep 1-1的任务消息经由子会话1的通道1被发送到Rep集群2的主节点Rep 2-1,然后Rep集群2的主节点Rep 2-1可以将该任务消息转发给Rep集群2的备份节点Rep 2-2,从而完成从Rep集群1的主节点Rep1-1到Rep集群2的备份节点Rep 2-2的任务消息的传输。
在一些情况下,除了Rep集群间的网络传输通道会发生故障之外,Rep集群中的节点也可能发生故障。Rep集群中的节点可能因为处于故障状态而不可用。然而,通过网络管理模块来感知节点故障通常存在一定的时间差,并且这个时间差通常是不固定的。例如,当接收节点因为其所在的服务器突然死机而发生故障时,对于故障的感知时间通常比较长,这就会导致问题,即发送Rep集群中的发送节点认为接收Rep集群中的接收节点没有故障,但是接收Rep集群中的接收节点实际上已经发生了故障,那么发送Rep集群中发送节点当前所知的接收Rep集群中的接收节点的状态与接收Rep集群中的该接收节点的实际的状态不一致。这就会导致发送Rep集群中的发送节点在一个较长的时间段期间持续地向接收Rep集群中的一个故障的接收节点发送任务消息,从而造成业务的长时间无响应。
结合参考图6A和图6B,仍然以Rep集群1中的主节点Rep 1-1向Rep集群2中的备份节点Rep 2-2发送任务消息为示例。
在示例中,图6A和图6B中的通道全部正常,但是Rep集群2中的备份节点Rep 2-2发生了故障,诸如,节点所在的服务器死机。因为由Rep集群1中的网络管理模块1来感知Rep集群2中的备份节点Rep 2-2的故障需要较长的时间,因此,Rep集群1中的主节点Rep 1-1将在Rep集群2中的备份节点Rep 2-2实际发生故障之后的较长一段时间期间仍然认为备份节点Rep 2-2处于正常工作状态,从而在较长一段时间期间持续地向备份节点Rep 2-2发送任务消息。但是,由于Rep集群2中的备份节点Rep 2-2实际上已经发生故障,因此,将造成业务的长时间无响应。
为解决上述问题,Rep集群1和Rep集群2可以定期地相互发送各自的视图,从而知道对方集群的状态。例如,Rep集群1可以定期地向Rep集群2发送自身的视图,从而Rep集群2能够知道Rep集群1中的每个节点的状态。相应地,Rep集群1也可以定期地从Rep集群2接收Rep集群2的视图,从而Rep集群1也可以知道Rep集群2中的每个节点的状态。在一些示例中,心跳消息可以携带Rep集群的视图,并且Rep集群之间也可以通过节点之间的网络连接来互相发送心跳消息。通过这种方式,可以有效避免发送Rep集群中的发送节点在较长的一段时间内持续地向接收Rep集群中的故障的接收节点发送任务消息。
Rep集群之间可以通过节点之间的网络连接来互相发送各自的视图。在上文中已经结合图5、图6A和图6B详细阐述了Rep集群之间的网络传输管理的方法,此处不再赘述。
仍然结合参考图6A和图6B,Rep集群1包括三个节点,分别为主节点Rep 1-1、备份节点Rep 1-2和Rep 1-3,Rep集群2也包括三个节点,分别为主节点Rep 2-1、备份节点Rep2-2和Rep 2-3。根据本公开的实施例,视图可以描述集群中的每个节点的节点状态、节点地址和节点类型。
Rep集群1包括主节点Rep 1-1、备份节点Rep 1-2和Rep 1-3,Rep集群1的视图则可以包括每个节点的相关信息。例如,对于主节点Rep 1-1,视图可以包括指示Rep 1-1是主节点的节点类型信息、指示Rep 1-1的地址的地址信息以及指示Rep 1-1的状态的节点状态信息,该信息可以由三元组表示。同样。对于备份节点Rep 1-2,视图可以包括指示Rep 1-2是备份节点的节点类型信息、指示Rep 1-2的地址的地址信息以及指示Rep 1-2的状态的节点状态信息,该信息也可以由三元组表示。在一些示例中,节点状态可以包括激活状态、备份状态、故障状态和恢复状态中。Rep集群1可以定期地将其自身的视图发送到Rep集群2。通过这种方式,Rep集群2就可以知道Rep集群1的中的每个节点的状态。Rep集群1的视图可以被表示如下:
{
Rep 1-1: {
role: leader
ip: IP1
state: state1
};
Rep 1-2: {
role: standby
ip: IP2
state: state2
};
Rep 1-2: {
role: standby
ip: IP3
state: state2
};
}
其中,role指示节点的类型信息,ip指示节点的地址信息,state指示节点的状态信息。
同样,Rep集群2也可以定期地向Rep集群1发送其自身的视图,从而Rep集群1也可以知道Rep集群2中的每个节点的状态。如果Rep集群2中的备份节点Rep 2-2由于其所在的服务器死机而变得不可用,由于Rep集群2定期向Rep集群1发送其自身的视图,Rep集群1就可以迅速知道Rep集群2中的备份节点Rep 2-2发生故障,从而可以采取措施,以避免因为无法及时感知对方Rep集群中的接收节点的故障而可能导致的问题。例如,Rep集群1中的主节点Rep 1-1向Rep集群2中的备份节点Rep 2-2发送消息,由于Rep集群2定期向Rep集群1发送其自身的视图,Rep集群1及时获知了Rep集群2中的备份节点Rep 2-2发生了故障,从而可以采取其他方式来发送任务消息,避免由于持续向已经死机的备份节点Rep 2-2发送任务消息而导致的业务的长时间无响应。
图7示出了根据本公开的实施例的网络管理模块的示意图。如图所示,网络管理模块可以包括收发单元和通道选择单元。但是应当注意,本公开不限于此,网络管理模块还可以更多的单元。
收发单元可以用于接收Rep集群的地址信息。结合参考图5,例如,当Rep集群1想要向Rep集群2发送任务消息时,收发单元可以从上层业务接收Rep集群2的地址信息。在一些示例中,地址信息可以由包括Rep集群ID、服务类型和Rep节点名称的三元组来表示。
通道选择单元可以用于选择发送任务消息的通道。结合参考图5,例如,当Rep集群1的主节点Rep 1-1想要向Rep集群2的备份节点Rep 2-2发送任务消息时,通道选择单元可以从子会话2中选择一个通道(例如,通道1)来发送任务消息。当通道1发生故障时,通道选择单元可以从子会话2中剩余的通道2和通道3中选择一个通道来发送任务消息。当子会话2中的通道1、通道2和通道3均发生故障时,通道选择单元从子会话1或子会话3的通道中选择一个通道来发送任务消息。在示例中,通道选择单元可以随机或者基于负载均衡来选择通道。
图8示出了根据本公开的实施例的用于Rep服务的系统的操作方法的流程图。
如图所示,在步骤801,监控模块将Rep集群中包括的多个节点中的一个节点确定为Rep集群的当前主节点。
在用于Rep服务的系统中,每个Rep集群可以包括一个监控模块和多个节点。当Rep集群中的多个节点首次启动时,多个节点均处于创建状态。监控模块可以为多个节点中的每个节点分配节点号。多个节点中的每个节点分别向监控模块发送心跳消息。监控模块将最先接收到其心跳消息的节点确定为Rep集群的主节点。被确定为主节点的节点从创建状态切换到激活状态。
在步骤803,监控模块将Rep集群中包括的多个节点中的剩余节点确定为Rep集群的当前备份节点。
被确定为备份节点的节点从创建状态切换到备份状态。
在步骤805,监控模块监控Rep集群的当前主节点和备份节点的状态。
监控模块可以通过接收来自Rep集群的当前主节点和当前备份节点的心跳消息来确定节点的状态。当监控模块没有接收到来自节点的心跳消息,或者,当监控模块在特定时间间隔内没有接收到来自节点的心跳消息时,监控模块可以确定该节点发生故障,即处于故障状态。对于Rep集群的当前主节点,监控模块确定其从激活状态切换到故障状态。对于Rep集群的当前备份节点,监控模块确定其从备份状态切换到故障状态。
在示例中,当确定Rep集群的当前主节点处于故障状态时,监控模块可以从Rep集群的当前备份节点中选择一个备份节点作为新的主节点。在一些实施例中,监控模块可以从Rep集群的当前备份节点中随机选择一个节点作为Rep集群的新的主节点。在一些实施例中,监控模块可以从Rep集群的当前备份节点中选择节点号最小一个节点作为Rep集群的新的主节点。被确定为Rep集群的新的主节点的备份节点从备份状态切换到激活状态。
本领域技术人员在考虑说明书及实践本文公开的内容后,将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本公开的真正范围和精神由权利要求限定。

Claims (20)

1.一种用于远程复制Rep服务的系统,包括:
多个Rep集群,所述多个Rep集群中的每个Rep集群包括监控模块和多个节点,
其中,所述监控模块被配置为:
将所述多个节点中一个节点确定为当前主节点;
将所述多个节点中的剩余节点确定为当前备份节点;
监控当前主节点和当前备份节点的状态。
2.根据权利要求1所述的系统,其中,所述状态包括故障状态、激活状态、备份状态和恢复状态。
3. 根据权利要求1所述的系统,其中,监控当前主节点和当前备份节点的状态包括:
分别从当前主节点和当前备份节点接收心跳消息;以及
基于没有接收到心跳消息来确定当前主节点和/或当前备份节点处于故障状态。
4.根据权利要求3所述的系统,其中,所述监控模块还被配置为:
当确定当前主节点处于故障状态时,从处于备份状态的当前备份节点中选择一个节点作为新的主节点。
5.根据权利要求1所述的系统,其中,所述多个Rep集群中的每个Rep集群还包括网络管理模块,其中,所述多个Rep集群包括第一Rep集群和第二Rep集群,当第一Rep集群向第二Rep集群发送任务消息时,第一Rep集群中用于发送任务消息的节点为发送节点,第二Rep集群中用于接收任务消息的节点为接收节点;
其中,所述网络管理模块被配置为:
从上层业务接收第二Rep集群中的所述接收节点的地址;以及
随机或基于负载均衡在第一Rep集群中的所述发送节点与第二Rep集群中的所述接收节点之间的子会话的一个或多个通道中,确定用于发送所述任务消息的通道。
6.根据权利要求5所述的系统,其中,所述网络管理模块还被配置为:
当所确定的通道发生故障时,随机或基于负载均衡在第一Rep集群中的所述发送节点与第二Rep集群中的所述接收节点之间的子会话的剩余通道中,确定用于发送所述任务消息的通道;
当所述子会话的所述一个或多个通道均发生故障时,随机或基于负载均衡在第一Rep集群中的所述发送节点与第二Rep集群中的剩余节点之间的子会话的一个或多个通道中,确定用于发送所述任务消息的通道。
7.根据权利要求5所述的系统,其中,所述地址由包括Rep集群ID、服务类型和Rep节点名称的三元组表示。
8. 根据权利要求5所述的系统,其中,第一Rep集群被配置为:
定期向第二Rep集群发送第一Rep集群的视图;以及
定期从第二Rep集群接收第二Rep集群的视图。
9.根据权利要求8所述的系统,其中,所述视图包括Rep集群中的每个节点的节点类型、节点地址和节点状态信息。
10.根据权利要求8所述的系统,其中,第一Rep集群的视图和第二Rep集群的视图被包括在心跳消息中。
11.一种用于远程复制Rep服务的方法,包括,对于多个Rep集群中的每个Rep集群:
由监控模块将Rep集群包括的多个节点中的一个节点确定为当前主节点;
由监控模块将Rep集群包括的多个节点中的剩余节点确定为当前备份节点;以及
由监控模块监控当前主节点和当前备份节点的状态。
12.根据权利要求11所述的方法,其中,所述状态包括故障状态、激活状态、备份状态和恢复状态。
13. 根据权利要求11所述的方法,其中,由监控模块监控当前主节点和当前备份节点的状态包括:
由监控模块分别从当前主节点和当前备份节点接收心跳消息;以及
由监控模块基于没有接收到心跳消息来确定当前主节点和/或当前备份节点处于故障状态。
14.根据权利要求13所述的方法,还包括:
当确定当前主节点处于故障状态时,由监控模块从处于备份状态的当前备份节点中选择一个节点作为新的主节点。
15. 根据权利要求11所述的方法,还包括,当多个Rep集群中的第一Rep集群向第二Rep集群发送任务消息时,第一Rep集群中用于发送任务消息的节点为发送节点,第二Rep集群中用于接收任务消息的节点为接收节点,其中:
由网络管理模块从上层业务接收第二Rep集群中的所述接收节点的地址;以及
由网络管理模块随机或基于负载均衡在第一Rep集群中的所述发送节点与第二Rep集群中的所述接收节点之间的子会话的一个或多个通道中,确定用于发送所述任务消息的通道。
16.根据权利要求15所述的方法,还包括:
当所确定的通道发生故障时,由网络管理模块随机或基于负载均衡在第一Rep集群中的所述发送节点与第二Rep集群中的所述接收节点之间的子会话的剩余通道中,确定用于发送所述任务消息的通道;
当所述子会话的所述一个或多个通道均发生故障时,由网络管理模块随机或基于负载均衡在第一Rep集群中的所述发送节点与第二Rep集群中的剩余节点之间的子会话的一个或多个通道中,确定用于发送所述任务消息的通道。
17.根据权利要求15所述的方法,其中,所述地址由包括Rep集群ID、服务类型和Rep节点名称的三元组表示。
18. 根据权利要求15所述的方法,还包括:
第一Rep集群定期向第二Rep集群发送第一Rep集群的视图;以及
第一Rep集群定期从第二Rep集群接收第二Rep集群的视图。
19.根据权利要求18所述的方法,其中,所述视图包括Rep集群中的每个节点的节点类型、节点地址和节点状态。
20.根据权利要求18所述的方法,其中,第一Rep集群的视图和第二Rep集群的视图被包括在心跳消息中。
CN202310882604.2A 2023-07-19 2023-07-19 用于远程复制服务的系统及其操作方法 Pending CN116614348A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310882604.2A CN116614348A (zh) 2023-07-19 2023-07-19 用于远程复制服务的系统及其操作方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310882604.2A CN116614348A (zh) 2023-07-19 2023-07-19 用于远程复制服务的系统及其操作方法

Publications (1)

Publication Number Publication Date
CN116614348A true CN116614348A (zh) 2023-08-18

Family

ID=87682183

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310882604.2A Pending CN116614348A (zh) 2023-07-19 2023-07-19 用于远程复制服务的系统及其操作方法

Country Status (1)

Country Link
CN (1) CN116614348A (zh)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103607297A (zh) * 2013-11-07 2014-02-26 上海爱数软件有限公司 一种计算机集群系统的故障处理方法
CN105141456A (zh) * 2015-08-25 2015-12-09 山东超越数控电子有限公司 一种高可用集群资源监控方法
WO2016150050A1 (zh) * 2015-03-24 2016-09-29 新余兴邦信息产业有限公司 高可用高性能数据库集群的实现方法及系统
CN113572831A (zh) * 2021-07-21 2021-10-29 重庆星环人工智能科技研究院有限公司 Kubernetes集群间的通信方法、计算机设备及介质
CN114385755A (zh) * 2021-12-30 2022-04-22 苏州中科先进技术研究院有限公司 一种分布式存储系统
CN116346605A (zh) * 2023-03-17 2023-06-27 浙江天正电气股份有限公司 集群服务系统的控制方法、装置、智能终端及存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103607297A (zh) * 2013-11-07 2014-02-26 上海爱数软件有限公司 一种计算机集群系统的故障处理方法
WO2016150050A1 (zh) * 2015-03-24 2016-09-29 新余兴邦信息产业有限公司 高可用高性能数据库集群的实现方法及系统
CN105141456A (zh) * 2015-08-25 2015-12-09 山东超越数控电子有限公司 一种高可用集群资源监控方法
CN113572831A (zh) * 2021-07-21 2021-10-29 重庆星环人工智能科技研究院有限公司 Kubernetes集群间的通信方法、计算机设备及介质
CN114385755A (zh) * 2021-12-30 2022-04-22 苏州中科先进技术研究院有限公司 一种分布式存储系统
CN116346605A (zh) * 2023-03-17 2023-06-27 浙江天正电气股份有限公司 集群服务系统的控制方法、装置、智能终端及存储介质

Similar Documents

Publication Publication Date Title
US10911295B2 (en) Server apparatus, cluster system, cluster control method and program
EP2224341B1 (en) Node system, server switching method, server device, and data transfer method
CN112181660A (zh) 一种基于服务器集群的高可用方法
CN103546914A (zh) 一种hss主备管理的方法及装置
CN101056254B (zh) 一种网络存储设备的扩展方法、系统及其装置
CN103560955A (zh) 冗余设备切换方法及装置
CN113132159B (zh) 存储集群节点故障的处理方法、设备及存储系统
CN110704250A (zh) 一种分布式系统的热备份装置
CN101237314A (zh) 一种保障复制业务传输的方法及接入设备
CA2743680A1 (en) Method and system for fail-safe call survival
CN110971662A (zh) 一种基于Ceph的两节点高可用实现方法及装置
CN109981353B (zh) 一种机框式网络通信设备中的邻站冗余保护方法及系统
CN113162797B (zh) 一种分布式集群的主节点故障的切换方法、系统及介质
CA2401635A1 (en) Multiple network fault tolerance via redundant network control
CN111953808A (zh) 一种双机双活架构的数据传输切换方法及架构构建系统
CN105245361A (zh) 用于Linux系统的数据高可用系统、方法和装置
CN110830310B (zh) 一种跨数据中心的灾难备份方法及bras系统
CN116614348A (zh) 用于远程复制服务的系统及其操作方法
CN111522698B (zh) 前端处理器的自动切换系统及方法
CN116346582A (zh) 一种实现主备双网冗余方法、装置、设备及存储介质
JP4879823B2 (ja) 監視制御システム
JP4781696B2 (ja) Ip電話システム
WO2014030732A1 (ja) 通信システム、通信装置、プロテクション切り替え方法および切り替えプログラム
KR100832543B1 (ko) 계층적 다중 백업 구조를 갖는 고가용성 클러스터 시스템및 이를 이용한 고가용성 구현 방법
CN115408199A (zh) 一种边缘计算节点的容灾处理方法及装置

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
RJ01 Rejection of invention patent application after publication

Application publication date: 20230818

RJ01 Rejection of invention patent application after publication