JP2015510201A - クラウドネットワークにおける迅速な災害回復準備のための方法および装置 - Google Patents

Abstract

様々な実施形態は、クラウドネットワークにおいて迅速な災害回復準備を行う方法および装置を提供し、これは災害事象をプロアクティブに検出し、クラウドリソースを迅速に割り当てる。迅速な災害回復準備は、回復トラフィックの急激な増加が（１つまたは複数の）回復アプリケーション／（１つまたは複数の）リソースに到達する前に、（１つまたは複数の）回復アプリケーション／（１つまたは複数の）リソース上の能力をプロアクティブに拡大することによって、目標回復時間（ＲＴＯ）を短縮することができる。さらにその上、迅速な災害回復準備は、「通常動作」中よりもさらに急速に能力を拡大することによってＲＴＯを短縮することができ、通常動作では、ある期間のあいだに負荷が利用しきい値を超えた後で、能力は、緩やかな拡大によって増加する。

Description

本発明は、一般にクラウドネットワークにおいて災害回復を行うための方法および装置に関する。

この項では、本発明をより良く理解することを容易にするうえで有用となり得る態様を紹介する。したがって、この項の記述は、この観点から読まれるべきであり、何が従来技術にあるかまたは何が従来技術にないかに関して自ら認めるものとして理解されるべきではない。

地理的に重複するデータセンタに対するサービス回復は、プライマリデータセンタサイトのサービスを利用できないようにする不可抗力または災害事象に続く業務の継続性を確保することができる。いくつかの知られたクラウドネットワーク災害回復スキームでは、アプリケーション用のクラウドリソースは、従来型のリソース割り当てスキームに基づいて割り当てられる。これらのスキームは、従来、災害事象に起因する新しいパターンの着信アプリケーション要求に応じて、割り当てられたアプリケーションリソースを拡大させ縮小させる。

いくつかの他の知られた災害回復スキームでは、システムのいくつかの部分は、予測される災害回復リソースの必要性を満足させるために過剰なリソースを含むことができる。

様々な実施形態は、クラウドネットワークにおいて迅速な災害回復準備を行う方法および装置を提供し、これは災害事象をプロアクティブに検出し、クラウドリソースを迅速に割り当てる。迅速な災害回復準備は、回復トラフィックの急激な増加が（１つまたは複数の）回復アプリケーション／（１つまたは複数の）リソースに到達する前に、（１つまたは複数の）回復アプリケーション／（１つまたは複数の）リソースについての能力をプロアクティブに拡大することによって、目標回復時間（ＲＴＯ）−災害事象に続いて回復データセンタにおいてユーザサービスを回復させるためにかかる時間−を短縮することができる。さらにその上、迅速な災害回復準備は、「通常動作」中よりもさらに急速に能力を拡大することによってＲＴＯを短縮することができ、通常動作では、ある期間のあいだに負荷が利用しきい値を超えた後で、能力は、緩やかな拡大によって増加する。有利には、災害事象を検出することおよび回復サイトへのクラウドネットワークリソースを迅速に拡大させるように手配することは、過剰なリソースを確保せずにネットワーク輻輳、飽和、または過負荷のリスクを低減し、これによって、影響を受けたユーザへのサービス回復を加速する。

一実施形態では、迅速な災害回復準備を行うために装置が提供される。本装置は、データストレージと、データストレージに通信可能に結合されたプロセッサとを含む。プロセッサは、第１のネットワークリソースからネットワークメトリックスをモニタし、受信したネットワークメトリックスに基づいて第２のネットワークリソースの利用可能性に影響を与える災害条件が生じたと判定し、第３のネットワークリソースに災害警戒警報メッセージを送るように構成される。ここでは、第１、第２および第３のネットワークリソースは、異なるリソースである。

上記の実施形態のいくつかでは、モニタしたネットワークメトリックスは、モニタしたトラフィックフローを含む。モニタしたトラフィックフローは、１つまたは複数のトラフィックフロー値を含む。

上記の実施形態のいくつかでは、災害条件が生じたという判定は、モニタしたトラフィックフローが中断されているという検出に基づく。

上記の実施形態のいくつかでは、災害条件が生じたという判定は、モニタしたトラフィックフローが異常なトラフィックパターンを有するという検出に基づく。

上記の実施形態のいくつかでは、モニタしたネットワークメトリックスは、警告機構情報を含む。

上記の実施形態のいくつかでは、警告機構情報は、外部由来のセンサ情報である。

上記の実施形態のいくつかでは、災害条件が生じたという判定は、確信レベルに基づく。

上記の実施形態のいくつかでは、災害条件が生じたという判定は、災害重大性レベルを判定するようにプロセッサをさらにプログラミングすることを含む。

上記の実施形態のいくつかでは、プロセッサは：複数のネットワークリソースを解析し、複数のネットワークリソースに基づいて災害回復勧告を決定し、災害回復勧告に基づいて第３のネットワークリソースを選択するようにさらにプログラミングされる。

上記の実施形態のいくつかでは、プロセッサは、災害回復勧告に基づいて第３のネットワークリソースを選択するようにさらにプログラミングされる。

上記の実施形態のいくつかでは、プロセッサは、災害回復勧告に基づいて災害警戒警報メッセージを作成するようにさらにプログラミングされる。

第２の実施形態では、装置は、迅速な災害回復準備を行うために提供される。本装置は、データストレージと、データストレージに通信可能に結合されたプロセッサとを含む。プロセッサは：災害警戒警報メッセージを受信し、迅速な弾力的（ｅｌａｓｔｉｃ）拡大動作を実行するようにプログラミングされ、迅速な弾力的拡大動作は：利用しきい値を超える前にネットワークリソースの拡大を含む。

上記の実施形態のいくつかでは、迅速な弾力的拡大動作は、利用しきい値を超えたときに割り当てられるリソースの通常の速度拡大の２倍よりも大きい速度拡大をさらに含む。

上記の実施形態のいくつかでは、迅速な弾力的拡大動作は、受信した災害警戒警報メッセージに基づく速度拡大をさらに含む。

上記の実施形態のいくつかでは、プロセッサは：トラフィック負荷をモニタし、モニタしたトラフィック負荷に基づいて災害条件が存在しないと判定し、災害条件が存在しないという判定に応答して、弾力的縮小動作を実行するようにさらにプログラミングされ、弾力的縮小動作は、ネットワークリソースの拡大部の少なくとも一部を解放する。

第３の実施形態では、システムは、迅速な災害回復準備を行うために提供される。本システムは：少なくとも１つのネットワークリソースと、複数のデータセンタと、少なくとも１つのネットワークリソースおよび複数のデータセンタに通信可能に結合されたリソースモニタとを含む。複数のデータセンタは、災害の影響を受けたデータセンタおよび回復データセンタを含む。リソースモニタは：少なくとも１つのネットワークリソースからネットワークメトリックスを受信し、受信したネットワークメトリックスに基づいて災害の影響を受けたデータセンタの利用可能性に影響を与える災害条件が生じたと判定し、回復データセンタへ災害警戒警報メッセージを送るようにプログラミングされる。回復データセンタは：災害警戒警報メッセージを受信し、迅速な弾力的拡大動作を実行するようにプログラミングされ、迅速な弾力的拡大動作は：利用しきい値を超える前にネットワークリソースの拡大を含む。

