特許 7341244 クラスタ管理方法、装置、およびシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-08-31

(45)【発行日】2023-09-08

(54)【発明の名称】クラスタ管理方法、装置、およびシステム

(51)【国際特許分類】

   G06F 11/07 20060101AFI20230901BHJP

【ＦＩ】

G06F11/07 151

G06F11/07 140A

【請求項の数】 17

(21)【出願番号】P 2021543554

(86)(22)【出願日】2019-09-27

(65)【公表番号】

(43)【公表日】2022-01-20

(86)【国際出願番号】 CN2019108367

(87)【国際公開番号】W WO2020073821

(87)【国際公開日】2020-04-16

【審査請求日】2022-09-21

(31)【優先権主張番号】201811168317.0

(32)【優先日】2018-10-08

(33)【優先権主張国・地域又は機関】CN

(73)【特許権者】

【識別番号】510330264

【氏名又は名称】アリババ・グループ・ホールディング・リミテッド

【氏名又は名称原語表記】ＡＬＩＢＡＢＡ ＧＲＯＵＰ ＨＯＬＤＩＮＧ ＬＩＭＩＴＥＤ

(74)【代理人】

【識別番号】100188558

【弁理士】

【氏名又は名称】飯田 雅人

(74)【代理人】

【識別番号】100205785

【弁理士】

【氏名又は名称】▲高▼橋 史生

(72)【発明者】

【氏名】リン・チェン

【審査官】武田 広太郎

(56)【参考文献】

【文献】米国特許出願公開第２０１８／０１５０３１７（ＵＳ，Ａ１）

【文献】特表２０１６ー５１０９６０（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ １１／０７

Ｇ０６Ｆ ９／５０

(57)【特許請求の範囲】

【請求項1】

クラスタ管理システムであって、
クラスタ内の分散整合性システムに動作要求を発行し、前記分散整合性システムの動作状態を表示するように構成された動作・メンテナンス制御プラットフォームと、
前記動作・メンテナンス制御プラットフォームと接続され、前記動作要求を処理するための決定情報を判定し、前記決定情報を前記動作・メンテナンス制御プラットフォームに送信するように構成された決定者モジュールであって、前記決定情報は、前記分散整合性システムのデータ整合性および可用性に基づいて判定される、決定者モジュールと、を備える、システム。

【請求項2】

前記システムは、
前記クラスタ内のホスト上に位置し、前記分散整合性システム内のサービスロールとして機能する構成要素モジュールの監視データを取得するように構成された監視モジュールであって、前記サービスロールは、前記クラスタの各ホストにおけるユーザ要求を調整および処理するためのモジュールである、監視モジュールと、
前記監視モジュールによって取得された前記監視データを収集し、前記監視データを表示するように構成された監視プラットフォームと、をさらに備える、請求項１に記載のシステム。

【請求項3】

前記監視プラットフォームは、前記監視データに従ってアラーム情報を生成し、前記アラーム情報をユーザ側デバイスに送信するようにさらに構成されている、請求項２に記載のシステム。

【請求項4】

前記決定者モジュールは、前記動作要求に対応する動作タイプを判定し、かつ前記動作タイプに対応する動作を実行するための決定情報を判定するようにさらに構成されており、前記決定情報は、前記分散整合性システムの可用性条件およびセキュリティ条件に基づいて判定される、請求項１に記載のシステム。

【請求項5】

前記決定者モジュールは、前記動作タイプが前記分散整合性システムの構成情報をアップグレードすることである場合、前記動作要求に対応する動作の実行を許可することを決定するようにさらに構成されている、請求項４に記載のシステム。

【請求項6】

前記決定者モジュールは、前記動作タイプが前記分散整合性システム内のサービスをアップグレードすることである場合、アップグレードのための前記クラスタから１つのホストを選択し、アップグレードのための前記クラスタから前記ホストを選択する前に、前記ホストがアップグレードされる以前の前のホストのサービスが前記可用性条件を満たすかどうかを判定し、前記サービスが前記可用性条件を満たす場合、前記選択されたホストをアップグレードすることを判定するようにさらに構成されている、請求項４に記載のシステム。

【請求項7】

前記決定者モジュールは、前記動作タイプが前記分散整合性システムによって展開されるホストを交換することである場合、新たに追加されたホストのシリアル番号を取得し、前記新たに追加されたホストの前記シリアル番号と、前記分散整合性システムにおいて交換されていないホストのシリアル番号との関連付けを確立して、新たな分散整合性システムを形成するようにさらに構成されている、請求項４に記載のシステム。

【請求項8】

前記決定者モジュールは、前記動作タイプが前記分散整合性システム内の指定されたホストによって使用されるディスクを交換することである場合、前記分散整合性システムの外部サービスを停止し、前記分散整合性システム内の別のホストからログ情報およびスナップショットデータを取得し、前記ログ情報および前記スナップショットデータを新たに追加されたディスクに記憶した後に前記外部サービスを再開するようにさらに構成されている、請求項４に記載のシステム。

【請求項9】

クラスタ管理方法であって、
クラスタ内の分散整合性システムによって発行された動作要求を取得することと、
前記動作要求を処理するための決定情報を判定し、前記決定情報を動作・メンテナンス制御プラットフォームに送信することであって、前記決定情報は、前記分散整合性システムのデータ整合性および可用性に基づいて判定される、判定することと、を含む、方法。

【請求項10】

前記動作要求を処理するための決定情報を前記判定することは、
前記動作要求に対応する動作タイプを判定することと、前記動作タイプに対応する動作を実行するための決定情報を判定することであって、前記決定情報は、前記分散整合性システムの可用性条件およびセキュリティ条件に基づいて判定される、判定することと、を含む、請求項９に記載の方法。

【請求項11】

前記動作タイプに対応する前記動作を実行するための前記決定情報を前記判定することは、前記動作タイプが前記分散整合性システムの構成情報をアップグレードしているとの判定に応答して、前記動作要求に対応する動作の実行を許可することを判定することを含む、請求項１０に記載の方法。

【請求項12】

前記動作タイプに対応する前記動作を実行するための前記決定情報を前記判定することは、
前記動作タイプが前記分散整合性システム内のサービスをアップグレードしているとの判定に応答して、アップグレードのための前記クラスタからホストを選択することと、
アップグレードのための前記クラスタから前記ホストを選択する前に、前記ホストがアップグレードされる以前の前のホストのサービスが前記可用性条件を満たすかどうかを判定することと、
前記サービスが前記可用性条件を満たすとの判定に応答して、前記選択されたホストをアップグレードすることを判定することと、を含む、請求項１０に記載の方法。

【請求項13】

前記動作タイプに対応する前記動作を実行するための前記決定情報を前記判定することは、
前記動作タイプが前記分散整合性システムによって展開されるホストを交換することであるとの判定に応答して、新たに追加されたホストのシリアル番号を取得することと、
前記新たに追加されたホストの前記シリアル番号と、前記分散整合性システムにおいて交換されていないホストのシリアル番号との関連付けを確立して、新たな分散整合性システムを形成することと、を含む、請求項１０に記載の方法。

【請求項14】

前記動作タイプに対応する前記動作を実行するための前記決定情報を前記判定することは、
前記動作タイプが前記分散整合性システムによって展開されるホストを交換することであるとの判定に応答して、前記分散整合性システムの外部サービスを停止することと、
前記分散整合性システム内の別のホストからログ情報およびスナップショットデータを取得することと、
前記ログ情報および前記スナップショットデータを新たに追加されたディスクに記憶した後に前記外部サービスを再開することと、を含む、請求項１０に記載の方法。

【請求項15】

クラスタ管理装置であって、
クラスタ内の分散整合性システムによって発行された動作要求を取得するように構成された取得モジュールと、
前記動作要求を処理するための決定情報を判定し、前記決定情報を動作・メンテナンス制御プラットフォームに送信するように構成された処理モジュールであって、前記決定情報は、前記分散整合性システムのデータ整合性および可用性に基づいて判定される、処理モジュールと、を備える、装置。

【請求項16】

記憶媒体であって、前記記憶媒体は、内部に記憶されたプログラムを備え、実行時に、前記プログラムは、前記記憶媒体が位置するデバイスを制御して、請求項９～１４のいずれか一項に記載のクラスタ管理方法を実行する、記憶媒体。

【請求項17】

コンピュータシステムであって、
プロセッサと、
メモリであって、前記プロセッサに接続され、前記プロセッサに処理ステップのための命令を提供するように構成されている、メモリと、を備え、前記処理ステップは、
クラスタ内の分散整合性システムによって発行された動作要求を取得することと、
前記動作要求を処理するための決定情報を判定し、前記決定情報を動作・メンテナンス制御プラットフォームに送信することであって、前記決定情報は、前記分散整合性システムのデータ整合性および可用性に基づいて判定される、判定することと、を含む、コンピュータシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、２０１８年１０月８日に出願された「クラスタ管理方法、装置、およびシステム」と題する中国特許出願第２０１８１１６８３１７０号の優先権を主張し、その全体が参照により本明細書に組み込まれる。

