WO2022190387A1

WO2022190387A1 - 管理システム及び管理方法

Info

Publication number: WO2022190387A1
Application number: PCT/JP2021/010206
Authority: WO
Inventors: 一成竹内
Original assignee: 楽天モバイル株式会社
Priority date: 2021-03-12
Filing date: 2021-03-12
Publication date: 2022-09-15
Also published as: US20230146880A1

Abstract

通信システムの拡張をスムーズに行うことができる管理システム及び管理方法を提供する。ＧＣクラスタ（１２）は、任意のコンピュータシステムからの通信確立要求の受付に応じた当該コンピュータシステムへの応答が可能な外部システムのアドレスを示すリソースデータを登録する。ｂｆｄ部（２２）は、リソースデータの登録に応じて、当該リソースデータにアドレスが示されている外部システムに所与のコンピュータシステムから通信確立要求が送信されるよう制御することで、当該所与のコンピュータシステムと外部システムとの間での通信を確立する。ＧＣクラスタ（１２）は、通信が確立された外部システムの、所与のコンピュータシステムが実行する所与の処理における役割を設定する。

Description

管理システム及び管理方法

　本発明は、管理システム及び管理方法に関する。

　特許文献１には、ＤＮＳ（Ｄｏｍａｉｎ　Ｎａｍｅ　Ｓｙｓｔｅｍ）サーバは、他のサーバの死活監視と負荷情報収集を行うこと、稼働系のサーバが高負荷状態もしくはサービス不能状態に陥った場合、ＤＮＳサーバは、待機系のサーバに対して起動命令を出し、新規に接続するクライアント端末からのアクセスを待機系のサーバに振り分けることが記載されている。

特開２０１９－１６８９２０号公報

　現在、データセンタ等の拠点ごとに、コンテナ型で仮想化されたアプリケーション（以降、コンテナ化されたアプリケーションとも呼ぶ。）を実行するノードのクラスタが構築されることで、全体として１つの通信システムが構築されることがある。

　そして、このような通信システムにおいて、ある機能を担うクラスタの増設が行われることがある。例えば、通信システムの可用性を高めるために、ある機能を担う既存のクラスタをバックアップするための新規のクラスタの増設が行われることがある。

　しかし、クラスタを増設するにあたって、特許文献１に記載の上記の技術を適用しても、ＤＮＳサーバの設定変更などを開発者が手作業で行う必要があるため手間がかかり、通信システムのスムーズな拡張ができない。

　なお、このことは、複数のクラスタを含む通信システムに限らず、クラスタではない一般的なサブシステムを複数含む通信システムであっても同様にあてはまる。

　本発明は上記実情に鑑みてなされたものであって、その目的の一つは、通信システムの拡張をスムーズに行うことができる管理システム及び管理方法を提供することにある。

　上記課題を解決するために、本発明に係る管理システムは、任意のコンピュータシステムからの通信確立要求の受付に応じた当該コンピュータシステムへの応答が可能な外部システムのアドレスを示すリソースデータを登録するリソースデータ登録手段と、前記リソースデータの登録に応じて、当該リソースデータにアドレスが示されている前記外部システムに所与のコンピュータシステムから通信確立要求が送信されるよう制御することで、当該所与のコンピュータシステムと前記外部システムとの間での通信を確立する通信確立手段と、前記通信が確立された前記外部システムの、前記所与のコンピュータシステムが実行する所与の処理における役割を設定する役割設定手段と、を含む。

　本発明の一態様では、前記リソースデータ登録手段は、前記所与のコンピュータシステムが既存の前記外部システムと連携して前記処理を実行している際に、新規の前記外部システムのアドレスを示す前記リソースデータを登録し、前記通信確立手段は、前記リソースデータの登録に応じて、前記所与のコンピュータシステムと前記新規の前記外部システムとの間での通信を確立し、前記役割設定手段は、前記通信が確立された前記新規の前記外部システムの、前記処理における前記既存の前記外部システムとの関係での役割を設定する。

　この態様では、前記役割設定手段は、前記新規の前記外部システムが、前記既存の前記外部システムのバックアップの役割であることを設定してもよい。

　さらに、前記処理に関する対象データを前記既存の前記外部システムに送信する送信手段、をさらに含み、前記送信手段は、前記既存の前記外部システムの障害又は前記所与のコンピュータシステムと前記既存の前記外部システムとの間の通信経路の障害が発生した場合に、前記既存の前記外部システムに代えて前記新規の前記外部システムに前記対象データを送信してもよい。

　さらに、前記既存の前記外部システムから繰り返し送信されるパケットであって、前記既存の前記外部システムとの間のパスの正常性を監視するためのパケットを受信する受信手段、をさらに含み、前記送信手段は、前記既存の前記外部システムから前記パケットを未受信の場合、前記既存の前記外部システムに代えて前記新規の前記外部システムに前記対象データを送信してもよい。

　さらに、前記受信手段は、前記新規の前記外部システムから繰り返し送信されるパケットであって、前記新規の前記外部システムとの間のパスの正常性を監視するためのパケットをさらに受信し、前記送信手段は、前記既存の前記外部システムから前記パケットを未受信であり、かつ、前記新規の前記外部システムから前記パケットを受信している場合、前記既存の前記外部システムに代えて前記新規の前記外部システムに前記対象データを送信してもよい。

　また、前記パケットは、ＢＦＤ（Ｂｉｄｉｒｅｃｔｉｏｎａｌ　Ｆｏｒｗａｒｄｉｎｇ　Ｄｅｔｅｃｔｉｏｎ）パケットであってもよい。

　また、本発明の一態様では、前記処理における前記外部システムの役割を示すサービスデータを登録するサービスデータ登録手段、をさらに含む。

　この態様では、前記サービスデータは、前記処理に関する対象データの送信先の名前解決に用いられるＤＮＳ（Ｄｏｍａｉｎ　Ｎａｍｅ　Ｓｙｓｔｅｍ）レコードであってもよい。

　また、本発明に係る管理方法は、任意のコンピュータシステムからの通信確立要求の受付に応じた当該コンピュータシステムへの応答が可能な外部システムのアドレスを示すリソースデータを登録するステップと、前記リソースデータの登録に応じて、当該リソースデータにアドレスが示されている前記外部システムに所与のコンピュータシステムから通信確立要求が送信されるよう制御することで、当該所与のコンピュータシステムと前記外部システムとの間での通信を確立するステップと、前記通信が確立された前記外部システムの、前記所与のコンピュータシステムが実行する所与の処理における役割を設定するステップと、を含む。

　なお、以上の構成要素の任意の組合せ、本開示の表現を、装置、コンピュータプログラム、コンピュータプログラムを読み取り可能に記録した記録媒体などの間で変換したものもまた、本開示の態様として有効である。

コンテナ化されたアプリケーションを実行するノードのクラスタが構築されたコンピュータシステムの構成を示す図である。第１実施例の通信システムの構成を示す図である。ＧＣクラスタのｃｏｒｅｄｎｓに記憶されるＤＮＳレコードの例を示す図である。ＧＣクラスタの動作を示すフローチャートである。ＧＣクラスタのｃｏｒｅｄｎｓに記憶されるＤＮＳレコードの例を示す図である。第２実施例の通信システムの構成を示す図である。ＧＣクラスタのｃｏｒｅｄｎｓに記憶されるＤＮＳレコードの例を示す図である。ＧＣクラスタの動作を示すフローチャートである。サービスデータのデータ構造の一例を示す図である。ＣＤＣ２が追加されていない状態における第３実施例の通信システムの構成を示す図である。ＧＣクラスタで実行される処理の流れの一例を示すフローチャートである。