上記の実施形態のいくつかでは、迅速な弾力的拡大動作は、利用しきい値を超えたときに割り当てられるリソースの通常の速度拡大の２倍よりも大きい速度拡大をさらに含む。

上記の実施形態のいくつかでは、迅速な弾力的拡大動作は、受信した災害警戒警報メッセージに基づく速度拡大をさらに含む。

第４の実施形態では、方法は、迅速な災害回復準備を行うために提供される。本方法は：第１のネットワークリソースからネットワークメトリックスを受信するステップと、受信したネットワークメトリックスに基づいて第２のネットワークリソースの利用可能性に影響を与える災害条件が生じたと判定するステップと、第３のネットワークリソースへ災害警戒警報メッセージを送るステップとを含む。ここでは、第１、第２および第３のネットワークリソースは、異なるリソースである。

上記の実施形態のいくつかでは、受信したネットワークメトリックスは、モニタしたトラフィックフローを含み、モニタしたトラフィックフローは、１つまたは複数のトラフィックフロー値を含む。

上記の実施形態のいくつかでは、災害条件が生じたと判定するステップは、モニタしたトラフィックフローが中断されていると検出するステップに基づく。

上記の実施形態のいくつかでは、災害条件が生じたと判定するステップは、確信レベルに基づく。

上記の実施形態のいくつかでは、本方法は：災害警戒警報メッセージを受信するステップと、迅速な弾力的拡大動作を実行するステップをさらに含み、迅速な弾力的拡大動作は：利用しきい値を超える前にネットワークリソースを拡大するステップを含む。

様々な実施形態が、添付した図面に図示される。

迅速な災害回復準備アーキテクチャ１１０の実施形態を含むクラウドネットワークの図である。 クラウドネットワークにおいて迅速な災害回復準備を行うための方法２００の実施形態を図示する流れ図である。 図２のステップ２３０に図示したような、クラウドネットワークメトリックスに基づいて災害を検出するためのリソースモニタ（例えば、図１のリソーモニタ１５０）のための方法３００の実施形態を図示する流れ図である。 図２のステップ２４０に図示したような、迅速な災害回復準備を実行するための回復リソース（例えば、図１のデータセンタ１８０内のアプリケーションまたはネットワーク１３０内のリソース）のための方法４００の実施形態を図示する流れ図である。 図１のリソースモニタ１５０、データセンタ１８０のうちの１つの仮想マシン、または図１のネットワーク１３０のリソースのうちの１つなどの様々な装置５００の実施形態の模式図である。

理解することを容易にするために、同一の参照番号が、実質的に同じもしくは類似の構造または実質的に同じもしくは類似の機能を有する要素を明示するために使用された。

本明細書および図面は、本発明の原理を単に例示する。したがって、本明細書において明確に記述されていないまたは示されていないにも拘わらず、本発明の原理を取り込んでおり、かつ本発明の範囲内に含まれる様々な配置を、当業者なら考案することが可能であろうことが理解されよう。さらにその上、本明細書において列挙したすべての例は、本技術をさらに進めるために本発明の原理および（１人または複数の）発明者によって提供された概念を理解する際に読者を助けるために、明確に教育上の目的のためだけであるように原理的に意図され、このような具体的に列挙した例および条件に限定されないように解釈されるものである。加えて、本明細書において使用するように「または（ｏｒ）」という用語は、別段示されていない限り、排他的でないことを指す。また、いくつかの実施形態は、新しい実施形態を形成するために１つまたは複数の他の実施形態と組み合わせられることが可能であるので、本明細書において説明する様々な実施形態は、必ずしも相互に排他的である必要はない。

様々な実施形態は、クラウドネットワークにおいて迅速な災害回復準備を行う方法および装置を提供し、これは、災害事象をプロアクティブに検出し、クラウドリソースを迅速に割り当てる。迅速な災害回復準備は、回復トラフィックの急激な増加が（１つまたは複数の）回復アプリケーション／（１つまたは複数の）リソースに到達する前に、（１つまたは複数の）回復アプリケーション／（１つまたは複数の）リソースの能力をプロアクティブに拡大することによってＲＴＯを短縮することができる。さらにその上、迅速な災害回復準備は、「通常動作」中よりもさらに迅速に能力を拡大することによってＲＴＯを短縮することができ、通常動作では、ある期間のあいだに負荷が利用しきい値を超えた後で、能力は、緩やかな拡大によって増加する。

図１は、迅速な災害回復準備アーキテクチャの実施形態を含むクラウドネットワーク１００を図示する。クラウドネットワーク１００は、通信パスを介してデータセンタ１８０−ａ−１８０−ｃ（一括して、データセンタ１８０）内のアプリケーションへアプリケーション要求を送る１つまたは複数のクライアント１２０−ａ−１２０−ｃ（一括して、クライアント１２０）を含む。通信パスは、クライアント通信チャネル１２５−ａ、１２５−ｂ、および１２５−ｃ（一括して、クライアント通信チャネル１２５）のうちの１つ、ネットワーク１３０、ならびにデータセンタ通信チャネル１８５−ａ、１８５−ｂ、および１８５−ｃ（一括して、データセンタ通信チャネル１８５）のうちの１つを含むことができる。クラウドネットワーク１００は、クラウドネットワークリソースをモニタし、かつリソースモニタ通信チャネル１５５を介して（１つまたは複数の）災害警戒警報メッセージを送るリソースモニタ１５０をやはり含む。

本明細書において使用するように「クラウドネットワークリソース」という用語は、すべての割り当てられたリソースを含むように広く理解されるべきである。例えば、クラウドネットワークリソースは、装置（例えば、ルータおよびワイヤレス基地局）または設備（例えば、光ファイバおよび同軸ケーブル）を含むことができる。

クライアント１２０は、データセンタ１８０上にインスタンス化されたアプリケーションインスタンスのうちの１つに向けられた（１つまたは複数の）アプリケーション要求を開始する任意のタイプのまたは任意の数の（１つまたは複数の）クライアントマシンであってもよい。例えば、クライアントは：サーバ、携帯電話、タブレット、コンピュータ、携帯情報端末（ＰＤＡ）、イーリーダ（ｅ−ｒｅａｄｅｒ）、ネットワークデバイス（例えば、スイッチまたはルータ）、等、であってもよい。

通信チャネル１２５および１８５は：ワイヤレス通信（例えば、ＬＴＥ、ＧＳＭ（登録商標）、ＣＤＭＡ、ブルートゥース）、フェムトセル通信（例えば、ＷｉＦｉ）、パケットネットワーク通信（例えば、ＩＰ）、ブロードバンド通信（例えば、ＤＯＣＳＩＳおよびＤＳＬ）、ストレージ通信（例えば、ファイバチャネル、ｉＳＣＳＩ）、等、などの１つまたは複数の通信チャネルを介してアプリケーション要求を検索することまたは応答することをサポートすることができる。単一接続として示されているが、通信チャネル１２５および１８５は、クライアント１２０とデータセンタ１８０上にインスタンス化されたアプリケーションインスタンスとの間の通信をサポートする任意の数の通信チャネルまたは通信チャネルの組合せであってもよいことを理解されたい。

