(57)【要約】  コンピュータ情報システムが、少なくとも２つのサービスクラスタと動的障害回復ノードとを含む。各サービスクラスタは、少なくとも２つのサービスノードを含む。各サービスノードは、複数のサービスカテゴリに対応するサービス要求を処理するサービス処理ロジックを含み、サービスクラスタに関連付けられた特定のサービスカテゴリのサービス要求だけを処理することになる。動的障害回復ノードは、サービスクラスタに関連付けられた特定のサービスカテゴリに基づいて各サービスクラスタのためのそれぞれの動的障害回復ポリシーを設定し、サービスクラスタの動作状態を監視することになる。サービスクラスタが正常に動作する場合、動的障害回復ノードは、サービスクラスタに関連付けられた特定のサービスカテゴリのサービス要求を、該サービスクラスタにスケジュールする。サービスクラスタが異常に動作する場合、動的障害回復ノードは、動的障害回復ポリシーに従ってサービス要求の処理を動的に調整する。
2015526815.tif 000002
【特許請求の範囲】
【請求項１】
各サービスクラスタが少なくとも２つのサービスノードを含む、少なくとも２つのサービスクラスタであって、各サービスノードは、複数のサービスカテゴリに対応するサービス要求を処理するサービス処理ロジックを含み、サービスクラスタに関連付けられた特定のサービスカテゴリのサービス要求だけを処理するように構成される、少なくとも２つのサービスクラスタと、
サービスクラスタに関連付けられた特定のサービスカテゴリに基づいて各サービスクラスタのためのそれぞれの動的障害回復ポリシーを設定し、サービスクラスタの動作状態を監視するように構成された動的障害回復ノードと、
を含み、
サービスクラスタが正常に動作する場合、前記動的障害回復ノードは、サービスクラスタに関連付けられた特定のサービスカテゴリのサービス要求を該サービスクラスタにスケジュールするように構成され、サービスクラスタが異常に動作する場合、前記動的障害回復ノードは、サービス要求の処理を前記動的障害回復ポリシーに従って動的に調整するように構成される、
コンピュータ情報システム。
【請求項２】
プライマリ動的障害回復ノードとスタンバイ動的障害回復ノードと、をさらに含み、前記プライマリ動的障害回復ノードと前記スタンバイ動的障害回復ノードとは、互いをバックアップし、互いの間で障害回復切り替えを実行するように構成される、請求項１に記載のコンピュータ情報システム。
【請求項３】
中核的ユーザ体験サービスクラスタとユーザ体験低下可能サービスクラスタとユーザ体験無視可能サービスクラスタと、をさらに含み、前記動的障害回復ノードは、下記の、
前記中核的ユーザ体験サービスクラスタが異常に動作する場合、サービス要求の少なくともサブセットを前記ユーザ体験低下可能サービスクラスタと前記ユーザ体験無視可能サービスクラスタとのサービスノードの間で均等に分散する動作と、
前記ユーザ体験低下可能サービスクラスタが異常に動作する場合、サービス要求の少なくともサブセットを前記ユーザ体験無視可能サービスクラスタのサービスノードの間で均等に分散する動作と、
前記ユーザ体験無視可能サービスクラスタが異常に動作する場合、サービス要求の少なくともサブセットを落とすように前記ユーザ体験無視可能サービスクラスタの動的障害回復ポリシーを更新する動作と、
を実行するように構成される、請求項１に記載のコンピュータ情報システム。
【請求項４】
前記動的障害回復ノードは、前記の動的調整を実行する前に当該コンピュータ情報システムにおける３つのサービスクラスタにおけるロードバランスを確認するようにさらに構成される、請求項３に記載のコンピュータ情報システム。
【請求項５】
前記中核的ユーザ体験サービスクラスタが異常に動作する場合、前記動的障害回復ノードは、
前記ユーザ体験低下可能サービスクラスタ及び前記ユーザ体験無視可能サービスクラスタがサービス要求を扱う能力があるかを判定し、
そうでない場合、前記ユーザ体験無視可能サービスクラスタがサービス要求を扱う十分な能力を有するまで前記ユーザ体験無視可能サービスクラスタの動的障害回復ポリシーを更新し、
なおもそうでない場合、前記ユーザ体験低下可能サービスクラスタがサービス要求を扱う十分な能力を有するまで前記ユーザ体験低下可能サービスクラスタの動的障害回復ポリシーを更新する、
ようにさらに構成される、請求項３に記載のコンピュータ情報システム。
【請求項６】
前記ユーザ体験低下可能サービスクラスタが異常に動作する場合、前記動的障害回復ノードは、
前記ユーザ体験無視可能サービスクラスタがサービス要求を扱う十分な能力を有するかを判定し、
そうでない場合、当該コンピュータ情報システムがピーク動作期間内であるかを判定し、
当該コンピュータ情報システムが前記ピーク動作期間内でない場合、サービス要求を前記ユーザ体験無視可能サービスクラスタと前記中核的ユーザ体験サービスクラスタとのサービスノードの間で均等に分散し、
当該コンピュータ情報システムが前記ピーク動作期間内である場合、当該コンピュータ情報システムが前記ユーザ体験低下可能サービスクラスタに向けられたサービス要求を扱う十分な能力を有するまで、前記ユーザ体験無視可能サービスクラスタに向けられたサービス要求の少なくともサブセットを落とす、
ようにさらに構成される、請求項３に記載のコンピュータ情報システム。
【請求項７】
前記３つのサービスクラスタの各々は、そのロードバランスを第１の所定時間間隔において前記動的障害回復ノードに報告するように構成され、前記動的障害回復ノードは、前記３つのサービスクラスタの各々の更新された動的障害回復ポリシーを第２の所定時間間隔において対応クライアントに報告するように構成される、請求項３に記載のコンピュータ情報システム。
【請求項８】
複数のサービスノードを含むコンピュータ情報システムによって実施される動的障害回復方法であって、
前記複数のサービスノードを少なくとも２つのサービスクラスタと動的障害回復ノードとに分けるステップであり、各サービスクラスタは少なくとも２つのサービスノードを含む、ステップと、
各サービスクラスタについて、
複数のサービスカテゴリに対応するサービス要求を処理するサービス処理ロジックを各サービスノードにインストールし、サービスクラスタに関連付けられた特定のサービスカテゴリのサービス要求だけを処理するようにサービスノードを構成するステップと、
前記動的障害回復ノードに、サービスクラスタに関連付けられた特定のサービスカテゴリに基づいてサービスクラスタのための動的障害回復ポリシーを設定させ、サービスクラスタの動作状態を監視させるステップと、
サービスクラスタが正常に動作する場合、サービスクラスタに関連付けられた特定のサービスカテゴリのサービス要求を該サービスクラスタ内のサービスノードにスケジュールするステップと、
サービスクラスタが異常に動作する場合、サービス要求の処理を前記動的障害回復ポリシーに従って動的に調整するステップと、
を含む方法。
【請求項９】
前記複数のサービスノードは、３つのサービスクラスタ、中核的ユーザ体験サービスクラスタとユーザ体験低下可能サービスクラスタとユーザ体験無視可能サービスクラスタとに分けられ、サービス要求の処理の前記の動的調整は、
前記中核的ユーザ体験サービスクラスタが異常に動作する場合、前記動的障害回復ノードに、サービス要求の少なくともサブセットを前記ユーザ体験低下可能サービスクラスタと前記ユーザ体験無視可能サービスクラスタとのサービスノードの間で均等に分散させるステップと、
前記ユーザ体験低下可能サービスクラスタが異常に動作する場合、前記動的障害回復ノードに、サービス要求の少なくともサブセットを前記ユーザ体験無視可能サービスクラスタのサービスノードの間で均等に分散させるステップと、
前記ユーザ体験無視可能サービスクラスタが異常に動作する場合、前記動的障害回復ノードに、サービス要求の少なくともサブセットを落とすように前記ユーザ体験無視可能サービスクラスタの動的障害回復ポリシーを更新させるステップと、
をさらに含む、請求項８に記載の方法。
【請求項１０】
前記動的障害回復ノードは、前記の動的調整を実行する前に前記コンピュータ情報システムにおける３つのサービスクラスタにおけるロードバランスを確認するように構成される、請求項９に記載の方法。
【請求項１１】
前記動的障害回復ノードに、サービス要求の少なくともサブセットを前記ユーザ体験低下可能サービスクラスタと前記ユーザ体験無視可能サービスクラスタとのサービスノードの間で均等に分散させるステップは、
前記ユーザ体験低下可能サービスクラスタ及び前記ユーザ体験無視可能サービスクラスタがサービス要求を扱う能力があるかを判定するステップと、
そうでない場合、前記ユーザ体験無視可能サービスクラスタがサービス要求を扱う十分な能力を有するまで前記ユーザ体験無視可能サービスクラスタの動的障害回復ポリシーを更新するステップと、
なおもそうでない場合、前記ユーザ体験低下可能サービスクラスタがサービス要求を扱う十分な能力を有するまで前記ユーザ体験低下可能サービスクラスタの動的障害回復ポリシーを更新するステップと、
をさらに含む、請求項９に記載の方法。
【請求項１２】
前記動的障害回復ノードに、サービス要求の少なくともサブセットを前記ユーザ体験無視可能サービスクラスタのサービスノードの間で均等に分散させるステップは、
前記ユーザ体験無視可能サービスクラスタがサービス要求を扱う十分な能力を有するかを判定するステップと、
そうでない場合、前記コンピュータ情報システムがピーク動作期間内であるかを判定するステップと、
前記コンピュータ情報システムが前記ピーク動作期間内でない場合、前記動的障害回復ノードに、サービス要求を前記ユーザ体験無視可能サービスクラスタと前記中核的ユーザ体験サービスクラスタとのサービスノードの間で均等に分散させるステップと、
前記コンピュータ情報システムが前記ピーク動作期間内である場合、前記動的障害回復ノードに、前記コンピュータ情報システムが前記ユーザ体験低下可能サービスクラスタに向けられたサービス要求を扱う十分な能力を有するまで、前記ユーザ体験無視可能サービスクラスタに向けられたサービス要求の少なくともサブセットを落とさせるステップと、
をさらに含む、請求項９に記載の方法。
【請求項１３】
前記３つのサービスクラスタの各々は、そのロードバランスを第１の所定時間間隔において前記動的障害回復ノードに報告するように構成され、前記動的障害回復ノードは、前記３つのサービスクラスタの各々の更新された動的障害回復ポリシーを第２の所定時間間隔において対応クライアントに報告するように構成される、請求項９に記載の方法。
【請求項１４】
複数のサービスノードを含むコンピュータ情報システムに関連して使用される非一時的コンピュータ可読媒体であって、当該非一時的コンピュータ可読媒体は前記コンピュータ情報システムにより実行される１又は複数のプログラムを記憶し、前記１又は複数のプログラムは、
前記複数のサービスノードを少なくとも２つのサービスクラスタと動的障害回復ノードとに分ける命令であり、各サービスクラスタは少なくとも２つのサービスノードを含む、命令と、
各サービスクラスタについて、
複数のサービスカテゴリに対応するサービス要求を処理するサービス処理ロジックを各サービスノードにインストールし、サービスクラスタに関連付けられた特定のサービスカテゴリのサービス要求だけを処理するようにサービスノードを構成する命令と、
前記動的障害回復ノードに、サービスクラスタに関連付けられた特定のサービスカテゴリに基づいてサービスクラスタのための動的障害回復ポリシーを設定させ、サービスクラスタの動作状態を監視させる命令と、
サービスクラスタが正常に動作する場合、サービスクラスタに関連付けられた特定のサービスカテゴリのサービス要求を該サービスクラスタ内のサービスノードにスケジュールする命令と、
サービスクラスタが異常に動作する場合、サービス要求の処理を前記動的障害回復ポリシーに従って動的に調整する命令と、
を含む、非一時的コンピュータ可読媒体。
【請求項１５】
前記複数のサービスノードは、３つのサービスクラスタ、中核的ユーザ体験サービスクラスタとユーザ体験低下可能サービスクラスタとユーザ体験無視可能サービスクラスタとに分けられ、サービス要求の処理の前記の動的調整は、
前記中核的ユーザ体験サービスクラスタが異常に動作する場合、前記動的障害回復ノードに、サービス要求の少なくともサブセットを前記ユーザ体験低下可能サービスクラスタと前記ユーザ体験無視可能サービスクラスタとのサービスノードの間で均等に分散させる命令と、
前記ユーザ体験低下可能サービスクラスタが異常に動作する場合、前記動的障害回復ノードに、サービス要求の少なくともサブセットを前記ユーザ体験無視可能サービスクラスタのサービスノードの間で均等に分散させる命令と、
前記ユーザ体験無視可能サービスクラスタが異常に動作する場合、前記動的障害回復ノードに、サービス要求の少なくともサブセットを落とすように前記ユーザ体験無視可能サービスクラスタの動的障害回復ポリシーを更新させる命令と、
をさらに含む、請求項１４に記載の非一時的コンピュータ可読媒体。
【請求項１６】
前記動的障害回復ノードは、前記の動的調整を実行する前に前記コンピュータ情報システムにおける３つのサービスクラスタにおけるロードバランスを確認するように構成される、請求項１５に記載の非一時的コンピュータ可読媒体。
【請求項１７】
前記動的障害回復ノードに、サービス要求の少なくともサブセットを前記ユーザ体験低下可能サービスクラスタと前記ユーザ体験無視可能サービスクラスタとのサービスノードの間で均等に分散させる命令は、
前記ユーザ体験低下可能サービスクラスタ及び前記ユーザ体験無視可能サービスクラスタがサービス要求を扱う能力があるかを判定する命令と、
そうでない場合、前記ユーザ体験無視可能サービスクラスタがサービス要求を扱う十分な能力を有するまで前記ユーザ体験無視可能サービスクラスタの動的障害回復ポリシーを更新する命令と、
なおもそうでない場合、前記ユーザ体験低下可能サービスクラスタがサービス要求を扱う十分な能力を有するまで前記ユーザ体験低下可能サービスクラスタの動的障害回復ポリシーを更新する命令と、
をさらに含む、請求項１５に記載の非一時的コンピュータ可読媒体。
【請求項１８】
前記動的障害回復ノードに、サービス要求の少なくともサブセットを前記ユーザ体験無視可能サービスクラスタのサービスノードの間で均等に分散させる命令は、
前記ユーザ体験無視可能サービスクラスタがサービス要求を扱う十分な能力を有するかを判定する命令と、
そうでない場合、前記コンピュータ情報システムがピーク動作期間内であるかを判定する命令と、
前記コンピュータ情報システムが前記ピーク動作期間内でない場合、前記動的障害回復ノードに、サービス要求を前記ユーザ体験無視可能サービスクラスタと前記中核的ユーザ体験サービスクラスタとのサービスノードの間で均等に分散させる命令と、
前記コンピュータ情報システムが前記ピーク動作期間内である場合、前記動的障害回復ノードに、前記コンピュータ情報システムが前記ユーザ体験低下可能サービスクラスタに向けられたサービス要求を扱う十分な能力を有するまで、前記ユーザ体験無視可能サービスクラスタに向けられたサービス要求の少なくともサブセットを落とさせる命令と、
をさらに含む、請求項１５に記載の非一時的コンピュータ可読媒体。
【請求項１９】
前記３つのサービスクラスタの各々は、そのロードバランスを第１の所定時間間隔において前記動的障害回復ノードに報告するように構成され、前記動的障害回復ノードは、前記３つのサービスクラスタの各々の更新された動的障害回復ポリシーを第２の所定時間間隔において対応クライアントに報告するように構成される、請求項１５に記載の非一時的コンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、コンピュータ情報処理の技術分野に関し、具体的には、コンピュータ情報システムとその動的障害回復（dynamic  disaster  recovery）方法とに関する。
【背景技術】
【０００２】
コンピュータ情報システムにおいて、情報サービスの機密性及び安定性を保証するためには、同じ機能を有する２以上のサービス処理システムが確立される必要があり、機能的な障害回復が２以上のサービス処理システム間で実施されることがある。すなわち、１つのサービス処理システムにおいて問題が発生したとき、別のサービス処理システムが使用されてサービスを外部に提供することができ、したがって、外部向けのサービスの機密性及び安定性を保証することができる。障害回復はシステム高可用性テクノロジーの重要なコンポーネントであり、外部環境の影響又はシステム上の緊急事態が前もって考慮される必要があり、したがって、障害が発生したときにシステムがサービス又はデータ損失をもたらすという不能が回避される。いわゆる障害は、正常なサービスを提供することを不可能にする事象、例えば、マシンハードウェア故障、ネットワーク故障、プログラムクラッシュ、及び緊急事態により引き起こされる過負荷などを指す。
【０００３】
現在、上記産業において、障害回復解決策は、コンピュータシステムの組成及びサービスアーキテクチャにおいて一般に実施される。
【０００４】
図１は、先行技術におけるインターネットサービスシステムのアーキテクチャの概略図である。図１を参照すると、インターネットサービスシステムは、コンピュータ情報システムの特定のアプリケーション領域であり、このアーキテクチャにおいて、すべてのサービスノードはピアである。例えば、図１には３つのピアサービスノード１０１、１０２及び１０３が存在し、サービスノードの各々はすべてのサービスの処理ロジックを外部に同時に提供し（サービスカテゴリは、分類されたクラスＡ、Ｂ及びＣであると仮定される）、これらのピアサービスノードがサービスクラスタを形成する。図１におけるシステムアーキテクチャは、多くのウェブサイトによって現在採用されており、その障害回復原理は、クライアントがあるカテゴリのサービス要求を開始した後、このサービス要求がシステムのトランスミッションコントロールプロトコル（ＴＣＰ）レイヤ上でロードバランシングシステムを通じてサービスクラスタの中のあるサービスノードに無作為に割り当てられ、このサービスノードが上記サービス要求に応答するというものである。障害事象、例えばハードウェア故障が、あるサービスノードにおいて発生したとき、サービス要求は、応答のために他の正常動作サービスノードに割り当てられることになる。
【０００５】
図２は、先行技術におけるインターネットサービスシステムの別のアーキテクチャの概略図である。図２を参照すると、このアーキテクチャにおいて、３つのサービスクラスタがそのサービスカテゴリに従って分類されており、各サービスクラスタの中のサービスノードのすべてが、それぞれの固定カテゴリのサービスだけを提供し、それぞれのサービスクラスタ内のサービスノードは、ピアである。例えば、図２において、サービスクラスタ２０１はクラスＡサービスを提供し、サービスクラスタ２０２はクラスＢサービスを提供し、サービスクラスタ２０３はクラスＣサービスを提供する。サービスクラスタ２０１を例にとると、その内部のサービスノード２１１、２１２及び２１３の各々は、クラスＡサービスのための処理ロジックだけを有し、サービスの各カテゴリに対応するサービスクラスタのアドレスが、クライアントに設定される。クライアントがクラスＡサービスのサービス要求を開始した後、クラスＡサービス要求がサービスクラスタ２０１に送信され、それから、クラスＡサービス要求は、ＴＣＰレイヤ上のロードバランシングシステムを通じてサービスクラスタ２０１の中のあるサービスノードに無作為に割り当てられ、このサービスノードが上記サービス要求に応答する。障害事象、例えばハードウェア故障が、サービスクラスタ２０１の中のサービスノードにおいて発生したとき、上記クラスＡサービス要求は、応答のために、サービスクラスタ２０１内の他の正常動作サービスノードに割り当てられる。現在、図２におけるシステムアーキテクチャは、多くのインターネットゲームサービスシステムによって一般に採用されている。
【０００６】
しかしながら、前述の先行技術は、下記の技術的な課題、すなわち、コンピュータ情報システム全体がロバスト性において不十分であることを有する。例えば、図１に例示されるアーキテクチャにおいて、サービスクラスタの中の故障サービスノードが一定数に到達した場合、システムの実際の負荷が、正常動作サービスノードによって生み出され得る負荷より大きくなり、システムは過負荷を掛けられ、それゆえに全体的に利用できなくなる。図２に例示されるアーキテクチャにおいて、異なるカテゴリのサービスノードが異なるサービスクラスタによって別個に処理されるが、図１に例示されるアーキテクチャにおけるものと同様の不十分なロバスト性の課題が、このサービスクラスタの各々にも存在する。すなわち、サービスクラスタの中の故障サービスノードが一定数に到達した場合、サービスクラスタの実際の負荷が正常動作サービスノードによって生み出され得る負荷より大きくなり、サービスクラスタは過負荷を掛けられ、それゆえに全体的に利用できなくなり、したがって、利用できないサービスクラスタに対応するそれぞれのサービスカテゴリのサービスを、外部に提供することができない。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上記を考慮して、本発明の目的は、コンピュータ情報システムのロバスト性を改良するように、コンピュータ情報システム及びその動的障害回復方法を提供することである。
【課題を解決するための手段】
【０００８】
本発明の技術的な解決策は、下記のとおり実施される。
【０００９】
いくつかの実施形態に従い、コンピュータ情報システムが、各サービスクラスタが少なくとも２つのサービスノードを含む、少なくとも２つのサービスクラスタであって、各サービスノードは、複数のサービスカテゴリに対応するサービス要求を処理するサービス処理ロジックを含み、サービスクラスタに関連付けられた特定のサービスカテゴリのサービス要求だけを処理するように構成される、少なくとも２つのサービスクラスタと、サービスクラスタに関連付けられた特定のサービスカテゴリに基づいて各サービスクラスタのためのそれぞれの動的障害回復ポリシーを設定し、サービスクラスタの動作状態を監視するように構成された動的障害回復ノードと、を含み、サービスクラスタが正常に動作する場合、上記動的障害回復ノードは、サービスクラスタに関連付けられた特定のサービスカテゴリのサービス要求を該サービスクラスタにスケジュールするように構成され、サービスクラスタが異常に動作する場合、上記動的障害回復ノードは、サービス要求の処理を上記動的障害回復ポリシーに従って動的に調整するように構成される。
【００１０】
いくつかの実施形態に従い、複数のサービスノードを含むコンピュータ情報システムによって実施される動的障害回復方法が、上記複数のサービスノードを少なくとも２つのサービスクラスタと動的障害回復ノードとに分けるステップであり、各サービスクラスタは少なくとも２つのサービスノードを含む、ステップと、各サービスクラスタについて、複数のサービスカテゴリに対応するサービス要求を処理するサービス処理ロジックを各サービスノードにインストールし、サービスクラスタに関連付けられた特定のサービスカテゴリのサービス要求だけを処理するようにサービスノードを構成するステップと、上記動的障害回復ノードに、サービスクラスタに関連付けられた特定のサービスカテゴリに基づいてサービスクラスタのための動的障害回復ポリシーを設定させ、サービスクラスタの動作状態を監視させるステップと、サービスクラスタが正常に動作する場合、サービスクラスタに関連付けられた特定のサービスカテゴリのサービス要求を該サービスクラスタ内のサービスノードにスケジュールするステップと、サービスクラスタが異常に動作する場合、サービス要求の処理を上記動的障害回復ポリシーに従って動的に調整するステップと、を含む。
【００１１】
いくつかの実施形態に従い、非一時的コンピュータ可読媒体が、複数のサービスノードを含むコンピュータ情報システムに関連して使用される。当該非一時的コンピュータ可読媒体は、上記コンピュータ情報システムにより実行される１又は複数のプログラムを記憶し、上記１又は複数のプログラムは、上記複数のサービスノードを少なくとも２つのサービスクラスタと動的障害回復ノードとに分ける命令であり、各サービスクラスタは少なくとも２つのサービスノードを含む、命令と、各サービスクラスタについて、複数のサービスカテゴリに対応するサービス要求を処理するサービス処理ロジックを各サービスノードにインストールし、サービスクラスタに関連付けられた特定のサービスカテゴリのサービス要求だけを処理するようにサービスノードを構成する命令と、上記動的障害回復ノードに、サービスクラスタに関連付けられた特定のサービスカテゴリに基づいてサービスクラスタのための動的障害回復ポリシーを設定させ、サービスクラスタの動作状態を監視させる命令と、サービスクラスタが正常に動作する場合、サービスクラスタに関連付けられた特定のサービスカテゴリのサービス要求を該サービスクラスタ内のサービスノードにスケジュールする命令と、サービスクラスタが異常に動作する場合、サービス要求の処理を上記動的障害回復ポリシーに従って動的に調整する命令と、を含む。
【００１２】
先行技術と比較すると、本発明においては、２つ以上のサービスクラスタがサービスカテゴリに従って分類され、２つ以上のサービスノードが各サービスクラスタに設定される。サービスノードはすべて、ピアノードである。すなわち、サービスノードはすべて、システムにおけるすべてのサービスカテゴリのサービス処理ロジックを備える必要がある。その一方で、各サービスクラスタの動的障害回復ポリシーが、設定される。サービスクラスタのすべてが正常に動作している場合、それぞれのサービスカテゴリのサービス要求は、応答処理のために、それぞれのサービスカテゴリに応答するように固定されたサービスクラスタに対してスケジュールされる。サービスクラスタのうち１つが異常に動作している場合、そのサービスクラスタの動的障害回復ポリシーに従って、対応サービスカテゴリのサービス要求のための応答サービスクラスタ及び／又は応答モードに対して、動的調整が行われる。このようにして、コンピュータ情報システム全体におけるすべてのサービスノードはピアであり、サービスクラスタの各々の動作状態に従って、サービス要求に対する対応サービスクラスタの応答モードは動的に調整することができる。サービスクラスタのうち１つの中の故障サービスノードが規定数に到達し、外部向けのサービスが提供できないとしても、サービスクラスタが相応に応答すべきサービス要求は他の正常動作サービスクラスタに転送されることもでき、したがって、コンピュータ情報システム全体によって外部に提供されるサービスは容易には中断されず、これにより、コンピュータ情報システムのロバスト性が改良される。
【図面の簡単な説明】
【００１３】
さらなる理解のために、下記の詳細な説明を添付の図面と共に参照すべきである。同様の参照番号は、図面にわたって対応部分を示す。
【図１】先行技術におけるインターネットサービスシステムのアーキテクチャの概略図である。
【図２】先行技術におけるインターネットサービスシステムの別のアーキテクチャの概略図である。
【図３】本発明のいくつかの実施形態に従うコンピュータ情報システムのための動的障害回復方法のフローチャートである。
【図４】本発明のいくつかの実施形態に従うコンピュータ情報システムのシステムアーキテクチャの概略図である。
【図５】本発明のいくつかの実施形態に従うコンピュータ情報システムの別のシステムアーキテクチャの概略図である。
【図６】本発明のいくつかの実施形態に従うサービスクラスタの中のサービスノードを例示するブロック図である。
【図７】本出願のいくつかの実施形態に従う動的障害回復ノードを例示するブロック図である。
【図８】本出願のいくつかの実施形態に従うクライアントを例示するブロック図である。
【発明を実施するための形態】
【００１４】
次に、様々な実施例に対して詳細に参照が行われ、その例が添付図面に例示される。下記の詳細な説明において、多数の特定の詳細が本願開示と本明細書に説明される実施例との完全な理解を提供するために明記される。しかしながら、本明細書に説明される実施例は、これらの特定の詳細なしで実施されることもある。他の例において、周知の方法、手順、コンポーネント及び機械的な装置は、実施例の様態を不必要に分かりにくくしないように、詳細には説明されていない。
【００１５】
本発明は、さらに、添付の図面と具体的な実施形態とを参照して以下に詳細に説明される。
【００１６】
図３は、本発明のいくつかの実施形態に従うコンピュータ情報システムのための動的障害回復方法のフローチャートである。図３を参照すると、コンピュータ情報システムのための動的障害回復方法は、下記のステップを含む。
【００１７】
ステップ３０１：サービスカテゴリに従って少なくとも２つのサービスクラスタを分類し、サービスクラスタの各々に少なくとも２つのサービスノードを設定し、サービスノードの各々は、システムにおけるサービスカテゴリのすべてのためのサービス処理ロジックを設定する。
【００１８】
ステップ３０２：サービスクラスタの各々のための動的障害回復ポリシーを設定する。
【００１９】
ステップ３０３：サービスクラスタの各々の動作状態を監視し、サービスクラスタの各々が正常に動作している場合、それぞれのサービスカテゴリのサービス要求が、動的障害回復ポリシーに従って、応答のために上記サービスカテゴリに対応するサービスクラスタに対してスケジュールされ、サービスクラスタのうち１つが異常に動作している場合、そのサービスクラスタの動的障害回復ポリシーに従って、対応サービスカテゴリのサービス要求の応答サービスクラスタ及び／又は応答モードに対して、動的調整が行われる。
【００２０】
本発明における方法に対応して、本発明は、コンピュータ情報システムも開示する。
【００２１】
図４は、本発明のいくつかの実施形態に従うコンピュータ情報システムのシステムアーキテクチャの概略図である。図４を参照すると、コンピュータ情報システムは、下記を含む。
【００２２】
サービスカテゴリに従って分類された少なくとも２つのサービスクラスタ。例えば、図３における３つのサービスクラスタ４０１、４０２及び４０３であり、各サービスクラスタは少なくとも２つのサービスノードを含む。サービスノードの各々は、コンピュータ情報システムにおけるサービスカテゴリのすべてのためのサービス処理ロジックを有し、サービス処理ロジックは、サービスクラスタに到達するサービス要求に応答することに使用される。すなわち、本発明におけるサービスクラスタのすべての中のすべてのサービスノードは、機能においてピアであり、サービス要求のいかなるカテゴリについても（例えば、図３において、３つのサービスカテゴリＡ、Ｂ及びＣが分類されると仮定される）、サービスノードのうち任意の１つがサービス要求に対して応答処理を実行することができる。
【００２３】
サービスクラスタに加えて、本発明のいくつかの実施形態に従うコンピュータ情報システムは、さらに、動的障害回復ノード、すなわち、図４におけるノードＤ４０４を含む。動的障害回復ノードは、サービスクラスタの各々のための動的障害回復ポリシーを設定すること、及びサービスクラスタの各々の動作状態を監視することに使用される。サービスクラスタのすべてが正常に動作している場合、動的障害回復ポリシーに従って、それぞれのサービスカテゴリのサービス要求が、応答処理のために上記サービスカテゴリに対応するサービスクラスタに対してスケジュールされる。サービスクラスタのうち１つが異常に動作している場合、そのサービスクラスタの動的障害回復ポリシーに従って、対応サービスカテゴリのサービス要求の応答サービスクラスタ及び／又は応答モードに対して、動的調整が行われる。
【００２４】
いくつかの実施形態において、動的障害回復ノードの数は、１つである。いくつかの他の実施形態において、動的障害回復ノードの数は、２つ又は３つ以上である。例えば、図５は、本発明のいくつかの実施形態に従うコンピュータ情報システムの別のシステムアーキテクチャの概略図であり、これには、互いをバックアップし、互いにおいて障害回復切り替えを実行する能力があるプライマリ動的障害回復ノード５４１とスタンバイ障害回復ノード５４２とが含まれ、プライマリ動的障害回復ノード５４１とスタンバイ障害回復ノード５４２とは、動的障害回復サービスを提供する障害回復サービスクラスタ５０４を形成する。正常な状況において、プライマリ動的障害回復ノードが動的障害回復サービスを提供し、プライマリ動的障害回復ノードが異常に動作するとき、スタンバイ動的障害回復ノードがさらなる動作のために切り替えられることができる。スタンバイ動的障害回復ノードはプライマリ動的障害回復ノードになるように切り替えられ、前述のプライマリ動的障害回復ノードはスタンバイ動的障害回復ノードになるように切り替えられ、これにより、システム全体のロバスト性がさらに改良される。
【００２５】
動的障害回復ポリシーは前もって設定されてよく、具体的に設定された動的障害回復ポリシーは様々な内容を有してよく、これらは以下で実施形態に具体的に導入される。
【００２６】
いくつかの実施形態において、動的障害回復ポリシーは、サービスクラスタのすべてが正常に動作している場合に、それぞれのサービスカテゴリのサービス要求が、そのサービスカテゴリに対応するように固定されたサービスクラスタによって実行される応答処理を受けるというストラテジを含む。図４及び図５に示されるとおり、サービスクラスタのすべてが正常に動作している場合、サービスクラスタ４０１は外部に対してクラスＡサービスだけを提供し、サービスクラスタ４０２は外部に対してクラスＢサービスだけを提供し、サービスクラスタ４０３は外部に対してクラスＣサービスだけを提供する。この固定の相互関係は、動的障害回復ポリシー内の情報の一部であり、前もって設定される必要があり、その特定の内容には、各サービスカテゴリとそれに対応するサービスクラスタアドレスとの間の相互関係を含む。サービスクラスタのうち１つが異常に動作している場合、その対応サービスカテゴリのサービス要求の応答サービスクラスタ及び／又は応答モードが、動的に調整される必要がある。さらに、特定の調整命令情報が動的障害回復ポリシーの一部であり、概して、各サービスカテゴリのサービスクラスタは、上記調整命令を含む対応動的障害回復ポリシーを有する。
【００２７】
ステップ３０３において、サービスカテゴリの各々の動作状態を監視する多数の特定の方法が存在する。例えば、２つの典型的な方法が、下記のとおりである。
【００２８】
第１の監視方法は、サービスクラスタの各々の中のサービスノードの各々が周期的に（例えば、Ｔ１秒の間隔で）その自身の負荷情報を動的障害回復ノードに報告することであり、負荷情報には、一般的な負荷情報、例えば、ＣＰＵ使用率、ネットワーク使用率などを含んでよい。動的障害回復ノードは、報告状況と報告された負荷情報とに従ってサービスクラスタの各々の動作状態を判断する。例えば、報告状況は、サービスノードが負荷情報をＴ１秒ごとに１回報告しているかを示し、サービスノードからの報告の数又は頻度が規定値より少ない場合、サービスノードが異常であると判定される。それから、サービスノードの負荷が規定値より大きいかが、報告された負荷情報に従って判断される。サービスノードの負荷が規定値より大きい場合、サービスノードは異常に動作していると判定される。最後、各サービスクラスタの中の異常なサービスノードの数が規定値より大きいかが判断される。それぞれのサービスクラスタの中の異常なサービスノードの数が規定値より大きい場合、それぞれのサービスクラスタは異常に動作していると判定され、そうでない場合、それぞれのサービスクラスタは正常に動作していると判定される。
【００２９】
別法として、第２の監視方法は、サービスを要求するクライアントが周期的に（例えば、Ｔ２秒の間隔で）各カテゴリのサービス要求の数及び応答コンディションを動的障害回復ノードに報告することであり、動的障害回復ノードは、それぞれのカテゴリに対応するサービスクラスタの動作状態を、それぞれのカテゴリのサービス要求の報告された数と応答コンディションとに従って判断する。例えば、あるカテゴリのサービス要求における応答失敗の数が規定閾値より大きい場合、このサービスカテゴリに対応するように固定されたサービスクラスタは異常に動作していると判定され、そうでない場合、このサービスカテゴリに対応するサービスクラスタは正常に動作していると判定される。
【００３０】
前述された監視方法を通じて、動的障害回復ノードは、いかなるときもサービスクラスタの各々の動作状態を監視し、動作状態とサービスクラスタの各々に対応する動的障害回復ポリシーとに従って調整を行うことができる。
【００３１】
いくつかの実施形態において、各サービスカテゴリとこれに対応するサービスクラスタアドレスとの間の相互関係に関する情報が、様々なクライアントに設定されてよい。例えば、上記情報は、前もってクライアントに具体的に設定されてもよく、あるいはシステムが起動した後に動的障害回復ノードによって様々なクライアントに送信されてもよい。コンピュータ情報システムが最初に起動した後、サービスクラスタのすべてが、デフォルトで正常に動作していると考えられ、この時点において、クライアントがあるカテゴリのサービス要求を開始した場合、そのカテゴリのサービス要求は、上記相互関係に従って、応答処理のために該カテゴリに対応するサービスクラスタアドレスに送出されることになる。例えば、クラスＡサービス要求はクラスＡサービスクラスタに送信され、クラスＢサービス要求はクラスＢサービスクラスタに送信され、クラスＣサービス要求はクラスＣサービスクラスタに送信される。サービス要求を受信するサービスクラスタは、内部のＴＣＰレイヤを通じてロードバランスをとる態様で、あるサービスノードにサービス要求を無作為に割り当て、このサービスノードは、サービス要求に対して応答処理を実行する。障害事象、例えばハードウェア故障が、あるサービスノードにおいて発生したとき、サービスクラスタは、受信したサービス要求を、応答処理のために他の正常動作サービスノードに割り当てることになる。
【００３２】
システムが動作するように起動した後、動的障害回復ノードは、前述の監視方法によってサービスクラスタの各々の動作状態を監視し、サービスクラスタのうち１つが異常に動作していると監視された場合、動的障害回復ノードは、サービスクラスタの動的障害回復ポリシーに従って、その対応サービスカテゴリのサービス要求のための応答サービスクラスタ及び／又は応答モードを動的に調整する。
【００３３】
いくつかの実施形態において、低下可能サービス次元（degradable  service  dimension）に従って分類されたサービスカテゴリの技術的解決策が、さらに提供される。上述の、サービスカテゴリに従ったサービスクラスタ分類について、種々のサービスカテゴリが、低下可能サービス次元を使用して区別される。低下可能サービスとは、サービスロジックの中のいくつかのモジュールにおいて故障が発生したとき、いくつかのサービスがユーザになおも提供されて、ユーザの中核的要望、例えばインターネットウェブサイトに対するユーザのログインと個人情報の確認となどの要望を満たせることを指し、このサービスは、低下可能サービスと呼ぶことができる。低下可能サービス次元は、低下可能サービスにとって容認可能な低下程度を評価し、容認可能な低下程度が大きいほど、その低下可能サービス次元は高くなる。
【００３４】
例えば、上述のクラスＡ、Ｂ及びＣサービスは、ユーザ作用及び到来作用に従って分類することができ、低下可能サービスのアプリケーションシナリオが考慮される。一般的なインターネットサービスを一例にとると、クラスＡサービスは、中核的ユーザ体験サービスであり、必須のコンテンツである。ユーザは、このカテゴリのサービス、例えばログイン動作などにおける問題を容認できず、これの低下可能サービス次元は最も低い。クラスＢサービスは、ユーザ体験低下可能サービスである。このカテゴリのサービス、例えば、友人のホームページを確認すること、ファイルをアップロード又はダウンロードすることなどのサービスにおいて短時間利用できないことは、ユーザにとって容認可能であり、このカテゴリのサービスの低下可能サービス次元は、クラスＡサービスの次元よりもわずかに高くなる。クラスＣサービスは、ユーザ体験無視可能サービスである。このカテゴリのサービスは、ユーザ体験にだけ影響し、サービスが長時間修復できないとしても大きな影響を与えず、このカテゴリのサービスの低下可能サービス次元は最も高い。
【００３５】
上記で説明されたとおり、クラスＡ、Ｂ及びＣサービスは、低下可能サービス次元に従って低から高に及ぶ。サービス要求の応答サービスクラスタ及び／又は応答モードが動的に調整されるとき、処理は、種々の低下可能サービス次元に従って実行されることができる。
【００３６】
例えば、サービスクラスタが異常に動作していて、動的障害回復ノードがサービスクラスタの動的障害回復ポリシーに従って対応サービスカテゴリのサービス要求の応答サービスクラスタ及び／又は応答モードを動的に調整する特定のモードには、下記の判断し及び処理するステップを含む：（１又は複数の）他の正常動作サービスクラスタの負荷状況が、異常動作サービスクラスタに対応するカテゴリのサービス要求の負荷を担うことができるかを判断し、そうである場合、（１又は複数の）正常動作サービスクラスタを、異常動作サービスクラスタに対応するカテゴリのサービス要求に応答するようにスケジュールし、そうでない場合、異常動作サービスクラスタの次元より高い低下可能サービス次元を有するサービスクラスタについて、上記のより高い低下可能サービス次元を有するサービスクラスタによってその対応カテゴリのサービス要求に対して実行される応答処理を停止し、判断し及び処理するステップを繰り返す。
【００３７】
例えば、図４及び図５に示されるとおり、動的障害回復ノードが、クラスＡサービスクラスタが異常に動作していると監視を通じて見いだした場合、動的障害回復ノードは、最初、別の正常動作サービスクラスタ（例えば、本明細書におけるクラスＢサービスクラスタ及びクラスＣサービスクラスタ）の負荷状況が、クラスＡサービスクラスタが相応に応答すべきと想定されるクラスＡサービス要求の負荷を担うことができるかを判断する。例えば、上記の判断は、具体的に、サービスノード又はクライアントによって報告される情報に従って実行されてよく、特定の判断態様が、当分野に知られる手法を使用して実施されてもよい。
【００３８】
クラスＢサービスクラスタとクラスＣサービスクラスタとがクラスＡサービス要求の負荷を担うことができる場合、正常動作のクラスＢサービスクラスタ及びクラスＣサービスクラスタは、クラスＡサービス要求に応答するようにスケジュールされる。例えば、具体的に、クライアントからのクラスＡサービス要求は、応答処理のためにクラスＢサービスクラスタ及びクラスＣサービスクラスタの中のサービスノードの各々に均等に分散されることがあり得る。
【００３９】
クラスＢサービスクラスタ及びクラスＣサービスクラスタ双方の低下可能サービス次元がクラスＡサービスクラスタの低下可能サービス次元より高いため、クラスＢサービスクラスタとクラスＣサービスクラスタとがクラスＡサービス要求の負荷を担うことができる場合、クラスＢサービスクラスタ及びクラスＣサービスクラスタのサービス要求に対するその応答は、調整することができる。例えば、具体的に、高い低下可能サービス次元を有する上記のサービスクラスタによってその対応カテゴリのサービス要求に対して実行される応答処理が停止されるということがあり得る。１つのサービスクラスタだけが、異常動作サービスクラスタの低下可能サービス次元より高い低下可能サービス次元を有する場合、上記のより高い低下可能サービス次元を有するサービスクラスタによってその対応カテゴリのサービス要求に対して実行される応答処理が直接停止される。少なくとも２つのサービスクラスタが、異常動作サービスクラスタの低下可能サービス次元より高い低下可能サービス次元を有する場合、例えば、本明細書におけるクラスＢサービスクラスタ及びクラスＣサービスクラスタの低下可能サービス次元が双方、クラスＡサービスクラスタの低下可能サービス次元より高い状況において、最も高い低下可能サービス次元を有するサービスクラスタ（例えば、本明細書におけるクラスＣサービスクラスタ）によってその対応カテゴリのサービス要求に対して実行される応答処理が最初停止され、それから、判断し及び処理するステップが繰り返される。正常動作サービスクラスタ（本明細書において、クラスＢサービスクラスタ及びクラスＣサービスクラスタ）の負荷状況が、異常動作サービスクラスタに対応するカテゴリのサービス要求の負荷をなお担うことができない場合、１段階低い低下可能サービス次元を有するサービスクラスタによってその対応カテゴリのサービス要求に対して実行される応答処理がさらに停止される。４つ以上のサービスクラスタが、異常なクラスＡサービスクラスタの低下可能サービス次元より高い低下可能サービス次元を有する場合、正常動作サービスクラスタの負荷状況がクラスＡサービス要求の負荷を担うことができるまで、あるいはクラスＡサービスクラスタの低下可能サービス次元より高い低下可能サービス次元を有するすべてのサービスクラスタによってその対応カテゴリのサービス要求に対して実行される応答処理が停止されるまで、判断し及び処理するステップが再び繰り返される。
【００４０】
オフライン応答を許容するサービスがインターネット情報サービスに存在し、そのサービスデータは頻繁には更新されず、それゆえにサーバ上に記憶されてよく、クライアント上に記憶されてもよく、このカテゴリのサービスのサービス要求は、サーバにより実行される応答処理を受けることができ、クライアントに記憶されたデータを使用してクライアントにより実行されるオフライン応答処理を受けることもできる。例えば、関係チェーン（relationship  chain）に基づいたいくつかのインターネットサービスは、オフライン応答を許容するこの種のサービスに属する。関係チェーンにおいて故障が発生し、あるいは関係チェーンがあまりに大きな圧力下にあるとき、ローカル関係チェーンモードが開始されることができ、クライアントは、毎日最初にログインするとき、関係チェーンデータをプルし、同じものをローカルクライアントに後続のプルなく記憶する。このようにして、サーバの関係チェーンサービスが利用できないとしても、クライアントは関係チェーンサービス要求に対してオフライン応答をなお行うことができ、これにより、ユーザが関係チェーンサービスを正常に使用できることが保証される。
【００４１】
それゆえに、いくつかの実施形態において、異常動作サービスクラスタの低下可能サービス次元より高い低下可能サービス次元を有するサービスクラスタに対応するカテゴリのサービスが、オフライン応答を許容するサービスである場合、例えば、クラスＣサービスがオフライン応答を許容するサービスである場合、クラスＣサービスクラスタによってクラスＣサービス要求に対して実行される応答処理を停止することには、クラスＣサービス要求のためのクラスＣサービスクラスタの応答モードを調整することを含み、これは具体的に、例えば、クラスＣサービス要求をオフライン応答モードに変更すること、及びサービス要求の起動側（initiator）クライアントにサービス要求をローカルにオフライン応答モードにおいて処理するように指示することである。
【００４２】
いくつかの実施形態において、対応カテゴリのサービス要求の応答サービスクラスタ及び／又は応答モードを動的に調整する動的障害回復ノードの特定の動作には、異常動作サービスクラスタに対応するカテゴリのサービス要求に応答するように正常動作サービスクラスタをスケジュールすること、及び／又はサービスクラスタのうち１つによってその対応カテゴリのサービス要求に対して実行される応答処理を停止すること、及び／又はあるカテゴリのサービスクラスタの応答モードをその対応カテゴリのサービス要求に関して調整することを含み、上記方法の特定の実施態様が下記のとおりである。
【００４３】
ａ）対応サービスカテゴリのサービス要求の応答サービスクラスタアドレス及び／又は応答モード情報を含むスケジュール情報を生成する。例えば、動的障害回復ノードが実行すべき調整動作が、クラスＡサービス要求に応答するようにクラスＢサービスクラスタとクラスＣサービスクラスタとをスケジュールすること、及びクラスＣサービス要求の応答モードをオフライン応答モードに変更すること、並びにその一方でクラスＢサービスクラスタによってクラスＢサービス要求に対して実行される応答処理を停止することであると仮定されるとき、スケジュール情報において、クラスＡサービス要求に対応する応答サービスクラスタのアドレスはクラスＢサービスクラスタ及びクラスＣサービスクラスタのアドレスであり、クラスＢサービス要求に対応する応答サービスクラスタのアドレスは空であり、クラスＣサービス要求の応答モードはオフライン応答に変更される。
【００４４】
ｂ）上記スケジュール情報をクライアントに送信する。例えば、具体的に、スケジュール情報は、生成された後にクライアントに能動的に送信され、あるいは、クライアントが動的障害回復ノードにＴ３秒ごとに１回問い合わせて、動的障害回復ノードが応答パケットの態様で最新のスケジュール情報をクライアントに送信する。
【００４５】
ｃ）クライアントが、受信したスケジュール情報に従って対応サービスクラスタに向けてサービス要求を開始し、かつ／あるいは応答モード情報に従って対応サービス要求を処理する。例えば、ステップａ）におけるスケジュール情報に従って、クライアントは、クラスＡサービス要求をクラスＢサービスクラスタ及びクラスＣサービスクラスタに送信し、クラスＢサービス要求を送信することを放棄し、クラスＣサービス要求は、オフライン応答モードにおいてクライアントによってローカルに処理される。
【００４６】
図４及び図５に示されるとおり、動的障害回復ノードが、クラスＢサービスクラスタが異常に動作していると監視を通じて見いだした場合、処理は、上記の判断し及び処理するステップに従って同様に実行されてよく、すなわち、他の正常動作のクラスＡサービスクラスタ及びクラスＣサービスクラスタの負荷状況が、異常動作クラスＢサービスクラスタに対応するクラスＢサービス要求の負荷を担うことができるかを判断する。そうである場合、クラスＢサービス要求に応答するように正常動作のクラスＡサービスクラスタ及びクラスＣサービスクラスタをスケジュールし、そうでない場合、クラスＢサービスクラスタの低下可能サービス次元より高い低下可能サービス次元を有するサービスクラスタ、すなわちクラスＣサービスクラスタについて、クラスＣサービスクラスタによってクラスＣサービス要求に対して実行される応答処理を停止し、それから、クラスＡサービスクラスタ及びクラスＣサービスクラスタの負荷状況がクラスＢサービス要求の負荷を担うことができるかを再度判断する。そうである場合、クラスＢサービス要求に応答するように正常動作のクラスＡサービスクラス及びクラスＣサービスクラスタをスケジュールし、そうでない場合、これ以上処理を実行しない。
【００４７】
さらに、クラスＢサービス要求のための動的障害回復ポリシーは別の態様で実施されてもよく、例えば、時間がサービスピーク期間であるかを判断する。そうである場合、上記の判断し及び処理するステップにおける調整は実行されないことになり、現在の時間が非ピーク期間である場合、上記の判断し及び処理するステップが調整のために再度実行される。
【００４８】
図４及び図５に示されるとおり、動的障害回復ノードが、クラスＣサービスクラスタが異常に動作していると監視を通じて見いだした場合、処理は、上記の判断し及び処理するステップに従って同様に実行されてよく、すなわち、他の正常動作のクラスＡサービスクラスタ及びクラスＢサービスクラスタの負荷状況が、異常動作クラスＣサービスクラスタに対応するクラスＣサービス要求の負荷を担うことができるかを判断する。そうである場合、クラスＣサービス要求に応答するように正常動作のクラスＡサービスクラスタ及びクラスＢサービスクラスタをスケジュールし、そうでない場合、クラスＣサービスクラスタの低下可能サービス次元が最も高いため、唯一の方法は、クラスＣサービス要求の応答モードを調整すること、すなわち、クラスＣサービス要求をオフライン応答モードに変更すること、及びクラスＣサービス要求の起動側にサービス要求をローカルにオフライン応答モードにおいて処理するように指示することである。
【００４９】
当然ながら、クラスＣサービス要求のための動的障害回復ポリシーは、別の態様で実施されてもよく、例えば、動的障害回復ノードが、クラスＣサービスクラスタが異常に動作していると監視を通じて見いだした場合、動的障害回復ノードはクラスＣサービス要求の応答モードを直接調整することができ、すなわち、動的障害回復ノードは、クラスＣサービス要求をオフライン応答モードに変更し、クラスＣサービス要求の起動側にサービス要求をローカルにオフライン応答モードにおいて処理するように指示する。
【００５０】
サービスクラスタのすべてが正常な状態に戻った場合、動的障害回復ノードは、サービスカテゴリの各々のサービス要求を、応答処理のために該サービスカテゴリに対応するサービスクラスタに対してスケジュールし続ける。例えば、特定の態様において、動的障害回復ノードは、サービスクラスタが正常に動作していると示すスケジュール情報をクライアントに送信する。このスケジュール情報を受信した後、クライアントが、各サービスカテゴリとこれに対応するサービスクラスタアドレスとの間の相互関係に関する記憶された情報に従ってあるカテゴリのサービス要求を開始する場合、クライアントは、そのサービスカテゴリのサービス要求を、これに対応するサービスクラスタアドレスに応答処理のために送信する。例えば、クラスＡサービス要求はクラスＡサービスクラスタに送信され、クラスＢサービス要求はクラスＢサービスクラスタに送信され、クラスＣサービス要求はクラスＣサービスクラスタに送信される。
【００５１】
上記で説明されたとおり、本発明と先行技術とを比較すると、コンピュータ情報システム全体におけるすべてのサービスノードがピアであり、サービスクラスタの各々の動作状態に従って、サービス要求に対する対応サービスクラスタの応答モードは動的に調整することができ、サービスクラスタのうち１つの中の故障サービスノードが特定数に到達し、外部向けサービスが提供できないとしても、サービスクラスタが相応に応答すべきサービス要求は別の正常動作サービスクラスタに転送されることもでき、したがって、コンピュータ情報システム全体によって外部に提供されるサービスは容易には中断されず、これにより、コンピュータ情報システムのロバスト性が改良され、バースト負荷及び故障を扱う能力が改良される。
【００５２】
さらに、本発明において、サービスノードがすべてピアである、すなわちサービスノードが同じ処理ロジックを含むため、本発明は、非常に強いスケーラビリティを有する。
【００５３】
さらに、本発明において、サービスカテゴリとこれに対応するサービスクラスタとは、低下可能サービスの次元に従って分類することができ、サービスクラスタのうち１つが異常であるとき、好ましくは、低い低下可能サービス次元を有するサービス（すなわち、比較的に中核のサービス）は継続的に提供でき、高い低下可能サービス次元を有するサービス（すなわち、ユーザがサービス品質の大幅な下落を我慢できるサービス）は停止され、あるいはオフライン応答モードに変更できることが保証される。このようにして、障害回復の間、中核サービスの安定性を保証することができ、ユーザの満足度を改良することができる。
【００５４】
図６は、いくつかの実施形態に従うサービスクラスタ（例えば、サービスクラスタ４０１、４０２又は４０３）の中のサービスノード６００を例示するブロック図である。サービスノード６００は、メモリ６１２に記憶されたモジュール、プログラム及び／又は命令を実行し、これにより処理動作を実行する１又は複数の処理ユニット（ＣＰＵ）６０２と、１又は複数のネットワーク又は他の通信インタフェース６１０と、メモリ６１２と、上記のコンポーネントを相互接続する１又は複数の通信バス６１４とを通常含む。通信バス６１４は、システムコンポーネント間の通信を相互接続し、制御する回路（チップセットと呼ばれることがある）を場合により含む。サービスノード６００は、ディスプレイ装置６０６とキーボード６０８とを含むユーザインタフェース６０４を場合により含んでよい。メモリ６１２は、ＤＲＡＭ、ＳＲＡＭ、ＤＤＲ  ＲＡＭ又は他のランダムアクセスソリッドステートメモリ装置などの高速ランダムアクセスメモリを含み、１又は複数の磁気ディスク記憶装置、光ディスク記憶装置、フラッシュメモリ装置又は他の不揮発性ソリッドステート記憶装置などの不揮発性メモリを含んでもよい。メモリ６１２は、（１又は複数の）ＣＰＵ６０２から遠隔に位置する１又は複数の記憶装置を場合により含んでよい。メモリ６１２、又は別法としてメモリ６１２内の（１又は複数の）不揮発性メモリ装置は、非一時的コンピュータ可読記憶媒体を含む。いくつかの実施形態において、メモリ６１２、又はメモリ６１２のコンピュータ可読記憶媒体は、下記のプログラム、モジュール及びデータ構造、又はこれらのサブセットを記憶する。
【００５５】
・様々な基本のシステムサービスを扱い、ハードウェア依存タスクを実行するための手順を含むオペレーティングシステム６１６。
【００５６】
・１又は複数の通信ネットワークインタフェース６１０（有線又は無線）と、インターネット、他のワイドエリアネットワーク、ローカルエリアネットワーク、メトロポリタンエリアネットワークなどの１又は複数の通信ネットワークとを介して、サービスノード６００を他のコンピュータに接続することに使用されるネットワーク通信モジュール６１８。
【００５７】
・それぞれのサービスカテゴリに対応するサービス要求を処理するサービス処理ロジック６２０。
【００５８】
・負荷ステータス又は状況を動的障害回復ノード４０４に報告する負荷状況報告モジュール６２２。
【００５９】
サービス処理ロジック６２０は、システムにおいて様々なサービスカテゴリからの要求を処理するロジックを含む。したがって、図４乃至図５に例示され上記で説明された例を使用すると、サービス処理ロジック６２０は、クラスＡ要求、クラスＢ要求及びクラスＣ要求に応答する能力がある。
【００６０】
上記で識別された要素の各々は、これまでに言及されたメモリ装置のうち１又は複数に記憶されてよく、上記で説明された機能を実行する命令セットに対応する。上記で識別されたモジュール又はプログラム（すなわち、命令セット）は、別個のソフトウェアプログラム、手順又はモジュールとして実施される必要はなく、したがって、上記のモジュールの様々なサブセットが、様々な実施形態において組み合わせられ、あるいはその他の方法で再配置されてよい。いくつかの実施形態において、メモリ６１２は、上記で識別されたモジュール及びデータ構造のサブセットを記憶してよい。さらに、メモリ６１２は、上記で説明されていない追加のモジュール及びデータ構造を記憶してもよい。
【００６１】
図６は「サービスノード」を示すが、図６は、本明細書に説明された実施形態の構造概要図であることよりも、一組のサーバに存在し得る様々な特徴の機能的説明であることが意図される。実際には、当業者により認識されるとおり、別個に示される項目が組み合わせられてよく、いくつかのアイテムが分離されてよい。
【００６２】
図７は、いくつかの実施形態に従う動的障害回復ノード４０４（又は、５４１若しくは５４２）を例示するブロック図である。動的障害回復ノード４０４は、メモリ７１２に記憶されたモジュール、プログラム及び／又は命令を実行し、これにより処理動作を実行する１又は複数の処理ユニット（ＣＰＵ）７０２と、１又は複数のネットワーク又は他の通信インタフェース７１０と、メモリ７１２と、上記のコンポーネントを相互接続する１又は複数の通信バス７１４とを通常含む。通信バス７１４は、システムコンポーネント間の通信を相互接続し、制御する回路（チップセットと呼ばれることがある）を場合により含む。動的障害回復ノード４０４は、ディスプレイ装置７０６とキーボード７０８とを含むユーザインタフェース７０４を場合により含んでよい。メモリ７１２は、ＤＲＡＭ、ＳＲＡＭ、ＤＤＲ  ＲＡＭ又は他のランダムアクセスソリッドステートメモリ装置などの高速ランダムアクセスメモリを含み、１又は複数の磁気ディスク記憶装置、光ディスク記憶装置、フラッシュメモリ装置又は他の不揮発性ソリッドステート記憶装置などの不揮発性メモリを含んでもよい。メモリ７１２は、（１又は複数の）ＣＰＵ７０２から遠隔に位置する１又は複数の記憶装置を場合により含んでよい。メモリ７１２、又は別法としてメモリ７１２内の（１又は複数の）不揮発性メモリ装置は、非一時的コンピュータ可読記憶媒体を含む。いくつかの実施形態において、メモリ７１２、又はメモリ７１２のコンピュータ可読記憶媒体は、下記のプログラム、モジュール及びデータ構造、又はこれらのサブセットを記憶する。
【００６３】
・様々な基本のシステムサービスを扱い、ハードウェア依存タスクを実行するための手順を含むオペレーティングシステム７１６。
【００６４】
・１又は複数の通信ネットワークインタフェース７１０（有線又は無線）と、インターネット、他のワイドエリアネットワーク、ローカルエリアネットワーク、メトロポリタンエリアネットワークなどの１又は複数の通信ネットワークとを介して、動的障害回復ノード４０４（又は、５４１若しくは５４２）を他のコンピュータに接続することに使用されるネットワーク通信モジュール７１８。
【００６５】
・動的障害回復ストラテジを設定し、サービスクラスタが異常に動作しているときにサービスクラスタに対して動的調整を行う動的障害回復モジュール７２０。
【００６６】
・サービスクラスタ及びサービスノード６００の動作状態を監視する監視モジュール７２２。
【００６７】
・サービスカテゴリとサービスクラスタとの間の対応を含む相互関係情報７２６含み、動的障害回復の間に調整を行うことに使用される調整情報及び他の情報を含む（１又は複数の）動的障害回復ストラテジ７２４。
【００６８】
・スケジュール情報７３０を生成し、送信するスケジュール情報モジュール７２８。
【００６９】
・各サービスクラスタのための応答モード情報を含むスケジュール情報７３０。
【００７０】
上記で識別された要素の各々は、これまでに言及されたメモリ装置のうち１又は複数に記憶されてよく、上記で説明された機能を実行する命令セットに対応する。上記で識別されたモジュール又はプログラム（すなわち、命令セット）は、別個のソフトウェアプログラム、手順又はモジュールとして実施される必要はなく、したがって、上記のモジュールの様々なサブセットが、様々な実施形態において組み合わせられ、あるいはその他の方法で再配置されてよい。いくつかの実施形態において、メモリ７１２は、上記で識別されたモジュール及びデータ構造のサブセットを記憶してよい。さらに、メモリ７１２は、上記で説明されていない追加のモジュール及びデータ構造を記憶してもよい。
【００７１】
図７は「動的障害回復ノード」を示すが、図７は、本明細書に説明された実施形態の構造概要図であることよりも、一組のサーバに存在し得る様々な特徴の機能的説明であることが意図される。実際には、当業者により認識されるとおり、別個に示される項目が組み合わせられてよく、いくつかのアイテムが分離されてよい。例えば、図７に別個に示されるいくつかの項目が単一のサーバ上で実施されてよく、単一の項目が１又は複数のサーバによって実施されてよい。
【００７２】
図８は、いくつかの実施形態に従うクライアント８００を例示するブロック図である。クライアント８００は、メモリ８１２に記憶されたモジュール、プログラム及び／又は命令を実行し、これにより処理動作を実行する１又は複数の処理ユニット（ＣＰＵ）８０２と、１又は複数のネットワーク又は他の通信インタフェース８１０と、メモリ８１２と、上記のコンポーネントを相互接続する１又は複数の通信バス８１４とを通常含む。通信バス８１４は、システムコンポーネント間の通信を相互接続し、制御する回路（チップセットと呼ばれることがある）を場合により含む。クライアント８００は、ディスプレイ装置８０６とキーボード８０８とを含むユーザインタフェース８０４を場合により含んでよい。メモリ８１２は、ＤＲＡＭ、ＳＲＡＭ、ＤＤＲ  ＲＡＭ又は他のランダムアクセスソリッドステートメモリ装置などの高速ランダムアクセスメモリを含み、１又は複数の磁気ディスク記憶装置、光ディスク記憶装置、フラッシュメモリ装置又は他の不揮発性ソリッドステート記憶装置などの不揮発性メモリを含んでもよい。メモリ８１２は、（１又は複数の）ＣＰＵ８０２から遠隔に位置する１又は複数の記憶装置を場合により含んでよい。メモリ８１２、又は別法としてメモリ８１２内の（１又は複数の）不揮発性メモリ装置は、非一時的コンピュータ可読記憶媒体を含む。いくつかの実施形態において、メモリ８１２、又はメモリ８１２のコンピュータ可読記憶媒体は、下記のプログラム、モジュール及びデータ構造、又はこれらのサブセットを記憶する。
【００７３】
・様々な基本のシステムサービスを扱い、ハードウェア依存タスクを実行するための手順を含むオペレーティングシステム８１６。
【００７４】
・１又は複数の通信ネットワークインタフェース８１０（有線又は無線）と、インターネット、他のワイドエリアネットワーク、ローカルエリアネットワーク、メトロポリタンエリアネットワークなどの１又は複数の通信ネットワークとを介して、クライアント８００を他のコンピュータに接続することに使用されるネットワーク通信モジュール８１８。
【００７５】
・サービス要求をサービスクラスタに送信するサービス要求モジュール８２０。
【００７６】
・サービス要求にオフラインで応答するオフライン応答モジュール８２２。
【００７７】
・サービスカテゴリとサービスクラスタとの間の対応を含む相互関係情報８２４。
【００７８】
・各サービスクラスタのための応答モード情報を含むスケジュール情報８２６。
【００７９】
上記で識別された要素の各々は、これまでに言及されたメモリ装置のうち１又は複数に記憶されてよく、上記で説明された機能を実行する命令セットに対応する。上記で識別されたモジュール又はプログラム（すなわち、命令セット）は、別個のソフトウェアプログラム、手順又はモジュールとして実施される必要はなく、したがって、上記のモジュールの様々なサブセットが、様々な実施形態において組み合わせられ、あるいはその他の方法で再配置されてよい。いくつかの実施形態において、メモリ８１２は、上記で識別されたモジュール及びデータ構造のサブセットを記憶してよい。さらに、メモリ８１２は、上記で説明されていない追加のモジュール及びデータ構造を記憶してもよい。
【００８０】
図８は「クライアント」を示すが、図８は、本明細書に説明された実施形態の構造概要図であることよりも、一組のサーバに存在し得る様々な特徴の機能的説明であることが意図される。実際には、当業者により認識されるとおり、別個に示される項目が組み合わせられてよく、いくつかのアイテムが分離されてよい。例えば、図８に別個に示されるいくつかの項目が単一のサーバ上で実施されてよく、単一の項目が１又は複数のサーバによって実施されてよい。
【００８１】
前述の説明は、解説を目的として、特定の実施形態を参照して説明されている。しかしながら、上記の例示的な議論は、網羅的であること、又は本発明を開示された正確な形態に限定することは意図されない。多くの修正及び変形が、上記の教示を考慮して可能である。本願実施形態は、本発明の原理とその実際の適用とを最も良く解説して、これにより考えられる具体的な用法に合わせたとおりに様々な修正を用いて本発明と様々な実施形態とを当業者が最も良く利用できるように、選択され、説明された。
【００８２】
上記で説明されたことは、単に本発明の好適な実施形態であり、本発明を限定することに使用されず、本発明の主旨及び原理内でなされるいかなる修正、均等的置換、改良等もすべて、本発明の保護範囲に包含されるものとする。
【００８３】
本明細書において様々な要素を説明するために第１、第２などの用語が使用され得るが、これらの要素は上記用語によって限定されるべきではない。上記用語は、１つの要素から別の要素を単に区別するために使用される。例えば、本発明の範囲から逸脱することなく、第１の順位付け基準が第２の順位付け基準と命名されてもよく、同様にして、第２の順位付け基準は第１の順位付け基準と命名されてもよい。第１の順位付け基準と第２の順位付け基準とは双方、順位付け基準であり、しかしこれらは同じ順位付け基準ではない。
【００８４】
本明細書における発明の説明に使用される術語は、単に具体的な実施例を説明する目的のものであり、本発明を限定することは意図されない。本発明の説明と別記の請求項とにおいて、単数形の「一の（“a”、“an”）」及び「その（“the”）」は、文脈が明らかに他を示さない限り、同様に複数形を含むことが意図される。さらに、本明細書において使用される用語「及び／又は」は、関連する列挙された項目のうち１又は複数についての任意の及びすべてのとり得る組み合わせを指し、包含することが理解されるであろう。さらに、用語「含まれる」「含まれている」「含む」及び／又は「含んでいる」は、本明細書において使用されるとき、宣言された特徴、動作、要素及び／又はコンポーネントの存在を指定し、しかし１又は複数の他の特徴、動作、要素、コンポーネント及び／又はこれらのグループの存在又は追加を除外しないことが理解されるであろう。
【００８５】
本明細書において、用語「〜する場合（“if”）」は、文脈に依存して、宣言された先行する条件が真である「とき」若しくは「と」又は「との判定に応じて」若しくは「との判定に従って」若しくは「との検出に応じて」を意味するとみなされてもよい。同様にして、「［宣言された先行する条件が真である］と判定された場合」又は「［宣言された先行する条件が真である］場合」若しくは「［宣言された先行する条件が真である］とき」といった語句は、文脈に依存して、宣言された先行する条件が真である「と判定すると」若しくは「との判定に応じて」若しくは「との判定に従って」又は「と検出すると」若しくは「との検出に応じて」を意味するとみなされてもよい。
【００８６】
様々な図面のうちいくつかが複数の論理的段階を具体的な順序で例示しているが、順序依存でない段階は再順序付けされてもよく、他の段階が組み合わせられ、あるいは出現してもよい。いくつかの再順序付け又は他のグルーピングが明確に言及されているが、他のものが当業者に明らかになるであろうし、ゆえに代替手段の網羅的なリストを提示しない。さらに、上記段階は、ハードウェア、ファームウェア、ソフトウェア、又はこれらの任意の組み合わせで実施されてよいことが認識されるべきである。
【００８７】
前述の説明は、解説を目的として、特定の実施形態を参照して説明されている。しかしながら、上記の例示的な議論は、網羅的であること、又は本発明を開示された正確な形態に限定することは意図されない。多くの修正及び変形が、上記の教示を考慮して可能である。本願実施例は、本発明の原理とその実際の適用とを最も良く解説して、これにより考えられる具体的な用法に合わせたとおりに様々な修正を用いて本発明と様々な実施形態とを当業者が最も良く利用できるように、選択され、説明された。実施例には、別記の請求項の主旨及び範囲内にある代替手段、修正及び均等物が含まれる。多数の特定の詳細が、本明細書に提示される対象事項の完全な理解を提供するために明記されている。しかし、上記対象事項はこれらの特定の詳細なしに実施され得ることが当業者に明らかになるであろう。他の例において、周知の方法、手順、コンポーネント及び回路は、実施例の様態を不必要に分かりにくくしないように詳細には説明されていない。
【００８８】
関連出願
本出願は、“ＣＯＭＰＵＴＥＲ  ＩＮＦＯＲＭＡＴＩＯＮ  ＳＹＳＴＥＭ  ＡＮＤ  ＤＹＮＡＭＩＣ  ＤＩＳＡＳＴＥＲ  ＲＥＣＯＶＥＲＹ  ＭＥＴＨＯＤ  ＴＨＥＲＥＦＯＲ”と題され２０１２年８月７日に申請された中国特許出願第２０１２１０２７７９８８．７号に対する優先を主張し、上記中国特許出願は、その全体が参照により援用される。
【図１】
2015526815.tif 000003
【図２】
2015526815.tif 000004
【図３】
2015526815.tif 000005
【図４】
2015526815.tif 000006
【図５】
2015526815.tif 000007
【図６】
2015526815.tif 000008
【図７】
2015526815.tif 000009
【図８】
2015526815.tif 000010
【国際調査報告】
2015526815.tif 000011
2015526815.tif 000012