WO2022254517A1 - 通信システム及び通信制御方法 - Google Patents

通信システム及び通信制御方法 Download PDF

Info

Publication number
WO2022254517A1
WO2022254517A1 PCT/JP2021/020675 JP2021020675W WO2022254517A1 WO 2022254517 A1 WO2022254517 A1 WO 2022254517A1 JP 2021020675 W JP2021020675 W JP 2021020675W WO 2022254517 A1 WO2022254517 A1 WO 2022254517A1
Authority
WO
WIPO (PCT)
Prior art keywords
bfdd
transmission
cluster
bfd
address
Prior art date
Application number
PCT/JP2021/020675
Other languages
English (en)
French (fr)
Inventor
一成 竹内
Original Assignee
楽天モバイル株式会社
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 楽天モバイル株式会社 filed Critical 楽天モバイル株式会社
Priority to US17/906,746 priority Critical patent/US20240205139A1/en
Priority to PCT/JP2021/020675 priority patent/WO2022254517A1/ja
Publication of WO2022254517A1 publication Critical patent/WO2022254517A1/ja

Links

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/26—Route discovery packet
    • 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/28—Routing or path finding of packets in data switching networks using route fault recovery

Definitions

  • the present invention relates to a communication system and a communication control method.
  • a bidirectional forwarding detection daemon that detects path failures between a first bfdd and a second bfdd by sending and receiving BFD packets to and from each other
  • BFD forwarding detection
  • Patent Literature 1 describes detecting that a primary pseudowire is in a failed state through a Bidirectional Forwarding Detection (BFD) session.
  • the first bfdd periodically sends BFD packets to the second bfdd at short time intervals (e.g., every few milliseconds) regardless of whether the second bfdd is operating normally. Send to
  • the second bfdd cannot properly process the BFD packets transmitted from the first bfdd due to, for example, a failure occurring in the node where the second bfdd is running. be done. While such a situation occurs, BFD packets transmitted from the first bfdd are not effectively used, and the transmission of BFD packets by the first bfdd results in wasted traffic.
  • the present invention has been made in view of the above circumstances, and one of its objects is to provide a communication system and a communication control method that can suppress the generation of wasteful traffic due to the transmission of BFD packets that are not effectively used. .
  • a communication system is a communication system including a first bidirectional transfer detection daemon (bfdd), wherein the first bfdd is included in a communication partner of the communication system. sending and receiving BFD packets to and from each other with a second bfdd that is a bfdd that is the bfdd that is the second bfdd, and in response to detecting no transmission of BFD packets from the second bfdd, the second bfdd by the first bfdd and transmission limiting means for limiting transmission of BFD packets to.
  • bfdd bidirectional transfer detection daemon
  • the transmission limiting means lengthens the transmission interval of BFD packets from the first bfdd to the second bfdd in response to the detection.
  • the transmission limiting means stops transmission of BFD packets from the first bfdd to the second bfdd in response to the detection.
  • transmission restriction cancellation for releasing the restriction on transmission of the BFD packet in response to detection of recovery of bfdd included in the communication partner further comprising means.
  • This aspect further includes address data receiving means for receiving address data indicating the address of a third bfdd which is the bfdd included in the communication partner after recovery, and the transmission restriction releasing means receives the address data. , the restriction on transmission of the BFD packets may be lifted.
  • it further includes address data acquisition means for accessing a storage unit storing address data indicating an address of bfdd included in the communication partner and acquiring the address data, wherein the transmission restriction release means Restrictions on transmission of said BFD packets may be lifted in response to detection of a change in the indicated address.
  • a first bidirectional transfer detection daemon (bfdd) included in a communication system transmits a BFD packet to a second bfdd which is bfdd included in a communication partner of the communication system.
  • FIG. 1 is a diagram showing the configuration of a computer system in which a cluster of nodes executing containerized applications is built;
  • FIG. 13 shows an example of a DNS record stored in coredns of a GC cluster;
  • 1 is a diagram showing the configuration of a computer system in which a cluster of nodes executing containerized applications is built;
  • FIG. 4 is a flow chart showing an example of the flow of processing executed by a GC cluster according to an embodiment of the present invention; 4 is a flow chart showing an example of the flow of processing executed by a GC cluster according to an embodiment of the present invention;
  • FIG. 1 is a diagram showing an example of a communication system 10 according to one embodiment of the present invention.
  • a communication system 10 according to this embodiment includes a GC cluster 12 and a CDC cluster 14.
  • the GC cluster 12 and the CDC cluster 14 according to this embodiment are computer systems in which clusters of nodes (computers and servers) that execute containerized applications are constructed.
  • the GC cluster 12 is a cluster built in a GC (Group Unit Center) station of a mobile communication carrier.
  • the CDC cluster 14 is a raster built in the CDC (Central Data Center) of a mobile telecommunications carrier.
  • a cluster according to this embodiment is a set of nodes on which software (specifically Kubernetes) for managing containerized workloads and services is installed. Also, the cluster according to the present embodiment is a Kubernetes cluster that defines a range in which pods, which are containerized applications, can be managed by Kubernetes. A Kubernetes cluster can also be said to be a set of multiple nodes on which Kubernetes can deploy pods.
  • the communication system 10 includes a plurality of GC clusters 12 and a plurality of CDC clusters 14, one GC cluster 12 and one CDC cluster 14 are representatively shown in FIG.
  • the GC cluster 12 is connected to the CDC cluster 14 via the WAN 16 including the L2 communication section.
  • the GC cluster 12 includes multiple master nodes 20 (master node 20a, master node 20b, master node 20c) and multiple worker nodes 22 (one node is shown in FIG. 1).
  • the pod 24 can also be said to be a CNF (Cloud-native Network Function) instance.
  • CNF Cloud-native Network Function
  • An envoy 26 is also placed in the worker node 22 .
  • the envoy 26 can be said to be a proxy unit that hooks transmission data output from a transmission source application defined by a known service mesh and transmits the transmission data to a transmission destination application according to a predetermined communication protocol. .
  • Each of the multiple master nodes 20 is a node that manages multiple worker nodes 22 and multiple pods 24 .
  • the GC cluster 12 includes a data store section 28.
  • the data store unit 28 includes, for example, kube-apiserver, which is a component of Kubernetes, and a data store such as etcd.
  • the GC cluster 12 also includes a Custom Resource Controller (CRC) 30 and a bidirectional transfer detection daemon (bfdd) 32 .
  • CRC 30 is located on master node 20c and bfdd 32 is located on master node 20a. Note that in the present embodiment, CRC 30 and bfdd 32 are not instantiated until setup related to initial settings described below is performed.
  • the GC cluster 12 also includes coredns 34 that resolves the name of the destination of the target data for the pods 26 within the cluster.
  • coredns 34 is located in master node 20a.
  • the CDC cluster 14 includes a plurality of master nodes 40 (master node 40a, master node 40b, master node 40c) and a plurality of worker nodes 42 (one node is shown in FIG. 1). included.
  • a pod 44 which is an application that executes various data processing (business processing, etc.) and is a containerized application, is deployed to the worker node 42.
  • the pod 44 can also be said to be a CNF (Cloud-native Network Function) instance.
  • CNF Cloud-native Network Function
  • An envoy 46 is also placed in the worker node 42 .
  • the envoy 46 can be said to be a proxy unit that hooks transmission data output from a transmission source application defined by a known service mesh and transmits the transmission data to a transmission destination application according to a predetermined communication protocol. .
  • Each of the multiple master nodes 40 is a node that manages multiple worker nodes 42 and multiple pods 44 .
  • the CDC cluster 14 includes a data store section 48.
  • the data store unit 48 includes, for example, kube-apiserver, which is a component of Kubernetes, and a data store such as etcd.
  • the CDC cluster 14 includes CRC50 and bfdd52.
  • CRC 50 is located at master node 40c and bfdd 52 is located at master node 40a.
  • address data indicating the IP address of bfdd52 and authentication information required for authentication of bfdd52 are registered in advance in the data store unit 48 of the CDC cluster 14 .
  • a plug-in definition for handling the information of the opposite cluster is registered in the data store unit 28 of the GC cluster 12 by the operation of the developer, for example. be.
  • the GC cluster 12 then instantiates the Custom Resource Controller (CRC) 30 .
  • CRC Custom Resource Controller
  • the instantiation of CRC 30 is performed for master node 20c.
  • the CRC 30 also instantiates a bidirectional transfer detection daemon (bfdd) 32 within the GC cluster 12 .
  • bfdd bidirectional transfer detection daemon
  • an instantiation of bfdd32 is executed for the master node 20a.
  • address data indicating the IP address of bfdd32 and authentication information necessary for authentication of bfdd32 are registered in the data store unit 28 of the GC cluster 12 .
  • resource information (Custom Resource) related to the opposing cluster (eg, the CDC cluster 14) is registered, for example, by a developer's operation.
  • the resource information to be registered is, for example, the address of the CDC cluster 14 (for example, the IP address and domain name of the kube-apiserver included in the data store unit 48) and the user information necessary for establishing communication with the CDC cluster 14. It is information indicating authentication information (credentials) such as name and password.
  • the CRC 30 of the GC cluster 12 reads the registered resource information and performs connection (negotiation) with the CDC cluster 14 .
  • the connection uses the address of the CDC cluster 14 indicated in the resource information. Also, in the connection, authentication using the authentication information indicated in the resource information is also performed.
  • the GC cluster 12 transmits to the CDC cluster 14 address data indicating the IP address of bfdd32 and authentication information required for authentication of bfdd32. Then, the CDC cluster 14 transmits address data indicating the IP address of the bfdd 52 and authentication information necessary for authenticating the bfdd 52 to the GC cluster 12 as a response to the transmission.
  • the CRC 30 of the GC cluster 12 registers the resource information of the CDC cluster 14 in the data store section 48 of the CDC cluster 14 .
  • the CDC cluster 14 may register the resource information of the CDC cluster 14 in the data store unit 48 of the CDC cluster 14 .
  • the CDC cluster 14 also registers the address data indicating the IP address of the bfdd32 received from the GC cluster 12 and the authentication information necessary for authenticating the bfdd32 in the data store unit 48 .
  • the GC cluster 12 also registers the address data indicating the IP address of the bfdd 52 received from the CDC cluster 14 and the authentication information necessary for authenticating the bfdd 52 in the data store unit 28 .
  • the GC cluster 12 can identify the IP address of bfdd 52 by referring to the address data registered in the data store unit 28 . Also, the CDC cluster 14 can specify the IP address of the bfdd 32 by referring to the address data registered in the data store unit 48 .
  • CRC30 instructs bfdd32 to establish a connection with bfdd52.
  • negotiation between bfdd32 and bfdd52 is then executed.
  • a communication bidirectional forwarding detection (BFD) session
  • BFD bidirectional forwarding detection
  • BFD packet communication according to the BFD protocol is started between bfdd32 and bfdd52.
  • the bfdd 32 exchanges BFD packets with the bfdd 52 included in the CDC cluster 14, which is the communication partner.
  • the bfdd 52 exchanges BFD packets with the bfdd 32 included in the GC cluster 12, which is the communication partner.
  • BFD packets are transmitted at intervals of several milliseconds.
  • the DNS record 60 illustrated in FIG. 2 is an A record 62 that associates the destination virtual domain name (pod.example.com) corresponding to the group including the pod 44 of the CDC cluster 14 with the IP address of the pod 44 of the CDC cluster 14. including.
  • the destination virtual domain name pod.example.com
  • the pod 24 of the GC cluster 12 transmits data related to application processing (hereinafter also referred to as "target data") to the pod 44 of the CDC cluster 14 via envoy26 and envoy46.
  • the target data includes, for example, the processing results of the pods 24 deployed within the GC cluster 12 .
  • the pod 24 of the GC cluster 12 requests, for example, the coredns 34 to resolve the destination pod name (for example, the destination virtual domain name obtained by virtualizing multiple pods including pod 44).
  • the coredns 34 returns the IP address of the pod 44 to the pod 24 within its own cluster based on the DNS record 60 .
  • the pod24 transmits the target data to the pod44 of the CDC cluster 14 based on the IP address of the pod44 provided by the coredns21.
  • bfdd32 detects that there is no transmission of BFD packets from bfdd52 (for example, bfdd32 has stopped receiving BFD packets from bfdd52 for a predetermined period of time or longer).
  • the CRC 30 restricts transmission of BFD packets by bdff 32 to bfdd 52 in response to detection of no transmission of BFD packets from bfdd 52 .
  • the CRC 30 may lengthen the transmission interval of the BFD packets from the bdff 32 to the bfdd 52 in response to detection of no BFD packet transmission from the bfdd 52 .
  • the CRC 30 may set the transmission interval of BFD packets from bdff 32 to bfdd 52 to several seconds or several tens of seconds (eg, 20 to 60 seconds).
  • the CRC 30 may stop transmission of BFD packets by bdff 32 to bfdd 52 in response to detecting no transmission of BFD packets from bfdd 52 .
  • the CRC 50 detects the disappearance of the bfdd 52. Then, the CRC 50 restores the bfdd included in the CDC cluster 14 in response to detection of loss of the bfdd 52 .
  • bfdd 54 restored in this manner is shown in master node 40b.
  • an IP address different from bfdd52 is set to bfdd54.
  • the CRC 50 updates the address data indicating the IP address of the bfdd 52 registered in the data store unit 48 of the CDC cluster 14 to the address data indicating the changed IP address (the IP address set in the bfdd 54). .
  • the CRC 50 may register authentication information required for authentication of the bfdd 54 in the data store section 48 .
  • the CRC 30 detects recovery of bfdd included in the CDC cluster 14 when, for example, transmission of BFD packets is restricted in this embodiment.
  • the CRC 30 lifts the restriction on transmission of BFD packets in response to detection of recovery of bfdd included in the CDC cluster 14 .
  • the CRC 30 may output a pairing change instruction from bfdd52 to bfdd54 to bfdd32.
  • bfdd 32 may establish a BFD session with bfdd 54 in response to receiving the pairing change instruction.
  • normal BFD packet communication according to the BFD protocol may be started between bfdd 32 and bfdd 54 .
  • BFD packets may be transmitted at intervals of several milliseconds.
  • the CRC 50 may send address data indicating the address of the bfdd 54, which is the bfdd included in the CDC cluster 14 after restoration, to the GC cluster 12. . Then, the CRC 30 included in the GC cluster 12 may receive the address data. Then, the CRC 30 may release the restriction on transmission of BFD packets in response to receiving the address data.
  • the CRC 50 may send authentication information required for authentication of the bfdd 54 to the GC cluster 12 . The CRC 30 may then receive the authentication information.
  • the CRC 30 accesses the data store unit 48 at predetermined time intervals (eg, 30-second to 1-minute intervals) to obtain the bfdd address (eg, IP address) may be acquired.
  • predetermined time intervals eg, 30-second to 1-minute intervals
  • the bfdd address eg, IP address
  • the CRC 30 may detect a change in the address indicated by the acquired address data. Then, the CRC 30 may release the restriction on transmission of BFD packets in response to detection of a change in the address indicated by the acquired address data.
  • the CRC 30 may acquire authentication information required for authentication of the bfdd 54 from the data store section 48 .
  • the CRC 30 changes the address data indicating the IP address of the bfdd 52 registered in the data store unit 28 of the GC cluster 12 to the changed IP address ( address data indicating the IP address set in bfdd54).
  • the CRC 30 may register authentication information required for authentication of the bfdd 54 in the data store section 28 .
  • the CRC 30 may rewrite the DNS record 60 registered in the coredns 21 in response to detection of no BFD packet transmission from the bfdd 54 .
  • an A record 62 included in the DNS record 60 is an A The record 62 may be rewritten.
  • the CRC 30 serves as a transmission restriction unit that restricts transmission of BFD packets from bfdd 32 to bfdd 52 in response to detection of no transmission of BFD packets from bfdd 52. I am in charge.
  • the CRC 30 plays a role as a transmission restriction release unit that releases the restriction on transmission of BFD packets in response to detection of recovery of bfdd included in the CDC cluster 14 when transmission of BFD packets is restricted. ing.
  • the CRC 30 may also serve as an address data receiving unit that receives address data indicating the address of bfdd 54, which is a bfdd included in the CDC cluster 14 after recovery.
  • the CRC 30 may also serve as an address data acquisition section that accesses the data store section 48 that stores address data indicating the address of bfdd included in the CDC cluster 14 and acquires the address data.
  • FIGS. 1 and 3 include block diagrams showing functional blocks included in each component of the communication system 10.
  • FIG. Each block shown in the block diagram of FIG. 1 or FIG. 3 can be realized by hardware such as a CPU and memory of a computer or by a mechanical device, and can be realized by a computer program or the like in terms of software. , here, the functional blocks realized by their cooperation are drawn. It should be understood by those skilled in the art that these functional blocks can be implemented in various ways by combining hardware and software.
  • the bfdd 32 transmits BFD packets to the bfdd 52 at predetermined time intervals (for example, at intervals of several milliseconds), and monitors (stands by) the reception of the BFD packets transmitted from the bfdd 52 (S101). .
  • CRC30 instructs bfdd32 to limit the transmission of BFD packets.
  • the bfdd 32 then restricts transmission of BFD packets as described above (S102).
  • the CRC 30 monitors (waits for) reception of address data from the CRC 50 (S103).
  • the CRC 30 When the CRC 30 detects the reception of the address data from the CRC 50, the CRC 30 releases the BFD packet transmission restriction (S104), and the processing shown in this processing example ends.
  • the CRC 30 accesses the data store unit 48 at predetermined time intervals (for example, intervals of 30 seconds to 1 minute) and acquires address data indicating the IP address of bfdd included in the CDC cluster 14. It is assumed that
  • bfdd 32 transmits BFD packets to bfdd 52 at predetermined time intervals (for example, at intervals of several milliseconds), and monitors (stands by) reception of BFD packets transmitted from bfdd 52 ( S201).
  • CRC30 instructs bfdd32 to limit the transmission of BFD packets.
  • the bfdd 32 then limits transmission of BFD packets as described above (S202).
  • the CRC 30 monitors changes in the address (for example, IP address) indicated by the address data acquired at predetermined time intervals (S203).
  • the CRC 30 When the CRC 30 detects a change in the address indicated by the address data, the CRC 30 releases the BFD packet transmission restriction (S204), and the processing shown in this processing example ends.
  • the CRC 30 acquires the address data indicating the IP address of the bfdd included in the CDC cluster 14 at predetermined time intervals in advance. For example, when the transmission of BFD packets is restricted, the CRC 30 acquires address data indicating IP addresses of bfdds included in the CDC cluster 14 and registered in the data store unit 48 at predetermined time intervals. may be started.
  • the CRC 30 may output to bfdd32 a pairing change instruction from bfdd52 to bfdd54.
  • a BFD session may then be established between bfdd32 and bfdd54.
  • updating of address data registered in the data store unit 28 and registration of authentication information may be performed together.
  • the CRC 30 monitors reception of address data from the CRC 50 and, at predetermined time intervals, sends an address indicating the IP address of bfdd included in the CDC cluster 14 registered in the data store unit 48 . Both data acquisition may be performed. Then, the restriction on transmission of BFD packets may be lifted in response to detection of either the reception of the address data from the CRC 50 or the change of the address indicated by the address data.
  • access from bfdd 54 to bfdd 32 may occur in accordance with recovery of bfdd included in the CDC cluster 14 . Then, the restriction on transmission of BFD packets may be lifted in response to detection of occurrence of access from bfdd 54 to bfdd 32 .
  • a situation may occur in which the bfdd52 cannot properly process the BFD packets sent from the bfdd32, such as when a failure occurs in the master node 40a. While such a situation is occurring, the BFD packets transmitted from bfdd 32 are not effectively used, and the transmission of BFD packets by bfdd 32 results in wasted traffic.
  • the GC cluster 12 restricts BFD packet transmission by bfdd32 in response to detection of no BFD packet transmission from bfdd52. In this manner, according to the present embodiment, it is possible to suppress generation of wasteful traffic due to transmission of BFD packets that are not effectively used.
  • one CRC 30 may be responsible for connection (negotiation) with the opposing cluster, and another CRC 30 may be responsible for limiting transmission of BFD packets. These CRCs 30 may then be arranged in separate master nodes 20 .
  • the GC cluster 12 may further include the CRC 50, or the CRC 30 having the function of the CRC 50 may operate in the GC cluster 12.
  • the CDC cluster 14 may further include the CRC 30 , or the CRC 50 having the functions of the CRC 30 may operate in the CDC cluster 14 .
  • bfdd 32 and coredns 34 may operate on the same master node 20 or on different master nodes 20 .
  • the CRC 30 and the bfdd 32 may operate on the same master node 20 or may operate on different master nodes 20 .
  • the CRC 30 and the coredns 34 may operate on the same master node 20 or may operate on different master nodes 20 .
  • the CRC 50 and the bfdd 52 may operate on the same master node 40 or may operate on different master nodes 40 .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