　実施例の概要を説明する。図１は、コンテナ化されたアプリケーションを実行するノード（コンピュータ、サーバとも言える）のクラスタが構築されたコンピュータシステムの構成を示す。図１には、上記クラスタが構築された複数のコンピュータシステムとして、ＧＣクラスタ１２、ＣＤＣクラスタ１４ａ、ＣＤＣクラスタ１４ｂを描いている。

　ＧＣクラスタ１２は、移動体通信事業者のＧＣ（Ｇｒｏｕｐ　Ｕｎｉｔ　Ｃｅｎｔｅｒ）局に構築されたクラスタである。実施例のクラスタは、コンテナ化されたワークロードやサービスを管理するソフトウェア（具体的にはクバネテス）がインストールされたノードのセットである。また、実施例のクラスタは、クバネテスがコンテナ化されたアプリケーションであるｐｏｄを管理可能な範囲を定めたクバネテスクラスタである。クバネテスクラスタは、クバネテスがｐｏｄをデプロイ可能な複数のノードのセットであるとも言える。

　ＧＣクラスタ１２は、複数のマスタノード２０（マスタノード２０ａ、マスタノード２０ｂ、マスタノード２０ｃ）と、複数のワーカノード２５（図１には１つのノードを図示）とを備える。ワーカノード２５には、各種データ処理（業務処理等）を実行するアプリケーションであり、コンテナ化されたアプリケーションであるｐｏｄ２６がデプロイされる。ｐｏｄ２６は、ＣＮＦ（Ｃｌｏｕｄ－ｎａｔｉｖｅ　Ｎｅｔｗｏｒｋ　Ｆｕｎｃｔｉｏｎ）インスタンスとも言える。

　複数のマスタノード２０のそれぞれは、複数のワーカノード２５および複数のｐｏｄ２６を管理するノードである。複数のマスタノード２０のそれぞれは、クラスタ内のｐｏｄ２６に対して名前解決サービスを提供するＤＮＳ（Ｄｏｍａｉｎ　Ｎａｍｅ　Ｓｙｓｔｅｍ）サーバであるｃｏｒｅｄｎｓ２１を含む。なお、複数のマスタノード２０の中から１つのリーダが選定され、図１では、マスタノード２０ａがリーダとして選定されている。

　ＣＤＣクラスタ１４ａは、移動体通信事業者の第１のＣＤＣ（Ｃｅｎｔｒａｌ　Ｄａｔａ　Ｃｅｎｔｅｒ）であるＣＤＣ１に構築されたクバネテスクラスタである。ＣＤＣクラスタ１４ａは、複数のマスタノード３０（マスタノード３０ａ、マスタノード３０ｂ、マスタノード３０ｃ）と、複数のワーカノード３５（図１では１つのノードを図示）とを備える。ワーカノード３５には、各種データ処理（業務処理等）を実行するｐｏｄ３６がデプロイされる。

　ＣＤＣクラスタ１４ｂは、移動体通信事業者の第２のＣＤＣであるＣＤＣ２に構築されたクバネテスクラスタである。ＣＤＣクラスタ１４ｂは、複数のマスタノード４０（マスタノード４０ａ、マスタノード４０ｂ、マスタノード４０ｃ）と、複数のワーカノード４５（図１では１つのノードを図示）とを備える。ワーカノード４５には、各種データ処理（業務処理等）を実行するｐｏｄ４６がデプロイされる。

　実施例では、ＧＣクラスタ１２のｐｏｄ２６は、ＣＤＣクラスタ１４ａのｐｏｄ３６へ、アプリケーション処理に関するデータ（以下「対象データ」とも呼ぶ。）を送信する。対象データは、例えば、ＧＣクラスタ１２内にデプロイされたｐｏｄ２６の処理結果を含む。ＣＤＣクラスタ１４ａで障害が発生した場合、ＧＣクラスタ１２のｐｏｄ２６は、ＣＤＣクラスタ１４ａのｐｏｄ３６に代えてＣＤＣクラスタ１４ｂのｐｏｄ４６へ対象データを送信する。

　これまで、異なるクバネテスクラスタのノード間で通信を行う場合、クラスタの外部に設けられたＧＳＬＢ装置５０（インフラＤＮＳとも呼ばれる。）にアクセスして、送信先のｐｏｄ（例えばｐｏｄ３６）の名前解決を行う必要があった。ＧＳＬＢ装置５０は、ＣＤＣクラスタ１４ａのｐｏｄ３６に対して所定のデータを定期的に送信することにより、ｐｏｄ３６のヘルスチェックを定期的に行う。また、ＧＳＬＢ装置５０は、ＣＤＣクラスタ１４ｂのｐｏｄ４６に対して所定のデータを定期的に送信することにより、ｐｏｄ４６のヘルスチェックを定期的に行う。

　ＧＣクラスタ１２のｐｏｄ２６は、送信先Ｐｏｄ名（例えばｐｏｄ３６とｐｏｄ４６とを仮想化した送信先仮想ドメイン名）の名前解決をｃｏｒｅｄｎｓ２１に要求する。ｃｏｒｅｄｎｓ２１は、送信先Ｐｏｄ名の名前解決をＧＳＬＢ装置５０に要求する。ＧＳＬＢ装置５０は、ＣＤＣクラスタ１４ａのｐｏｄ３６の状態が正常であれば、名前解決要求に対する応答として、ｐｏｄ３６のＩＰアドレスをＧＣクラスタ１２のｃｏｒｅｄｎｓ２１へ送信する。ｃｏｒｅｄｎｓ２１は、ｐｏｄ３６のＩＰアドレスを自クラスタ内のｐｏｄ２６に返す。ｐｏｄ２６は、ｃｏｒｅｄｎｓ２１から提供されたｐｏｄ３６のＩＰアドレスをもとに、ＣＤＣクラスタ１４ａのｐｏｄ３６へ対象データを送信する。

　一方、ＣＤＣクラスタ１４ａのｐｏｄ３６の状態が異常の場合、ＧＳＬＢ装置５０は、そのことを検出する。ＧＳＬＢ装置５０は、名前解決要求への応答として、ＣＤＣクラスタ１４ｂのｐｏｄ４６のＩＰアドレスをＧＣクラスタ１２のｃｏｒｅｄｎｓ２１へ送信する。ｃｏｒｅｄｎｓ２１は、ｐｏｄ４６のＩＰアドレスを自クラスタ内のｐｏｄ２６に返す。ｐｏｄ２６は、ｃｏｒｅｄｎｓ２１から提供されたｐｏｄ４６のＩＰアドレスをもとに、ＣＤＣクラスタ１４ｂのｐｏｄ４６へ対象データを送信する。

