JP6988973B2

JP6988973B2 - Ｏｐｃｕａを用いたシステム処理、ｏｐｃｕａを用いた通信方法、及び負荷分散装置

Info

Publication number: JP6988973B2
Application number: JP2020166830A
Authority: JP
Inventors: グェンヴィエン; クレイパトリック; ルーブレンドン
Original assignee: Yokogawa Electric Corp
Current assignee: Yokogawa Electric Corp
Priority date: 2019-10-31
Filing date: 2020-10-01
Publication date: 2022-01-05
Anticipated expiration: 2040-10-01
Also published as: EP3817335A1; JP2021072105A; US20210136143A1; US11032362B2; EP3817335B1

Description

ＯＰＣ（Open Platform Communications）ＵＡ（Unified Architecture）は、プラットフォームから独立した、サービス中心のアーキテクチャであり、機械同士の通信、機械と企業体との通信、及び中間にある他の全てのものを含む、企業体全体での相互運用に必要な基盤を提供するアーキテクチャである。

ＯＰＣＵＡクライアントは、冗長サーバセットを含むＯＰＣＵＡサーバの、複数のエンドポイントのユニフォームリソースロケータ（ＵＲＬ）を指定することができない。その結果、ＯＰＣＵＡクライアントは、冗長サーバセットにおいてＯＰＣＵＡサーバと通信できない。それにもかかわらず、ユーザは、冗長サーバセットにおいてＯＰＣＵＡクライアントを用いてＯＰＣＵＡサーバと通信可能になることを希望している。

一以上の実施形態は、ＯＰＣＵＡを用いたシステム処理を提供する。前記システムは、第１のＯＰＣＵＡサーバ及び第２のＯＰＣＵＡサーバを備える冗長サーバセットと、前記冗長サーバセットと通信するエンドポイントユニフォームリソースロケータ（ＵＲＬ）を指定するＯＰＣＵＡクライアントと、前記冗長サーバセットと前記ＯＰＣＵＡクライアントとの間に接続された負荷分散装置（ＬＢ）と、を備える。前記ＯＰＣＵＡクライアントは、前記エンドポイントＵＲＬに接続要求を送信する。前記第１のＯＰＣＵＡサーバは、アクティブサーバである。前記第２のＯＰＣＵＡサーバは、スタンバイサーバである。前記ＬＢは、前記第１のＯＰＣＵＡサーバへの接続をプロキシする。前記エンドポイントＵＲＬは、前記第１のＯＰＣＵＡサーバ及び前記第２のＯＰＣＵＡサーバのそれぞれのＵＲＬとは異なる。

一以上の実施形態は、ＯＰＣＵＡを用いた通信方法を提供する。前記通信方法は、ＯＰＣＵＡクライアントにより、第１のＯＰＣＵＡサーバ及び第２のＯＰＣＵＡサーバを備える冗長サーバセットと通信するＵＲＬを指定するステップと、前記ＯＰＣＵＡクライアントにより、前記エンドポイントＵＲＬに接続要求を送信するステップと、前記冗長サーバセットと前記ＯＰＣＵＡクライアントとの間に接続されたＬＢにより、前記第１のＯＰＣＵＡサーバへの接続をプロキシするステップと、を含む。前記第１のＯＰＣＵＡサーバは、アクティブサーバである。前記第２のＯＰＣＵＡサーバは、スタンバイサーバである。前記エンドポイントＵＲＬは、前記第１のＯＰＣＵＡサーバ及び前記第２のＯＰＣＵＡサーバのそれぞれのＵＲＬとは異なる。

一以上の実施形態は、ＯＰＣＵＡを用いて処理を行うシステムのＬＢを提供する。前記ＬＢは、エンドポイントユニフォームリソースロケータ（ＵＲＬ）への接続要求をＯＰＣＵＡクライアントから受信する送受信部と、前記送受信部に接続されたプロセッサと、を備える。前記ＬＢは、冗長サーバセットと前記ＯＰＣＵＡクライアントとの間に接続されている。前記冗長サーバセットは、第１のＯＰＣＵＡサーバ及び第２のＯＰＣＵＡサーバを備えている。前記エンドポイントＵＲＬは、前記冗長サーバセットと通信するＯＰＣＵＡクライアントにより指定される。前記プロセッサは、前記要求に基づいて前記第１のＯＰＣＵＡサーバへの接続をプロキシする。前記第１のＯＰＣＵＡサーバは、アクティブサーバである。前記第２のＯＰＣＵＡサーバは、スタンバイサーバである。前記エンドポイントＵＲＬは、前記第１のＯＰＣＵＡサーバ及び前記第２のＯＰＣＵＡサーバのそれぞれのＵＲＬとは異なる。

一以上の実施形態によれば、本格的な改変、負荷分散装置の導入によるＯＰＣＵＡサーバの再コンパイル、及び、ＯＰＣＵＡＰｕｂ／Ｓｕｂ通信モジュールと連動させたファイアウォールテーブルの操作を行うことなく、任意のＯＰＣＵＡサーバから透過的な冗長サーバセットを構成することが可能である。