有効活用されないＢＦＤパケットの送信による無駄なトラフィックの発生を抑制できる通信システム及び通信制御方法を提供する。ｂｆｄｄ（３２）は、ＣＤＣクラスタ（１４）に含まれるｂｆｄｄ（５２）との間で互いにＢＦＤパケットを送受信する。ＣＲＣ（３０）は、ｂｆｄｄ（５２）からのＢＦＤパケットの送信がないことの検出に応じて、ｂｆｄｄ（３２）によるｂｆｄｄ（５２）へのＢＦＤパケットの送信を制限する。

Description

通信システム及び通信制御方法
　本発明は、通信システム及び通信制御方法に関する。
　第１の双方向転送検出デーモン（ｂｆｄｄ）と第２のｂｆｄｄとの間で互いにＢＦＤパケットを送受信することで、第１のｂｆｄｄと第２のｂｆｄｄとの間のパスの障害を検出する双方向転送検出（ＢＦＤ）プロトコルが存在する。ＢＦＤプロトコルを用いた障害検出技術の一例として、特許文献１には、双方向転送検出（ＢＦＤ）セッションによって、プライマリ疑似回線が障害状態になったことを検出することが記載されている。
国際公開第２０１８／０５０１２０号
　ＢＦＤプロトコルでは、第１のｂｆｄｄは、第２のｂｆｄｄが正常に動作しているか否かに関わらず、第２のｂｆｄｄにＢＦＤパケットを短い時間間隔で（例えば、数ミリ秒間隔で）定期的に送信する。
　ここで例えば、第２のｂｆｄｄが稼働しているノードで障害が発生するなどして、第１のｂｆｄｄから送信されたＢＦＤパケットを第２のｂｆｄｄが適切に処理できない状況が発生することが考えられる。このような状況が発生している間は、第１のｂｆｄｄから送信されるＢＦＤパケットは有効活用されず、第１のｂｆｄｄによるＢＦＤパケットの送信は無駄なトラフィックとなる。
　本発明は上記実情に鑑みてなされたものであって、その目的の一つは、有効活用されないＢＦＤパケットの送信による無駄なトラフィックの発生を抑制できる通信システム及び通信制御方法を提供することにある。
　上記課題を解決するために、本発明に係る通信システムは、第１の双方向転送検出デーモン（ｂｆｄｄ）を含む通信システムであって、前記第１のｂｆｄｄは、前記通信システムの通信相手に含まれるｂｆｄｄである第２のｂｆｄｄとの間で互いにＢＦＤパケットを送受信し、前記第２のｂｆｄｄからのＢＦＤパケットの送信がないことの検出に応じて、前記第１のｂｆｄｄによる前記第２のｂｆｄｄへのＢＦＤパケットの送信を制限する送信制限手段、を含む。
　本発明の一態様では、前記送信制限手段は、前記検出に応じて、前記第１のｂｆｄｄによる前記第２のｂｆｄｄへのＢＦＤパケットの送信間隔を長くする。
　あるいは、前記送信制限手段は、前記検出に応じて、前記第１のｂｆｄｄによる前記第２のｂｆｄｄへのＢＦＤパケットの送信を停止する。
　また、本発明の一態様では、前記ＢＦＤパケットの送信が制限されている際における、前記通信相手に含まれるｂｆｄｄの復旧の検出に応じて、前記ＢＦＤパケットの送信の制限を解除する送信制限解除手段、をさらに含む。
　この態様では、復旧後における前記通信相手に含まれるｂｆｄｄである第３のｂｆｄｄのアドレスを示すアドレスデータを受信するアドレスデータ受信手段、をさらに含み、前記送信制限解除手段は、前記アドレスデータの受信に応じて、前記ＢＦＤパケットの送信の制限を解除してもよい。
　あるいは、前記通信相手に含まれるｂｆｄｄのアドレスを示すアドレスデータを記憶する記憶部にアクセスして当該アドレスデータを取得するアドレスデータ取得手段、をさらに含み、前記送信制限解除手段は、前記アドレスデータが示すアドレスの変更の検出に応じて、前記ＢＦＤパケットの送信の制限を解除してもよい。
　また、本発明に係る通信制御方法は、通信システムに含まれる第１の双方向転送検出デーモン（ｂｆｄｄ）が、前記通信システムの通信相手に含まれるｂｆｄｄである第２のｂｆｄｄにＢＦＤパケットを送信するステップと、前記第１のｂｆｄｄが前記第２のｂｆｄｄから送信されるＢＦＤパケットを受信するステップと、前記第２のｂｆｄｄからのＢＦＤパケットの送信がないことの検出に応じて、前記第１のｂｆｄｄによる前記第２のｂｆｄｄへのＢＦＤパケットの送信を制限するステップと、を含む。
コンテナ化されたアプリケーションを実行するノードのクラスタが構築されたコンピュータシステムの構成を示す図である。 ＧＣクラスタのｃｏｒｅｄｎｓに記憶されるＤＮＳレコードの例を示す図である。 コンテナ化されたアプリケーションを実行するノードのクラスタが構築されたコンピュータシステムの構成を示す図である。 本発明の一実施形態に係るＧＣクラスタで実行される処理の流れの一例を示すフローチャートである。 本発明の一実施形態に係るＧＣクラスタで実行される処理の流れの一例を示すフローチャートである。
　以下、本発明の一実施形態について図面に基づき詳細に説明する。
　図１は、本発明の一実施形態に係る通信システム１０の一例を示す図である。図１に示すように、本実施形態に係る通信システム１０には、ＧＣクラスタ１２と、ＣＤＣクラスタ１４と、が含まれる。本実施形態に係るＧＣクラスタ１２や、ＣＤＣクラスタ１４は、コンテナ化されたアプリケーションを実行するノード（コンピュータ、サーバとも言える）のクラスタが構築されたコンピュータシステムである。
　ＧＣクラスタ１２は、移動体通信事業者のＧＣ（Ｇｒｏｕｐ　Ｕｎｉｔ　Ｃｅｎｔｅｒ）局に構築されたクラスタである。
　ＣＤＣクラスタ１４は、移動体通信事業者のＣＤＣ（Ｃｅｎｔｒａｌ　Ｄａｔａ　Ｃｅｎｔｅｒ）に構築されたラスタである。
　本実施形態に係るクラスタは、コンテナ化されたワークロードやサービスを管理するソフトウェア（具体的にはクバネテス）がインストールされたノードのセットである。また、本実施形態に係るクラスタは、クバネテスがコンテナ化されたアプリケーションであるｐｏｄを管理可能な範囲を定めたクバネテスクラスタである。クバネテスクラスタは、クバネテスがｐｏｄをデプロイ可能な複数のノードのセットであるとも言える。
　通信システム１０には、複数のＧＣクラスタ１２と複数のＣＤＣクラスタ１４とが含まれるが、図１には１つのＧＣクラスタ１２と１つのＣＤＣクラスタ１４とが代表して示されている。
　ＧＣクラスタ１２は、Ｌ２通信区間を含むＷＡＮ１６を介して、ＣＤＣクラスタ１４に接続される。
　ＧＣクラスタ１２には、複数のマスタノード２０（マスタノード２０ａ、マスタノード２０ｂ、マスタノード２０ｃ）と、複数のワーカノード２２（図１には１つのノードを図示）とが含まれる。
　ワーカノード２２には、各種データ処理（業務処理等）を実行するアプリケーションであり、コンテナ化されたアプリケーションであるｐｏｄ２４がデプロイされる。ｐｏｄ２４は、ＣＮＦ（Ｃｌｏｕｄ－ｎａｔｉｖｅ　Ｎｅｔｗｏｒｋ　Ｆｕｎｃｔｉｏｎ）インスタンスとも言える。
　また、ワーカノード２２には、ｅｎｖｏｙ２６も配置される。ｅｎｖｏｙ２６は、公知のサービスメッシュにより規定された、送信元アプリケーションから出力された送信データをフックし、所定の通信プロトコルにしたがって、その送信データを送信先アプリケーションへ送信することを代行するプロキシ部と言える。
　複数のマスタノード２０のそれぞれは、複数のワーカノード２２および複数のｐｏｄ２４を管理するノードである。
　また、図１の例では、ＧＣクラスタ１２には、データストア部２８が含まれる。データストア部２８は、例えば、クバネテスのコンポーネントである、ｋｕｂｅ－ａｐｉｓｅｒｖｅｒや、ｅｔｃｄ等のデータストア、などを含んで構成されている。
　また、ＧＣクラスタ１２には、Ｃｕｓｔｏｍ　Ｒｅｓｏｕｒｃｅ　Ｃｏｎｔｒｏｌｌｅｒ（ＣＲＣ）３０、及び、双方向転送検出デーモン（ｂｆｄｄ）３２が含まれる。図１の例では、ＣＲＣ３０は、マスタノード２０ｃに配置されており、ｂｆｄｄ３２は、マスタノード２０ａに配置されている。なお、本実施形態では、以下で説明する初期設定に係るセットアップがされるまでは、ＣＲＣ３０及びｂｆｄｄ３２のインスタンシエーションはされていない。
　また、ＧＣクラスタ１２には、クラスタ内のｐｏｄ２６に対して、対象データの送信先の名前解決を行うｃｏｒｅｄｎｓ３４も含まれている。図１の例では、ｃｏｒｅｄｎｓ３４は、マスタノード２０ａに配置されている。
　図１に示すように、ＣＤＣクラスタ１４には、複数のマスタノード４０（マスタノード４０ａ、マスタノード４０ｂ、マスタノード４０ｃ）と、複数のワーカノード４２（図１には１つのノードを図示）とが含まれる。
　ワーカノード４２には、各種データ処理（業務処理等）を実行するアプリケーションであり、コンテナ化されたアプリケーションであるｐｏｄ４４がデプロイされる。ｐｏｄ４４は、ＣＮＦ（Ｃｌｏｕｄ－ｎａｔｉｖｅ　Ｎｅｔｗｏｒｋ　Ｆｕｎｃｔｉｏｎ）インスタンスとも言える。
　また、ワーカノード４２には、ｅｎｖｏｙ４６も配置される。ｅｎｖｏｙ４６は、公知のサービスメッシュにより規定された、送信元アプリケーションから出力された送信データをフックし、所定の通信プロトコルにしたがって、その送信データを送信先アプリケーションへ送信することを代行するプロキシ部と言える。
　複数のマスタノード４０のそれぞれは、複数のワーカノード４２および複数のｐｏｄ４４を管理するノードである。
　また、図１の例では、ＣＤＣクラスタ１４には、データストア部４８が含まれる。データストア部４８は、例えば、クバネテスのコンポーネントである、ｋｕｂｅ－ａｐｉｓｅｒｖｅｒと、ｅｔｃｄ等のデータストアと、を含んで構成されている。
　また、ＣＤＣクラスタ１４には、ＣＲＣ５０、及び、ｂｆｄｄ５２が含まれる。図１の例では、ＣＲＣ５０は、マスタノード４０ｃに配置されており、ｂｆｄｄ５２は、マスタノード４０ａに配置されている。なお、本実施形態では、以下で説明する初期設定に係るセットアップの際には、ＣＲＣ５０及びｂｆｄｄ５２は既に稼働していることとする。
　また、ｂｆｄｄ５２のＩＰアドレスを示すアドレスデータ、及び、ｂｆｄｄ５２の認証に必要な認証情報が、ＣＤＣクラスタ１４のデータストア部４８に予め登録されていることとする。
　本実施形態では例えば、初期設定に係るセットアップにおいて、例えば開発者等の操作によって、ＧＣクラスタ１２のデータストア部２８に、対向クラスタの情報を扱うためのプラグイン定義（Ｃｕｓｔｏｍ　Ｒｅｓｏｕｒｃｅ　Ｄｅｆｉｎｉｓｉｏｎ）が登録される。
　すると、ＧＣクラスタ１２が、Ｃｕｓｔｏｍ　Ｒｅｓｏｕｒｃｅ　Ｃｏｎｔｒｏｌｌｅｒ（ＣＲＣ）３０のインスタンシエーションを実行する。ここでは例えば、ＣＲＣ３０のインスタンシエーションがマスタノード２０ｃに対して実行される。
　また、ＣＲＣ３０は、ＧＣクラスタ１２内に、双方向転送検出デーモン（ｂｆｄｄ）３２のインスタンシエーションを実行する。ここでは例えば、ｂｆｄｄ３２のインスタンシエーションがマスタノード２０ａに対して実行される。
　そして本実施形態では、ＧＣクラスタ１２のデータストア部２８に、ｂｆｄｄ３２のＩＰアドレスを示すアドレスデータ及びｂｆｄｄ３２の認証に必要な認証情報が登録される。
　そして、ＧＣクラスタ１２のデータストア部２８に、例えば開発者等の操作によって、対向クラスタ（例えば、ＣＤＣクラスタ１４）に関するリソース情報（Ｃｕｓｔｏｍ　Ｒｅｓｏｕｒｃｅ）が登録される。
　登録されるリソース情報は、例えば、ＣＤＣクラスタ１４のアドレス（例えばデータストア部４８に含まれるｋｕｂｅ－ａｐｉｓｅｒｖｅｒのＩＰアドレス及びドメイン名）や、ＣＤＣクラスタ１４との通信を確立する際に必要となるユーザ名やパスワードなどといった認証情報（クレデンシャル）、などを示す情報である。
　すると、ＧＣクラスタ１２のＣＲＣ３０が、登録されたリソース情報を読み取って、ＣＤＣクラスタ１４との間での接続（ネゴシエーション）を行う。当該接続では、リソース情報に示されているＣＤＣクラスタ１４のアドレスが用いられる。また、当該接続において、リソース情報に示されている認証情報を用いた認証も行われる。
　また、当該接続において、ＧＣクラスタ１２は、ｂｆｄｄ３２のＩＰアドレスを示すアドレスデータ、及び、ｂｆｄｄ３２の認証に必要な認証情報を、ＣＤＣクラスタ１４に送信する。そして、ＣＤＣクラスタ１４は、当該送信に対するレスポンスとして、ｂｆｄｄ５２のＩＰアドレスを示すアドレスデータ、及び、ｂｆｄｄ５２の認証に必要な認証情報をＧＣクラスタ１２に送信する。
　上述の認証が成功すると、ＣＤＣクラスタ１４のデータストア部４８にＣＤＣクラスタ１４のリソース情報が登録されていないかどうかが確認される。登録されていない場合は、ＧＣクラスタ１２のＣＲＣ３０が、ＣＤＣクラスタ１４のデータストア部４８にＣＤＣクラスタ１４のリソース情報を登録する。なお、ＣＤＣクラスタ１４が、ＣＤＣクラスタ１４のデータストア部４８にＣＤＣクラスタ１４のリソース情報を登録してもよい。
　また、ＣＤＣクラスタ１４は、ＧＣクラスタ１２から受信した、ｂｆｄｄ３２のＩＰアドレスを示すアドレスデータ、及び、ｂｆｄｄ３２の認証に必要な認証情報を、データストア部４８に登録する。また、ＧＣクラスタ１２は、ＣＤＣクラスタ１４から受信した、ｂｆｄｄ５２のＩＰアドレスを示すアドレスデータ、及び、ｂｆｄｄ５２の認証に必要な認証情報を、データストア部２８に登録する。
　以上のようにして、ＧＣクラスタ１２は、データストア部２８に登録されているアドレスデータを参照することで、ｂｆｄｄ５２のＩＰアドレスを特定することが可能となる。また、ＣＤＣクラスタ１４は、データストア部４８に登録されているアドレスデータを参照することで、ｂｆｄｄ３２のＩＰアドレスを特定することが可能となる。
　そして、ＣＲＣ３０は、ｂｆｄｄ５２との接続を行うようｂｆｄｄ３２に指示する。すると、ｂｆｄｄ３２とｂｆｄｄ５２との間でのネゴシエーションが実行される。その結果、ｂｆｄｄ３２とｂｆｄｄ５２との間の通信（双方向転送検出（ＢＦＤ）セッション）が確立され、ＢＦＤパケットの送信先や送信タイミングが設定される。
　ｂｆｄｄ３２とｂｆｄｄ５２との間でＢＦＤセッションが確立されると、ｂｆｄｄ３２とｂｆｄｄ５２との間で、ＢＦＤプロトコルに従った、ＢＦＤパケットの通信が開始される。
　本実施形態では例えば、ｂｆｄｄ３２は、通信相手であるＣＤＣクラスタ１４に含まれるｂｆｄｄ５２との間で互いにＢＦＤパケットを送受信する。また、ｂｆｄｄ５２は、通信相手であるＧＣクラスタ１２に含まれるｂｆｄｄ３２との間で互いにＢＦＤパケットを送受信する。本実施形態では例えば、ＢＦＤパケットは数ミリ秒間隔で送信される。
　また、本実施形態では例えば、開発者の操作に応じて、図２に例示されているＤＮＳレコード６０がＧＣクラスタ１２のｃｏｒｅｄｎｓ３４に登録される。図２に示すＤＮＳレコード６０は、ＣＤＣクラスタ１４のｐｏｄ４４を含むグループに対応する送信先仮想ドメイン名（ｐｏｄ．ｅｘａｍｐｌｅ．ｃｏｍ）と、ＣＤＣクラスタ１４のｐｏｄ４４のＩＰアドレスとを対応付けたＡレコード６２を含む。
　そして、本実施形態では例えば、ＧＣクラスタ１２のｐｏｄ２４は、ｅｎｖｏｙ２６及びｅｎｖｏｙ４６を経由して、ＣＤＣクラスタ１４のｐｏｄ４４へ、アプリケーション処理に関するデータ（以下「対象データ」とも呼ぶ。）を送信する。対象データは、例えば、ＧＣクラスタ１２内にデプロイされたｐｏｄ２４の処理結果を含む。
　対象データの送信において、ＧＣクラスタ１２のｐｏｄ２４は、例えば、送信先Ｐｏｄ名（例えば、ｐｏｄ４４を含む複数のｐｏｄを仮想化した送信先仮想ドメイン名）の名前解決をｃｏｒｅｄｎｓ３４に要求する。ｃｏｒｅｄｎｓ３４は、ＤＮＳレコード６０に基づいて、ｐｏｄ４４のＩＰアドレスを自クラスタ内のｐｏｄ２４に返す。ｐｏｄ２４は、ｃｏｒｅｄｎｓ２１から提供されたｐｏｄ４４のＩＰアドレスをもとに、ＣＤＣクラスタ１４のｐｏｄ４４へ対象データを送信する。
　ここで本実施形態において、以上のようにしてＧＣクラスタ１２及びＣＤＣクラスタ１４が動作している際に、図３に示すように、ｂｆｄｄ５２が動作しているＣＤＣクラスタ１４のマスタノード４０ａにノード障害が発生したとする。
　すると、ｂｆｄｄ３２は、ｂｆｄｄ５２からのＢＦＤパケットの送信がないこと（例えばｂｆｄｄ３２が、所定時間以上にわたるｂｆｄｄ５２からのＢＦＤパケットの受信断）を検出する。
　そして、ＣＲＣ３０は、ｂｆｄｄ５２からのＢＦＤパケットの送信がないことの検出に応じて、ｂｄｆｆ３２によるｂｆｄｄ５２へのＢＦＤパケットの送信を制限する。
　ここで、ＣＲＣ３０は、ｂｆｄｄ５２からのＢＦＤパケットの送信がないことの検出に応じて、ｂｄｆｆ３２によるｂｆｄｄ５２へのＢＦＤパケットの送信間隔を長くしてもよい。例えば、ＣＲＣ３０は、ｂｄｆｆ３２によるｂｆｄｄ５２へのＢＦＤパケットの送信間隔を、数秒、あるいは、数十秒（例えば、２０～６０秒）にしてもよい。
　あるいは、ＣＲＣ３０は、ｂｆｄｄ５２からのＢＦＤパケットの送信がないことの検出に応じて、ｂｄｆｆ３２によるｂｆｄｄ５２へのＢＦＤパケットの送信を停止してもよい。
　また、マスタノード４０ａにノード障害が発生すると、ＣＲＣ５０は、ｂｆｄｄ５２の消失を検出する。そして、ＣＲＣ５０は、ｂｆｄｄ５２の消失の検出に応じて、ＣＤＣクラスタ１４に含まれるｂｆｄｄを復旧させる。図３の例では、このようにして復旧されたｂｆｄｄ５４が、マスタノード４０ｂに示されている。ここで、ｂｆｄｄ５４には、ｂｆｄｄ５２とは異なるＩＰアドレスが設定されることとなる。
　そして、ＣＲＣ５０は、ＣＤＣクラスタ１４のデータストア部４８に登録されている、ｂｆｄｄ５２のＩＰアドレスを示すアドレスデータを、変更後のＩＰアドレス（ｂｆｄｄ５４に設定されたＩＰアドレス）を示すアドレスデータに更新する。ここで、ＣＲＣ５０は、ｂｆｄｄ５４の認証に必要な認証情報を、データストア部４８に登録してもよい。
　そして、ＣＲＣ３０は、本実施形態では例えば、ＢＦＤパケットの送信が制限されている際における、ＣＤＣクラスタ１４に含まれるｂｆｄｄの復旧を検出する。
　そして、ＣＲＣ３０は、本実施形態では例えば、ＣＤＣクラスタ１４に含まれるｂｆｄｄの復旧の検出に応じて、ＢＦＤパケットの送信の制限を解除する。ここで、例えば、ＣＲＣ３０は、ｂｆｄｄ３２に、ｂｆｄｄ５２からｂｆｄｄ５４へのペアリング変更指示を出力してもよい。そして、ｂｆｄｄ３２がペアリング変更指示の受付に応じて、ｂｆｄｄ５４との間でのＢＦＤセッションを確立してもよい。そして、ｂｆｄｄ３２とｂｆｄｄ５４との間で、ＢＦＤプロトコルに従った、通常のＢＦＤパケットの通信が開始されてもよい。当該通信では、例えば、数ミリ秒間隔でのＢＦＤパケットの送信が行われるようにしてもよい。
　ここで例えば、ＣＲＣ５０が、ＣＤＣクラスタ１４に含まれるｂｆｄｄの復旧に応じて、復旧後におけるＣＤＣクラスタ１４に含まれるｂｆｄｄであるｂｆｄｄ５４のアドレスを示すアドレスデータを、ＧＣクラスタ１２に送信してもよい。そして、ＧＣクラスタ１２に含まれるＣＲＣ３０が、当該アドレスデータを受信してもよい。そして、ＣＲＣ３０が、当該アドレスデータの受信に応じて、ＢＦＤパケットの送信の制限を解除してもよい。なおここで、ＣＲＣ５０は、ｂｆｄｄ５４の認証に必要な認証情報を、ＧＣクラスタ１２に送信してもよい。そして、ＣＲＣ３０が、当該認証情報を受信してもよい。
　あるいはＣＲＣ３０が、所定時間間隔（例えば、３０秒～１分間隔）で、データストア部４８にアクセスして、データストア部４８に登録されている、ＣＤＣクラスタ１４に含まれるｂｆｄｄのアドレス（例えばＩＰアドレス）を示すアドレスデータを取得してもよい。
　そして、ＣＲＣ３０は、取得されるアドレスデータが示すアドレスの変更を検出してもよい。そして、ＣＲＣ３０は、取得されるアドレスデータが示すアドレスの変更の検出に応じて、ＢＦＤパケットの送信の制限を解除してもよい。ここで例えば、ＣＲＣ３０は、ｂｆｄｄ５４の認証に必要な認証情報をデータストア部４８から取得してもよい。
　また、ＣＲＣ３０は、ＣＤＣクラスタ１４に含まれるｂｆｄｄの復旧の検出に応じて、ＧＣクラスタ１２のデータストア部２８に登録されている、ｂｆｄｄ５２のＩＰアドレスを示すアドレスデータを、変更後のＩＰアドレス（ｂｆｄｄ５４に設定されたＩＰアドレス）を示すアドレスデータに更新する。ここで、ＣＲＣ３０は、ｂｆｄｄ５４の認証に必要な認証情報を、データストア部２８に登録してもよい。
　なお、ＣＲＣ３０は、ｂｆｄｄ５４からのＢＦＤパケットの送信がないことの検出に応じて、ｃｏｒｅｄｎｓ２１に登録されているＤＮＳレコード６０を書き換えてもよい。例えば、ＤＮＳレコード６０に含まれるＡレコード６２が、送信先仮想ドメイン名（ｐｏｄ．ｅｘａｍｐｌｅ．ｃｏｍ）と、ＣＤＣクラスタ１４のバックアップである別のＣＤＣクラスタのｐｏｄのＩＰアドレスと、を対応付けたＡレコード６２に書き換えられてもよい。
　以上で説明したように、ＣＲＣ３０は、本実施形態において、ｂｆｄｄ５２からのＢＦＤパケットの送信がないことの検出に応じて、ｂｆｄｄ３２によるｂｆｄｄ５２へのＢＦＤパケットの送信を制限する送信制限部としての役割を担っている。
　また、ＣＲＣ３０は、ＢＦＤパケットの送信が制限されている際における、ＣＤＣクラスタ１４に含まれるｂｆｄｄの復旧の検出に応じて、ＢＦＤパケットの送信の制限を解除する送信制限解除部としての役割を担っている。
　また、ＣＲＣ３０は、復旧後におけるＣＤＣクラスタ１４に含まれるｂｆｄｄであるｂｆｄｄ５４のアドレスを示すアドレスデータを受信するアドレスデータ受信部としての役割を担ってもよい。
　また、ＣＲＣ３０は、ＣＤＣクラスタ１４に含まれるｂｆｄｄのアドレスを示すアドレスデータを記憶するデータストア部４８にアクセスして当該アドレスデータを取得するアドレスデータ取得部としての役割を担ってもよい。
　また、図１や図３には、通信システム１０の各構成要素が備える機能ブロックを示すブロック図が含まれている。図１又は図３のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵ・メモリをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。
　ここで、本実施形態に係るＧＣクラスタ１２で実行されるＢＦＤパケットの送信制御に係る処理の流れの一例を、図４に例示するフロー図を参照しながら説明する。
　本処理例では、ｂｆｄｄ３２は、ｂｆｄｄ５２に所定時間間隔（例えば数ミリ秒間隔）でＢＦＤパケットを送信するとともに、ｂｆｄｄ５２から送信されるＢＦＤパケットの受信を監視している（待ち受けている）（Ｓ１０１）。
　ここで、ｂｆｄｄ３２が、所定時間以上にわたるｂｆｄｄ５２からのＢＦＤパケットの受信断を検出すると、ＣＲＣ３０が、ＢＦＤパケットの送信制限をｂｆｄｄ３２に指示する。そして、ｂｆｄｄ３２は、上述のように、ＢＦＤパケットの送信を制限する（Ｓ１０２）。
　そして、ＣＲＣ３０は、ＣＲＣ５０からのアドレスデータの受信を監視する（待ち受ける）（Ｓ１０３）。
　ＣＲＣ３０がＣＲＣ５０からのアドレスデータの受信を検出すると、ＣＲＣ３０は、ＢＦＤパケットの送信の制限を解除して（Ｓ１０４）、本処理例に示す処理は終了される。
　次に、本実施形態に係るＧＣクラスタ１２で実行されるＢＦＤパケットの送信制御に係る処理の流れの別の一例を、図５に例示するフロー図を参照しながら説明する。
　本処理例では例えば、ＣＲＣ３０は、所定時間間隔（例えば、３０秒～１分間隔）で、データストア部４８にアクセスして、ＣＤＣクラスタ１４に含まれるｂｆｄｄのＩＰアドレスを示すアドレスデータを取得していることとする。
　また、本処理例でも、ｂｆｄｄ３２は、ｂｆｄｄ５２に所定時間間隔（例えば数ミリ秒間隔）でＢＦＤパケットを送信するとともに、ｂｆｄｄ５２から送信されるＢＦＤパケットの受信を監視している（待ち受けている）（Ｓ２０１）。
　ここで、ｂｆｄｄ３２が、所定時間以上にわたるｂｆｄｄ５２からのＢＦＤパケットの受信断を検出すると、ＣＲＣ３０が、ＢＦＤパケットの送信制限をｂｆｄｄ３２に指示する。そして、ｂｆｄｄ３２は、上述のように、ＢＦＤパケットの送信を制限する（Ｓ２０２）。
　そして、ＣＲＣ３０は、所定時間間隔で取得しているアドレスデータが示すアドレス（例えばＩＰアドレス）の変更を監視する（Ｓ２０３）。
　ＣＲＣ３０が、アドレスデータが示すアドレスの変更を検出すると、ＣＲＣ３０は、ＢＦＤパケットの送信の制限を解除して（Ｓ２０４）、本処理例に示す処理は終了される。
　なお、本処理例において、ＣＲＣ３０による、所定時間間隔でのＣＤＣクラスタ１４に含まれるｂｆｄｄのＩＰアドレスを示すアドレスデータの取得が、予め実行されている必要はない。例えば、ＢＦＤパケットの送信が制限されたことに応じて、ＣＲＣ３０が、所定時間間隔での、データストア部４８に登録されている、ＣＤＣクラスタ１４に含まれるｂｆｄｄのＩＰアドレスを示すアドレスデータの取得を開始してもよい。
　また、Ｓ１０４又はＳ２０４に示す処理において、上述のように、ＣＲＣ３０は、ｂｆｄｄ３２に、ｂｆｄｄ５２からｂｆｄｄ５４へのペアリング変更指示を出力してもよい。そして、ｂｆｄｄ３２とｂｆｄｄ５４との間でのＢＦＤセッションが確立されるようにしてもよい。また、Ｓ１０４又はＳ２０４に示す処理において、上述のように、データストア部２８に登録されているアドレスデータの更新や、認証情報の登録が併せて行われてもよい。
　また、本実施形態において、ＣＲＣ３０は、ＣＲＣ５０からのアドレスデータの受信の監視と、所定時間間隔での、データストア部４８に登録されている、ＣＤＣクラスタ１４に含まれるｂｆｄｄのＩＰアドレスを示すアドレスデータの取得の両方を実行してもよい。そして、ＣＲＣ５０からのアドレスデータの受信、又は、アドレスデータが示すアドレスの変更のいずれか一方が検出されることに応じて、ＢＦＤパケットの送信の制限が解除されるようにしてもよい。
　また、本実施形態において、ＣＤＣクラスタ１４に含まれるｂｆｄｄの復旧に応じて、ｂｆｄｄ５４からｂｆｄｄ３２へのアクセスが発生するようにしてもよい。そして、ｂｆｄｄ５４からｂｆｄｄ３２へのアクセスの発生の検出に応じて、ＢＦＤパケットの送信の制限が解除されるようにしてもよい。
　マスタノード４０ａで障害が発生するなどして、ｂｆｄｄ３２から送信されたＢＦＤパケットをｂｆｄｄ５２が適切に処理できない状況が発生することが考えられる。このような状況が発生している間は、ｂｆｄｄ３２から送信されるＢＦＤパケットは有効活用されず、ｂｆｄｄ３２によるＢＦＤパケットの送信は無駄なトラフィックとなる。
　本実施形態では、以上で説明したように、ＧＣクラスタ１２は、ｂｆｄｄ５２からのＢＦＤパケットの送信がないことの検出に応じて、ｂｆｄｄ３２によるＢＦＤパケットの送信を制限する。このようにして、本実施形態によれば、有効活用されないＢＦＤパケットの送信による無駄なトラフィックの発生を抑制できることとなる。
　なお、本発明は上述の実施形態に限定されるものではない。
　例えば、１つのＣＲＣ３０が対向クラスタとの間での接続（ネゴシエーション）の役割を担い、別のＣＲＣ３０が、ＢＦＤパケットの送信制限の役割を担ってもよい。そして、これらのＣＲＣ３０が別々のマスタノード２０に配置されてもよい。
　また、ＧＣクラスタ１２がＣＲＣ５０をさらに含むようにしてもよいし、ＣＲＣ５０の機能を備えたＣＲＣ３０がＧＣクラスタ１２で動作してもよい。また、ＣＤＣクラスタ１４がＣＲＣ３０をさらに含むようにしてもよいし、ＣＲＣ３０の機能を備えたＣＲＣ５０がＣＤＣクラスタ１４で動作してもよい。
　また、ｂｆｄｄ３２とｃｏｒｅｄｎｓ３４とが同じマスタノード２０で稼働してもよいし、異なるマスタノード２０で稼働してもよい。また、ＣＲＣ３０とｂｆｄｄ３２とが同じマスタノード２０で稼働してもよいし、異なるマスタノード２０で稼働してもよい。また、ＣＲＣ３０とｃｏｒｅｄｎｓ３４とが同じマスタノード２０で稼働してもよいし、異なるマスタノード２０で稼働してもよい。
　また、ＣＲＣ５０とｂｆｄｄ５２とが同じマスタノード４０で稼働してもよいし、異なるマスタノード４０で稼働してもよい。

