JP2019053474A - クラウドベースサービスのデータ保護方法 - Google Patents
クラウドベースサービスのデータ保護方法 Download PDFInfo
- Publication number
- JP2019053474A JP2019053474A JP2017176614A JP2017176614A JP2019053474A JP 2019053474 A JP2019053474 A JP 2019053474A JP 2017176614 A JP2017176614 A JP 2017176614A JP 2017176614 A JP2017176614 A JP 2017176614A JP 2019053474 A JP2019053474 A JP 2019053474A
- Authority
- JP
- Japan
- Prior art keywords
- storage device
- data
- cloud
- operation data
- based service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Images
Abstract
【課題】寿命予測モデル及び7日以内の故障率モデルにより、寿命を予測して7日以内に記憶装置が故障する確率を決定するクラウドベースサービスのデータ保護方法を提供する。【解決手段】クラウドベースサービスのデータ保護方法は、クラウドベースサービスシステム中の記憶装置の履歴稼働データを収集するステップ(S01)と、前記収集した稼働データにより寿命予測モデル及び7日以内の故障率モデルを構築するステップ(S02)と、各前記記憶装置が過去24時間の前記稼働データを前記寿命予測モデル及び前記7日以内の故障率モデルに入力し、各組中の予測寿命範囲及び対応した故障率を得るステップ(S03)と、前記ステップ(S03)の結果に基づき、前記記憶装置中のデータをバックアップするステップ(S04)とを含む。【選択図】図2
Description
本発明は、データの保護方法に関し、特に、クラウドベースサービスのデータ保護方法に関する。
Mongo(登録商標)DBなどの作業負担は、ノードクラスタを有するクラウドベースサービスシステムで操作される。この作業負担は、クラウドベースサービスの単一のノード又は複数のノード上で作動し、各ノードには、少なくとも1つの磁気ディスクが割り当てられ、アクセスするデータが記憶される。単一のノードの作業の作業負担において、割り当てられた磁気ディスクが故障すると、バックアップされたデータをリストアする前は実行できなかった。
複数のノードの作業の作業負担にとって、そのうち一つの割り当てられた磁気ディスクが故障するか、全ノードが故障してしまった場合、データを新たなノードへ移す必要があるため、クラウドベースサービスの性能が低下し、作業負担の性能にも悪影響を与える虞があった。クラウドベースサービス中の磁気ディスクの健康状態と、データのリストアの計画的なアーカイブとは、作業負担のデータを保護するためにとても大切な要素であった。
複数のノードの作業の作業負担にとって、そのうち一つの割り当てられた磁気ディスクが故障するか、全ノードが故障してしまった場合、データを新たなノードへ移す必要があるため、クラウドベースサービスの性能が低下し、作業負担の性能にも悪影響を与える虞があった。クラウドベースサービス中の磁気ディスクの健康状態と、データのリストアの計画的なアーカイブとは、作業負担のデータを保護するためにとても大切な要素であった。
上述したニーズの解決手段として現在多くの技術がある。それら解決手段の多くは、記憶装置の寿命の予測に関する。例えば、記憶装置の寿命を予測する従来の方法は、操作習慣情報及び対応した操作寿命値をそれぞれ含む複数の訓練データを記録するデータベースを設定するステップと、対応した記憶装置から操作習慣情報を取得するステップと、操作習慣情報及び対応した訓練データの操作寿命値に基づき、記憶装置の寿命予測モデルを構築するステップと、記憶装置の寿命予測モデルに記憶装置の操作習慣情報を入力するステップと、個別の記憶装置に予測寿命値を生成するステップと、を含む。記憶装置の寿命予測モデルは、予測寿命値を使用して構築してもよい。記憶装置中の第1の記憶装置が故障したときに、第1の記憶装置の実際の寿命を記憶し、記憶装置の寿命予測モデルを構築する。
従来様々な方法により、記憶装置の寿命を予測してデータを保護し、予測結果に基づいて実行していたが、応用する際、依然として様々な問題点があった。
まず、記憶装置(ハードディスク又はソリッド・ステート・ディスク)が故障する確率は、記憶装置が使用寿命の終点に近づくにつれて急速に高まった。しかし、前述したような方法では、操作寿命値の訓練データにのみ頼り、使用寿命の終点前に記憶装置が突然故障することを予測することは困難であった。
第2に、記憶装置の故障は、作業負担の結果であり、つまり、作業負担の使用ニーズの高まりにより、記憶装置の寿命が短くなるが、作業負担の影響は、従来の方法では考慮されない。また、データ保護には、記憶装置中に記憶したデータのバックアップの適切な計画が含まれてもよいが、データのバックアップを頻繁に行うと、関連する作業負担の性能が低下する虞がある。これとは反対に、作業負担の系統的な崩壊が発生する虞もあった。そのため、記憶装置の寿命を予測することができれば、問題を解決することができる。
まず、記憶装置(ハードディスク又はソリッド・ステート・ディスク)が故障する確率は、記憶装置が使用寿命の終点に近づくにつれて急速に高まった。しかし、前述したような方法では、操作寿命値の訓練データにのみ頼り、使用寿命の終点前に記憶装置が突然故障することを予測することは困難であった。
第2に、記憶装置の故障は、作業負担の結果であり、つまり、作業負担の使用ニーズの高まりにより、記憶装置の寿命が短くなるが、作業負担の影響は、従来の方法では考慮されない。また、データ保護には、記憶装置中に記憶したデータのバックアップの適切な計画が含まれてもよいが、データのバックアップを頻繁に行うと、関連する作業負担の性能が低下する虞がある。これとは反対に、作業負担の系統的な崩壊が発生する虞もあった。そのため、記憶装置の寿命を予測することができれば、問題を解決することができる。
上述したような問題点を改善するために、本発明のクラウドベースサービスのデータ保護方法は、磁気ディスクが使用寿命の終点近くなったときの故障確率である「故障確率」の概念を導入した。そのため、本発明は、磁気ディスクが故障する可能性が高い時間点を正確に予測することができ、クラウドベースサービスのデータを保護することができる。
本発明の主な目的は、寿命予測モデル及び7日以内の故障率モデルにより、寿命を予測して7日以内に記憶装置が故障する確率を決定するクラウドベースサービスのデータ保護方法を提供することにある。
上記課題を解決するために、本発明の第1の形態によれば、クラウドベースサービスシステム中の記憶装置の履歴稼働データを収集するステップ(A)と、前記収集した稼働データにより寿命予測モデル及び7日以内の故障率モデルを構築するステップ(B)と、各前記記憶装置が過去24時間の前記稼働データを前記寿命予測モデル及び前記7日以内の故障率モデルに入力し、各組中の予測寿命範囲及び対応した故障率を得るステップ(C)と、前記ステップ(C)の結果に基づき、前記記憶装置中のデータをバックアップするステップ(D)と、を含むことを特徴とするクラウドベースサービスのデータ保護方法が提供される。
前記稼働データは、性能データ、SMART(Self−Monitoring Analysis and Reporting Technology)データ、前記記憶装置の使用可能容量、前記記憶装置の総容量又は装置メタデータであることが好ましい。
前記性能データは、レイテンシ、処理量、CPU(Central Processing Unit)負荷、メモリ使用量又はIOPS(Input/Output Per Second)であることが好ましい。
前記記憶装置は、ハードディスク又はソリッド・ステート・ディスクであることが好ましい。
前記寿命予測モデル及び前記7日以内の故障率モデルは、将来新たに収集する前記稼働データにより継続的に更新されることが好ましい。
前記記憶装置の前記履歴稼働データを収集する時間間隔は1時間であることが好ましい。
前記寿命予測モデルは、故障していない前記記憶装置と故障した前記記憶装置とに区分するステップ(B1)と、前記寿命範囲を前記故障した記憶装置に類別し、前記故障していない記憶装置の全てを特定の寿命範囲に設定するステップ(B2)と、前記寿命範囲に基づき、前記記憶装置の前記稼働データを複数組中に分級(binning)するステップ(B3)と、全ての組に対し、各前記記憶装置からの前記稼働データを正常化させるステップ(B4)と、により構築されることが好ましい。
前記寿命予測モデルは、前記寿命範囲に基づき、前記記憶装置の前記稼働データを複数組に分級させるステップ(B3’)と、全組に対し、各前記記憶装置からの前記稼働データを正常化させるステップ(B4’)と、により操作されることが好ましい。
前記7日以内の故障率モデルは、前記稼働データをソートするステップ(B5)と、故障した記憶装置と、ランダムに取得した故障していない複数の記憶装置と、に対し、最後に収集した時点から起算して7日以内の前記記憶装置の前記稼働データを得るステップ(B6)と、各前記記憶装置からの前記稼働データを正常化させるステップ(B7)と、により構築されることが好ましい。
最後に収集した時点から7日以内に収集した前記稼働データの前記故障した記憶装置と、前記故障していない記憶装置との比率は1:1であることが好ましい。
全く新しいか、加えられたばかりの前記クラウドベースサービスシステムである前記記憶装置の前記履歴稼働データを収集するステップ(A1)をさらに含むことが好ましい。
前記寿命予測モデルは、ANN(Artificial Neural Network)アルゴリズムにより、入力された過去24時間の前記稼働データと、前記履歴稼働データとにより前記予測寿命範囲を予測することが好ましい。
前記7日以内の故障率モデルは、ANNアルゴリズムにより、入力された過去24時間の前記稼働データ及び前記履歴稼働データを計算し、対応する故障率を予測することが好ましい。
前記ステップ(D)において、特定の寿命より短い予測寿命を有する、及び/又は、特定のパーセンテージを超えた故障率を有する前記記憶装置中のデータをバックアップすることが好ましい。
前記ステップ(D)において、計算により得られたスナップショット時間間隔でスナップショット作業を行い、前記記憶装置中のデータをバックアップすることが好ましい。
前記スナップショット時間間隔は、前記ステップ(C)の結果をファジィシステム中に入力し、算出することが好ましい。
前記ファジィシステムは、複数の分級(bin)、故障率及びスナップショット時間間隔の言語値を定義するステップ(E1)と、メンバシップ関数を構築し、全ての前記分級、前記故障率及び前記スナップショット時間間隔の程度を描くステップ(E2)と、前記分級、前記故障率及び前記スナップショット時間間隔によりファジィルールを構築するステップ(E3)と、により形成されることが好ましい。
前記ファジィシステムは、前記分級及び前記故障率を受け取るステップ(F1)と、前記ファジィルールの前記メンバシップ関数に前記分級及び前記故障率を入力し、ファジィ化、ファジィ推論及び結果集約を行うステップ(F2)と、非ファジィ化を行って前記スナップショット時間間隔を得るステップ(F3)と、の操作を含むことが好ましい。
本発明のクラウドベースサービスのデータ保護方法は、寿命予測モデル及び7日以内の故障率モデルにより、寿命を予測して7日以内に記憶装置が故障する確率を決定し、これらの結果を得た後、データのバックアップ(スナップショット作業)のスケジュールを決定することで、従来技術の問題点を改善することができる。
以下、本発明の実施形態について図に基づいて説明する。なお、これによって本発明が限定されるものではない。
本発明の一実施形態に係るクラウドベースサービスのデータ保護方法は、電子メールサービス、ビデオストリーミング、ERPシステムなどの作業負担のアーキテクチャに応用することができる。本方法が応用する典型的なクラウドベースサービスシステム10を図1に示す。
クラウドベースサービスシステム10は、サーバ(ホスト)100及び複数の記憶装置200を含む。サーバ100は、中央処理装置101、記憶装置入出力ユニット102、データベース103及びネットワーク入出力ユニット104を基本的に有する。中央処理装置101は、クラウドベースサービスシステム10の操作と、その上で稼働する作業負担とを管理する。それとともに、中央処理装置101は、記憶装置入出力ユニット102を介して記憶装置200からの稼働データ及びネットワーク入出力ユニット104からの稼働データを追跡・記録することができる。記憶装置入出力ユニット102は、クラウドベースサービスシステム10の工業規格の如何なるハードウェアにも応用でき、内部データを転送する。この工業規格は、ペリフェラルコンポーネントインターコネクトエクスプレス(Peripheral Component Interconnect Express:PCI Express)、IDE(Integrated Device Electronics)、SATA(Serial Advanced Technology Attachment)又はユニバーサルシリアルバス(Universal Serial Bus:USB)でもよい。
ネットワーク入出力ユニット104は、外部クライアント装置(例えば、パーソナルコンピュータ、タブレットコンピュータ、スマートフォンなど)に無線接続又は有線接続するハードウェアである。ネットワーク入出力ユニット104は、USBポート、RJ45ポート、光ファイバケーブル、Wi−Fi(登録商標)モジュール又はブルートゥース(登録商標)モジュールでもよい。データベース103とは、ハードディスク、ソリッド・ステート・ディスク又はサーバ100のDRAM中の恒久的又は一時的に構築したデータベース又は構造データを指し、直接的に作業負担にアクセスさせず、本発明の応用に有利である。
本実施形態は、N個の記憶装置200(第1の記憶装置200(1)、第2の記憶装置200(2)、第3の記憶装置300(3)…及び第Nの記憶装置200(N))を有する。
クラウドベースサービスシステム10は、サーバ(ホスト)100及び複数の記憶装置200を含む。サーバ100は、中央処理装置101、記憶装置入出力ユニット102、データベース103及びネットワーク入出力ユニット104を基本的に有する。中央処理装置101は、クラウドベースサービスシステム10の操作と、その上で稼働する作業負担とを管理する。それとともに、中央処理装置101は、記憶装置入出力ユニット102を介して記憶装置200からの稼働データ及びネットワーク入出力ユニット104からの稼働データを追跡・記録することができる。記憶装置入出力ユニット102は、クラウドベースサービスシステム10の工業規格の如何なるハードウェアにも応用でき、内部データを転送する。この工業規格は、ペリフェラルコンポーネントインターコネクトエクスプレス(Peripheral Component Interconnect Express:PCI Express)、IDE(Integrated Device Electronics)、SATA(Serial Advanced Technology Attachment)又はユニバーサルシリアルバス(Universal Serial Bus:USB)でもよい。
ネットワーク入出力ユニット104は、外部クライアント装置(例えば、パーソナルコンピュータ、タブレットコンピュータ、スマートフォンなど)に無線接続又は有線接続するハードウェアである。ネットワーク入出力ユニット104は、USBポート、RJ45ポート、光ファイバケーブル、Wi−Fi(登録商標)モジュール又はブルートゥース(登録商標)モジュールでもよい。データベース103とは、ハードディスク、ソリッド・ステート・ディスク又はサーバ100のDRAM中の恒久的又は一時的に構築したデータベース又は構造データを指し、直接的に作業負担にアクセスさせず、本発明の応用に有利である。
本実施形態は、N個の記憶装置200(第1の記憶装置200(1)、第2の記憶装置200(2)、第3の記憶装置300(3)…及び第Nの記憶装置200(N))を有する。
稼働データは、性能データ、SMART(Self−Monitoring Analysis and Reporting Technology)データ、記憶装置200の使用可能容量、記憶装置200の総容量又は装置のメタデータでもよい。これら性能データは、作業負担を実行するクラウドベースサービスシステム10の稼働の物理情報である。例えば、性能データは、レイテンシ、処理量、CPU(Central Processing Unit)負荷、メモリ使用量又はIOPS(Input/Output Per Second)でもよい。それらは、記憶装置200に接続された記憶装置入出力ユニット102、外部クライアント装置に接続されたネットワーク入出力ユニット104、又は中央処理装置101を介してデータフローから直接来る。
SAMRTデータを使用して、シリアルコード(数字)により発生し得る駆動器の故障を示す。これは、各記憶装置200にインストールした監視ソフトウェアにより得られる。SMARTの定義に依り、記憶装置200はハードディスク又はソリッド・ステート・ディスクでもよい。クラウドベースサービスシステム10が稼働するか記憶装置が取り付けられる前に、容易に得られる限り、性能データ及びSMARTデータ以外のデータも本発明に利用することができる。
SAMRTデータを使用して、シリアルコード(数字)により発生し得る駆動器の故障を示す。これは、各記憶装置200にインストールした監視ソフトウェアにより得られる。SMARTの定義に依り、記憶装置200はハードディスク又はソリッド・ステート・ディスクでもよい。クラウドベースサービスシステム10が稼働するか記憶装置が取り付けられる前に、容易に得られる限り、性能データ及びSMARTデータ以外のデータも本発明に利用することができる。
以上は、標準的な本発明に応用し得るクラウドベースサービスシステムである。本発明の方法の実現には、稼働データ収集装置110が必要である。本実施形態において、稼働データ収集装置110は、ハードウェアであり、サーバ100中に取り付けて中央処理装置101と接続し、稼働データを収集し、収集した稼働データをデータベース103(通常、データベースの形態で存在する)中に記憶させる。実際には、ハードウェアと同じ機能を有するソフトウェアをサーバ100にインストールし、中央処理装置101により操作してもよい。稼働データ収集装置110と中央処理装置101とを一緒に稼働して本発明のステップを実行する。
図2を参照する。図2は、本発明の一実施形態に係るクラウドベースサービスシステム10中のデータを保護する方法を示す流れ図である。
本方法の第1のステップは、稼働データ収集装置110を利用してクラウドベースサービスシステム10中の記憶装置200の履歴稼働データを収集する(S01)。当該方法を応用する前に、クラウドベースサービスシステム10は、既に一定時間稼働された可能性があり、収集した稼働データは、作業負担のデータアクセスの負担(作業負担が記憶装置200にアクセスする時間及び頻度)を反映する。しかし、データが消失するかクラウドベースサービスシステム10が完成したばかりで履歴稼働データが無い場合、本方法の稼働データにより、クラウドベースサービスシステム10が使用する個別の記憶装置200の関連データを収集する。
本方法の第1のステップは、稼働データ収集装置110を利用してクラウドベースサービスシステム10中の記憶装置200の履歴稼働データを収集する(S01)。当該方法を応用する前に、クラウドベースサービスシステム10は、既に一定時間稼働された可能性があり、収集した稼働データは、作業負担のデータアクセスの負担(作業負担が記憶装置200にアクセスする時間及び頻度)を反映する。しかし、データが消失するかクラウドベースサービスシステム10が完成したばかりで履歴稼働データが無い場合、本方法の稼働データにより、クラウドベースサービスシステム10が使用する個別の記憶装置200の関連データを収集する。
本方法の第2のステップは、収集した稼働データにより、寿命予測モデル及び7日以内の故障率モデルを構築する(S02)。寿命予測モデル及び7日以内の故障率モデルは、データベースの形態でデータベース103中に記憶され、実行して周期的にデータを更新する。寿命予測モデル及び7日以内の故障率モデルのステップは以下の通りである。
図3を参照する。図3は、寿命予測モデルを構築するワークフローである。
まず、クラウドベースサービスシステム10の記憶装置200が得た履歴稼働データを取得する(S11)。履歴稼働データは、バッチ単位で得られる。即ち、現有する一部は、寿命予測モデルの記憶装置200の履歴稼働データがデータベース中にすでにあり、他方のバッチが取得した履歴稼働データが新たに加えられる。新たに得た記憶装置200の履歴稼働データは、例えば、半時間前から新たな訓練材料と見なされ、予測結果がより実際のものに近づく。稼働データは、寿命予測モデルを構築して更新し、将来的にそれを更新する。「故障した記憶装置」が現れるまで一定時間待つ必要がある。本発明が提供する方法は、時間の経過に伴う記憶装置200の寿命分布を知る必要がある。
続いて、複数の記憶装置200を故障していないものと故障したものとに区分する(S12)。1つの記憶装置200が故障していないものであり動作できる場合、収集した履歴駆動データは、記憶装置200が耐え得る過酷な環境(作業負担の応用、クラウドベースサービスシステム10の管理モード、クラウドベースサービスシステム10のハードウェアの物理的状態など)のみ反映される。もし記憶装置200が故障して駆動できない場合、その収集した履歴稼働データは、その一生の記録と見なされ得る。もし故障した記憶装置200が経験した状況が同じであり、同じか類似した駆動データをトレースして得られる場合、同様にどの記憶装置200も失敗する可能性がある。異なる寿命範囲により、故障した記憶装置200が類別される(S13)。ここで寿命範囲とは連続した日数のことである(例えば、0日(DOA:Dead on Arrival)から90日まで、91日から180日、181日から270日までなど)。故障前の稼働日数に基づき、各記憶装置200は、寿命範囲に分類し得る。
故障していない記憶装置200にとっては、正常な状態に属しているため、全ての故障していない記憶装置200を特定の寿命範囲に設定する(S14)。この特定の寿命範囲には上限は無く、例えば、1081日を超えてもよい。ここで「1081日」とは、クラウドベースサービスシステム10が既に稼働したか、故障していない記憶装置200が既に稼働した時間を指す。即ち、故障していない記憶装置200は既に少なくとも1081日間正常に作動している。ここで、1081日とは単なる参考例であり、特定の寿命範囲の下限は1081日間だけには限定されない。
まず、クラウドベースサービスシステム10の記憶装置200が得た履歴稼働データを取得する(S11)。履歴稼働データは、バッチ単位で得られる。即ち、現有する一部は、寿命予測モデルの記憶装置200の履歴稼働データがデータベース中にすでにあり、他方のバッチが取得した履歴稼働データが新たに加えられる。新たに得た記憶装置200の履歴稼働データは、例えば、半時間前から新たな訓練材料と見なされ、予測結果がより実際のものに近づく。稼働データは、寿命予測モデルを構築して更新し、将来的にそれを更新する。「故障した記憶装置」が現れるまで一定時間待つ必要がある。本発明が提供する方法は、時間の経過に伴う記憶装置200の寿命分布を知る必要がある。
続いて、複数の記憶装置200を故障していないものと故障したものとに区分する(S12)。1つの記憶装置200が故障していないものであり動作できる場合、収集した履歴駆動データは、記憶装置200が耐え得る過酷な環境(作業負担の応用、クラウドベースサービスシステム10の管理モード、クラウドベースサービスシステム10のハードウェアの物理的状態など)のみ反映される。もし記憶装置200が故障して駆動できない場合、その収集した履歴稼働データは、その一生の記録と見なされ得る。もし故障した記憶装置200が経験した状況が同じであり、同じか類似した駆動データをトレースして得られる場合、同様にどの記憶装置200も失敗する可能性がある。異なる寿命範囲により、故障した記憶装置200が類別される(S13)。ここで寿命範囲とは連続した日数のことである(例えば、0日(DOA:Dead on Arrival)から90日まで、91日から180日、181日から270日までなど)。故障前の稼働日数に基づき、各記憶装置200は、寿命範囲に分類し得る。
故障していない記憶装置200にとっては、正常な状態に属しているため、全ての故障していない記憶装置200を特定の寿命範囲に設定する(S14)。この特定の寿命範囲には上限は無く、例えば、1081日を超えてもよい。ここで「1081日」とは、クラウドベースサービスシステム10が既に稼働したか、故障していない記憶装置200が既に稼働した時間を指す。即ち、故障していない記憶装置200は既に少なくとも1081日間正常に作動している。ここで、1081日とは単なる参考例であり、特定の寿命範囲の下限は1081日間だけには限定されない。
続いて、寿命範囲に基づき、複数の記憶装置200の稼働データを複数組に分級(bin)する(S15)。データの分級とは、マイナー観察エラー(minor observation error)の効果を低下させる、データの前処理技術である。小さなインターバルに入る(即ち分級)元データ値は、インターバルを表す数値により代替され、その数値は一般に中間値であり、量子化形式である。記憶装置200の稼働データは、故障の有無に関わらず、ステップS15で定義された寿命範囲に基づいて分級される。記憶装置200が1組に分級されると(例えば、bin♯4(271日から360日まで))、全ての駆動データも当該組に分級される。簡素化するために、分級数値(インターバルの代表値)は、1個目(0日から90日まで)から始まる順序である。最後に、全ての組の各記憶装置200からの駆動データを正常化させる(S16)。
各組(分級)中の記憶装置200は、同じ形態(ソリッド・ステート・ディスク又はハードディスク)でないか、同じモデル(同じ製造メーカの同じ特定の又は製造のモデル)であり、とても重要なこととして、予測する寿命予測モデルは、「アップルトゥアップル(apple−to−apple)」の方式で構築する必要があることである。予測は、全てのモデルでなく、特定のモデルで認識されるべきである(ソリッド・ステート・ディスクに適用できるものでもハードディスクには適用できない可能性があり、512Gのソリッド・ステート・ディスクに適用できるものでも1Gのソリッド・ステート・ディスクには適用できない可能性があり、東芝社製の1Gのソリッド・ステート・ディスクに適用できるものでも、サムソン社製の1Gのソリッド・ステート・ディスクには適用できない可能性がある)。上述したステップが終了した後、当該組(分級)の結果を表示し、寿命予測モデルは、各記憶装置200の寿命予測を提供する準備が整う。ここで予測ステップは、訓練のために駆動データを24回収集するが、1日1回行い得る。
各組(分級)中の記憶装置200は、同じ形態(ソリッド・ステート・ディスク又はハードディスク)でないか、同じモデル(同じ製造メーカの同じ特定の又は製造のモデル)であり、とても重要なこととして、予測する寿命予測モデルは、「アップルトゥアップル(apple−to−apple)」の方式で構築する必要があることである。予測は、全てのモデルでなく、特定のモデルで認識されるべきである(ソリッド・ステート・ディスクに適用できるものでもハードディスクには適用できない可能性があり、512Gのソリッド・ステート・ディスクに適用できるものでも1Gのソリッド・ステート・ディスクには適用できない可能性があり、東芝社製の1Gのソリッド・ステート・ディスクに適用できるものでも、サムソン社製の1Gのソリッド・ステート・ディスクには適用できない可能性がある)。上述したステップが終了した後、当該組(分級)の結果を表示し、寿命予測モデルは、各記憶装置200の寿命予測を提供する準備が整う。ここで予測ステップは、訓練のために駆動データを24回収集するが、1日1回行い得る。
ここで、寿命予測モデルを構築する説明は学習段階と称され、オンライン上の所望の作業負担前、又はクラウドベースサービスシステム10の稼働前に、上述したステップのデータを再び使用してもよい。寿命予測モデルを続いて稼働段階に応用し、稼働段階において寿命予測モデルの稼働は、オンラインの作業負担の衝撃を考慮する。
稼働の寿命予測モデルのステップは、簡素化してクラウドベースサービスシステム10の記憶装置200が既に取得した記憶装置200を得る(S11)。寿命範囲に基づき、記憶装置200の稼働データを複数組に分級する(S15)。全ての組の各記憶装置200からの稼働データを正常化させる。この段階では、ステップS11、ステップS15及びステップS16を繰り返すだけで、所望の分級が寿命予測モデルを参照して見つけることができる。
稼働の寿命予測モデルのステップは、簡素化してクラウドベースサービスシステム10の記憶装置200が既に取得した記憶装置200を得る(S11)。寿命範囲に基づき、記憶装置200の稼働データを複数組に分級する(S15)。全ての組の各記憶装置200からの稼働データを正常化させる。この段階では、ステップS11、ステップS15及びステップS16を繰り返すだけで、所望の分級が寿命予測モデルを参照して見つけることができる。
7日以内の故障確率モデルについては、図4を参照する。図4は、7日以内の故障率モデルを構築するワークフローである。
まず、クラウドベースサービスシステム10の記憶装置200が既に取得した履歴稼働データを得る(S21)。同様に、履歴稼働データは、バッチ単位で得られる。即ち、現有する一部を用いて7日以内の故障確率モデルを構築する記憶装置200の履歴稼働データがデータベース中に既に存在し、他方のバッチが取得した履歴稼働データが新たに加えられる。新たに得られた記憶装置200の履歴稼働データは、新たな材料と見なされて訓練を行い、予測結果がより真実に近づく。しかし、全ての履歴稼働データが使用できるわけではない。続いて、7日以内の故障確率モデルは、これら複数の稼働データをソートする必要があり(S22)、どの稼働データが故障していない記憶装置から来たのかを知り、どの稼働データが故障した記憶装置から来たのかを知る必要がある。続いて、故障した記憶装置200は、最近収集した時点から7日以内の記憶装置200からの稼働データを得て(S23)、故障していない記憶装置200からランダムに取得し、最近収集した時点から7日以内の記憶装置200の稼働データを得る(S24)。
前回収集した時点が1時間前である場合、記憶装置200の稼働データは、1時間前に収集を開始し、168時間後に終了しなければならない。重要なこととして、本発明に依ると、最近収集した時点から7日以内に、稼働データの故障した記憶装置200と、故障していない記憶装置200との比率は1:1であり、このように平衡方式により記憶装置200の故障率を予測することができる。故障していない記憶装置200の数は、故障した記憶装置200より多い。これはステップS24で、ランダムに取得した故障していない複数の記憶装置200が必要なためであり、故障していない全ての記憶装置200がその理由ではない。
最終的に、各記憶装置200からの稼働データを正常化させる(S25)。同様に、正常化により各モデルの記憶装置200の故障率をより正確に予測することができる。本発明によると、寿命予測モデル及び7日以内の故障率モデルは、継続的に将来新たに収集する稼働データを更新しなければならない。記憶装置200の履歴稼働データを収集する時間間隔は1時間であることが好ましい。
まず、クラウドベースサービスシステム10の記憶装置200が既に取得した履歴稼働データを得る(S21)。同様に、履歴稼働データは、バッチ単位で得られる。即ち、現有する一部を用いて7日以内の故障確率モデルを構築する記憶装置200の履歴稼働データがデータベース中に既に存在し、他方のバッチが取得した履歴稼働データが新たに加えられる。新たに得られた記憶装置200の履歴稼働データは、新たな材料と見なされて訓練を行い、予測結果がより真実に近づく。しかし、全ての履歴稼働データが使用できるわけではない。続いて、7日以内の故障確率モデルは、これら複数の稼働データをソートする必要があり(S22)、どの稼働データが故障していない記憶装置から来たのかを知り、どの稼働データが故障した記憶装置から来たのかを知る必要がある。続いて、故障した記憶装置200は、最近収集した時点から7日以内の記憶装置200からの稼働データを得て(S23)、故障していない記憶装置200からランダムに取得し、最近収集した時点から7日以内の記憶装置200の稼働データを得る(S24)。
前回収集した時点が1時間前である場合、記憶装置200の稼働データは、1時間前に収集を開始し、168時間後に終了しなければならない。重要なこととして、本発明に依ると、最近収集した時点から7日以内に、稼働データの故障した記憶装置200と、故障していない記憶装置200との比率は1:1であり、このように平衡方式により記憶装置200の故障率を予測することができる。故障していない記憶装置200の数は、故障した記憶装置200より多い。これはステップS24で、ランダムに取得した故障していない複数の記憶装置200が必要なためであり、故障していない全ての記憶装置200がその理由ではない。
最終的に、各記憶装置200からの稼働データを正常化させる(S25)。同様に、正常化により各モデルの記憶装置200の故障率をより正確に予測することができる。本発明によると、寿命予測モデル及び7日以内の故障率モデルは、継続的に将来新たに収集する稼働データを更新しなければならない。記憶装置200の履歴稼働データを収集する時間間隔は1時間であることが好ましい。
寿命予測モデルのシナリオと類似し、上述した7日以内の故障率モデルの説明は学習段階と称され、これは所望の作業負担がオンライン前又はクラウドベースサービスシステム10の稼働前に、上述のステップのデータが再び使用されることを意味する。7日以内の故障率モデルも続いて作動段階に応用することができ、作動段階中の7日以内の故障率モデルの稼働では、オンラインの作業負担の衝撃を考慮する。7日以内の故障率モデルは、クラウドベースサービスシステム10中の記憶装置200が既に取得した記憶装置200を得て稼働する。故障率は、7日以内の故障率モデルを参照して得ることができる。
本発明が開示するクラウドベースサービスシステム10中のデータを保護する方法の第3のステップは、各記憶装置200が入力した過去24時間の稼働データを寿命予測モデル及び7日以内の故障率モデル中に入力し、各組中の予測寿命範囲と、対応する故障率とを得る(S03)。図5を参照する。図5は、寿命予測モデル及び7日以内の故障率モデルの入力及び出力を示すテーブルである。
寿命予測モデル及び7日以内の故障率モデルが予測を提供する準備ができた後、稼働データを入力する。稼働データはN個あるが、ここでは3個使用して説明する。第1の記憶装置200(1)が有する所定の寿命範囲は、bin♯18(所定の寿命は3061時間から3240時間である)組中に入り、故障率は35%である。第2の記憶装置200(2)が有する所定の寿命範囲は、bin♯21(所定の寿命は3601時間から3780時間である)組中に入り、故障率は21%である。第3の記憶装置200(3)が有する所定の寿命範囲は、bin♯2(所定の寿命は181時間から360時間である)組中に入り、故障率は95%である。
第3の記憶装置200(3)は、短めの予測寿命と、高めの機会を有して7日以内に故障しそうである。そのため、第3の記憶装置200(3)中に記憶したデータは、紛失することを防ぐために複製しなければならない。本発明で述べる方法の最終ステップは、ステップ(S03)の結果に基づき、複数の記憶装置中のデータをバックアップする(S04)。
寿命予測モデル及び7日以内の故障率モデルが予測を提供する準備ができた後、稼働データを入力する。稼働データはN個あるが、ここでは3個使用して説明する。第1の記憶装置200(1)が有する所定の寿命範囲は、bin♯18(所定の寿命は3061時間から3240時間である)組中に入り、故障率は35%である。第2の記憶装置200(2)が有する所定の寿命範囲は、bin♯21(所定の寿命は3601時間から3780時間である)組中に入り、故障率は21%である。第3の記憶装置200(3)が有する所定の寿命範囲は、bin♯2(所定の寿命は181時間から360時間である)組中に入り、故障率は95%である。
第3の記憶装置200(3)は、短めの予測寿命と、高めの機会を有して7日以内に故障しそうである。そのため、第3の記憶装置200(3)中に記憶したデータは、紛失することを防ぐために複製しなければならない。本発明で述べる方法の最終ステップは、ステップ(S03)の結果に基づき、複数の記憶装置中のデータをバックアップする(S04)。
本発明において、寿命予測モデルは、ANN(Artificial Neural Network)アルゴリズムにより、入力された過去24時間の稼働データと、履歴稼働データとにより寿命の範囲を予測する。同様に、7日以内の故障率モデルもANNアルゴリズムにより、入力した過去24時間の稼働データ及び履歴稼働データを計算し、対応した故障率を予測する。
寿命予測モデルに応用するANNアルゴリズムと、7日間の故障率モデルに応用するANNアルゴリズムとは、同じでもよいし異なってもよい。入力した稼働データと、取得した履歴稼働データとの間のパラメータを計算できる限り、現有する多くのANNアルゴリズムを応用することもできる。寿命予測モデルは、1組(ランク番号)を表し、7日以内の故障率モデルは、各記憶装置200が提供する確率値である。
寿命予測モデルに応用するANNアルゴリズムと、7日間の故障率モデルに応用するANNアルゴリズムとは、同じでもよいし異なってもよい。入力した稼働データと、取得した履歴稼働データとの間のパラメータを計算できる限り、現有する多くのANNアルゴリズムを応用することもできる。寿命予測モデルは、1組(ランク番号)を表し、7日以内の故障率モデルは、各記憶装置200が提供する確率値である。
新しい形式の記憶装置又は新しい記憶装置(例えば、第N+1の記憶装置200(N+1))は、クラウドベースサービスシステム10に用いられるが、クラウドベースサービスシステム10には記録されない。本発明によると、ステップS01の後に、記憶装置200の履歴稼働データを収集するステップがさらに必要である。これら複数の記憶装置200は、全く新しいか、加えられたばかりのクラウドベースサービスシステム10である(S01’)。
上述したように、第N+1の記憶装置200(N+1)がオンラインとなる前に、残りの記憶装置200(1)〜200(N)は、過去に多くの稼働データを収集しており、現存する寿命予測モデルと、現存する7日以内の故障率モデルとを有する。第N+1の記憶装置200(N+1)の履歴稼働データは、その他データセンター又はテストサイトから取得し、クラウドベースサービスシステム10に発行する。ステップS01〜S02を行った後、新しい寿命予測モデル及び新しい7日以内の故障率モデルを構築することができる。第N+1の記憶装置200(N+1)は、性能を正確に予測するために、どの組のモデル(現存するモデル又は新しいモデル)にするか決定しなければならない。この判断はサーバ100の管理者が手作業で処理してもよいし、稼働データ収集装置110により行ってもよい。
稼働データ収集装置110は、アービタ(arbiter)のような役割をし、第N+1の記憶装置200(N+1)の性能に基づいて将来、決定する。決定する時間点は長くなる可能性がある。決定を発行する前に、現存するモデル又は新しいモデルは、デフォルトモデルとしてクラウドベースサービスシステム10中で実行される。2組のモデルは、第N+1の記憶装置200(N+1)に対する予測が実際の状況と大きく異なることをサーバ100が発見すると、稼働データ収集装置110は、本発明のステップに基づき、1組のモデルが提供する予測が許容範囲に入るまで、より新しいモデルを構築することを決定する。
上述したように、第N+1の記憶装置200(N+1)がオンラインとなる前に、残りの記憶装置200(1)〜200(N)は、過去に多くの稼働データを収集しており、現存する寿命予測モデルと、現存する7日以内の故障率モデルとを有する。第N+1の記憶装置200(N+1)の履歴稼働データは、その他データセンター又はテストサイトから取得し、クラウドベースサービスシステム10に発行する。ステップS01〜S02を行った後、新しい寿命予測モデル及び新しい7日以内の故障率モデルを構築することができる。第N+1の記憶装置200(N+1)は、性能を正確に予測するために、どの組のモデル(現存するモデル又は新しいモデル)にするか決定しなければならない。この判断はサーバ100の管理者が手作業で処理してもよいし、稼働データ収集装置110により行ってもよい。
稼働データ収集装置110は、アービタ(arbiter)のような役割をし、第N+1の記憶装置200(N+1)の性能に基づいて将来、決定する。決定する時間点は長くなる可能性がある。決定を発行する前に、現存するモデル又は新しいモデルは、デフォルトモデルとしてクラウドベースサービスシステム10中で実行される。2組のモデルは、第N+1の記憶装置200(N+1)に対する予測が実際の状況と大きく異なることをサーバ100が発見すると、稼働データ収集装置110は、本発明のステップに基づき、1組のモデルが提供する予測が許容範囲に入るまで、より新しいモデルを構築することを決定する。
データを保護するためには、故障率が高めであるか、寿命が短めの記憶装置200中のデータをバックアップすることが非常に大切である。唯一注意が必要なことは、バックアップの頻度である(本実施形態では、翌日にバックアップを行うか否かである)。ステップS04を行う簡単な方法は、対応した特定寿命より短い予測寿命を有する、及び/又は、特定のパーセンテージを超えた故障率を有する記憶装置200中のデータをバックアップする。
例えば、第1の記憶装置200(1)は、ソリッド・ステート・ディスクであるため、bin♯18の範囲内に入り、故障率予測が90%を超えるときに、データをバックアップする。図5中の故障率は僅か35%であるため、第1の記憶装置200(1)中のデータは、2016年5月12日の13時45分から2016年5月13日の13時45分までバックアップされない。時間間隔は、1日(24時間)だけに限定されない。これは以下で決定され、説明される。
例えば、第1の記憶装置200(1)は、ソリッド・ステート・ディスクであるため、bin♯18の範囲内に入り、故障率予測が90%を超えるときに、データをバックアップする。図5中の故障率は僅か35%であるため、第1の記憶装置200(1)中のデータは、2016年5月12日の13時45分から2016年5月13日の13時45分までバックアップされない。時間間隔は、1日(24時間)だけに限定されない。これは以下で決定され、説明される。
勿論、バックアップは記憶装置200に対するスナップショットでもよい。他の実施形態では、本発明は他のステップを提供し、ステップS04について詳しく説明する。計算して得られたスナップショット時間間隔のスナップショット作業は、記憶装置200中のデータをバックアップする(S04’)。スナップショット時間間隔は、ステップS03の結果をファジィシステム中に入力し、算出することができる。
応用するファジィシステムは、以下のステップにより構築される(図6を参照する)。複数の分級、故障率及びスナップショット時間間隔の言語値を定義し(S31)、メンバシップ関数を構築し、全ての分級、故障率及びスナップショット時間間隔の程度を描き(S32)、これら複数の分級、故障率及びスナップショット時間間隔によりファジィルールを構築する(S33)。より理解し易いように、図7を参照する。
応用するファジィシステムは、以下のステップにより構築される(図6を参照する)。複数の分級、故障率及びスナップショット時間間隔の言語値を定義し(S31)、メンバシップ関数を構築し、全ての分級、故障率及びスナップショット時間間隔の程度を描き(S32)、これら複数の分級、故障率及びスナップショット時間間隔によりファジィルールを構築する(S33)。より理解し易いように、図7を参照する。
図7を参照する。図7は、分級、故障率ならびにスナップショット時間間隔の言語値及びファジィルールを示す。分級(予測寿命)の言語値は、「非常に長い」、「長い」、「ニュートラル」、「短い」、「非常に短い」である。故障率の言語値は、「可能性が高い」、「ニュートラル」、「可能性が低い」である。スナップショット時間間隔の言語値は、「非常に長い」、「長い」、「ニュートラル」、「短い」、「非常に短い」である。ファジィルールは、各分級列及び各故障予測のコラム中で説明される。例えば、予測寿命が「長く」、故障率が「可能性が高い」場合、スナップショット時間間隔は「短い」。ファジィルールの定義は、クラウドベースサービスシステム10上で実行される作業負担のポリシーに基づいて構築される。ファジィルールは、作業負担のニーズ(SLA)に基づいて変わる。分級、故障率及びスナップショット時間間隔の程度を描くメンバシップ関数を図8、図9及び図10に示す。
以下、ファジィシステムの操作ステップについて述べる。まず、分級及び故障率を受け取る(S41)。分級及び故障率は、ステップ(S03)を行った結果である。続いて、分級及び故障率をファジィルールのメンバシップ関数に入力し、ファジィ化、ファジィ推論及び結果集約を行う(S42)。
従来技術には、ファジィ化、ファジィ推論及び結果集約を実現する多くの技術があるが、本発明はこれらだけに限定されるものではなく、例えば、その他のファジィシステムと同様、最後に非ファジィ化を行ってスナップショット時間間隔を得てもよい(S43)。同様に、非ファジィ化の方式は、ファジィ化の方式に応じて使用してもよく、これも本発明により制限されるわけではない。計算のスナップショット時間間隔は、記憶装置200に直ちに応用してもよい。勿論、全ての記憶装置200それぞれのスナップショット時間間隔は、1日1回に決めてもよく、スナップショット時間間隔は0にしてもよい(現在のところデータを保護する必要はない)。
従来技術には、ファジィ化、ファジィ推論及び結果集約を実現する多くの技術があるが、本発明はこれらだけに限定されるものではなく、例えば、その他のファジィシステムと同様、最後に非ファジィ化を行ってスナップショット時間間隔を得てもよい(S43)。同様に、非ファジィ化の方式は、ファジィ化の方式に応じて使用してもよく、これも本発明により制限されるわけではない。計算のスナップショット時間間隔は、記憶装置200に直ちに応用してもよい。勿論、全ての記憶装置200それぞれのスナップショット時間間隔は、1日1回に決めてもよく、スナップショット時間間隔は0にしてもよい(現在のところデータを保護する必要はない)。
上述した実施形態は、クラウドベースサービスシステム中でデータを収集して訓練を提供し、寿命予測寿命モデル及び7日以内の故障率モデルを更新することができるが、これらのモデルのクラウドベースサービスシステムへ応用するだけに限定されるわけではない。より広範な応用において、寿命予測モデルと、7日以内の故障率モデルは、データセンター又はクラウドベースサービスシステム中で訓練を行い、その他同じ又は類似した配置の記憶装置を有するクラウドベースサービスシステム中に応用し、有限の資源を利用して本方法を実現する長所を有する。
当該分野の技術を熟知するものが理解できるように、本発明の好適な実施形態を前述の通り開示したが、これらは決して本発明を限定するものではない。本発明の主旨と領域を逸脱しない範囲内で各種の変更や修正を加えることができる。従って、本発明の特許請求の範囲は、このような変更や修正を含めて広く解釈されるべきである。
10 クラウドベースサービスシステム
100 サーバ
101 中央処理装置
102 記憶装置入出力ユニット
103 データベース
104 ネットワーク入出力ユニット
110 稼働データ収集装置
200(1) 第1の記憶装置
200(2) 第2の記憶装置
200(3) 第3の記憶装置
200(N) 第Nの記憶装置
200(N+1) 第N+1の記憶装置
100 サーバ
101 中央処理装置
102 記憶装置入出力ユニット
103 データベース
104 ネットワーク入出力ユニット
110 稼働データ収集装置
200(1) 第1の記憶装置
200(2) 第2の記憶装置
200(3) 第3の記憶装置
200(N) 第Nの記憶装置
200(N+1) 第N+1の記憶装置
Claims (18)
- クラウドベースサービスシステム中の記憶装置の履歴稼働データを収集するステップ(A)と、
前記収集した稼働データにより寿命予測モデル及び7日以内の故障率モデルを構築するステップ(B)と、
各前記記憶装置が過去24時間の前記稼働データを前記寿命予測モデル及び前記7日以内の故障率モデルに入力し、各組中の予測寿命範囲及び対応した故障率を得るステップ(C)と、
前記ステップ(C)の結果に基づき、前記記憶装置中のデータをバックアップするステップ(D)と、を含むことを特徴とする、
クラウドベースサービスのデータ保護方法。 - 前記稼働データは、性能データ、SMART(Self−Monitoring Analysis and Reporting Technology)データ、前記記憶装置の使用可能容量、前記記憶装置の総容量又は装置メタデータであることを特徴とする請求項1に記載のクラウドベースサービスのデータ保護方法。
- 前記性能データは、レイテンシ、処理量、CPU(Central Processing Unit)負荷、メモリ使用量又はIOPS(Input/Output Per Second)であることを特徴とする請求項2に記載のクラウドベースサービスのデータ保護方法。
- 前記記憶装置は、ハードディスク又はソリッド・ステート・ディスクであることを特徴とする請求項1に記載のクラウドベースサービスのデータ保護方法。
- 前記寿命予測モデル及び前記7日以内の故障率モデルは、将来新たに収集する前記稼働データにより継続的に更新されることを特徴とする請求項1に記載のクラウドベースサービスのデータ保護方法。
- 前記記憶装置の前記履歴稼働データを収集する時間間隔は1時間であることを特徴とする請求項1に記載のクラウドベースサービスのデータ保護方法。
- 前記寿命予測モデルは、故障していない前記記憶装置と故障した前記記憶装置とに区分するステップ(B1)と、前記寿命範囲を前記故障した記憶装置に類別し、前記故障していない記憶装置の全てを特定の寿命範囲に設定するステップ(B2)と、前記寿命範囲に基づき、前記記憶装置の前記稼働データを複数組中に分級(binning)するステップ(B3)と、全ての組に対し、各前記記憶装置からの前記稼働データを正常化させるステップ(B4)と、により構築されることを特徴とする請求項1に記載のクラウドベースサービスのデータ保護方法。
- 前記寿命予測モデルは、前記寿命範囲に基づき、前記記憶装置の前記稼働データを複数組に分級させるステップ(B3’)と、全組に対し、各前記記憶装置からの前記稼働データを正常化させるステップ(B4’)と、により操作されることを特徴とする請求項1に記載のクラウドベースサービスのデータ保護方法。
- 前記7日以内の故障率モデルは、前記稼働データをソートするステップ(B5)と、故障した記憶装置と、ランダムに取得した故障していない複数の記憶装置と、に対し、最後に収集した時点から起算して7日以内の前記記憶装置の前記稼働データを得るステップ(B6)と、各前記記憶装置からの前記稼働データを正常化させるステップ(B7)と、により構築されることを特徴とする請求項1に記載のクラウドベースサービスのデータ保護方法。
- 最後に収集した時点から7日以内に収集した前記稼働データの前記故障した記憶装置と、前記故障していない記憶装置との比率は1:1であることを特徴とする請求項9に記載のクラウドベースサービスのデータ保護方法。
- 全く新しいか、加えられたばかりの前記クラウドベースサービスシステムである前記記憶装置の前記履歴稼働データを収集するステップ(A1)をさらに含むことを特徴とする請求項1に記載のクラウドベースサービスのデータ保護方法。
- 前記寿命予測モデルは、ANN(Artificial Neural Network)アルゴリズムにより、入力された過去24時間の前記稼働データと、前記履歴稼働データとにより前記予測寿命範囲を予測することを特徴とする請求項1に記載のクラウドベースサービスのデータ保護方法。
- 前記7日以内の故障率モデルは、ANNアルゴリズムにより、入力された過去24時間の前記稼働データ及び前記履歴稼働データを計算し、対応する故障率を予測することを特徴とする請求項1に記載のクラウドベースサービスのデータ保護方法。
- 前記ステップ(D)において、特定の寿命より短い予測寿命を有する、及び/又は、特定のパーセンテージを超えた故障率を有する前記記憶装置中のデータをバックアップすることを特徴とする請求項1に記載のクラウドベースサービスのデータ保護方法。
- 前記ステップ(D)において、計算により得られたスナップショット時間間隔でスナップショット作業を行い、前記記憶装置中のデータをバックアップすることを特徴とする請求項1に記載のクラウドベースサービスのデータ保護方法。
- 前記スナップショット時間間隔は、前記ステップ(C)の結果をファジィシステム中に入力し、算出することを特徴とする請求項15記載のクラウドベースサービスのデータ保護方法。
- 前記ファジィシステムは、複数の分級(bin)、故障率及びスナップショット時間間隔の言語値を定義するステップ(E1)と、メンバシップ関数を構築し、全ての前記分級、前記故障率及び前記スナップショット時間間隔の程度を描くステップ(E2)と、前記分級、前記故障率及び前記スナップショット時間間隔によりファジィルールを構築するステップ(E3)と、により形成されることを特徴とする請求項16に記載のクラウドベースサービスのデータ保護方法。
- 前記ファジィシステムは、前記分級及び前記故障率を受け取るステップ(F1)と、前記ファジィルールの前記メンバシップ関数に前記分級及び前記故障率を入力し、ファジィ化、ファジィ推論及び結果集約を行うステップ(F2)と、非ファジィ化を行って前記スナップショット時間間隔を得るステップ(F3)と、の操作を含むことを特徴とする請求項17に記載のクラウドベースサービスのデータ保護方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2017176614A JP2019053474A (ja) | 2017-09-14 | 2017-09-14 | クラウドベースサービスのデータ保護方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2017176614A JP2019053474A (ja) | 2017-09-14 | 2017-09-14 | クラウドベースサービスのデータ保護方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2019053474A true JP2019053474A (ja) | 2019-04-04 |
Family
ID=66015136
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2017176614A Withdrawn JP2019053474A (ja) | 2017-09-14 | 2017-09-14 | クラウドベースサービスのデータ保護方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2019053474A (ja) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111858120A (zh) * | 2020-07-20 | 2020-10-30 | 北京百度网讯科技有限公司 | 故障预测方法、装置、电子设备及存储介质 |
CN111966569A (zh) * | 2019-05-20 | 2020-11-20 | 中国电信股份有限公司 | 硬盘健康度评估方法和装置、计算机可读存储介质 |
CN113781257A (zh) * | 2021-08-10 | 2021-12-10 | 浙江运达风电股份有限公司 | 一种风电机组故障数据分类存储的方法及系统 |
JP2022508320A (ja) * | 2018-12-05 | 2022-01-19 | 中興通訊股▲ふん▼有限公司 | ハードディスク故障発生時期の予測方法、装置及び記憶媒体 |
CN117912534A (zh) * | 2024-03-20 | 2024-04-19 | 济南浪潮数据技术有限公司 | 一种磁盘状态预测方法、装置、电子设备及存储介质 |
-
2017
- 2017-09-14 JP JP2017176614A patent/JP2019053474A/ja not_active Withdrawn
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2022508320A (ja) * | 2018-12-05 | 2022-01-19 | 中興通訊股▲ふん▼有限公司 | ハードディスク故障発生時期の予測方法、装置及び記憶媒体 |
JP7158586B2 (ja) | 2018-12-05 | 2022-10-21 | 中興通訊股▲ふん▼有限公司 | ハードディスク故障発生時期の予測方法、装置及び記憶媒体 |
CN111966569A (zh) * | 2019-05-20 | 2020-11-20 | 中国电信股份有限公司 | 硬盘健康度评估方法和装置、计算机可读存储介质 |
CN111858120A (zh) * | 2020-07-20 | 2020-10-30 | 北京百度网讯科技有限公司 | 故障预测方法、装置、电子设备及存储介质 |
JP2021121956A (ja) * | 2020-07-20 | 2021-08-26 | ベイジン バイドゥ ネットコム サイエンス アンド テクノロジー カンパニー リミテッド | 故障予測方法、装置、電子設備、記憶媒体、及びプログラム |
JP7237110B2 (ja) | 2020-07-20 | 2023-03-10 | ベイジン バイドゥ ネットコム サイエンス テクノロジー カンパニー リミテッド | 故障予測方法、装置、電子設備、記憶媒体、及びプログラム |
US11675649B2 (en) | 2020-07-20 | 2023-06-13 | Beijing Baidu Netcom Science And Technology Co., Ltd. | Fault prediction method, apparatus and storage medium |
CN111858120B (zh) * | 2020-07-20 | 2023-07-28 | 北京百度网讯科技有限公司 | 故障预测方法、装置、电子设备及存储介质 |
CN113781257A (zh) * | 2021-08-10 | 2021-12-10 | 浙江运达风电股份有限公司 | 一种风电机组故障数据分类存储的方法及系统 |
CN117912534A (zh) * | 2024-03-20 | 2024-04-19 | 济南浪潮数据技术有限公司 | 一种磁盘状态预测方法、装置、电子设备及存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10157105B2 (en) | Method for data protection for cloud-based service system | |
JP2019053474A (ja) | クラウドベースサービスのデータ保護方法 | |
US10956277B2 (en) | Optimizing data backup schedules | |
US10769007B2 (en) | Computing node failure and health prediction for cloud-based data center | |
US20200034665A1 (en) | Determining validity of machine learning algorithms for datasets | |
US20150205657A1 (en) | Predicting failure of a storage device | |
US8140914B2 (en) | Failure-model-driven repair and backup | |
US11392826B2 (en) | Neural network-assisted computer network management | |
Dai et al. | Self-healing and hybrid diagnosis in cloud computing | |
US20160232450A1 (en) | Storage device lifetime monitoring system and storage device lifetime monitoring method thereof | |
US8904144B1 (en) | Methods and systems for determining at risk index for storage capacity | |
CN105511957A (zh) | 用于生成作业告警的方法和系统 | |
KR20210108874A (ko) | 기계 학습을 사용하여 스토리지 장치 장애를 예측하는 시스템 및 장치 | |
US20210366268A1 (en) | Automatic tuning of incident noise | |
US20220036224A1 (en) | Determination of storage configuration for enterprise distributed environment | |
Qian et al. | P3: Priority based proactive prediction for soon-to-fail disks | |
US9710178B2 (en) | Optimizing volume placement based upon desired response time and priority | |
CN108021484B (zh) | 云端服务系统中磁盘预期寿命值的延长方法及其系统 | |
US11334410B1 (en) | Determining aberrant members of a homogenous cluster of systems using external monitors | |
US20230035666A1 (en) | Anomaly detection in storage systems | |
TWI608358B (zh) | 用於雲端服務系統中資料保護的方法 | |
EP3457282A1 (en) | Method for data protection in cloud-based service system | |
Lyu et al. | Assessing the maturity of model maintenance techniques for AIOps solutions | |
TW201816625A (zh) | 用於延長雲端服務系統中磁碟預期壽命值的方法及使用該方法的系統 | |
JP2020155008A (ja) | 制御方法,情報処理装置および制御プログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20200529 |
|
A761 | Written withdrawal of application |
Free format text: JAPANESE INTERMEDIATE CODE: A761 Effective date: 20200708 |