一以上の実施形態に係る、ＯＰＣＵＡシステムを示す図である。一以上の実施形態に係る、ＯＰＣＵＡクライアントのハードウェアの概略図である。一以上の実施形態に係る、エンドポイントＵＲＬを指定するための、ＯＰＣＵＡクライアントに表示される管理者設定の概略図である。一以上の実施形態に係る、負荷分散装置のハードウェアの概略図である。一以上の実施形態に係る、ＯＰＣＵＡサーバのハードウェアの概略図である。一以上の実施形態に係る、ＯＰＣＵＡシステムにおける初期化後の処理のシーケンス図である。一以上の実施形態に係る、サーバ名及びサーバＵＲＬに関連付けられたエンドポイントＵＲＬを示す、負荷分散装置に含まれるテーブルである。一以上の実施形態に係る、ＯＰＣＵＡシステムにおけるフェイルオーバーの処理のシーケンス図である。一以上の実施形態に係る、ＯＰＣＵＡシステムの初期化後の処理のフローチャートである。一以上の実施形態に係る、ＯＰＣＵＡシステムにおけるフェイルオーバー処理のフローチャートである。

本発明の実施形態について、図面を参照しながら、以下詳細に説明する。整合をとるため、複数の図面における同じ要素は、同じ参照符号で示される。

より完全な発明の理解のため、以下の発明の実施形態の説明において、多数の具体的な詳細について説明する。しかしながら、当業者にとって、発明がこれらの具体的な詳細以外で実施され得ることは明らかである。他の例において、発明が不明確になるのを回避するために、周知の構成については詳細に説明していない。

図１は、一以上の実施形態に係る、ＯＰＣＵＡシステム１を示す。ＯＰＣＵＡシステム１は、ＯＰＣＵＡクライアント１１０と、負荷分散装置（ＬＢ）１２０と、ＯＰＣＵＡサーバ１３１及び１３２を備える冗長サーバセット１３０と、ＯＰＣＵＡサーバ１４１及び１４２と、を備える。ＯＰＣＵＡクライアント１１０は、ＬＢ１２０に接続されており、ＬＢ１２０は、冗長サーバセット１３０のＯＰＣＵＡサーバ１３１及び１３２に接続されている。

ＯＰＣＵＡシステム１は、クライアント−サーバ型に加えてＯＰＣＵＡパブリッシャー（Publisher）及びサブスクライバー（Subscriber）のメッセージ送受信型を規定する、ＯＰＣＵＡパブリッシャーサブスクライバー（Ｐｕｂ／Ｓｕｂ）通信モデルを適用することにより、プラットフォームから独立し、サービス中心のアーキテクチャを適用する。

Ｐｕｂ／Ｓｕｂ通信モデルには、パブリッシャー及びサブスクライバーという２つの役割がある。パブリッシャー及びサブスクライバーは、変数値及びイベントフィールドを示すデータセットをそれぞれ格納している。パブリッシャーは、ユーザデータグラムプロトコル（ＵＤＰ）を用いて、データセットを含むメッセージを一以上のサブスクライバーに送信し、サブスクライバーのそれぞれは、同一のメッセージを受信する。

一以上の実施形態において、パブリッシャーに格納されたデータセットの値が更新された場合、パブリッシャーは、更新された値を有するデータセットを、一以上のサブスクライバーに提供する。サブスクライバーは、更新された値を有するデータセットをパブリッシャーから受信したとき、更新された値を有するデータセットに基づいて、内部に格納されたデータセットを更新する。

ＯＰＣＵＡクライアント１１０は、ＯＰＣＵＡシステム１におけるクライアントコンピュータである。ＯＰＣＵＡクライアント１１０は、ＯＰＣＵＡサーバ１３１及び１３２にメッセージを送信するソフトウェアアプリケーションを有する。メッセージは、ＯＰＣＵＡクライアント１１０とＯＰＣＵＡサーバ１３１及び１３２との間で伝送される、所定のサービス要求又は応答を示すデータユニットであってよい。

ＬＢ１２０は、プロキシ、ヘルスチェック、及びＵＤＰ切換え機能を実行する。プロキシは、ＯＰＣＵＡクライアント１１０並びにＯＰＣＵＡサーバ１３１、１３２、１４１及び１４２へのＴＣＰ／ＩＰ接続を管理する。ＬＢ１２０は、ＯＰＣＵＡサーバであってよく、パブリッシャー又はサブスクライバーのいずれかであってよい。

冗長サーバセット１３０のＯＰＣＵＡサーバ１３１及び１３２は、一組の冗長サーバである。ＯＰＣＵＡシステム１は、一組又は複数組の冗長ＯＰＣＵＡサーバを含んでよい。これらの冗長ＯＰＣＵＡサーバにより、ＯＰＣＵＡシステム１は冗長モードを使用できるようになる。

一以上の実施形態において、冗長モードは、メッセージがＯＰＣＵＡサーバ１３１及び１３２の双方により受信される、ホットスタンバイモードであってよい。ホットスタンバイモードは、ミラーリング又はサーバミラーリングと称されうる。ホットスタンバイモードにおいて、ＯＰＣＵＡサーバ１３１及び１３２の一方は、アクティブサーバとして構成され、ＯＰＣＵＡサーバ１３１及び１３２の他方は、スタンバイサーバとして構成される。アクティブサーバは、メインサーバ又はマスターサーバと称され、スタンバイサーバは、マックアップサーバ又はミラーサーバと称されてよい。

一以上の実施形態において、ＯＰＣＵＡサーバ１３１及び１３２の双方は、パブリッシャー及びサブスクライバーの双方として機能してよい（つまり、パブリッシャー及びサブスクライバーの双方の機能を含む）。

次に、ＯＰＣＵＡサーバ１４１及び１４２について、一以上の実施形態において、ＯＰＣＵＡサーバ１４１はパブリッシャーであり、ＯＰＣＵＡサーバ１４２はサブスクライバーであってよく、その逆であってもよい。あるいは、ＯＰＣＵＡサーバ１４１及び１４２は、双方ともパブリッシャー又はサブスクライバーであってもよい。