ネットワーク１３０は、クライアント１２０とデータセンタ１８０上にインスタンス化されたアプリケーションインスタンスとの間の通信を容易にするための任意の適切な（１つまたは複数の）ネットワークであってもよい。例えば、ネットワーク１３０は：（１つまたは複数の）ローカルエリアネットワーク（ＬＡＮ）、（１つまたは複数の）ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、等、の組合せであってもよい。

リソースモニタ１５０は、クラウドネットワークリソースまたは警告機構をモニタする。特に、リソースモニタ１５０がデータセンタ（例えば、データセンタ１８０−ａ）に影響を及ぼす災害を示している（１つまたは複数の）条件を検出すると、リソースモニタ１５０は、（１つまたは複数の）回復アプリケーション／（１つまたは複数の）リソース（例えば、データセンタ１８０−ｂ上にインスタンス化されたアプリケーションインスタンスまたはネットワーク１３０内のルータ）へ（１つまたは複数の）災害警戒警報メッセージを送る。リソースモニタ１５０がネットワーク１３０の外に示されているが、リソースモニタ１５０は、ネットワーク１３０内に存在してもよいことを理解されたい。

リソースモニタ通信チャネル１５５は：ワイヤレス通信（例えば、ＬＴＥ、ＧＳＭ、ＣＤＭＡ、ブルートゥース）、フェムトセル通信（例えば、ＷｉＦｉ）、パケットネットワーク通信（例えば、ＩＰ）、ブロードバンド通信（例えば、ＤＯＣＳＩＳおよびＤＳＬ）、ストレージ通信（例えば、ファイバチャネル、ｉＳＣＳＩ）、等、などの１つもしくは複数の通信チャネルを介してクライアント１２０、ネットワーク１３０のリソース（図示せず）、またはデータセンタ１８０内のアプリケーションへのメッセージを受信することまたは送信することをサポートすることができる。単一接続として示されているが、リソースモニタ通信チャネル１５５は、リソースモニタ１５０とクライアント１２０、ネットワーク１３０のリソース（図示せず）、またはデータセンタ１８０内のアプリケーションとの間の通信をサポートする任意の数の通信チャネルまたは通信チャネルの組合せであってもよいことを理解されたい。

データセンタ１８０は、地理的に分散され、任意の構成を含むことができる。データセンタ１８０は、クライアント１２０からのアプリケーション要求のサービスを提供するように作成されたアプリケーションを実行させる仮想マシンを備えるリソースを含む。特に、データセンタ１８０内の少なくとも１つのアプリケーションは、リソースモニタ１５０から（１つまたは複数の）災害警戒警報メッセージを受信するように構成される。受信した災害警戒警報メッセージに応じて、データセンタ１８０は、影響を受けたクライアント１２０のサービス回復を加速するために（１つまたは複数の）回復アプリケーション／（１つまたは複数の）リソースをプロアクティブに割り当てる。

（１つまたは複数の）回復アプリケーション／（１つまたは複数の）リソースをプロアクティブにかつ迅速に割り当てることによって、回復を必要とするクライアント１２０の大部分が（１つまたは複数の）回復行為を開始する前には、能力の弾力的サージ（ｅｌａｓｔｉｃ ｓｕｒｇｅ）がオンラインであることを理解されたい。例えば、災害事象は、多数のクライアント１２０が短時間のウィンドウ内に回復サイトへ回復する（例えば、接続し、ログオンしおよび認証され、ならびにセッションを確立する）ように試みさせることがあり、これは、回復データセンタを過負荷にすることがある。したがって、急速に増加する負荷は、輻輳制御（これは顧客サービス品質を低下させることがある）を用いて過負荷をトリガせずに効果的に扱われることが可能である。

リソースモニタ１５０のいくつかの実施形態では、災害を示す条件（すなわち、災害条件）は、トラフィックフローの劇的な変化、異常なトラフィックパターンまたは信号消失指標などの明白なアラーム／故障指示を含むことができる。さらなる実施形態では、リソースモニタ１５０は、しきい数の信号消失指標を受信した後で、災害条件があると判定するであろう。いくつかの信号消失指標が、光ファイバなどの伝送媒体の破壊を示すことがあることを理解されたい。

リソースモニタ１５０のいくつかの実施形態では、警告機構は、外部由来のセンサまたはモニタしたデータ供給部からの入力部を含むことができる。これらの実施形態のいくつかでは、外部由来のセンサは、地震計モニタである。これらの実施形態のいくつかでは、モニタしたデータ供給部は、国家的／国際的津波警告機構または他の災害警告機構へのインターネット接続である。

いくつかの実施形態では、データセンタ１８０は、プロセッサ／ＣＰＵコア、ネットワークインターフェース、メモリデバイスまたはデータストレージデバイスなどのリソースを含むことができる。その上、データセンタ１８０は：１つまたは複数のサーバ、プロセッサ、メモリ、ネットワークインターフェースまたはストレージデバイスなどの構成要素からなるブレードなどの任意の適切な物理ハードウェア構成であってもよい。これらの実施形態のいくつかでは、データセンタは、互いに遠く離れたクラウドネットワークリソースを含むことができる。プロセッサ、ネットワークインターフェース、メモリデバイスまたはデータストレージなどのリソースを割り当てることによって、データセンタは、アプリケーションインスタンスまたは仮想マシンの処理能力、帯域幅能力、ＲＡＭおよび固定ストレージ能力をスケーリングすることができることを理解されたい。

図２は、クラウドネットワークにおいて迅速な災害回復準備を行うための方法２００の実施形態を図示する流れ図を示す。

方法２００では、ステップ２２０は、（例えば、図１のネットワーク１３０のリソース（図示せず）もしくは図１のデータセンタ１８０内のアプリケーションによって）クラウドネットワークリソースからまたは警告機構からクラウドネットワークメトリックスをモニタするステップを含む。クラウドネットワークメトリックスは、災害条件の存在を判定するためまたは災害条件から回復させることを容易にするためにネットワーク条件を判定するために使用されることが可能な任意の適切なメトリックスであってもよい。例えば、クラウドネットワークメトリックスは：トラフィックフロー値、ローディング／能力値、ネットワーク提供、健全性メッセージ（例えば、ハートビートメッセージ）、ネットワークアラーム（例えば、複数のファイバ断線）、外部由来のアラーム、データフィード、等、を含むことができる。

方法２００では、ステップ２３０は、（例えば、図１のリソースモニタ１５０によって）クラウドネットワークメトリックスに基づいて災害条件を判定するステップを含む。特に、集めたクラウドネットワークメトリックスの特性が、災害条件が生じていることを示すかどうかを判定するために、クラウドネットワークメトリックスは解析される。災害条件が生じている場合には、方法を実行している装置は、（１つまたは複数の）回復アプリケーション／（１つまたは複数の）リソースへ災害警戒警報メッセージを送り、ステップ２４０に進み、それ以外では装置はステップ２２０に戻る。災害条件の検出は、実際の災害が生じたことまたは生じるであろうことを必要としないことを理解されたい。むしろ、災害条件検出は、災害が生じた可能性があることをモニタしたクラウドネットワークメトリックスが示すことを示すにすぎない。災害の絶対的な確認の前に災害警戒警報メッセージを送ることによって長くなった時間の合間を、回復トラフィックの可能性のある急激な増加の前に回復準備を終わらせるために（１つまたは複数の）回復アプリケーション／（１つまたは複数の）リソースに与えることができるので有利である。