　ＧＣクラスタ１２とＧＳＬＢ装置５０は、レイヤ２（Ｌ２）通信区間（例えばイーサネット（登録商標））を含むＷＡＮ５２を介して接続される。ここで、ＷＡＮ５２における正常時のＬ２通信経路に障害が発生した場合、バックアップ用のＬ２通信経路に切り替わるまでに比較的長い時間を要する。そのため、ＧＣクラスタ１２とＧＳＬＢ装置５０間のＷＡＮ５２に障害が発生した場合、送信先ＰｏｄのＩＰアドレスをＧＳＬＢ装置５０から得るまでに時間を要し、ＧＣクラスタ１２とＣＤＣクラスタ１４ａ（またはＣＤＣクラスタ１４ｂ）との通信が遅延する可能性があった。

　そこで、本開示の第１実施例および第２実施例では、複数のクバネテスクラスタ間での通信において、送信先のクバネテスクラスタから数秒おきに繰り返し送信されるパケットであって、送信元のクバネテスクラスタと送信先のクバネテスクラスタ間のパスの正常性を監視するためのパケットを利用することにより、複数のクバネテスクラスタ間での通信の遅延を抑制する。実施例における上記パケットは、ＢＦＤ（Ｂｉｄｉｒｅｃｔｉｏｎａｌ　Ｆｏｒｗａｒｄｉｎｇ　Ｄｅｔｅｃｔｉｏｎ）機能により送受信されるＢＦＤパケットである。

＜第１実施例＞
　図２は、第１実施例の通信システム１０の構成を示す。図２は、通信システム１０の各構成要素が備える機能ブロックを示すブロック図を含む。本開示のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵ・メモリをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。

　通信システム１０のＧＣクラスタ１２のノード構成は、上述した図１のＧＣクラスタ１２のノード構成と同じである。通信システム１０のＧＣクラスタ１２は、Ｐｏｄを実行するノードのクラスタであるクバネテスクラスタが構築されたコンピュータシステムである。また、ＧＣクラスタ１２は、Ｐｏｄの処理に関連する送信対象データ（以下「対象データ」）の送信元となるコンピュータシステムである。ＧＣクラスタ１２は、複数の外部システム（第１実施例ではＣＤＣクラスタ１４ａおよびＣＤＣクラスタ１４ｂ）と通信を行う通信部をノード（すなわちクラスタを構成するノード内）に備える。通信部は、マスタノード２０に設けられたｂｆｄ部２２と、ワーカノード２５に設けられたｅｎｖｏｙ２７を備える。ｂｆｄ部２２とｅｎｖｏｙ２７の詳細は後述する。

　マスタノード２０は、ｃｏｒｅｄｎｓ２１とｂｆｄ部２２と更新部２３を備える。ワーカノード２５は、ｐｏｄ２６とｅｎｖｏｙ２７を備える。ｅｎｖｏｙ２７は、公知のサービスメッシュにより規定された、送信元アプリケーション間から出力された送信データをフックし、所定の通信プロトコルにしたがって、その送信データを送信先アプリケーションへ送信することを代行するプロキシ部と言える。

　ＧＣクラスタ１２は、Ｌ２通信区間を含むＷＡＮ５２を介して、ＣＤＣクラスタ１４ａとＣＤＣクラスタ１４ｂとに接続される。通信システム１０のＣＤＣクラスタ１４ａのノード構成は、上述の図１のＣＤＣクラスタ１４ａのノード構成と同じである。ＣＤＣクラスタ１４ａは、クバネテスクラスタが構築されたコンピュータシステムであって、対象データの本来の送信先となる第１の外部コンピュータシステムである。マスタノード３０は、ｂｆｄ部３１を備える。ワーカノード３５は、ｐｏｄ３６とｅｎｖｏｙ３７を備える。

　通信システム１０のＣＤＣクラスタ１４ｂのノード構成は、上述の図１のＣＤＣクラスタ１４ｂのノード構成と同じである。ＣＤＣクラスタ１４ａと同様に、ＣＤＣクラスタ１４ｂも、クバネテスクラスタが構築されたコンピュータシステムである。ＣＤＣクラスタ１４ｂは、ＣＤＣクラスタ１４ａに障害が発生した場合や、ＧＣクラスタ１２とＣＤＣクラスタ１４ａ間の通信経路に障害が発生した場合、ＣＤＣクラスタ１４ａに代わって対象データの送信先となる第２の外部コンピュータシステムである。マスタノード４０は、ｂｆｄ部４１を備える。ワーカノード４５は、ｐｏｄ４６とｅｎｖｏｙ４７を備える。

　或るノード上の１つ以上の機能ブロックの機能は、コンピュータ読み取り可能なコンピュータプログラムに実装されてもよい。このコンピュータプログラムは、非一時的な記録媒体に格納されてもよく、その記録媒体を介して上記ノードのストレージにインストールされてもよい。または、上記コンピュータプログラムは、ネットワークを介してダウンロードされ、上記ノードのストレージにインストールされてもよい。上記ノードのＣＰＵは、上記コンピュータプログラムをメインメモリに読み出して実行することにより、上記ノードが備える１つ以上の機能ブロックの機能を発揮してもよい。

　ＧＣクラスタ１２のｂｆｄ部２２は、通信部における受信部として、ＣＤＣクラスタ１４ａのｂｆｄ部３１から数秒おきに繰り返し送信されるＢＦＤパケットを順次受信する。ＧＣクラスタ１２のｐｏｄ２６およびｅｎｖｏｙ２７は、通信部における送信部として、ＣＤＣクラスタ１４ａからのＢＦＤパケットを未受信の場合、ＣＤＣクラスタ１４ａに代えてＣＤＣクラスタ１４ｂへ対象データを送信する。

　ＣＤＣクラスタ１４ａに障害が発生した場合、または、ＧＣクラスタ１２とＣＤＣクラスタ１４ａ間の通信経路に障害が発生した場合、ＣＤＣクラスタ１４ａからのＢＦＤパケットが未受信となる。この場合に、ＧＣクラスタ１２は、当該障害を迅速に検知して、対象データの送信先を迅速にＣＤＣクラスタ１４ｂに切り替えることができる。

　ＧＣクラスタ１２のｂｆｄ部２２は、通信部における受信部として、ＣＤＣクラスタ１４ｂのｂｆｄ部４１から数秒おきに繰り返し送信されるＢＦＤパケットをさらに順次受信する。ＧＣクラスタ１２のｐｏｄ２６およびｅｎｖｏｙ２７は、通信部における送信部として、ＣＤＣクラスタ１４ａからのＢＦＤパケットを未受信であり、一方で、ＣＤＣクラスタ１４ｂからのＢＦＤパケットの受信を継続している場合、ＣＤＣクラスタ１４ａに代えてＣＤＣクラスタ１４ｂへ対象データを送信する。

　この態様によると、ＣＤＣクラスタ１４ａに障害が発生した場合、または、ＧＣクラスタ１２とＣＤＣクラスタ１４ａ間の通信経路に障害が発生した場合、ＣＤＣクラスタ１４ｂとの通信状態が正常であることを条件として、対象データの送信先を迅速にＣＤＣクラスタ１４ｂに切り替える。これにより、対象データを一層確実に送信先へ届けることができる。