【0002】

本出願は、コンピュータ技術の分野に関し、より具体的には、クラスタ管理方法、装置、およびシステムに関する。

【背景技術】

【0003】

分散整合性システムでは、継続的なバージョンリリース、構成変更、ホストの置き換えなどの動作およびメンテナンスに対処するには、プロセスを制御し、システムの通常のサービスおよびデータセキュリティを確保するために、良好な自律的動作・メンテナンス決定システムが必要とされる。大規模なクラウドコンピューティングシナリオでは、分散整合性システムの自律的動作およびメンテナンスをより良く管理するために、分散整合性システムと連係および相互作用してそのシステムの自律的なサービスを達成するために、統一された動作・メンテナンススケジューリングプラットフォームが必要とされる。

【0004】

しかしながら、現在、業界における分散整合性システムの主な動作およびメンテナンス方法では、これらの動作およびメンテナンス作業のために動作・メンテナンス担当者が使用する様々なスクリプトを書き込むための分散整合性システムの開発者を採用し、その動作およびメンテナンス作業は、対応するスクリプトを実行することによって実行されている。しかしながら、既存の実施態様では、エラーが発生する傾向がある。さらに、動作・メンテナンス担当者は、動作エラーの発生を防止するために膨大な時間を費してスクリプトデータに精通する必要があり、これはデータ損失またはサービス中断につながる可能性がある。

【0005】

上記の問題については、有効な解決策はまだ提案されていない。

【発明の概要】

【0006】

本出願の実施形態は、分散整合性システムのためのクラスタ管理方法で使用される手動操作のより高いエラー率によって引き起こされる、分散整合性システムにおけるデータ損失またはサービス中断の技術的問題を少なくとも解決するための、クラスタ管理方法、装置、およびシステムを提供する。

【0007】

本出願の実施形態の一態様によれば、クラスタ管理システムが提供され、クラスタ管理システムは、動作要求をクラスタ内の分散整合性システムに発行し、分散整合性システムの動作状態を表示するように構成された動作・メンテナンス制御プラットフォームと、動作・メンテナンス制御プラットフォームと接続され、動作要求を処理するための決定情報を判定し、決定情報を動作・メンテナンス制御プラットフォームに送信するように構成された決定者モジュールと、を備え、決定情報は、データ整合性および分散整合性システムの可用性に基づいて判定される。

【0008】

本出願の実施形態の別の態様によれば、クラスタ管理方法がさらに提供され、クラスタ管理方法は、クラスタ内の分散整合性システムによって発行された動作要求を取得することと、動作要求を処理するための決定情報を判定し、決定情報を動作・メンテナンス制御プラットフォームに送信することとを含み、決定情報は、分散整合性システムのデータ整合性および可用性に基づいて判定される。

【0009】

本出願の実施形態の別の態様によれば、クラスタ管理装置がさらに提供され、クラスタ管理装置は、クラスタ内の分散整合性システムによって発行された動作要求を取得するように構成された取得モジュールと、動作要求を処理するための決定情報を判定し、決定情報を動作・メンテナンス制御プラットフォームに送信するように構成された処理モジュールとを備え、決定情報は、分散整合性システムのデータ整合性および可用性に基づいて判定される。

【0010】

本出願の実施形態の別の態様によれば、内部に記憶されたプログラムを有する記憶媒体がさらに提供され、実行中に、プログラムは、記憶媒体が配置されているデバイスを制御して、上述のクラスタ管理方法のうちのいずれか１つを実行する。

【0011】

本出願の実施形態の別の態様によれば、コンピュータシステムがさらに提供され、コンピュータシステムは、プロセッサと、メモリであって、プロセッサに接続され、プロセッサに処理ステップを処理するための命令を提供するように構成されている、メモリと、を備え、処理ステップは、クラスタ内の分散整合性システムによって発行された動作要求を取得することと、動作要求を処理するための決定情報を判定し、動作・メンテナンス制御プラットフォームに決定情報を送信することと、を含み、決定情報は、分散整合性システムのデータ整合性および可用性に基づいて判定される。

【0012】

本出願の実施形態では、クラスタ内の分散整合性システムによって発行された動作要求が取得され、動作要求を処理するための決定情報が判定され、かつ動作・メンテナンス制御プラットフォームに送信され、決定情報は、分散整合性システムのデータ整合性および可用性に基づいて判定される。

【0013】

本出願の実施形態に基づいて、分散整合性システム内の決定者モジュールを通してサービスプログラムの可用性およびデータセキュリティを確保する目的が達成され、それによって、分散整合性システムのクラスタ管理効率を向上させ、分散整合性システムのデータ損失またはサービス中断を回避する技術的効果が達成され、これは、分散整合性システムのためのクラスタ管理方法で使用される手動操作のより高いエラー率によって引き起こされる、分散整合性システム内のデータ損失またはサービス中断の技術的問題を解決する。

【図面の簡単な説明】

【0014】

本明細書において説明される添付の図面は、本出願のさらなる理解を提供することを意図しており、本出願の一部を構成する。本出願の例示的な実施形態およびその説明は、本出願を説明するために使用され、本出願に対する不適切な限定を構成するものではない。図面において、

【図1】本出願の実施形態による、クラスタ管理システムの概略図である。

【図2】本出願の実施形態による、任意選択のクラスタ管理システムの概略図である。

【図3】本出願の実施形態による、クラスタ管理方法を実施するためのコンピュータ端末（またはモバイルデバイス）のハードウェア構造のブロック図である。

【図4】本出願の実施形態による、クラスタ管理方法のフローチャートである。

【図5】本出願の実施形態による、任意選択のクラスタ管理方法のフローチャートである。

【図6】本出願の実施形態による、クラスタ管理装置の概略図である。

【図7】本出願の実施形態による、コンピュータ端末の構造ブロック図である。

【発明を実施するための形態】

【0015】

当業者が本出願の解決策をよりよく理解することを可能にするために、本出願の実施形態における技術的解決策は、本出願の実施形態における添付の図面を参照して、以下に明確かつ完全に説明されるであろう。明らかに、記載された実施形態は、本出願の実施形態のいくつかを表すに過ぎず、すべてではない。本出願の実施形態に基づいて、創造的な努力なしに当業者によって得られたすべての他の実施形態は、本出願の保護範囲内に入るべきである。

【0016】

本明細書、特許請求の範囲、および上述の添付図面における「第１」および「第２」を含む用語は、同様の対象物を区別するために使用され、特定の順序または配列を説明するために必ずしも使用されないことに留意されたい。このように使用されるデータは、本明細書に記載されている本出願の実施形態が、本明細書に例示または記載されているもの以外の順序で実装され得るように、適宜交換され得ることを理解されたい。加えて、用語「ｃｏｍｐｒｉｓｉｎｇ（備える、含む）」および「ｈａｖｉｎｇ（有する）」ならびにそれらの任意の変形は、非排他的な包含物を対象とすることが意図される。例えば、一連のステップまたはユニットを含有するプロセス、方法、システム、製品、またはデバイスは、必ずしも明示的に列挙されたステップまたはユニットに限定されず、代わりに、明示的に列挙されていない他のステップまたはユニット、またはこれらのプロセス、方法、製品、またはデバイスに固有の他のステップまたはユニットを含み得る。

【0017】

まず、本出願の実施形態の説明に現れる名詞または用語のいくつかは、以下のように説明される。

【0018】

サーバ集合体（Ｑｕｏｒｕｍ）：分散整合性システムのサーバ集合体。各サーバ集合体は、分散整合性システムのメモリ内データベース、ならびにトランザクションログ情報およびスナップショットデータを永続的に保存する。

【0019】

クラスタ：クラウドコンピューティングシナリオにおけるシステムサービスの展開は、クラスタごとに分類される。クラスタには一定数のホストがあり、システムおよび製品がホストに展開される。

【0020】

ＨｏｓｔＮａｍｅ：一意の論理ホスト名を指す。

【0021】

サーバロール：構成要素モジュールとも呼ばれる。分散整合性システムには多くの構成要素モジュールが存在し、各構成要素モジュールは関連するプロトコルを通じてユーザ要求を調整および処理する必要がある。

【0022】

監視モジュール：分散整合性システムのサービスロールの健康状態を監視するために使用される。

【0023】

決定者モジュール：分散整合性システム上で動作・メンテナンス担当者によって実行された一連の操作を処理するために使用される。これらの操作は、これらの操作が実行され得るかどうか、およびいつ実行され得るかをシステムが確認するという点で、システムの決定に依存する。決定者モジュールは、ホスト上で動作するソフトウェアスレーブプログラムであってもよく、上記の決定機能を実施するために使用されるホストであってもよい。

【0024】

監視プラットフォーム（ＭｏｎＰＦ）：ホストから収集された基本的な監視を表示し、分散整合性システムの監視表示ページを表示するために使用される。

【0025】

動作・メンテナンス管理プラットフォーム（ＯＭＣＰ）：分散整合性システム対するアップグレード、ホスト交換などの動作およびメンテナンス作業用のプラットフォームを使用し得る動作・メンテナンス担当者向けに提供される。

【0026】

実施形態１
本出願の実施形態によれば、図１に示すクラスタ管理システムの実施形態が提供される。図１は、本出願の実施形態による、クラスタ管理システムの概略図である。図１に示すように、クラスタ管理システム１００は、動作・メンテナンス制御プラットフォーム１０１と、決定者モジュール１０３と、を備える。
動作・メンテナンス制御プラットフォーム１０１は、クラスタ内の分散整合性システムに動作要求を発行し、分散整合性システムの動作状態を表示するように構成され、決定者モジュール１０３は、動作・メンテナンス制御プラットフォーム１０１と接続され、動作要求を処理するための決定情報を判定し、決定情報を動作・メンテナンス制御プラットフォームに送信するように構成され、決定情報は、分散整合性システムのデータ整合性および可用性に基づいて判定される。

【0027】

任意選択で、上述の動作・メンテナンス制御プラットフォーム（ＯＭＣＰ）は、動作・メンテナンスのための基本的な展開および統合プラットフォームである。動作・メンテナンス担当者は、動作・メンテナンス制御プラットフォームを使用して、クラスタ内のシステムに動作要求を発行することができる。上述の分散整合性システムの動作状態は、例えば、分散整合性システムが動作要求を実行した後に表示されたページのビューを動作・メンテナンス担当者に示すことによって、動作・メンテナンス制御プラットフォームを使用して動作・メンテナンス担当者にも示され得る。

【0028】

本出願のいくつかの実施形態では、上述の動作要求は、分散整合性システムのバージョンアップ、構成情報のアップグレード、またはサーバの再起動を要求するために使用され得る。

【0029】

なお、本出願の実施形態における上述の動作・メンテナンス制御プラットフォームはまた、動作・メンテナンス担当者に、クラスタ内の分散整合性システムの監視状態および各ステージのアップグレード状態をウェブページを通じて表示してもよい。

【0030】

任意選択の実施形態では、クラウドコンピューティングシナリオにおいて、分散整合性システム全体は、外部使用のためのユニットとしてクラスタを使用して展開されてもよく、管理次元と見なされてもよい。クラスタ内の分散整合性システムのサービスの自律性をより良く達成するために、本出願の実施形態では、クラスタの属性は、３つのタプル＜Ｃｌｕｓｔｅｒ，ＨｏｓｔＮａｍｅ，Ｓｅｒｖｅｒｒｏｌｅ＞に細かく分割することができ、それによって、クラスタを他のクラスタとより良く区別することができる。属性が分割された後、ついで、分散整合性システムを動作させるために、特定のＡＰＩインターフェースが設計されてもよい。

【0031】

なお、クラスタに存在するホストの数は、各ホスト上に展開されるサービスロールの数を表す。

【0032】

上述の任意選択の実施形態では、決定者モジュールは、動作・メンテナンス制御プラットフォームによって提供されるＡＰＩインターフェースを使用して、動作・メンテナンス制御プラットフォームを定期的にポーリングする。任意選択で、ポーリング間隔は、分単位で設定され得る。さらに、動作・メンテナンス制御プラットフォームは、例えば、承認される必要がある現在の動作、承認されている動作、進行中の動作などを要求するための動作要求を決定者モジュールに返す。

【0033】

さらに、決定者モジュールは、動作・メンテナンス制御プラットフォームによって返された動作要求に従って、分散整合性システムのデータ整合性および可用性に基づいて、動作要求を処理するための決定情報を判定し、ＡＰＩインターフェースを介して、決定情報を動作・メンテナンス制御プラットフォームに返し、それによって、動作・メンテナンス制御プラットフォームは、決定情報に従って対応する処理を進めることができる。

【0034】

本出願の実施形態では、クラスタ内の分散整合性システムによって発行された動作要求が取得され、動作要求を処理するための決定情報が判定され、かつ動作・メンテナンス制御プラットフォームに送信され、決定情報は、分散整合性システムのデータ整合性および可用性に基づいて判定される。

【0035】

本出願の実施形態に基づいて、分散整合性システム内の決定者モジュールを通してサービスプログラムの可用性およびデータセキュリティを確保する目的が達成され、それによって、分散整合性システムのクラスタ管理効率を向上させ、分散整合性システムのデータ損失またはサービス中断を回避する技術的効果が達成され、これは、分散整合性システムのためのクラスタ管理方法で使用される手動操作のより高いエラー率によって引き起こされる、分散整合性システム内のデータ損失またはサービス中断の技術的問題を解決する。

【0036】

任意選択の実施形態では、図２に示すように、上述のシステムは、クラスタ内のホスト上に位置し、分散整合性システム内のサービスロールとして機能する構成要素モジュールの監視データを取得するように構成された監視モジュール１０５であって、サービスロールは、クラスタの各ホストにおけるユーザ要求を調整および処理するためのモジュールである、監視モジュール１０５と、監視モジュールによって取得された監視データを収集および表示するように構成された監視プラットフォーム１０７と、をさらに備える。

【0037】

なお、分散整合性システムが複雑な動作環境で動作すると、ホストおよび分散整合性システムの基本的な指標（例えば、ディスクの空き容量、ディスク使用量、ホストおよびシステムのメモリ消費量、ネットワーク帯域幅比など）だけでなく、分散整合性システムのサービスの可用性（例えば、分散整合性システムのサーバが正常に機能するかどうか、サーバが動作しているときの１秒あたりの要求の数など）も監視する必要がある。

【0038】

本出願の実施形態では、分散整合性システムは、クラスタのホスト上に設けられた監視モジュールを介して上述の監視機能を実現し、分散整合性システム内のサービスロールとして機能する構成要素モジュールの監視データを取得し、監視プラットフォーム（例えば、ＭｏｎＰＥ監視プラットフォーム）を介して監視モジュールによって取得された監視データを収集することができる。監視データは、監視プラットフォーム上に表示され得る。

【0039】

加えて、本出願の実施形態では、分散整合性システム内のサービスロールとして機能する構成要素モジュールの監視データは、監視モジュールを使用して取得され、監視データは、ログ分析のためのオープンソースのビッグデータ分析および処理システム（Ｓｐａｒｋ）などの関連データ分析プラットフォームにも接続され、それにより、故障診断および自動作業負荷分析を容易にすることができる。

【0040】

本出願のいくつかの実施形態では、監視プラットフォーム１０７は、監視データに従ってアラーム情報を生成し、アラーム情報をユーザ側デバイスに送信するようにさらに構成されている。

【0041】

例えば、監視プラットフォームが監視データに従ってアラーム情報を生成した後、ＳＭＳおよび電話プラットフォームを接続して、アラーム情報を出力し、動作・メンテナンス担当者またはシステム開発者に通知してもよく、一定期間にわたって分散整合性システムの監視指標表示ビューをさらに表示してもよい。

【0042】

任意選択の実施形態では、監視プラットフォームは、グローバル監視プラットフォームとして機能し、クラスタ内の分散整合性システムの監視状態を報告するためのＡＰＩインターフェースを提供する。分散整合性システムは、監視モジュール（監視プログラム）を提供することによって、分散整合性システム内のサービスロールとして機能する構成要素モジュールの監視データ（例えば、様々な監視指標および健康パラメータ）を取得し、監視プラットフォームによって提供されるＡＰＩインターフェースを呼び出して、監視データを監視プラットフォームに報告する。このように、監視プラットフォームは、動作・メンテナンス担当者またはシステム開発者から、クラスタ内の分散整合性システムの現在の状態をリアルタイムで学習し、例外に対して迅速に応答することができる。

【0043】

なお、ＡＰＩインターフェースは、分散整合性システムによって開始される必要がある動作挙動のための第１のＡＰＩインターフェースであって、動作・メンテナンス制御プラットフォームを動作させるために動作・メンテナンス担当者によって開始される、第１のＡＰＩインターフェースと、第２のＡＰＩインターフェースであって、動作・メンテナンス制御プラットフォームから決定を受信するときに分散整合性システムが応答する必要がある第２のＡＰＩインターフェースと、のうちの少なくとも１つであってもよい。

【0044】

本明細書では、第１のＡＰＩインターフェースは、クラスタ内のサービスロールの決定情報を取得するように構成されており、第１のＡＰＩインターフェースの名前は、ＧｅｔＭａｃｈｉｎｅＳＲＡｃｔｉｏｎＩｎｆｏＦｏｒＤｅｃｉｄｅｒＭｏｄｕｌｅであり、第１のＡＰＩインターフェースのパラメータリストは、
＞ｃｌｕｓｔｅｒ：ｒｅｑｕｉｒｅｄ
＞ｓｅｒｖｅｒｒｏｌｅ：ｒｅｑｕｉｒｅｄであり得る。

【0045】

第１のＡＰＩインターフェースの戻り値は、
＞ｅｒｒ＿ｃｏｄｅ：動作・メンテナンス制御プラットフォームによって定義された標準エラーコード。

【0046】

＞ｅｒｒ＿ｍｓｇ：動作・メンテナンス制御プラットフォームによって定義され、エラーコードに対応する標準的なエラー情報。

【0047】

第１のＡＰＩインターフェースの返却結果はＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）である。

【0048】

ここで、第２のＡＰＩインターフェースは、クラスタ内のサービスロールの決定情報を設定するように構成されており、第２のＡＰＩインターフェースの名前は、ＳｅｔＭａｃｈｉｎｅＳＲＡｃｔｉｏｎＩｎｆｏＦｏｒＤｅｃｉｄｅｒＭｏｄｕｌｅであり、第２のＡＰＩインターフェースのパラメータリストは、
＞ｃｌｕｓｔｅｒ：ｒｅｑｕｉｒｅｄ
＞ｄｅｃｉｄｅ＿ｉｎｆｏ：ｒｅｑｕｉｒｅｄ

【0049】

第２のＡＰＩインターフェースの戻り値は、
＞ｅｒｒ＿ｃｏｄｅ：動作・メンテナンス制御プラットフォームによって定義された標準エラーコード。

【0050】

＞ｅｒｒ＿ｍｓｇ：動作・メンテナンス制御プラットフォームによって定義され、エラーコードに対応する標準的なエラー情報。

【0051】

＞ｄａｔａ：正常に動作するホストのＳｅｒｖｅｒＲｏｌｅリスト。

【0052】

第２のＡＰＩインターフェースの戻り結果は、データである。

【0053】

任意選択の実施形態では、決定者モジュールは、動作要求に対応する動作タイプを判定し、かつ動作タイプに対応する動作を実行するための決定情報を判定するようにさらに構成されており、決定情報は、分散整合性システムの可用性条件およびセキュリティ条件に基づいて判定される。

【0054】

任意選択で、動作タイプは、動作がどのホストに基づいているかを示すための特徴付けとして使用され得る。ここで、決定情報は、動作タイプに対応する動作を実行するための許可と、動作タイプに対応する動作を実行するためのキャンセルとのいずれかを含む。

【0055】

任意選択の実施形態では、決定者モジュールは、動作タイプが分散整合性システムの構成情報をアップグレードすることである場合、動作要求に対応する動作の実行が許可されていることを判定するようにさらに構成されている。

【0056】

なお、分散整合性システムでは、いくつかの構成情報は、グローバル構成テンプレートによって管理されている。したがって、コードではなくいくつかの構成情報を修正する必要がある場合、グローバル構成テンプレート内のパラメータのみを修正する必要がある。ついで、分散整合性システムの構成情報が全体としてアップグレードされる。分散整合性システムは、構成情報の変更を学習し、新しい構成情報を取得する。

【0057】

任意選択の実施形態では、動作・メンテナンス担当者が、動作・メンテナンス制御プラットフォームを使用して、特定のクラスタ内の分散整合性システムの構成情報をアップグレードするための動作要求を開始する場合、分散整合性システムは、動作要求に対応する決定情報を取得し得る。分散整合性システムの構成情報がアップグレードされるシナリオについては、分散整合性システムのプロセスを再起動する必要はない。利用不可の時間をもたらさず、ディスク内のデータセキュリティに影響を与えないので、動作・メンテナンス制御プラットフォームによって提供されるＡＰＩインターフェースは、直接以下のように呼ばれ得る。ＳｅｔＭａｃｈｉｎｅＳＲＡｃｔｉｏｎＩｎｆｏＦｏｒ。そして、決定者モジュールは、動作要求に対応する動作の実行を許可する情報で直接応答することができ、それによって構成情報をアップグレードする動作を直接承認し得る。

【0058】

任意の実施形態では、決定者モジュールは、動作タイプが分散整合性システム内のサービスをアップグレードすることである場合、アップグレードのためのクラスタから１つのホストを選択するようにさらに構成され、アップグレードのためのクラスタから１つのホストが選択される前に、上記ホストがアップグレードされる以前の前のホストのサービスが可用性条件を満たすかどうかが判定され、サービスが可用性条件を満たす場合に、選択されたホストをアップグレードすることが判定される。

【0059】

分散整合性システム内のサービスがアップグレードされると、分散整合性システムのサービス（すなわち、サービスプログラム）を再起動することができる。さらに、分散整合性システム内のサービスがアップグレードされると、分散整合性システムのサービスの利用不可の時間は一時的に影響を受けることになる。したがって、決定者モジュールが、動作・メンテナンス制御プラットフォームによって開始された、分散整合性システムのサービスをアップグレードするための動作要求を取得すると、ホストがアップグレードされる以前の前のホストのサービスが可用性条件、例えば、分散整合性システムのサーバ集合体Ｑｕｏｒｕｍにおけるサービス可用性を満たしているかどうかを判定する必要があり、サーバ集合体Ｑｕｏｒｕｍ内で一度に１つのホスト内のサービスのみがアップグレードされるアップグレードシーケンスが採用される。さらに、ホストのサービスがアップグレードのために選択されるたびに、選択されたホストがアップグレードされる以前の前のホストのサービスが可用性条件を満たすことを保証する必要があり、サービスが可用性条件を満たすと、選択されたホストをアップグレードすることが判定される。

【0060】

任意選択の実施形態では、決定者モジュールは、動作タイプが分散整合性システムによって展開されるホストを交換することである場合、新たに追加されたホストのシリアル番号を取得し、新たに追加されたホストのシリアル番号と、分散整合性システムにおいて交換されていないホストのシリアル番号との関連付けを確立して、新たな分散整合性システムを形成するようにさらに構成されている。

【0061】

クラウドコンピューティングのシナリオで使用されるサーバは、すべて一般的なサーバである。したがって、毎年多くのホストが保証対象外になるか、または破損する。ホストを交換し、新しいホスト上に分散整合性システムのサービスプログラムを再展開する必要がある。

【0062】

上述の任意選択の実施形態では、サーバ集合体Ｑｕｏｒｕｍ内のホストがクラッシュすると、サーバ集合体Ｑｕｏｒｕｍ内の利用可能な分散整合性システムのサービスプログラムの数は１つ減少する。したがって、サービスプログラムを新しいホスト上に展開する必要がある。

【0063】

サーバ集合体に３つのホストがあり、分散整合性システムのサービスプログラムが各ホスト上に展開されると仮定して、３つのホストの各々は、分散整合性システムに関して、例えば、１、２、および３であり得る固定のシリアル番号を有する。シリアル番号３のホストがクラッシュして交換する必要がある場合、シリアル番号４の新たに追加されたホスト、ならびにシリアル番号１および２の以前のホストは、分散整合性システムのプロトコルを修正することによって、分散整合性システムにサーバ集合体を形成すると判定され得る。

【0064】

なお、シリアル番号１および２の以前のホストは、シリアル番号４の新たに追加されたホストを認識していないため、シリアル番号４の新たに追加されたホストは、シリアル番号１および２の以前のホストとサーバ集合体を直接形成することはできない。したがって、ホストが交換されると、サービスプログラムは、１、２、および４を自律的に組み合わせて、新しいサーバ集合体を形成することができ、それによって、自律型ホスト交換サービスを真に実装することができることを保証する必要がある。

【0065】

任意選択の実施形態では、決定者モジュールは、動作タイプが分散整合性システム内の指定されたホストによって使用されるディスクを交換することである場合、分散整合性システムの外部サービスを停止し、分散整合性システム内の他のホストからログ情報およびスナップショットデータを取得し、ログ情報およびスナップショットデータを新たに追加されたディスクに記憶した後に外部サービスを再開するようにさらに構成されている。

【0066】

本出願の実施形態では、分散整合性システムは、ログ情報およびスナップショットデータを永続的かつトランザクション的に要求し得る。したがって、ホストディスクの読み取りおよび書き込み動作を関与させる必要がある。さらに、ホストディスクの故障率が高いため、分散整合性システムプログラムで、ディスクが破損しているか、保証外であることを示すＩＯ故障が頻繁に発生する。

【0067】

したがって、監視モジュールによって監視された障害ディスクに対するアラームが送信された後、動作・メンテナンス担当者は、動作・メンテナンス制御プラットフォームを使用してホストディスクを交換する要求を開始し、分散整合性システムの決定者モジュールに要求を送信する必要がある。動作・メンテナンス制御プラットフォームから送信されたホストディスクの交換要求を受信した後、決定者モジュールは、データセキュリティに関連する問題に対処する必要がある。例えば、分散整合性システムのログおよびスナップショットのディスク位置が／ｄｆｓ／ｄｉｓｋ１である場合、第１のディスクｄｉｓｋ１上にＩＯ障害が発生し、分散整合性システムの外部サービスが停止され、新たに追加された第２のディスクのディスク位置／ｄｆｓ／ｄｉｓｋ２においてデータが復元されると、分散整合性システムのサービスプログラムに対して、サービス低下が実行される。すべてのログ情報およびスナップショットデータは、サーバ集合体内の他のホストから取得され、データが復元された後、外部サービスが再開される。

【0068】

実施形態２
本出願の実施形態によれば、クラスタ管理方法の実施形態がさらに提供される。なお、添付の図面のフローチャートに示すステップは、例えば、コンピュータシステム内のコンピュータ実行可能命令のセットとして実行され得る。フローチャートには論理シーケンスが示されているが、いくつかの場合では、本明細書に示されたまたは説明されたステップは、異なるシーケンスで実行され得る。

【0069】

本出願の実施形態で提供される方法の実施形態は、モバイル端末、コンピュータ端末、または同様のコンピューティング装置で実行され得る。図３は、クラスタ管理方法を実施するためのコンピュータ端末（またはモバイルデバイス）のハードウェア構造のブロック図を示す。図３に示すように、コンピュータ端末１０（またはモバイルデバイス１０）は、１つ以上の（図には１０２ａ、１０２ｂ、・・・、１０２ｎとして示される）プロセッサ１０２（プロセッサ１０２は、ＭＣＵを含むマイクロプロセッサまたはＦＰＧＡを含むプログラマブル論理デバイスなどの処理装置を含み得るが、これらに限定されない）と、データを記憶するためのメモリ１０４と、通信のための送信モジュール１０６と、を含み得る。加えて、コンピュータ端末１０は、ディスプレイ、入力／出力インターフェース（Ｉ／Ｏインターフェース）、ユニバーサルシリアルバス（ＵＳＢ）ポート（Ｉ／Ｏインターフェースのポートの１つとして含まれ得る）、ネットワークインターフェース、電源、および／またはカメラをさらに含み得る。当業者は、図３に示す構造が例示的なものに過ぎず、上述の電子装置の構造を限定しないことを理解し得る。例えば、コンピュータ端末１０はまた、図３に示すものよりも多い、または少ない構成要素を含み得、または図３に示す構成とは異なる構成を有し得る。

【0070】

なお、上記の１つ以上のプロセッサ１０２および／または他のデータ処理回路は、本明細書では概して「データ処理回路」と呼ばれ得る。データ処理回路は、全体的に、または部分的に、ソフトウェア、ハードウェア、ファームウェア、または任意の他の組み合わせとして具現化され得る。加えて、データ処理回路は、スタンドアロン処理モジュールであってもよく、コンピュータ端末１０（またはモバイルデバイス）内の他の要素のいずれか１つに完全にまたは部分的に統合されていてもよい。本出願の実施形態に関与するように、データ処理回路は、プロセッサ制御（例えば、インターフェースに接続された可変抵抗器端子経路の選択）として機能し得る。

【0071】

メモリ１０４は、本出願の実施形態では、クラスタ管理に対応するプログラム命令／データ記憶装置などの、アプリケーションソフトウェアのソフトウェアプログラムおよびモジュールを記憶するように構成され得る。プロセッサ１０２は、メモリ１０４に記憶されたソフトウェアプログラムおよびモジュールを動作させて、様々な機能アプリケーションおよびデータ処理を実行し、すなわち、上述のクラスタ管理方法を実施する。メモリ１０４は、高速ランダムアクセスメモリを含み得、１つ以上の磁気記憶装置、フラッシュメモリ、または他の不揮発性固体メモリなどの不揮発性メモリも含み得る。いくつかの例では、メモリ１０４は、プロセッサ１０２に対してリモートに配設されたメモリをさらに含み得、これらのリモートメモリは、ネットワークを介してコンピュータ端末１０に接続され得る。上述のネットワークの例としては、インターネット、企業イントラネット、ローカルエリアネットワーク、モバイル通信ネットワーク、およびそれらの組み合わせが挙げられるが、これらに限定されない。

【0072】

送信装置１０６は、ネットワークを介してデータを受信または送信するように構成されている。上述のネットワークの具体例は、コンピュータ端末１０の通信プロバイダによって提供される無線ネットワークを含み得る。一例では、送信装置１０６は、インターネットとの通信が可能になるように、ベースステーションを通して他のネットワークデバイスに接続され得るネットワークアダプタ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃｏｎｔｒｏｌｌｅｒ（ＮＩＣ））を含む。一例では、送信装置１０６は、無線方式でインターネットと通信するために使用される無線周波数（ＲＦ）モジュールであってもよい。

【0073】

ディスプレイは、例えば、タッチスクリーン液晶ディスプレイ（ＬＣＤ）であってもよく、それにより、ユーザがコンピュータ端末１０（またはモバイルデバイス）のユーザインターフェースと対話することを可能にする。

【0074】

上述の動作環境下で、本出願は、図４に示すようなクラスタ管理方法を提供する。図４は、本出願の実施形態による、クラスタ管理方法のフローチャートである。図４に示すように、本方法は、以下のステップを含む。
ステップＳ４０２クラスタ内の分散整合性システムによって発行された動作要求を取得する。
ステップＳ４０４動作要求を処理するための決定情報を判定し、決定情報を動作・メンテナンス制御プラットフォームに送信する。決定情報は、分散整合性システムのデータ整合性および可用性に基づいて判定される。

【0075】

任意選択で、上述の動作・メンテナンス制御プラットフォーム（ＯＭＣＰ）は、動作・メンテナンスのための基本的な展開および統合プラットフォームである。動作・メンテナンス担当者は、動作・メンテナンス制御プラットフォームを使用して、クラスタ内のシステムに動作要求を発行することができる。上述の分散整合性システムの動作状態は、例えば、分散整合性システムが動作要求を実行した後に表示されたページのビューを動作・メンテナンス担当者に示すことによって、動作・メンテナンス制御プラットフォームを使用して動作・メンテナンス担当者にも示され得る。

【0076】

任意選択の実施形態では、上述の動作要求は、分散整合性システムのバージョンアップ、構成情報のアップグレード、またはサーバの再起動を要求するために使用され得る。

【0077】

なお、本出願の実施形態における上述の動作・メンテナンス制御プラットフォームはまた、動作・メンテナンス担当者に、クラスタ内の分散整合性システムの監視状態および各ステージのアップグレード状態をウェブページを通じて表示してもよい。

【0078】

任意選択の実施形態では、クラウドコンピューティングシナリオにおいて、分散整合性システム全体は、外部使用のためのユニットとしてクラスタを使用して展開されてもよく、管理次元と見なされてもよい。クラスタ内の分散整合性システムのサービスの自律性をより良く達成するために、本出願の実施形態では、クラスタの属性は、３つのタプル＜Ｃｌｕｓｔｅｒ，ＨｏｓｔＮａｍｅ，Ｓｅｒｖｅｒｒｏｌｅ＞に細かく分割することができ、それによって、クラスタを他のクラスタとより良く区別することができる。属性が分割された後、ついで、分散整合性システムを動作させるために、特定のＡＰＩインターフェースが設計されてもよい。その上、クラスタ内に配設されるホストの数および各ホスト上に展開されるサービスロールの数が、さらに判定されてもよい。

【0079】

上述の任意選択の実施形態では、決定者モジュールは、動作・メンテナンス制御プラットフォームによって提供されるＡＰＩインターフェースを使用して、動作・メンテナンス制御プラットフォームを定期的にポーリングする。任意選択で、ポーリング間隔は、分単位で設定され得る。さらに、動作・メンテナンス制御プラットフォームは、例えば、承認される必要がある現在の動作、承認されている動作、進行中の動作などを要求するための動作要求を決定者モジュールに返す。

【0080】