次に、ＯＰＣＵＡクライアント１１０、ＬＢ１２０、ＯＰＣＵＡサーバ１３１、１３２、１４１及び１４２のハードウェア構成について説明する。

図２は、一以上の実施形態に係る、ＯＰＣＵＡクライアント１１０のハードウェアの概略図である。図２に示すように、ＯＰＣＵＡクライアント１１０は、プロセッサ（例えば中央処理装置（ＣＰＵ））１１０１、プロセッサ１１０１と通信するメモリ１１０２、ストレージ１１０３、送受信部１１０４、及びディスプレイ１１０５を少なくとも備える。プロセッサ１１０１は、メモリ１１０２に格納されたプログラムを実行する。ストレージ１１０３は、非一時的なコンピュータ可読の記憶媒体である。送受信部１１０４は、メッセージ（データ、信号）を送受信し、ローカルエリアネットワーク（ＬＡＮ）インタフェース、無線ＬＡＮインタフェース、又は、例えばロングタームエヴォリューション（ＬＴＥ）及びＮｅｗＲａｄｉｏ（ＮＲ）（５Ｇ）などのセルラーネットワークインタフェースの少なくともいずれかであってよい。ディスプレイ１１０５は、プロセッサ１１０１からの指示に基づいて情報を表示する。

図３に示すように、ディスプレイ１１０５は、ＯＰＣＵＡサーバのエンドポイントＵＲＬを指定するために使用される管理者設定を表示する。例えば、ＯＰＣＵＡクライアント１１０が冗長サーバセット１３０との通信を開始する前に、冗長サーバセット１３０のエンドポイントＵＲＬが、管理者設定において指定される。

図４は、一以上の実施形態に係る、ＬＢ１２０のハードウェアの概略図である。図４に示すように、ＬＢ１２０は、プロセッサ（例えばＣＰＵ）１２０１、メモリ１２０２、ストレージ１２０３、及び送受信部１２０４を少なくとも備える。プロセッサ１２０１は、メモリ１２０２に格納されたプログラムを実行する。ストレージ１２０３は、非一時的なコンピュータ可読の記憶媒体である。送受信部１２０４は、メッセージを送受信し、ＬＡＮインタフェース、無線ＬＡＮインタフェース、又は、例えばＬＴＥ及びＮＲ（５Ｇ）などのセルラーネットワークインタフェースの少なくともいずれかであってよい。ＬＢ１２０は、ディスプレイ１１０５を備えていてもよい。例えば、送受信部１２０４は、ＯＰＣＵＡクライアント１１０からデータ信号（例えばエンドポイントＵＲＬへの接続要求）を受信する。プロセッサ１２０１は、ＯＰＣＵＡクライアント１１０からの接続要求に基づき、ＯＰＣＵＡサーバ１３１への接続をプロキシする。

図５は、一以上の実施形態に係る、ＯＰＣＵＡサーバ１３１、１３２、１４１及び１４２のハードウェアの概略図である。図５に示すように、ＯＰＣＵＡサーバ１３１、１３２、１４１及び１４２のそれぞれは、プロセッサ１３０１（例えばＣＰＵ）、メモリ１３０２、ストレージ１３０３、及び送受信部１３０４を少なくとも備える。プロセッサ１３０１は、メモリ１３０２に格納されたプログラムを実行する。ストレージ１３０３は、非一時的なコンピュータ可読の記憶媒体である。送受信部１３０４は、メッセージを送受信し、ＬＡＮインタフェース、無線ＬＡＮインタフェース、又は、例えばＬＴＥ及びＮＲ（５Ｇ）などのセルラーネットワークインタフェースの少なくともいずれかであってよい。ＯＰＣＵＡサーバ１３１、１３２、１４１及び１４２のそれぞれは、ディスプレイ１１０５を備えていてもよい。

次に、ＯＰＣＵＡシステム１におけるプログラムの初期化後の一連の処理について説明する。具体的には、図６は、一以上の実施形態に係る、ＯＰＣＵＡシステム１における処理のシーケンス図である。

図６のステップＳ１０１において、冗長サーバセット１３０のエンドポイントＵＲＬが、ＯＰＣＵＡクライアント１１０において指定される。例えば、指定されたエンドポイントＵＲＬは、opc.tcp://192.168.1.150である。

ステップＳ１０２において、ＯＰＣＵＡクライアント１１０は、指定されたエンドポイントＵＲＬへの接続要求を、ＬＢ１２０に送信する。

ステップＳ１０３において、ＬＢ１２０は、指定されたエンドポイントＵＲＬへの接続を、ＯＰＣＵＡサーバ１３１にプロキシする。例えば、図７に示すように、ＬＢ１２０は、サーバ名及びサーバＵＲＬに関連付けられたエンドポイントＵＲＬを含むテーブルを備える。冗長サーバセット１３０のエンドポイントＵＲＬ「192.168.1.150」は、ＯＰＣＵＡサーバ１３１に関連付けられている（つまり、冗長サーバセット１３０において、ＯＰＣＵＡサーバ１３１はアクティブサーバとして構成され、ＯＰＣＵＡサーバ１３２はスタンバイ（バックアップ）サーバとして構成されている）。

ステップＳ１０４において、ＬＢ１２０は、ＯＰＣＵＡサーバ１３１に接続（例えばプロキシ接続）要求を送信する。

ステップＳ１０５において、ＯＰＣＵＡクライアント１１０とＯＰＣＵＡサーバ１３１との間で、ＴＣＰ／ＩＰ接続が確立される。