　ＧＣクラスタ１２のｃｏｒｅｄｎｓ２１は、クラスタ内のｐｏｄ２６に対して、対象データの送信先の名前解決を行う。ｐｏｄ２６とｅｎｖｏｙ２７は、通信部における送信部として、対象データの送信先アドレスをｃｏｒｅｄｎｓ２１に問い合わせ、ｃｏｒｅｄｎｓ２１から提供された送信先アドレス宛に対象データを送信する。更新部２３は、ＣＤＣクラスタ１４ａからのＢＦＤパケットを未受信の場合、対象データの送信先アドレスを、ＣＤＣクラスタ１４ａのアドレスからＣＤＣクラスタ１４ｂのアドレスに変更するようｃｏｒｅｄｎｓ２１のレコードを更新する。この態様によると、ｃｏｒｅｄｎｓ２１のレコードを更新することで、対象データの送信先を柔軟に変更することができる。

　第１実施例の通信システム１０の動作を説明する。

　まず、図２を参照しつつ、通信システム１０の構築時の動作を説明する。ＧＣクラスタ１２は、データストア部２８を備えてもよい。データストア部２８は、開発者の操作に応じて、クバネテスクラスタのリソース（例えば、マスタノード２０、ｃｏｒｅｄｎｓ２１、ｂｆｄ部２２、更新部２３、ワーカノード２５、ｐｏｄ２６、ｅｎｖｏｙ２７）を登録する。ＣＤＣクラスタ１４ａのデータストア部３８とＣＤＣクラスタ１４ｂのデータストア部４８においても同様に、クバネテスクラスタのリソースが登録される。データストア部２８、３８、４８は、例えば、クバネテスのｋｕｂｅ－ａｐｉｓｅｒｖｅｒ、及び、ｅｔｃｄなどによって実装可能である。

　ＧＣクラスタ１２のｂｆｄ部２２は、開発者の操作に応じて、ＣＤＣクラスタ１４ａのｂｆｄ部３１とのネゴシエーションを実施する。また、ＧＣクラスタ１２のｂｆｄ部２２は、開発者の操作に応じて、ＣＤＣクラスタ１４ｂのｂｆｄ部４１とのネゴシエーションを実施する。このネゴシエーションにより、ＢＦＤパケットの送信先や送信タイミングを設定する。ＧＣクラスタ１２、ＣＤＣクラスタ１４ａ、ＣＤＣクラスタ１４ｂのそれぞれは、マスタノード２０のリーダ選定処理を実行する。実施例では、マスタノード２０ａ、マスタノード３０ａ、マスタノード４０ａがリーダとして選定されたこととする。

　本実施例では、少なくとも１つの外部システム（例えば、ＣＤＣクラスタ１４ａやＣＤＣクラスタ１４ｂ）の、所与の処理（例えば、上述のアプリケーション処理）における役割を示すサービスデータが、ＧＣクラスタ１２に登録される。このようなサービスデータの一例として、図３に示されている、ＧＣクラスタ１２のｃｏｒｅｄｎｓ２１に記憶されるＤＮＳレコードが挙げられる。

　図３は、ＧＣクラスタ１２のｃｏｒｅｄｎｓ２１に記憶されるＤＮＳレコードの例を示す。同図は、ｃｏｒｅｄｎｓ２１に当初設定されるＤＮＳレコードを示している。ＤＮＳレコード６０は、ＣＤＣクラスタ１４ａのｐｏｄ３６のＦＱＤＮ（ｐｏｄ．ＣＤＣ１．ｅｘａｍｐｌｅ．ｃｏｍ）と、ｐｏｄ３６のＩＰアドレスとを対応付けたＡレコード６２を含む。また、ＤＮＳレコード６０は、ＣＤＣクラスタ１４ｂのｐｏｄ４６のＦＱＤＮ（ｐｏｄ．ＣＤＣ２．ｅｘａｍｐｌｅ．ｃｏｍ）と、ｐｏｄ４６のＩＰアドレスとを対応付けたＡレコード６２を含む。

　また、ＤＮＳレコード６０は、ｐｏｄ３６とｐｏｄ４６のグループに対応する送信先仮想ドメイン名（ｐｏｄ．ｅｘａｍｐｌｅ．ｃｏｍ）と、その別名としてのｐｏｄ３６のＦＱＤＮ（ｐｏｄ．ＣＤＣ１．ｅｘａｍｐｌｅ．ｃｏｍ）とを対応付けたＣＮＡＭＥレコード６４を含む。

　図４は、ＧＣクラスタ１２の動作を示すフローチャートである。まず、ＣＤＣクラスタ１４ａの状態が正常であり、かつ、ＧＣクラスタ１２とＣＤＣクラスタ１４ａ間の通信経路も正常である場合の動作を説明する。ＧＣクラスタ１２のｂｆｄ部２２は、ＣＤＣクラスタ１４ａのｂｆｄ部３１へＢＦＤパケットを送信する処理を予め定められた時間おきに繰り返し実行する。また、ｂｆｄ部２２は、ＣＤＣクラスタ１４ｂのｂｆｄ部４１へＢＦＤパケットを送信する処理を予め定められた時間おきに繰り返し実行する（Ｓ１０）。

　また、ＧＣクラスタ１２のｂｆｄ部２２は、ＣＤＣクラスタ１４ａのｂｆｄ部３１から予め定められた時間おきに繰り返し送信されたＢＦＤパケットを順次受信する。また、ｂｆｄ部２２は、ＣＤＣクラスタ１４ｂのｂｆｄ部４１から予め定められた時間おきに繰り返し送信されたＢＦＤパケットを順次受信する（Ｓ１２）。ここでは、ＣＤＣクラスタ１４ａからのＢＦＤパケットと、ＣＤＣクラスタ１４ｂからのＢＦＤパケットのいずれも、例えば数秒おきに繰り返し受信されるものとする。ＧＣクラスタ１２の更新部２３は、ｂｆｄ部２２におけるＢＦＤパケットの受信状況が正常であると判定し、ｃｏｒｅｄｎｓ２１のＤＮＳレコード６０を更新する処理をスキップする（Ｓ１４のＹ）。

　ＧＣクラスタ１２のｐｏｄ２６は、ＣＤＣクラスタ１４ａまたはＣＤＣクラスタ１４ｂへ送信すべき対象データを取得する（Ｓ１８）。ｐｏｄ２６は、送信先仮想ドメイン名（ｐｏｄ．ｅｘａｍｐｌｅ．ｃｏｍ）を指定した名前解決の問い合わせをｃｏｒｅｄｎｓ２１へ送信する。ｃｏｒｅｄｎｓ２１は、送信先仮想ドメイン名に対応するｐｏｄ３６のＩＰアドレスをｐｏｄ２６へ返す（Ｓ２０）。なお、ｐｏｄ２６は、ｃｏｒｅｄｎｓ２１のＣＮＡＭＥレコード６４とＡレコード６２を順次検索し、送信先仮想ドメイン名に対応するｐｏｄ３６のＩＰアドレスをｃｏｒｅｄｎｓ２１から取得してもよい。

　ＧＣクラスタ１２のｐｏｄ２６は、対象データを含む電文であって、かつ、ｐｏｄ３６のＩＰアドレスを送信先アドレスとして指定した電文をｅｎｖｏｙ２７に渡す（Ｓ２２）。ｅｎｖｏｙ２７は、プロキシ部として、ｐｏｄ２６から対象データを受け付け、ＣＤＣクラスタ１４ａまたはＣＤＣクラスタ１４ｂへ対象データを送信することを代行する。ここでは、ｅｎｖｏｙ２７は、対象データを含む電文であって、かつ、ｐｏｄ３６のＩＰアドレスを送信先アドレスとして指定した電文をＷＡＮ５２へ送出することで、対象データをＣＤＣクラスタ１４ａのｐｏｄ３６（ｅｎｖｏｙ３７）へ送信する（Ｓ２４）。