Claims (7)

  1. 　第１の双方向転送検出デーモン（ｂｆｄｄ）を含む通信システムであって、
    　前記第１のｂｆｄｄは、前記通信システムの通信相手に含まれるｂｆｄｄである第２のｂｆｄｄとの間で互いにＢＦＤパケットを送受信し、
    　前記第２のｂｆｄｄからのＢＦＤパケットの送信がないことの検出に応じて、前記第１のｂｆｄｄによる前記第２のｂｆｄｄへのＢＦＤパケットの送信を制限する送信制限手段、
    　を含むことを特徴とする通信システム。
  2. 　前記送信制限手段は、前記検出に応じて、前記第１のｂｆｄｄによる前記第２のｂｆｄｄへのＢＦＤパケットの送信間隔を長くする、
    　ことを特徴とする請求項１に記載の通信システム。
  3. 　前記送信制限手段は、前記検出に応じて、前記第１のｂｆｄｄによる前記第２のｂｆｄｄへのＢＦＤパケットの送信を停止する、
    　ことを特徴とする請求項１に記載の通信システム。
  4. 　前記ＢＦＤパケットの送信が制限されている際における、前記通信相手に含まれるｂｆｄｄの復旧の検出に応じて、前記ＢＦＤパケットの送信の制限を解除する送信制限解除手段、をさらに含む、
    　ことを特徴とする請求項１から３のいずれか一項に記載の通信システム。
  5. 　復旧後における前記通信相手に含まれるｂｆｄｄである第３のｂｆｄｄのアドレスを示すアドレスデータを受信するアドレスデータ受信手段、をさらに含み、
    　前記送信制限解除手段は、前記アドレスデータの受信に応じて、前記ＢＦＤパケットの送信の制限を解除する、
    　ことを特徴とする請求項４に記載の通信システム。
  6. 　前記通信相手に含まれるｂｆｄｄのアドレスを示すアドレスデータを記憶する記憶部にアクセスして当該アドレスデータを取得するアドレスデータ取得手段、をさらに含み、
    　前記送信制限解除手段は、前記アドレスデータが示すアドレスの変更の検出に応じて、前記ＢＦＤパケットの送信の制限を解除する、
    　ことを特徴とする請求項４に記載の通信システム。
  7. 　通信システムに含まれる第１の双方向転送検出デーモン（ｂｆｄｄ）が、前記通信システムの通信相手に含まれるｂｆｄｄである第２のｂｆｄｄにＢＦＤパケットを送信するステップと、
    　前記第１のｂｆｄｄが前記第２のｂｆｄｄから送信されるＢＦＤパケットを受信するステップと、
    　前記第２のｂｆｄｄからのＢＦＤパケットの送信がないことの検出に応じて、前記第１のｂｆｄｄによる前記第２のｂｆｄｄへのＢＦＤパケットの送信を制限するステップと、
    　を含むことを特徴とする通信制御方法。