方法２００では、ステップ２４０は、（例えば、図１のネットワーク１３０のリソース（図示せず）または図１のデータセンタ１８０上で実行しているアプリケーションインスタンスによって）迅速な災害回復準備を実行するステップを含む。特に、（１つまたは複数の）回復アプリケーション／（１つまたは複数の）リソースは、災害警戒警報メッセージを受信し、（１つまたは複数の）災害の影響を受けたアプリケーション／（１つまたは複数の）リソースから転じられることが予想される回復トラフィックの予想される急激な増加を取り扱うためにクラウドネットワークリソースをプロアクティブに（再び）割り当てる。

いくつかの実施形態では、ステップ２２０は、図１のリソースモニタ１５０によって実行される。

図３は、図２のステップ２３０に図示したように、クラウドネットワークメトリックスに基づいて災害を検出するためのリソースモニタ（例えば、図１のリソーモニタ１５０）のための方法３００の実施形態を図示する流れ図を示す。本方法は、図２のステップ２２０中に取り込んだようなクラウドネットワークメトリックスをモニタするステップ（ステップ３２０）を含む。本方法を実行する装置は、次に、受信したクラウドネットワークメトリックスが災害事象を示しているかどうかを判定し（ステップ３３０）、そうである場合には、任意選択で緩和方策を決定し（ステップ３４０）、図２のステップ２４０および図４で説明するように、１つまたは複数の災害警戒警報メッセージを作成し（ステップ３５０）、（１つまたは複数の）回復アプリケーション／（１つまたは複数の）リソースへ送る（ステップ３６０）。

方法３００では、ステップ３２０は、１つまたは複数のソースから（例えば、リソースモニタ通信チャネル１５５を介してまたは直接リソースモニタ１５０から）１つまたは複数のクラウドネットワークメトリックスをモニタするステップを含む。いくつかの実施形態では、リソースモニタは、モニタすべきクラウドネットワークメトリックスを選択するまたは準備することができる。例えば、リソースモニタは、データセンタ（例えば、図１のデータセンタ１８０）のうちの１つまたは複数へのまたはからの（１つまたは複数の）トラフィックフローをモニタすることができる。

方法３００では、ステップ３３０は、受信したクラウドメトリックスに基づいて災害を検出するステップを含む。特に、集めたクラウドネットワークメトリックスの特性が、災害条件が生じていることを示すかどうかを判定するために、クラウドネットワークメトリックスは解析される。

方法３００は、任意選択でステップ３４０を含む。ステップ３４０は、緩和方策を決定するステップを含む。特に、リソースモニタは、クラウドネットワークリソース（例えば、図１のネットワーク１３０またはデータセンタ１８０内のアプリケーション）のネットワーク準備、ステータス、性能または損傷の知識を有することができる。この知識に基づいて、リソースマネージャは、災害回復勧告を行うことができる。

方法３００では、ステップ３５０は、災害警戒警報メッセージを作成するステップを含む。特に、メッセージは、災害条件が検出されているかまたは回復準備情報を提供する指標を含む。

方法３００では、ステップ３６０は、（１つまたは複数の）回復アプリケーション／（１つまたは複数の）リソースへ１つまたは複数の災害警戒警報メッセージを送るステップを含む。特に（１つまたは複数の）災害警戒警報メッセージのうちの１つまたは複数は、本方法を実行する装置が決定する（１つまたは複数の）回復アプリケーション／（１つまたは複数の）リソースへ向けられ、図２のステップ２４０および図４に説明するように、迅速な災害回復準備を実行するために（１つまたは複数の）災害警戒警報メッセージを使用するであろう。

方法３００は、任意選択でステップ３７０を含む。ステップ３７０は、災害解除メッセージを送るステップを含む。特に、災害警告または災害事象が終わった後で、（１つまたは複数の）回復アプリケーション／（１つまたは複数の）リソースは、可能性のある災害に対処するために確保されていた回復クラウドネットワークリソースを解放するメッセージを送られる。

いくつかの実施形態では、ステップ３２０は、リソースモニタ自体からクラウドネットワークメトリックスを収集するリソースモニタ（例えば、図１のリソースモニタ１５０）を含む。例えば、リソースモニタがキャリアのネットワークとデータセンタとの間のネットワーク内のルータ／ＩＰネットワーク網接続として設置される場合である。

いくつかの実施形態では、ステップ３２０は、ネットワーク内のリソース（例えば、図１のネットワーク１３０の一部であるキャリアのネットワーク（図示せず）内のルータ）からデータセンタ（例えば、図１のデータセンタ１８０−ｂ）へのＩＰネットワーク網接続をモニタするステップを含む。これらの実施形態のいくつかでは、ステップ３３０は、ＩＰトラフィックのフローが即座に低下するまたはデータセンタへのアクセス接続が失敗するもしくは切断されると、モニタしたデータセンタが災害を被っているはずであることを検出するステップを含む。ＩＰトラフィックフローだけでなく任意のトラフィックフローがモニタされてもよいことを理解されたい。

いくつかの実施形態では、ステップ３３０は、災害条件が存在するかどうかを判定するために１つよりも多くのクラウドネットワークメトリックスを集合させるステップを含む。

いくつかの実施形態では、ステップ３３０は、災害が生じたことの「確信レベル」に基づいて災害条件が存在すると判定するステップを含む。これらの実施形態のいくつかでは、確信レベルは、意欲的であってもよい。例えば、実際の災害の「確信レベル」が５０パーセント（５０％）以下である時に、災害条件の判定はトリガされてもよい。サービスプロバイダは、誤検出（ｆａｌｓｅ ｐｏｓｉｔｉｖｅ）（すなわち、決して生じない災害に対して準備すること）よりも誤不検出（ｆａｌｓｅ ｎｅｇａｔｉｖｅ）（すなわち、実際の災害に対してプロアクティブに準備しないこと）に関心がある場合があることを理解されたい。

ステップ３３０の第１の実施形態では、ステップ３２０で受信したクラウドネットワークメトリックスが災害事象を示すかどうかを検出するために、ルールに基づくモデリングが使用される。例えば、モニタしたトラフィックフローのトラフィックレベルが限界期間のあいだずっとトラフィックしきい値まで低下するまたはトラフィックしきい値よりも下である（例えば、トラフィックフローが１分間０まで低下する）場合には、災害が検出される。

ステップ３３０の第２の実施形態では、ステップ３２０で受信したクラウドネットワークメトリックスが災害事象を示すかどうかを検出するために、従来型の予測解析プログラムが使用される。例えば、モニタしたトラフィックフローが、従来型の予測解析プログラムへと入力されことがある。このような予測解析プログラムは、次に、災害が検出されているかどうかの判定を下すために、格納されたトレーニングトラフィックフローパターンに対して入力したトラフィックフローパターンを分類することができる。これらの実施形態のいくつかでは、予測解析プログラムは、確信レベルに基づいて災害検出分類を行うために学習することができる。

いくつかの実施形態では、ステップ３４０は、ネットワークステータス／性能／損傷情報に基づいて緩和方策を決定するステップを含む。これらの実施形態のいくつかでは、緩和方策の決定は、下記のうちの１つまたは複数を含む：
１）どの（１つまたは複数の）データセンタ／（１つまたは複数の）アプリケーションインスタンスが影響を受けた可能性があるかを推定するステップ（例えば、サンノゼの地震は、シリコンバレー地域内のデータセンタに強い影響を与えた可能性がある）、
２）（１つまたは複数の）災害警戒警報メッセージをどの（１つまたは複数の）回復アプリケーション／（１つまたは複数の）リソース（例えば、図１のネットワーク１３０内のルータまたはデータセンタ１８０−ｂ内のアプリケーション）に向けるかを決定するステップ、
３）影響を受けたユーザのサービスを効率的に回復させるために、決定した（１つまたは複数の）回復アプリケーション／（１つまたは複数の）リソースに準備を行わせるために、回復リソースのサージングまたは回復ポリシなどの回復準備を決定するステップ（例えば、図１のネットワーク１３０内のルータにおいてＱｏＳポリシを変更するステップ、またはデータセンタ１８０−ｂ内のアプリケーションにおいて回復リソースをサージングするステップ）。

いくつかの実施形態では、ステップ３４０は、複数の災害重大性レベルを設定するステップを含む。これらの実施形態のいくつかでは、災害重大性レベルは、災害条件の確信レベルに基づく。これらの実施形態のいくつかでは、災害重大性レベルは、災害の可能性のある強い影響に基づく。例えば、断線したファイバは、１つのデータセンタに影響を与えるだけであり得るが一方で、地震または津波は、複数のデータセンタを含む全体の領域に影響を与えることがある。複数のデータセンタと比較して１つのデータセンタに影響を与える災害への対応が異なる場合があることを理解されたい。例えば、異なるＱｏＳポリシが適用されることがある、またはリソースが本質的でないカスタマサービスの前に緊急サービスに対して割り当てられることがある。これらの実施形態のいくつかでは、災害警戒警報メッセージは、災害重大性レベルに基づくであろう。

いくつかの実施形態では、ステップ３４０は、対応する複数の災害重大性レベルへの複数の災害応答を設定するステップを含む。例えば、赤、黄色、および緑の災害重大性レベルが設定される場合には、適用するＱｏＳポリシについての勧告または各災害レベルに対して確保するリソースの量は、異なってもよい。

いくつかの実施形態では、ステップ３４０は、（１つまたは複数の）回復アプリケーション／（１つまたは複数の）リソースについての地理的情報を決定するステップ、およびさらに、緩和方策を地理的情報に基づくものにするステップを含む。例えば、災害の影響を受けたデータセンタの境界が、ある地理的地域内で検出されたと判定された場合、リソースモニタは、影響を受けた地理的地域の外にある回復データセンタを選択することができる。

ステップ３４０のいくつかの実施形態では、緩和方策は、（１つまたは複数の）回復アプリケーション／（１つまたは複数の）リソースへの回復負荷の配分を決定するステップを含む。例えば、災害の影響を受けたデータセンタ（例えば、図１のデータセンタ１８０−ａ）からの負荷は、分散され、回復データセンタ（例えば、図１のデータセンタ１８０−ａおよび１８０−ｂ）に負荷バランスさせるであろう。

いくつかの実施形態では、ステップ３４０は、１つまたは複数のクラウドネットワークリソース（例えば、図１のデータセンタ１８０のアプリケーションのうちの１つもしくは複数またはネットワーク１３０の１つもしくは複数のリソース（図示せず））とメッセージを交換するステップを含む。例えば、リソースモニタ（例えば、図１のリソースモニタ１５０）は、（１つまたは複数の）リソース能力を勧告することまたは回復データセンタがメッセージ要求に含まれる指定された（１つまたは複数の）リソース能力を取り扱うことが可能であるかどうかを要求することのいずれかを可能性のある回復データセンタ（例えば、データセンタ１８０−ｂ）上のアプリケーションへメッセージを送ることができる。これらの実施形態では、緩和方策勧告は、このメッセージ交換に基づくことがある。

いくつかの実施形態では、ステップ３４０は、トラフィックを自律的に向け直すステップを含む（例えば、災害の影響を受けたデータセンタから離れた回復データセンタへトラフィックをシフトさせるためにＤＮＳを自律的に変更する）。

いくつかの実施形態では、ステップ３４０は、災害の影響を受けたデータセンタ上で実行している（１つまたは複数の）アプリケーションの必要条件を収集するステップを含む。特に、アプリケーションの必要条件およびいくつの仮想マシンが存在するか、仮想マシンがどのようにして接続されるか、アプリケーションのデータアクセスパターン、またはアプリケーションのサービス必要条件などの情報を含むアプリケーションの様々なリソースのトポロジが、収集されることがある。例えば、リソースモニタ１５０が災害の検出の直前に使用されているデータセンタ１８０−ａのリソースの知識を有する場合には、リソースモニタ１５０は、これらの必要条件の少なくともあるサブセットに基づいて回復データセンタ（例えば、１８０−ｂ）への回復勧告（例えば、予想される負荷値）を作成し、渡すことができる。

ステップ３４０のいくつかの実施形態では、（１つまたは複数の）回復アプリケーション／（１つまたは複数の）リソースのうちの１つまたは複数についての回復勧告が、決定されることがある。これらの実施形態のさらなる実施形態では、災害警戒警報メッセージは、災害回復勧告を含む。

ステップ３４０のいくつかの実施形態では、回復勧告は：リソース割り当て勧告、リソース必要条件または回復パラメータ（例えば、予想される負荷またはＲＴＯ必要条件）、を含むことができる。

いくつかの実施形態では、ステップ３５０は、ネットワークステータス／性能／損傷／勧告情報または（１つまたは複数の）災害警戒警報メッセージのうちの１つまたは複数内のステップ３４０からのアプリケーション必要条件に基づく情報を取り込むステップを含む。

いくつかの実施形態では、ステップ３７０は、後で受信されるクラウドネットワークメトリックスに基づいて、災害警告または事象が終了すると判定するステップを含む。例えば、データセンタ（例えば、データセンタ１８０−ａ）からのモニタされるトラフィックフローがドロップしていることに基づいて、災害警告が決定される場合には、モニタしたトラフィックフローが回復していることを後で受信するクラウドネットワークメトリックスが示すのであれば、災害警告は終了されてもよい。

いくつかの実施形態では、ステップ３７０は、時間しきい値に基づいて、災害警告または事象が終了すると判定するステップを含む。例えば、実際の災害が３０分以内に記録されない場合には、システムは、災害警告を終了することができる。