　次に、ＣＤＣクラスタ１４ａに障害が発生し、または、ＧＣクラスタ１２とＣＤＣクラスタ１４ａ間の通信経路に障害が発生した場合の動作を説明する。ＧＣクラスタ１２のｂｆｄ部２２は、ＣＤＣクラスタ１４ａのｂｆｄ部３１から送信されたＢＦＤパケットを、予め定められた時間を超えて未受信となる。その一方、ｂｆｄ部２２は、ＣＤＣクラスタ１４ｂのｂｆｄ部４１から送信されたＢＦＤパケットを予め定められた時間間隔で繰り返し受信することを継続する。

　ＧＣクラスタ１２の更新部２３は、ｂｆｄ部２２におけるＢＦＤパケットの受信状況を確認する。更新部２３は、ＣＤＣクラスタ１４ａからのＢＦＤパケットが予め定められた時間を超えて未受信であり、かつ、ＣＤＣクラスタ１４ｂからのＢＦＤパケットが定期的に受信され続けている場合（Ｓ１４のＮ）、対象データの送信先アドレスを、ＣＤＣクラスタ１４ａのｐｏｄ３６のＩＰアドレスからＣＤＣクラスタ１４ｂのｐｏｄ４６のＩＰアドレスに変更するようｃｏｒｅｄｎｓ２１のレコードを更新する（Ｓ１６）。

　図５は、ＧＣクラスタ１２のｃｏｒｅｄｎｓ２１に記憶されるＤＮＳレコードの例を示す。同図は、更新後のＤＮＳレコードを示している。更新部２３は、ｐｏｄ３６とｐｏｄ４６のグループに対応する送信先仮想ドメイン名（ｐｏｄ．ｅｘａｍｐｌｅ．ｃｏｍ）と、その別名としてのｐｏｄ４６のＦＱＤＮ（ｐｏｄ．ＣＤＣ２．ｅｘａｍｐｌｅ．ｃｏｍ）とを対応付けるようＣＮＡＭＥレコード６４を変更する。

　図４に戻り、ＧＣクラスタ１２のｐｏｄ２６は、対象データを取得し（Ｓ１８）、送信先仮想ドメイン名（ｐｏｄ．ｅｘａｍｐｌｅ．ｃｏｍ）を指定した名前解決の問い合わせをｃｏｒｅｄｎｓ２１へ送信し、送信先仮想ドメイン名に対応づけられたｐｏｄ４６のＩＰアドレスをｃｏｒｅｄｎｓ２１から取得する（Ｓ２０）。ｐｏｄ２６は、対象データを含む電文であって、かつ、ｐｏｄ４６のＩＰアドレスを送信先アドレスとして指定した電文をｅｎｖｏｙ２７に渡す（Ｓ２２）。ｅｎｖｏｙ２７は、当該電文をＷＡＮ５２へ送出することで、対象データをＣＤＣクラスタ１４ｂのｐｏｄ４６（ｅｎｖｏｙ４７）へ送信する（Ｓ２４）。なお、図４のＳ１０～Ｓ１６の処理と、Ｓ１８～Ｓ２４の処理は並行して実行されてもよい。

　このように、第１実施例のＧＣクラスタ１２は、対象データの本来の送信先であるＣＤＣクラスタ１４ａに障害が発生し、または、ＧＣクラスタ１２とＣＤＣクラスタ１４ａ間の通信経路に障害が発生した場合、ＢＦＤパケットの受信状況に基づきその障害を迅速に検知できる。ＧＣクラスタ１２は、障害の発生を検知した場合に、ＣＤＣクラスタ１４ａに代えてＣＤＣクラスタ１４ｂへ対象データを送信することで、クバネテスクラスタ間での通信の遅延を抑制することができる。

　また、以上で説明したように、ＣＤＣ１は、送信先仮想ドメイン名（ｐｏｄ．ｅｘａｍｐｌｅ．ｃｏｍ）に対応する送信先としての役割を担っている。また、ＣＤＣ２は、送信先仮想ドメイン名（ｐｏｄ．ｅｘａｍｐｌｅ．ｃｏｍ）に対応する送信先のバックアップ（ＣＤＣ１のバックアップ）としての役割を担っている。そして、これらのことが、図３に示すＤＮＳレコード６０に示されている。

＜第２実施例＞
　本実施例に関して、第１実施例と相違する点を中心に以下説明し、共通する点の説明を適宜省略する。本実施例の構成要素のうち第１実施例の構成要素と同一または対応する構成要素には同一の符号を付して説明する。

　図６は、第２実施例の通信システム１０の構成を示す図である。第２実施例の通信システム１０も、第１実施例の通信システム１０と同様に、ＧＣクラスタ１２、ＣＤＣクラスタ１４ａ、ＣＤＣクラスタ１４ｂを備える。第２実施例の各クラスタのノード構成および機能ブロックは、第１実施例と同様である。

　ＧＣクラスタ１２のｅｎｖｏｙ２７は、プロキシ部として、ｐｏｄ２６から対象データを受け付け、ＣＤＣクラスタ１４ａへ対象データを送信することを代行する。ｅｎｖｏｙ２７は、ＣＤＣクラスタ１４ａからＢＦＤパケットを未受信の場合、対象データの送信先アドレスを、ＣＤＣクラスタ１４ａのＩＰアドレスからＣＤＣクラスタ１４ｂのＩＰアドレスに書き換える。

　第２実施例の通信システム１０の動作を説明する。ここでは、第１実施例の通信システム１０と異なる動作として、ＣＤＣクラスタ１４ａに障害が発生し、または、ＧＣクラスタ１２とＣＤＣクラスタ１４ａ間の通信経路に障害が発生した場合の動作を説明する。

　図７は、ＧＣクラスタ１２のｃｏｒｅｄｎｓ２１に記憶されるＤＮＳレコードの例を示す。ＤＮＳレコード６０は、ＣＤＣクラスタ１４ａのｐｏｄ３６とＣＤＣクラスタ１４ｂのｐｏｄ４６のグループに対応する送信先仮想ドメイン名（ｐｏｄ．ｅｘａｍｐｌｅ．ｃｏｍ）と、ＣＤＣクラスタ１４ａのｐｏｄ３６のＩＰアドレスとを対応付けたＡレコード６２を含む。第２実施例のＤＮＳレコード６０は、第１実施例のＤＮＳレコード６０と異なり、ＢＦＤパケットの受信状況が変化しても変更されない。

　図８は、ＧＣクラスタ１２の動作を示すフローチャートである。同図のＳ３０とＳ３２は、図４のＳ１０とＳ１２と同じであるため説明を省略する。ＧＣクラスタ１２の更新部２３は、ｂｆｄ部２２におけるＢＦＤパケットの受信状況を確認する。ここでは、ＣＤＣクラスタ１４ａからのＢＦＤパケットは、予め定められた時間を超えて未受信であり、一方、ＣＤＣクラスタ１４ｂからのＢＦＤパケットは、定期的に受信され続けている。

