(57)【要約】【課題】寿命予測モデル及び７日以内の故障率モデルにより、寿命を予測して７日以内に記憶装置が故障する確率を決定するクラウドベースサービスのデータ保護方法を提供する。【解決手段】クラウドベースサービスのデータ保護方法は、クラウドベースサービスシステム中の記憶装置の履歴稼働データを収集するステップ（Ｓ０１）と、前記収集した稼働データにより寿命予測モデル及び７日以内の故障率モデルを構築するステップ（Ｓ０２）と、各前記記憶装置が過去２４時間の前記稼働データを前記寿命予測モデル及び前記７日以内の故障率モデルに入力し、各組中の予測寿命範囲及び対応した故障率を得るステップ（Ｓ０３）と、前記ステップ（Ｓ０３）の結果に基づき、前記記憶装置中のデータをバックアップするステップ（Ｓ０４）とを含む。【選択図】図２
2019053474.tif 000002
【特許請求の範囲】
【請求項１】
クラウドベースサービスシステム中の記憶装置の履歴稼働データを収集するステップ（Ａ）と、
前記収集した稼働データにより寿命予測モデル及び７日以内の故障率モデルを構築するステップ（Ｂ）と、
各前記記憶装置が過去２４時間の前記稼働データを前記寿命予測モデル及び前記７日以内の故障率モデルに入力し、各組中の予測寿命範囲及び対応した故障率を得るステップ（Ｃ）と、
前記ステップ（Ｃ）の結果に基づき、前記記憶装置中のデータをバックアップするステップ（Ｄ）と、を含むことを特徴とする、
クラウドベースサービスのデータ保護方法。
【請求項２】
前記稼働データは、性能データ、ＳＭＡＲＴ（Ｓｅｌｆ−Ｍｏｎｉｔｏｒｉｎｇ  Ａｎａｌｙｓｉｓ  ａｎｄ  Ｒｅｐｏｒｔｉｎｇ  Ｔｅｃｈｎｏｌｏｇｙ）データ、前記記憶装置の使用可能容量、前記記憶装置の総容量又は装置メタデータであることを特徴とする請求項１に記載のクラウドベースサービスのデータ保護方法。
【請求項３】
前記性能データは、レイテンシ、処理量、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）負荷、メモリ使用量又はＩＯＰＳ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ  Ｐｅｒ  Ｓｅｃｏｎｄ）であることを特徴とする請求項２に記載のクラウドベースサービスのデータ保護方法。
【請求項４】
前記記憶装置は、ハードディスク又はソリッド・ステート・ディスクであることを特徴とする請求項１に記載のクラウドベースサービスのデータ保護方法。
【請求項５】
前記寿命予測モデル及び前記７日以内の故障率モデルは、将来新たに収集する前記稼働データにより継続的に更新されることを特徴とする請求項１に記載のクラウドベースサービスのデータ保護方法。
【請求項６】
前記記憶装置の前記履歴稼働データを収集する時間間隔は１時間であることを特徴とする請求項１に記載のクラウドベースサービスのデータ保護方法。
【請求項７】
前記寿命予測モデルは、故障していない前記記憶装置と故障した前記記憶装置とに区分するステップ（Ｂ１）と、前記寿命範囲を前記故障した記憶装置に類別し、前記故障していない記憶装置の全てを特定の寿命範囲に設定するステップ（Ｂ２）と、前記寿命範囲に基づき、前記記憶装置の前記稼働データを複数組中に分級（ｂｉｎｎｉｎｇ）するステップ（Ｂ３）と、全ての組に対し、各前記記憶装置からの前記稼働データを正常化させるステップ（Ｂ４）と、により構築されることを特徴とする請求項１に記載のクラウドベースサービスのデータ保護方法。
【請求項８】
前記寿命予測モデルは、前記寿命範囲に基づき、前記記憶装置の前記稼働データを複数組に分級させるステップ（Ｂ３’）と、全組に対し、各前記記憶装置からの前記稼働データを正常化させるステップ（Ｂ４’）と、により操作されることを特徴とする請求項１に記載のクラウドベースサービスのデータ保護方法。
【請求項９】
前記７日以内の故障率モデルは、前記稼働データをソートするステップ（Ｂ５）と、故障した記憶装置と、ランダムに取得した故障していない複数の記憶装置と、に対し、最後に収集した時点から起算して７日以内の前記記憶装置の前記稼働データを得るステップ（Ｂ６）と、各前記記憶装置からの前記稼働データを正常化させるステップ（Ｂ７）と、により構築されることを特徴とする請求項１に記載のクラウドベースサービスのデータ保護方法。
【請求項１０】
最後に収集した時点から７日以内に収集した前記稼働データの前記故障した記憶装置と、前記故障していない記憶装置との比率は１：１であることを特徴とする請求項９に記載のクラウドベースサービスのデータ保護方法。
【請求項１１】
全く新しいか、加えられたばかりの前記クラウドベースサービスシステムである前記記憶装置の前記履歴稼働データを収集するステップ（Ａ１）をさらに含むことを特徴とする請求項１に記載のクラウドベースサービスのデータ保護方法。
【請求項１２】
前記寿命予測モデルは、ＡＮＮ（Ａｒｔｉｆｉｃｉａｌ  Ｎｅｕｒａｌ  Ｎｅｔｗｏｒｋ）アルゴリズムにより、入力された過去２４時間の前記稼働データと、前記履歴稼働データとにより前記予測寿命範囲を予測することを特徴とする請求項１に記載のクラウドベースサービスのデータ保護方法。
【請求項１３】
前記７日以内の故障率モデルは、ＡＮＮアルゴリズムにより、入力された過去２４時間の前記稼働データ及び前記履歴稼働データを計算し、対応する故障率を予測することを特徴とする請求項１に記載のクラウドベースサービスのデータ保護方法。
【請求項１４】
前記ステップ（Ｄ）において、特定の寿命より短い予測寿命を有する、及び／又は、特定のパーセンテージを超えた故障率を有する前記記憶装置中のデータをバックアップすることを特徴とする請求項１に記載のクラウドベースサービスのデータ保護方法。
【請求項１５】
前記ステップ（Ｄ）において、計算により得られたスナップショット時間間隔でスナップショット作業を行い、前記記憶装置中のデータをバックアップすることを特徴とする請求項１に記載のクラウドベースサービスのデータ保護方法。
【請求項１６】
前記スナップショット時間間隔は、前記ステップ（Ｃ）の結果をファジィシステム中に入力し、算出することを特徴とする請求項１５記載のクラウドベースサービスのデータ保護方法。
【請求項１７】
前記ファジィシステムは、複数の分級（ｂｉｎ）、故障率及びスナップショット時間間隔の言語値を定義するステップ（Ｅ１）と、メンバシップ関数を構築し、全ての前記分級、前記故障率及び前記スナップショット時間間隔の程度を描くステップ（Ｅ２）と、前記分級、前記故障率及び前記スナップショット時間間隔によりファジィルールを構築するステップ（Ｅ３）と、により形成されることを特徴とする請求項１６に記載のクラウドベースサービスのデータ保護方法。
【請求項１８】
前記ファジィシステムは、前記分級及び前記故障率を受け取るステップ（Ｆ１）と、前記ファジィルールの前記メンバシップ関数に前記分級及び前記故障率を入力し、ファジィ化、ファジィ推論及び結果集約を行うステップ（Ｆ２）と、非ファジィ化を行って前記スナップショット時間間隔を得るステップ（Ｆ３）と、の操作を含むことを特徴とする請求項１７に記載のクラウドベースサービスのデータ保護方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データの保護方法に関し、特に、クラウドベースサービスのデータ保護方法に関する。
【背景技術】
【０００２】
Ｍｏｎｇｏ（登録商標）ＤＢなどの作業負担は、ノードクラスタを有するクラウドベースサービスシステムで操作される。この作業負担は、クラウドベースサービスの単一のノード又は複数のノード上で作動し、各ノードには、少なくとも１つの磁気ディスクが割り当てられ、アクセスするデータが記憶される。単一のノードの作業の作業負担において、割り当てられた磁気ディスクが故障すると、バックアップされたデータをリストアする前は実行できなかった。
複数のノードの作業の作業負担にとって、そのうち一つの割り当てられた磁気ディスクが故障するか、全ノードが故障してしまった場合、データを新たなノードへ移す必要があるため、クラウドベースサービスの性能が低下し、作業負担の性能にも悪影響を与える虞があった。クラウドベースサービス中の磁気ディスクの健康状態と、データのリストアの計画的なアーカイブとは、作業負担のデータを保護するためにとても大切な要素であった。
【０００３】
上述したニーズの解決手段として現在多くの技術がある。それら解決手段の多くは、記憶装置の寿命の予測に関する。例えば、記憶装置の寿命を予測する従来の方法は、操作習慣情報及び対応した操作寿命値をそれぞれ含む複数の訓練データを記録するデータベースを設定するステップと、対応した記憶装置から操作習慣情報を取得するステップと、操作習慣情報及び対応した訓練データの操作寿命値に基づき、記憶装置の寿命予測モデルを構築するステップと、記憶装置の寿命予測モデルに記憶装置の操作習慣情報を入力するステップと、個別の記憶装置に予測寿命値を生成するステップと、を含む。記憶装置の寿命予測モデルは、予測寿命値を使用して構築してもよい。記憶装置中の第１の記憶装置が故障したときに、第１の記憶装置の実際の寿命を記憶し、記憶装置の寿命予測モデルを構築する。
【０００４】
従来様々な方法により、記憶装置の寿命を予測してデータを保護し、予測結果に基づいて実行していたが、応用する際、依然として様々な問題点があった。
まず、記憶装置（ハードディスク又はソリッド・ステート・ディスク）が故障する確率は、記憶装置が使用寿命の終点に近づくにつれて急速に高まった。しかし、前述したような方法では、操作寿命値の訓練データにのみ頼り、使用寿命の終点前に記憶装置が突然故障することを予測することは困難であった。
第２に、記憶装置の故障は、作業負担の結果であり、つまり、作業負担の使用ニーズの高まりにより、記憶装置の寿命が短くなるが、作業負担の影響は、従来の方法では考慮されない。また、データ保護には、記憶装置中に記憶したデータのバックアップの適切な計画が含まれてもよいが、データのバックアップを頻繁に行うと、関連する作業負担の性能が低下する虞がある。これとは反対に、作業負担の系統的な崩壊が発生する虞もあった。そのため、記憶装置の寿命を予測することができれば、問題を解決することができる。
【０００５】
上述したような問題点を改善するために、本発明のクラウドベースサービスのデータ保護方法は、磁気ディスクが使用寿命の終点近くなったときの故障確率である「故障確率」の概念を導入した。そのため、本発明は、磁気ディスクが故障する可能性が高い時間点を正確に予測することができ、クラウドベースサービスのデータを保護することができる。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明の主な目的は、寿命予測モデル及び７日以内の故障率モデルにより、寿命を予測して７日以内に記憶装置が故障する確率を決定するクラウドベースサービスのデータ保護方法を提供することにある。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明の第１の形態によれば、クラウドベースサービスシステム中の記憶装置の履歴稼働データを収集するステップ（Ａ）と、前記収集した稼働データにより寿命予測モデル及び７日以内の故障率モデルを構築するステップ（Ｂ）と、各前記記憶装置が過去２４時間の前記稼働データを前記寿命予測モデル及び前記７日以内の故障率モデルに入力し、各組中の予測寿命範囲及び対応した故障率を得るステップ（Ｃ）と、前記ステップ（Ｃ）の結果に基づき、前記記憶装置中のデータをバックアップするステップ（Ｄ）と、を含むことを特徴とするクラウドベースサービスのデータ保護方法が提供される。
【０００８】
前記稼働データは、性能データ、ＳＭＡＲＴ（Ｓｅｌｆ−Ｍｏｎｉｔｏｒｉｎｇ  Ａｎａｌｙｓｉｓ  ａｎｄ  Ｒｅｐｏｒｔｉｎｇ  Ｔｅｃｈｎｏｌｏｇｙ）データ、前記記憶装置の使用可能容量、前記記憶装置の総容量又は装置メタデータであることが好ましい。
【０００９】
前記性能データは、レイテンシ、処理量、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）負荷、メモリ使用量又はＩＯＰＳ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ  Ｐｅｒ  Ｓｅｃｏｎｄ）であることが好ましい。
【００１０】
前記記憶装置は、ハードディスク又はソリッド・ステート・ディスクであることが好ましい。
【００１１】
前記寿命予測モデル及び前記７日以内の故障率モデルは、将来新たに収集する前記稼働データにより継続的に更新されることが好ましい。
【００１２】
前記記憶装置の前記履歴稼働データを収集する時間間隔は１時間であることが好ましい。
【００１３】
前記寿命予測モデルは、故障していない前記記憶装置と故障した前記記憶装置とに区分するステップ（Ｂ１）と、前記寿命範囲を前記故障した記憶装置に類別し、前記故障していない記憶装置の全てを特定の寿命範囲に設定するステップ（Ｂ２）と、前記寿命範囲に基づき、前記記憶装置の前記稼働データを複数組中に分級（ｂｉｎｎｉｎｇ）するステップ（Ｂ３）と、全ての組に対し、各前記記憶装置からの前記稼働データを正常化させるステップ（Ｂ４）と、により構築されることが好ましい。
【００１４】
前記寿命予測モデルは、前記寿命範囲に基づき、前記記憶装置の前記稼働データを複数組に分級させるステップ（Ｂ３’）と、全組に対し、各前記記憶装置からの前記稼働データを正常化させるステップ（Ｂ４’）と、により操作されることが好ましい。
【００１５】
前記７日以内の故障率モデルは、前記稼働データをソートするステップ（Ｂ５）と、故障した記憶装置と、ランダムに取得した故障していない複数の記憶装置と、に対し、最後に収集した時点から起算して７日以内の前記記憶装置の前記稼働データを得るステップ（Ｂ６）と、各前記記憶装置からの前記稼働データを正常化させるステップ（Ｂ７）と、により構築されることが好ましい。
【００１６】
最後に収集した時点から７日以内に収集した前記稼働データの前記故障した記憶装置と、前記故障していない記憶装置との比率は１：１であることが好ましい。
【００１７】
全く新しいか、加えられたばかりの前記クラウドベースサービスシステムである前記記憶装置の前記履歴稼働データを収集するステップ（Ａ１）をさらに含むことが好ましい。
【００１８】
前記寿命予測モデルは、ＡＮＮ（Ａｒｔｉｆｉｃｉａｌ  Ｎｅｕｒａｌ  Ｎｅｔｗｏｒｋ）アルゴリズムにより、入力された過去２４時間の前記稼働データと、前記履歴稼働データとにより前記予測寿命範囲を予測することが好ましい。
【００１９】
前記７日以内の故障率モデルは、ＡＮＮアルゴリズムにより、入力された過去２４時間の前記稼働データ及び前記履歴稼働データを計算し、対応する故障率を予測することが好ましい。
【００２０】
前記ステップ（Ｄ）において、特定の寿命より短い予測寿命を有する、及び／又は、特定のパーセンテージを超えた故障率を有する前記記憶装置中のデータをバックアップすることが好ましい。
【００２１】
前記ステップ（Ｄ）において、計算により得られたスナップショット時間間隔でスナップショット作業を行い、前記記憶装置中のデータをバックアップすることが好ましい。
【００２２】
前記スナップショット時間間隔は、前記ステップ（Ｃ）の結果をファジィシステム中に入力し、算出することが好ましい。
【００２３】
前記ファジィシステムは、複数の分級（ｂｉｎ）、故障率及びスナップショット時間間隔の言語値を定義するステップ（Ｅ１）と、メンバシップ関数を構築し、全ての前記分級、前記故障率及び前記スナップショット時間間隔の程度を描くステップ（Ｅ２）と、前記分級、前記故障率及び前記スナップショット時間間隔によりファジィルールを構築するステップ（Ｅ３）と、により形成されることが好ましい。
【００２４】
前記ファジィシステムは、前記分級及び前記故障率を受け取るステップ（Ｆ１）と、前記ファジィルールの前記メンバシップ関数に前記分級及び前記故障率を入力し、ファジィ化、ファジィ推論及び結果集約を行うステップ（Ｆ２）と、非ファジィ化を行って前記スナップショット時間間隔を得るステップ（Ｆ３）と、の操作を含むことが好ましい。
【発明の効果】
【００２５】
本発明のクラウドベースサービスのデータ保護方法は、寿命予測モデル及び７日以内の故障率モデルにより、寿命を予測して７日以内に記憶装置が故障する確率を決定し、これらの結果を得た後、データのバックアップ（スナップショット作業）のスケジュールを決定することで、従来技術の問題点を改善することができる。
【図面の簡単な説明】
【００２６】
【図１】本発明の一実施形態に係るクラウドベースサービスのデータ保護方法を応用する典型的なクラウドベースサービスシステムを示すブロック図である。
【図２】本発明の一実施形態に係るクラウドベースサービスシステム中のデータを保護する方法を示す流れ図である。
【図３】寿命予測モデルを構築するワークフローである。
【図４】７日以内の故障率モデルを構築するワークフローである。
【図５】寿命予測モデル及び７日以内の故障率モデルの入力及び出力を示すテーブルである。
【図６】ファジィシステムを形成する方法を示す流れ図である。
【図７】分級、故障率、スナップショット時間間隔の言語値及びファジィルールを示す。
【図８】本発明の一実施形態に係るファジィシステムを示すメンバシップ関数である。
【図９】本発明の一実施形態に係るファジィシステムを示すメンバシップ関数である。
【図１０】本発明の一実施形態に係るファジィシステムを示すメンバシップ関数である。
【発明を実施するための形態】
【００２７】
以下、本発明の実施形態について図に基づいて説明する。なお、これによって本発明が限定されるものではない。
【００２８】
本発明の一実施形態に係るクラウドベースサービスのデータ保護方法は、電子メールサービス、ビデオストリーミング、ＥＲＰシステムなどの作業負担のアーキテクチャに応用することができる。本方法が応用する典型的なクラウドベースサービスシステム１０を図１に示す。
クラウドベースサービスシステム１０は、サーバ（ホスト）１００及び複数の記憶装置２００を含む。サーバ１００は、中央処理装置１０１、記憶装置入出力ユニット１０２、データベース１０３及びネットワーク入出力ユニット１０４を基本的に有する。中央処理装置１０１は、クラウドベースサービスシステム１０の操作と、その上で稼働する作業負担とを管理する。それとともに、中央処理装置１０１は、記憶装置入出力ユニット１０２を介して記憶装置２００からの稼働データ及びネットワーク入出力ユニット１０４からの稼働データを追跡・記録することができる。記憶装置入出力ユニット１０２は、クラウドベースサービスシステム１０の工業規格の如何なるハードウェアにも応用でき、内部データを転送する。この工業規格は、ペリフェラルコンポーネントインターコネクトエクスプレス（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ  Ｅｘｐｒｅｓｓ：ＰＣＩ  Ｅｘｐｒｅｓｓ）、ＩＤＥ（Ｉｎｔｅｇｒａｔｅｄ  Ｄｅｖｉｃｅ  Ｅｌｅｃｔｒｏｎｉｃｓ）、ＳＡＴＡ（Ｓｅｒｉａｌ  Ａｄｖａｎｃｅｄ  Ｔｅｃｈｎｏｌｏｇｙ  Ａｔｔａｃｈｍｅｎｔ）又はユニバーサルシリアルバス（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ：ＵＳＢ）でもよい。
ネットワーク入出力ユニット１０４は、外部クライアント装置（例えば、パーソナルコンピュータ、タブレットコンピュータ、スマートフォンなど）に無線接続又は有線接続するハードウェアである。ネットワーク入出力ユニット１０４は、ＵＳＢポート、ＲＪ４５ポート、光ファイバケーブル、Ｗｉ−Ｆｉ（登録商標）モジュール又はブルートゥース（登録商標）モジュールでもよい。データベース１０３とは、ハードディスク、ソリッド・ステート・ディスク又はサーバ１００のＤＲＡＭ中の恒久的又は一時的に構築したデータベース又は構造データを指し、直接的に作業負担にアクセスさせず、本発明の応用に有利である。
本実施形態は、Ｎ個の記憶装置２００（第１の記憶装置２００（１）、第２の記憶装置２００（２）、第３の記憶装置３００（３）…及び第Ｎの記憶装置２００（Ｎ））を有する。
【００２９】
稼働データは、性能データ、ＳＭＡＲＴ（Ｓｅｌｆ−Ｍｏｎｉｔｏｒｉｎｇ  Ａｎａｌｙｓｉｓ  ａｎｄ  Ｒｅｐｏｒｔｉｎｇ  Ｔｅｃｈｎｏｌｏｇｙ）データ、記憶装置２００の使用可能容量、記憶装置２００の総容量又は装置のメタデータでもよい。これら性能データは、作業負担を実行するクラウドベースサービスシステム１０の稼働の物理情報である。例えば、性能データは、レイテンシ、処理量、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）負荷、メモリ使用量又はＩＯＰＳ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ  Ｐｅｒ  Ｓｅｃｏｎｄ）でもよい。それらは、記憶装置２００に接続された記憶装置入出力ユニット１０２、外部クライアント装置に接続されたネットワーク入出力ユニット１０４、又は中央処理装置１０１を介してデータフローから直接来る。
ＳＡＭＲＴデータを使用して、シリアルコード（数字）により発生し得る駆動器の故障を示す。これは、各記憶装置２００にインストールした監視ソフトウェアにより得られる。ＳＭＡＲＴの定義に依り、記憶装置２００はハードディスク又はソリッド・ステート・ディスクでもよい。クラウドベースサービスシステム１０が稼働するか記憶装置が取り付けられる前に、容易に得られる限り、性能データ及びＳＭＡＲＴデータ以外のデータも本発明に利用することができる。
【００３０】
以上は、標準的な本発明に応用し得るクラウドベースサービスシステムである。本発明の方法の実現には、稼働データ収集装置１１０が必要である。本実施形態において、稼働データ収集装置１１０は、ハードウェアであり、サーバ１００中に取り付けて中央処理装置１０１と接続し、稼働データを収集し、収集した稼働データをデータベース１０３（通常、データベースの形態で存在する）中に記憶させる。実際には、ハードウェアと同じ機能を有するソフトウェアをサーバ１００にインストールし、中央処理装置１０１により操作してもよい。稼働データ収集装置１１０と中央処理装置１０１とを一緒に稼働して本発明のステップを実行する。
【００３１】
図２を参照する。図２は、本発明の一実施形態に係るクラウドベースサービスシステム１０中のデータを保護する方法を示す流れ図である。
本方法の第１のステップは、稼働データ収集装置１１０を利用してクラウドベースサービスシステム１０中の記憶装置２００の履歴稼働データを収集する（Ｓ０１）。当該方法を応用する前に、クラウドベースサービスシステム１０は、既に一定時間稼働された可能性があり、収集した稼働データは、作業負担のデータアクセスの負担（作業負担が記憶装置２００にアクセスする時間及び頻度）を反映する。しかし、データが消失するかクラウドベースサービスシステム１０が完成したばかりで履歴稼働データが無い場合、本方法の稼働データにより、クラウドベースサービスシステム１０が使用する個別の記憶装置２００の関連データを収集する。
【００３２】
本方法の第２のステップは、収集した稼働データにより、寿命予測モデル及び７日以内の故障率モデルを構築する（Ｓ０２）。寿命予測モデル及び７日以内の故障率モデルは、データベースの形態でデータベース１０３中に記憶され、実行して周期的にデータを更新する。寿命予測モデル及び７日以内の故障率モデルのステップは以下の通りである。
【００３３】
図３を参照する。図３は、寿命予測モデルを構築するワークフローである。
まず、クラウドベースサービスシステム１０の記憶装置２００が得た履歴稼働データを取得する（Ｓ１１）。履歴稼働データは、バッチ単位で得られる。即ち、現有する一部は、寿命予測モデルの記憶装置２００の履歴稼働データがデータベース中にすでにあり、他方のバッチが取得した履歴稼働データが新たに加えられる。新たに得た記憶装置２００の履歴稼働データは、例えば、半時間前から新たな訓練材料と見なされ、予測結果がより実際のものに近づく。稼働データは、寿命予測モデルを構築して更新し、将来的にそれを更新する。「故障した記憶装置」が現れるまで一定時間待つ必要がある。本発明が提供する方法は、時間の経過に伴う記憶装置２００の寿命分布を知る必要がある。
続いて、複数の記憶装置２００を故障していないものと故障したものとに区分する（Ｓ１２）。１つの記憶装置２００が故障していないものであり動作できる場合、収集した履歴駆動データは、記憶装置２００が耐え得る過酷な環境（作業負担の応用、クラウドベースサービスシステム１０の管理モード、クラウドベースサービスシステム１０のハードウェアの物理的状態など）のみ反映される。もし記憶装置２００が故障して駆動できない場合、その収集した履歴稼働データは、その一生の記録と見なされ得る。もし故障した記憶装置２００が経験した状況が同じであり、同じか類似した駆動データをトレースして得られる場合、同様にどの記憶装置２００も失敗する可能性がある。異なる寿命範囲により、故障した記憶装置２００が類別される（Ｓ１３）。ここで寿命範囲とは連続した日数のことである（例えば、０日（ＤＯＡ：Ｄｅａｄ  ｏｎ  Ａｒｒｉｖａｌ）から９０日まで、９１日から１８０日、１８１日から２７０日までなど）。故障前の稼働日数に基づき、各記憶装置２００は、寿命範囲に分類し得る。
故障していない記憶装置２００にとっては、正常な状態に属しているため、全ての故障していない記憶装置２００を特定の寿命範囲に設定する（Ｓ１４）。この特定の寿命範囲には上限は無く、例えば、１０８１日を超えてもよい。ここで「１０８１日」とは、クラウドベースサービスシステム１０が既に稼働したか、故障していない記憶装置２００が既に稼働した時間を指す。即ち、故障していない記憶装置２００は既に少なくとも１０８１日間正常に作動している。ここで、１０８１日とは単なる参考例であり、特定の寿命範囲の下限は１０８１日間だけには限定されない。
【００３４】
続いて、寿命範囲に基づき、複数の記憶装置２００の稼働データを複数組に分級（ｂｉｎ）する（Ｓ１５）。データの分級とは、マイナー観察エラー（ｍｉｎｏｒ  ｏｂｓｅｒｖａｔｉｏｎ  ｅｒｒｏｒ）の効果を低下させる、データの前処理技術である。小さなインターバルに入る（即ち分級）元データ値は、インターバルを表す数値により代替され、その数値は一般に中間値であり、量子化形式である。記憶装置２００の稼働データは、故障の有無に関わらず、ステップＳ１５で定義された寿命範囲に基づいて分級される。記憶装置２００が１組に分級されると（例えば、ｂｉｎ♯４（２７１日から３６０日まで））、全ての駆動データも当該組に分級される。簡素化するために、分級数値（インターバルの代表値）は、１個目（０日から９０日まで）から始まる順序である。最後に、全ての組の各記憶装置２００からの駆動データを正常化させる（Ｓ１６）。
各組（分級）中の記憶装置２００は、同じ形態（ソリッド・ステート・ディスク又はハードディスク）でないか、同じモデル（同じ製造メーカの同じ特定の又は製造のモデル）であり、とても重要なこととして、予測する寿命予測モデルは、「アップルトゥアップル（ａｐｐｌｅ−ｔｏ−ａｐｐｌｅ）」の方式で構築する必要があることである。予測は、全てのモデルでなく、特定のモデルで認識されるべきである（ソリッド・ステート・ディスクに適用できるものでもハードディスクには適用できない可能性があり、５１２Ｇのソリッド・ステート・ディスクに適用できるものでも１Ｇのソリッド・ステート・ディスクには適用できない可能性があり、東芝社製の１Ｇのソリッド・ステート・ディスクに適用できるものでも、サムソン社製の１Ｇのソリッド・ステート・ディスクには適用できない可能性がある）。上述したステップが終了した後、当該組（分級）の結果を表示し、寿命予測モデルは、各記憶装置２００の寿命予測を提供する準備が整う。ここで予測ステップは、訓練のために駆動データを２４回収集するが、１日１回行い得る。
【００３５】
ここで、寿命予測モデルを構築する説明は学習段階と称され、オンライン上の所望の作業負担前、又はクラウドベースサービスシステム１０の稼働前に、上述したステップのデータを再び使用してもよい。寿命予測モデルを続いて稼働段階に応用し、稼働段階において寿命予測モデルの稼働は、オンラインの作業負担の衝撃を考慮する。
稼働の寿命予測モデルのステップは、簡素化してクラウドベースサービスシステム１０の記憶装置２００が既に取得した記憶装置２００を得る（Ｓ１１）。寿命範囲に基づき、記憶装置２００の稼働データを複数組に分級する（Ｓ１５）。全ての組の各記憶装置２００からの稼働データを正常化させる。この段階では、ステップＳ１１、ステップＳ１５及びステップＳ１６を繰り返すだけで、所望の分級が寿命予測モデルを参照して見つけることができる。
【００３６】
７日以内の故障確率モデルについては、図４を参照する。図４は、７日以内の故障率モデルを構築するワークフローである。
まず、クラウドベースサービスシステム１０の記憶装置２００が既に取得した履歴稼働データを得る（Ｓ２１）。同様に、履歴稼働データは、バッチ単位で得られる。即ち、現有する一部を用いて７日以内の故障確率モデルを構築する記憶装置２００の履歴稼働データがデータベース中に既に存在し、他方のバッチが取得した履歴稼働データが新たに加えられる。新たに得られた記憶装置２００の履歴稼働データは、新たな材料と見なされて訓練を行い、予測結果がより真実に近づく。しかし、全ての履歴稼働データが使用できるわけではない。続いて、７日以内の故障確率モデルは、これら複数の稼働データをソートする必要があり（Ｓ２２）、どの稼働データが故障していない記憶装置から来たのかを知り、どの稼働データが故障した記憶装置から来たのかを知る必要がある。続いて、故障した記憶装置２００は、最近収集した時点から７日以内の記憶装置２００からの稼働データを得て（Ｓ２３）、故障していない記憶装置２００からランダムに取得し、最近収集した時点から７日以内の記憶装置２００の稼働データを得る（Ｓ２４）。
前回収集した時点が１時間前である場合、記憶装置２００の稼働データは、１時間前に収集を開始し、１６８時間後に終了しなければならない。重要なこととして、本発明に依ると、最近収集した時点から７日以内に、稼働データの故障した記憶装置２００と、故障していない記憶装置２００との比率は１：１であり、このように平衡方式により記憶装置２００の故障率を予測することができる。故障していない記憶装置２００の数は、故障した記憶装置２００より多い。これはステップＳ２４で、ランダムに取得した故障していない複数の記憶装置２００が必要なためであり、故障していない全ての記憶装置２００がその理由ではない。
最終的に、各記憶装置２００からの稼働データを正常化させる（Ｓ２５）。同様に、正常化により各モデルの記憶装置２００の故障率をより正確に予測することができる。本発明によると、寿命予測モデル及び７日以内の故障率モデルは、継続的に将来新たに収集する稼働データを更新しなければならない。記憶装置２００の履歴稼働データを収集する時間間隔は１時間であることが好ましい。
【００３７】
寿命予測モデルのシナリオと類似し、上述した７日以内の故障率モデルの説明は学習段階と称され、これは所望の作業負担がオンライン前又はクラウドベースサービスシステム１０の稼働前に、上述のステップのデータが再び使用されることを意味する。７日以内の故障率モデルも続いて作動段階に応用することができ、作動段階中の７日以内の故障率モデルの稼働では、オンラインの作業負担の衝撃を考慮する。７日以内の故障率モデルは、クラウドベースサービスシステム１０中の記憶装置２００が既に取得した記憶装置２００を得て稼働する。故障率は、７日以内の故障率モデルを参照して得ることができる。
【００３８】
本発明が開示するクラウドベースサービスシステム１０中のデータを保護する方法の第３のステップは、各記憶装置２００が入力した過去２４時間の稼働データを寿命予測モデル及び７日以内の故障率モデル中に入力し、各組中の予測寿命範囲と、対応する故障率とを得る（Ｓ０３）。図５を参照する。図５は、寿命予測モデル及び７日以内の故障率モデルの入力及び出力を示すテーブルである。
寿命予測モデル及び７日以内の故障率モデルが予測を提供する準備ができた後、稼働データを入力する。稼働データはＮ個あるが、ここでは３個使用して説明する。第１の記憶装置２００（１）が有する所定の寿命範囲は、ｂｉｎ♯１８（所定の寿命は３０６１時間から３２４０時間である）組中に入り、故障率は３５％である。第２の記憶装置２００（２）が有する所定の寿命範囲は、ｂｉｎ♯２１（所定の寿命は３６０１時間から３７８０時間である）組中に入り、故障率は２１％である。第３の記憶装置２００（３）が有する所定の寿命範囲は、ｂｉｎ♯２（所定の寿命は１８１時間から３６０時間である）組中に入り、故障率は９５％である。
第３の記憶装置２００（３）は、短めの予測寿命と、高めの機会を有して７日以内に故障しそうである。そのため、第３の記憶装置２００（３）中に記憶したデータは、紛失することを防ぐために複製しなければならない。本発明で述べる方法の最終ステップは、ステップ（Ｓ０３）の結果に基づき、複数の記憶装置中のデータをバックアップする（Ｓ０４）。
【００３９】
本発明において、寿命予測モデルは、ＡＮＮ（Ａｒｔｉｆｉｃｉａｌ  Ｎｅｕｒａｌ  Ｎｅｔｗｏｒｋ）アルゴリズムにより、入力された過去２４時間の稼働データと、履歴稼働データとにより寿命の範囲を予測する。同様に、７日以内の故障率モデルもＡＮＮアルゴリズムにより、入力した過去２４時間の稼働データ及び履歴稼働データを計算し、対応した故障率を予測する。
寿命予測モデルに応用するＡＮＮアルゴリズムと、７日間の故障率モデルに応用するＡＮＮアルゴリズムとは、同じでもよいし異なってもよい。入力した稼働データと、取得した履歴稼働データとの間のパラメータを計算できる限り、現有する多くのＡＮＮアルゴリズムを応用することもできる。寿命予測モデルは、１組（ランク番号）を表し、７日以内の故障率モデルは、各記憶装置２００が提供する確率値である。
【００４０】
新しい形式の記憶装置又は新しい記憶装置（例えば、第Ｎ＋１の記憶装置２００（Ｎ＋１））は、クラウドベースサービスシステム１０に用いられるが、クラウドベースサービスシステム１０には記録されない。本発明によると、ステップＳ０１の後に、記憶装置２００の履歴稼働データを収集するステップがさらに必要である。これら複数の記憶装置２００は、全く新しいか、加えられたばかりのクラウドベースサービスシステム１０である（Ｓ０１’）。
上述したように、第Ｎ＋１の記憶装置２００（Ｎ＋１）がオンラインとなる前に、残りの記憶装置２００（１）〜２００（Ｎ）は、過去に多くの稼働データを収集しており、現存する寿命予測モデルと、現存する７日以内の故障率モデルとを有する。第Ｎ＋１の記憶装置２００（Ｎ＋１）の履歴稼働データは、その他データセンター又はテストサイトから取得し、クラウドベースサービスシステム１０に発行する。ステップＳ０１〜Ｓ０２を行った後、新しい寿命予測モデル及び新しい７日以内の故障率モデルを構築することができる。第Ｎ＋１の記憶装置２００（Ｎ＋１）は、性能を正確に予測するために、どの組のモデル（現存するモデル又は新しいモデル）にするか決定しなければならない。この判断はサーバ１００の管理者が手作業で処理してもよいし、稼働データ収集装置１１０により行ってもよい。
稼働データ収集装置１１０は、アービタ（ａｒｂｉｔｅｒ）のような役割をし、第Ｎ＋１の記憶装置２００（Ｎ＋１）の性能に基づいて将来、決定する。決定する時間点は長くなる可能性がある。決定を発行する前に、現存するモデル又は新しいモデルは、デフォルトモデルとしてクラウドベースサービスシステム１０中で実行される。２組のモデルは、第Ｎ＋１の記憶装置２００（Ｎ＋１）に対する予測が実際の状況と大きく異なることをサーバ１００が発見すると、稼働データ収集装置１１０は、本発明のステップに基づき、１組のモデルが提供する予測が許容範囲に入るまで、より新しいモデルを構築することを決定する。
【００４１】
データを保護するためには、故障率が高めであるか、寿命が短めの記憶装置２００中のデータをバックアップすることが非常に大切である。唯一注意が必要なことは、バックアップの頻度である（本実施形態では、翌日にバックアップを行うか否かである）。ステップＳ０４を行う簡単な方法は、対応した特定寿命より短い予測寿命を有する、及び／又は、特定のパーセンテージを超えた故障率を有する記憶装置２００中のデータをバックアップする。
例えば、第１の記憶装置２００（１）は、ソリッド・ステート・ディスクであるため、ｂｉｎ♯１８の範囲内に入り、故障率予測が９０％を超えるときに、データをバックアップする。図５中の故障率は僅か３５％であるため、第１の記憶装置２００（１）中のデータは、２０１６年５月１２日の１３時４５分から２０１６年５月１３日の１３時４５分までバックアップされない。時間間隔は、１日（２４時間）だけに限定されない。これは以下で決定され、説明される。
【００４２】
勿論、バックアップは記憶装置２００に対するスナップショットでもよい。他の実施形態では、本発明は他のステップを提供し、ステップＳ０４について詳しく説明する。計算して得られたスナップショット時間間隔のスナップショット作業は、記憶装置２００中のデータをバックアップする（Ｓ０４’）。スナップショット時間間隔は、ステップＳ０３の結果をファジィシステム中に入力し、算出することができる。
応用するファジィシステムは、以下のステップにより構築される（図６を参照する）。複数の分級、故障率及びスナップショット時間間隔の言語値を定義し（Ｓ３１）、メンバシップ関数を構築し、全ての分級、故障率及びスナップショット時間間隔の程度を描き（Ｓ３２）、これら複数の分級、故障率及びスナップショット時間間隔によりファジィルールを構築する（Ｓ３３）。より理解し易いように、図７を参照する。
【００４３】
図７を参照する。図７は、分級、故障率ならびにスナップショット時間間隔の言語値及びファジィルールを示す。分級（予測寿命）の言語値は、「非常に長い」、「長い」、「ニュートラル」、「短い」、「非常に短い」である。故障率の言語値は、「可能性が高い」、「ニュートラル」、「可能性が低い」である。スナップショット時間間隔の言語値は、「非常に長い」、「長い」、「ニュートラル」、「短い」、「非常に短い」である。ファジィルールは、各分級列及び各故障予測のコラム中で説明される。例えば、予測寿命が「長く」、故障率が「可能性が高い」場合、スナップショット時間間隔は「短い」。ファジィルールの定義は、クラウドベースサービスシステム１０上で実行される作業負担のポリシーに基づいて構築される。ファジィルールは、作業負担のニーズ（ＳＬＡ）に基づいて変わる。分級、故障率及びスナップショット時間間隔の程度を描くメンバシップ関数を図８、図９及び図１０に示す。
【００４４】
以下、ファジィシステムの操作ステップについて述べる。まず、分級及び故障率を受け取る（Ｓ４１）。分級及び故障率は、ステップ（Ｓ０３）を行った結果である。続いて、分級及び故障率をファジィルールのメンバシップ関数に入力し、ファジィ化、ファジィ推論及び結果集約を行う（Ｓ４２）。
従来技術には、ファジィ化、ファジィ推論及び結果集約を実現する多くの技術があるが、本発明はこれらだけに限定されるものではなく、例えば、その他のファジィシステムと同様、最後に非ファジィ化を行ってスナップショット時間間隔を得てもよい（Ｓ４３）。同様に、非ファジィ化の方式は、ファジィ化の方式に応じて使用してもよく、これも本発明により制限されるわけではない。計算のスナップショット時間間隔は、記憶装置２００に直ちに応用してもよい。勿論、全ての記憶装置２００それぞれのスナップショット時間間隔は、１日１回に決めてもよく、スナップショット時間間隔は０にしてもよい（現在のところデータを保護する必要はない）。
【００４５】
上述した実施形態は、クラウドベースサービスシステム中でデータを収集して訓練を提供し、寿命予測寿命モデル及び７日以内の故障率モデルを更新することができるが、これらのモデルのクラウドベースサービスシステムへ応用するだけに限定されるわけではない。より広範な応用において、寿命予測モデルと、７日以内の故障率モデルは、データセンター又はクラウドベースサービスシステム中で訓練を行い、その他同じ又は類似した配置の記憶装置を有するクラウドベースサービスシステム中に応用し、有限の資源を利用して本方法を実現する長所を有する。
【００４６】
当該分野の技術を熟知するものが理解できるように、本発明の好適な実施形態を前述の通り開示したが、これらは決して本発明を限定するものではない。本発明の主旨と領域を逸脱しない範囲内で各種の変更や修正を加えることができる。従って、本発明の特許請求の範囲は、このような変更や修正を含めて広く解釈されるべきである。
【符号の説明】
【００４７】
１０  クラウドベースサービスシステム
１００  サーバ
１０１  中央処理装置
１０２  記憶装置入出力ユニット
１０３  データベース
１０４  ネットワーク入出力ユニット
１１０  稼働データ収集装置
２００（１）  第１の記憶装置
２００（２）  第２の記憶装置
２００（３）  第３の記憶装置
２００（Ｎ）  第Ｎの記憶装置
２００（Ｎ＋１）  第Ｎ＋１の記憶装置
【図１】
2019053474.tif 000003
【図２】
2019053474.tif 000004
【図３】
2019053474.tif 000005
【図４】
2019053474.tif 000006
【図５】
2019053474.tif 000007
【図６】
2019053474.tif 000008
【図７】
2019053474.tif 000009
【図８】
2019053474.tif 000010
【図９】
2019053474.tif 000011
【図１０】
2019053474.tif 000012