さらなる実施形態では、ステップ３７０は、ステップ３３０の災害条件判定を修正するステップを含むことがある。例えば、モニタされるトラフィックフローが１１：３０ＰＭにドロップしようとしているが、トラフィックが再開すると災害警告は１２：００ＰＭに常に終了することに基づいて、システムが災害警告を繰り返し送る場合には、ステップ３３０は、これらの誤検出を多少なりとも解消する試みで修正されることがある。もう１つの例では、災害警告が時間しきい値の終了に基づいて終了する場合には、災害警告終了の直ぐ後に別のアラームをトリガしないように、ステップ３３０は、より厳しい判定特性を含むように修正されることがある。

ステップ３５０では、災害警戒警報メッセージの作成を他の方法ステップのうちのいずれかからの情報に基づくものにすることは、任意の形式の情報の包含物を含むことができ、そして災害警戒警報メッセージ内の情報を「コピーすること」を必要としないことを理解されたい。

図４は、図２のステップ２４０に図示したように、迅速な災害回復準備を実行するための回復リソース（例えば、図１のデータセンタ１８０内のアプリケーションまたはネットワーク１３０内のリソース）のための方法４００の実施形態を図示する流れ図を示す。本方法は、図３のステップ３６０のあいだに送られたような、１つまたは複数の災害警戒警報メッセージを受信するステップ（ステップ４２０）を含む。本方法を実行する装置は、次に、受信した災害警戒警報メッセージを構文解析し（ステップ４３０）、その後：（ｉ）迅速なエラスティシティ（ｅｌａｓｔｉｃｉｔｙ）を実行する（ステップ４４０）、（ｉｉ）動作回復ポリシを事前調整する（ステップ４５０）、または（ｉｉｉ）ネットワークを事前調整する（ステップ４６０）。最後に、本方法は、装置を通常動作に戻すステップを含む（ステップ４７０）。

方法４００では、ステップ４２０は、（例えば、データセンタ通信チャネル１８５を介して、ネットワーク１３０内の通信チャネル（図示せず）を介して、またはそれ自体から直接）１つまたは複数の災害警戒警報メッセージを受信するステップを含む。

方法４００では、ステップ４３０は、（１つまたは複数の）受信した災害警戒警報メッセージを構文解析するステップを含む。特に、災害警戒警報メッセージは、もしあるならば、ステップ４４０、４５０、または４６０のどれが実行されるべきであるかを判定するために構文解析される。装置が１つのステップ（例えば、ステップ４４０）だけを実行することができ、災害警戒警報メッセージが単に災害警告指標であってもよいことを理解されたい。

方法４００は、ステップ４４０を任意選択で含む。ステップ４４０は、迅速なエラスティシティを実行するステップを含む。特に、本方法を実行する装置は、装置が輻輳状態をまだ検出していない場合でさえ、災害警戒警報メッセージの受信に基づいて迅速な弾力的拡大を始める。迅速な弾力的拡大は、通常の弾力的拡大とは異なる。通常の弾力的拡大では、負荷がある期間にわたって利用しきい値を超えた後で、能力は、定常状態で拡大される。迅速な弾力的拡大では、能力は、予測されるトラフィックの急激な増加への準備で（すなわち、負荷が利用しきい値を超えたという判定に基づかないで）増加される。

方法４００は、ステップ４５０を任意選択で含む。ステップ４５０は、回復ポリシを事前調整するステップを含む。特に、本方法を実行する装置は、災害警戒警報メッセージの受信に基づいて装置のクラウドネットワークリソースのうちの１つまたは複数についての装置の動作ポリシを修正することができる。動作ポリシを修正するステップは：（ｉ）サービス品質のパラメタを構成するサブステップ、（ｉｉ）低優先度／オフラインタスクを区別するサブステップ、または（ｉｉｉ）類似のサブステップ、を含むことができる。

方法４００は、ステップ４６０を任意選択で含む。ステップ４６０は、ネットワークを事前調整するステップを含む。特に、本方法を実行する装置は、トラフィックフローを再構成すること、（１つまたは複数の）回復アプリケーション／（１つまたは複数の）リソースの帯域幅を増加させること、等ができる。

方法４００は、ステップ４７０を任意選択で含む。ステップ４７０は、通常モードの動作に装置を戻すステップを含む。特に、ステップ４４０、４５０および４６０のうちの１つまたは複数において取られた準備は、「ロールバック」されることがある。

いくつかの実施形態では、ステップ４４０は、大きな弾力的拡大を含む。大きな弾力的拡大は、通常拡大と比較して２倍よりも大きい倍率の回復クラウドネットワークリソースの拡大である。これらの実施形態のいくつかでは、大きな弾力的拡大は、通常拡大よりも１０倍大きい。

いくつかの実施形態では、ステップ４４０は、格納された値に基づいて弾力的拡大動作を開始する。例えば、格納した値は、回復データセンタ上のアプリケーションが、認証サーバなどの回復クリティカルパス内の要素に対して１００％以上能力を増加させることを規定することができる。さらなる実施形態では、複数の値が、時間または日、曜日、等の動的な情報に基づいて格納されることがある。

いくつかの実施形態では、ステップ４４０は、装置に利用可能な情報に基づいて弾力的拡大動作を開始するステップを含む。特に、装置は、個々のアプリケーションの予想される負荷またはＲＴＯ必要条件のうちの１つまたは複数を満足させるために十分なリソースを割り当てることができる／十分なアプリケーションインスタンスを開始することができる。例えば、情報が、あるアプリケーションに対して１５分のＲＴＯを指定する場合には、ユーザ資格をホストする回復装置上の認証データベースは、弾力的拡大動作を、１５分未満の時間枠内にすべてのユーザ（例えば、図１のクライアント１２０）についての資格を有効にするための能力に基づくものにすることができる。災害事象に続く回復データセンタへのユーザ認証要求の急激な増加に適応させるために、弾力的拡大動作が、通常動作に対して要求されるものよりさらに積極的に能力を拡大させることができることを理解されたい。

いくつかの実施形態では、ステップ４４０は、（１つまたは複数の）災害警戒警報メッセージに含まれる情報に基づいて弾力的拡大動作を開始するステップを含む。（１つまたは複数の）災害警戒警報メッセージは、弾力的拡大動作を、：（ｉ）受けるであろう予想される負荷、（ｉｉ）ＲＴＯ必要条件、（ｉｉｉ）ＱｏＳポリシ、（ｉｖ）ネットワーク構成、（ｖ）などに基づくものにするように任意の適切な情報を含むことができる。予想される負荷は、弾力的拡大動作を：負荷、リソース必要条件、影響を受けたユーザの数、または影響を受けたデータセンタのサイズなどのいずれかの他の関連する二次情報、などに基づくものにするように任意の適切な情報を含むことができる。例えば、災害警戒警報メッセージが災害の影響を受けたデータセンタのサイズについての情報を含む場合には、回復データセンタ（例えば、図１のデータセンタ１８０−ｂ）内のアプリケーションは、小さい災害の影響を受けたデータセンタに対して５０パーセント（５０％）および大きい災害の影響を受けたデータセンタに対して１００パーセント（１００％）だけリソースを拡大することができる。