PCT/JP2021/020675 2021-05-31 2021-05-31 通信システム及び通信制御方法 WO2022254517A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US17/906,746 US20240205139A1 (en) 2021-05-31 2021-05-31 Communication system and communication control method
PCT/JP2021/020675 WO2022254517A1 (ja) 2021-05-31 2021-05-31 通信システム及び通信制御方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/020675 WO2022254517A1 (ja) 2021-05-31 2021-05-31 通信システム及び通信制御方法

Publications (1)

Publication Number Publication Date
WO2022254517A1 true WO2022254517A1 (ja) 2022-12-08

Family

ID=84323954

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/020675 WO2022254517A1 (ja) 2021-05-31 2021-05-31 通信システム及び通信制御方法

Country Status (2)

Country Link
US (1) US20240205139A1 (ja)
WO (1) WO2022254517A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016048850A (ja) * 2014-08-27 2016-04-07 富士通株式会社 パケット転送装置、パケット転送システム、及びパケット転送方法
JP2018014556A (ja) * 2016-07-19 2018-01-25 富士通株式会社 パケット伝送装置、及び、障害監視方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016048850A (ja) * 2014-08-27 2016-04-07 富士通株式会社 パケット転送装置、パケット転送システム、及びパケット転送方法
JP2018014556A (ja) * 2016-07-19 2018-01-25 富士通株式会社 パケット伝送装置、及び、障害監視方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
OOIKE, KOUICHI ET AL.: "Monthly RFI News [BFD Protocol Overview]", ASCII. TECHNOLOGIES, vol. 15, no. 9, 1 September 2010 (2010-09-01), pages 144 - 146, XP009541761 *