さらに、決定者モジュールは、動作・メンテナンス制御プラットフォームによって返された動作要求に従って、分散整合性システムのデータ整合性および可用性に基づいて、動作要求を処理するための決定情報を判定し、ＡＰＩインターフェースを介して、決定情報を動作・メンテナンス制御プラットフォームに返し、それによって、動作・メンテナンス制御プラットフォームは、決定情報に従って対応する処理を進めることができる。

【0081】

本出願の実施形態では、クラスタ内の分散整合性システムによって発行された動作要求が取得され、動作要求を処理するための決定情報が判定され、かつ動作・メンテナンス制御プラットフォームに送信され、決定情報は、分散整合性システムのデータ整合性および可用性に基づいて判定される。

【0082】

本出願の実施形態に基づいて、分散整合性システム内の決定者モジュールを通してサービスプログラムの可用性およびデータセキュリティを確保する目的が達成され、それによって、分散整合性システムのクラスタ管理効率を向上させ、分散整合性システムのデータ損失またはサービス中断を回避する技術的効果が達成され、これは、分散整合性システムのためのクラスタ管理方法で使用される手動操作のより高いエラー率によって引き起こされる、分散整合性システム内のデータ損失またはサービス中断の技術的問題を解決する。

【0083】

任意選択の実施形態では、本出願の実施形態による、任意選択のクラスタ管理方法のフローチャートを図５に示す。図５に示さすように、動作要求を処理するための決定情報を判定することは、以下のステップを含む。
ステップＳ５０２動作要求に対応する動作タイプを判定する。
ステップＳ５０４動作タイプに対応する動作を実行するための決定情報を判定し、決定情報は、分散整合性システムの可用性条件およびセキュリティ条件に基づいて判定される。

【0084】

任意選択で、動作タイプは、動作がどのホストに基づいているかを示すための特徴付けとして使用され得る。ここで、決定情報は、動作タイプに対応する動作を実行するための許可と、動作タイプに対応する動作を実行するためのキャンセルとのいずれかを含む。

【0085】

任意選択の実施形態では、動作タイプに対応する動作を実行するための決定情報を判定するステップは、動作タイプが分散整合性システムの構成情報をアップグレードしているときに、動作要求に対応する動作の実行が許可されていると判定することを含む。

【0086】

なお、分散整合性システムでは、いくつかの構成情報は、グローバル構成テンプレートによって管理されている。したがって、コードではなくいくつかの構成情報を修正する必要がある場合、グローバル構成テンプレート内のパラメータのみを修正する必要がある。ついで、分散整合性システムの構成情報が全体としてアップグレードされる。分散整合性システムは、構成情報の変更を学習し、新しい構成情報を取得する。

【0087】

任意選択の実施形態では、動作・メンテナンス担当者が、動作・メンテナンス制御プラットフォームを使用して、特定のクラスタ内の分散整合性システムの構成情報をアップグレードするための動作要求を開始する場合、分散整合性システムは、動作要求に対応する決定情報を取得し得る。分散整合性システムの構成情報がアップグレードされるシナリオについては、分散整合性システムのプロセスを再起動する必要はない。利用不可の時間をもたらさず、ディスク内のデータセキュリティに影響を与えないので、動作・メンテナンス制御プラットフォームによって提供されるＡＰＩインターフェースは、直接以下のように呼ばれ得る。ＳｅｔＭａｃｈｉｎｅＳＲＡｃｔｉｏｎＩｎｆｏＦｏｒ。そして、決定者モジュールは、動作要求に対応する動作の実行を許可する情報で直接応答することができ、それによって構成情報をアップグレードする動作を直接承認し得る。

【0088】

別の任意選択の実施形態では、動作タイプに対応する動作を実行するための決定情報を判定するステップは、動作タイプが分散整合性システム内のサービスをアップグレードすることである場合、アップグレードのためのクラスタから１つのホストを選択することと、アップグレードのためのクラスタから１つのホストを選択する前に、ホストがアップグレードされる以前の前のホストのサービスが可用性条件を満たすかどうかを判定することと、サービスが可用性条件を満たす場合、選択されたホストをアップグレードすることを判定することと、を含む。

【0089】

分散整合性システム内のサービスがアップグレードされると、分散整合性システムのサービス（すなわち、サービスプログラム）を再起動することができる。さらに、分散整合性システム内のサービスがアップグレードされると、分散整合性システムのサービスの利用不可の時間は一時的に影響を受けることになる。したがって、決定者モジュールが、動作・メンテナンス制御プラットフォームによって開始された、分散整合性システムのサービスをアップグレードするための動作要求を取得すると、ホストがアップグレードされる以前の前のホストのサービスが可用性条件、例えば、分散整合性システムのサーバ集合体Ｑｕｏｒｕｍにおけるサービス可用性を満たしているかどうかを判定する必要があり、サーバ集合体内で一度に１つのホスト内のサービスのみがアップグレードされるアップグレードシーケンスが採用される。さらに、ホストのサービスがアップグレードのために選択されるたびに、選択されたホストがアップグレードされる以前の前のホストのサービスが可用性条件を満たすことを保証する必要があり、サービスが可用性条件を満たすと、選択されたホストをアップグレードすることが判定される。

【0090】

本出願の実施形態では、任意選択で、動作タイプに対応する動作を実行するための決定情報を決定するステップは、動作タイプが分散整合性システムによって展開されるホストを交換することである場合、新たに追加されたホストのシリアル番号を取得することと、新たに追加されたホストのシリアル番号と、分散整合性システムにおいて交換されていないホストのシリアル番号との関連付けを確立して、新たな分散整合性システムを形成することと、を含む。

【0091】

クラウドコンピューティングのシナリオで使用されるサーバは、すべて一般的なサーバである。したがって、毎年多くのホストが保証対象外になるか、または破損する。ホストを交換し、新しいホスト上に分散整合性システムのサービスプログラムを再展開する必要がある。

【0092】

上述の任意選択の実施形態では、サーバ集合体内のホストがクラッシュすると、サーバ集合体内の利用可能な分散整合性システムのサービスプログラムの数は１つ減少する。したがって、サービスプログラムを新しいホスト上に展開する必要がある。

【0093】

サーバ集合体に３つのホストがあり、分散整合性システムのサービスプログラムが各ホスト上に展開されると仮定して、３つのホストの各々は、分散整合性システムに関して、例えば、１、２、および３であり得る固定のシリアル番号を有する。シリアル番号３のホストがクラッシュして交換する必要がある場合、シリアル番号４の新たに追加されたホスト、ならびにシリアル番号１および２の以前のホストは、分散整合性システムのプロトコルを修正することによって、分散整合性システムにサーバ集合体を形成すると判定され得る。

【0094】

なお、シリアル番号１および２の以前のホストは、シリアル番号４の新たに追加されたホストを認識していないため、シリアル番号４の新たに追加されたホストは、シリアル番号１および２の以前のホストとサーバ集合体を直接形成することはできない。したがって、ホストが交換されると、サービスプログラムは、１、２、および４を自律的に組み合わせて、新しいサーバ集合体を形成することができ、それによって、自律型ホスト交換サービスを真に実装することができることを保証する必要がある。

【0095】

本出願の実施形態にはさらに任意の実施形態が存在し、動作タイプに対応する動作を実行するための決定情報を判定するステップは、動作タイプが分散整合性システム内の指定されたホストによって使用されるディスクを交換することである場合、分散整合性システムの外部サービスを停止することと、分散整合性システム内の他のホストからログ情報およびスナップショットデータを取得することと、ログ情報およびスナップショットデータを新たに追加されたディスクに記憶した後に外部サービスを再開することと、を含む。

【0096】

本出願の実施形態では、分散整合性システムは、ログ情報およびスナップショットデータを永続的かつトランザクション的に要求し得る。したがって、ホストディスクの読み取りおよび書き込み動作を関与させる必要がある。さらに、ホストディスクの故障率が高いため、分散整合性システムプログラムで、ディスクが破損しているか、保証外であることを示すＩＯ故障が頻繁に発生する。

【0097】

したがって、監視モジュールによって監視された障害ディスクに対するアラームが送信された後、動作・メンテナンス担当者は、動作・メンテナンス制御プラットフォームを使用してホストディスクを交換する要求を開始し、分散整合性システムの決定者モジュールに要求を送信する必要がある。動作・メンテナンス制御プラットフォームから送信されたホストディスクの交換要求を受信した後、決定者モジュールは、データセキュリティに関連する問題に対処する必要がある。例えば、分散整合性システムのログおよびスナップショットのディスク位置が／ｄｆｓ／ｄｉｓｋ１である場合、第１のディスクｄｉｓｋ１上にＩＯ障害が発生し、分散整合性システムの外部サービスが停止され、新たに追加された第２のディスクのディスク位置／ｄｆｓ／ｄｉｓｋ２においてデータが復元されると、分散整合性システムのサービスプログラムに対して、サービス低下が実行される。すべてのログ情報およびスナップショットデータは、サーバ集合体内の他のホストから取得され、データが復元された後、外部サービスが再開される。