いくつかの実施形態では、ステップ４４０は、「ちょうどよい（ｊｕｓｔ ｒｉｇｈｔ）」弾力的拡大動作を模倣するステップを含む。「ちょうどよい」弾力的拡大動作は、ほぼ予想される瞬間的なトラフィック拡大まで能力を急激に増加させる。例えば、災害警戒警報メッセージが移動されるであろう負荷の推定を含む場合には、本方法を実行している装置は、予測される負荷を取り扱うために十分に能力を急激に増加させることができる。これらの実施形態のいくつかでは、アプリケーションは、バッファゾーンを与えるために予測される負荷よりも大きく能力を急激に増加させることができる。いくつかの実施形態では、安全ゾーンは、１０パーセント（１０％）以下であってもよい。

いくつかの実施形態では、ステップ４５０は、動作ポリシを修正するステップを含む。これらの実施形態のいくつかでは、本方法を実行する装置は、低優先度タスクまたはオフラインタスクを延期することができる。これらの実施形態のいくつかでは、本方法を実行する装置は、影響を受けたユーザを扱うためにより多くのリソースを利用可能にさせるように、ＱｏＳを修正することができる。

いくつかの実施形態では、ステップ４５０は、（１つまたは複数の）災害警戒警報メッセージに含まれた情報に基づいて（例えば、ＨＴＴＰアダプティブビットレートストリーミングを使用して）アダプティブビットレートを設定するステップを含む。例えば、ビデオ配信アプライアンスなどの回復リソースは、ビデオ用のビットレートがある期間のあいだ削減されることを勧告する情報を有する災害警戒警報メッセージを送られることがある。ビデオ帯域幅のこのような削減は、システムが災害に続いて直ちにトラフィック（例えば、認証トラフィック）の急激な増加を取り扱うことを可能にすることができる。

いくつかの実施形態では、ステップ４５０は、ＱｏＳトラフィック管理ポリシを設定するステップを含む。１つのさらなる実施形態では、ルータなどの回復リソースは、ある期間のあいだ厳しい優先度キューに設定されるキューイングポリシを勧告する情報を有する災害警戒警報メッセージを送られることがある。例えば、高優先度パケットまたはリアルタイムパケットの配信を容易にすることに役立つように−他のパケットタイプを待たせることを代償にしてである。第２のさらなる実施形態では、ルータなどの回復リソースは、あるタイプのパケット（例えば、ビデオ）がドロップされることを勧告する情報を有する災害警戒警報メッセージを送られることがある。第３のさらなる実施形態では、データセンタ内のアプリケーションなどの回復アプリケーションは、バックアップポリシが処理オーバーヘッドを軽くするためにある期間のあいだ軽くされる、または直ぐのバックアップが強要される（例えば、データセンタがリスク地域内にあると、リソースモニタが判定した場合には、遠隔地へのバックアップが、データストアの完全性を保護するために強要されることがある）ことを勧告する情報を有する災害警戒警報メッセージを送られることがある。

いくつかの実施形態では、ステップ４７０は、トラフィックスパイクがある時間間隔のあいだに起きない場合には、ロールバックするステップを含む。いくつかの実施形態では、ロールバック間隔は、３０分未満であってもよい。これらの実施形態のいくつかでは、ロールバック間隔は、インフラストラクチャ−アズ−ア−サービス（ｉｎｆｒａｓｔｒｕｃｔｕｒｅ−ａｓ−ａ−ｓｅｒｖｉｃｅ）がどのようにして料金請求されるかに基づく。例えば、サービスプロバイダは、サービスプロバイダがそのアプリケーションのために使用しているリソースの量に対して１時間単位で料金請求されることがある。この例では、サービスプロバイダは、１時間単位の増分でロールバック間隔を設定することができる。

いくつかの実施形態では、ステップ４７０は、装置が後で「すべてクリア」を受信する場合には、ロールバックするステップを含む。例えば、リソースモニタ（例えば、図１０のリソースモニタ１５０）は、条件が誤検出であるまたは災害が通り過ぎたことによって、災害条件が終了したと判定することができる。この実施形態では、リソースモニタは、災害条件が終了したことを装置に通知する装置への後続のメッセージを送ることができる。

特定のシーケンスで主に示し説明したが、方法２００、３００および４００において示したステップが、任意の適切なシーケンスで実行されてもよいことを理解されたい。その上、１つのステップによって特定されるステップはまた、シーケンス内の１つまたは複数の他のステップで実行されることがある、または１つのステップよりも多くの通常の行為が、１回だけ実行されることがある。

様々な上記の方法のステップは、プログラミングされたコンピュータによって実行されることが可能であることを理解されたい。ここでは、いくつかの実施形態は、プログラムストレージデバイス、例えば、データ記録媒体もやはりカバーするものとし、ストレージデバイスは、マシン可読またはコンピュータ可読であり、命令のマシン実行可能なプログラムもしくはコンピュータ実行可能なプログラムをエンコードし、ここでは、前記命令が、前記上記の方法のステップのうちの一部またはすべてを実行する。プログラムストレージデバイスは、例えば、ディジタルメモリ、磁気ディスクおよび磁気テープなどの磁気記録媒体、ハードドライブ、または光学式可読データ記録媒体であってもよい。本実施形態はまた、上記の方法の前記ステップを実行するようにプログラミングされたコンピュータをカバーするものとする。

図５は、図１のリソースモニタ１５０、データセンタ１８０のうちの１つの仮想マシン、または図１のネットワーク１３０のリソースのうちの１つなどの様々な装置５００の実施形態を模式的に図示する。装置５００は、プロセッサ５１０、データストレージ５１１、およびＩ／Ｏインターフェース５３０を含む。

プロセッサ５１０は、装置５００の動作を制御する。プロセッサ５１０は、データストレージ５１１と協働する。

データストレージ５１１は、（例えば、図３のステップ３２０からの）クラウドネットワークメトリックス、（例えば、図３のステップ３４０からの）収集したクラウドネットワークリソース特性、（例えば、図４のステップ４５０からの）ＱｏＳ必要条件、または（例えば、図４のステップ４６０からの）必要に応じて新しいデータ、などのプログラムデータを格納することができる。データストレージ５１１は、プロセッサ５１０により実行可能なプログラム５２０をやはり格納する。

プロセッサ実行可能プログラム５２０は、Ｉ／Ｏインターフェースプログラム５２１、災害条件検出プログラム５２３、または迅速な災害回復準備プログラム５２５を含むことができる。プロセッサ５１０は、プロセッサ実行可能なプログラム５２０と協働する。

Ｉ／Ｏインターフェース５３０は、上に説明したように（例えば、図３のステップ３２０においてクラウドネットワークメトリックスをモニタする際に、図３のステップ３６０において（１つまたは複数の）災害警戒警報メッセージを送る際に、および図４のステップ４２０において（１つまたは複数の）災害警戒警報メッセージを受信する際に）図１の通信チャネル１２５、１５５または１８５を介して通信をサポートするために、プロセッサ５１０およびＩ／Ｏインターフェースプログラム５２１と協働する。

災害条件検出プログラム５２３は、上に説明したように図２のステップ２３０および図３の方法３００の複数のステップを実行する。

迅速な災害回復準備プログラム５２５は、上に説明したように図２のステップ２４０および図４の方法４００の複数のステップを実行する。

いくつかの実施形態では、装置５００は、仮想マシンであってもよい。これらの実施形態のいくつかでは、仮想マシンは、異なるマシンからの構成要素を含んでもよい、または地理的に分散されてもよい。例えば、データストレージ５１１およびプロセッサ５１０は、２つの異なる物理マシン内にあってもよい。

プロセッサ実行可能なプログラム５２０がプロセッサ５１０上に実装されると、プログラムコードセグメントは、特定の論理回路と同様に動作する特有のデバイスを形成するためにプロセッサと結合する。

例えば、プログラムおよび論理がデータストレージ内に格納され、メモリがプロセッサに通信可能に接続される実施形態に関して本明細書において示し、説明したが、このような情報が：任意の適切な配置のデバイスに通信可能に結合された任意の適切な配置のメモリ、ストレージもしくはデータベースを使用して、（１つもしくは複数の）メモリ、（１つもしくは複数の）ストレージもしくは（１つもしくは複数の）内部もしくは外部データベースの任意の適切な組み合わせ内に情報を格納して、または任意の適切な数のアクセス可能な外部メモリ、ストレージもしくはデータベースを使用して、任意の他の適切な方式で（例えば、任意の適切な数のメモリ、ストレージもしくはデータベースを使用して）格納されてもよいことを理解されたい。そのようなものとして、本明細書において呼ばれるデータストレージという用語は、（１つまたは複数の）メモリ、（１つまたは複数の）ストレージ、および（１つまたは複数の）データベースのすべての適切な組み合わせを包括的に含むことを意味する。

本明細書および図面は、単に本発明の原理を図示する。したがって、本明細書において明示的に記述しなかったまたは示さなかったにも拘わらず、本発明の原理を取り込んであり、かつ本発明の精神および範囲内に含まれる様々な配置を、当業者なら考案することが可能であろうことが理解されよう。さらにその上、本明細書において列挙したすべての例は、本発明の原理および本技術をさらに進めるために（１人または複数の）発明者によって提供された概念を理解する際に読者を助けるために、明確に教育的な目的のためだけであるように原理的に意図され、このような具体的に列挙した例および条件に限定されないように解釈されるべきである。その上、本発明の原理、態様および実施形態ならびにこれらの具体的な例を列挙している本明細書中のすべての記述は、これらの等価物を包括的に含むものとする。

「プロセッサ」として名付けた任意の機能ブロックを含む図に示した様々な要素の機能は、専用のハードウェアならびに適切なソフトウェアと協働してソフトウェアを実行することが可能なハードウェアの使用を通して実現されてもよい。プロセッサによって実現されるときには、機能は、１つの専用プロセッサによって、１つの共有プロセッサによって、またはプロセッサのいくつかが共有されることがある複数の個別のプロセッサによって実現されてもよい。その上、「プロセッサ」または「コントローラ」という用語の明示的な使用は、ソフトウェアを実行することが可能なハードウェアだけを指すように解釈されるべきではなく、限定ではなく、ディジタル信号プロセッサ（ＤＳＰ）ハードウェア、ネットワークプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ソフトウェアを格納するための読出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、および不揮発性ストレージを暗に含むことができる。従来型および／またはカスタムの他のハードウェアも、やはり含まれてもよい。同様に、図に示したいずれかのスイッチは、単に概念的なものである。これらの機能は、プログラムロジックの動作を介して、専用ロジックを介して、プログラム制御および専用ロジックの相互作用を介して、または手作業でさえ実行されることがあり、特定の技術が、コンテキストからより具体的に理解されるように実施者によって選択可能である。

本明細書内のいずれかのブロック図は、本発明の原理を具体化する例示的な回路の概念的な図を表すことを理解されたい。同様に、いずれかのフローチャート、フローダイアグラム、状態遷移図、疑似コード、等が、コンピュータ可読媒体内に実質的に表現されることがあり、コンピュータまたはプロセッサが明示的に示されているか否かに拘わらず、このようなコンピュータまたはプロセッサによってそのように実行されることがあり得る様々なプロセスを表すことを理解されたい。

Claims (10)

1. 迅速な災害回復準備を行うための装置であって、
   データストレージと、
   データストレージに通信可能に結合されたプロセッサとを備え、プロセッサが、
   第１のネットワークリソースからネットワークメトリックスをモニタし、
   受信したネットワークメトリックスに基づいて第２のネットワークリソースの利用可能性に影響を与える災害条件が生じたと判定し、
   第３のネットワークリソースへ災害警戒警報メッセージを送る
   ように構成され、
   第１、第２および第３のネットワークリソースが、異なるリソースである、
   装置。
2. モニタしたネットワークメトリックスが、モニタしたトラフィックフローを含み、モニタしたトラフィックフローが、１つまたは複数のトラフィックフロー値を含み、災害条件が生じたという判定は、モニタしたトラフィックフローが中断されていることの検出またはモニタしたトラフィックフローが異常なトラフィックパターンを有することの検出のうちの少なくとも１つに基づく、請求項１に記載の装置。
3. モニタしたネットワークメトリックスが、外部由来のセンサ情報を含む、請求項１に記載の装置。
4. 災害条件が生じたという判定が、確信レベルに基づく、請求項１に記載の装置。
5. プロセッサが、
   複数のネットワークリソースを解析し、
   複数のネットワークリソースに基づいて災害回復勧告を決定し、
   災害回復勧告に基づいて第３のネットワークリソースを選択する
   ようにさらに構成される、請求項１に記載の装置。
6. 迅速な災害回復準備を行うための装置であって、
   データストレージと、
   データストレージに通信可能に結合されたプロセッサとを備え、プロセッサが、
   災害警戒警報メッセージを受信し、
   迅速な弾力的拡大動作を実行するように構成され、迅速な弾力的拡大動作が、利用しきい値を超える前にネットワークリソースの拡大を含む、装置。
7. 迅速な弾力的拡大動作が、受信した災害警戒警報メッセージに基づく速度拡大をさらに含む、請求項６に記載の装置。
8. プロセッサが、
   トラフィック負荷をモニタし、
   モニタしたトラフィック負荷に基づいて災害条件が存在しないと判定し、
   災害条件が存在しないという判定に応答して、弾力的縮小動作を実行するようにさらに構成され、弾力的縮小動作が、ネットワークリソースの拡大の少なくとも一部を解除する、請求項６に記載の装置。
9. 迅速な災害回復準備のための方法であって、
   データストレージに通信可能に結合されたプロセッサにおいて、第１のネットワークリソースからネットワークメトリックスを受信するステップと、
   データストレージと協働するプロセッサによって、受信したネットワークメトリックスに基づいて第２のネットワークリソースの利用可能性に影響を与える災害条件が生じたと判定するステップと、
   第３のネットワークリソースへ災害警戒警報メッセージを、データストレージと協働するプロセッサにより送るステップと
   を含み、
   第１、第２および第３のネットワークリソースが、異なるリソースである、
   方法。
10. 災害警戒警報メッセージを、第３のネットワークリソースによって受信するステップと、
    迅速な弾力的拡大動作を、第３のネットワークリソースによって実行するステップとをさらに含み、迅速な弾力的拡大動作が、利用しきい値を超える前にネットワークリソースを拡大させる、請求項９に記載の方法。

Images