ステップＳ１０６において、ＯＰＣＵＡクライアント１１０は、冗長サーバセット１３０におけるデータセットを更新するために使用される設定値（ＳＶ）を、エンドポイントＵＲＬに送信する。データセットは、指定されたデータの値のリストであり、イベントフィールド及び変数を含む。

ステップＳ１０７において、ＬＢ１２０は、ＳＶをＯＰＣＵＡサーバ１３１に送信する。ＳＶは、冗長サーバセット１３０のエンドポイントＵＲＬに関連付けられている。

ステップＳ１０８において、ＯＰＣＵＡサーバ１３１は、ＳＶに基づいて値を算出する。

ステップＳ１０９において、パブリッシャー及びサブスクライバーの双方として機能するＯＰＣＵＡサーバ１３１は、算出した値を含むデータセットを提供する。

ステップＳ１１０において、サブスクライバーとして機能するＯＰＣＵＡサーバ１４２は、ＯＰＣＵＡサーバ１３１からデータセットを受信し、内部に格納されたデータセットの現在の値を、ＯＰＣＵＡサーバ１３１からのデータセットに含まれる算出された値に書き換える。

ステップＳ１１１において、パブリッシャー及びサブスクライバーの双方として機能するＯＰＣＵＡサーバ１３２は、ＯＰＣＵＡサーバ１３１からデータセットを受信し、内部に格納されたＳＶを、ＯＰＣＵＡサーバ１３１からのデータセットに含まれる算出された値に更新する。

ステップＳ１１２において、ＯＰＣＵＡサーバ１３２は、ＳＶに基づいて新たな値を算出し、データセットを用いて他のサーバに新たな値を提供することを試行する。しかしながら、ＬＢ１２０は、スタンバイ（バックアップ）サーバが他のサーバにデータセットを提供することを禁止するファイアウォールテーブルを備える。言い換えると、ＯＰＣＵＡサーバ１３２によるデータセットの発行は、ＬＢ１２０のファイアウォールにより阻止される。

次に、ＯＰＣＵＡシステム１におけるプログラムの初期化後の他の一連の処理について説明する。図８は、一以上の実施形態に係る、ＯＰＣＵＡシステム１におけるフェイルオーバーの処理のシーケンス図である。

図８に示すように、ステップＳ２０１において、ＬＢ１２０は、ハートビート信号（つまりヘルスチェック信号）をＯＰＣＵＡサーバ１３１に送信することにより、ＯＰＣＵＡサーバ１３１についてヘルスチェックを実行する。一以上の実施形態におけるここでの例では、ＯＰＣＵＡサーバ１３１はアクティブサーバとして機能し、ＯＰＣＵＡサーバ１３２は、スタンバイサーバとして機能する。

ステップＳ２０２において、ＯＰＣＵＡサーバ１３１は、ハートビート信号に応答して、確認応答信号をＬＢ１２０に送信する。ステップＳ２０２において、ＬＢ１２０がハートビート信号を送信した後、確認応答信号を受信していなければ、ＬＢ１２０は、ステップＳ２０４において、ＯＰＣＵＡサーバ１３１が応答していないと決定する（つまり、ＯＰＣＵＡサーバ１３１における障害と決定する）。

ＯＰＣＵＡサーバ１３１が応答していないと決定すると、ステップＳ２０５において、ＬＢ１２０は、冗長サーバセット１３０のエンドポイントＵＲＬを、ＯＰＣＵＡサーバ１３１からＯＰＣＵＡサーバ１３２に切り換える。

ステップＳ２０６において、ＬＢ１２０は、ＯＰＣＵＡサーバ１３２のデータセットの発行をＯＰＣＵＡサーバ１３２に許可するように、ファイアウォールルールを変更する。

ステップＳ２０７において、ＬＢ１２０は、ＯＰＣＵＡサーバ１３２に接続要求を送信する。

ステップＳ２０８において、ＯＰＣＵＡクライアント１１０とＯＰＣＵＡサーバ１３２との間で、ＴＣＰ／ＩＰ接続が確立される。

ステップＳ２０９において、ＯＰＣＵＡサーバ１３２は、他のサーバにデータセットを提供する。

ステップＳ２１０において、サブスクライバーとして機能するＯＰＣＵＡサーバ１４２は、ＯＰＣＵＡサーバ１３２のデータセットを受信し、ＯＰＣＵＡサーバ１４２のデータセットに内部に格納された現在の値を、ＯＰＣＵＡサーバ１３２から受信したデータセット内の値に書き換える。

従って、一以上の実施形態によれば、アクティブサーバとスタンバイサーバとがフェイルオーバー処理（つまり２つのサーバのうち１つが応答しないとき）により切り換えられ、切換え後の新たなアクティブサーバが、ＯＰＣＵＡシステム１の他のサブスクライバーにデータセットを提供する。さらに、切換え前のアクティブサーバは、切換え後は、他のサブスクライバーにデータセットを提供しない。一以上の実施形態のさらなる利点について、以下説明する。

一以上の実施形態によれば、ＯＰＣＵＡクライアントとＯＰＣＵＡサーバとの間の直接接続は、ＬＢを使用して提供される。これにより、ＯＰＣＵＡシステム１では、仮想サーバなどの仲介手段を用いる必要がなくなる。ＬＢは、接続の管理を行うが、ＯＰＣＵＡサーバのそれぞれに直接向かう接続の経路の決定も行う。例えば、ＯＰＣＵＡクライアントは、エンドポイントＵＲＬに接続され、ＯＰＣＵＡサーバのノード値を変更し、呼出／要求は、アクティブサーバで直接行われる。

その結果、仲介手段を用いた場合に発生する単一点障害が防止され得る。さらに、ＬＢは、ＯＰＣＵＡシステムの基盤に本格的な改変を加えることなく、容易にＯＰＣＵＡシステムに組み込むことができる。

一以上の実施形態において、上述のＵＤＰハートビートを用いた切換時間は、約１００から２００ｍｓであり、仮想サーバ（例えば仮想サーバ方式を実装する）により要求される３０秒のスイッチ時間よりも極めて速い。すなわち、一以上の実施形態は、フェイルオーバーの速度を短縮し、その結果、切換中におけるデータの喪失を減らすことができる。

仮想仲介サーバでは、全てのユースケースについて、各クライアントにカスタムインストールを行うことが必要とされる。適正数量の仮想クライアントが必要であり、各仮想クライアントの規模とサーバの数量に対して要求されるハードウェアが接続されることが必要である。その一方で、ＬＢを用いる一以上の実施形態に係る発明では、インストール及び実装の自由度が高く、より多くのサーバが接続された場合に規模の変更が容易である。例えば、冗長サーバに、より多くのＯＰＣＵＡサーバを追加することは、構成ファイルを変更するのと同程度に容易であり、初期実装の後に実行することができる。ウェブトラフィックに用いられるＬＢは、数百から数千の接続を円滑に処理するであろう。

最後に、一以上の実施形態において、複数のＯＰＣＵＡクライアントは、同一のＬＢを利用することができる。ＯＰＣＵＡクライアント及びＯＰＣＵＡサーバは、ＬＢと相互にやり取りするために追加のソフトウェア又は改変を必要としない。全てのシステム構成は、ＬＢにより直接もたらされ、ＬＢにより実装される。

図９は、一以上の実施形態に係るフローチャートである。このフローチャートは、図６を参照して上記説明した処理を反映している。

図９のステップＳ１００１において、ＯＰＣＵＡクライアント１１０は、冗長サーバセット１３０と通信するエンドポイントＵＲＬを指定する。冗長サーバセット１３０は、ＯＰＣＵＡサーバ１３１（以下「第１のＯＰＣＵＡサーバ」という）及びＯＰＣＵＡサーバ１３２（以下「第２のＯＰＣＵＡサーバ」という）を含む。第１及び第２のＯＰＣＵＡサーバは、それぞれアクティブサーバ及びスタンバイサーバである。

ステップＳ１００２において、ＯＰＣＵＡクライアント１１０は、エンドポイントＵＲＬに接続要求を送信する。

ステップＳ１００３において、冗長サーバセット１３０とＯＰＣＵＡクライアント１１０との間に接続されたＬＢ１２０は、第１のＯＰＣＵＡサーバへの接続をプロキシする。一以上の実施形態において、エンドポイントＵＲＬは、第１のＯＰＣＵＡサーバ及び第２のＯＰＣＵＡサーバのそれぞれのＵＲＬとは異なっていてよい。ＬＢ１２０が接続をプロキシした後、ＯＰＣＵＡクライアント１１０と第１のＯＰＣＵＡサーバとの間で、ＴＣＰ／ＩＰ接続が確立される。

Ｐｕｂ／Ｓｕｂ通信モデルでは、第１のＯＰＣＵＡサーバ及び第２のＯＰＣＵＡサーバは、それぞれパブリッシャー及び少なくとも１つのサブスクライバーである。第１及び第２のＯＰＣＵＡサーバは、それぞれ第１のデータセット及び第２のデータセットである。

ステップＳ１００４において、第１のＯＰＣＵＡサーバは、第１のデータセットを更新する。

ステップＳ１００５において、第１のＯＰＣＵＡサーバは、更新された第１のデータセットを、少なくとも１つのサブスクライバーに（つまり第２のＯＰＣＵＡサーバに）提供する。

ステップＳ１００６において、第２のＯＰＣＵＡサーバは、更新された第１のデータセットを第１のＯＰＣＵＡサーバから受信したとき、第２のデータセットを更新する。一以上の実施形態において、ＬＢ１２０のファイアウォールテーブルにより、第２のＯＰＣＵＡサーバが前記少なくとも１つのサブスクライバー以外の他の既存のサブスクライバーに第２のデータセットを提供することが阻止される。

図１０は、一以上の実施形態に係るフローチャートである。このフローチャートは、図８を参照して上記説明した処理を反映している。図１０のステップＳ２００１−２００３は、図９のステップＳ１００１−１００３と同一であるため、簡略化のためここでは説明を繰り返さない。

ステップＳ２００４において、第１のＯＰＣＵＡサーバ１３１の故障を検出すると、フェイルオーバー処理が実行され、第２のＯＰＣＵＡサーバをアクティブサーバとし、第１のＯＰＣＵＡサーバをスタンバイサーバとする切換えが行われる。切換え後、第２のＯＰＣＵＡサーバは、パブリッシャーとなる。

ステップＳ２００５において、第２のＯＰＣＵＡサーバは、前記少なくとも１つのサブスクライバー以外の他の既存のサブスクライバーに第２のデータセットを提供する。

ステップＳ２００６において、他の既存のサブスクライバーは、第２のＯＰＣＵＡサーバから第２のデータセットを受信したとき、データセットをそれぞれ更新する。一以上の実施形態において、フェイルオーバー処理の結果としての切換えの後、ＬＢ１２０のファイアウォールテーブルにより、第１のＯＰＣＵＡサーバがサブスクライバーに第１のデータセットを提供することが阻止される。