【0098】

なお、実施形態の任意選択または好ましい実施態様については、実施形態１の関連する説明が参照され得る。詳細は、ここでは再び述べない。

【0099】

なお、上記の方法の実施形態に関して、簡潔な説明を提供するために、方法の実施形態はすべて、一連の動作の組み合わせとして表される。しかしながら、いくつかのステップは別の順序で、または本出願に従って同時に実行され得るため、当業者は、本出願が、記載された一連の動作によって限定されないことを知るべきである。第二に、当業者は、明細書に記載の実施形態がすべて好ましい実施形態であり、関連する動作およびモジュールが必ずしも本出願によって必要とされるわけではないことも知るべきである。

【0100】

前述の実施形態の説明に基づいて、当業者は、前述の実施形態の方法が、ソフトウェアおよび必要とされるユニバーサルハードウェアプラットフォームを使用して実装され得、かつハードウェアを使用することによっても確実に実装され得ること、ただし、多くの場合、前者がより良い実装であることを明確に理解することができる。そのような理解に基づいて、本発明の技術的解決策のうち、必須であるか、または先行技術に寄与する部分は、ソフトウェア製品の形態で具現化され得る。コンピュータソフトウェア製品は、記憶媒体（ＲＯＭ／ＲＡＭ、磁気ディスク、および光ディスクなど）に記憶され、端末デバイス（携帯電話、コンピュータ、サーバ、ネットワークデバイスなどであり得る）が本発明の各実施形態の方法を実行することを可能にするためのいくつかの命令を含む。

【0101】

実施形態３
本出願の実施形態によれば、コンピュータシステムの実施形態がさらに提供され、コンピュータシステムは、プロセッサと、プロセッサに接続され、処理ステップを処理するための命令をプロセッサに提供するように構成されたメモリと、を備え、処理ステップは、クラスタ内の分散整合性システムによって発行された動作要求を取得するステップ、および動作要求を処理するための決定情報を判定し、動作・メンテナンス制御プラットフォームに決定情報を送信するステップであり、決定情報は、分散整合性システムのデータ整合性および可用性に基づいて判定される。

【0102】

本出願の実施形態では、クラスタ内の分散整合性システムによって発行された動作要求が取得され、動作要求を処理するための決定情報が判定され、かつ動作・メンテナンス制御プラットフォームに送信され、決定情報は、分散整合性システムのデータ整合性および可用性に基づいて判定される。

【0103】

本出願の実施形態に基づいて、分散整合性システム内の決定者モジュールを通してサービスプログラムの可用性およびデータセキュリティを確保する目的が達成され、それによって、分散整合性システムのクラスタ管理効率を向上させ、分散整合性システムのデータ損失またはサービス中断を回避する技術的効果が達成され、これは、分散整合性システムのためのクラスタ管理方法で使用される手動操作のより高いエラー率によって引き起こされる、分散整合性システム内のデータ損失またはサービス中断の技術的問題を解決する。

【0104】

なお、実施形態の任意選択または好ましい実施態様については、実施形態１および２の関連する説明が参照され得る。詳細は、ここでは再び述べない。

【0105】

実施形態４
本出願の実施形態によれば、上記のクラスタ管理方法を実装する装置の実施形態がさらに提供される。図６は、本出願の実施形態による、クラスタ管理装置の概略図である。図６に示すように、装置６００は、取得モジュール６０２と、処理モジュール６０４と、を備える。
取得モジュール６０２は、クラスタ内の分散整合性システムによって発行された動作要求を取得するように構成されており、処理モジュール６０４は、動作要求を処理するための決定情報を判定し、決定情報を動作・メンテナンス制御プラットフォームに送信するように構成されており、決定情報は、分散整合性システムのデータ整合性および可用性に基づいて判定される。

【0106】

なお、ここで、取得モジュール６０２および処理モジュール６０４は、実施形態２のステップＳ４０２～Ｓ４０４に対応する。２つのモジュールおよび対応するステップは、同じ例を実装し、同じ適用されたシナリオで使用されるが、２つのモジュールは、上記の実施形態２によって開示される内容に限定されるべきではない。なお、装置の一部として、上述のモジュールは、実施形態２において提供されるコンピュータ端末１０内で動作してもよい。

【0107】

なお、実施形態の任意選択または好ましい実施態様については、実施形態１および２の関連する説明が参照され得る。詳細は、ここでは再び述べない。

【0108】

実施形態５
本出願の実施形態によれば、コンピュータ端末の実施形態がさらに提供される。コンピュータ端末は、コンピュータ端末グループ内の任意のコンピュータ端末デバイスであってもよい。任意選択で、本実施形態では、コンピュータ端末はまた、モバイル端末などの端末デバイスに置き換えられ得る。

【0109】

任意選択で、本実施形態では、コンピュータ端末は、コンピュータネットワーク内の複数のネットワークデバイスのうちの少なくとも１つに配設されてもよい。

【0110】

本実施形態では、コンピュータ端末は、クラスタ管理方法における、クラスタ内の分散整合性システムによって発行された動作要求を取得するステップ、および動作要求を処理するための決定情報を判定し、決定情報を動作・メンテナンス制御プラットフォームに送信するステップのプログラムコードを実行し得、決定情報は、分散整合性システムのデータ整合性および可用性に基づいて判定される。

【0111】

任意選択で、図７は、本出願の実施形態による、コンピュータ端末の構造ブロック図である。図７に示すように、コンピュータ端末７００は、１つ以上（図では１つのみ図示）のプロセッサ７０２と、メモリ７０４と、周辺インターフェース７０６と、を含み得る。

【0112】

メモリは、本出願の実施形態では、クラスタ管理方法および装置に対応するプログラム命令／モジュールなどのソフトウェアプログラムおよびモジュールを記憶するように構成され得る。プロセッサは、メモリに記憶されたソフトウェアプログラムおよびモジュールを動作させて、様々な機能アプリケーションおよびデータ処理を実行し、すなわち、上述のクラスタ管理方法を実施する。メモリは、高速ランダムアクセスメモリを含み得、１つ以上の磁気記憶装置、フラッシュメモリ、または他の不揮発性固体メモリなどの不揮発性メモリも含み得る。いくつかの例では、メモリは、プロセッサに対してリモートに配設されたメモリをさらに含み得、これらのリモートメモリは、ネットワークを介してコンピュータ端末に接続され得る。上述のネットワークの例としては、インターネット、企業イントラネット、ローカルエリアネットワーク、モバイル通信ネットワーク、およびそれらの組み合わせが挙げられるが、これらに限定されない。

【0113】

プロセッサは、送信装置を介してメモリに記憶された情報およびアプリケーションプログラムを呼び出して、クラスタ内の分散整合性システムによって発行された動作要求を取得するステップと、動作要求を処理するための決定情報を判定し、決定情報を動作・メンテナンス制御プラットフォームに送信するステップと、を実行することができ、決定情報は、分散整合性システムのデータ整合性および可用性に基づいて判定される。

【0114】

任意選択で、プロセッサは、動作要求に対応する動作タイプを判定するステップ、および動作タイプに対応する動作を実行するための決定情報を判定するステップのプログラムコードをさらに実行することができ、決定情報は、分散整合性システムの可用性条件およびセキュリティ条件に基づいて判定される。

【0115】

任意選択で、プロセッサは、動作タイプが分散整合性システムの構成情報をアップグレードすることである場合、動作要求に対応する動作の実行が許可されていることを判定するステップのプログラムコードをさらに実行することができる。

【0116】

任意選択で、プロセッサは、動作タイプが分散整合性システム内のサービスをアップグレードすることである場合、アップグレードのためのクラスタから１つのホストを選択するステップ、アップグレードのためのクラスタから１つのホストを選択する前に、ホストがアップグレードされる以前の前のホストのサービスが可用性条件を満たすかどうかを判定するステップ、およびサービスが可用性条件を満たす場合、選択されたホストをアップグレードすることを判定するステップのプログラムコードをさらに実行することができる。

【0117】

任意選択で、プロセッサは、動作タイプが分散整合性システムによって展開されるホストを交換することである場合、新たに追加されたホストのシリアル番号を取得するステップ、および新たに追加されたホストのシリアル番号と、分散整合性システムにおいて交換されていないホストのシリアル番号との関連付けを確立して、新たな分散整合性システムを形成するステップのプログラムコードをさらに実行することができる。