　更新部２３は、ＢＦＤパケットの受信状況を異常と判定し（Ｓ３４のＮ）、対象データの送信先アドレスを、ＣＤＣクラスタ１４ａのｐｏｄ３６のＩＰアドレスからＣＤＣクラスタ１４ｂのｐｏｄ４６のＩＰアドレスに変更するようｅｎｖｏｙ２７に指示する（Ｓ３６）。例えば、更新部２３は、対象データの送信先アドレスを、ｐｏｄ３６のＩＰアドレスからｐｏｄ４６のＩＰアドレスに変更することを指示する内容のファイルやフラグをｅｎｖｏｙ２７が参照可能な記憶領域に格納してもよい。ＢＦＤパケットの受信状況が正常であれば（Ｓ３４のＹ）、Ｓ３６の処理をスキップする。

　ＧＣクラスタ１２のｐｏｄ２６は、対象データを取得し（Ｓ３８）、送信先仮想ドメイン名（ｐｏｄ．ｅｘａｍｐｌｅ．ｃｏｍ）を指定した名前解決の問い合わせをｃｏｒｅｄｎｓ２１へ送信し、送信先仮想ドメイン名に対応づけられたＣＤＣクラスタ１４ａのｐｏｄ３６のＩＰアドレスをｃｏｒｅｄｎｓ２１から取得する（Ｓ４０）。ｐｏｄ２６は、対象データを含む電文であって、かつ、ｐｏｄ３６のＩＰアドレスを送信先アドレスとして指定した電文（ここでは「送信電文」と呼ぶ。）をｅｎｖｏｙ２７に渡す（Ｓ４２）。

　ｅｎｖｏｙ２７は、更新部２３から送信先アドレス変更の指示を受け付けた場合であり、例えば、上記指示を含むファイルが所定の記憶領域に格納された場合（Ｓ４４のＹ）、ｐｏｄ２６から出力された送信電文の送信先アドレスをＣＤＣクラスタ１４ｂのｐｏｄ４６のＩＰアドレスに書き換える（Ｓ４６）。ｅｎｖｏｙ２７は、送信先アドレス書き換え後の送信電文をＷＡＮ５２へ送出することで、対象データをＣＤＣクラスタ１４ｂのｐｏｄ４６（ｅｎｖｏｙ４７）へ送信する（Ｓ４８）。

　送信先アドレス変更の指示を受け付けていなければ（Ｓ４４のＮ）、Ｓ４６の処理をスキップする。この場合、ｅｎｖｏｙ２７は、ｐｏｄ２６から出力された送信電文を、送信先アドレスを書き換えることなくＷＡＮ５２へ送出することで、対象データをＣＤＣクラスタ１４ａのｐｏｄ３６（ｅｎｖｏｙ３７）へ送信する（Ｓ４８）。なお、図８のＳ３０～Ｓ３６の処理と、Ｓ３８～Ｓ４８の処理は並行して実行されてもよい。

　第２実施例のＧＣクラスタ１２も、第１実施例のＧＣクラスタ１２と同様の効果を奏する。すなわち、第２実施例の通信システム１０においても、クバネテスクラスタ間での通信の遅延を抑制することができる。

＜第３実施例＞
　本開示の第３実施例では、以下で説明するようにして、データストア部２８へのリソースの登録をトリガとした、クラスタ間の通信の確立が行われる。

　以下、第３実施例に関し、データストア部２８へのリソースの登録をトリガとしたクラスタ間の通信の確立に関する機能を中心に、また、第１実施例や第２実施例と相違する点を中心に説明し、共通する点の説明を適宜省略する。本実施例の構成要素のうち第１実施例や第２実施例の構成要素と同一または対応する構成要素には同一の符号を付して説明する。

　第３実施例では、ＧＣクラスタ１２が、任意のコンピュータシステムからの通信確立要求の受付に応じた当該コンピュータシステムへの応答が可能な外部システムのアドレスを示すリソースデータをデータストア部２８に登録する。

　図９は、ＧＣクラスタ１２のデータストア部２８に登録されるリソースデータのデータ構造の一例を示す図である。図９に示すように、リソースデータには、例えば、アドレスデータ、ドメイン名データ、クレデンシャルデータ、などが含まれる。

　第３実施例に係るリソースデータは、通信システム１０に含まれるクラスタ等のコンピュータシステムに対応付けられるデータである。

　リソースデータに含まれるアドレスデータは、当該リソースデータに対応付けられるコンピュータシステムのアドレス（ここでは例えばＩＰアドレス）を示すデータである。

　当該リソースデータに含まれるドメイン名データは、当該リソースデータに対応付けられるコンピュータシステムのドメイン名（ここでは例えばＦＱＤＮ）を示すデータである。

　当該リソースデータに含まれるクレデンシャルデータは、当該リソースデータに対応付けられるコンピュータシステムとの通信を確立する際に必要となるユーザ名やパスワードなどといった認証情報（クレデンシャル）を示すデータである。

　以下の説明では、初期状態において、ＣＤＣ１及びＣＤＣ２のリソースデータがＧＣクラスタ１２のデータストア部２８には登録されていないこととする。

　また、以下の説明では、予め、ＧＣクラスタ１２のリーダとしてマスタノード２０ａが選定されていることとする。また、ＧＣクラスタ１２のｂｆｄ部２２は起動されており、通信が可能な状態となっていることとする。

　本実施例において、例えば、ＣＤＣ１のセットアップが終了し、ＣＤＣ１が利用可能となったとする。また、ＣＤＣクラスタ１４ａのリーダとしてマスタノード３０ａが選定されたとする。そして、ＣＤＣクラスタ１４ａのｂｆｄ部３１は起動され、任意のコンピュータシステムからの通信確立要求の受付に応じた当該コンピュータシステムへの応答が可能な状態となったとする。

　この状況で、例えば開発者の操作に応じて、ＧＣクラスタ１２は、上述のように、外部システムのアドレスを示すリソースデータをデータストア部２８に登録する。この状況では、例えば、ＧＣクラスタ１２が所与のコンピュータシステムに相当し、ＣＤＣ１が外部システムに相当する。

　すると、ＧＣクラスタ１２のｂｆｄ部２２は、リソースデータの登録に応じて、当該リソースデータにアドレスが示されている外部システムに所与のコンピュータシステムから通信確立要求が送信されるよう制御することで、当該所与のコンピュータシステムと外部システムとの間での通信を確立する。この状況では、ＣＤＣ１が外部システムに相当し、所与のコンピュータシステムがＧＣクラスタ１２に相当する。この例では、ＣＤＣ１との間で通信が確立されるコンピュータシステムは、リソースデータが登録されるコンピュータシステムと同じＧＣクラスタ１２である。なお、ＣＤＣ１との間で通信が確立されるコンピュータシステムと、リソースデータが登録されるコンピュータシステムとは異なっていてもよい。

　例えば、ＧＣクラスタ１２のｂｆｄ部２２が、ＣＤＣ１に対応付けられるリソースデータのデータストア部２８への登録をトリガとして、ＣＤＣクラスタ１４ａのｂｆｄ部３１とのネゴシエーションを実施する。このネゴシエーションにより、ＧＣクラスタ１２とＣＤＣクラスタ１４ａとの間の通信（ＢＦＤセッション）が確立され、ＢＦＤパケットの送信先や送信タイミングが設定される。

　その後、ＧＣクラスタ１２が、通信が確立された外部システムの、所与のコンピュータシステムが実行する所与の処理における役割を設定する。例えば、ＧＣクラスタ１２が実行するアプリケーション処理が、所与のコンピュータシステムが実行する所与の処理に相当する。

　ここで、ＧＣクラスタ１２が、例えば開発者の操作に応じて、所与の処理における外部システム（ここでは例えばＣＤＣ１）の役割を示すサービスデータを登録してもよい。サービスデータの一例としては、上述の対象データの送信先の名前解決に用いられるＤＮＳレコード６０が挙げられる。

　ここで例えば、ＧＣクラスタ１２が、開発者の操作に応じて、図７に例示されているＤＮＳレコード６０がＧＣクラスタ１２のｃｏｒｅｄｎｓ２１に登録されるとする。上述のように、図７に示すＤＮＳレコード６０は、ＣＤＣクラスタ１４ａのｐｏｄ３６とＣＤＣクラスタ１４ｂのｐｏｄ４６のグループに対応する送信先仮想ドメイン名（ｐｏｄ．ｅｘａｍｐｌｅ．ｃｏｍ）と、ＣＤＣクラスタ１４ａのｐｏｄ３６のＩＰアドレスとを対応付けたＡレコード６２を含む。

　すると、上述のように、ｃｏｒｅｄｎｓ２１は、ｐｏｄ２６から送信される、送信先仮想ドメイン名（ｐｏｄ．ｅｘａｍｐｌｅ．ｃｏｍ）を指定した名前解決の問い合わせの受付に応じて、ｐｏｄ３６のＩＰアドレスをｐｏｄ２６へ返すこととなる。

　このようにして、図１０に示すように、ＧＣクラスタ１２のｐｏｄ２６が取得する対象データを、ｅｎｖｏｙ２７経由で、ＣＤＣクラスタ１４ａに送信することが可能となる。

　その後、例えば、ＣＤＣクラスタ１４ａのバックアップとしての役割を担う、ＣＤＣクラスタ１４ｂのセットアップが行われ、ＣＤＣ２が利用可能となったとする。また、ＣＤＣクラスタ１４ｂのリーダとしてマスタノード３０ｂが選定されたとする。そして、ＣＤＣクラスタ１４ｂのｂｆｄ部４１は起動され、任意のコンピュータシステムからの通信確立要求の受付に応じた当該コンピュータシステムへの応答が可能な状態となったとする。

　そして、ＧＣクラスタ１２が、所与のコンピュータシステムが既存の外部システムと連携して所与の処理を実行している際に、新規の外部システムのアドレスを示すリソースデータをデータストア部２８に登録する。この状況では、例えば、ＧＣクラスタ１２が所与のコンピュータシステムに相当し、ＣＤＣ１が既存の外部システムに相当し、ＣＤＣ２が新規の外部システムに相当する。

　ここでは例えば、開発者の操作に応じて、ＣＤＣ２に対応付けられるリソースデータがデータストア部２８に登録される。

　すると、ＧＣクラスタ１２のｂｆｄ部２２は、当該リソースデータの登録に応じて、当該リソースデータにアドレスが示されている外部システムに所与のコンピュータシステムから通信確立要求が送信されるよう制御することで、ＧＣクラスタ１２とＣＤＣ２との間での通信を確立する。

　例えば、ＧＣクラスタ１２のｂｆｄ部２２は、ＣＤＣ２に対応付けられるリソースデータのデータストア部２８への登録をトリガとして、ＣＤＣクラスタ１４ｂのｂｆｄ部４１とのネゴシエーションを実施する。このネゴシエーションにより、ＧＣクラスタ１２とＣＤＣクラスタ１４ｂとの間の通信（ＢＦＤセッション）が確立され、ＢＦＤパケットの送信先や送信タイミングが設定される。

　その後、ＧＣクラスタ１２が、通信が確立された外部システムの、所与の処理における既存の外部システムとの関係での役割を設定する。この状況では、例えば、ＣＤＣ２が、通信が確立された外部システムに相当し、ＣＤＣ１が、既存の外部システムに相当する。

　ここで例えば、ＣＤＣ２が、ＣＤＣ１のバックアップの役割であることが設定されてもよい。

　例えば、開発者の操作に応じて、ＧＣクラスタ１２のｃｏｒｅｄｎｓ２１に登録されているＤＮＳレコード６０が、図７に示すものから図３に示すものに更新されてもよい。

　上述のように、図３に示すＤＮＳレコード６０は、ＣＤＣクラスタ１４ａのｐｏｄ３６のＦＱＤＮ（ｐｏｄ．ＣＤＣ１．ｅｘａｍｐｌｅ．ｃｏｍ）と、ｐｏｄ３６のＩＰアドレスとを対応付けたＡレコード６２を含む。また、ＤＮＳレコード６０は、ＣＤＣクラスタ１４ｂのｐｏｄ４６のＦＱＤＮ（ｐｏｄ．ＣＤＣ２．ｅｘａｍｐｌｅ．ｃｏｍ）と、ｐｏｄ４６のＩＰアドレスとを対応付けたＡレコード６２を含む。

　このようにして、ＣＤＣ２がＣＤＣ１のバックアップであることが示された、図３に示すＤＮＳレコード６０が、ｃｏｒｅｄｎｓ２１に登録される。

　第３実施例では、第１実施例と同様に、ｐｏｄ２６は、所与の処理に関する対象データを既存の外部システムに送信する。

　そして、第１実施例と同様に、既存の外部システムの障害又は所与のコンピュータシステムと既存の外部システムとの間の通信経路の障害が発生したとする。

　この場合、ｐｏｄ２６は、既存の外部システムに代えて新規の外部システムに対象データを送信する。

　この状況では、例えば、ＣＤＣ１が既存の外部システムに相当し、ＧＣクラスタ１２が所与のコンピュータシステムに相当し、ＣＤＣ２が新規の外部システムに相当する（図２参照）。

　そのため、第３処理例でも、クバネテスクラスタ間での通信の遅延を抑制することができる。

　なお、第３処理例でも、第１処理例と同様に、ｂｆｄ部２２は、ＣＤＣ１から繰り返し送信されるパケットであって、ＣＤＣ１との間のパスの正常性を監視するためのパケット（例えばＢＦＤパケット）を受信してもよい。

　また、ｂｆｄ部２２は、ＣＤＣ２から繰り返し送信されるパケットであって、ＣＤＣ２との間のパスの正常性を監視するためのパケット（例えばＢＦＤパケット）を受信してもよい。

　そして、第１処理例と同様に、ｐｏｄ２６は、ＣＤＣ１からパケットを未受信の場合、ＣＤＣ１に代えてＣＤＣ２に対象データを送信してもよい。ここで、ｐｏｄ２６は、ＣＤＣ１からパケットを未受信であり、かつ、ＣＤＣ２からパケットを受信している場合、ＣＤＣ１に代えてＣＤＣ２に対象データを送信してもよい。

　第３実施例では、ＣＤＣ１のリソースデータの登録時にはＣＤＣ１のｂｆｄ部３１が既に起動されている。また、ＣＤＣ２のリソースデータの登録時にはＣＤＣ２のｂｆｄ部４１が既に起動されている。そのため、第３実施例では、リソースデータが登録されると、開発者の操作を介することなく、登録されたリソースデータに応じたＢＦＤセッションが確立されることとなる。