本開示につき、限られた数の実施形態に関して説明したが、当業者は、本開示を利用して、範囲を逸脱することなく、多様な他の実施形態が考案され得ることを理解できるであろう。従って、本発明の範囲は、添付された特許請求の範囲のみに限定されるものではない。

Claims

ＯＰＣＵＡを用いて処理を行うシステムであって、
第１のＯＰＣＵＡサーバ及び第２のＯＰＣＵＡサーバを備える冗長サーバセットと、
前記冗長サーバセットと通信するエンドポイントユニフォームリソースロケータ（ＵＲＬ）を指定するＯＰＣＵＡクライアントと、
前記冗長サーバセットと前記ＯＰＣＵＡクライアントとの間に接続された負荷分散装置（ＬＢ）と、
を備え、
前記ＯＰＣＵＡクライアントは、前記エンドポイントＵＲＬに接続要求を送信し、
前記第１のＯＰＣＵＡサーバは、アクティブサーバであり、
前記第２のＯＰＣＵＡサーバは、スタンバイサーバであり、
前記ＬＢは、前記第１のＯＰＣＵＡサーバへの接続をプロキシし、
前記エンドポイントＵＲＬは、前記第１のＯＰＣＵＡサーバ及び前記第２のＯＰＣＵＡサーバのそれぞれのＵＲＬとは異なり、
前記システムは、パブリッシャーがデータセットを含み、前記データセットを少なくとも１つのサブスクライバーに提供する、パブリッシャーサブスクライバー（Ｐｕｂ／Ｓｕｂ）通信モデルを適用し、
前記Ｐｕｂ／Ｓｕｂ通信モデルにおいて、前記第１のＯＰＣＵＡサーバ及び前記第２のＯＰＣＵＡサーバは、それぞれ前記パブリッシャー及び前記少なくとも１つのサブスクライバーであり、
前記第１のＯＰＣＵＡサーバは、第１のデータセットを含み、
前記第２のＯＰＣＵＡサーバは、第２のデータセットを含み、
前記第１のデータセットが更新されたとき、前記第１のＯＰＣＵＡサーバは、前記更新された第１のデータセットを前記少なくとも１つのサブスクライバーに提供し、
前記第２のＯＰＣＵＡサーバは、前記更新された第１のデータセットを受信したとき、前記第２のデータセットを更新し、
前記第２のＯＰＣＵＡサーバは、前記第２のデータセットを前記少なくとも１つのサブスクライバーに提供しない、
システム。
前記ＬＢが前記接続をプロキシした後、前記ＯＰＣＵＡクライアントと前記第１のＯＰＣＵＡサーバとの間でＴＣＰ／ＩＰ接続が確立される、請求項１に記載のシステム。
前記ＬＢは、前記第２のＯＰＣＵＡサーバが前記少なくとも１つのサブスクライバーに前記第２のデータセットを提供することを阻止するファイアウォールテーブルを備える、請求項１又は２に記載のシステム。
ＯＰＣＵＡを用いて処理を行うシステムであって、
第１のＯＰＣＵＡサーバ及び第２のＯＰＣＵＡサーバを備える冗長サーバセットと、
前記冗長サーバセットと通信するエンドポイントユニフォームリソースロケータ（ＵＲＬ）を指定するＯＰＣＵＡクライアントと、
前記冗長サーバセットと前記ＯＰＣＵＡクライアントとの間に接続された負荷分散装置（ＬＢ）と、
を備え、
前記ＯＰＣＵＡクライアントは、前記エンドポイントＵＲＬに接続要求を送信し、
前記第１のＯＰＣＵＡサーバは、アクティブサーバであり、
前記第２のＯＰＣＵＡサーバは、スタンバイサーバであり、
前記ＬＢは、前記第１のＯＰＣＵＡサーバへの接続をプロキシし、
前記エンドポイントＵＲＬは、前記第１のＯＰＣＵＡサーバ及び前記第２のＯＰＣＵＡサーバのそれぞれのＵＲＬとは異なり、
前記システムは、パブリッシャーがデータセットを含み、前記データセットを少なくとも１つのサブスクライバーに提供する、パブリッシャーサブスクライバー（Ｐｕｂ／Ｓｕｂ）通信モデルを適用し、
前記Ｐｕｂ／Ｓｕｂ通信モデルにおいて、前記第１のＯＰＣＵＡサーバ及び前記第２のＯＰＣＵＡサーバは、それぞれ前記パブリッシャー及び前記少なくとも１つのサブスクライバーであり、
前記第１のＯＰＣＵＡサーバは、第１のデータセットを含み、
前記第２のＯＰＣＵＡサーバは、第２のデータセットを含み、
フェイルオーバー処理において、前記アクティブサーバが、前記第１のＯＰＣＵＡサーバから前記第２のＯＰＣＵＡサーバに切り換えられ、
前記第２のＯＰＣＵＡサーバは、前記第２のデータセットを前記少なくとも１つのサブスクライバーに提供し、
前記スタンバイサーバが、前記第２のＯＰＣＵＡサーバから前記第１のＯＰＣＵＡサーバに切り換えられ、
前記フェイルオーバー処理の後、前記第２のＯＰＣＵＡサーバは、前記第２のデータセットを前記少なくとも１つのサブスクライバーに提供し、
前記第１のＯＰＣＵＡサーバは、前記第２のデータセットを受信したとき、前記第１のデータセットを更新し、
前記第１のＯＰＣＵＡサーバは、前記第１のデータセットを前記少なくとも１つのサブスクライバーに提供しない、
システム。
前記ＬＢは、前記第１のＯＰＣＵＡサーバが前記少なくとも１つのサブスクライバーに前記第１のデータセットを提供することを阻止するファイアウォールテーブルを備える、請求項４に記載のシステム。
ＯＰＣＵＡを用いた通信方法であって、
ＯＰＣＵＡクライアントにより、第１のＯＰＣＵＡサーバ及び第２のＯＰＣＵＡサーバを備える冗長サーバセットと通信するエンドポイントユニフォームリソースロケータ（ＵＲＬ）を指定するステップと、
前記ＯＰＣＵＡクライアントにより、前記エンドポイントＵＲＬに接続要求を送信するステップと、
前記冗長サーバセットと前記ＯＰＣＵＡクライアントとの間に接続された負荷分散装置（ＬＢ）により、前記第１のＯＰＣＵＡサーバへの接続をプロキシするステップと、
を含み、
前記第１のＯＰＣＵＡサーバは、アクティブサーバであり、
前記第２のＯＰＣＵＡサーバは、スタンバイサーバであり、
前記エンドポイントＵＲＬは、前記第１のＯＰＣＵＡサーバ及び前記第２のＯＰＣＵＡサーバのそれぞれのＵＲＬとは異なり、
パブリッシャーがデータセットを含み、前記データセットを少なくとも１つのサブスクライバーに提供する、パブリッシャーサブスクライバー（Ｐｕｂ／Ｓｕｂ）通信モデルを適用するステップ、をさらに含み、
前記Ｐｕｂ／Ｓｕｂ通信モデルにおいて、前記第１のＯＰＣＵＡサーバ及び前記第２のＯＰＣＵＡサーバは、それぞれ前記パブリッシャー及び前記少なくとも１つのサブスクライバーであり、
前記第１のＯＰＣＵＡサーバは、第１のデータセットを含み、
前記第２のＯＰＣＵＡサーバは、第２のデータセットを含み、
前記第１のＯＰＣＵＡサーバにより、前記第１のデータセットを更新するステップと、
前記第１のＯＰＣＵＡサーバにより、前記更新された第１のデータセットを前記少なくとも１つのサブスクライバーに提供するステップと、
前記第２のＯＰＣＵＡサーバにより、前記第２のＯＰＣＵＡサーバが前記更新された第１のデータセットを受信したとき、前記第２のデータセットを更新するステップと、
をさらに含み、
前記第２のＯＰＣＵＡサーバは、前記第２のデータセットを前記少なくとも１つのサブスクライバーに提供しない、
通信方法。
前記ＬＢが前記接続をプロキシした後、前記ＯＰＣＵＡクライアントと前記第１のＯＰＣＵＡサーバとの間でＴＣＰ／ＩＰ接続が確立される、請求項６に記載の通信方法。
前記ＬＢのファイアウォールテーブルにより、前記第２のＯＰＣＵＡサーバが前記少なくとも１つのサブスクライバーに前記第２のデータセットを提供することを阻止するステップをさらに含む、請求項６又は７に記載の通信方法。
ＯＰＣＵＡを用いた通信方法であって、
ＯＰＣＵＡクライアントにより、第１のＯＰＣＵＡサーバ及び第２のＯＰＣＵＡサーバを備える冗長サーバセットと通信するエンドポイントユニフォームリソースロケータ（ＵＲＬ）を指定するステップと、
前記ＯＰＣＵＡクライアントにより、前記エンドポイントＵＲＬに接続要求を送信するステップと、
前記冗長サーバセットと前記ＯＰＣＵＡクライアントとの間に接続された負荷分散装置（ＬＢ）により、前記第１のＯＰＣＵＡサーバへの接続をプロキシするステップと、
を含み、
前記第１のＯＰＣＵＡサーバは、アクティブサーバであり、
前記第２のＯＰＣＵＡサーバは、スタンバイサーバであり、
前記エンドポイントＵＲＬは、前記第１のＯＰＣＵＡサーバ及び前記第２のＯＰＣＵＡサーバのそれぞれのＵＲＬとは異なり、
パブリッシャーがデータセットを含み、前記データセットを少なくとも１つのサブスクライバーに提供する、パブリッシャーサブスクライバー（Ｐｕｂ／Ｓｕｂ）通信モデルを適用するステップ、をさらに含み、
前記Ｐｕｂ／Ｓｕｂ通信モデルにおいて、前記第１のＯＰＣＵＡサーバ及び前記第２のＯＰＣＵＡサーバは、それぞれ前記パブリッシャー及び前記少なくとも１つのサブスクライバーであり、
前記第１のＯＰＣＵＡサーバは、第１のデータセットを含み、
前記第２のＯＰＣＵＡサーバは、第２のデータセットを含み、
フェイルオーバー処理において、前記アクティブサーバを、前記第１のＯＰＣＵＡサーバから前記第２のＯＰＣＵＡサーバに切り換えるステップと、
前記第２のＯＰＣＵＡサーバにより、前記第２のデータセットを前記少なくとも１つのサブスクライバーに提供するステップと、
をさらに含み、
前記スタンバイサーバを、前記第２のＯＰＣＵＡサーバから前記第１のＯＰＣＵＡサーバに切り換えるステップと、
前記フェイルオーバー処理の後、前記第２のＯＰＣＵＡサーバにより、前記第２のデータセットを前記少なくとも１つのサブスクライバーに提供するステップと、
前記第１のＯＰＣＵＡサーバにより、前記第１のＯＰＣＵＡサーバが前記第２のデータセットを受信したとき、前記第１のデータセットを更新するステップと、
をさらに含み、
前記第１のＯＰＣＵＡサーバは、前記第１のデータセットを前記少なくとも１つのサブスクライバーに提供しない、
通信方法。
前記ＬＢのファイアウォールテーブルにより、前記第１のＯＰＣＵＡサーバが前記少なくとも１つのサブスクライバーに前記第１のデータセットを提供することを阻止するステップをさらに含む、請求項９に記載の通信方法。
ＯＰＣＵＡを用いて処理を行うシステムの負荷分散装置（ＬＢ）であって、
エンドポイントユニフォームリソースロケータ（ＵＲＬ）への接続要求をＯＰＣＵＡクライアントから受信する送受信部と、
前記送受信部に接続されたプロセッサと、
を備え、
前記ＬＢは、冗長サーバセットと前記ＯＰＣＵＡクライアントとの間に接続されており、
前記冗長サーバセットは、第１のＯＰＣＵＡサーバ及び第２のＯＰＣＵＡサーバを備え、
前記エンドポイントＵＲＬは、前記冗長サーバセットと通信するＯＰＣＵＡクライアントにより指定され、
前記プロセッサは、前記要求に基づいて前記第１のＯＰＣＵＡサーバへの接続をプロキシし、
前記第１のＯＰＣＵＡサーバは、アクティブサーバであり、
前記第２のＯＰＣＵＡサーバは、スタンバイサーバであり、
前記エンドポイントＵＲＬは、前記第１のＯＰＣＵＡサーバ及び前記第２のＯＰＣＵＡサーバのそれぞれのＵＲＬとは異なり、
前記システムは、パブリッシャーがデータセットを含み、前記データセットを少なくとも１つのサブスクライバーに提供する、パブリッシャーサブスクライバー（Ｐｕｂ／Ｓｕｂ）通信モデルを適用し、
前記Ｐｕｂ／Ｓｕｂ通信モデルにおいて、前記第１のＯＰＣＵＡサーバ及び前記第２のＯＰＣＵＡサーバは、それぞれ前記パブリッシャー及び前記少なくとも１つのサブスクライバーであり、
前記第１のＯＰＣＵＡサーバは、第１のデータセットを含み、
前記第２のＯＰＣＵＡサーバは、第２のデータセットを含み、
前記第１のデータセットが更新されたとき、前記第１のＯＰＣＵＡサーバは、前記更新された第１のデータセットを前記少なくとも１つのサブスクライバーに提供し、
前記第２のＯＰＣＵＡサーバは、前記更新された第１のデータセットを受信したとき、前記第２のデータセットを更新し、
前記第２のＯＰＣＵＡサーバは、前記第２のデータセットを前記少なくとも１つのサブスクライバーに提供しない、
ＬＢ。
前記プロセッサが前記接続をプロキシした後、前記ＯＰＣＵＡクライアントと前記第１のＯＰＣＵＡサーバとの間でＴＣＰ／ＩＰ接続が確立される、請求項１１に記載のＬＢ。
ＯＰＣＵＡを用いて処理を行うシステムの負荷分散装置（ＬＢ）であって、
エンドポイントユニフォームリソースロケータ（ＵＲＬ）への接続要求をＯＰＣＵＡクライアントから受信する送受信部と、
前記送受信部に接続されたプロセッサと、
を備え、
前記ＬＢは、冗長サーバセットと前記ＯＰＣＵＡクライアントとの間に接続されており、
前記冗長サーバセットは、第１のＯＰＣＵＡサーバ及び第２のＯＰＣＵＡサーバを備え、
前記エンドポイントＵＲＬは、前記冗長サーバセットと通信するＯＰＣＵＡクライアントにより指定され、
前記プロセッサは、前記要求に基づいて前記第１のＯＰＣＵＡサーバへの接続をプロキシし、
前記第１のＯＰＣＵＡサーバは、アクティブサーバであり、
前記第２のＯＰＣＵＡサーバは、スタンバイサーバであり、
前記エンドポイントＵＲＬは、前記第１のＯＰＣＵＡサーバ及び前記第２のＯＰＣＵＡサーバのそれぞれのＵＲＬとは異なり、
前記システムは、パブリッシャーがデータセットを含み、前記データセットを少なくとも１つのサブスクライバーに提供する、パブリッシャーサブスクライバー（Ｐｕｂ／Ｓｕｂ）通信モデルを適用し、
前記Ｐｕｂ／Ｓｕｂ通信モデルにおいて、前記第１のＯＰＣＵＡサーバ及び前記第２のＯＰＣＵＡサーバは、それぞれ前記パブリッシャー及び前記少なくとも１つのサブスクライバーであり、
前記第１のＯＰＣＵＡサーバは、第１のデータセットを含み、
前記第２のＯＰＣＵＡサーバは、第２のデータセットを含み、
フェイルオーバー処理において、前記アクティブサーバが、前記第１のＯＰＣＵＡサーバから前記第２のＯＰＣＵＡサーバに切り換えられ、
前記第２のＯＰＣＵＡサーバは、前記第２のデータセットを前記少なくとも１つのサブスクライバーに提供し、
前記スタンバイサーバが、前記第２のＯＰＣＵＡサーバから前記第１のＯＰＣＵＡサーバに切り換えられ、
前記フェイルオーバー処理の後、前記第２のＯＰＣＵＡサーバは、前記第２のデータセットを前記少なくとも１つのサブスクライバーに提供し、
前記第１のＯＰＣＵＡサーバは、前記第２のデータセットを受信したとき、前記第１のデータセットを更新し、
前記第１のＯＰＣＵＡサーバは、前記第１のデータセットを前記少なくとも１つのサブスクライバーに提供しない、
ＬＢ。