【0118】

任意選択で、プロセッサは、動作タイプが分散整合性システム内の指定されたホストによって使用されるディスクを交換することである場合、分散整合性システムの外部サービスを停止するステップ、分散整合性システム内の他のホストからログ情報およびスナップショットデータを取得するステップ、ならびにログ情報およびスナップショットデータを新たに追加されたディスクに記憶した後に外部サービスを再開するステップのプログラムコードをさらに実行することができる。

【0119】

本出願の実施形態が使用される場合、クラスタ管理ソリューションが提供される。本実施形態では、クラスタ管理ソリューションは、クラスタ内の分散整合性システムによって発行された動作要求を取得することと、動作要求を処理するための決定情報を判定し、決定情報を動作・メンテナンス制御プラットフォームに送信することと、を含み、決定情報は、分散整合性システムのデータ整合性および可用性に基づいて判定される。

【0120】

本出願の実施形態に基づいて、分散整合性システム内の決定者モジュールを通してサービスプログラムの可用性およびデータセキュリティを確保する目的が達成され、それによって、分散整合性システムのクラスタ管理効率を向上させ、分散整合性システムのデータ損失またはサービス中断を回避する技術的効果が達成され、これは、分散整合性システムのためのクラスタ管理方法で使用される手動操作のより高いエラー率によって引き起こされる、分散整合性システム内のデータ損失またはサービス中断の技術的問題を解決する。

【0121】

当業者は、図７に示す構造が例示的であることを理解し得、コンピュータ端末はまた、スマートフォン（アンドロイド（登録商標）電話およびｉＯＳ電話など）、タブレットコンピュータ、パームコンピュータ、およびモバイルインターネットデバイス（ＭＩＤ）、ＰＡＤ、および他の端末デバイスであってもよい。図７は、上記電子デバイスの構造を制限しない。例えば、コンピュータ端末７００はまた、図７に示すものよりも多いまたは少ない構成要素（ネットワークインターフェース、表示装置など）を含み得、または図７に示す構成とは異なる構成を有し得る。

【0122】

当業者は、上述の実施形態の様々な方法におけるステップのすべてまたは一部が、プログラムを通じて端末デバイスの関連するハードウェアに指示することによって完了され得ることを理解し得る。プログラムは、フラッシュディスク、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク、光ディスクなどを含み得るコンピュータ可読記憶媒体に記憶され得る。

【0123】

実施形態６
本出願の実施形態によれば、記憶媒体の実施形態がさらに提供される。任意選択で、本実施形態では、記憶媒体は、上記の実施形態２において提供されたクラスタ管理方法によって実行されたプログラムコードを記憶するように構成され得る。

【0124】

任意選択で、本実施形態では、記憶媒体は、コンピュータネットワーク内のコンピュータ端末グループの任意のコンピュータ端末に位置してもよく、またはモバイル端末グループの任意のモバイル端末に位置してもよい。

【0125】

任意選択で、本実施形態では、記憶媒体は、クラスタ内の分散整合性システムによって発行された動作要求を取得するステップ、および動作要求を処理するための決定情報を判定し、決定情報を動作・メンテナンス制御プラットフォームに送信するステップを実行するためのプログラムコードを記憶するように構成されており、決定情報は、分散整合性システムのデータ整合性および可用性に基づいて判定される。

【0126】

任意選択で、本実施形態では、動作要求に対応する動作タイプを判定するステップ、および動作タイプに対応する動作を実行するための決定情報を判定するステップを実行するためのプログラムコードを記憶するように構成されており、決定情報は、分散整合性システムの可用性条件およびセキュリティ条件に基づいて判定される。

【0127】

任意選択で、本実施形態では、動作タイプが分散整合性システムの構成情報をアップグレードすることである場合、動作要求に対応する動作の実行が許可されていることを判定するステップを実行するためのプログラムコードを記憶するように構成されている。

【0128】

任意選択で、本実施形態では、記憶媒体は、動作タイプが分散整合性システム内のサービスをアップグレードすることである場合、アップグレードのためのクラスタから１つのホストを選択するステップ、アップグレードのためのクラスタから１つのホストを選択する前に、ホストがアップグレードされる以前の前のホストのサービスが可用性条件を満たすかどうかを判定するステップ、およびサービスが可用性条件を満たす場合、選択されたホストをアップグレードすることを判定するステップを実行するためのプログラムコードを記憶するように構成されている。

【0129】

任意選択で、本実施形態では、記憶媒体は、動作タイプが分散整合性システムによって展開されるホストを交換することである場合、新たに追加されたホストのシリアル番号を取得するステップ、および新たに追加されたホストのシリアル番号と、分散整合性システムにおいて交換されていないホストのシリアル番号との関連付けを確立して、新たな分散整合性システムを形成するステップを実行するためのプログラムコードを記憶するように構成されている。

【0130】

任意選択で、本実施形態では、動作タイプが分散整合性システム内の指定されたホストによって使用されるディスクを交換することである場合、分散整合性システムの外部サービスを停止するステップ、分散整合性システム内の他のホストからログ情報およびスナップショットデータを取得するステップ、ならびにログ情報およびスナップショットデータを新たに追加されたディスクに記憶した後に外部サービスを再開するステップを実行するためのプログラムコードを記憶するように構成されている。

【0131】

本出願の実施形態のシリアル番号は、説明のためだけのものであり、実施形態の品質を表すものではない。

【0132】

本出願の上記の実施形態では、各実施形態の説明は、独自の強調を有する。一実施形態において詳細に記載されていない任意の部分に関して、他の実施形態において関連する説明を参照してもよい。

【0133】

本出願によって提供されるいくつかの実施形態では、開示される技術内容は、他の方法で実装され得ることを理解されたい。上記の装置の実施形態は、例示のためのみのものである。例えば、ユニットの分割は単なる論理的な機能分割である。実際の実装では、他の分割手段があり得る。例えば、複数のユニットまたは構成要素を組み合わせてもよく、別のシステムに統合されてもよく、またはいくつかの特徴を無視もしくは未実装のままにしてもよい。さらに、表示もしくは考察された相互結合、直接結合、または通信接続は、いくつかのインターフェースを通じて達成され得る。ユニットまたはモジュールの間接結合または通信接続は、電気的または他の形態であり得る。

【0134】

別個の構成要素として記載されるユニットは、物理的に分離されても、分離されなくてもよい。ユニットとして表示される構成要素は、物理ユニットであってもなくてもよく、すなわち、それらは１つの場所に位置してもよく、または複数のネットワークユニット上に分散されてもよい。ユニットの一部またはすべては、実施形態の解決策の目的を達成するための実際のニーズに応じて選択されてもよい。

【0135】

加えて、本出願の各実施形態における様々な機能ユニットは、１つの処理ユニットに統合されてもよく、または各ユニットは、個別におよび物理的に存在してもよく、または２つ以上のユニットが１つのユニットに統合されてもよい。上述の統合ユニットは、ハードウェアの形態で実装されてもよく、またはソフトウェア機能ユニットとして実装されてもよい。

【0136】

統合ユニットがソフトウェア機能ユニットの形態で実装され、独立した製品として販売または使用される場合、それらは、コンピュータ可読記憶媒体に記憶され得る。そのような理解に基づいて、本発明の技術的解決策のうちのすべて、または必須であるか、もしくは先行技術に寄与する部分は、ソフトウェア製品の形態で具現化され得る。コンピュータソフトウェア製品は、記憶媒体に記憶され、コンピュータデバイス（パーソナルコンピュータ、サーバ、ネットワークデバイスなどであり得る）が、本出願の各実施形態で説明される方法のステップのすべてまたは一部を実行することを可能にするためのいくつかの命令を含む。上記記憶媒体は、ＵＳＢフラッシュディスク、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、モバイルハードディスク、磁気ディスク、光ディスク、またはプログラムコードを記憶し得る他の媒体を含む。

【0137】

上述の実施形態は、本出願の単なる好ましい実施形態である。当業者には、本出願の原理から逸脱することなく、いくつかの改善および修正が行われ得ることに留意されたい。これらの改善および修正もまた、本出願の保護範囲内にあると見なされるべきである。

【符号の説明】

【0138】

１０ コンピュータ端末
１００ クラスタ管理システム
１０１ 動作・メンテナンス制御プラットフォーム
１０２ プロセッサ
１０３ 決定者モジュール
１０４ メモリ
１０５ 監視モジュール
１０６ 送信装置
１０７ 監視プラットフォーム
６００ 装置
６０２ 取得モジュール
６０４ 処理モジュール
７００ コンピュータ端末
７０２ プロセッサ
７０４ メモリ
７０６ 周辺インターフェース

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】