　また、第３実施例では、外部システムの増設と、当該外部システムのサービスへの登録とを独立して行うことができる。そのため、予め外部システムをいくつか増設してＢＦＤセッションの確立が実行された後で、適宜、ＢＦＤセッションが確立された当該外部システムをサービスに登録すること（例えば、当該外部システムをＤＮＳレコード６０に登録すること）が可能となる。

　このようにして、第３実施例によれば、通信システム１０のスムーズな拡張が可能となる。

　ここで、第３実施例においてＧＣクラスタ１２で実行される処理の流れの一例を、図１１を参照しながら説明する。

　まず、開発者の操作に従って、ＧＣクラスタ１２は、データストア部２８に、通信システム１０に新たに追加される外部システムのリソースデータを登録する（Ｓ５０）。

　そして、ＧＣクラスタ１２のｂｆｄ部２２は、Ｓ５０に示す処理で登録されたリソースデータを参照して、当該リソースデータに対応付けられる外部システムとの間でｂｆｄのネゴシエーションを実施する（Ｓ５２）。このネゴシエーションに係る処理には、例えば、ＧＣクラスタ１２から当該外部システムへの通信確立要求の送信処理が含まれる。Ｓ５２に示す処理では、当該リソースデータに基づいて、ネゴシエーションを実施する相手である外部システムを特定してもよい。そして特定される外部システムに対して、当該リソースデータに含まれるクレデンシャルデータを用いた認証が実行されてもよい。また、Ｓ５２に示す処理では、Ｓ５０に示す処理で登録されたリソースデータが外部システムに送信されてもよい。そして、このリソースデータが送信先の外部システムのデータストア部に登録されてもよい。Ｓ５２に示す処理が実行されることで、ＧＣクラスタ１２と当該外部システムとの間の通信が確立されることとなる。

　そして、開発者の操作に従って、ＧＣクラスタ１２は、ｃｏｒｅｄｎｓ２１に、Ｓ５０に示す処理で登録されたリソースデータに対応付けられる外部システムの役割が示されたサービスデータ（上述の例ではＤＮＳレコード６０）を登録する（Ｓ５４）。そして、本処理例に示す処理は終了される。

　以後、図４に示す処理と同様の処理が実行される。

　なお、Ｓ５４に示す処理でＤＮＳレコード６０の登録が行われる必要はない。例えば、Ｓ５０に示す処理でのリソースデータの登録に応じて、ＣＤＣクラスタ１４ａだけに対して対象データの送信が行われる状態から、図８に示されている動作が行われるよう、ＧＣクラスタ１２が制御してもよい。例えば、ＣＤＣクラスタ１４ａからのＢＦＤパケットを未受信である場合にＣＤＣクラスタ１４ｂに対象データが送信されるようＧＣクラスタ１２が制御してもよい。

　以上、本開示を第１実施例、第２実施例、及び、第３実施例をもとに説明した。これらの実施例は例示であり、各構成要素あるいは各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本開示の技術の範囲にあることは当業者に理解されるところである。

　上述した実施例および変形例の任意の組み合わせもまた本開示の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施例および変形例それぞれの効果をあわせもつ。また、請求項に記載の各構成要件が果たすべき機能は、実施例および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。

Claims

　任意のコンピュータシステムからの通信確立要求の受付に応じた当該コンピュータシステムへの応答が可能な外部システムのアドレスを示すリソースデータを登録するリソースデータ登録手段と、
　前記リソースデータの登録に応じて、当該リソースデータにアドレスが示されている前記外部システムに所与のコンピュータシステムから通信確立要求が送信されるよう制御することで、当該所与のコンピュータシステムと前記外部システムとの間での通信を確立する通信確立手段と、
　前記通信が確立された前記外部システムの、前記所与のコンピュータシステムが実行する所与の処理における役割を設定する役割設定手段と、
　を含むことを特徴とする管理システム。
　前記リソースデータ登録手段は、前記所与のコンピュータシステムが既存の前記外部システムと連携して前記処理を実行している際に、新規の前記外部システムのアドレスを示す前記リソースデータを登録し、
　前記通信確立手段は、前記リソースデータの登録に応じて、前記所与のコンピュータシステムと前記新規の前記外部システムとの間での通信を確立し、
　前記役割設定手段は、前記通信が確立された前記新規の前記外部システムの、前記処理における前記既存の前記外部システムとの関係での役割を設定する、
　ことを特徴とする請求項１に記載の管理システム。
　前記役割設定手段は、前記新規の前記外部システムが、前記既存の前記外部システムのバックアップの役割であることを設定する、
　ことを特徴とする請求項２に記載の管理システム。
　前記処理に関する対象データを前記既存の前記外部システムに送信する送信手段、をさらに含み、
　前記送信手段は、前記既存の前記外部システムの障害又は前記所与のコンピュータシステムと前記既存の前記外部システムとの間の通信経路の障害が発生した場合に、前記既存の前記外部システムに代えて前記新規の前記外部システムに前記対象データを送信する、
　ことを特徴とする請求項３に記載の管理システム。
　前記既存の前記外部システムから繰り返し送信されるパケットであって、前記既存の前記外部システムとの間のパスの正常性を監視するためのパケットを受信する受信手段、をさらに含み、
　前記送信手段は、前記既存の前記外部システムから前記パケットを未受信の場合、前記既存の前記外部システムに代えて前記新規の前記外部システムに前記対象データを送信する、
　ことを特徴とする請求項４に記載の管理システム。
　前記受信手段は、前記新規の前記外部システムから繰り返し送信されるパケットであって、前記新規の前記外部システムとの間のパスの正常性を監視するためのパケットをさらに受信し、
　前記送信手段は、前記既存の前記外部システムから前記パケットを未受信であり、かつ、前記新規の前記外部システムから前記パケットを受信している場合、前記既存の前記外部システムに代えて前記新規の前記外部システムに前記対象データを送信する、
　ことを特徴とする請求項５に記載の管理システム。
　前記パケットは、ＢＦＤ（Ｂｉｄｉｒｅｃｔｉｏｎａｌ　Ｆｏｒｗａｒｄｉｎｇ　Ｄｅｔｅｃｔｉｏｎ）パケットである、
　ことを特徴とする請求項５又は６に記載の管理システム。
　前記処理における前記外部システムの役割を示すサービスデータを登録するサービスデータ登録手段、をさらに含む、
　ことを特徴とする請求項１から７のいずれか一項に記載の管理システム。
　前記サービスデータは、前記処理に関する対象データの送信先の名前解決に用いられるＤＮＳ（Ｄｏｍａｉｎ　Ｎａｍｅ　Ｓｙｓｔｅｍ）レコードである、
　ことを特徴とする請求項８に記載の管理システム。
　任意のコンピュータシステムからの通信確立要求の受付に応じた当該コンピュータシステムへの応答が可能な外部システムのアドレスを示すリソースデータを登録するステップと、
　前記リソースデータの登録に応じて、当該リソースデータにアドレスが示されている前記外部システムに所与のコンピュータシステムから通信確立要求が送信されるよう制御することで、当該所与のコンピュータシステムと前記外部システムとの間での通信を確立するステップと、
　前記通信が確立された前記外部システムの、前記所与のコンピュータシステムが実行する所与の処理における役割を設定するステップと、
　を含むことを特徴とする管理方法。