Also Published As

Publication number Publication date
US20240205139A1 (en) 2024-06-20

Similar Documents

Publication Publication Date Title
US11140135B2 (en) Scalable proxy clusters
US7844851B2 (en) System and method for protecting against failure through geo-redundancy in a SIP server
JP4897927B2 (ja) 複数のアダプタにわたり複数の仮想ｉｐアドレスを同時にサポートしているホストにおけるフェイルオーバのための方法、システム、およびプログラム
KR100812374B1 (ko) 클러스터 시스템에서 프로토콜 네트워크 장애 관리 시스템및 방법
CN105024855A (zh) 分布式集群管理系统和方法
EP2939401B1 (en) Method for guaranteeing service continuity in a telecommunication network and system thereof
JP2001356973A (ja) ネットワークシステム
WO2014089799A1 (zh) 一种确定虚拟机漂移的方法和装置
US20130139178A1 (en) Cluster management system and method
CN102064954A (zh) 一种分布式容错系统、设备和方法
CN110771097B (zh) 用于网络设备与应用服务器之间的数据隧道传输的连接性监测
JP4703682B2 (ja) クラスタシステム及びプログラム
US7948983B2 (en) Method, computer program product, and apparatus for providing passive automated provisioning
WO2013164917A1 (ja) 移動体通信システム、呼処理ノード及び通信制御方法
CN116781564B (zh) 一种容器云平台的网络检测方法、系统、介质和电子设备
JP2009194787A (ja) ゲートウェイ装置
WO2022254517A1 (ja) 通信システム及び通信制御方法
US20230146880A1 (en) Management system and management method
JP6036380B2 (ja) 通信システム
KR20120121202A (ko) 데이터 분산 서비스 네트워크 과부하 방지 방법
JP2016162324A (ja) 情報処理システム、制御プログラム及び制御方法
US11870646B2 (en) Fabric availability and synchronization
JP6407114B2 (ja) 通信システム、通信方法、通信ノード装置、及びプログラム
KR20060121237A (ko) 라우터 기능성을 자동으로 전송하는 방법
CN104954187A (zh) 一种确定用户侧设备状态的方法和装置

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 17906746

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21944027

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP